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

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

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

Оговорка. В этой статье я буду писать о сервисе MDM (Master Data Management), под которым подразумеваю весь набор процессов управления мастер‑данными. Тратить внимание читателей на терминологию предметной области не буду — об этом написано немало статей, в том числе и на Хабре. Под «справочником» далее в статье я понимаю ссылочные данные (Reference data).

Поехали!

Знайте и фиксируйте, какую проблему решаете 

Это первая и особенная практика. У неё самое важное влияние: знание эффектов от сервиса MDM позволяет находить и обосновывать финансирование его развития и эксплуатации.

Практика применима не только к управлению мастер‑данными, но и к любому платформенному сервису. Сервис MDM не приносит денег вашему бизнесу напрямую (за редким исключением), но тратит их. Чтобы получить ресурсы для существования и развития сервиса MDM, нужно обосновать его важность: продемонстрировать, как и чем он помогает бизнесу.

Каждый раз, когда возникает потребность создания/доработки MDM, должно фиксироваться влияние этой доработки на бизнес: цели, которые доработка позволяет достигать; риски, которые она снимает.

Интегрируйте потребителей с мастер-системой 

В Data Lineage между сервисом MDM и конечным потребителем мастер‑данных не должно быть никаких систем, кроме транспортных (шины, ETL, сервиса мастер‑данных). Такой подход позволяет добиться прозрачности происхождения мастер‑данных и высокой скорости распространения изменений. Потребители получают мастер‑данные через одинаковое количество интеграций, поэтому риск расхождения версии у двух взаимодействующих систем потребителей в один момент времени снижается.

Сложный Data Lineage влияет на:

• скорость распространения изменений,

• трудоёмкость развития модели мастер‑данных,

• трудоёмкость сопровождения сервиса MDM,

• риски расхождения версии мастер данных в связанных системах.

Стремитесь к разумному упрощению архитектуры

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

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

Сложная архитектура влияет на:

• трудоёмкость развития сервиса MDM,

• трудоёмкость сопровождения сервиса MDM,

• риски расхождения логики в множественных реализациях.

Не связывайтесь с транзакционными данными 

Часто возникает искушение работать с какой‑то информацией как с мастер‑данными (с помощью сервиса MDM), чтобы повторно использовать уже реализованные процессы. Как правило, в сервис MDM пытаются добавить транзакционные или конфигурационные данные.

Транзакционные данные имеют высокую частоту изменения. Мастер‑данные всегда характеризуются меньшей частотой изменений, и сервис MDM строится с учётом этого свойства. Появление в сервисе часто изменяемых данных вызывает деградацию его производительности. Хорошим дифференцирующим свойством транзакционных данных является наличие в одной записи двух или более объектов мастер‑данных.

Управление транзакционными данными в сервисе MDM влияет на:

• трудоёмкость развития сервиса MDM,

• трудоёмкость сопровождения сервиса MDM,

• объем необходимых сервису MDM вычислительных ресурсов.

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

Управление конфигурационными данными в сервисе MDM влияет на:

• скорость развития конфигурируемого процесса,

• скорость изменения конфигурации,

• трудоёмкость сопровождения конфигурируемого процесса,

• трудоёмкость сопровождения сервиса MDM.

Используйте глобальные идентификаторы 

Чем меньше разнообразных уникальных идентификаторов имеет объект мастер данных, тем проще (дешевле, быстрее) работа сервиса MDM. Если объект имеет уникальный идентификатор организационного уровня выше (управляемый на уровне холдинга, государства, международной организации), то следует использовать только его и воздержаться от создания новых. Здесь есть исключение — с идентификатором могут быть связаны ограничения регулятора, и он может быть неудобен.

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

Практика создания дополнительных уникальных идентификаторов влияет на:

• трудоёмкость сопровождения сервиса MDM,

• трудоёмкость развития бизнес‑процессов, использующих такие мастер данные,

• риск появления потребности в дополнительных сервисах сопоставления.

Стремитесь использовать глобальные справочники 

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

