Архитектурные антипаттерны

В ходе подготовки небольшого выступления для конференции AgileDays’2014, которая состоится в Москве 21-22 марта, сделал картинку об «антипаттернах» деятельности архитекторов информационных систем. В качестве источника использовал статью Philippe Kruchten «What do software architects really do?», в которой он пытался сформулировать подобные антипаттерны. Филипп Крачтен, в свою очередь, их тоже не сам придумал, а позаимствовал у Scott Ambler (см. Enterprise Modeling Anti-Patterns на сайте Agile Modeling).

architects

По Крачтену, время архитектора в равных пропорциях делится на непосредственно проектирование и общение. Я решил затраченное на общение время разделить на коммуникации с заинтересованными лицами и разговоры с командой проекта. С другой стороны, проектирование складывается из изучения чего-то и придумывания чего-то полезного. В моей интерпретации (впрочем, далекой от оригинала) получается примерно следующее.

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

Второй персонаж – выставочный архитектор, в некотором смысле, противоположен первому. Он тоже хороший эксперт, но уже давно ничего не придумывает. Большую часть времени он проводит в Интернете, выискивая технологические новинки, чтоб затем бесконечно обсуждать их на интернет-форумах  или же на офлайновых конференциях. Порой он может развернуть какую-нибудь софтину и даже собрать пару учебных примеров, но происходит это все реже и реже.

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

Следующий персонаж – PowerPoint architect – встречается практически в каждой компании. Он давно уже ничего не изобретает и ничего не изучает. Ну, разве что почитывает иногда научно-популярные статейки про Big Data, но так в них все равно ерунда написана.  Зато в отсутствии  выстроенных коммуникаций с заказчиком его уж точно нельзя обвинить. Такой архитектор рисует потрясающей красоты картинки, никак не связанные с ИТ. Впрочем, заказчику импонирует доходчивый стиль изложения и отсутствие непонятных терминов.

Смещение акцентов в деятельности архитектора с проектирования на коммуникации – черта наших дней. Может показаться что архитектор, проводящий большую часть времени с рабочей группой проекта – наиболее симпатичный персонаж. Он задает правильные вопросы, помогает команде формулировать варианты решений и даже зарисовывает их в виде архитектурных набросков. Однако такому архитектору катастрофически не хватает времени на изучение современных архитектур, а круговорот проектной деятельности не дает сконцентрироваться на какой-то одной задаче и изобрести что-то стоящее. В негативном варианте развития событий такой эксперт скатывается к деятельности по документированию решений, т.е. становится высокооплачиваемым техническим писателем.

Чтоб не завершать заметку на столь пессимистичной ноте, замечу, что эти антипаттерны всего лишь гротескное отображение действительности. Реальные архитекторы умело маневрируют между такими ролями, успевая разговаривать с разработчиками и заказчиками, изобретать оригинальные решения и быть в курсе современных технологий. Проблемы возникают только в случае “застревания” (акцентирования) в какой-то из перечисленных ролей. Но это свойственно далеко не только архитекторам. «Застревают» буквально все – разработчики, аналитики, тестировщики и менеджеры проектов.  Особенно это свойственно организациям с выстроенными процессами и отлаженным менеджментам. Впрочем, это уже скорее из темы «дилеммы инноватора».

Желание похвалить или поругать картинку – приветствуется. Жду вас в комментариях

Архитектурные антипаттерны: 7 комментариев

  1. Максим, спасибо за интересный пост!

    Картинка: 1) бессистемно совмещает русский и английский текст, 2) рожи архитекторов дают мало представления о сути проблемы. Но сам по себе заход на систематизацию интересный, и вместе с пояснениями картинка становится полезной 🙂
    В качестве развития темы – могу предположить, что реальный архитектор не только маневрирует между этими ролями – он и должен время от времени сознательно занимать ту или иную позицию, в зависимости от фазы проекта(ов). Может быть, и здесь есть система?
    Еще одна игрушка, которая может родиться по итогам этой картинки – это опросник “где Вы в Квадранте Смирнова” – и набор советов по достижению более сбалансированной ситуации 🙂
    Интересно, что оригинальной статье уже больше 5 лет. Вот и говори теперь про быстро меняющийся мир.

    1. Я бы не ограничивался одной позицией, а скорее ввел бы стрелочки из одного квадранта в другой, как, например, консультант – это стрелочка от изучения к команде. От изучения к изобретениям, от команды к заказчику, двусторонняя стрелка между командой и изобретением и т.д.

      Спасибо за комментарий, полезно!

  2. Вопрос о системе маневрирования, упоминаемой Олегом: является ли она метаархитектурой или только объемлющей системой?

    1. Я думаю, что для обсуждения метаархитектуры(мета-модели?) и видов активностей архитектора на различных фазах проекта этак картинка не очень подходит. Для этого скорее подойдет стандартное “4+1” views and viewpoints

  3. Мне кажется, среди ролей – а может и работ, кому что больше нравится – приведенных в посте, не хватает еще нескольких. Как минимум одной – Evalution Architect. То есть оценка работы предложенных архитектур в текущем ландшафте. Так сказать, из наболевшего личного. Человек, который собирает и никак не соберет полную архитектурную картинку на основе метрик. Который работает с Ops-ами и Field-ами, конфигурацией и Support-ами.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *