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

Одна из самых сложных проблем ИТ кроется в традиционном подходе к инфраструктуре ПО, поддерживающего бизнес-процессы предприятия. Когда организация по мере роста постепенно приобретает новые корпоративные приложения, - это разумный и естественный путь. На сегодня нет единой системы, которая бы покрыла все функциональные потребности. Очевидно, что в результате подобного подхода образуется не единый континент ИТ-среды, а архипелаг, состоящий из различных островков автоматизации. Некоторые из них, заметим, могут быть весьма большими, например островок R/3, однако в целом - это именно архипелаг. Определенную отрицательную роль здесь сыграл и принцип "best of breed", когда компания пытается выбрать "лучший в своем классе" продукт, в результате информационная система имеет лучшие в своих классах, то есть самые удобные островки.

Естественное желание - связать эти островки вместе - и порождает задачи интеграции приложений. Однако опыт показывает, что, несмотря на уверения поставщиков, заставить различные приложения работать совместно весьма и весьма проблематично. Дело в том, что островки приложений очень существенно отличаются друг от друга. Они отличаются моделью данных, заложенных в их основу, технологическим стеком, на котором они построены, и т. д. Но самое существенное - они отличаются моделью реализации процессов. Вследствие всего этого интегрировать их, в том смысле в каком мы бы хотели, так сказать, полностью, пока не удается. Факт состоит в том, что интеграция приложений, для всех организаций, кроме самых маленьких и простых, трудна и сложна. Как правило, интеграция приложений требует углубленного определения задач и сложных технологий. По результатам некоторых исследований, до 60% средств, выделенных на ИТ-проекты компании тратят на интеграцию. Это очень много и в каком-то смысле это результат подхода "best of breed". Конечно же такая стратегия имеет право на существование, но при этом нужно понимать, что обязательно возникнут расходы на последующей интеграции.

Миф о стандартной технологии

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

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

Миф об универсальности веб-сервисов

О веб-сервисах стоит сказать немного отдельно. В отличие от традиционных EAI-технологий которые всегда зависели от одного-двух поставщиков или же разрабатывались для конкретных продуктов, веб-сервисы предоставляют стандартизированные способы работы с интеграцией. Несколько факторов - повсеместное использование Интернет-стандартов, возникновение стандартной индустриальной платформы взаимодействия J2EE и быстрое распространение XML в качестве независимого от платформы формата передачи сообщений - способствуют активному продвижению такого подхода. В 2001-2002 годах лидеры рынка EAI - BEA и IBM - были полны энтузиазма в отношении веб-сервисов. На конференции BEA eWorld 2002 Питер Холдрич, системный архитектор BEA, даже сравнил происходящие сдвиги в сторону веб-сервисов с изменениями понимания вселенной в европейской культуре. По его мнению информационные системы перестают быть "плоскими", и начинает формироваться более сложная картина: на протяжении предыдущего десятилетия транзакция представляла собой простое сообщение между жестко связанными системами, передаваемое в синхронном режиме, то теперь системы становятся слабосвязанными и асинхронными, что гораздо более удобно для бизнес-процессов.

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

Три вида интеграции

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

Информационно-ориентированная интеграция

Информационно-ориентированная интеграция используется в тех случаях, когда необходимо только реплицировать информацию между двумя или больше системами. Опыт проектов, которые мне пришлось наблюдать, показывает, что решение бизнес-задач большинства предприятий лежит именно в этой плоскости. Информационно-ориентированная интеграция менее дорога и сложна, чем другие виды интеграции, потому что информация просто извлекается из исходной системы, преобразовывается, чтобы снять семантические различия, и передается в нужную систему. Технология информационно-ориентированной интеграции включает брокеры сообщений (SeeBeyond и WebMethods), ПО middleware (IBM MQSeries), серверы репликации баз данных и другие технологии, которые имеют дело с распространением информации между двумя или больше системами. Во многом благодаря успеху продуктов, созданных на основе реляционных баз данных и сопутствующих стандартов (таких, как SQL и ODBC), интеграция на уровне данных продолжает господствовать в качестве способа оптимизации взаимосвязей между различными системами.

