* Smith P.; Edge J.; Parry S.; Wilkinson D. Crossing the Data Delta: Turn the data you have into the information you need. Entity Group Limited, 2016.

12.1.6. Влияние на ценность данных

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

Переход к виртуализированным средствам хранения и обработки данных обеспечивает целый ряд вполне ощутимых преимуществ.

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

●Подготовка к аварийному восстановлению упрощается, когда все информационные ресурсы, подлежащие включению в резервную копию, находятся в одном месте.

●По аналогичным соображениям упрощается создание многоуровневой архитектуры интеграции с предоставлением

централизованных информационных сервисов (более подробно см.

вразделе 12.2).

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

12.2.Интеграция и интероперабельность данных

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

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

12.2.1. Определение области знаний «Интеграция и интероперабельность данных»

Интеграция и интероперабельность данных (Data Integration and Interoperability, DII) – область, которая описывает процессы, связанные с перемещением и консолидацией данных как внутри хранилищ, приложений и организаций, так и в рамках обеспечения их взаимодействия.

Интеграция позволяет объединять данные в согласованные физические или виртуальные формы. Под интероперабельностью данных подразумевается способность двух или более информационных систем или компонентов к обмену и использованию информации, полученной в результате обмена[415],[416].

12.2.2. Цели и бизнес-драйверы

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

●своевременное предоставление требуемых данных потребителям (как пользователям, так и приложениям) в нужном им формате;

●физическая или виртуальная консолидация данных в хабах (концентраторах);

●снижение стоимости и сложности решений по управлению данными за счет разработки общих моделей и интерфейсов;

●выявление значимых событий (возможностей и угроз) и автоматический запуск процедур выдачи уведомлений и принятия мер;

●поддержка функций BI, аналитики, управления основными данными и обеспечение операционной эффективности.

Основной драйвер деятельности в области интеграции и интероперабельности данных – потребность в управлении перемещением данных.

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

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

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

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

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

иупрощают проверку их соблюдения.

12.2.3.Основные аспекты обеспечения интеграции и интероперабельности данных

При создании решений в области интеграции и интероперабельности данных важно уделять внимание следующим

аспектам[417],[418].

Корпоративный подход

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

Важным инструментом в реализации корпоративного подхода являются корпоративные сервисные шины (Enterprise Service Buses, ESB) – интеграционные решения, обеспечивающие синхронизацию данных в режиме, близком к реальному времени, между многими системами. Такие решения используют понятие хаба данных, предоставляющего каноническую модель для совместного использования данных организацией.

Каноническая модель данных – общая модель (используемая организацией или группой, отвечающей за обмен данными), стандартизирующая формат, в котором осуществляется распространение данных. Использование канонической модели ограничивает количество преобразований данных при обмене между системами или организациями. Каждой системе достаточно реализовать преобразование данных только в каноническую модель (при передаче) или из нее (при приеме), вместо того чтобы разрабатывать отдельные средства преобразования для множества систем, с которыми осуществляется обмен. В средах, где обмениваются данными более ста прикладных систем, интеграционное решение на основе канонической модели – единственно возможное.

ESB – пример реализации подхода к построению интеграционных решений, основанного на слабом связывании. Она действует как сервис обмена данными между приложениями. При таком подходе получение ответов на запросы, обращенные к другой системе, не является обязательным условием продолжения работы первой системы, т. е. доступность каждой из слабо связанных систем не зависит от доступности другой системы. Слабое связывание может быть реализовано с использованием различных средств: например,

посредством сервисов, интерфейсов прикладного программирования (API) или очередей сообщений.

Исследование данных

Исследование данных необходимо проводить перед проектированием интеграционных решений. Цель исследования – определение потенциальных источников данных, которые могут быть использованы при выполнении работ по интеграции. Оно должно выявить, где данные могут быть получены и где они должны интегрироваться.

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

Сервис-ориентированная архитектура

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

Цель сервис-ориентированной архитектуры – организация строго определенного взаимодействия между отдельными независимыми программными модулями. Каждый модуль выполняет функции (часто говорят «предоставляет сервисы») в интересах других программных модулей или людей. Ключевой концептуальный момент SOA – предоставляемые сервисы независимы: сервис и приложение ничего не знают друг о друге. Сервис-ориентированная архитектура может быть реализована с помощью различных технологий, включая веб-сервисы и обмен сообщениями.

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

Примерами наиболее часто применяемых стандартов реализации являются:

●SOAP: простой протокол доступа к объектам (Simple Object Access Protocol) – протокол обмена структурированными сообщениями

враспределенной вычислительной среде;

●RESTful API: набор архитектурных принципов построения сервис-ориентированных приложений. REST – сокр. от англ. Representational State Transfer (передача состояния представления). RESTful – прилагательное, употребляющееся по отношению к сервисам, которые соответствуют принципам REST;

●JMS: служба сообщений Java (Java Message Service) – стандарт обмена сообщениями между приложениями, выполненными на платформе Java;

●RMI: удаленный вызов методов (Remote Method Invocation) –

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

Модель публикации и подписки

