пятница, 20 марта 2020 г.

Архитектор, кто ты?

Статья подготовлена для корпоративного портала.

Все сложные системы так или иначе выйдут из строя. Между малым и большим, между совершенным и несовершенным есть некий человек или люди, у которых было видение формы вещей; мы называем таких людей "архитекторами". 
-- Гради Буч 

Так получилось, что в рамках проектов консалтинга за последние несколько лет была возможность заглянуть в несколько достаточно крупных (ну и не очень крупных) компаний, занимающихся внутренней или заказной разработкой. Практически во всех этих компаниях были люди, которые в названии должности имели слово «архитектор». Но вот то, чем они занимались, было от области бизнес аналитики до построения хрустальных замков и демонстрации их бизнесу. То, что ниже - это общее виденье, за что же должна отвечать роль архитектора, а о типах архитекторов и детальках их работы поговорим в другой раз.



Не важно, что мы возьмем, - архитектурный фреймворк на основе модели Захмана или Togaf, рекомендации по архитектурной работе в рамках гибких подходов, - мы увидим, что архитектор отвечает за два типа архитектурных артефактов: описывающие фактическую архитектуру и описывающие архитектурные решения. Зачем они нужны и в чем принципиальная разница?

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

Работа по восстановлению архитектуры выполняется архитектором, как правило, индивидуально. Это не означает, что он не общается с техническими специалистами, пользователями систем, другими архитекторами. Нет, это означает, что он собирает информацию, запирается (может быть даже и в башне из слоновой кости) и заполняет таблицы, пишет описания, рисует диаграммы. Остальные заинтересованные лица в этом процессе участвуют как поставщики информации и верификаторы на объективность зафиксированных данных. Да, эти архитектурные артефакты объективны. Они нацелены, чтобы максимально полно отображать окружающую действительность. Самая глобальная ошибка, которую может допустить архитектор на этом этапе, поверить кому-то на слово, не проверив ту самую пресловутую объективную реальность. Сказал разработчик что в таблице пять полей? Отлично, идем и проверяем. Сказал администратор баз данных, что кластер под СУБД из трех машин? Аналогично, идем и проверяем. Самое сложное в этой работе, это осознание того факта, что эта работа на будущее оказывает очень и очень опосредованное влияние.

А вот после того, как появилось понимание, где мы находимся сейчас, можно переходить ко второй существенной части работы архитектора – к принятию архитектурных решений. И здесь ситуация меняется кардинально. Если до этого архитектор работал с объективностью, практически индивидуально, то при принятии архитектурных решений надо понимать, что все решения будут субъективны, иметь существенное влияние на будущее и не принимаются архитектором индивидуально.

В процессе выработки архитектурных решений, роль архитектора заключается больше в направлении заинтересованных сторон по наиболее оптимальному пути. Архитектор здесь прорабатывает варианты, рассматривает какие плюсы и минусы могут быть после их внедрения. Да, именно потому, что никто не знает, к каким последствиям приведет то или иное решение, мы уже не можем говорить о объективизме, все плюсы и минусы решений – субъективны. А дальше, имея фактуру вариантов, заинтересованные лица собираются и при фасилитации архитектора принимают решение. Не архитектор принимает решение, а заинтересованные лица. Архитектор может подготовить замечательное решение, которое решит все проблемы текущей архитектуры и откроет компании огромные возможности для дальнейшего развития, но если спонсор не может выделить на эти изменения достаточный бюджет, то идти по этому пути бессмысленно и надо искать другие, альтернативные варианты архитектурных решений, которые будут может и менее эффективны, но более реалистичны в текущих условиях. И это касается не только спонсора. Предлагает архитектор внедрить новую систему хранения данных, у компании специалистов по ее поддержке нет, на рынке готовых специалистов нет, внешних компаний готовых взять решение на поддержку нет. И что? Есть смысл переходить на эту систему хранения? Вполне возможно и есть, но надо будет включить в план работ не просто найм специалистов, но и их обучение. Или отказаться от архитектурного решения и, если сроки критичны, пробовать реализовывать на имеющемся у компании стеке или стеке, по которому реально найти специалистов.

Если обобщить все вышесказанное, то получается вот такая картина:

Так кто же такой архитектор?

Это человек, который фиксирует текущую объективную архитектуру, предлагает архитектурные решения решающее задачи заинтересованных сторон и помогающий этим заинтересованным сторонам выбрать наиболее оптимальное из рассматриваемых решений. Только ни в коем случае не надо считать, что предложенные архитектором решения не меняются: меняются, да еще как! В процессе обсуждения уточняются, отбрасываются категорически неприемлемые, появляются новые. Главное - вовремя остановиться в обсуждении архитектурных решений и начать их реализовывать.

2 комментария:

  1. Возникает вопрос. До какого уровня архитектор вырабатывает архитектурные решения и как это влияет на работу разрабочиков? Приведите пример из практики успешных архитекторов.

    Возьмем 2 крайности:
    1.Архитектор парит над разрабочиками и ходит в кабинет только РП и заказчика. Он выбирает СУБД, выбирает ЯП, основной фреймворк, рисует модель данных. Все ниже отдается на откуп разработчкам.Синхронно или асинхронно идет вызов, решат разработчки, будет 1 вызов или 2 - реашт разработчики. Разработчики при таком подходе чувствуют и значимость и ответсвенность. Можно даже требовать от разработчиков взамен вырабатывать, фиксировать и согласовывать технические решения. Таким образом разработчки будут делать выработку и описание архитектурных решений (то есть работу разработчика).

    2. Архитектор кропотливо работает бок о бок с разработчиками. Говорит, когда они выбирают не тот уровень изоляции транзакций, когда вместо синхронного вызова делают асинхронный. И, по мнению разработчков, начинает душить этих самых разработчиков. превращая их просто в кодеров.

    ОтветитьУдалить
    Ответы
    1. Как говорит Макс Дороффеев, в любой непонятной ситуации надо включать мозг. Это я к тому, что если у вас команда мидлов-джунов, а система важная, то вариант 2. Та же команда пилит MVP под выкидку, вполне норм вариант 1, т.к. позволяет набить людям шишек. В сыгранной квалифицированной команде архитектор может даже до уровня баз не опускаться, домены нарезал, а дальше аналитик или тимлид сами модель данных сделают. Универсальных решений, как правило, не бывает, в этом сложность проектной работы, но в этом ее и прелесть :)

      Удалить