Помочь данным работать на бизнес

О том, как единая модель данных в организации способна уничтожить барьер между бизнесом и IT и стимулировать рост доходов, рассказала начальник управления архитектуры данных департамента IT-архитектуры ВТБ Крестина Андреева.

Выйти из полноэкранного режима

Развернуть на весь экран

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

В микросервисной архитектуре мы имеем дело уже не с большой и сложной системой, монолитом, которому нужно «уметь» все — он трансформировался во множество независимых компонентов. И вот перед нами реальность новой, гораздо более гибкой системы и возможность совершенно по-новому управлять IT-ландшафтом. Если бы не одно «но»: очень часто организации так и не могут отказаться от свойственной монолиту логики управления данными. И это способно свести все плюсы перехода к нулю. Для монолитных систем характерен подход «о данных подумаем завтра» (data last), и именно он тормозит развитие и рост, «столкнувшись» с микросервисами.

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

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

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

Но самое главное, не происходит демократизации данных: они слабо доступны бизнесу на всех организационных уровнях. При этом именно равный доступ к данным для бизнеса и IT — залог успеха цифровизации организации, а значит, и создания дополнительных источников прибыли. Ключ к созданию по-настоящему гибкой микросервисной архитектуры — в смене подхода управления данными с «подумаем о данных завтра» (data last) на data first.

Data first невозможен без того, чтобы бизнес и IT говорили на одном, общем для них языке. То есть требования к сервисам должны быть сформулированы в категориях данных, необходимых как для работы сервиса, так и для оценки его эффективности.

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

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