Привет! В одном из прошлых постов мы рассказывали вам, что в МКБ пришел Главный архитектор (ГА), Клецких Дмитрий. Проанализировав и оценив состояние дел, новый руководитель занялся изменениями, внедрением новых процессов и методологии. Собственно, об этом и будет пост.

Люди

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

Без паники, перестал существовать именно сам отдел в старой иерархии, а не архитекторы — все они были переведены в непосредственное управление главному архитектору на уровне дирекции, с прямым подчинением CIO. Почему именно так? Потому что ранее архитектурный отдел не был в операционном управлении у Директора ИТ (фактически руководство осуществлялось руководителем, ответственным за реализацию delivery-решений).

Чтобы устранить конфликт интересов и поднять значимость архитектурной функции, в ИТ и появилась новая роль «главный архитектор», отдел был упразднен, а архитекторы переведены в подчинение главному архитектору.

А ещё это дало отличную возможность сделать сразу несколько полезных для работы вещей: 

• пересмотреть должностные инструкции архитекторов; 

• свободно распределять их по направлению деятельности в матрице ответственности;

• вынести и изменить процессы архитектуры на уровне всей ИТ-составляющей; 

• расширять штат корпоративной архитектуры новыми сотрудниками.

Методологии

Бытует мнение, что когда в компанию приходит новый директор по маркетингу, он проводит ребрендинг. Чего угодно — от общих рекламных кампаний до сайта или приложения. 

Когда в компанию приходит новый главный архитектор, он неизбежно приносит полезный багаж знаний и опыта с предыдущих мест работы. Включая и видение «Как всё должно быть». В небольшом стартапе проще было бы взять и всё настроить заново. Но архитектура в МКБ уже прошла длинный (и непростой) путь. В банке уже были и процессы, и внутренние нормативные документы, и репутация. Всё это предстояло переосмыслить, изменить к лучшему и даже создать новое.

Но главное — поменялось отношение к самой архитектуре. Новый подход стал звучать так:

Архитектура — это не сервисная или контролирующая функция, а командная, то есть архитектор — часть производственной команды 

Соответственно, все процессы стали пересматривать именно с такой точки зрения.

Вот как теперь выглядит архитектура МКБ:

Она была разделена на уровни проектирования (строки) и архитектурные домены (столбцы). На пересечении же — объекты управления.

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

Корпоративные архитекторы работают на первых двух уровнях, третий находится в зоне ответственности владельцев ИТ-систем и Департамента ИТ-развития.

Определили и утвердили шаблоны стратегической (Enterprise), концептуальной (Solution) и системной архитектур. А раз есть шаблон, то есть и понимание того, что и как нужно сформулировать, заполнить и сделать для получения результатов. Ну и самое главное — по какому именно процессу, кто должен что согласовать и зачем. 

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

Всё это нашло отражение в первом внутреннем нормативном документе под звучным названием «Порядок управления корпоративной архитектурой». Порядок был разработан в кратчайшие сроки, согласован с менеджментом ИТ и утвержден приказом по банку за подписью курирующего ИТ заместителя председателя правления банка Сергея Путятинского.

После этого начали развиваться отдельные архитектурные направления. 

Например, были зафиксированы критерии разработки концептуальной архитектуры (КА):

• создание новой ИТ-системы;

• создание новых информационных потоков;

• согласование отклонений или исключений от требований архитектурных стандартов организации;

• замена технологического стека или класса критичности системы.

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

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

Отражение этого процесса нашло в новом документе «Положению об архитектурном совете», а сам совет заменил комитет и по слову, и по духу став его преемником. 

Что ещё нужно было сделать? Верно, зафиксировать весь процесс, связывающий создание КА и архитектурный совет. Уже утверждён ВНД «Порядок работы процесса концептуального проектирования», в котором подробно уточняются процесс, входные и выходные артефакты на шагах, роли и возможные развилки шагов.

Проверяем теорию на практике

Даже на момент согласования и затем утверждения всех этих документов машина ИТ под управлением корпоративной архитектуры уже заработала по новым процессам.

За какие-то полгода (с конца марта по конец августа) на согласование было запущено более 60 концептуальных архитектур и 28 Архитектурных советов. 

Среди этого множества важных для ИТ-вопросов были и ключевые для нашего бизнеса:

• Платформа ДБО ЮЛ

• Платформа Казначейства

• Рефакторинг системы управления резервами

• Новая управленческая отчетность MIS

• Внедрение нового кредитного конвейера КИБ

• «Белые списки» и вопросы импортозамещения

• Техническая политика банка

• Критерии целевых ИТ-систем, целевые ИТ-системы (MC, BC)

• Стратегия трансформации ИТ-ландшафта.

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

В чем плюсы такого подхода

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

Организации, в которых нет архитектурной функции, несут все риски появления некачественных и неоптимальных ИТ-решений в своем ИТ-ландшафте, что прямо сказывается на достижении стратегических целей бизнеса

Что дальше

Важность архитектуры для любой организации, связанной с ИТ, сложно переоценить. Особенно, учитывая, что цена ошибки на начальной стадии с учетом уменьшения ТТМ непозволительно высока. Мы продолжаем активно развивать наши процессы и компетенции, увеличивать «архитектурные мощности» и покрытие нужд и требований бизнеса.

В ближайших планах — создать и апробировать на практике новые процессы: разработку стратегической архитектуры, управление архитектурным технологическим долгом, архитектурный надзор и контроль, создание и ведение инструмента управления корпоративной архитектурой и прочее.