Модель публикации и подписки (publish and subscribe) предусматривает наличие систем, поставляющих данные («издателей»), и систем, получающих эти данные («подписчиков»). Системы, поставляющие данные, вносятся в каталог сервисов данных, а системы, которым эти данные требуются, должны подписываться на услуги провайдера. После публикации данные автоматически рассылаются подписчикам.

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

Модель публикации и подписки идеально подходит для распространения данных среди всех заинтересованных сторон.

Извлечение, преобразование и загрузка

В основе любых решений в области интеграции и интероперабельности данных лежит процесс извлечения,

преобразования и загрузки (Extract, Transform, Load; ETL). Вне зависимости от того, выполняются они физически или виртуально, в пакетном режиме или режиме реального времени, эти шаги непременно присутствуют при перемещении данных между приложениями и организациями.

Процесс преобразования переводит выбранные данные в структуру, совместимую с целевым хранилищем. Часто бывает так, что при этом нужно объединить фрагменты данных вместе (агрегирование) или, возможно, выполнить операции с данными, или провести вычисления, чтобы предоставить дополнительную информацию (обогащение). Границы между преобразованием, агрегированием и обогащением провести непросто, но все эти действия представляют собой добавление некоторой ценности к исходным данным. Это позволяет представлять потребителям данные в более полезной форме.

Задержка при обработке

В зависимости от требований по интеграции данных процедуры ETL могут выполняться в режиме периодической пакетной обработки или обработки по мере доступности новых или обновленных данных (в режиме реального времени или управляемой на основе событий – event driven). Обработка данных о текущих операциях обычно проводится в режиме реального времени или в режиме, близком к реальному времени (near real-time), а данных, требуемых для анализа и отчетности, – по графику, в пакетном режиме.

Обычное явление сегодня – потоковая обработка данных. Потоковые данные (streaming data) «вытекают» из компьютерных систем в непрерывном режиме по ходу событий (фиксируется такая информация, как сведения о покупках товаров или ценных бумаг, комментарии в социальных сетях или показания датчиков, отслеживающих различные характеристики). Однако реализация потоковой обработки сопряжена с серьезными затратами на аппаратное и программное обеспечение.

Задержка (latency) – это разница во времени между моментом, когда данные были сгенерированы в системе-источнике, и моментом, когда они стали доступны в целевой системе. Различные подходы к обработке данных определяют различную степень задержки.

Задержка может быть высокой (при пакетной обработке), низкой (при запуске процедур переноса на основе событий) или очень низкой (при использовании синхронизации в режиме реального времени или при потоковой обработке).

Оркестровка данных

Потоки данных в интеграционном решении должны быть спроектированы и документально оформлены. Оркестровка данных как раз и представляет собой описание потоков данных от «старта» до «финиша», включая промежуточные шаги, требуемые для выполнения преобразования и транзакции. Можно рассмотреть, например, такой набор действий, которые могут образовывать единую транзакцию: разместить заказ, произвести оплату, запросить доставку, отменить заказ, вернуть платеж, отменить доставку. Оркестровка пакетной интеграции данных должна также предоставлять сведения о частоте перемещения и преобразования данных. Отдельные задачи, c помощью которых реализуется пакетная интеграция, обычно описываются в планировщике, который и запускает их в указанное время, с указанной периодичностью или по наступлении заданного события. Расписание задач может включать множество взаимозависимых шагов.

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

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

Проверка качества данных

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

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

Врезультате любые системы, подписанные на услуги по предоставлению данных, будут получать данные, уровень качества которых измерен и известен.

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

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

Диаграммы подобного рода могут быть полезны при объяснении всем заинтересованным сторонам ключевого принципа развития интеграционных решений – устранение связей «точка-точка» за счет реализации более многоуровневой технологии, поддерживаемой ESB.

12.2.4. Контекстная диаграмма области знаний и уровни зрелости функции «Интеграция и интероперабельность данных»

Контекстная диаграмма области знаний «Интеграция и интероперабельность данных» представлена на рисунке 12.4.

Интеграция и интероперабельность данных зависит от других областей управления данными:

●руководство данными – в части определения правил преобразования данных и структуры сообщений;

●архитектура данных – в части разработки архитектуры интеграционных решений;

●безопасность данных – в части обеспечения соответствия интеграционных решений требованиям по безопасности данных, как постоянно хранимых (persistent), так и виртуальных (virtual), а также «данных в движении» (in motion), которые перемещаются между приложениями и организациями;

●метаданные – в части отслеживания такой информации, как техническое описание данных (постоянно хранимых, виртуальных и передаваемых), описание их значения для бизнеса, описание бизнесправил преобразования данных, а также история операций и сведения о происхождении (lineage) данных;

●хранение и операции с данными – в части физической реализации решений по хранению данных;

●моделирование и проектирование данных – в части проектирования структур данных (постоянно хранимых, виртуальных,

атакже сообщений, которые перемещаются между приложениями и организациями).

На рисунке 12.5 представлены обобщенные характеристики уровней зрелости функции «Интеграция и интероперабельность данных».