Архитектура — всё. Да здравствует архитектура
Привет! В одном из прошлых постов мы рассказывали вам, что в МКБ пришел Главный архитектор (ГА), Клецких Дмитрий. Проанализировав и оценив состояние дел, новый руководитель занялся изменениями, внедрением новых процессов и методологии. Собственно, об этом и будет пост.
Люди
Как водится, сначала о главном — о людях. Главный архитектор провёл ряд организационных изменений, в результате которых отдел архитектуры, находящийся в организационной структуре на уровне Дирекции информационных технологий, перестал существовать.
Без паники, перестал существовать именно сам отдел в старой иерархии, а не архитекторы — все они были переведены в непосредственное управление главному архитектору на уровне дирекции, с прямым подчинением CIO. Почему именно так? Потому что ранее архитектурный отдел не был в операционном управлении у Директора ИТ (фактически руководство осуществлялось руководителем, ответственным за реализацию delivery-решений).
Чтобы устранить конфликт интересов и поднять значимость архитектурной функции, в ИТ и появилась новая роль «главный архитектор», отдел был упразднен, а архитекторы переведены в подчинение главному архитектору.
А ещё это дало отличную возможность сделать сразу несколько полезных для работы вещей:
пересмотреть должностные инструкции архитекторов;
свободно распределять их по направлению деятельности в матрице ответственности;
вынести и изменить процессы архитектуры на уровне всей ИТ-составляющей;
расширять штат корпоративной архитектуры новыми сотрудниками.
Методологии
Бытует мнение, что когда в компанию приходит новый директор по маркетингу, он проводит ребрендинг. Чего угодно — от общих рекламных кампаний до сайта или приложения.
Когда в компанию приходит новый главный архитектор, он неизбежно приносит полезный багаж знаний и опыта с предыдущих мест работы. Включая и видение «Как всё должно быть». В небольшом стартапе проще было бы взять и всё настроить заново. Но архитектура в МКБ уже прошла длинный (и непростой) путь. В банке уже были и процессы, и внутренние нормативные документы, и репутация. Всё это предстояло переосмыслить, изменить к лучшему и даже создать новое.
Но главное — поменялось отношение к самой архитектуре. Новый подход стал звучать так:
Архитектура — это не сервисная или контролирующая функция, а командная, то есть архитектор — часть производственной команды
Соответственно, все процессы стали пересматривать именно с такой точки зрения.
Вот как теперь выглядит архитектура МКБ:
Она была разделена на уровни проектирования (строки) и архитектурные домены (столбцы). На пересечении же — объекты управления.
Главный архитектор отвечает и регулирует изменения на всех уровнях и доменах.
Корпоративные архитекторы работают на первых двух уровнях, третий находится в зоне ответственности владельцев ИТ-систем и Департамента ИТ-развития.
Определили и утвердили шаблоны стратегической (Enterprise), концептуальной (Solution) и системной архитектур. А раз есть шаблон, то есть и понимание того, что и как нужно сформулировать, заполнить и сделать для получения результатов. Ну и самое главное — по какому именно процессу, кто должен что согласовать и зачем.
Так архитектура внедрилась в сквозной производственный процесс на стадии разработки технического решения, хотя раньше в нем не участвовала напрямую.
Всё это нашло отражение в первом внутреннем нормативном документе под звучным названием «Порядок управления корпоративной архитектурой». Порядок был разработан в кратчайшие сроки, согласован с менеджментом ИТ и утвержден приказом по банку за подписью курирующего ИТ заместителя председателя правления банка Сергея Путятинского.
После этого начали развиваться отдельные архитектурные направления.
Например, были зафиксированы критерии разработки концептуальной архитектуры (КА):
создание новой ИТ-системы;
создание новых информационных потоков;
согласование отклонений или исключений от требований архитектурных стандартов организации;
замена технологического стека или класса критичности системы.
Концептуальная архитектура разрабатывается по шаблону, создается концептуальная схема, заполняются все разделы (включая отклонения и архитектурный долг), и уже после этого созданный документ отправляется на согласование менеджерам ИТ и информационной безопасности.
Бывает и так, что концептуальная архитектура является не просто инкрементом состояния и взаимодействия систем, а привносит изменения в ИТ ландшафт или в технологический стек. Тогда после её согласования вопрос выносится на утверждение Архитектурного совета Банка, где руководители ИТ дополнительно на своем уровне уточняют требования и архитектурные решения.
Отражение этого процесса нашло в новом документе «Положению об архитектурном совете», а сам совет заменил комитет и по слову, и по духу став его преемником.
Что ещё нужно было сделать? Верно, зафиксировать весь процесс, связывающий создание КА и архитектурный совет. Уже утверждён ВНД «Порядок работы процесса концептуального проектирования», в котором подробно уточняются процесс, входные и выходные артефакты на шагах, роли и возможные развилки шагов.
Проверяем теорию на практике
Даже на момент согласования и затем утверждения всех этих документов машина ИТ под управлением корпоративной архитектуры уже заработала по новым процессам.
За какие-то полгода (с конца марта по конец августа) на согласование было запущено более 60 концептуальных архитектур и 28 Архитектурных советов.
Среди этого множества важных для ИТ-вопросов были и ключевые для нашего бизнеса:
Платформа ДБО ЮЛ
Платформа Казначейства
Рефакторинг системы управления резервами
Новая управленческая отчетность MIS
Внедрение нового кредитного конвейера КИБ
«Белые списки» и вопросы импортозамещения
Техническая политика банка
Критерии целевых ИТ-систем, целевые ИТ-системы (MC, BC)
Стратегия трансформации ИТ-ландшафта.
Конечно же, всё это сопровождается сбором и обработкой обратной связи. Меняются и дополняются шаблоны, как презентаций, так и концептуальной архитектуры. Мы стараемся слушать и слышать наших потребителей сервиса.
В чем плюсы такого подхода
Архитектурная практика не может существовать без архитектурных процессов, в рамках которых регулярно появляются архитектурные артефакты, содержащие описание тех или иных архитектурных решений. Без процессов фактически архитектурной функции и нет.
Организации, в которых нет архитектурной функции, несут все риски появления некачественных и неоптимальных ИТ-решений в своем ИТ-ландшафте, что прямо сказывается на достижении стратегических целей бизнеса
Что дальше
Важность архитектуры для любой организации, связанной с ИТ, сложно переоценить. Особенно, учитывая, что цена ошибки на начальной стадии с учетом уменьшения ТТМ непозволительно высока. Мы продолжаем активно развивать наши процессы и компетенции, увеличивать «архитектурные мощности» и покрытие нужд и требований бизнеса.
В ближайших планах — создать и апробировать на практике новые процессы: разработку стратегической архитектуры, управление архитектурным технологическим долгом, архитектурный надзор и контроль, создание и ведение инструмента управления корпоративной архитектурой и прочее.
