Каталог данных - это не панацея
🗂 Каталог данных - это не панацея. Это инфраструктура.
Или иными словами любая информационная система без выстраивания процесса, останется просто еще одной ИС в каталоге ИС.
В последнее время часто сталкиваюсь с кейсами, когда data catalog формально внедрён, но не выполняет своей функции - не потому что он плох, а потому что его пытаются внедрить в отрыве от процессов.
📌 Есть сбор метаданных - регулярный и автоматический. 📌 Есть бизнес-глоссарий - вроде бы даже с понятиями. 📌 Есть lineage - частично, но хоть что-то. 📌 Есть интерфейс - можно найти объект, если знаешь, как он называется. Но…
❌ Нет обязательного описания схем и полей. ❌ Нет связей с терминами из глоссария. ❌ Нет собственников объектов. ❌ Нет контроля на этапе изменения - можно создавать “втихаря”. ❌ Нет встроенности в рабочий цикл команды.
🎯 В итоге: каталог есть, но не помогает. Он не упрощает, не ускоряет, не связывает. Максимум, что можно - это посмотреть структуру таблицы, если повезёт её найти.
💬 На мой взгляд, любой каталог данных - это не отдельная система. Это точка интеграции процессов: - архитектуры, - разработки, - бизнес-анализа, - и управления качеством данных.
🧩 Если он не встроен в релизный цикл, если мета не является обязательной частью создания объектов - ничего не произойдёт. Он станет просто “папкой с файлами”, в которой когда-то кто-то что-то собирал.
🔑 А ещё: без минимального карт-бланша на изменения - внедрить ничего не получится. В крупных организациях всегда есть “разные башни”. И если одна из них строит инфраструктуру, не вовлекая остальные - инфраструктура останется пустой.
#DataGovernance #DataCatalog #Metadata #DataEngineering #ProcessDesign #DataStrategy …
· 07.01
«Каталог легко создать, каталог не легко поддерживать»
В этом весь парадокс. Проблема не в том, что его «внедряют без процессов». Проблема в том, что его вообще НЕ внедряют. Установить софт — это не внедрение. Внедрение — это когда процесс работы команды меняется так, что игнорировать каталог становится дороже и сложнее, чем вести его. Пока это не так — он обречён быть «папкой, в которой когда-то кто-то что-то собирал».
ответить
коммент удалён
· 08.01
Да, полностью согласен. Типовой сценарий:
Отделу Х поручают внедрить data catalog и они делают всё правильно - строят единую точку входа для создания объектов в хранилище через фреймворк или DSL, с валидациями, обязательными атрибутами, связями с глоссарием, владельцами и т.д. То есть каталог реально встраивается (должен был бы встроиться) в инженерный процесс. Но есть внутренний заказчик (условный отдел А), которому каталог нужен ради конкретной функции - например lineage. И есть другой отдел (условный Б), у которого горят сроки и которому «разбираться с новым DSL» вообще не в приоритете. В итоге после общения всех со всеми принимается волевое решение о частичном пуске. Кому-то нужно работать по новому процессу, а кому-то пока можно «сбоку». И этот список исключений со временем только растёт.
Формально объекты отдела Б в каталог попадут - автоматика все соберёт, как и старые обьекты. Но без человеческих описаний, без владельцев, без нормальных связей с терминами - то есть без тех вещей, которые должны задаваться при создании. Часто даже есть договорённость «потом дозаполнить», но у отдела Б всегда горят сроки, и до метаданных руки так и не доходят. И на выходе получается, что у отдела Х каталог вроде бы есть и даже работает, но по половине инфраструктуры пользователь не может найти ответ на свой вопрос. А не нашёл ответ - не стал пользоваться. Не стал пользоваться - каталог перестаёт быть инструментом. Через пару лет после запуска он превращается в портал, о котором знает небольшой процент людей... и не все уже помнят зачем он. Остальные же искренне не понимают, зачем им создавать объекты через «неудобный DSL», если без быстрее. Так компромисс и приводит к тому, что все вроде поработали хорошо (так что выгорели в дебатах и ручных действиях и поувольнялись), усложнили процессы компании и создали ту самую «папку».
ответить
ответ удалён