В ВТБ реализован проект «Управление жизненным циклом данных в условиях постоянных изменений», ставший системным архитектурным ответом на вызовы цифровой трансформации. Он представляет архитектурную инновацию промышленного управления данными. О реализации проекта и его роли рассказывают Владимир Громов, заместитель руководителя департамента технологического развития общебанковских систем, Даниил Казаков, начальник управления архитектуры данных, и Ростислав Даньков, директор по управлению проектами группы методологии управления данными ВТБ, — номинанты на премию Data Award.

- Какие обстоятельства привели ВТБ к реализации этого проекта?

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

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

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

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

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

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

- Какие задачи были поставлены?

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

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

Ответом на эти задачи стала инновационная архитектурная модель, построенная на трех взаимосвязанных ноу-хау.

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

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

Третье — контрактная модель поставки данных. Мы формализовали поставку через дата-контракты, которые фиксируют структуру, формат, правила изменения, SLA, частоту, объем и ответственность сторон. Это позволило превратить поставку данных из технической операции в прозрачный управляемый процесс.

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

- Какие меры приняты относительно качества?

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

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

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

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

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

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

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

- Третье направление — дата-контракты — являются сейчас темой, активно обсуждающейся в профильных сообществах…

В.Г.: Для нас дата-контракт — это не просто техническое описание интерфейса или формата передачи. Это инструмент управляемости, который фиксирует взаимные обязательства сторон при поставке данных.

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

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

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

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

По сути, дата-контракт для нас — это инструмент перевода поставки данных из «серой зоны» в полноценный управляемый контур с понятными правилами, обязанностями и метриками.

- Складывается ощущение, что каждая компания понимает под дата-контрактом что-то свое. Что это такое для ВТБ, что он включает?

Р.Д.: Это действительно так: на рынке под дата-контрактом часто понимают очень разные вещи — от схемы данных в API до внутренних регламентов взаимодействия. Для ВТБ дата-контракт — это, прежде всего, комплексная модель договоренности о данных как о промышленном продукте.

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

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

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

- Насколько эти изменения важны для банка?

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

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

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

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

Для банка это означает более высокую устойчивость, предсказуемость и масштабируемость всей data-инфраструктуры.

- Каковы масштабы?

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

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

Если говорить о цифрах, то это более 300 систем-источников, более 2 тыс. сотрудников, вовлеченных в процессы управления данными, более 2 тыс. дата-контрактов, более 5 тыс. автоматизированных технических и бизнес-контролей, а также специализированный стрим качества данных численностью более 100 человек.

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

- Какие меры предпринимались для вовлечения бизнеса в процессы управления данными?

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

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

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

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

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

- Что вызывало больше всего проблем?

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

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

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

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

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

- Какие результаты достигнуты и ожидаются?

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

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

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

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

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

В-пятых, через KPI и организационные роли была закреплена персональная ответственность за качество данных и соблюдение правил поставки.

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

- После проведенных работ бизнес еще не полностью доверяет данным? Чего ему не хватает для этого?

Р.Д.: Доверие к данным — это не состояние, которое можно однажды «включить» и считать вопрос закрытым. Особенно в большой организации, в которой одновременно меняются системы, процессы, продукты и модели принятия решений. Поэтому мы рассматриваем доверие не как разовую цель, а как постоянно укрепляемый результат.

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

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

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

- Как вы видите роль проекта для бизнеса банка?

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

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

- Каково значение проекта для отрасли?

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

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

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

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

- Что дальше, что еще предстоит сделать?

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

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

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

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

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

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

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

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