Senior Solution Architect в EPAM и победитель премии Belarus IT Awards в номинации «Ambassador of Enterprise Backend» Иван Подобед пишет в своей колонке об основах и границах понятия ИТ-архитектуры. 
Не графоманства ради, но для вящего развлечения почтенной публики, хотелось мне представить свой ответ на вопрос «Кто есть ИT-архитектор?». Однако же в процессе написания пришло (внезапно) понимание того, что неплохо было бы начать кратенько с корней — что есть ИT-архитектура. Несовпадение с мнением уважаемой редакции, не менее уважаемой компании-работодателя и очень уважаемой аудитории ресурса допускается и даже весьма вероятно. Далее по тексту термин архитектура будет использоваться в узком смысле — как IT/Software-архитектура, если явно не указано другое.
Приступим. А зачем вообще нужна эта самая архитектура?
Возможные ответы: борьба со сложностью с помощью функциональной и нефункциональной декомпозиции, целостность концепции, достижение приоритетных атрибутов качества (таких как стабильность, производительность), моделирование системы для предсказания соответствию поставленным бизнес-целям.
Архитектура однако важна не только для реализации системы. Она играет определяющую роль в сложности (и цене) интегрирования программной системы в определённую инфраструктуру клиента, в процессы сопровождения и поддержки. В конце концов, архитектура влияет на окупаемость системы, прибыль компании и иногда даже на бизнес-стратегию. Да, бывает и так, хотя для нас более привычны обратные примеры.
Как вы догадываетесь, замахнулся я довольно широко. Оправдано ли это? Посмотрим на определения. Начнем с варианта, предложенного одной международной инженерной организацией:
Architecture is a system fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution (IEEE 1471).
Такое определение способно подвергнуть панике многих «софтваре архитекторов», ибо ничего в нём нет ни про код, ни про паттерны, ни про сборщики мусора с компиляторными оптимизациями. Однако как многие уже догадались, весь трюк как раз в определении того, что есть система. Подставив нужные границы в это определение, мы получим очень много разных архитектур — от архитектуры процессора до архитектуры предприятия, сектора или индустрии (Enterprise Architecture нормально на русский не переводится, это скорее устоявшийся термин, так как к предприятиям имеет косвенное отношение).
Особенно интересно получается, когда в границы системы удаётся захватить нетехнические элементы, — такие, как бизнес-цели, стратегии и процессы. Они умудряются потянуть за собой совсем уже странные вещи, например, промышленные тренды или модели монетизации. Это может звучать жестоко по отношению к профессиональным знаниям и обязанностям ИТ-архитектора, но с другой стороны, считать это частью системы часто приносит большие преимущества за счёт минимизации затрат и рисков на построение моста между бизнес-контекстом и программным решением. Задумайтесь об этом, когда спонсор вашей программной системы со вздохом скажет что-то вроде: «Ваш софт отлично разработан, в срок и в бюджет попали, и работает быстро и надежно. Только не очень-то он нам помогает в нашей работе». Ведь в каждой шутке есть доля шутки, особенно в этой.
Гибкие методологии тоже не панацея, ибо они скорее о том, что заказчик хочет, чем о том, что ему на самом деле нужно. Но это уже совсем другая история, и не мне её рассказывать. Задержусь лишь для того, чтобы оставить тут концепцию Architectural Runway как мост между Agile-принципами и архитектурой.
Степень проникновения нетехнических элементов (и превращения их в технические с помощью нехитрых приёмов) определяет основные уровни архитектуры.
-
Техническая архитектура, оперирующая как раз на уровне кода, подключаемых пакетов, библиотек и фреймворков; бизнес проникает сюда обычно в стартапном режиме либо в виде спецификации требований (она же бывает и в виде бэклога).
-
Архитектура решений (Solution architecture), работающая в границах одной или нескольких технических платформ; бизнес устанавливает цели и метрики проекта, а также входные ограничения (обычно в виде бюджета и сроков), приоритетные атрибуты качества и способы их достижения уже в зоне ответственности системы.
- Enterprise-архитектура, работающая с целями и стратегией бизнеса напрямую, помогая формировать техническую стратегию достижения бизнес целей и устанавливая входные данные для архитектуры программных решений.
Весь в надежде на продуктивное обсуждение и комментарии, морально готовлюсь к заходу уже на святое — на реальную область ответственности архитектора.
*Мнение колумнистов может не совпадать с позицией редакции.
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.