Системы управления данными: как не ухудшить уровень сервиса ИТ-службы

Насколько велик риск появления нового монолита, роста техдолга и срыва уровня ИТ-сервиса при внедрении систем управления мастер-данными и руководства данными

Чего на самом деле боится ИТ-служба

ИТ-директор отвечает не только за «внедрение платформы», но и за то, чтобы критичные для бизнеса системы продолжали работать: система управления взаимоотношениями с клиентами (CRM), система планирования ресурсов предприятия (ERP), витрины данных, системы отчетности, интеграционная шина.
Любая инициатива внедрения системы управления мастер-данными (УМД или MDM) и системы руководства данными (РД  или DG) воспринимается как попытка привнести в этот ландшафт еще один центр тяжести, через который рано или поздно начнут пытаться прогнать все — от клиентов и продуктов до справочников регуляторной отчетности.

Ключевые страхи ИТ-блока можно сформулировать так:

• Система УМД превратится в мега-монолит, без которого ничего не работает.
• Практика руководства данными — это бесконечные комитеты, документы и тикеты, которые повиснут на ИТ-службе.
• Промышленная система сделает нас технологически зависимыми от компании-поставщика, а самописную систему УМД мы уже не потянем по совокупной стоимости владения.

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

Когда система УМД становится монолитом

Систему УМД задумывают как «слой мастер-данных», но на практике УМД может превратиться в новый монолит по ряду причин:

• в УМД хранят не только мастер-данные, но и бизнес-логику, например: правила расчетов объемов продукции или тарифов;
• через УМД начинают прогонять синхронизацию «всего со всем», подменяя функционал шины данных или даже части корпоративного хранилища данных (КХД);
• каждое новое требование (регулятора, формирование отчета, построение интеграции) реализуется непосредственно в УМД, а не в соответствующих доменах архитектуры.

В результате УМД перестает быть управляемым реестром мастер-сущностей и превращается в «архитектуру внутри архитектуры» со своим программным интерфейсом (API), механизмами выгрузки-трансформации-загрузки (ETL), правилами проверки и специфическими интеграциями.
Любой инцидент в этом случае может привести к деградации множества систем, а какое-то изменение может стоить дорого и занимать месяцы — это прямой удар по уровню сервисного обслуживания и скорости внесения изменений.

Как не превратить УМД в новый монолит

Задача ИТ-директора — изначально задать рамки, в которых УМД становится компонентом архитектуры, а не «вторым ядром».

Несколько принципов, которые стоит закрепить в целевой архитектуре:

1. УМД — это реестр мастер-сущностей, а не контейнер всей бизнес-логики. Все расчеты, сложные тарифные правила и кросс-продуктовые сценарии живут в профильных системах и сервисах.
2. Интеграция с УМД должна строиться по стандартным шаблонам (шина данных, отправка событий, взаимодействие через программные интерфейсы), но не должна строиться по принципу «каждый с каждым» через точечные запросы в базах данных (БД) или файлы.
3. УМД не заменяет работу КХД, витрин данных и аналитических систем (BI): УМД обеспечивает качественные мастер-данные, а не берет на себя функции КХД.
4. Любое решение (например, реализовать еще одну логику в УМД) проходит через архитектурный комитет и рассматривается с точки зрения роста связи и сложности.

Такие архитектурные договоренности важнее, чем конкретный вендор или самописное решение.

Когда самописный УМД «съедает» ИТ-ресурсы

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

Пока бизнес-требования растут умеренно, такой подход работает, но на масштабе подводные камни становятся очевидными:

• нет описанного жизненного цикла мастер-данных (от создания до архивирования);
• правила качества и дублирования живут в коде (или даже в электронных таблицах формата Excel), а не в управляемой конфигурации;
• любое изменение регуляторных требований заставляет вручную изменять схемы БД, логику работы и процедуры выгрузки;
• поддержка концентрируется вокруг узкого круга людей, и со временем это становится критичной.

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

Промышленные системы УМД и РД как опора для архитектуры

Зрелые системы УМД и руководства данными как раз созданы для того, чтобы снять с ИТ-команд обязанность бесконечно «изобретать велосипед» — инструменты качества данных, управление бизнес-процессами, ведение версионирования, построение графа происхождения данных, механизмы интеграции.

С точки зрения ИТ-директора ценность здесь не в «красивом интерфейсе», а в следующих преимуществах:

• есть формализованная модель данных, которая визуально конфигурируется;
• правила качества и поиск дубликатов описываются декларативно, их можно версионировать, тестировать и согласовывать с бизнесом;
• интеграционные механизмы (программные интерфейсы, событийные модели, массовые выгрузки) встроены в продукт и поддерживаются поставщиком, а не живут в виде «зоопарка» скриптов;
• архитектура платформы предполагает отказоустойчивость, режим работы без сохранения состояния, поддержку Linux-установщиков российского стека, интеграцию со службой каталогов, режим единого входа и стандартные средства мониторинга.

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

Система руководство данными разгружает ИТ-службу

Система руководство данными часто воспринимается ИТ-службой как бюрократия: комитеты, политики по управлению данными, документы, которые потоком будут идти в почте, а ИТ все равно останется крайним.
В действительности система РД — это способ навести порядок в части ответственности за данные: определить владельцев доменов, специалистов по управлению данными, правила качества, приоритеты и критерии качества.

Для ИТ-директора РД дает несколько важных вещей:

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

РД-платформы позволяют автоматизировать часть этой работы: согласование и хранение политик, формирование графа происхождения данных (data lineage), связи между системами и атрибутами, чтобы не держать все это в головах отдельных людей или, например, в схемах различного формата.

УМД и РД помогают выполнять требования регуляторов

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

Наличие систем УМД и РД позволяет:

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

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

Что должен контролировать ИТ-директор

Чтобы внедрение систем УМД и РД не разрушило управление сервисом обслуживания, ИТ-директору важно следить за выполнением следующих требований:

1. Четкое позиционирование систем УМД и РД в целевой архитектуре: их зона ответственности, границы, интеграционные паттерны, допустимый объем бизнес-логики.
2. Архитектурные принципы: отсутствие жесткой синхронной зависимости пользовательских систем и критичных операций от ядра системы УМД там, где это не оправдано, т.е. приоритет на событийную и асинхронную интеграцию.
3. Управляемый жизненный цикл мастер-данных: понятные требования на создание и изменение записей, правила работы в случае недоступности УМД, сценарии деградации.
4. Встроенный мониторинг и аудит: ИТ-служба должна видеть, где «ломаются» данные и процессы, а не узнавать о проблеме из отчета регулятору или от бизнеса.
5. Формализованная практика руководства данными: владельцы доменов, специалисты по управлению данными, комитет по данным, который принимает решения по изменениям модели, а не перекладывает все на ИТ-службу.

Иначе системы УМД и РД рискуют стать очередным «черным ящиком», за который ИТ-служба отвечает, но не управляет.

Системам УМД и РД быть

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

Выбор у ИТ-директора не между «делать системы УМД и РД или нет», а между:

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

В последнем случае системы УМД и РД — это не очередной монолит, а способ навести порядок в существующей архитектуре и упростить ИТ-директору контроль над тем, как данные обеспечивают устойчивость и развитие бизнеса.

Источник: РБК