Средний

8 мин

2.3K

Приветствую! На связи корпоративный архитектор банка Уралсиб - Моне Даниил! СА говорит ''это срочно для бизнеса'', а КА — ''это не по стратегии''? Узнаете себя? Мы нашли способ, как помирить их в одном домене, не жертвуя ни скоростью, ни качеством

Глоссарий (чтобы не путаться)

• КА - Корпоративный архитектор (он же 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-архитектуру компании целиком.

• Определяет стандарты, принципы, целевую архитектуру.

• Следит, чтобы новые решения не противоречили стратегии и не ломали другие системы.

• Участвует в планировании (релизы, кварталы), проводит архитектурный контроль.

 Итого по ролям:

1. В книжках роли чётко разделены. На практике — нет.

2. В каждом домене часто работает один СА, который одновременно является и системным архитектором.

3. Он следит за архитектурой внутри каждой системы своего домена.

4. КА не погружается в детали реализации одной системы, но отвечает за то, как системы общаются между собой через домены.

5. КА также задаёт архитектурные принципы и проверяет, что СА их не нарушает (даже если внутри домена всё красиво).

Фокус на взаимодействие КА и СА

Дальше я беру фокус на связку КА — СА. Потому что именно здесь возникает большинство вопросов, споров и недопонимания.

Где граница?

• КА — стратегия, стандарты, контроль, влияние на другие домены, модель принятия решений

• СА — конкретное решение внутри своего домена, детали реализации, внутренняя архитектура систем.

Зона соприкосновения: любое решение, которое выходит за пределы домена или требует новых интеграций.

Простыми словами: если решение затрагивает только свою систему и существующие интеграции — СА может действовать самостоятельно. Как только появляется связь с новой системой — нужен КА. 

Корпоративный архитектор также прорабатывает границы принятия решений и зоны ответственности команды. Он определяет, какие решения должны приниматься на уровне СА, какие — на уровне КА, а какие — выноситься на архитектурный комитет. Это модель принятия решений: на каком уровне и кем конкретно решение принимается. Без этого каждый раз возникает вопрос «а кто вообще должен это согласовывать?».

У нас в банке, например, мы используем чек-листы привлечения КА — список критериев, по которым СА понимает, что пора звать корпората.

Аналогия для тех, кто любит понятные образы:
Есть отличная аналогия, которую используют во Франции:

КА — это городской планировщик (urbaniste). Он решает, где будут жилые кварталы, где промышленные зоны, как пройдут дороги и где подведут электричество.

СА — архитектор, который проектирует конкретное здание на выделенном участке. Он обязан соблюдать генплан города, но сам решает, сколько будет этажей, из каких материалов строить и где поставить двери.

Ни один архитектор здания не спроектирует город. И ни один городской планировщик не спроектирует детально дом. Но вместе у них получается город, в котором удобно жить.

Как КА взаимодействует с СА (шесть режимов)?

Первое — согласование архитектуры
КА валидирует архитектуру и проверяет, что она не противоречит стандартам и целевой архитектуре. Это может быть задача в Jira, а может — короткий синк раз в неделю, где голосом пробегаются по спорным моментам. 

Второе — запрос на разработку концепции
СА знает, что надо, но не знает, как это реализовать в тандеме с другими системами. Или решения нет — надо купить или разработать что-то новое. Тогда КА погружается в бизнес и предлагает концепцию. А СА потом её детализирует.

Третье — архитектурный контроль
КА согласовал решение. Но надо убедиться, что в итоге реализовали именно то, что согласовали.
Вы скажете: «СА сам может проконтролировать внутри команды». И будете правы. Но контроль КА не лишний. СА может что-то упустить, забыть согласовать новые изменения или ошибиться, решив, что они «ничего концептуально не меняют».
По-хорошему, КА должен провалидировать документацию перед выпуском в прод — для тех решений, где его привлекали. Чтобы заметить критические отклонения. Не чтобы ругать, а чтобы:

• Огласить риски;

• аргументировать критичность изменений;

• проконтролировать создание техдолга и его приоритизацию.

Важно! КА не должен становиться бутылочным горлышком. Он проверяет не каждый чих, а только те изменения, которые были согласованы с его участием, либо изменения, которые могут повлиять на другие домены. Для рядовых релизов внутри домена достаточно контроля самого СА. 

И шестое (неочевидное, но важное) — обратная связь от СА к КА
Именно СА на земле видят, какие стандарты работают, а какие — тормозят разработку. Их фидбек помогает КА корректировать стратегию и делать её более реалистичной. Без этого КА рискует остаться в башне из слоновой кости, рисуя красивые схемы, которые никто не может реализовать.

Гильдия архитекторов
Помимо всего этого, у нас есть своя гильдия архитекторов, где мы обсуждаем проблемы каждого из доменов, делимся инструментами и подходами.

Чем гильдия полезна на практике:

• Позволяет быстро находить cross-domain конфликты до того, как они уйдут в реализацию.

• Формирует единую архитектурную культуру и язык (например, единые правила моделирования).

• Снижает входной порог для новых архитекторов через менторство и готовые шаблоны.

• Создаёт пул экспертов, которые могут подменить или помочь коллеге из другого домена в кризисной ситуации.

Ценность ролей. Что будет, если кого-то убрать?

Если убрать КА:

• Нет единой стратегии — каждый домен живёт своей жизнью.

• Интеграции хаотичные, системы дублируют друг друга.

• Архитектурный долг растёт бесконтрольно.

• Появляется «зоопарк» технологий и несовместимые решения на стыках доменов.

Если нет СА (или он не взаимодействует с КА):

• Бизнес-задачи не превращаются в нормальную архитектуру.

• Решения принимаются локально, без оглядки на общую картину.

• Рано или поздно это выстрелит проблемами на стыках доменов.

Ценность плотного взаимодействия КА и СА:

1. КА получает реалистичную обратную связь — его стратегии не «падают в пропасть».

2. СА перестаёт гадать — он понимает границы своей свободы.

3. Сокращаются итерации согласования: если СА и КА встречаются регулярно, крупные изменения не взрываются в последний момент.

4. Компания получает предсказуемую архитектуру, в которой можно и фичи развивать, и старые интеграции не разваливать. 

Как организовать работу (коротко)?

• КА домена отслеживает релизы своих систем.

• Регулярные встречи для контроля архитектурных изменений.

• КА участвует в квартальном планировании.

• TOGAF? В жизни — «как получится». Главное, чтобы работало, а не чтобы соответствовало фреймворку. 

Заключение

В идеальном мире роли разведены, у каждой — своя чёткая ЗО. В реальном российском enterprise СА и системный архитектор — часто один человек. А граница между КА и СА определяется простым правилом: «если трогаешь что-то за пределами домена — зови КА»

Это не плохо и не хорошо. Это данность, с которой надо работать. Главное — понимать, кто за что отвечает, и не бояться привлекать корпоративного архитектора на ранних этапах.

Потому что один час обсуждения до начала разработки экономит две недели пересогласований на этапе приёмочного тестирования. Проверено на сотне систем.

P.S. А как у вас?

Расскажите в комментариях:

• У вас в компании СА и системный архитектор — это один человек или разные?

• Как часто вы зовёте КА на согласование?

• Есть ли гильдия архитекторов и что она даёт?