Как мы по шагам строим корпоративную архитектуру банка29.02.2024 14:00

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

Если прежде ключевые решения централизованно принимались в головном офисе и доводились до банков в разных странах «сверху», то теперь ситуация потребовала взрастить экспертизу для принятия решений внутри организации. Для этого был необходим комплексный взгляд на всю организацию и её процессы, потребности в котором не существовало ранее. Его нужно было оперативно создать, что требовало существенной смены команды: от лиц, принимающих решения до сотрудников на местах. Процедуры бывшей головной организации потеряли актуальность, мы временно ушли на «ручное» принятие решений. В результате на отдельных направлениях слились контролирующая и исполнительская функции, что приводило к субъективности принятия решений. Одновременно с этим, как и у всех в финансовом секторе, происходили изменения банковского рынка, возникали задачи по импортозамещению. Ситуация явно требовала по-новому подходить к выстраиванию процессов и процедур. Отвечая на эти вызовы, в конце 2022 года мы начали выстраивать в банке корпоративную архитектуру.

Когда произносят термин «корпоративная архитектура», всегда кажется, что это одновременно и достаточно очевидная, и совершенно непонятная субстанция. Огня добавляет тот факт, что и определения в TOGAF«е и прочих источниках звучат общо, размыто и отличаются от одного источника к другому. В корпоративной архитектуре есть набор элементов, они широко известны: это модели бизнес-процессов, бизнес- и системные функции, набор данных и сущностей, структуры и роли, системы и приложения, конфигурационные единицы, на которых выстраиваются потоки создания ценности. Выгоды банк начинает получать сразу, как только выстраиваются устойчивые связи между компонентами, т. е. они работают на одну цель.

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

Проект

Безусловно, чтобы двинуться по этому пути, нам нужно зафиксировать текущее состояние, asis и, взвесив объём работ, уровень вовлечения мидл-менеджмента и профильных экспертов, мы приняли решение открыть проект с одноимённым названием, в котором зафиксировали три этапа на пути к большой цели. Это, собственно:

Инвентаризация текущего состояния по всем слоям архитектуры.
Отрисовка на базе полученной информации ландшафта в формате AS IS.
Проектирование целевого ландшафта (на горизонте 2023–2025 годов) и «дорожной карты» к нему.

Мы создали Штаб архитектуры — функциональную команду профильных экспертов уровня Enterprise по всем слоям архитектуры, а именно:

Бизнес-архитектор.
Архитектор данных.
Архитектор слоя приложений.
Архитектор инфраструктурного слоя.

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

1-й этап — инвентаризация

Мы понимали, что максимальная синергия будет достигнута за счёт гармоничного развития всех компонентов корпоративной архитектуры, и если этого добиться, то мультипликационный эффект будет ощутим сразу на нескольких уровнях:

Наличием актуальной, структурированной, непротиворечивой и сведённой в единый формат информации мы добьёмся сокращения времени на разработку возможных сценариев реализации и выбора целевого решения, тем самым снизив время этапов delivery (постановка задачи, разработка и согласование архитектурного видения и т. д.).
Детальная информация по всем слоям архитектуры, будь то набор процессов, реализующихся на конкретном сегменте ландшафта, затронутые бизнес- и системные функции, направление потоков данных, конфигурационные единицы, сильно расширяет спектр имеющихся возможностей, позволяет обнаружить и впоследствии устранить дублирование функционала & персонала и убрать double cost на любом этапе реализации, т. е. фактически добавляет прозрачности в управленческих действиях.

Поэтому мы отвели целый квартал на этап 1 — «Инвентаризация», в ходе которого была собрана и актуализирована информация по стеку технологий: фрагментарная информация сведена воедино, дополнены недостающие элементы в универсальных форматах и шаблонах, сопоставлена эта история с теми архитектурными стандартами, которые уже существовали в регламентной базе. Проведена актуализация каталогов и справочников и сформирована «тепловая карта» бизнес-процессов и их покрытия схемами, отрисованными в Sparx EA. Далее был проведён gap-анализ, по результату которого сформирована карта расхождений — стандарты и принципы архитектуры, зафиксированные во внутренних нормативных документах, против обогащённых данных, полученных в рамках инвентаризации.

По сути, этап инвентаризации даёт максимальную фактуру, где «сбоит», в частности, мы выявили проблемы с актуальностью и дублированием в НСИ и ВНД, что напрямую влияет на способность своевременно выявлять и минимизировать избыточную и дублирующую функциональность. Отсутствие эталона с обеих сторон спровоцировало нас на креатив: мы разработали крутую легенду из категорий, позволяющих на этапе инвентаризации не просто дособрать и бинарно оценить, соответствует компонент или нет, а подготовить фактуру для принятия управленческих действий с as is-ландшафтом. Вот она:

