Каталог - швейцарский нож. … Или сказание о Франкенштейне

Наткнулся по ходу работы на классическую дилемму, с которой сталкиваются многие архитекторы или энтузиасты ИТ: а не использовать ли Каталог Данных не по прямому назначению, а как платформу для управления всей ИТ-инфраструктурой. Эдакий Франкенштейн из сервисов для пользователя.
Back in to Monolith 2.0

Хотелось бы вместе с вами порассуждать от рациональности такого подхода. Приглашаю проследовать за моими мыслями и дать свой непредвзятый совет в комментах под этим постом ;)

Каталог Данных (КД) заслуженно считается одним из ключевых элементов современной архитектуры управления данными. Это и поиск и профилирование и отслеживание происхождения.. Его главная сила 💪🏻— метаданные. Именно эта сила порождает соблазн использовать его как основу для построения других систем: Service Desk, CMDB, управления доступом, ролевками..

Однако рациональность такого подхода неоднозначна и требует взвешенного анализа. Вот примеры подобных скрещиваний:

1. Каталог Данных как основа для Service Desk
Тут видна разная природа процессов: Service Desk (в рамках ITIL/ITSM) — в первую очередь, система управления инцидентами, запросами и изменениями. Это workflow для решения проблем пользователей.
В ней разные объекты управления— тикеты, пользователи, сервисы, SLA. Объекты в КД — это таблицы, пайплайны, датасеты, метрики.
Попытка запихнуть систему тикетов в КД приведет к созданию костылей. Современные Service Desk (например Jira, simple one) заточены под работу с запросами, имеют готовые порталы самообслуживания, интеграции с мессенджерами и почтой. Повторить это в КД будет крайне затратно. Да и зачем?
Рациональнее наладить интеграцию между КД и Service Desk.

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

3. Автоматизация ролевых моделей и управления доступом.
Тут зерно рациональности присутствует (это одна из тенденций).
Современные КД развивают функционал Data Governance, где одним из моделей является управление доступом.
КД, являясь системой, которая знает:
· Какие данные у нас есть (каталог)
· Кто их владелец (stewardship )
· Какой у них уровень чувствительности (классификация) ... является удобной платформой для автоматизации запросов на доступ.
Пользователь находит Дата-продукт или витрину, нажимает "Запросить доступ", система автоматически создает тикет в Service Desk или напрямую в целевую систему , указывая владельца, обоснование и уровень доступа.

Причем это не "превращение" КД в другую систему, а естественное расширение функций.

4. Каталог Данных как НСИ (Нормативный Справочник Информации) для реестров

Для хранения реестров данных - рациональный подход. КД по определению является главным реестром всех данных организации. Он должен содержать в себе метаданные о всех бизнес-терминах, их атрибутах, владельцах и источниках.
Для реестров инфраструктуры (например, реестр серверов, помещений, оргструктуры) использование КД сомнительно. Для этих задач лучше подходят специализированные системы (CMDB, ERP, HR-системы). Однако КД может и должен потреблять эти справочники из мастер источников для обогащения своих метаданных (например, чтобы показывать не только название базы данных, но и ответственного за сервер инженера из CMDB).

Кажется что КД — подходящая НСИ для метаданных и бизнес-глоссария. Для других типов реестров он должен быть потребителем, а не источником.

5. Инфраструктурный мониторинг

Рационально? не думаю.

Тут весьма разные парадигмы: Инфраструктурный мониторинг (Zabbix, Prometheus) работает с метриками в реальном времени (CPU load, memory usage, latency). И оперирует потоками чисел, которые агрегируются, на их основе строятся графики и срабатывают алерты.
Задача же КД хранить статическую или медленно меняющуюся информацию. Например, "что такое метрика cpu_idle", кто за нее отвечает, где находится дашборд"). Т.е. это каталогизация самого факта существования метрик и дашбордов.
Попытка использовать КД для мониторинга — как навигация по пробкам на бумажной карте Москвы.

