Революция как необходимость

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

В чем суть изменений, которые ваша команда проводит в жизнь?

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

Цифровая трансформация ВТБ — это четыре ключевых направления. Первое — изменения производственного процесса таким образом, чтобы вся работа концентрировалась вокруг продукта, а вывод продукта или нового сервиса на рынок был максимально быстрым и надежным.

У нас работают более 180 стримов, которые состоят из 1400 команд общей численностью порядка 20 тыс. человек. Каждая команда владеет своим фрагментом архитектуры банка и своими продуктами. В команды входят и представители бизнеса, и ИТ-специалисты. Они объединены единой задачей создания своего продукта.

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

Второе направление изменений — программно-проектное управление. У нас 16 крупных программ. Они охватывают задачи от фронтенда до лаборатории продвинутой аналитики. Каждая программа модифицирует или заново создает определенные архитектурные слои.

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

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

К каким результатам вы намерены прийти?

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

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

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

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

Важный аспект трансформации — открытость нашей платформы. B июле наша API-платформа получила международную награду английского издания Global Banking & Finance Review и была отмечена жюри PayTech Awards английского издания Fintech Futures. С помощью этого инструмента мы предоставляем нашим партнерам возможности встраиваться в цепочки с нашими продуктами, и также мы можем включать партнерские продукты в свои.

Неужели революция так обязательна? Нельзя ли было пойти более плавным, эволюционным путем?

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

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

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

Основа вашей архитектурной революции — переход от монолитных систем к микросервисам. Почему вы уверены, что микросервисы себя оправдают?

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

Почему я радикальный сторонник разделения на сервисы? Удобно ли иметь один объект управления? Да, конечно удобно. Однако критически тяжело поддерживать его надежность в силу того, что сам по себе объект большой. Продолжительность проведения бэкапов, регламентных работ, обслуживания и восстановления критически зависят от размера баз данных. Этот монстр постоянно растет, в нем увеличивается число связей. Всегда можно создать еще одну таблицу. Всегда можно разработать дополнительную функциональность и связать ее с существующей. Но число и сложность таких связей постоянно увеличивается. Все это может работать только на hi-end-оборудовании и на промышленных базах класса Oracle, которые очень сильно компенсируют ошибки разработчиков.

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

Двадцать лет назад большие объекты и AБC воспринимались в банках абсолютно нормально. Банки, особенно в прошлом, весьма консервативные организации. Но сейчас ситуация другая. Люди хотят получать банковские услуги быстро и просто.

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

Посмотрим на ВТБ за последние годы: присоединения ВТБ24, Банка Москвы и ряда других банков поменьше. В результате в ландшафте несколько АБС всех этих банков, у каждого банка свои монолитные. Традиционно, если архитектура не сервисная, вывод продукта в канал — в каждый канал — это отдельный проект. Надо собрать одних, надо привлечь других, надо составить план, включить в бэклог, и уже спустя три месяца — или полгода — произойдет, возможно, что-то хорошее.

Несколько АБС означает, что одни и те же продукты находятся в разных системах. Сможем ли мы в таких условиях быстро вывести новый продукт для всех наших клиентов? Конечно нет. Либо можем вывести для какой-то части клиентов, что нелогично, либо надо ждать последнего.

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

Не менее важный вопрос: можем ли мы быстро вывести продукт во все каналы, если каждый из них имеет фрагменты продуктовой логики? Нет. Либо не во все каналы, либо опять ждем последнего. Однако любой клиент спросит: а почему я вот этот продукт здесь вижу, а здесь не вижу? Теперь перемножим это все: можем ли в монолитной архитектуре во всех каналах и для всех клиентов быстро внедрить изменения? Нет.

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

Какие преимущества у сервисного слоя? API и слабая связанность компонентов, обеспечивающая массовую параллельную разработку множества сервисов. Все «кубики» довольно независимы, слабо связаны. Целостность каждого сервиса с точки зрения общего архитектурного ландшафта поддерживается как святая святых. Но внутри можно менять сам продукт и быстро выводить его во все каналы.

Для некоторых каналов время вывода продукта, разработанного по стандарту check list VTB platform approved, составляет 4 минуты. Канал не имеет своей продуктовой бизнес-логики. Это своего рода сосуд, готовый быстро наполняться сценариями и сервисами, разработанными параллельно многочисленными продуктовыми командами. Пока это возможно только для части каналов, например для обслуживания в точках продаж и интернет-банка для малого бизнеса, которые мы развиваем практически с нуля. Но это демонстрирует суть нашего подхода.

