SSOT-архитектура: как построить единый источник истины в крупной организации
Single Source of Truth — не один продукт, а архитектурный принцип. Эта статья разбирает, как построить единый источник истины по ключевым доменам данных в банке, у оператора или в государственной организации, какие компоненты обязательны, какие политические препятствия типичны и как их преодолеть.
Обсудить задачуЭта архитектурная статья разбирает SSOT как архитектурный принцип — не один продукт, а подход к назначению ответственности и потокам обновлений между системами. С политическими препятствиями и фазовым roadmap.
В чём архитектурный вызов
В крупной организации каждый домен данных (клиенты, продукты, договоры, операции) живёт в нескольких системах одновременно. Каждая система считает себя источником истины, но не имеет полной картины. Расхождения между копиями накапливаются годами и становятся системной проблемой — отчёты не сходятся, регулятор задаёт вопросы, бизнес-решения принимаются на разных версиях. SSOT — это архитектурный подход, в котором по каждому полю данных назначается один источник истины, остальные системы — потребители.
Какие системы, потоки и команды вовлечены
- Доменные системы — АБС (банк), BSS (оператор), государственные реестры, ERP, CRM
- Слой разрешения личности и сущностей — клиент, договор, продукт, операция
- Хранилище мастер-данных (MDM) — единый профиль с привязкой источников по полям
- Шина событий — поток обновлений между источниками и потребителями
- Хранитель данных как роль — разрешение конфликтов, контроль качества
- Слой согласий и аудита — кто, когда, какие данные использовал
Типичные архитектурные ошибки
- Декларация SSOT без назначения ответственности по полям — каждое ведомство/блок продолжает считать себя источником
- Попытка построить единое хранилище всех данных — копия всех систем в одном месте, без операционной модели
- MDM без хранителя данных — система деградирует от мусора в первые месяцы
- Запуск SSOT в изоляции от потребителей — никто не пользуется, потому что данные считаются устаревшими
- Игнорирование политики между ведомствами/блоками — технология не решает спор о том, чьи данные правильные
- Отсутствие историзации — невозможно понять, что было правдой в прошлый момент
Возможные подходы
- Полный MDM — централизованное хранилище мастер-данных, потоки обновлений из источников. Зрелый подход для крупных организаций
- Distributed SSOT — каждый домен живёт в своём источнике, но публикует события в общий поток. Лёгкий подход с меньшей нагрузкой
- Federated SSOT — комбинация: критичные домены в MDM, остальные через distributed-модель
- Read replica SSOT — общая read-only копия для аналитики и каналов, источники остаются мастером
Как обойтись без замены ядра
SSOT строится вокруг существующих систем, не вместо них. Каждая система остаётся источником истины по своим полям, но публикует обновления в единый поток. При устаревании одной из систем её можно заменить без переделки SSOT-слоя — слой потребляет события из любого источника, реализующего общий контракт. Замена систем — отдельная программа, не предпосылка SSOT.
Риски, зависимости, ограничения
- Политическая работа между владельцами систем — главный риск, не технология. Без межведомственного/межблокового соглашения SSOT застревает
- Хранитель данных как обязательная роль с мандатом разрешать конфликты
- Качество данных в источниках — SSOT делает мусор видимым, но не очищает его автоматически
- Сложность миграции исторических данных — может занимать годы при больших объёмах
- Регуляторные требования к защите данных и согласиям — встраивать с первого дня
Как выглядит фазовый путь
- Месяцы 1-3: инвентаризация доменов, переговоры о источниках истины по полям, формирование роли хранителя
- Месяцы 4-9: слой разрешения личности и единый профиль для приоритетного домена (обычно клиент)
- Месяцы 10-15: потоки событий из источников в SSOT, потребление профиля каналами
- Месяцы 16-24: расширение на следующие домены (продукты, договоры, операции)
- После 24 месяцев — постепенная миграция исторических данных, расширение на минорные домены
Что ещё стоит изучить
Темы из этой же области, которые часто разбираем вместе с этой
CRM
Не коробочный CRM, а правильно выстроенный контур управления клиентами — от первого контакта до лояльности.
→РешениеBI
Аналитика — не красивые графики на стене. Это ответ на вопрос 'почему?' до того, как проблема станет убытком.
→РешениеКонтакт-центр
Контакт-центр — не телефонная станция, а точка, где клиент решает: остаться с вами или уйти. Вопрос в том, как он устроен внутри.
→РешениеОнбординг
Онбординг — первое впечатление клиента о вашей компании. Если оно занимает 5 дней и 12 бумажных форм, второго впечатления не будет.
→Об этом не просто пишу — могу прийти, разобрать вашу ситуацию и спроектировать решение под ваш контур.
Обсудить применение →Готовы обсудить вашу задачу?
Расскажите, что не работает или что нужно построить. Первый разговор — без обязательств.
Обычно отвечаю в течение нескольких часов