«Разрешено текущим стандартом и останется стандартом впоследствии».
«Разрешено текущим стандартом, но должно стать исключением».
«Явно не разрешено, но должно стать стандартом, включая справочники по областям применения».
«Явно не разрешено, к выводу из эксплуатации» — это самая простая категория.
«Явно не разрешено, но используется в силу вендорских ограничений либо должно быть признано исключением».
«Требует дальнейшего анализа» — эта категория присваивалась, когда собранной в инвентаризацию информации не достаточно, требуется дополнительный анализ.

Команда проекта проводила инвентаризацию по разработанным шаблонам и с учётом категорий легенды: какую-то информацию удавалось вытащить централизованно, но с бОльшей частью нам сильно помогли коллеги на местах — сотрудники центров компетенций. На базе этих семи категорий Штабом архитектуры был сформирован технологический радар, и далее с каждой категорией велась отдельная работа. Стоит отметить, что техрадар — довольно удобный формат представления результата этапа инвентаризации, который позволяет визуализировать удалённость компонент от стандарта и критичность ситуации в том или ином домене.

В Блоке ИТ у нас есть отличная возможность поделиться результатом проделанной работы через трансляции на закрытом YouTube-канале. Достижениями проекта корпоративной архитектуры мы регулярно делимся на этой и других платформах. Кстати, первое выступление было как раз по результатам инвентаризации: подобные площадки нужно обязательно использовать не только для демонстрации фактических результатов, но и для популяризации самой идеи и возможности доступным языком объяснить суть и задачи корпоративной архитектуры, а также какую пользу эта история принесёт сотрудникам команд изменений.

2-й этап — целевой ландшафт AS IS — и TO BE

После инвентаризации мы перешли ко второму этапу проекта — выстраиванию целевого ландшафта. Активности по AS IS- и TO BE-ландшафту мы проводили параллельно, это идеальный вариант, потому как есть чёткая взаимосвязь между решением куда-то идти и фиксацией вариантов, как и сколько времени мы живём в нецелевом состоянии, будем ли мы вкладывать ресурс — как человеческий, так и временной — в развитие нецелевого инструмента и как долго (а эти решения, как мы понимаем, могут быть оценены в конкретных суммах).

Как мы формировали целевую архитектуру?

Прежде всего мы выделили четыре уровня, в которые так или иначе вовлечены Архитекторы:

Уровень технологической стратегии Банка.
Уровень целевой архитектуры.
Архитектура домена.
Концептуальная архитектура функциональной области.

В идеальной картине мира эти уровни — зеркальный ответ на бизнес-потребности аналогичной иерархии. Бизнес-цели декомпозируются сверху вниз, а реализованный пакет изменений приводит к апдейту фактической картинки по итогу отчётного периода в формате bottom up.

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

Под каждый уровень мы прописали артефакты, ответственные роли, критерии эскалации и площадку принятия индивидуальных и коллегиальных решений. Например, зона ответственности Solution-Архитектора — концептуальная архитектура функциональной области, где он единолично принимает решения, однако существует набор маркеров, где для валидации подключается Архитектор Домена, т. к. проектируемое решение может повлечь изменения схемы уровня Enterprise. Бывают крупные проекты с вводом новых компонент ландшафта и набором интеграций за пределами одного домена, требующие участия нескольких архитекторов — для них также есть набор критериев, по которым они выносят задачу на уровень вверх, уже на коллегиальное обсуждение — на площадку Архитектурного Комитета.

Концепция корпоративной архитектуры подразумевает выстраивание ландшафта Банка в разрезе слоёв архитектуры начиная от бизнес-слоя к инфраструктуре, поэтому нарезку архитектурных доменов мы привязали к каталогу бизнес-процессов, в результате у нас появились три типа доменов:

Продуктоориентированные.
Обеспечивающие.
Домены процессов управления.

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

Функциональные команды, наоборот, призваны первыми реагировать на потребности бизнеса, гибко перестраивая состав участников и зону охватываемых изменений. Таким образом, нарезка команд часто комплектуется не только от оргструктуры затрагиваемых функций, но и под конкретные задачи. Поэтому где-то границы архитектурного домена и кросс-функциональных команд совпадают, но в большинстве случаев функциональный стрим как пазл своими границами выходит за рамки архитектурного домена. Доменов у нас счётное количество, границы задаются слоем бизнес-архитектуры, т. е. сводной информацией по процессному управлению, функциональной и организационной моделям Банка. Mapping архитектурных доменов и функциональных команд, а также Enterprise-Архитекторов, курирующих домены, стал для нас задачей номер один в построении карты коммуникаций.