Именно такая интеграция в основном имеется в виду, когда говорится о традиционных технологиях Enterprise Application Integration (EAI). Сегодня технологии EAI - это зрелые, устоявшиеся технологии, и их удобно использовать. Однако они страдают серьезными ограничениями. Типичной внутренней архитектурой в этом случае является подход, называемый hub and spoke. По сути, он предназначен для того, чтобы перебрасывать большие объемы данных из одной системы в другую, причем делать это с использованием преобразований из модели конкретного приложения в общее представление (common view), затем - в представление конкретного приложения. Таким образом можно перебрасывать данные из CRM в ERP-систему и обратно.

Проблема состоит в том, что очень многие поставщики позиционируют это решение как интеграцию бизнес-процессов. И только потом заказчики выясняют, что существуют более чем серьезные ограничения и по сути никакой интеграции бизнес-процессов в таком подходе нет. Это просто перекачка больших объемов данных, которая может делается с помощью последних технологий, J2EE, XML, но, по сути, тоже самое можно сделать и с помощью передачи файлов. Именно так работает, скажем, BizTalk, активно рекламируемый Microsoft как средство интеграции бизнес-процессов. Интеграция на уровне данных сама по себе не предлагает средств для связи с традиционными приложениями. Архитектура EAI управляется событиями и основана на репозитории, который хранит метаданные. Но события, которые есть в этих системах, закрыты, у них нет программных интерфейсов. Поэтому, например, SCM-система не имеет возможности напрямую вызвать функцию ERP-системы и взять данные через этот программный интерфейс. Кроме того, традиционная архитектура EAI не всегда хорошо работает в реальном времени, что является критически важным для стратегических бизнес-приложений.

Сервисно-ориентированная интеграция

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

Самым популярным способом сервисно-ориентированной интеграции еще недавно были уже ставшие традиционными распределенные объектные стандарты типа CORBA и COM. Продукты, созданные на основе этих технологий, также традиционно относятся к EAI-приложениям. Но сегодня большинство организаций выбирает веб-сервисы (которые, между прочим, совместимы с традиционными стандартами). Основную роль здесь играют серверы приложений (BEA WebLogic и IBM WebSphere). Хотя, в принципе, любой инструмент, который может реализовывать варианты взаимодействия приложений на уровне их функций, вписывается в эту категорию.

В целом, стоит сказать, что технологические основы сервисно-ориентированной интеграции пока еще не столь развиты. Да, веб-сервисы используются в ряде проектов, к ним присматриваются компании, но проектов, в которых интеграция приложений целиком была бы построена на них, в мире очень мало. Доверять этой технологии еще пока весьма сложно. Тем более что применение веб-сервисов для интеграции унаследованных приложений, которые в основном и установлены в компаниях, связано с крайне трудоемкой работой по реинжинирингу этих систем и созданию для них необходимых интерфейсов. Совсем недавно на рынке появилась новая, очень интересная технология, получившая название Enterprise Servise Bus (ESB), которая опирается на SOA и веб-сервисы. Однако она еще очень молода, и продукты на основе ESB пока находятся в стадии разработки и апробации.

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

Процессно-ориентированная интеграция

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

Технология процессно-ориентированной интеграции существует в двух формах: технология процессной интеграции от традиционных EAI-игроков (Mercator и WebMethods) и стоящая особняком технология процессной интеграции от Metastorm и Versata. Технология от EAI-поставщиков более обща и законченна, тогда как технология Metastorm требует значительно более детального исследования приложений, которые интегрируются, и большей доработки.

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

Сначала - задачи

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

