Любой корпоративный ИТ-ландшафт состоит из множества приложений, большинство из которых имеют собственные базы данных.
В этих базах данных хранятся информационные объекты, представляющие бизнес-объекты, события и этапы бизнес-процессов.
Многие объекты бизнес-процессов имеют «отражения» сразу в нескольких базах данных: например, единица оборудования промышленного предприятия описывается с разных точек зрения в системах учета, управления ремонтом и техническим обслуживанием, управления производством и т. д. Чтобы бизнес-приложения, автоматизирующие разные бизнес-процессы, как-то работали вместе, их необходимо интегрировать: внедрить продукты классов MDM (Master Data Management) и ESB (Enterprise Service Bus), позволяющие хоть как-то управлять обменом информацией между множеством -платформенные решения.
Те, кто занимался такой интеграцией, прекрасно понимают, что это долгая, трудная и неблагодарная работа.
Что, если есть способ избавиться сразу от всех проблем интеграции? Такая «волшебная пуля» существует, и ее называют архитектурой, ориентированной на данные.
Его основная идея — сделать данные, а не бизнес-приложения, центральным элементом корпоративной ИТ-архитектуры.
Этот принцип изложен в Манифест дата-центрической архитектуры и в книге Революция, ориентированная на данные: восстановление работоспособности корпоративных информационных систем .
Представьте, что у компании есть единое виртуальное хранилище данных, в котором каждый бизнес-объект или событие существует в единственном экземпляре.
Для наглядности можно представить, что идея MDM-системы доведена до логически завершенной реализации, и именно MDM является хранилищем всех корпоративных данных; бизнес-приложения не имеют собственной СУБД и работают только с объектами данных из MDM. Преимущества такой архитектуры очевидны:
- Необходимость в интеграционных процедурах отпадает раз и навсегда.
- Затраты на хранение данных сокращаются за счет устранения множества копий каждого бизнес-объекта в разных системах.
- Аналитика и поддержка принятия решений упрощаются, поскольку теперь для построения любого аналитического профиля больше не нужно тратить месяцы на извлечение и объединение данных из разных систем — они всегда под рукой.
- Улучшает качество данных за счет исключения неполных и нерелевантных представлений бизнес-объектов.
- Процесс замены одного бизнес-приложения другим упрощается, поскольку все они работают с одними и теми же данными.
Вы можете легко и быстро создавать микро-интерфейсы для решения конкретных бизнес-задач.
Неужели нельзя выбросить все существующие бизнес-приложения и начать с нуля, вывернув наизнанку всю корпоративную ИТ-архитектуру? Необходим плавный процесс перехода, и этого можно достичь, рассматривая платформу управления корпоративными данными не только как физический репозиторий, содержащий материализованные представления всех бизнес-объектов, но и как логическую витрину данных, способную извлекать эти объекты из любого репозитория.
включая базы данных и службы устаревших бизнес-приложений.
Клиенту платформы не должно быть важно, где находятся нужные ему данные — в одном из множества хранилищ, скрытых внутри платформы, или в СУБД бизнес-приложения.
На практике, скорее всего, необходимый объект данных будет собран платформой в момент выполнения запроса из нескольких источников.
Итак, если на первом этапе построить платформу, работающую в режиме логической витрины данных, способную обеспечить «прозрачный» доступ ко всем (или хотя бы многим) данным из существующих корпоративных систем, а затем постепенно перенести эти данные в виртуальную витрину.
корпоративное облако – плавный переход к дата-ориентированной архитектуре будет успешным.
Уже на первом этапе можно будет создавать новые, ориентированные на данные приложения.
Чем этот подход отличается от создания «обычного» корпоративного облака или озера данных? Прежде всего, методология использования платформы, особое внимание к структуре данных и некоторым функциональным особенностям.
Если обычное озеро данных зачастую представляет собой совокупность наборов данных, созданных кем-то для решения конкретных задач и заведомо содержащих копию информации, которая уже где-то существует, то для датацентрической архитектуры принципиально важно придерживаться принципа «один объект в реальный мир — один объект данных».
И никаких физических порезов, по крайней мере стойких.
Управление структурой корпоративных данных — отдельный и очень важный вопрос, которому зачастую уделяется слишком мало внимания.
Задача описания структуры всей информации, с которой работает предприятие, может показаться настолько сложной, что никто даже не думает о ее решении; вместо этого для конкретных бизнес-задач создается множество структур данных, что имеет очевидные последствия.
Мы утверждаем, что эту проблему можно и нужно решить; она может быть успешно решена на практике в конкретных проектах; вам просто нужно использовать подходящие для этого технологии.
Один из возможных вариантов — описать структуру корпоративной информации с помощью онтологий (см.
спецификацию СОВА консорциум W3C).
Тема онтологического моделирования выходит за рамки данной статьи; отметим лишь, что одной из его ключевых особенностей является технологическая однородность самих данных и описания их структуры.
Устраняя традиционный разрыв между данными и описанием их структуры (иногда неточно называемым метаданными) в реляционном мире, возможность управлять данными и их структурой с помощью одних и тех же инструментов обеспечивает уровень гибкости, необходимый для создания и поддержки моделей данных, включающих в себя десятки тысяч моделей данных.
типы сущностей и свойств.
Нельзя забывать о многочисленных разработанных методах онтологического моделирования, использовании онтологий верхнего уровня, повторном использовании и расширении стандартных онтологий.
Когда вся корпоративная информация становится структурированной и логически связной, она приобретает свойства графа корпоративных знаний, что открывает новый уровень аналитических возможностей предприятия и позволяет значительно более эффективно монетизировать накопленную информацию.
Какими функциональными свойствами должна обладать платформа, являющаяся ядром дата-ориентированной архитектуры? Она должна:
- Поддерживать хранение состояния каждого объекта данных в любой момент времени.
Объекты данных — это не просто отражения текущего состояния объектов или событий реального мира, а «четырехмерные» описания всех состояний на протяжении всего срока службы объекта.
- Храните непрерывную историю модели данных (структуры).
Структура данных так же изменчива, как и сами данные.
Платформа должна иметь возможность представлять объекты данных в соответствии с любой версией структуры.
Структура должна формально описывать значение каждого элемента данных.
- Поддержка множества API для работы с данными, включая REST, GraphQL, SPARQL.
- Обеспечить возможности обнаружения и извлечения данных.
- Разработали инструменты управления доступом к данным и защиты конфиденциальной информации.
- Вспомогательные инструменты для отслеживания происхождения данных, мониторинга качества данных и описания степени доверия к данным.
В онтологической модели можно в машиночитаемом и автоматически исполняемом виде описать не только структуру данных, но и алгоритмы их обработки — правила контроля целостности, арифметических вычислений и добавления информации (см.
спецификации).
ШАКЛ и расширенные функции SHACL ).
Это позволяет по-новому взглянуть на принцип low code: если единая корпоративная платформа управления данными хранит не только данные и описание их структуры, но и машиночитаемое описание алгоритмов обработки данных, то новые бизнес-приложения, ориентированные на использование таких описаний станет еще более гибким и позволит менять их поведение на лету, не вмешиваясь не только в код, но и в настройки приложения.
Платформы, соответствующие таким требованиям, уже существуют и используются как на российском, так и на зарубежном рынке.
Теги: #Хранение данных #Облачные вычисления #архитектура приложений #онтологии #Семантика #виртуализация данных #граф знаний #OWL #архитектура, ориентированная на данные #онтологическое моделирование
