Проблемы интеграции данных

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

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

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

3. Значение Хранилищ данных

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

     Интеграция  оперативных данных в Хранилище  имеет несколько преимуществ. Хранилище  данных может создаваться в следующих  целях:

• интеграция текущих и исторических значений данных;
• объединение данных из разрозненных источников;
• создание надежной платформы данных для аналитических целей;
• обеспечение однородности данных в организации;
• облегчение внедрения корпоративных стандартов данных без изменения существующих операционных систем;
• обеспечение широкой исторической картины и возможностей для анализа тенденций.

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

     Сегодня существует 4 основных подхода к  построению корпоративного Хранилища  данных: создание Хранилища по условиям заказчика, Хранилище данных на основе систем планирования ресурсов предприятия (Enterprise Resource Planning, сокр. ERP), виртуальное  Хранилище и новый тип - настраиваемое  Хранилище.

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

1. Обеспечивать определенную скорость доступа и гибкость, что включает:
• итеративный подход к внедрению, позволяющий учитывать меняющиеся бизнес-требования. Возможность быстрого обеспечения решения для конкретной области бизнеса, а также дальнейших расширений;
• возможность быстрого создания прототипов, чтобы новые бизнес-требования могли быть оперативно изучены вместе с пользователями;
• отсутствие жестких схем, т.к. пользователи часто обнаруживают, что им нужна совсем другая информация из Хранилища, чем они первоначально предполагали.
2. Обеспечивать масштабируемость:
• подход должен быть масштабируемым для того чтобы общий проект мог быть разделен на несколько отдельных (более мелких) проектов, направленных на удовлетворение различных приоритетов, имеющихся в тех или иных подразделениях организации. Это также упростит общее внедрение, т.к. позволит избежать осуществления очень крупных проектов;
• в идеале Хранилище должно легко расширяться для включения новых сфер бизнеса или наборов данных транзакций. Например, должна существовать возможность сначала создать Хранилище для областей продаж и маркетинга, а затем включить в него сферу финансов.
3. Обеспечивать расширяемость:
• по мере развития, роста и изменения бизнеса неизбежно появляются потенциальные новые источники данных (например, при приобретении другой компании). Очень важно иметь возможность быстро включить эти новые источники данных в Хранилище без сложной и длительной реконструкции последнего.
4. Обеспечивать ориентацию на пользователей:
• часто Хранилище может использоваться как цельный источник данных для создания различных подмножеств данных, таких как витрины или кубы, что облегчает разработку отчетности. Хранилище должно поддерживать процесс создания таких витрин и помогать пользователю в извлечении наборов данных;
• конструктивное решение Хранилища данных должно позволять бизнес-пользователям принимать участие как в первоначальной разработке Хранилища, так и в последующих изменениях его дизайна, связанных с изменениями требований бизнеса. Как показывает опыт, чем больше вовлечены пользователи в общее проектирование Хранилища, тем более вероятно, что будет удовлетворять требованиям бизнеса. Например, в Хранилище должен учитываться тот факт, что один и тот же субъект бизнеса в одних случаях может рассматриваться как клиент, а в других - как поставщик.
• в идеале Хранилище данных должно быть легко адаптируемым, чтобы пользователи могли работать только на уровне бизнеса, не осложняя себе жизнь, например, названиями таблиц. Также изменения в Хранилище, связанные с изменениями в бизнесе, не должны требовать выгрузки всех данных и их повторной последующей загрузки. Это замедляет развитие бизнеса и затрудняет способность быстро реагировать на изменения.
5. Обеспечивать способность реагировать на изменения и осуществлять бизнес-моделирование:
• Хранилище данных должно обладать способностью учитывать временную зависимость и вариабельность, т.е. поддерживать так называемую "корпоративную память": информацию о прошлом, настоящем и будущем бизнеса. Организации хотят иметь такие Хранилища, которые могут функционировать в течение длительного периода времени и хранить историческую информацию. В течение этого периода некоторые объекты могут измениться. Если эти исторические данные не сохраняются, то сравнение состояний одного и того же объекта во времени окажется невозможным;
• необходима функция поддержки планирования бизнес-сценариев, т.е. способность рассматривать и анализировать данные в различных аспектах, включая исторические тенденции. Это необходимо для изучения будущих возможностей бизнеса. Помимо этого, часто возникают новые сценарии и структуры отчетности, которые должны быть включены в Хранилище до того, как они вступят в силу. Это также важно для планирования различных сценариев.

4. Классификация технологий интеграции

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

     Можно дать следующую классификацию технологий интеграции:

• Системы интеграции корпоративных приложений (Enterprise Applications Integration, EAI) — технологии, ориентированные на решение проблем интеграции различных систем, приложений и данных внутри отдельной организации. Для этих технологий используется аббревиатура A2A (Application-to-Application — приложение-приложение).

• Системы интеграции между  организациями (межведомственной интеграции) Business-to-Business (Business-to-Business Integration, B2Bi) — технологии, ориентированные на обеспечение безопасного, надежного информационного обмена между различными организациями и их информационными системами. Эти технологии обеспечивают пересылку информации за пределы сетевых экранов (firewall) и дают возможность автоматизировать бизнес-процессы в рамках «расширенных организаций», которые включают поставщиков, партнеров, потребителей продуктов и услуг и т. д.