Необходимо начать с бизнес-задач и затем искать технологию, которая отвечает этим требованиям. Возможно, вы уже решили, какой тип интеграции вам подойдет, но не спешите. Ошибки здесь случались слишком часто. Опыт показывает, что слишком много организаций применяют решения на веб-сервисах, там, где они не нужны. По оценкам экспертов, лишь в 20% проектов интеграции нужно использовать сервисно-ориентированную интеграцию. В остальных случаях происходит лишь обмен данными. Веб-услуги это всего лишь часть технологий, они выполняют свою работу, однако это не единственный способ интеграции приложений. В общем и целом веб-сервисы и традиционные EAI-технологии являются сторонами единой интеграционной среды. Традиционные EAI-подходы часто оказываются более конкретными, сильносвязанными решениями, а веб-сервисы представляют обобщенный слабосвязанный подход к проблемам интеграции. "Специализированные решения требуют больших усилий разработчиков и поддержки, в то время как обобщенные решения, как правило, оказываются менее эффективными, - считает Чарльз Голдфарб, создатель XML-технологии. - Вы обмениваете общее снижение ресурсов организации - ресурсы, необходимые для разработки конкретного решения, - на снижение ресурсов компьютеров, которые могут работать не столь эффективно". "Если вы работаете с большими объемами и ваши цели четко определены, то, возможно, вам имеет смысл оптимизировать рабочий цикл, создав сильносвязанное специализированное решение, - продолжает Голдфарб. Однако если вам нужна гибкость, то подход использования веб-сервисов может оказаться более ценным".

Прединтегрированные и композитные приложения

Кроме описанных вариантов интеграции приложений, связанных с внедрением тех или иных специализированных систем, существуют и несколько других способов решения проблем интеграции.
Первая - это ориентация на прединтегрированные продукты одного поставщика. Если сравнить приложения с автомобилем, то подход "best of breed" означает, что предприятие выбирает лучшие в мире шасси, двигатель, кузов. Но это еще не означает, что в результате получится лучший автомобиль, так как автомобили изготавливаются в условиях фабричного производства, а не прямо на шоссе. Поэтому мысль о том, что корпоративные приложения тоже должны собираться в условиях фабричного производства, кажется разумной.
Одним из самых активных приверженцев такого подхода является Oracle, как правило, опирающийся на идею создания единой базы данных для различных приложений и интеграции на ее основе. Часть специалистов считает, что движение к прединтегрированным программным коплексам - это путь, который позволяет решить многие из сложностей информационной инфраструктуры. Однако заказчики отнюдь не спешат воспользоваться такой возможностью, понимая, что тем самым они оказываются накрепко привязанными к одному поставщику ПО. Кроме того, еще не один программный комплекс не покрывал всего спектра задач предприятия. И скорее всего - никогда не покроет.
Понятно, что создавать прединтегрированные приложения не так легко. Поэтому дальнейшее обсуждение вопроса, готовы ли корпоративные приложения к полноценной интеграции, привело к новому витку их развития - концепции композитных приложений. По сути, композитные приложения - это те же самые прикладные программные системы, которые однако имеют возможность через унифицированные интерфейсы обращаться к унаследованному базисному функционалу корпопративных приложений. В этом случае, например, система управления логистическими цепочками может строиться именно как композитное приложение: оно обращается к ERP-системе, CRM-системе, другим системам, которые имеются в компании, выстраивая тем самым новый сквозной бизнес-процесс. В этом смысле композитные приложения являются технологическим развитием идей процессно-ориентированной интеграции. Но на новом этапе - хорошо разработанные и каталогизированные программные интерфейсы позволяют на основе обособленных островков композитных приложений построить некоторую единую систему, то есть, решить задачу интеграции.
Однако это отнюдь не настоящее, и таких приложений еще практически нет. Здесь также в лидерах Oracle. Если раньше к E-Business Suite можно было обращаться через интерфейсные таблицы, XML-шлюзы, то буквально недавно Oracle заявил, что фактически открывает прикладные программные интерфейсы. Это превращает E-Business Suite в так называемый integration ready продукт, который в будущем может быть использован для разработки новых композитных приложений. В эту же сторону движется и SAP с xApps. В качестве технологической основы композитных приложений большинство специалистов видит веб-сервисы.
В целом, нам очень повезло - никто из крупных поставщиков корпоративных приложений - ни SAP, ни Oracle, ни MBS - не смог стать монополистом. Это и определило их движение в сторону предоставления возможностей взаимодействия различных приложений. У них просто нет выбора - попытка и далее продвигать политику покупки всех приложений из одних рук и закрытых интерфейсов, очевидно, привела бы к проблемам для этого поставщика. В первую очередь это, а отнюдь не декларируемое стремление к стандартизации, движет ими. Но для заказчиков это, очевидно, выгодно.