Схематично структура ландшафта и уровни архитектуры выглядят так:

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

Архитекторы домена каждый по своему сегменту ландшафта структурировали информацию по всем слоям архитектуры, где-то дополнив, где-то создав с нуля, где-то привязав сущности к конкретному домену. Выжимку в формате агрегации инфо, индикаторов и progress bar собрали в артефакт «Паспорт домена», который впоследствии стал отправной точкой для работы: помимо справочной информации о команде/продукте/канале, в структуру Паспорта выводится инфо о ключевых инициативах домена, влияющих на архитектуру сегмента ландшафта, а также приводится структурированная информация по слоям архитектуры:

По слою бизнес-архитектуры туда сводится информация о бизнес-процессах и функциях, относящихся к периметру домена, их уровню критичности, формируется «тепловая карта» покрытия схемами бизнес-процессов в Sparx ЕА.
По слою данных выводится перечень порождаемых и используемых в данном сегменте ландшафта сущностей.
В блоке, касающемся слоя приложений, у нас есть перечень ИС и МС по классам критичности и с цветовой индикацией «целевой/нецелевой объект», детализация ключевых системных функций с аналогичной индикацией, которая интересна коллегам в процессе разработки solution-решений.
Последний блок сводной страницы Паспорта касается технологического слоя: тут мы считаем полезным выведение Gap«ов по связке «компонент инфраслоя — компонент слоя приложений» в разрезе допустимого в стандартах архитектуры. Мы также прорабатываем подход к увязке компонентов инфраструктурного слоя с системной функциональностью — ключевыми блоками систем-монолитов, что существенно упростит мониторинг состояния legacy.

Cтруктура Паспорта домена:

Создание и поддержание в актуальном состоянии Паспорта как основного артефакта Enterprise-архитектора стало возможным благодаря технологическому радару, сформированному на фазе 1 проекта. Потребителями артефакта являются не только сотрудники Штаба Архитектуры, но и коллеги, вовлечённые в процессы Change Management, Capacity Management, а после реализации всех связок и автоматической актуализации инфо по ним список дополнится Incident Management и командой мониторинга.

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

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

Отдельным достижением проекта я считаю создание и последующую синхронизацию реестров бизнес- и системных функций через справочник объектов, т. е. увязку компонент сразу трёх слоев: бизнес-, данных и ИТ-архитектуры. Подобная аналитика выступает хорошим пререквизитом для Реестра GAP«ов ландшафта в части выявления рассинхрона между его слоями, т. к. позволяет сформировать карту дублирующей и избыточной функциональности. В процессе работы над реестрами были созданы критерии попадания сущностей в справочник объектов, лимитированы права на его управление, обновлены мануалы. За таким, казалось бы, простым набором шагов стоит титаническая работа команды, ведь русский язык богат на синонимы, что даёт пространство вариантов для нейминга сущностей на каждом слое ландшафта…, а также вариаций их привязки друг к другу и как следствие — беспрепятственного создания дублей.

Нельзя просто отфильтровать, выгрузить таблицу и сказать: «У тебя третья и пятнадцатая строки совпадают». Клиент-ФЛ, клиент-ИП-шник и новый клиент — для многих этот набор про одного и того же Иванова Ивана Ивановича, но с точки зрения сущностей это могут быть совершенно разные данные с отличающимся атрибутивным составом и привязанные к разным функциям.

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

Ну и пару слов хотелось бы добавить про выстраивание архитектурных процессов. Мы выбрали горизонт для технологической стратегии, в рамках которого можем сбалансировать конкретику по отдельным архитектурным решениям и гибкость к внешним изменениям. На это нам понадобится два года. Определение срока и формализация критерия целевой/нецелевой компонент архитектуры позволили нам отрисовать TO BE-ландшафт, промаркировать проекты, которые нас приближают к светлому будущему уже сейчас, а также формализовать события, по которым проектный офис будет обмениваться информацией о новых кандидатах в этот список со Штабом архитектуры. Это стало основой процесса мониторинга архитектурных событий, то есть фокусом Enterprise-архитектуры, и тут из интересного, помимо классических ввода/вывода компоненты из эксплуатации, мы, например, фиксируем даты заморозки изменений в нецелевой ИС и конкретный функционал к переносу.

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

Иногда команды изменений привлекают его к реализации, если задача сложная со множеством интеграций или кросс-доменная. Преимущественно это операционка, но она также может выступить источником пересмотра ландшафта, и критерии эскалации вопроса на Архитектор домена в этом смысле одинаковые как для Solution-уровня, так и для Enterprise — появление нового компонента или серьёзный рефакторинг текущего. Ну и уже упомянутые ввод/вывод в эксплуатацию.