• Технологии  управления бизнес-процессами (Business Process Management, BPM), являющиеся результатом естественной эволюции классических систем документооборота и делопроизводства (workflow systems) и систем класса EAI и B2Bi. Традиционные системы управления документами ориентировались в основном на пересылку информации между людьми, выполнявшими определенные действия. В отличие от технологий B2Bi, которые ориентированы на интеграцию данных в межведомственной среде, технологии BPM интегрируют данные, приложения и людей через единые бизнес-процессы. Это отражает современную точку зрения, что основой интеграции должны быть бизнес-процессы. Причина здесь состоит в том, что бизнес-процессы организации «пересекают» границы различных приложений, департаментов и организаций.

     Традиционные  технологии интеграции корпоративных  приложений EAI и межведомственной интеграции B2Bi основаны на использовании так  называемого брокера (узла пересылки, шлюза) сообщений.

     Технологическим фундаментом брокера сообщений  является, как правило, программное  обеспечение промежуточного слоя пересылки  сообщений (Messaging-Oriented Middleware, MOM), которое  обеспечивает транспорт доставки информации и данных между прикладными системами. Примером такого программного обеспечения  является «сервер очередей сообщений» MSMQ (Microsoft Message Queuing). Продукты этого класса обеспечивают транспорт гарантированной  доставки сообщений между приложениями в территориально распределенной среде. Подход к интеграции приложений на основе продуктов класса MOM стал стандартным  в области интеграции корпоративных  информационных систем в конце 90-х годов.

     Базовая идея этой технологии заключается в  следующем: пусть имеется несколько приложений, связанных некоторой коммуникационной средой, но, возможно, не очень надежной. Одно приложение (например, система документооборота A) должно переслать информацию/документ другому приложению (системе документооборота B). Система A передает документ серверу пересылки сообщений и «забывает» о нем. Сервер пересылки сообщений обеспечит гарантированную и однократную доставку информации в систему B.

     Если  при этом интегрируемые приложения находятся внутри организации в  рамках одной корпоративной сети, то обеспечивается пересылка информации в режиме, «близком к реальному времени». Если интегрируются приложения, находящиеся в разных организациях, то принцип «очереди сообщений» и гарантированной доставки, который реализуется MOM-продуктами, обеспечивает асинхронное взаимодействие и так называемое «слабое связывание». Приложение организации A не вправе ожидать мгновенной доступности приложения организации B, но программное обеспечение гарантированной доставки сообщений берет на себя ответственность за доставку информации между ними.

4. Правительственный шлюз в интеграции информационных систем

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

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

4. Брокер сообщений

     Сегодня брокеры сообщений могут объединять большое количество взаимодействующих  систем. Результатом этого является то, что компания Gartner Group называет «Корпоративной нервной системой», т.е. инфраструктура брокера сообщений, к которой  легко могут быть подключены по сути дела любые приложения и которая  обеспечивает взаимодействие между  ними в режиме, близком к реальному  времени.

     Брокер  сообщений интегрирует гетерогенные приложения и хранилища данных и  предоставляет три типа служб:

• Пересылка сообщений и перемещение данных обеспечивает физический транспорт доставки сообщений между приложениями. Это может быть сделано на основе таких Интернет-протоколов, как Hypertext Transfer Protocol (HTTP) и традиционных систем пересылки сообщений, например Microsoft Messaging Queuing и IBM MQ Series. Первые поколения этих технологий использовали собственные закрытые форматы для своих сообщений. В последнее время языком описания сообщений все больше становится XML.
• Интеллектуальная маршрутизация, которая определяет для каждого сообщения то, к какому приложению оно должно попасть. Маршрутизация часто включает механизмы публикации и подписки, когда серверное приложение один раз «публикует» некоторое бизнес-событие для брокера сообщений, а определенное количество других бизнес-приложений, заинтересованных в данном событии, «подписываются» на него.
• Трансформирование обеспечивает «мэппирование» (определение соответствия) данных между потенциально различными семантиками одного приложения или разных приложений. Так, если одно приложение использует в формате своих данных буквы «М» и «Ж» для описания пола человека, а другое приложение использует для такого кодирования «1» и «0», то уровень трансформации брокера сообщений может «мэппировать» информацию между приложениями, не меняя логику каждого из них. В более сложных ситуациях, когда одно приложение может ожидать 5 атрибутов в записи о клиенте, а другое приложение обеспечивает эти же атрибуты в двух различных записях баз данных, уровень трансформации может обеспечить «мэппирование» между такими различными структурами данных.

     Архитектура брокера сообщений может включать две дополнительных высокоуровневых  службы:

• Управление бизнес-процессами доводит уровень интеллектуальной маршрутизации до возможностей автоматизации потоков работ (workflow), которые полностью обслуживают внутренние и внешние процессы;
• Мониторинг процессов и событий превращает брокер сообщений в центр информационных потоков внутри и вне предприятия, а также обеспечивает функции анализа бизнес-операций в масштабе близком к реальному времени.