Про архитектора и аналитика

Давайте поговорим о такой роли, как архитектор, точнее о тех, кого принято называть солюшен архитектором (Solution Architrect).

Для начала я расскажу, как я себе понимаю эту роль.

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

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

Отсюда вытекает, что:

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

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

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

Но как системный аналитик может делать эту работу, не понимая и не принимая во внимание ту концепцию, которую архитектор закладывает в систему? Вот и выходит, что системный аналитик должен владеть базовыми знаниями архитектурного проектирования, иначе он не сможет пропустить бизнес-требования через концепцию архитектуры и привести системный анализ к тому результату, который позволит эту концепцию реализовать. А архитектор должен его на этом пути задрайвить. Т.е. архитектор должен хорошо владеть инструментами бизнес- и системного анализа.

Взаимосвязь разработки требований и проектирования архитектуры показана на рисунке (построенную на основе структуры требований, описанной здесь).

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

Обобщая всё это, напрашивается вывод, что техническое управление системным анализом должен осуществлять архитектор.