Приветствую! На связи корпоративный архитектор банка Уралсиб - Моне Даниил! СА говорит ''это срочно для бизнеса'', а КА — ''это не по стратегии''? Узнаете себя? Мы нашли способ, как помирить их в одном домене, не жертвуя ни скоростью, ни качеством
Глоссарий (чтобы не путаться)
КА - Корпоративный архитектор (он же EA Enterprise Architect). Стратег, стандарты, вся IT-архитектура компании и модель принятия решения.
СА - Архитектор решения (он же SA Solution Architect). Конкретная задача, бизнес-требования, выбор технологий и проработка решений.
System Architect - Системный архитектор. Внутренности одной системы (API, данные, железо) и ее стратегия. Технологическое развитие платформы и контроль соответствия.
Важно! В тексте описана реальная ситуация: в российском enterprise. СА и Системный архитектор — часто один человек. Если они разделены — читайте как «СА + Системный». Если совмещены — просто «СА».
Введение
Представьте компанию с IT-продуктами. Возьмём для примера ту, у которой около 100 систем. Очевидно, что тут помимо техлидов нужны ещё архитекторы. Такие, которые будут контролировать, чтобы это всё не сломалось, но в то же время быстро и безболезненно развивалось.
Так вот, в этой компании есть архитекторы. Они бывают разные. Сегодня я расскажу про три основные роли, которые встречаются в большинстве крупных компаний. А ещё — про взаимодействие между ними, для чего оно нужно и как строится.
По TOGAF архитекторов делят на 4 домена (бизнес, данные, приложения, технология). В реальных российских компаниях это работает… ну, скажем так, с большими допущениями.
Цель статьи — разобрать три роли: корпоративный архитектор (КА), архитектор решения (СА) и системный архитектор. А потом показать, где они пересекаются, где начинают друг друга раздражать и как из этого вырастает нормальная работа.
Кто есть кто?
Системный архитектор
Начнём с него. У нас 100 систем. И вряд ли они написаны на одном языке. И вряд ли они все написаны силами наших разработчиков.
Для контроля всей начинки каждой из систем мы нанимаем системного архитектора.
Зачем он нужен?
Отвечает за внутреннее устройство системы.
Проектирует API, модели данных, схемы коммуникации между сервисами (внутри системы).
Занимается производительностью, отказоустойчивостью, масштабируемостью.
Задает принципы стратегии развития платформы.
Контроль соответствия стратегии развития.
Он знает свою систему вдоль и поперёк. Контролирует, чтобы по ней была полная документация: все схемы, описание потоков, интеграций, сайзинг и особенности.
Хорошо, разобрались. Теперь у каждой системы есть человек, который выполняет роль системного архитектора (я умышленно пишу «выполняет роль», потому что это может быть как отдельный сотрудник, так и техлид или СА).
Архитектор решения (СА)
Дальше — интереснее. Каждая система взаимодействует с другими. Да, системные архитекторы могут общаться между собой и описывать стыки. Но куда эффективнее — поделить системы на группы / подразделения / домены и на каждую группу выделить отдельного человека, который будет заниматься исключительно архитектурой решений.
Что такое «решение» в нашем контексте?
Это бизнес-задача или потребность, которая реализуется через изменение существующей архитектуры: создание нового сервиса, доработка существующего или интеграция между системами. У решения всегда есть границы, сроки и измеримый результат.
Что делает СА:
Отвечает за конкретное решение под бизнес-задачу.
Переводит требования бизнеса в архитектуру.
Выбирает технологический стек, определяет границы системы, интеграции с другими системами.
Работает с бизнесом, продуктом, командой разработки и… системным архитектором.
Проработка и определение оптимального решения. Где баланс между стратегией и тактическими задачами. Для бизнеса надо быстро и дешево, для стратегии - качество и эффективность.
Очень часто СА и системный архитектор — один человек. Более того, один человек может отвечать не за одну систему, а за несколько. Так и получается: человек и следит за внутренностями 10–15 систем, и проектирует решения между ними. Это нормальная практика, особенно когда объём не зашкаливает.
Важное уточнение. Такое совмещение работает, когда на домен приходится 10–20 систем.
Если систем 50+ или они критически нагружены — роли лучше разделять. Но в нашем примере со 100 системами и 4–5 доменами совмещение вполне жизнеспособно.
Корпоративный архитектор (КА)
НО. У нас 100 систем. Допустим, мы разбили их на домены. Получилось 4–5 доменов, а значит, 4–5 СА = системных архитекторов. Хорошо, это ещё не страшно.
Но как они все будут проектировать свои решения и одновременно следить за всеми остальными? Кто скажет, что интеграцию с внешней системой надо делать через единый шлюз? Кто стандартизирует подход к проектированию? Кто проследит за каждым СА и направит их в одну сторону?
Тут и появляется корпоративный архитектор (КА). Он смотрит на всё со стороны, на общую картину. Придумывает, куда двигаться, чтобы через 5–10 лет архитектура не рассыпалась. Разрабатывает общие стандарты. Проводит аудит и контролирует решения, которые выходят за рамки своих доменов.
Что делает КА:
Смотрит на всю IT-архитектуру компании целиком.
Определяет стандарты, принципы, целевую архитектуру.
Следит, чтобы новые решения не противоречили стратегии и не ломали другие системы.
Участвует в планировании (релизы, кварталы), проводит архитектурный контроль.
Итого по ролям:
В книжках роли чётко разделены. На практике — нет.
В каждом домене часто работает один СА, который одновременно является и системным архитектором.
Он следит за архитектурой внутри каждой системы своего домена.
КА не погружается в детали реализации одной системы, но отвечает за то, как системы общаются между собой через домены.
КА также задаёт архитектурные принципы и проверяет, что СА их не нарушает (даже если внутри домена всё красиво).
Фокус на взаимодействие КА и СА
Дальше я беру фокус на связку КА — СА. Потому что именно здесь возникает большинство вопросов, споров и недопонимания.
Где граница?
КА — стратегия, стандарты, контроль, влияние на другие домены, модель принятия решений
СА — конкретное решение внутри своего домена, детали реализации, внутренняя архитектура систем.
Зона соприкосновения: любое решение, которое выходит за пределы домена или требует новых интеграций.
Простыми словами: если решение затрагивает только свою систему и существующие интеграции — СА может действовать самостоятельно. Как только появляется связь с новой системой — нужен КА.
Корпоративный архитектор также прорабатывает границы принятия решений и зоны ответственности команды. Он определяет, какие решения должны приниматься на уровне СА, какие — на уровне КА, а какие — выноситься на архитектурный комитет. Это модель принятия решений: на каком уровне и кем конкретно решение принимается. Без этого каждый раз возникает вопрос «а кто вообще должен это согласовывать?».
У нас в банке, например, мы используем чек-листы привлечения КА — список критериев, по которым СА понимает, что пора звать корпората.
Аналогия для тех, кто любит понятные образы:
Есть отличная аналогия, которую используют во Франции:
КА — это городской планировщик (urbaniste). Он решает, где будут жилые кварталы, где промышленные зоны, как пройдут дороги и где подведут электричество.
СА — архитектор, который проектирует конкретное здание на выделенном участке. Он обязан соблюдать генплан города, но сам решает, сколько будет этажей, из каких материалов строить и где поставить двери.
Ни один архитектор здания не спроектирует город. И ни один городской планировщик не спроектирует детально дом. Но вместе у них получается город, в котором удобно жить.
Как КА взаимодействует с СА (шесть режимов)?
Первое — согласование архитектуры
КА валидирует архитектуру и проверяет, что она не противоречит стандартам и целевой архитектуре. Это может быть задача в Jira, а может — короткий синк раз в неделю, где голосом пробегаются по спорным моментам.
Второе — запрос на разработку концепции
СА знает, что надо, но не знает, как это реализовать в тандеме с другими системами. Или решения нет — надо купить или разработать что-то новое. Тогда КА погружается в бизнес и предлагает концепцию. А СА потом её детализирует.
Третье — архитектурный контроль
КА согласовал решение. Но надо убедиться, что в итоге реализовали именно то, что согласовали.
Вы скажете: «СА сам может проконтролировать внутри команды». И будете правы. Но контроль КА не лишний. СА может что-то упустить, забыть согласовать новые изменения или ошибиться, решив, что они «ничего концептуально не меняют».
По-хорошему, КА должен провалидировать документацию перед выпуском в прод — для тех решений, где его привлекали. Чтобы заметить критические отклонения. Не чтобы ругать, а чтобы:
Огласить риски;
аргументировать критичность изменений;
проконтролировать создание техдолга и его приоритизацию.
Важно! КА не должен становиться бутылочным горлышком. Он проверяет не каждый чих, а только те изменения, которые были согласованы с его участием, либо изменения, которые могут повлиять на другие домены. Для рядовых релизов внутри домена достаточно контроля самого СА.
Четвёртое — контроль изменений в архитектуре домена
Раз в месяц можно встречаться и кратко просматривать все изменения в архитектуре — даже те, на которые КА не привлекали. КА должен быть в курсе актуальной архитектуры компании.
Хороший способ — контролировать релизы команд своего домена.
Пример. Какую-то задачу пропустили мимо КА. Команда реализовала функциональность, которая на самом деле выведена в централизованный сервис. То есть завуалировали функционал и потратили в два раза больше ресурсов. Если этого не заметить — ресурсы будут тратиться вдвое и дальше, при поддержке и развитии.
Пятое — развитие и повышение компетенции
Митапы, привлечение архитекторов к разработке принципов, обсуждение предложений, обратная связь по взаимодействию.
Мы в банке используем ArchiMate. Например, мы привлекали своих СА для обсуждения и формирования СОМ (соглашение о моделировании) и работы в общем репозитории. Собирали обратную связь, предлагали решения, согласовывали с ними. Потому что основной исполнитель — СА, и ему должно быть в первую очередь удобно.
И шестое (неочевидное, но важное) — обратная связь от СА к КА
Именно СА на земле видят, какие стандарты работают, а какие — тормозят разработку. Их фидбек помогает КА корректировать стратегию и делать её более реалистичной. Без этого КА рискует остаться в башне из слоновой кости, рисуя красивые схемы, которые никто не может реализовать.
Гильдия архитекторов
Помимо всего этого, у нас есть своя гильдия архитекторов, где мы обсуждаем проблемы каждого из доменов, делимся инструментами и подходами.
Чем гильдия полезна на практике:
Позволяет быстро находить cross-domain конфликты до того, как они уйдут в реализацию.
Формирует единую архитектурную культуру и язык (например, единые правила моделирования).
Снижает входной порог для новых архитекторов через менторство и готовые шаблоны.
Создаёт пул экспертов, которые могут подменить или помочь коллеге из другого домена в кризисной ситуации.
Ценность ролей. Что будет, если кого-то убрать?
Если убрать КА:
Нет единой стратегии — каждый домен живёт своей жизнью.
Интеграции хаотичные, системы дублируют друг друга.
Архитектурный долг растёт бесконтрольно.
Появляется «зоопарк» технологий и несовместимые решения на стыках доменов.
Если нет СА (или он не взаимодействует с КА):
Бизнес-задачи не превращаются в нормальную архитектуру.
Решения принимаются локально, без оглядки на общую картину.
Рано или поздно это выстрелит проблемами на стыках доменов.
Ценность плотного взаимодействия КА и СА:
КА получает реалистичную обратную связь — его стратегии не «падают в пропасть».
СА перестаёт гадать — он понимает границы своей свободы.
Сокращаются итерации согласования: если СА и КА встречаются регулярно, крупные изменения не взрываются в последний момент.
Компания получает предсказуемую архитектуру, в которой можно и фичи развивать, и старые интеграции не разваливать.
Как организовать работу (коротко)?
КА домена отслеживает релизы своих систем.
Регулярные встречи для контроля архитектурных изменений.
КА участвует в квартальном планировании.
TOGAF? В жизни — «как получится». Главное, чтобы работало, а не чтобы соответствовало фреймворку.
Заключение
В идеальном мире роли разведены, у каждой — своя чёткая ЗО. В реальном российском enterprise СА и системный архитектор — часто один человек. А граница между КА и СА определяется простым правилом: «если трогаешь что-то за пределами домена — зови КА»
Это не плохо и не хорошо. Это данность, с которой надо работать. Главное — понимать, кто за что отвечает, и не бояться привлекать корпоративного архитектора на ранних этапах.
Потому что один час обсуждения до начала разработки экономит две недели пересогласований на этапе приёмочного тестирования. Проверено на сотне систем.
P.S. А как у вас?
Расскажите в комментариях:
У вас в компании СА и системный архитектор — это один человек или разные?
Как часто вы зовёте КА на согласование?
Есть ли гильдия архитекторов и что она даёт?
