что такое интеграция информации
Интеграция данных
Содержание
Уровни интеграции данных
Системы интеграции данных могут обеспечивать интеграцию данных на физическом, логическом и семантическом уровне. Интеграция данных на физическом уровне с теоретической точки зрения является наиболее простой задачей и сводится к конверсии данных из различных источников в требуемый единый формат их физического представления. Интеграция данных на логическом уровне предусматривает возможность доступа к данным, содержащимся в различных источниках, в терминах единой глобальной схемы, которая описывает их совместное представление с учетом структурных и, возможно, поведенческих (при использовании объектных моделей) свойств данных. Семантические свойства данных при этом не учитываются. Поддержку единого представления данных с учетом их семантических свойств в контексте единой онтологии предметной области обеспечивает интеграция данных на семантическом уровне. [1]
Процессу интеграции препятствует неоднородность источников данных, в соответствии с уровнем интеграции. Так, при интеграции на физическом уровне в источниках данных могут использоваться различные форматы файлов. На логическом уровне интеграции может иметь место неоднородность используемых моделей данных для различных источников или различаются схемы данных, хотя используется одна и та же модель данных. Одни источники могут быть веб-сайтами, а другие — объектными базами данных и т. д. При интеграции на семантическом уровне различным источникам данных могут соответствовать различные онтологии. Например, возможен случай, когда каждый из источников представляет информационные ресурсы, моделирующие некоторый фрагмент предметной области, которому соответствует своя понятийная система, и эти фрагменты пересекаются.
Возникающие задачи
При создании системы интеграции возникает ряд задач, состав которых зависит от требований к ней и используемого подхода. К ним, в частности, относятся:
Архитектуры систем интеграции
Консолидация
В случае консолидации данные извлекаются из источников, и помещаются в Хранилище данных. Процесс заполнения Хранилища состоит из трех фаз — извлечение, преобразование, загрузка (Extract, Transformation, Loading — ETL). Во многих случаях именно ETL понимают под термином «интеграция данных». Еще одна распространенная технология консолидации данных — управление содержанием корпорации (enterprise content management, сокр. ECM). Большинство решений ECM направлены на консолидацию и управление неструктурированными данными, такими как документы, отчеты и web-страницы.
Консолидация — однонаправленный процесс, то есть данные из нескольких источников сливаются в Хранилище, но не распространяются из него обратно в распределенную систему. Часто консолидированные данные служат основой для приложений бизнес-аналитики (Business Intelligence, BI), OLAP-приложений.
При использовании этого метода обычно существует некоторая задержка между моментом обновления информации в первичных системах и временем, когда данные изменения появляются в конечном месте хранения. Конечные места хранения данных, содержащие данные с большими временами отставания (например, более одного дня), создаются с помощью пакетных приложений интеграции данных, которые извлекают данные из первичных систем с определенными, заранее заданными интервалами. Конечные места хранения данных с небольшим отставанием обновляются с помощью оперативных приложений интеграции данных, которые постоянно отслеживают и передают изменения данных из первичных систем в конечные места хранения.
Федерализация
При использовании медиатора создается общее представление (модель) данных. Медиатор — посредник, поддерживающий единый пользовательский интерфейса на основе глобального представления данных, содержащихся в источниках, а также поддержку отображения между глобальным и локальным представлениями данных. Пользовательский запрос, сформулированный в терминах единого интерфейса, декомпозируется на множество подзапросов, адресованных к нужным локальным источникам данных. На основе результатов их обработки синтезируется полный ответ на запрос. Используются две разновидности архитектуры с посредником — Global as View и Local as View. [1]
Отображение данных из источника в общую модель выполняется при каждом запросе специальной оболочкой (wrapper). Для этого необходима интерпретация запроса к отдельным источникам и последующее отображение полученных данных в единую модель. Сейчас этот способ также относят к федеративным БД. [3]
Интеграция корпоративной информации (Enterprise information integration, сокр. EII) — это пример технологии, которая поддерживает федеративный подход к интеграции данных.
Изучение и профилирование первичных данных, необходимые для федерализации, несильно отличаются от аналогичных процедур, требуемых для консолидации.
Распространение данных
Приложения распространения данных осуществляют копирование данных из одного места в другое. Эти приложения обычно работают в оперативном режиме и производят перемещение данных к местам назначения, то есть зависят от определенных событий. Обновления в первичной системе могут передаваться в конечную систему синхронно или асинхронно. Синхронная передача требует, чтобы обновления в обеих системах происходили во время одной и той же физической транзакции. Независимо от используемого типа синхронизации, метод распространения гарантирует доставку данных в систему назначения. Такая гарантия — это ключевой отличительный признак распространения данных. Большинство технологий синхронного распространения данных поддерживают двусторонний обмен данными между первичными и конечными системами. Примерами технологий, поддерживающих распространение данных, являются интеграция корпоративных приложений (Enterprise application integration, сокр. EAI) и тиражирование корпоративных данных (Еnterprise data replication, сокр. EDR). От фееративных БД этот способ отличает двустороннее распространение данных. [1]
Сервисный подход
Сервисно-ориентированная архитектура SOA (Service Oriented Architecture), успешно применяемая при интеграции приложений, применима и при интеграции данных. Данные также остаются у владельцев и даже местонахождение данных неизвестно. При запросе происходит обращение к определённым сервисам, которые связаны с источниками, где находится информация и ее конкретный адрес.
Интеграция данных объединяет информацию из нескольких источников таким образом, чтобы ее можно было показать клиенту в виде сервиса. Сервис — это не запрос в традиционном смысле обращения к данным, скорее, это извлечение некоторой бизнес-сущности (или сущностей), которое может быть выполнено сервисом интеграции через серию запросов и других сервисов. Подход SOA концентрируется, в первую очередь, на определении и совместном использовании в форме сервисов относительно ограниченного количества самых важных бизнес-функций в корпорации. Следовательно, сервис-ориентированные интерфейсы в довольно большой степени строятся на ограниченном количестве запросов на необходимую информацию, которую нужно представить потребителю.
Имея соответствующие учетные данные системы безопасности, потребитель может осуществить выборку любых данных из источника через почти неограниченное количество различных запросов SQL. Но для этого потребитель должен иметь представление о модели источника данных и способе создания результата с использованием этой базовой модели. Чем сложнее модель источника данных, тем более сложной может оказаться эта задача. [4]
Кроме того
В [1] описан пример гибридного подхода.
Проблемы интеграции информации
Вне зависимости от выбранных технологии и метода интеграции данных, остаются вопросы, связанные с их смысловой интерпретацией и различиями в представлении одних и тех же вещей. Именно, приходится разрешать несоответствие схем данных [6] и несоответствие самих данных.
Типы несоответствия схем данных
Структурные и семантические конфликты выливаются в следующие проблемы:
Типы несоответствия собственно данных
Информационная интеграция
Под Интеграцией информации подразумевается объединение информации из нескольких баз данных (источников данных) с различными структурами данных в целом в единую единую структуру данных.
Интеграция более сложных систем не находилась в центре внимания компьютерных исследований до 1990-х годов и поэтому находится в процессе разработки.
Содержание
сказка
Модели обработки данных, существующие с 2011 года, приводят к изоляции данных в виде островков данных из разрозненных данных. Эти острова являются нежелательным артефактом из-за метода моделирования данных, который приводит к разрозненным наборам данных. Чтобы противодействовать этой проблеме, были разработаны методы, позволяющие избежать артефактов изоляции данных и интегрировать их в структуру данных.
Методы
Возможности и цели
Информационная интеграция приобретает важное значение в ряде различных ситуаций, как коммерческих, так и научных. Примеры практического применения интеграции информации можно найти в интеграции информации о продукте из информации производителя и извлечении этой информации с помощью поисковых систем по продукту или при оценке различных наборов геологических данных для определения трансграничных свойств поверхности.
Материализованный vs. Виртуальная интеграция
В основном можно выделить два типа интеграции:
Для сравнения можно выделить следующие преимущества и недостатки.
Интеграционные архитектуры
Материализованные архитектуры интеграции
В случае материализованных систем данные импортируются из источников, настраиваются и хранятся централизованно. Данные, доступные в исходных системах, обычно не меняются.
Архитектуры виртуальной интеграции
В отличие от материализованных систем, данные в системах виртуальных баз данных не хранятся в самой интегрированной системе, а остаются физически в источниках данных и загружаются в систему интеграции только в ответ на запросы (виртуальное хранилище данных).
похожие темы
Информационная интеграция показывает, среди прочего, совпадение и взаимосвязь со следующими предметными областями:
Интеграция данных
Преобразовывайте структурированные и неструктурированные данные из разных источников в достоверную и унифицированную форму, доступную для любой системы
Обзор
Что такое интеграция данных?
Интеграция данных — это совокупность технических и деловых процессов, таких как ETL, репликация и виртуализация данных. Интеграция данных используется для объединения информации из разрозненных источников в виде понятного и ценного набора данных для целей интеллектуальной обработки и бизнес-аналитики. Комплексное решение для интеграции данных предоставляет достоверные данные из различных локальных и облачных источников для обеспечения конвейера достоверных данных, готового к работе с DataOps.
Продукты IBM для интеграции данных, включая интеграцию данных в IBM Cloud Pak® for Data, являются масштабируемыми мультиоблачными решениями, которые помогут ускорить внедрение ИИ. Извлекайте большие объемы данных из различных источников, преобразовывайте их любым способом и загружайте в корпоративное хранилище данных или облачные сервисы.
Продукты IBM для интеграции данных также можно использовать отдельно или в качестве управляемых услуг в рамках IBM Cloud®.
Разбор за 30 секунд: Что такое интеграция данных? (00:30)
IBM занимает второе место в категории «Варианты использования фабрик данных»
Узнайте больше из отчета Gartner «Самые необходимые функции для инструментов интеграции данных», 2021 г.
Варианты использования интеграции данных
Интеграция данных о клиентах
Объединение данных из распределенных баз данных и систем позволяет улучшить взаимоотношение с клиентами (CRM) и предоставлять им то, что они ожидают.
Интеграция данных в сфере здравоохранения
Объединение клинических данных, результатов геномного анализа, радиологических исследований и снимков позволяет ускорить получение ценной информации и сделать ее доступной для лечения пациентов, когортных исследований и анализа состояния здоровья населения.
Интеграция больших данных
Современные хранилища данных, обеспечивающие унифицированное представление больших данных из нескольких источников, позволяют упростить процессы интеллектуальной обработки деловой информации.
Преимущества решений IBM для интеграции данных
Платформа с открытым исходным кодом
Воспользуйтесь платформой интеграции данных на основе Red Hat® OpenShift®, обеспечивающей масштабируемость корпоративного класса и безопасность.
Автоматизация на основе ИИ
Ускорьте доставку и сократите совокупную стоимость владения за счет автоматизации задач на основе ИИ.
Возможность развертывания в мультиоблачных средах
Воспользуйтесь преимуществами технологии контейнеров для интеграции данных в гибридных и мультиоблачных средах.
IBM DataStage
Продукт IBM® DataStage® является лидер ом в сфере ETL и представляет собой масштабируемый инструмент интеграции данных для проектирования, разработки и выполнения заданий по перемещению и преобразованию данных в среде заказчика и в облачных средах.
Благодаря современной архитектуре на основе контейнеров в Red Hat OpenShift решение IBM DataStage for IBM Cloud Pak for Data объединяет лучшие в отрасли инструменты интеграции данных с DataOps, механизмами контроля и аналитики на базе единой платформы данных и ИИ. Предоставляйте достоверные данные в большом масштабе в гибридных или мультиоблачных средах.
Дополнительные продукты для интеграции данных
IBM InfoSphere Information Server
Улучшайте сквозную интеграцию данных для очистки, мониторинга, преобразования и предоставления достоверных данных.
IBM InfoSphere Information Server for Data Integration
Обеспечивает понимание, очистку, преобразование, мониторинг и доставку достоверной информации с богатым контекстом.
IBM BigIntegrate
Экспортируйте, преобразовывайте и импортируйте кластеры хранения больших данных Hadoop.
IBM Analytics помогает нам получать более качественные знания и поддерживает рост нашего бизнеса.
Ромина Орешкович
Директор по финансовым вопросам, Orbico
Ресурсы
Отчет Gartner Magic Quadrant за 2021 год в категории инструментов для интеграции данных
Узнайте, как компания IBM на протяжении более десяти лет признается лидер ом в отчете Magic Quadrant в категории инструментов интеграции данных.
Интеграция данных. Важная составляющая успешной стратегии ИИ
Узнайте, почему интеграция данных имеет решающее значение для предоставления доступа в реальном времени к большим объемам данных для ИИ.
Прочитать публикацию в блоге
Интеграция и контроль облачных данных
Присоединяйтесь к участникам вебинара и узнайте, какие пять шагов помогут сократить расходы, повысить уровень масштабирования и гибкость.
Интерактивное руководство по DataOps
Узнайте, как DataOps создает масштабируемую и гибкую культуру данных с помощью автоматизации, качества данных и средств контроля.
Оптимизируйте корпоративное хранилище данных для мультиоблачной стратегии
Узнайте о том, как на практике обеспечить наличие достоверных, готовых к использованию данных, и о том, какие преимущества это может дать.
Читать публикацию (3 МБ)
IBM Cloud Pak for Data расширяет возможности услуг DataOps
Повысьте гибкость бизнеса, сократите риски и обеспечьте экономию средств.
Прочитать публикацию в блоге
IBM DataStage
Предоставляйте готовые бизнес-данные в реальном времени для ИИ с помощью IBM DataStage.
Читать краткий обзор (173 КБ)
Более глубокое представление
Методы интеграции данных
Интеграция данных играет важнейшую роль для консолидации корпоративных данных в единое, достоверное представление для аналитики и развития бизнеса. Например, унифицированное представление данных о клиентах способствует созданию более эффективных маркетинговых стратегий. При этом используются различные методы интеграции данных, например:
Сложные задачи интеграции данных
Многие организации сталкиваются с ростом объемов данных, поступающих из разных систем, включая реляционные базы данных и службы потоковой передачи данных. Интеллектуальная обработка данных, скрывающихся в разнообразных источниках, позволяет принимать более обоснованные решения, однако для обеспечения контроля, регулирования и доверия необходимо реализовать последовательные процессы интеграции данных. Препятствием на пути интеграции могут стать следующие факторы:
Высокое время отклика данных в мультиоблачных средах
Низкая скорость перемещения томов данных между мультиоблачными средами и озерами данных не позволяет использовать данные в приложениях или операционных системах в режиме реального времени.
Большое количество сложных и дорогих инструментов
Управление несколькими инструментами интеграции данных требует высоких денежных затрат и усилий.
Неавтоматизированные рабочие процессы
Задачи, выполняемые вручную, например написание кода и проектирование задач, могут увеличивать сроки разработки и модернизации приложений. Кроме того, неавтоматизированные процессы должны быть спроектированы для каждой облачной среды, что в случае нескольких облачных сред увеличивает продолжительность и стоимость разработки.
Низкое качество данных и уровень управления
Данные, поступающие из множества разнотипных систем, могут быть непростыми в управлении, что подвергает ваш бизнес риску. Надежные и достоверные данные также являются обязательным условием для создания эффективных моделей ИИ.
Облачная интеграция данных
К хранилищам данных относятся локальные среды, облачные среды и среды озер данных. Кроме того, организации часто используют несколько облачных сред от разных поставщиков для решения различных задач в области хранения или развертывания приложений. Интеграция облачных данных направлена на создание унифицированного представления данных из разных сред.
Для уменьшения сложности при интеграции облачных данных требуется более современный подход. Надежный инструмент интеграции данных в мультиоблачных средах должен решать следующие задачи:
Такой современный подход реализован в IBM DataStage for IBM Cloud Pak for Data.
Отличия между интеграцией данных и интеграцией приложений
На первый взгляд, интеграция данных и интеграция приложений — схожие понятия, но на самом деле они сильно отличаются друг от друга. Как отмечалось выше, интеграция данных — это деятельность, направленная на поиск и получение информации из разрозненных источников, а также формирование унифицированного представления данных. Интеграция приложений напрямую связывает несколько независимых приложений для обеспечения их взаимодействия, как правило, с помощью современных API или традиционных сервис-ориентированных архитектур. Объединение и оптимизация данных и рабочих процессов позволяют сократить разрыв между локальными системами и облачными приложениями.
Отличия между интеграцией данных и миграцией данных
Миграция данных представляет собой процесс перемещения данных между хранилищами разных типов. Сюда входит перемещение данных из локальных сред в облако. Интеграция данных — более сложный процесс, включающий шаги ETL или ELT для подготовки данных к анализу.
Интеграция информационных систем предприятия
5. Интеграция информационных систем предприятия
5.1. Взаимосвязь информационных подсистем предприятия
Каким образом связаны информационные системы внутри предприятия? Обычный путь для российской компании средних размеров — начинать внедрение информационных технологий с автоматизации работы бухгалтерии, отдела кадров и документооборота. Данные этих систем наиболее формализованы, процессы легко автоматизируются. Широко распространенные пакеты «1C: Бухгалтерия», «Босс: Кадровик», «LanDocs», «LanStaff», «Salary» и др. позволяют наращивать себя любыми приложениями и, таким образом, интегрировать их в общую информационную систему предприятия. Рис. 5.1 показывает, каким образом модули информационной системы компании связаны друг с другом. Модуль TPS обслуживает основные производственные и вспомогательные процессы, и обычно это главный источник для других информационных модулей. ESS — главный получатель данных и внутренних систем и внешней среды.
Другие системы также обмениваются данными. И здесь возникает один из самых трудных вопросов для руководителя — поиск оптимальной степени интеграции. Большой соблазн иметь абсолютно интегрированную систему, но такая интеграция чрезвычайно трудоемка, стоит немалых денег. И лучше даже не говорить, во что обходится сопровождение такой системы. Поэтому нужно взвесить потребности в интегрированных системах, поставив их на чашу весов против трудностей и дороговизны крупномасштабной ИС. Не существует стандартного уровня интеграции или централизации — каждый руководитель должен самостоятельно (или с помощью консалтинговой фирмы) решать эту непростую проблему.
Связи между DSS и совокупностью TPS, KWS, MIS намеренно показаны неопределенными. Иногда DSS тесно связана с другими подсистемами. Но это только в том случае, если предприятие отличается высокой степенью автоматизации всех процессов. Обычно подсистема DSS изолированы от основных производственных информационных систем и использует их данные и информационные потоки для работы своих аналитических систем.
В любом случае, нет рецептов на все случаи — все зависит от организационно-функциональной структуры конкретного предприятия, структуры его бизнеса, реальных инвестиционных возможностей и политики развития.
5.2. Сервис-ориентированная архитектура ИС
Интеграция разнородных и распределенных данных не в состоянии разрешить все вопросы управления предприятием. В соответствии с процессным подходом наибольшую ценность представляют не сами по себе данные, а использование информации в тех или иных бизнес-процессах компании. В самых современных ИС принято рассматривать за «атомарную» единицу не данные в «чистом» виде, а некоторый сервис, соответствующий какому-то элементарному бизнес-процессу. В частности, такой сервис может просто выдавать какие-то данные, являясь аналогом «атомарной» единицы классических ИС.
В настоящее время при формировании информационной инфраструктуры предприятия, при проектировании и реализации КИС всё чаще применяется сервис-ориентированная архитектура (Service-Oriented Architecture — SOA). Это такая архитектура ИС, в которой система строится из набора гетерогенных слабосвязанных компонентов (сервисов). SOA понимается как парадигма организации и использования распределенного множества функций, которые могут контролироваться различными владельцами. Базовыми понятиями в такой архитектуре являются «информационная услуга» и «композитное приложение».
Информационная услуга (сервис) — это атомарная прикладная функция автоматизированной системы, пригодная для использования при разработке приложений, реализующих прикладную логику автоматизируемых процессов как в самой системе, так и для использования в приложениях других автоматизированных систем.
Сервис обычно характеризуется следующими свойствами:
Композитное (составное) приложение — программное решение для конкретной прикладной проблемы, связывающее прикладную логику процесса с источниками данных и информационных услуг, хранящихся на гетерогенном множестве базовых информационных систем. Обычно композитные приложения ассоциированы с процессами деятельности и могут объединять различные этапы процессов, представляя их пользователю через единый интерфейс.
Использование такого подхода при построении архитектуры сложных интегрированных информационных систем позволяет:
Благодаря упрощению среды управления и взаимодействия снижается потребность в кодировании новых программ. Повторное использование сервисов сокращает затраты времени на разработку; рационализация унаследованных процессов помогает уменьшить общее число процессов, требующих эксклюзивных методов управления. Благодаря использованию простых протоколов, значительно сокращаются трудозатраты на поддержку приложений.
Обязательным условием построения и внедрения архитектуры системы на основе SOA является использование единой инфраструктуры описания сервисов (репозитория сервисов), разрешенных протоколов доступа и обмена сообщениями, форматов сообщений.
Упомянутая инфраструктура образует так называемую интеграционную шину (Enterprise Service Bus — ESB), являющуюся одним из центральных компонентов системы. Она устанавливает единые правила публикации сервисов, управления и информационного взаимодействия между приложениями различных систем, входящих в состав интегрированной системы. Это упрощает управление приложениями и их поддержку, а также снижает риск фрагментации приложений и процессов.
Основные компоненты архитектуры информационной системы, построенной на основе концепции SOA и ESB, представлены на рис. 5.2.
Каждая из служб взаимодействует не с остальными службами напрямую, а только с шиной. ИШ образует однородную среду информационного взаимодействия и является фундаментом для интеграции информационных систем, функционирующих в различных учреждениях и ведомствах. ИШ определяет кем, где, каким образом и в каком порядке должны обрабатываться запросы.
Если сервис (информационный ресурс) не поддерживает эти правила, необходимо создавать промежуточный модуль-адаптер, который предоставляет системе необходимый интерфейс и обеспечивает взаимодействие с ресурсом.
По данным Gartner Group («Predicts 2007: SOA Advances», 17 ноября 2006): «К 2008 году SOA станет господствующей архитектурой построения ИТ-систем, что приведет к окончанию 40-летней эры господства архитектуры монолитных приложений». Отметим, что этот прогноз в большой степени оправдался.
Изменение и совершенствование бизнес-процессов в компаниях занимает годы. По усредненным данным Gartner Group: 80 % ИТ-бюджета — это расходы на сопровождение систем, из них 35 % — затраты на интеграцию приложений, 60 % стоимости внедрения корпоративной ИС составляют расходы на интеграцию, 50 % ИТ-бюджета потрачено на обеспечение интерфейсов систем. Использование SOA архитектуры позволяет эффективно организовать оперативную адаптацию ИТ-систем под требования бизнеса, что дает стратегическое преимущество компании, заключающееся в:
С точки зрения бизнеса SOA можно представить как набор гибких служб и процессов, которые бизнес предлагает своим заказчикам, партнерам или внутри своей собственной организации. В данном контексте эти же службы можно по-разному комбинировать и оснащать, поддерживая изменения или развитие бизнес-требований и моделей с течением времени.
Основные бизнес-цели внедрения SOA-решений состоят в ликвидации:
Становление и развитие SOA происходило на базе практических требований бизнеса, заключавшимхся, прежде всего, в разумной экономии программных и технологических средств и затрат на реализацию и сопровождение информационной инфраструктуры:
Сегодняшний уровень развития SOA позволяет утверждать, что все указанные требования в той или иной мере выполняются. Рост рынка продуктов для SOA-решений — 100 % в год. В 2007 году SOA была использована как основа создания 50 % новых, критичных для бизнеса приложений и бизнес-процессов; к 2012 году этот показатель вырос до 85 %. Более 80 % приложений, введенных в промышленное использование в 2010 году, будут частично или полностью перепроектированы к 2014 году, чтобы быть использованы в построении композитных приложений в SOA-архитектуре.
К 2014 более 80 % всех программных инфраструктурных продуктов будут включать корпоративную шину сервисов или требовать ее использования. Среди исполнительных директоров компаний 58 % считают, что в период до 2015года в числе главных стратегических преимуществ компаний новые модели ведения бизнеса имеют бoльшее значение, чем выпуск новых продуктов и услуг. По данным Forrester («The State of SOA in Financial Services», январь 2014 года) «Большинство финансовых компаний будут использовать SOA к концу 2014 г. В настоящее время более 60 % европейских финансовых компаний или уже используют SOA или на последней стадии внедрения».
5.3. Варианты интеграционных решений
Многообразие применяемых технологий и систем, разнообразие форматов данных, циркулирующих в информационных потоках, обилие аналитических и отчётных форм сделали чрезвычайно актуальной задачу интеграции указанных выше технологических и информационных объектов и сущностей, а также физические и виртуальные пространства их взаимодействия в единую информационно-управленческую среду (рис. 5.3) [Н.И. Куцевич.,http://www.rtsoft.ru].
Интеграция — это не просто механическое объединение модулей информационной системы. При разработке плана интеграции исходят прежде всего из стратегических целей развития предприятия, возможного изменения бизнес-логики, в соответствии с которой выстраиваются бизнес-процессы и осуществляется их информационное сопровождение. Интеграция может производиться на уровне форматов и баз данных, программно-аппаратных и сетевых устройств, пользовательских интерфейсов, форм и шаблонов документооборота, программных приложений и т.д. Выгоды от такой интеграции очевидны.
Подход к разработке и внедрению КИС, основанный на интеграции приложений, позволяет:
Интеграция на уровне данных
Одной из главных проблем интеграции данных является обилие форматов и типов (неструктурированные, частично-структурированные, жёстко-структурированные) данных, а также лавинообразное нарастание их объёмов. Циркулирование разнородных массивов данных и информации в сетях различных служб предприятия создает множество проблем с их сбором, структурированием, обработкой, анализом, хранением, архивированием и передачей пользователю для принятия делового решения. На рисунке 5.4 показана традиционная схема интеграции данных.
Для их интеграции в настоящее время обычно используют стандартные интерфейсы и протоколы, например, SQL и JDBC/ODBC, применяют различные инструменты реляционных баз данных (Relational Database — RD), сквозных репозиториев — баз данных с «надстройкой», содержащей информацию об артефактах и объектах проектирования, надмножество словарей метаданных (Transparent Repository — TR) и современных хранилищ и фабрик данных (Data Warehouse, Data Factory — DW, DF).
Последний вид технологий интеграции применяется, как правило, в крупных компаниях и производственных объединениях. Такие технологии создают удобную для пользователя единую среду для хранения и использования данных. Ниже будет подробнее рассказано о системах коллективного использования информации.
Интеграция на уровне физических, программных и пользовательских интерфейсов
Этот вид интеграции начинался как один из видов «лоскутной интеграции», когда предпринимались попытки объединить разрозненные программные приложения, написанные в разное время разными разработчиками, в подобие единого целого. Приложения объединялись по принципу «каждый с каждым», что, в конечном счёте, усложняло их взаимодействие и создавало массу проблем. Кроме того, всё сложнее становилось использовать унаследованные (Legacy Software) и встроенные (Embedded System) системы.
Такой подход хорош для небольшого количества приложений. При большом их числе он практически не работает и не позволяет строить качественно новые запросы к агрегированным данным, т.е. существенного выигрыша от объединения данных нет. В настоящее время проблема интеграции на уровне интерфейсов решается на базе использования информационных подсистем, реализованных стандартными программными приложениями с открытыми интерфейсами (Open Application Programming Interface).
Подобные унифицированные интерфейсы разрабатываются, например, на базе семейства международных стандартов POSIX. В этом случае степень интегрируемости можно характеризовать некоторым числовым показателем (метрикой) который можно, условно говоря, вычислить, перемножив показатель «качества» и «показатель открытости» программного интерфейса. Показателем качества могут выступать такие характеристики, как «совместимость», «надёжность», «переносимость», «понятность», «удобство использования» и пр. В результате мы получим индекс, который (в известной степени) характеризует способность приложения быть частью какого-то другого, глобального композитного приложения.
В настоящее время всё чаще применяется следующий алгоритм: отделяют слой обработки данных от привязанных к ним форм визуализации и реализуют прикладную бизнес-логику на одном из языков третьего поколения (3GL), оформив программный доступ к прикладным функциям в виде хорошо документированного программного интерфейса (рис. 5.5).
Интеграция на функционально-прикладном и организационном уровнях
Этот вид интеграции предполагает объединение ряда однотипных или схожих функций в макрофункции с перераспределением потоков данных и управления, а также ресурсов и механизмов для исполнения. Это часто влечёт за собой перестройку организационных структур, бизнес-процессов и, соответственно, схему их информационного и документационного обеспечения.
Выгоды от такой интеграции очевидны — процессы становятся более прозрачными, управляемыми, менее затратными, уменьшается количество обслуживающего персонала, число ошибок при формировании документов и т.д. Однако интеграция такого вида влечёт за собой существенную перестройку или полный реинжиниринг сети процессов, что связано с крупными рисками. Чаще всего такая интеграция проводится в том случае, когда предприятие готовится к внедрению КИС на базе известного решения, которое требует привести бизнес-процессы к требуемому стандарту, или перестраивает свою деятельность в связи со сменой устремлений, открытием филиалов в других странах, освоением новых сегментов рынка и т.д.
Интеграция на уровне корпоративных программных приложений
Интеграция на уровне приложений (Enterprise Application Integration — EAI,) подразумевает совместное использование исполняемого кода, а не только внутренних данных интегрируемых приложений. Программы разбиваются на компоненты, которые интегрируются с помощью стандартизованных программных интерфейсов и специального связующего ПО.
При таком подходе из этих компонентов создается универсальное программное ядро или платформа, с помощью которых используют все приложения. Для каждого приложения создается только один интерфейс для связи с этим ядром, что существенно облегчает задачу интеграции. Полученную в результате систему легче поддерживать и расширять. Повторное использование функций в рамках имеющейся среды позволяет значительно снизить время и стоимость разработки приложений. В этом случае анализ внутренней конструкции приложений — обязательный этап в оценке степени интегрируемости тех приложений, которые предполагается связывать в рамках того или иного проекта. Этот анализ усложняется тем, что обычно разработчики приложений, являющихся законченными программными продуктами, как правило, не показывают деталей внутренней конструкции приложений.
В связи с этим технология интеграции в настоящее время рассматривает не просто интеграцию приложений, но их интеграцию на базе интеграции бизнес-процессов – в этом случае следует говорить об интеграции на уровне всего предприятия (Enterprise Integration Metodology — EIM). Схема такой объединенной методологии показана на рисунке 5.6.
Методология EIM реализуется современными технологиями и инструментами, среди которых можно, например, указать рассмотренную выше технологию интеграции на базе сервис-ориентированных архитектур (SOA). Архитектура ИС в таком случае строится из набора гетерогенных слабосвязанных компонентов (сервисов) и понимается как парадигма организации и использования распределенного множества функций, которые могут контролироваться различными владельцами. Базовыми понятиями в такой архитектуре являются «информационная услуга» и «композитное приложение».
Интеграция при помощи Web-сервисов
Самый современный и быстро развивающийся подход к интеграции приложений. Он основан на обеспечении стандартного для Web-служб интерфейса доступа к приложениям и данным (рис.5.7).
Например, используя стандартный протокол доступа к объектам SOAP (Simple Object Access Protocol), браузер пользователя может сравнить данные на нескольких сайтах и представить клиенту сравнительный отчет. Другой пример — сотрудники территориально распределенного предприятия могут одновременно использовать корпоративные приложения, доступ к которым осуществляется через соответствующие Web-сервисы (портальное решение).
Web-сервисы напоминают подход EAI, но с одним важным отличием — в большинстве случаев EAI-решения разрабатываются как частные для связи конкретных продуктов. Соответственно, подключить к существующему EAI-решению еще одну систему — достаточно трудная и долговременная задача. Web-сервисы существенно более унифицированы и стандартизованы. Поскольку Web-сервисы основаны на общих для W3C-консорциума стандартах, они могут работать всюду, где используется всемирная паутина (WWW). Результаты построения КИС на основе Web-интеграции:
В настоящее время крупные разработчики программных продуктов предлагают консолидированные решения, которые содержат не только конкретные инструменты для разработки и внедрения изначально интегрированных корпоративных приложений, но и реализуют интегрированную среду разработки таких приложений. Примером такого решения может служить программный продукт IBM WebSphere (рис. 5.8).