При этом самое важное для нас — надежность новых сервисов. Любой новый сервис или даже новая технология проходит три стадии зрелости. Вначале он работает при определенных условиях, потом работает в нормальных условиях. Без дополнительных усилий многие сервисы на этом этапе останавливаются в развитии собственной надежности. Но есть и третья стадия — работает при любых условиях, в том числе при отклонениях. Фюзеляж уже пробит в нескольких местах, уже отказал один из двигателей, но самолет летит, и он управляем. Именно так должен работать клиентский сервис в условиях серьезных отклонений. И подобный вопрос не решить банальным резервированием, речь идет о еще одном дополнительном уровне защиты критичных клиентских сервисов на прикладном уровне.

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

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

Как у вас организовано управление изменением архитектуры ИТ-систем?

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

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

Мы ввели новую роль: архитектор блока/директор по ИТ-архитектуре для каждого из направлений — розничный бизнес, малый бизнес и другие, всего около 10 направлений. Линейно они подчиняются мне, а функционально работают с руководителем соответствующего производственного департамента, и мы вместе с ним оцениваем результаты их работы.

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

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

Какие еще управленческие решения помогают вам трансформировать архитектуру?

Еще одно важное управленческое решение — то, что мы договорились на период трансформации для стримов установить «по умолчанию» квоты на архитектурные задачи и устранение технологического долга суммарно на уровне 50%. Конечно, мы бы хотели снизить такую нагрузку, но сначала нужно эти архитектурные проблемы решить. Не честно по отношению к клиенту радовать его новыми сервисами, если мы видим, что внутри сервиса «все завязано на узелках». При этом нам удается поддерживать и высокий темп вывода новых клиентских сервисов за счет того, что темп устранения технологического долга в разы превышает появление нового, и это позволяет в некоторых стримах уже 70–80% бэклога посвящать развитию нового функционала, поскольку потребности в 50%-ной квоте на технологические задачи у них уже просто нет.

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

Во-первых, процент реализованной новой бизнес-функциональности в целевой архитектуре. О наших амбициях и динамике нашего движения свидетельствует то, что при показателе прошлого года на уровне 65% мы поставили себе задачу получить 85% в конце этого года. По итогам первого полугодия мы имеем 80%. Безусловно, каждый следующий процент сложнее предыдущего, но мы контролируемо и уверенно движемся к цели.

Во-вторых, глубина устранения технологического долга. Этот показатель демонстрирует, сколько кварталов уйдет в стриме на устранение техдолга из расчета 30% capacity стрима. Закончить этот год мы должны с показателем, не превышающим один квартал.

Кроме того, под мониторингом находится показатель глубины реализации новых архитектурных задач из расчета 20% capacity стрима, который позволяет архитекторам не только контролировать производство, но и «держать себя в руках», разумно внедряя новые стандарты.

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

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

Каким образом архитектурные требования и стандарты разработки доводятся до программистов, до исполнителей?

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

Важнейшими компонентами для команд является check list VTB platform approved, обобщающий все стандарты сервисной платформы с шаблонами проектирования для каждого из правил и отвечающий на вопрос «как мне спроектировать новый сервис на платформе» и связанный с ним инструментарий «Портал разработчика», уже с шаблонами кода, автотестов, возможностью оперативного получения среды как для понимания «как работает платформа», так и разработки своего сервиса.

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

Какова структура вашей платформы разработки?

Общее для всех слоев — это ориентация на импортонезависимый открытый стек. В теме импортозависимости необходимо обращать внимание не только на слово «импорт», но на «зависимость» как таковую. Поставив перед собой задачу изменить соотношение внутренней разработки vs вендорских решений с 20/80 на 80/20 и приблизившись уже к 70% in-house, мы создаем центры компетенций по ключевым продуктам open source. Мы системно следуем тезису максимальной открытости нашей платформы, поэтому делимся нашим доработками с сообществом, имея в своих рядах признанных сообществами участников.

Итак, самый нижний слой — динамическая инфраструктура, полностью реализованная на open source. Следующие слой — служебные сервисы, составляющие основу платформы в формате PaaS предоставления продуктовым командам. Журнал аудита, сервис трассировки, сервис мониторинга, сервис электронной подписи — всего около 30 сервисов, позволяющих продуктовым командам не тратить время на их изготовление и сосредоточится на бизнес-функционале.

Далее слой из нескольких десятков общих сервисов — например, карточка клиента, нотификация, хранение документов и другие. Бизнес-команды также не отвлекаются на написание этих сервисов, а просто переиспользуют общие через реестр API/API Gateway.

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

И наконец, канальные приложения, являющиеся точкой соприкосновения клиента с нашими сервисами.

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

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

Что вы считаете наиболее важным в глобальной трансформации всех ИТ-систем и подходов?

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

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

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