Организация управления данными в микросервисной архитектуре на основе единой модели данных

Заказчик
ПАО Банк ВТБ
Год завершения проекта
2022
Сроки выполнения проекта
Декабрь, 2021 - Ноябрь, 2022
Масштаб проекта
36960 человеко-часов
Цели
  • Снижение затрат на поиск источников данных и интеграцию;
  • Снижение затрат на загрузку данных из источников в хранилище данных за счет формирования промежуточного семантического слоя;
  • Уменьшение влияния изменений в микросервисах на остальной ландшафт банка (интеграционный слой и хранилище данных) — фактическая изоляция интеграционных интерфейсов от физической структуры данных;
  • Упрощение ИТ-ландшафта банка за счет снижения количества интеграционных потоков и сервисов и их унификации в части структур и описаний данных;
  • Повышение прозрачности и децентрализация процесса управления архитектурой данных в микросервисной архитектуре.

Уникальность проекта

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

Реализованный проект отличают:
— Тесная интеграция корпоративной (единой) модели данных в производственный процесс;
— Унификация крупного ИТ-ландшафта (более 1000 микросервисов) — как с точки зрения структуры данных, так и семантики взаимодействия;
— Внедрение сквозного процесса управления архитектурой данных — от требований к системе и определения структур данных до заключения контрактов на данные.
Проект решает задачи импортозамещения
Да
Использованное ПО
Sparx Enterprise Architect, инструмент моделирования ПО собственной разработки на Python для автоматизации процесса валидации соответствия интерфейсов логическим моделям данных.
Сложность реализации
Управление данными в микросервисной архитектуре осложнено несколькими факторами —
  1. Привычные для монолитов и крупных систем объекты управления (сущности) отсутствуют, каждый микросервис отвечает за строго ограниченный набор данных. Данными одной сущности часто управляют много микросервисов, что затрудняет определение достоверных источников данных и их владельцев.
  2. Каждый владелец микросервиса определяет и описывает только свои данные, опираясь на свою локальную экспертизу и не учитывая окружающий ландшафт, что затрудняет идентификацию общих данных и множит одинаковые по сути, но разные по семантике интеграционные потоки между информационными системами.
  3. При организации сбора данных в единый дата-маркет большое количество трудозатрат уходит на очистку, нормализацию и приведение к единой семантике данных, получаемых из микросервисов.
Среди факторов высокой сложности реализации также —
  • Сжатые сроки, обусловленными коротким релизным циклом микросервисов;
  • Высокая зависимость от других процессов, в том числе изменения нормативной документации
  • Разнородность ИТ-ландшафта банка — в том числе, различные типы баз данных (реляционные, объектные, колоночные и др.) и необходимость учета особенностей и ограничений legacy-ландшафта
  • Широта охвата проекта — он затрагивает производственный процесс, все команды разработки, бизнес-подразделения и архитекторов.
Описание проекта
Фокус реализуемого сегодня ВТБ подхода к data management — управление едиными объектами во всех процессах банка. Чтобы сделать процесс эффективным, важно:
  • правильно определить границы, разделяющие концептуальные сущности и не оставить белых пятен
  • описать жизненный цикл каждой сущности в бизнес процессах банка
  • сформировать детальное представление о том, как сущность или ее части выглядит в каждой из систем на разных стадиях ее жизненного цикла, какие данные появляются на каждом этапе жизненного цикла, востребованность этих данных, в том числе для отчетности и т.д.

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

Ключевые задачи проекта включают:

1. Создание единых правил для:
  • определения сущностей и атрибутов, с которыми работает микросервис (границ, состава уникальных данных и т.д.);
  • обмена данными между микросервисами в ландшафте Банка.

  • 2. Создание библиотеки шаблонов описания сущностей (единой модели данных) и библиотеки логических моделей данных сервисов

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

    4. Организация процессов формирования контрактов на данные на основании логических моделей данных как для операционных процессов, так и для процессов сбора данных в дата маркет

    5. Децентрализация процесса управления данными — каждый микросервис все так же ответственен за свои данные, но формирование моделей данных выполняется по единым принципам.

    За 11 месяцев с момента запуска проекта удалось:
    1. Разработать методологию управления архитектурой данных в микросервисной архитектуре на основании правил идентификации уникальных объектов данных (общих и специфических), используемых в процессах банка и правил моделирования логики работы сервисов с использованием идентифицированных объектов…
    2. … и полный цикл проектирования архитектуры данных — от идентификации сущности и ее атрибутов до формирования контракта на данные и мониторинга исполнения данного контракта в процессе эксплуатации сервиса
    3. Внедрить процесс ведения единой модели данных, процесс формирования логических моделей данных на основе единой модели
    • Запустить загрузку в централизованный дата-маркет
    География проекта
    РФ
    Коментарии: 1

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

    • Максим Часовиков
      Рейтинг: 4767
      РАНХиГС
      Директор Проектов проектного офиса ректора
      06.01.2023 20:02

      Добрый день, вы пишите:

      • Снижение затрат на поиск источников данных и интеграцию;
      • Снижение затрат на загрузку данных из источников в хранилище данных за счет формирования промежуточного семантического слоя;
      • Уменьшение влияния изменений в микросервисах на остальной ландшафт банка (интеграционный слой и хранилище данных) — фактическая изоляция интеграционных интерфейсов от физической структуры данных;
      • Упрощение ИТ-ландшафта банка за счет снижения количества интеграционных потоков и сервисов и их унификации в части структур и описаний данных;


      На сколько удалось достичь этих заявленных целей?

    Год
    Предметная область
    Отрасль
    Управление
    Мы используем файлы cookie в аналитических целях и для того, чтобы обеспечить вам наилучшие впечатления от работы с нашим сайтом. Заходя на сайт, вы соглашаетесь с Политикой использования файлов cookie.