Запустив эти два увязанных между собой процесса, мы фактически отстроили процедуру непрерывной актуализации того среза инфы, которую собрали на 1-м этапе проекта:

Сложности

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

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

Банк — живой организм, в ландшафте которого постоянно происходят изменения, и многие знают, что особенно напряжённым является 1-й квартал: это не только календарная смена года, когда закрывается большой объём отчётности и в целом подводятся финансовые итоги предыдущего года, но и период маркетинговых акций и специальных условий для клиентов, что является дополнительной нагрузкой на специалистов поддержки. Так совпало, что инвентаризация стартовала именно в 1-м квартале 2023 года, и мы особенно благодарны за расстановку приоритетов и глобальную поддержку руководству Банка в этот период.

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

Чем мы как Банк рискуем в этот момент? Во-первых, black box, то есть объём неизвестных нам изменений на отдельно взятом сегменте ландшафта. Рано или поздно отсутствие архитектурного надзора приведёт к реализации рисков, неочевидных при автономной оценке изменений внутри такой команды. Во-вторых, растёт зависимость организации от отдельных сотрудников и как следствие — стоимость функции. В случае если мы расстаёмся с сотрудниками такой команды, то неизбежно возникают риски отсутствия документированности изменений.

Работа с такими командами подразумевает бОльший объём ресурса как на социализацию концепции и ключевых процедур, так и на доращивание отдельных специалистов при разделении Enterprise- и Solution-уровней. Мы действовали через пилотирование нововведений на отдельных участках, независимую оценку результатов/lesson learn и веерное подключение к целевой схеме взаимодействия.

Результаты

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

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

Ни для кого не секрет, что ресурс — это дефицит. На что его стоит потратить прямо сейчас и почему? Есть ли возможность объединить задачи разных направлений? Как реализовать максимально выгодным способом и без переделок? Как сравнить варианты реализации? В какой момент нужно остановиться с кастомизацией и взглянуть на рынок? При корректно выстроенных процессах корпоративной архитектуры у нас достаточно фактуры для ответа на любой из этих вопросов в моменте, а также при обсуждении тактических и стратегических решений.

Поэтому логичным продолжением процессных изменений в нашем случае явились изменения организационные: мы объединили команду бизнес- и ИТ-архитекторов в единый департамент, синхронизировав их работы в рамках 2-го этапа проекта.

Что ещё предстоит сделать?

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

Поэтому в 2024-м дорогу к целевому ландшафту мы планируем осваивать через тесное сотрудничество с бизнес-блоками, для чего свяжем этот процесс со стратегией развития Банка в целом и портфелем изменений в частности. Мы уже встроили механизм мониторинга архитектурных событий в проектное управление и будем соединять эти процессы дальше.

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

Вторым направлением мы видим выстраивание партнёрства с HR-блоком в части функциональной модели и организационного проектирования. Выгоды по этому направлению можно будет ощутить после стандартизации ролевой модели, устранения дублей и избыточного функционала по отдельным направлениям, но теперь мы сосредоточимся не на инструменте и данных, а на отдельных ролях, профилях сотрудников и ключевых функциях. Такая унификация упростит формирование и актуализацию профиля, например, к подбору на типовые и run-позиции, снизит стоимость отдельных функций.

Что можно посоветовать коллегам?

Приветствуйте инициативу изменений. Берите в команду критиков и скептиков. Чем больше возражений вы отработаете на этапе гипотез, тем более совершенный продукт вы получите в roll out.

Что бы я сама сделала по-другому, если бы начала процесс изменений сначала? Вела бы видеозапись наших шторминг-сессий: это было забавно, искренне и трепетно по отношению к нашему «Хоум Банку».

P. S.
В октябре я рассказывала о промежуточных результатах нашего проекта на Arch Days 2023 — ежегодной конференции архитекторов. Данное мероприятие — особенный день для всех ИТ-архитекторов, возможность не только обсудить инновации по профилю, но и рассмотреть интересные варианты реализации проблем, с которыми сталкиваются повсеместно. Мне было приятно получить высшую оценку и множество откликов по результатам голосования за спикеров мероприятия. Один из сотрудников нашего Банка, присутствовавший в зале, встретил своего бывшего руководителя, который прокомментировал моё выступление словами: «Теперь я понимаю, почему и зачем ты ушёл, какую интересную задачу тебе подвесили и что тебя увлекло!» На мой взгляд, искренний интерес и признание коллег архитектурного сообщества — лучший мотиватор двигаться дальше.