Относительно понятия «архитектор» в ИТ есть множество мнений, зависящих от размеров компании, уровня зрелости ИТ организации и личности высказывающегося. Вопросы определения видов архитекторов и их обязанностей поднимаются в телеграм-каналах и на собеседованиях. Я решил изучить и изложить понимание ИТ архитектора в соответствии с определением IT Architecture Body Of Knowledge и описать, как я понимаю положение этой роли в цепочке создания ценности для бизнеса на основании данного определения.
Стоит сказать, что IASA (ассоциация ИТ архитекторов) во вступлении к ITABoK под заголовком Why IT Architecture Instead of Enterprise Architecture or Other пишет, что выбирая термин, они были в трудной ситуации из-за того, что некоторые архитекторы (Enterprise Architect, далее EA) аргументированно позиционируют себя за пределами ИТ. Обращу внимание, что EA рассматриваются как аудитория ITABoK. При этом, чтобы не оттолкнуть другую часть аудитории, которая тесно связывает себя с ИТ, авторы предпочли термин «ИТ» (перед «архитектор»), чтобы определить аудиторию свода знаний.
Итак, ITABoK по-русски следует называть «Свод знаний ИТ архитектора», понимая под ИТ архитектором любого, кто занимается архитектурой в ИТ или вокруг ИТ. Если читатель может получать пользу от свода знаний ИТ архитектора, значит он ИТ архитектор.
ИТ архитектор — абстрактная роль, объединяющая все специализации архитекторов в ИТ и вокруг ИТ (в т.ч. EA).
В главе ITABoK «Что такое архитектура?» под заголовком What is an Architect? описывается ситуация со специализациями. Указано, что архитектор может (само)определяться со своим архетипом (специализацией) на основании того, какие активности он выполняет (бизнес-моделирование с позиций ИТ, управление процессом создания кода, выбор фреймворков и продуктов и т.д.). Однако, все виды имеют общие фундаментальные навыки.
Следующей иллюстрацией показано, что архитектором может быть разработчик с бизнес-компетенциями, бизнес-человек с техническими компетенциями, сетевой или системный специалист, имеющий бизнес-понимание и высокие компетенции в инфраструктуре, ИТ человек, который закрывает разрыв между бизнесом и технологиями, и дано обобщение:
ИТ архитектор — технологический стратег для бизнеса.
Формулировки «технологический стратег» свод знаний придерживается далее как основной, относящейся к ИТ архитектору.
Имеет ли смысл должность ИТ архитектора?
На практике, должность лица, выполняющего архитектурные функции, не сказывается на качестве ИТ архитектуры. Также, найм или выделение должности архитектора, само по себе никак не сказывается, должно быть реальное изменение процессов. Отсутствием формального ИТ архитектора может быть удобно прикрываться. Во введении к ITABoK под заголовком Skill-based Versus Process-based сказано:
Skilled professionals will create a successful architecture practice regardless of process or framework, while unskilled professionals will fail regardless of the quality of their framework.
Переведу писание:
Квалифицированные профессионалы создадут успешные архитектурные практики невзирая на процесс или фреймворк, в то время как неквалифицированные провалятся несмотря на качество их фреймворка.
От себя добавлю, что квалификация, о которой идёт речь, как я это понимаю, это в первую очередь широкая квалификация уровня ИТ (разработка, эксплуатация, понимание процессов) и только во вторую очередь квалификация в рамках специализации по профессии ИТ архитектора. Поэтому, должность (того или иного) ИТ архитектора ни к чему в 99.9% компаний, где эту роль выполняют наиболее опытные члены команды в существующих должностях.
Место архитектора в цепочке создания ценности
Снова поговорим о роли архитектора, а не о должности.
Мест реализации этой роли несколько, и они зависят от того, о каком ИТ архитекторе (специализации) мы говорим. Если сфокусироваться на проектах по программному обеспечению, процесс создания ценности можно грубо разбить на 4 элемента — постановку задачи, разработку, тестирование, организационные мероприятия внедрения. Это этапы, которые в (условно) последовательном процессе дают работающее, полезное программное обеспечение (далее ПО). Теперь погрузимся в первый.
Постановка задачи на разработку ПО
Возьмём постановку задачи на разработку или доработку программного обеспечения и опишем её как функцию некоторой роли:
На входе какие-то бизнес-требования (фигурой показано, что они документированные, предположим так), на выходе документированные технические требования, достаточные для создания или доработки ПО. В компаниях любого масштаба происходит подобное, роль в центре (в общем случае) — аналитик.
Прямоугольниками на схеме я обозначил принципы и ограничения (абстракция), которые должны быть известны аналитику, чтобы получить описанный выход.
Что такое приципы и ограничения?
Аналитик нарабатывает экспертизу. Это означает, что ограничения системы, в рамках которой он выполняет постановку, становятся ему известны от разработчиков, от других аналитиков и из личного опыта, возникающего в результате попыток реализации придуманных им решений. Ограничения — данность при свершившемся (некогда ранее) выборе.
Ситуация с принципами отличается. В существующей системе есть принципы, заложенные ранее, которые передаются тем же путём, что и ограничения. Разница с ограничениями в том, что нарушение принципов может не блокировать выпуск ПО, но вести к нарушениям более высокого порядка, путанице, искажению процессов, созданию технологических узких мест и может блокировать достижение стратегических целей.
Соответственно, если путаница и всё перечисленное за ней имеет место, для разрешения ситуации нужно принятие принципов и изменение системы. Если мы создаём новую систему (или заменяем одну на другую), мы сначала определяем принципы, а после этого выбираем или разрабатываем систему, в которую они заложены. В действующей системе, иногда, возможна реализация новых принципов для какой-то её части.
Получается, что в отличии от ограничений, с которыми мы соглашаемся, принципы мы устанавливаем.
В примере с разработкой ПО для основных участников процесса (для роли аналитика, разработчика, тестировщика) принципы и ограничения данность, но кто-то же должен ими управлять…
Кто управляет принципами и ограничениями?
Расширим схему ещё двумя ролями:
Ролей можно было добавить массу. Не всегда видение бизнеса (само по себе абстрактное понятие) попадает к ИТ архитектору напрямую или выглядит однозначным. Я отобразил концептуальную взаимосвязь понятий и ролей верхнего уровня — текущее состояние ИТ системы, целевое состояние, архитектор, собственник (или высшее должностное лицо) и некоторое видение развития компании, под которое целевое состояние должно быть подстроено.
Такая картина, во всяком случае для меня, позиционирует архитектора как технологического стратега, что соответствует ITABoK.
Тут показано место, где ИТ архитектор (роль, должность не важна), не будучи основным участником процесса разработки, участвует в создании ценности. Основной участник этого этапа — системный аналитик, т.к. после его выходов начинается разработка, которая является прямым продолжением процесса. Помимо этого места, как контролёр и регулятор архитектор участвует на этапе разработки и на любых других этапах, где отвечает за свой уровень.
Иные представления об архитекторе
Есть альтернативные представления, где архитектор встраивается в цепочки по схемам:
- Бизнес-аналитик → Архитектор → Системный аналитик → Разработчики …
- Бизнес-аналитик → Системный аналитик → Архитектор → Разработчики …
- Иная роль → Архитектор → Разработчики …
и т. п. То есть, архитектор является основным участником процесса.
Бывает, такая схема применяется к каким-то подвидам архитекторов (как роль так и должность может называться не ИТ архитектор, но, например, системный или интеграционный). В частности, такой архитектор может проектировать API для взаимодействия сервисов или маппинг сущностей, свойств, полей таблиц данных.
Причисление такой роли к архитекторам происходит, вероятно, из-за того, что нужна роль или должность, высокие технические компетенции которой не позволяют применять к ней слово «аналитик», но это не разработчик. Отличительной характеристикой является то, что такой архитектор оперирует аргументами на уровне разработчиков (на равных, в отличии от аналитика), но включен в основной процесс разработки на этапе постановки задачи, а не реализации, сохраняя, таким образом, (относительно) верхне-уровневый взгляд на объект работы.