Никогда не делайте обрезку подобных справочников, даже если вам необходимы 2–3 значения из 1000. Если усечение необходимо ради пользовательского удобства, делайте это на уровне интерфейса. Пользовательский интерфейс дорабатывает команда, напрямую связанная с заказчиком: внести в него изменения всегда проще и быстрее, чем произвести изменения справочника с оценкой влияния на всех потребителей (у ссылочных данных потребителей больше, и влияние изменений сильнее, чем у мастер‑ данных).

Создание с нуля справочников для типовых ссылочных данных влияет на:

• трудоёмкость развития сервиса MDM,

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

• риски появления потребности в дополнительных сервисах сопоставления. 

Не удаляйте записи из справочников 

Здесь я имею в виду ссылочные данные, про мастер‑данные будет следующий раздел.

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

Удаление записей справочников влияет на риски появления неконсистентных данных. 

Реализуйте процесс чистки мастер-данных 

Со временем в сервисе MDM накапливаются записи мастер‑данных, которые больше не нужны для автоматизации бизнес‑процессов и не фигурируют в данных вне исторического хранилища. Объём такой информации может существенно влиять на работу потребителей сервиса MDM: увеличение объёмов хранимой и передаваемой информации, ухудшение пользовательского опыта, замедление работы систем, достижение технологических лимитов. Этот объём будет влиять и на сам сервис, когда потребуется выполнить массовое изменение в мастер‑данных (например изменение иерархической классификации или бизнес‑правил, привязанных к классификатору).

Накопление объёма неиспользуемых мастер данных влияет на:

• ресурсоёмкость использующих мастер данные систем,

• риски ухудшения пользовательского опыта,

• риски достижения технологических лимитов,

• трудоёмкость сопровождения сервиса MDM,

• ресурсоёмкость сервиса MDM.

Используйте в транзакциях идентификаторы ссылочных и мастер-данных вместо явных значений

Рекомендация актуальна для данных, которые могут быть переданы в другое приложением — в другом приложении могут быть другие строки.

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

Мастер‑данные изменяемы, использование идентификаторов упрощает процесс внесения изменений в мастер‑данные (дополнительно смотрите следующий пункт про сохранение истории). При использовании идентификаторов мастер‑данных вы сможете собрать LFL‑отчёты, даже если в историческом горизонте менялся принятый стандарт именования.

Использование текста в записях данных вместо идентификаторов из справочника влияет на:

• риски высоких трудозатрат на трансляцию строк,

• трудоёмкость сопровождения сервиса MDM (внесение изменений в значения).

Сохраняйте историю для мастер-данных 

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

Отсутствие истории мастер‑данных влияет на:

• риски появления не консистентных исторических данных,

• риски невозможности анализа исторических данных.

Не храните мастер-данные в системе-потребителе 

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

Хранение копии мастер‑данных добавляет ряд задач:

• контроль целостности,

• контроль актуальности,

• мониторинг интеграции.

На стороне потребителя увеличивается объём хранимой информации.

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

Хранение мастер‑данных у потребителя влияет на:

• трудоёмкость сопровождения интеграции информационных систем,

• трудоёмкость сопровождения сервиса MDM,

• трудоёмкость развития сервиса MDM,

• риски расхождения версии мастер‑данных в связанных системах.

Используйте широковещательную рассылку изменений

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

Использование адресных рассылок изменений мастер‑данных влияет на:

• ресурсоёмкость сервиса MDM,

• трудоемкость сопровождения сервиса MDM,

• трудоёмкость развития систем потребителей.

Дайте потребителям интерфейс для инициализации своих мастер-данных

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

Отсутствие автоматической возможности инициализации потребителя влияет на:

• трудоёмкость сопровождения потребителя при восстановлении после сбоя,

• трудоёмкость сопровождения потребителя при запуске нового экземпляра,

• трудоёмкость контроля актуальности мастер данных потребителя.

Заключение

Увы, но магии не существует. Главное в применении «лучших практик» — не следовать им слепо. Архитектурное решение — всегда поиск компромисса (если нет архитектурной развилки, то решение не архитектурное, а инженерное)

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