Data mesh: это про владение данными, а не про платформу
Разбираю концепцию data mesh без хайпа - почему это прежде всего организационная модель, а не технический стек.
Концепция data mesh появилась несколько лет назад и сейчас переживает пик интереса. Я вижу её в тендерных описаниях, в вакансиях и в стратегических документах компаний, которые никогда раньше ни о чём подобном не задумывались.
Проблема в том, что большинство обсуждений data mesh сводят его к технологическому выбору: какую платформу взять, как организовать хранение, какие инструменты каталогизации использовать. Это неверная точка входа. Data mesh - прежде всего организационная модель. И если не разобраться с организационной частью, никакая платформа не поможет.
В чём суть идеи
Традиционно данные в компании собираются в одном месте - в централизованном хранилище или озере данных - и обслуживаются специализированной командой. Эта модель хорошо работает до определённого масштаба. Потом центральная команда превращается в узкое горлышко: все домены хотят данные, а пропускная способность одной команды ограничена.
Data mesh предлагает другой принцип. Каждый домен - продажи, логистика, производство - владеет своими данными как продуктом. Он отвечает за их качество, доступность и документацию. Центральная команда предоставляет инфраструктуру и стандарты, но не занимается данными каждого домена вручную.
Ключевое слово - "данные как продукт". Это значит, что у данных есть владелец, который отвечает за их полезность для потребителей внутри компании.
Почему это не работает без организационных изменений
Я видел несколько попыток внедрить data mesh через технологическое решение. Компания покупает платформу, настраивает каталог, объявляет о переходе на децентрализованную модель. Через полгода всё возвращается к прежнему состоянию.
Причина всегда одна. Домены не хотят брать ответственность за данные. У них нет людей с нужными компетенциями. У них нет времени поддерживать что-то, что не входит в их прямые обязанности. Данные продолжают обновляться нерегулярно, документация остаётся устаревшей, потребители не доверяют качеству.
Без ответа на вопрос "кто конкретно отвечает за эти данные и что от него требуется" переход на data mesh - просто переименование проблемы.
Что нужно решить до выбора платформы
Прежде чем думать о технологии, стоит разобраться с несколькими организационными вопросами:
- Определены ли у вас домены и их границы? Не просто оргструктура, а зоны ответственности за данные.
- Есть ли в каждом домене человек или команда, способные владеть данными как продуктом?
- Как будут разрешаться конфликты между доменами - когда данные нужны сразу нескольким?
- Какова федеральная функция - кто устанавливает стандарты и следит за их соблюдением?
- Как вы измерите качество данных по каждому домену?
Если на эти вопросы нет ответа, добавление платформы только усложнит ситуацию.
Когда data mesh имеет смысл
Честный ответ: не для всех. Data mesh - решение для компаний с высокой децентрализацией, множеством доменов с разной скоростью развития и хронической перегруженностью центральной данных-команды.
Если у вас один продукт, одна команда и относительно понятный поток данных - централизованная модель с хорошей инженерией данных будет проще и эффективнее.
Data mesh - не шаг вперёд по умолчанию. Это архитектурный выбор с конкретными предпосылками. Начинать стоит с диагностики организации, а не с выбора инструмента.