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

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

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

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

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

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

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

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

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


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

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

Комментарии

Популярные сообщения из этого блога

Карта компетенции аналитика

Оценка эффективности работы руководителя проектов

Драйв