что такое интеграция систем

Что такое системная интеграция?

Системная интеграция важна как для общения между предприятиями, так и для внутреннего сотрудничества внутри предприятия. Как провайдер iPaaS, системная интеграция — это то, что мы делаем ежедневно.

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

Общее определение системной интеграции

В очень широком смысле системная интеграция — это процесс соединения различных подсистем (компонентов) в одну большую систему, которая функционирует как единое целое. Что касается программных решений, системная интеграция обычно определяется как процесс объединения различных ИТ-систем, услуг и/или программного обеспечения, чтобы все они могли функционально работать вместе.

Какова роль системного интегратора?

В широком смысле в мире ИТ системный интегратор (SI) рассматривается как компания, специализирующаяся на внедрении, планировании, координации, составлении графиков, тестировании, улучшении и иногда поддержке ИТ-систем. Хорошими примерами системных интеграторов являются, например, Deloitte, IBM, Accenture, TCS и т.д. Они реализуют крупные ИТ-проекты (например, проекты ERP), пытаясь управлять такими проектами и многочисленными вовлеченными поставщиками. Однако с точки зрения системной интеграции роль системного интегратора сужается до обеспечения интеграции данных между различными существующими системами конечного потребителя, определенными в объеме проекта. Это может означать все, что угодно, от простых внутренних двухточечных соединений до очень сложных интеграций «многие ко многим» как внутри компании, так и с третьими сторонами.

Роль системных интеграторов в этом уравнении обычно заключается в разработке, внедрении и тестировании интеграционного решения, но роль системного интегратора может также включать постоянное управление решениями, а также связь с третьими сторонами для установления связи с ними. Однако наиболее важно то, что системный интегратор вносит свой вклад в интеграцию, которой заказчик не хватает внутри компании (или имеет под рукой нехватку доступных внутренних ресурсов). CTI признан одним из лучших системных интеграторов России рейтинга CRN/RE.

Методы системной интеграции

Типичные методы системной интеграции делятся на следующие категории:

Двухточечная интеграция

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

Вертикальная интеграция

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

Звездная интеграция

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

Горизонтальная интеграция

При горизонтальной интеграции отдельная подсистема используется в качестве общего уровня интерфейса между всеми подсистемами. Очень часто этот уровень называют Enterprise Service Bus (ESB). Этот метод позволяет каждой подсистеме иметь только один интерфейс для связи со всеми другими подсистемами, подключенными к общему уровню интерфейса (т. Е. С десятью системами есть только десять соединений). Преимущество этого метода также в том, что каждую подсистему можно изменить или даже заменить без необходимости переделывать интерфейсы любых других систем.

Интеграция с общим форматом данных

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

Почему интеграция B2B актуальна как никогда?

Интеграция Business to Business — отнюдь не новая концепция. Некоторые ИТ-компании начали реализовывать проекты интеграции B2B почти 50 лет назад (и, надеюсь, к настоящему времени некоторые из них даже завершили эти проекты…). Интеграция B2B в основном означает интеграцию, автоматизацию и оптимизацию бизнес-процессов, выходящих за рамки межсетевого экрана компании. Хотя эти процессы могут значительно различаться между собой, их объединяет одна общая черта: интеграция таких внешних бизнес-процессов обеспечивает организации устойчивое конкурентное преимущество. Такие преимущества могут включать, например, видимость в реальном времени, улучшенную автоматизацию, оптимизацию запасов и повышенную удовлетворенность клиентов.

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

Хотя интеграция B2B первоначально началась с того, что крупные предприятия обязали методы получения бизнес-информации, она довольно быстро переросла в стандарты электронного обмена данными (EDI), а затем и в другие новые технологии, такие как XML, JSON и т. Д. В настоящее время кажется, что каждый Новое приложение имеет некоторый тип API, который позволяет интегрироваться с таким приложением. Тем не менее, это оставляет задачу фактической интеграции такого API с другими системами, и чаще всего большинство компаний просто не знают, как это сделать.

Проблемы системной интеграции

Типичные причины неудач проекта системной интеграции включают, например:

Постоянные изменения интеграционного ландшафта

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

Отсутствие квалифицированных ресурсов

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

Отсутствие ответственности

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

Интеграция устаревшей системы

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

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

Как iPaaS и платформа гибридной интеграции (HIP) могут помочь преодолеть проблемы интеграции?

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

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

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

Вы хотите узнать больше о HIP? Ознакомьтесь с публикацией «Руководство по платформе гибридной интеграции». Кроме того, ознакомьтесь с публикацией на iPaaS: Всеобъемлющее руководство, чтобы узнать больше об iPaaS.

Источник

Интеграция информационных систем предприятия

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).

Источник