---

Итоговый вердикт:

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

Свежий опрос от коллег на тему Data Governance!

Владелец Данных VS Владелец процесса

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

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

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

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

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

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


Заметки Data Steward | Евгений Толпышев | Подписаться

Любопытная статья , на подумать )

…Я его слепила из того что было.. 🎶. (с)

Или рассуждение на тему - что делать если задача построить Управление данными есть, а ресурсов - нет.

Ответ - и не такое можно слепить, имея навыки писать процедуры и excel.

Вот гипотетический сценарий, когда в качестве инструментов доступны: Excel, Confluence и самописные скрипты в рамках существующего хранилища.

Все можно реализовать, комбинируя функциональность каждого компонента.

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

Итого, вместо развертывания специализированной платформы, фреймворк строится на соглашениях и рутинных операциях.

Пример: процент заполненности поля или соответствие шаблону, вычисляются скриптами и могут быть выгружены обратно в Excel для визуализации. Confluence обеспечивает необходимый контекст, объясняя, почему то или иное правило является важным с бизнес-точки зрения.

В чем риски такого подхода?
Первый риск - операционная хрупкость. Процесс, зависящий от ручных манипуляций с Excel-файлами и запуска скриптов, крайне уязвим к человеческим ошибкам. Версионность конфигураций правил отслеживается плохо, что может привести к несогласованности проверок.

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

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

Четвертый риск касается безопасности и контроля доступа. Управление разрешениями на уровне Excel-файлов и страниц Confluence не обеспечивает того же уровня гранулярности и аудита, что и специализированные решения для управления данными. Есть опасность несанкционированного изменения критичных бизнес-правил.

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

Но для построения устойчивой, масштабируемой и надежной практики требуется инвестирование в соответствующие инструменты.

Решение из подручных средств является тактическим, но не стратегическим.

#инструменты_управления_данными
#сделай_сам

Показалась весьма занятным исследование на тему : а где сейчас деньги в IT?

Анализ рынка ПО и ИТ-услуг в мире и в России. Занимательные выводы про то, что будет расти и на сколько
#исследования

Решил сделать подборку презентации топовых компаний на предмет Data Governance.
Выжимка презентаций из нашего основного чата:

https://t.me/DataAdventurers

Подписывайтесь !;)

⤵️⤵️⤵️

Пришлось столкнуться с тем, что в наследство достался реестр бизнес-доменов, в котором были назначены владельцы данных. Реестр был трехлетней давности - это тот самый момент, когда устаревание данных произошло не в самой базе данных, а прямо в инструменте управления.

Штош… Пора актуализировать.
Какие шаги можно предпринять?

Прежде всего признать, что ответственность владельца данных не может быть определён исключительно на основе перечня доменов или таблиц. Это совокупность бизнес- процессов, охватывающих происхождение, качество, использование и соответствие данных регуляторным требованиям. Поэтому первым шагом должна стать инвентаризация всех сквозных бизнес - процессов и объектов данных, находящихся в зоне домена: это и таблицы в хранилище данных (DWH), и сущности в АБС.

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

Особое внимание не забудьте уделить метаданным. Владелец данных должен быть в состоянии объяснить, откуда берутся значения в его таблицах, как часто обновляются и с какой точностью отражают реальность. Часто это требуется чтобы привязаться к бизнес-контексту: например, если в DWH хранится агрегированный показатель «просрочка по портфелю», владелец должен понимать, какие источники участвуют в его расчёте, какие бизнес-правила заложены в логику расчета показателя.

Также необходимо погрузить владельца в тему качества данных. Это можно сделать через SLA на поставку данных, например СМЭФ.
Важно, чтобы такие обязательства были измеримы и подотчётны — иначе роль владельца данных рискует превратиться в декларативную функцию без реального влияния.

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

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

#владелец_данных


Заметки Data Steward | Евгений Толпышев | Подписаться