Vitalii Tsybulnyk / Виталий Цыбульник

On Software Development / О софтверной разработке

About the author

    Vitalii Tsybulnyk
Vitalii Tsybulnyk is a Software Engineering Manager at Mictosoft Azure.
E-mail me Send mail

Activity

Recent comments

Disclaimer

The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

© Copyright 2008-2018

Какие бывают архитекторы и архитектуры

Мне кажется, что роль Архитектора - это пожалуй одна из самых значимых и одновременно самых неоднозначных ролей в процессе разработки ПО. Это связано с очевидной важностью, но тем не менее неоднозначностью самого понятия "архитектура".

Согласно RUP архитектура - это "высший уровень концепта системы в её рабочем окружении. Архитектура программной системы (в определённый момент времени) - это её организация или структура наиболее значимых компонент, взаимодействующих через интерфейсы, а эти компоненты в свою очередь составлены из более мелких компонентов и интерфейсов."

Однако Мартин Фаулер считает это определение абсолютно надуманным [1], т.к. по его мнению у программных систем нет "высшего концептуального уровня", пользователь имеет обсолютно другое видение концепции системы, чем разработчики, пользователя абсолютно не волнует "структура наиболее значимых компонент". По мнению Фаулера "архитектура - это высший уровень концепта, который сложился у разработчиков о системе в её рабочем окружении. При этом учитывается видение разработчиков уровня эксперта, и именно это делает компоненты такими значимыми - так сказали эксперты." Таким образом, более корректным определением могло бы быть “В наиболее успешных софтверных проектах разработчики-эксперты, работающие над проектом, имеют общее пронимание строения этой системы, которое называется ‘архитектура’. Это понимание включает в себя деление системы на компоненты и их взаимодействие между собой через интерфейсы. Эти компоненты обычно состоят из более мелких компонент, однако архитектура включает в себя только те компоненты и интерфейсы, которые поняты всеми разработчиками." Такое определение лучше, поскольку оно отражает социальную природу арихитектуры, т.к. она не столько зависит от ПО как такового, сколько от того, каков групповой консенсус по поводу этого ПО [1].

Существует и другой стиль определения архитектуры: “арихитектура - это набор решений об устройстве системы, которые должны быть приняты на ранних стадиях проекта”, однако Фаулер не соглашается и с этим, т.к. "архитектура - это набор решений, которые хотелось бы сделать правильно на ранних стадиях проекта, однако это не значит что они окажутся верными с большей вероятностью, чем любые другие". Тем более, что согласно такому определеню, например выбор языка программирования был бы частью архитектуры для большинства проектов, хотя это не так. Всё это демонстрирует сложности формулировки точного определения понятия архитектуры. Говоря проще, "архитектура - это всё наиболее важное в проекте, что бы это ни было" [1].

Так мы приходим к заключению, что раз архитектура - это важные вещи, то Архитектор - это человек, занимающийся наиболее важными для проекта вещами. И вот на этом этапе Фаулер выделяет два типа архитекторов [1]:

 - Architectus Reloadus (по прообразу персонажа из фильма "Matrix Reloaded") - это человек, принимающий в проекте все важные решения. Он делает это потому, что принятие ключевых решений одним человеком повышает целостность системы, и возможно ещё потому, что он не считает остальных членов команды достаточно компетентными для принятия таких решений. Зачастую такие решения должны быть приняты вначале цикла разработки, чтобы у всех остальных был план, которому можно следовать.

 - Architectus Oryzus (если кто-то знает латынь, помогите с переводом) - этот вид архитекторов осведомлён о том, что происходит в проекте, выявляя важные загвоздки и устраняя их до того как они превратятся в серьёзные проблемы. Наиболее важная часть работы таких архитекторов - это интенсивное сотрудничество: работа с разработчиками над кодом, работа с бизнес-аналитиками над техническим смыслом и последствиями реализаций требований и идей на нетехническом языке и т.п. Ценность архитектора этого типа "обратно пропорциональна количеству решений, которые он принимает" [1].

Не менее интересную крассификацию архитектур и архитекторов предлагает Люк Хохман [2]. Он разделяет софтверную систему на два измерения:
 - tarchitecture (техтектура или “техническая архитектура”), за неё обычно отвечает традиционный архитектор или технический руководитель - tarchitect (техтектор)
 - marketecture (маркетектура или “меркетинговая архитектура”), её определяет продукт-менеджер, бизнес-менеджер или програм-менежер - marketect (маркетектор).

Техтектура преобладает, когда разработчики думают об устройстве системы. Маркетектура - это бизнес перспектива этого устройства. Хотя техтектура и маркетектура влияют друг на друга, маркетектура доминирует: маркетектурные вопросы - начиная от юзабилити, апгрейдабилити,  саппортабилити и заканчивая развёртываемостью и надёжнотью (т.н. нефунциональные требования) - меняются радикально от рынка к рынку и влияют на техтектуру более значительно, чем техтектурные вопросы о внутреннем устройстве системы влияют на её бизнес-ценность. Я бы даже усилил это утверждение: по-настоящему хороший продукт начинается тогда, когда маркетекрута полностью перестаёт подчиняться техтектуре, а техтектура в свою очередь действует исключительно в рамках предложенной маркетектуры.

 

Источники 

1. Martin Fowler 'Who Needs an Architect?'

2. Luke Hohmann 'The Difference between Marketecture and Tarchitecture'


Posted by Vitalii Tsybulnyk on Saturday, August 22, 2009 7:21 AM
Permalink | Comments (0) | Post RSSRSS comment feed

Add comment




  Country flag

b i u quote
Loading