Sberbank Enterprise
Architecture Framework
Как управлять
информационной
архитектурой
в компании
Информационной
Архитектурой
в компании
Сергей
Чернов
Дмитрий
Христенко
Николай
Брезгинов
Евгения
Миненко
• Опыт в ИТ – 24 года
• Опыт в телеком + IT более
15 лет (интеграция,
разработка, консалтинг).
• Архитектор данных (СберФакторинг),
разработчик SBF.DM
Ведущий специалист
по дизайну
• Развитие процессов Data Governance –
более 5 лет
• Кандидат технических наук
• Развитие процессов Data
Governance – более 2 лет
• Работа с данными – более
6 лет (аналитика, разработка,
консалтинг)
• Data Management /
Data Governance - 3 года
• Разработка ПО - 7 лет
• Работа с данными - более 10 лет
ЧТО ДАЕТ КОМПАНИИ ВНЕДРЕНИЕ ПРОЦЕССА
УПРАВЛЕНИЯ ИНФОРМАЦИОННОЙ АРХИТЕКТУРОЙ
Повышение
производительности
труда архитекторов,
разработчиков и аналитиков за
счет использования
согласованной достоверной
информации о данных
Снижение трудозатрат
на разработку за счет
исключения дублирования
структур данных
Снижение вероятности
наступления рисков данных
за счет наличия
информации о местах
хранения данных, их
использовании, а также
категории и критичности
ПРЕДПОСЫЛКИ УПРАВЛЕНИЯ ИНФОРМАЦИОННОЙ АРХИТЕКТУРОЙ (ИА)
DG – данные
это актив
1
2
ИА –
структурированное
описание активов
и планирование
изменений
Управление
ИА можно
реализовывать
по-разному
3
4
SEAF – единая
методология описания
архитектуры компании,
включая вертикаль ИА
SEAF - ЕДИНАЯ АРХИТЕКТУРА КОМПАНИИ
01
02
Открытый и развиваемый сообществом
экспертов-практиков архитектурный
фреймворк
В своей основе использующий
подход «Архитектура-как-код»
03
04
Обеспечивает взаимосвязи
всех слоев архитектуры
(горизонтально и вертикально)
Является единой точкой управления
архитектурными изменениями
ВНУТРЕННИЕ СВЯЗИ ИНФОРМАЦИОННОЙ АРХИТЕКТУРЫ
Пользователи
Бизнесаналитики
Системные
аналитики
Инженеры /
разработчики
Реестры
(списки)
Реестр отчетов
Реестр витрин
Реестр Автомати-зированных
систем
Модели
(сущности, связи)
Концептуальная
модель данных
Логическая
модель данных
Физическая
модель данных
Словарь
(единый перечень)
Бизнес глоссарий
МЕСТО ИНФОРМАЦИОННОЙ АРХИТЕКТУРЫ В КОРПОРАТИВНОЙ
АРХИТЕКТУРЫ КОМПАНИИ
БАЗОВЫЙ ПОДХОД К ФОРМИРОВАНИЮ СЛОЕВ И ВЕРТИКАЛЕЙ:
Слои выделяют функциональные области, а Вертикали пронизывают их и связывают
ВЕРТИКАЛЬ ИНФОРМАЦИОННОЙ
АРХИТЕКТУРЫ
СЛОИ КОРПОРАТИВНОЙ АРХИТЕКТУРЫ
Бизнес-глоссарий
✦ Бизнес-термин
Бизнес Архитектура
✦ Термины участвуют в бизнес процессах
Логическая модель
✦ Логическая сущность
✦ Логический атрибут
✦ Связь между двумя
логическими сущностями
Прикладная Архитектура
(уровень Сервисов)
✦ Логические сущности принадлежат мастер-системе (АС)
(уровень Интеграций)
✦ Логические сущности участвуют в интеграционных потоках
Физическая модель
✦ Физическая таблица
✦ Физический атрибут
Прикладная Архитектура
(уровень Сервисов)
✦ Физическая таблицы принадлежат конкретной БД (АС)
ПОДДЕРЖКА СОГЛАШЕНИЯ О МОДЕЛИРОВАНИИ
Иерархия объектов:
✦ Предметная область (ПО)
✦ Поддомен(ы)
Проект миграции
ПО – отдельное свойство модели
Для каждого ПО всегда
есть хотя бы один поддомен
ПО
✦ Модель поддомена
✦ Сущности и связи
между ними
Наименование модели = поддомену
При наличии пакетов, наименование
пакета = поддомену
Поддомены
КМД
для ПО всегда как минимум
определен один поддомен,
равный ПО
Сущности
Автор модели, включающей
один или несколько
поддоменов
Связи
ОПИСАНИЕ СЛОЕВ И СУЩНОСТЕЙ ИНФОРМАЦИОННОЙ АРХИТЕКТУРЫ
Агрегат (слой) обеспечивает разбиение ЛМД на различные области
✦ Агрегат (сущность)
Бизнес-глоссарий (слой)
перечень бизнес-терминов,
используемых в процессах
и продуктах компании,
обеспечивающий
их единообразное понимание
✦ Бизнес-термин (сущность)
понятие, которым оперируют
бизнес-процессы компании
Логическая модель данных (слой)
множество сущностей, атрибутов и
связей между ними, определяющее
используемые в компании данные
Физическая модель данных (слой)
описание технической реализации,
основанное на ЛМД, включающее
в себя структуры хранения данных
✦ Логическая сущность (сущность)
центральная сущность ИА
✦ Физическая таблица (сущность)
описывает конкретное
представление данных в БД
✦ Логический атрибут (сущность)
дочерний объект для расширения
свойств Логической Сущности
✦ Логическая связь (сущность)
обеспечивает связь между двумя
Логическими сущностями
✦ Физический атрибут (сущность)
дочерний объектом
Физической таблицы.
Описывает конкретный столбец
(колонку) в физической таблице
ОБЪЕКТЫ УПРАВЛЕНИЯ ИНФОРМАЦИОННОЙ АРХИТЕКТУРЫ (1
Бизнесглоссарий
При имплементации
в компании всегда реализуются
все слои Информационной
Архитектуры
Если какие-либо слои
отсутствуют, то они выступают
как прокси
и формируются однозначным
соответствием
из имеющихся слоев
Это необходимо
для полной связанности
с архитектурой компании
и соответствия КА ДЗО
Бизнес-термин
Логическая
модель
Логические
связи
Физические
таблицы
Логическая
сущность
Логические
атрибуты
Физические
атрибуты
Физическая
модель
ОБЪЕКТЫ УПРАВЛЕНИЯ ИНФОРМАЦИОННОЙ АРХИТЕКТУРЫ (2
Агрегат
ПО, Поддомен, Модель – различные
объекты типа «Агрегат»
Предметная
Область
Поддомен
Объект Агрегат является также является
атрибутом Агрегата
Таким образом реализуется любой
уровень вложенности и строится
иерархия вложенных Агрегатов
Модель
поддомена
Модель
поддомена
Логическая модель
LE
✦ Логическая сущность
Объект Агрегат типа
«Модель» является атрибутом
Логической сущности
LE
LE
LE
LE
LE
LE
ПРИМЕР РЕАЛИЗАЦИИ
Бизнестермины
Рейтинг
Фильм
Актер
1:N ассоциация 0:N
Логические
сущности
Актер
Рейтинг
Фильм
1:N ассоциация 0:N
Актриса
0:N ассоциация 0:N
Raiting
Физические
таблицы
Film
film_actor
film_id
actor_id
language_id
film_id
Actor
actor_id
ИМПЛЕМЕНТАЦИЯ МЕТОДОЛОГИИ
В СБЕРФАКТОРИНГ
Архитектура данных
ü Разработка корпоративной модели данных
❍ Выбор инструментов для создания логической и физической моделей данных
❍ Разработка ВНД
Мастер-данные и нормативно-справочная информация (НСИ)
❏Определение и фиксация мастер-данных
❏Создание справочников и назначение владельцев
❏Выбор инструментов для автоматизации
Качество данных
❏Определение требований к качеству данных
❏Определение и создание набора проверок качества данных
Поможет одинаково определять
бизнес-сущности в процессах
Поможет исключить расхождения
данных
в источниках и отчетах
Поможет снизить количество
ошибок в отчетах
Метаданные
ü Разработка регламента управления метаданными
❍ Выбор инструментов для оптимизации существующих механизмов сбора метаданных
❍ Разработка хранилища/реестра метаданных
ü Выполнено
❍ В процессе
❏Планируется
Поможет сократить время поиска
данных
СберФакторинг – с нуля до SB.FDM
2022 кв2
Реестр отчетов
2023 кв3
• Хранилище метаданных
• Регламент НСИ
2023 кв4
• Внедрения хранилища
метаданных
• Описание Справочников
(добавление признака
в Реестр Данных)
2022 кв3
Реестр данных
(Физическая модель данных –
Физические таблицы)
2023 кв2
• Регламент управления
метаданными
• Ручная Логическая
модель данных
2024 кв1
• Графическая реализация
ЛМД в instance DocHub
• Связь ЛМ и ФМ
2022 кв4
Автоматическое обновление Реестра
данных
2023 кв1
• Регламент Архитектуры
данных
• Детализация Реестра
данных до уровня полей
(Физический Атрибут)
2024 кв2
• Решение SBF.DM (SuperSet + DocHub)
• Передача Метаданных в модель ИА SEAF
АПРОБАЦИЯ МЕТАМОДЕЛИ ИНФОРМАЦИОННОЙ АРХИТЕКТУРЫ ВМЕСТЕ
СО СБЕРФАКТОРИНГ
Сокращения
✦ ECS - Elastic Cloud Server
✦ EIP - External IP
✦ VPC - Virtual Private Cloud
✦ BI - Business Intelligence
✦ SBF.DM - Sberfactoring
Data Management
Router
Cloud.ru
платформа Advanced
VPC
EIP
ECS1
ECS2
EIP
port: xxx
port: 49003
port: 49001
метамодель
ИА
DocHub
SuperSet BI
SEAF
core
PostgreSQL
Backend python
Airflow
(КА ДЗО)
Internet
DocHub
PostgreSQL
СУБД источник данных для решения
SBF
DM
ПЕРЕДАВАЕМЫЕ НА СТЕНДЕ ОБЪЕКТЫ
Сущности ИА
Атрибутный состав
Сущности SBF.DM
Бизнес-термин
Полный
Бизнес-термин
Агрегат
Частичный
Предметная область
Логическая сущность
Частичный
Логическая сущность
Логический атрибут
Частичный
Логический атрибут
Логическая связь
Полный
Логическая связь
Физическая таблица
Частичный
Физическая таблица
Физический атрибут
Частичный
Физический атрибут
ЧТО МЫ ПРЕДЛАГАЕМ
ЧТО МЫ НЕ ПРЕДЛАГАЕМ
Метамодель для описания
Информационной Архитектуры
Автоматизированную
систему
Регламент управления
Информационной Архитектурой
(включая ролевую модель)
ПО по сбору метаданных
ИНФОРМАЦИОННАЯ АРХИТЕКТУРА
КАК КОД. РЕАЛИЗАЦИЯ В DOCHUB
01
02
DocHub – инструмент описания
архитектуры, реализующий
принцип «архитектура-как-код»
Архитектура описывается в
yaml-файлах:
Для реализации архитектурных
компонентов необходимо описать:
✦ Возможно установка
и использование как плагина
в IDE или отдельного instance
✦ Сущности (entities)
✦ Объекты ИА в формате
определенных в ИА сущностей
(entities) в yaml/json файлах
Далее для примера будем
рассматривать плагин DocHub
в VS Code
✦ Представления сущностей
для визуального
отображения
(presentation)
03
Для удобства заполнения
используется репозиторий seaf-dzoexample
Плагин DocHub
Структура seaf-core
yaml сущности
Меню DocHub
yaml представлений
КАК УСТАНОВИТЬ ИНСТРУМЕНТАРИЙ
Аккаунт SEAF на GitHub
https://github.com/SEAFTeam/
Репозиторий seaf-core
Метамодели Корпоративной Архитектуры:
✦ docs - документация
✦ functions - функции
✦ entities – сущности
1
В IDE (например VScode) устанавливаем
plugin DocHub
2
Скачиваем в пустую папку репозитории:
включая отображения
presentations и templates
2
В корне папки создаем файл
dochub.yaml *:
imports:
Репозиторий seaf-dzo-example
Файлы с примерами объектов
для метамодели seaf-core
В формате yaml или json
✦ seaf-core
✦ seaf-dzo-example
✦ seaf-core/dochub.yaml
✦ seaf-dzo-example/dochub.yaml
* здесь “seaf-core” и “seaf-dzo-example” названия папок
куда установили пакеты на шаге 2)
SEAF-DZO-EXAMPLE
(ДЛЯ ПОЛЬЗОВАТЕЛЯ)
Один файл для каждого типа
сущности метамодели ИА:
✦ Бизнес-термин
✦ Агрегат
✦ Логическая сущность
✦ Логический атрибут
✦ Логическая связь
✦ Физическая таблица
✦ Физический атрибут
Представлены описания объектов
Бизнес-термин
в формате json
ПРЕДСТАВЛЕНИЯ МЕТАМОДЕЛИ ИНФОРМАЦИОННОЙ
АРХИТЕКТУРЫ
Таблица – базовое отображение в меню
Диаграмма (для отображения логических связей)
Карточка объекта
БИЗНЕС-ТЕРМИН
(БИЗНЕС-ОБЪЕКТ)
Понятие, которым оперируют
бизнес-процессы компании
Обеспечивает связь с Бизнес Архитектурой (БА),
посредством включения бизнес-терминов в
бизнес-процессах
Варианты включения бизнес-термина
в бизнес-процесс
Бизнес-процесс
Описания взаимодействия
процесса и термина (ресурсов)
Поддерживает
(supported)
Ресурсы - используются, но не
трансформируются, реализуют выполнение
чего?-> Процесса
Потребляется
(consumes)
Ресурсы - потребляются, расходуются при
выполнении чего?-> Процесса
Производит (produces)
отношение Процесс - имеет на выход что? ->
Ресурсы
АГРЕГАТ
Тип объекта Агрегат может принимать
следующие значения, согласно мета атрибуту
«Уровень агрегации»:
✦ Под-домен
✦ Проект
✦ Модель
✦ Пакет
✦ Файл
✦ Предметная область
✦ Домен
Сущность Агрегат позволяет ссылаться сама на
себя, поскольку Агрегат является мета
атрибутом объекта Агрегата
(мета атрибут «Содержимое»)
Таким образом реализуется любой уровень
вложенности и строится иерархия вложенных
агрегатов.
ЛОГИЧЕСКАЯ СУЩНОСТЬ
(ДАТА-ОБЪЕКТ)
Логическая сущность является центральной
сущностью ИА и обеспечивает:
✦ связь с Прикладной Архитектурой (ПА) на уровне Сервисов,
посредством принадлежности Логической сущности к мастер-системе
(мета атрибут «Мастер система»)
✦ связь с Прикладной Архитектурой (ПА) на уровне Интеграций между
компонентами/автоматизированными системами (АС), посредством
указания Логических сущностей в интеграционных потоках
✦ распределение всей ИА компании на области, посредством включения
в Агрегаты (мета атрибут «Агрегат»)
✦ связь с Бизнес-глоссарием ИА, посредством ссылок на бизнес-термины
(мета атрибут «Бизнес-термины»)
✦ связь с ФМД ИА, через ссылки из объектов Физических таблиц
Мета атрибут «Категория» заполняется значением из списка:
✦ Перс данные
✦ Медицинские данные
✦ Платежные данные (карты)
✦ Коммерческая тайна
✦ Прочее
ЛОГИЧЕСКИЙ АТРИБУТ
Логический атрибут является дочерним
объектом по отношению к объекту Логической
Сущности
Служит для расширения свойств Логической
сущности
при моделировании ЛМД
При создании объекта Логический атрибут, в
мета атрибуте «Логическая сущность»,
обязательно указывается ссылка на
родительский объект Логическая сущность
Логический атрибут имеет однозначную
прямую связь с бизнес уровнем ИА,
через мета атрибут «Бизнес-термин»,
посредством ссылки на конкретный бизнестермин
ЛОГИЧЕСКАЯ СВЯЗЬ
Логическая связь обеспечивает связь
между двумя Логическими сущностями
Для создания объекта Логическая связь всегда
необходимы два различных объекта Логическая сущность,
для каждой из которых должен быть определен мета
атрибут «Множественность
«Множественность А» определяет сколько
объектов А, могут быть связаны с одним объектом В.
Записывается в виде N:M, где:
✦ N – (целое число >= 0) минимальное возможное
количество связанных объектов А, для одного объекта В.
"N" всегда принимает конкретное целочисленное
значение
✦ М – (целое число >= N) максимальное возможное
количество связанных объектов А, для одного объекта В.
"M" может принимать конкретное целочисленное
значение или оставаться переменной
ЛОГИЧЕСКАЯ СВЯЗЬ (ПРИМЕР)
Объект Логическая связь AddressClient. Реализует связь между Логическими сущностями: (А) Адрес, (В) клиент.
«Множественность А» показывает сколько Адресов может быть у одного Клиента.
(А) Адрес ¬(В) клиент.
Варианты значений атрибута «Множественность А»:
Значение
Пояснение
0:1
У Клиента может быть только один Адрес или не быть вообще (отсутствовать)
2:2
У Клиента обязательно должно быть привязано два Адреса.
0:M
У Клиента может не быть Адреса, но больше M Адресов одному Клиенту привязывать нельзя
1:3
Клиент может иметь от одного до трех связанных Адресов. Например, домашний, рабочий, запасной. Обязателен хотя бы один Адрес
2:5
Клиент может иметь от двух до пяти связанных Адресов. Обязательно привязать минимум два адреса, например домашний и рабочий.
Аналогично определяется «Множественность В». Сколько Клиентов могут быть привязаны к одному Адресу.
(А) Адрес ® (В) клиент.
Варианты значений атрибута «Множественность В»:
Значение
Пояснение
0:1
На Адресе может быть максимум один Клиент, или не быть Клиентов вообще (отсутствовать)
0:M
К Адресу можно привязать не больше M Клиентов. На Адресе может вообще не быть Клиентов.
1:1
К Адресу должен быть привязан только один Клиент. Отсутствие Клиентов на Адресе не допустимо
2:2
К Адресу обязательно привязывать двух Клиентов. Например семейный аккаунт и администратор.
ФИЗИЧЕСКАЯ ТАБЛИЦА
Описывает конкретное
представление данных в БД
Обеспечивает связь с Прикладной
Архитектурой (ПА) на уровне Сервисов, через
мета атрибут «Автоматизированная система»,
посредством ссылки
на конкретную АС в ПА
При наличии компонентов АС описанных на
прикладном уровне, рекомендуется указывать
компонент БД данной АС,
где физически находится таблица
Связь с ЛМД реализуется через мета атрибут
«Логическая сущность»
ФИЗИЧЕСКИЙ АТРИБУТ
Физический атрибут является дочерним
объектом Физической таблицы
Описывает конкретный столбец (колонку) в
физической таблице
Родительский объект Физическая таблица
указывается как ссылка в мета атрибуте
«Физическая таблица»
Если Физический атрибут является
связанным атрибутом, то для него
заполняются мета атрибуты:
✦ Флаг FOREIGN KEY
✦ Связанная таблица (ссылка на связанный объект
Физическая таблица)
✦ Ключ в связанной таблице (ссылка
на связанный объект Атрибут
физической таблицы)
SEAF CORE (ДЛЯ РАЗРАБОТЧИКА)
Схема сущности
Представления сущности
MarkDown документ карточки объекта
Что делать
(С) Чернышевский
Включить в политику процесс
управления ИА
Назначить ответственных на роли
в процессе управления ИА
Адаптировать и внедрить в
компании регламент
по управлению ИА
Обеспечить автоматический
сбор данных для ФМД
Поддерживать в актуальном состоянии слои
ЛМД, БГ и Агрегатов