https://www.ibm.com/developerworks/ru/library/ws-jcajms/index.html
Интеграция приложений предприятия[1] (Enterprise Application Integration, EAI) — это технологии и приложения, задача которых - вовлечь несколько приложений, используемых в одной организации, в единый процесс и осуществлять преобразование форматов данных между ними.
Необходимость в интеграции приложений обычно возникает, если информационные системы разработаны различными производителями. А также если количество информационных систем достаточно велико, так что осуществлять интеграцию между каждой парой из них ресурсозатратно.
Интеграция приложений предприятия (Enterprise Application Integration, EAI) — это процесс налаживания связей между различными приложениями для поддержки потоков информации между организационными или функциональными единицами и их информационными системами. Интеграция между предприятиями особенно важна при создании сообществ сотрудничающих в нескольких областях партнеров. Отношения с партнерами надо укреплять, чтобы улучшать качество, снижать издержки, повышать оперативность реакции и в целом увеличивать свое присутствие на глобальном рынке. В условиях Интернет-экономики ключом к успеху становится разрушение границ между компаниями, или даже интеграция на уровне внутренней логистики и финансов в цепочке поставщиков и покупателей. Это ведет к увеличению прибыли от инвестиций в такие системы.
Полная интеграция с большим количеством систем, баз данных и протоколов традиционно достигалась с помощью интерфейсов, которые за последнее время эволюционировали и стали средой, известной как Интеграция приложений предприятия (EAI). Эта новая среда использует стандарты XML и Java для создания мостов между внутренними и внешними приложениями, порожденными сетью Интернет и электронной коммерцией.
Точечный подход — создание отдельных интерфейсов для двух конкретных приложений — непростительно дорог, потому что таких интерфейсов понадобились бы десятки, если не сотни. Среды EAI используют альтернативный подход — создание «брокера» информации, который служит посредником между всеми системами, которые загружают свои данные в EAI, одновременно конвертируя данные в единые форматы и протоколы брокера, что значительно облегчает коммуникацию. При разработке будущих систем необходимо всего лишь предусмотреть соответствующий адаптер для подключения к брокеру, в результате чего система сможет обмениваться данными с любыми другими системами. Обмен данных через EAI управляется правилами бизнес-процесса, которые задаются пользователем, а брокер маршрутизирует данные в соответствии с этими правилами, попутно конвертируя их в необходимый для загрузки в конечную систему формат.
Сочетание SAP и EAI является идеальной средой для компании, следующей последним тенденциям в направлении электронного бизнеса и применении обращенных к потребителю приложений. В частности, это обусловлено дороговизной адаптации всех ключевых приложений компании (включая системы SAP) к сети Интернет. Однако в некоторых ситуациях компания может быть просто вынуждена использовать ключевые системы в сети Интернет посредством браузера и пользовательских Web-интерфейсов.
Интеграция В2В является средством создания сплоченных бизнес-сообществ, которые действуют с гибкостью и скоростью единой организации. Только EAI может обеспечить запускаемые потребителем в реальном времени транзакции среди нескольких компаний, координирующих свои действия с целью максимального удовлетворения требований потребителя. Компания SAP тесно сотрудничает с ведущими разработчиками EAI-технологий и ЕАI-продуктов.
В соответствии с определением, приведенным на авторитетном ресурсе ITtoolbox, EAI - это сложная и многогранная технология, которая охватывает все уровни корпоративной системы - ее архитектуру, аппаратное и программное обеспечение и процессы. EAI означает проведение интеграции на следующих уровнях:
Интеграция бизнес-процессов (Business Process Integration, сокр. BPI)
При интеграции бизнес-процессов компания должна определять, реализовывать и управлять процессами обмена корпоративной информацией между различными бизнес-системами. Благодаря этому организация может упростить операции, сократить расходы и улучшить реагирование на запросы клиентов. Элементы включают управление процессами, моделирование процессов и технологический процесс, который охватывает различные задачи, процедуры, архитектуры, требуемую входную и выходную информацию, а также средства, необходимые для каждого шага в бизнес-процессе.
Интеграция приложений (Application Integration)
На этом уровне интеграции целью является объединение данных или функции одного приложения с другим, благодаря чему обеспечивается интеграция, близкая к реальному времени. Интеграция приложений используется - и это далеко не полный список - для интеграции B2B, внедрения CRM-систем, которые интегрированы с корпоративными серверными приложениями, web-интеграции и построения web-сайтов, которые поддерживают многочисленные бизнес системы. Кроме того, может потребоваться проведение специальной интеграции, особенно когда требуется интегрировать существующее приложение с вновь устанавливаемым ERP-приложением.
Интеграция данных (Data Integration)
Залогом успешной интеграции приложений и бизнес-процессов является интеграция данных и систем баз данных. Прежде чем приступать к интеграции, необходимо идентифицировать (определить местонахождение) и каталогизировать данные, построить модель данных. По завершении этих трех шагов данные можно совместно использовать/распространять в системах баз данных.
Стандарты интеграции (Standards of Integration)
Для обеспечения интеграции данных необходимо выбрать стандартные форматы для данных. Стандартами интеграции являются те форматы, которые поддерживают использование и распространение информации и бизнес данных, т.е. стандарты являются основой для проведения интеграции корпоративных приложений. К ним относятся COM+/DCOM, CORBA, EDI, JavaRMI и XML.
Интеграция платформ (Platform Integration)
Чтобы завершить интеграцию систем - базовой архитектуры, аппаратного и программного обеспечения - необходимо интегрировать разнесенные части гетерогенной сети. Интеграция платформ касается процессов и инструментов, с помощью которых эти системы могут осуществлять безопасный и оптимальный обмен информацией. В результате, данные могут беспрепятственно передаваться по различным приложениям. Например, определение того, как нужно надежно передавать информацию с NT- на UNIX-машину, является чрезвычайно непростой задачей по интеграции всей корпоративной системы.
Типичная информационная среда предприятия - это несколько программ, разрабатывавшихся в разное время разными разработчиками на разных платформах в соответствии с тем пониманием бизнес-процессов, которое существовало в соответствующее разработке время. Часть из них обычно бывает разработана внутри предприятия, часть - приобретена как тиражный продукт, однако все они обычно задействованы и их функционирование критично для предприятия.
Проблема заключается в том, что эти приложения - отдельные технологические островки, независимые друг от друга - с отдельными, часто несопоставимыми данными "об одном и том же", с отсутствием технической документации и, следовательно, невозможностью развития. Кроме того, такие приложения обычно плохо или вообще не связаны друг с другом.
Обычная история развития информационных систем в компании состоит в компьютеризации отдельных критических участков бизнеса по принципу "гаси, где горит". Поскольку отдачу от проекта автоматизации до его внедрения точно просчитать невозможно, а более простое решение обходится дешевле, то на ранних этапах развития компании предпочтение часто отдается простым "кусочным" решениям. В итоге получается 2-3 ни технически, ни организационно не связанные друг с другом программы. До определенного момента развития компании и бизнес-среды вокруг нее такой подход оправдан и дает неплохие результаты.
Но с ростом бизнеса, развитием структуры компании, повышением конкурентной борьбы на рынке резко повышается значение полноты, оперативности и разносторонности предоставления информации о деятельности компании в целом. Данные, поступающие из отдельных систем, оказываются несогласованными или даже недоступными в нужное время. Например, если в складской и бухгалтерской системе сотрудники, не договорившись, ввели различающиеся данные об одном и том же заказчике, то задача сбора элементарного отчета по этому заказчику по данным склада и бухгалтерии превращается в задачу, требующую дней, а то и недель кропотливого ручного труда.
Разные программные решения могут накапливаться и в результате слияния, поглощения и реорганизации компаний. Часто такие проблемы возникают при образовании холдингов, в которые объединяются несколько компаний с уже имеющимися информационными системами.
Результатом "лоскутной" информационной среды является низкая эффективность работы ее составляющих, увеличение затрат на поддержку, эксплуатацию и развитие, невозможность обеспечить требуемую информационно-учетную и аналитическую поддержку бизнес-процессов на должном уровне и в срок и, соответственно, потери в эффективности бизнеса.
При лоскутной автоматизации практически невозможно увидеть реальную картину деятельности предприятия. Следовательно, невозможно и сколько-нибудь обоснованно планировать его деятельность и финансовые результаты.
Вот простой пример: у предприятия, занимающегося перевозками, существуют 2 несвязанные между собой приложения - учет заказов, где фиксируются все полученные заказы на перевозку и работы по ним (ведет Оперативный отдел) и бухгалтерия, где фиксируются все затраты (как наличные, так и безналичные) на выполнение заказов для клиентов, а также доходы от клиентов. Отделы разные, за "одинаковостью" занесения названий клиентов никто не следит, бухгалтерия не классифицирует работы, по которым учитывает затраты и доходы, а в Учете заказов классификация работ есть, но затраты и доходы они узнают из бухгалтерии.
В этом случае ответ на вопросы типа "От каких выполненнных работ для Клиентов мы получили какой доход и какие на них были затраты?" может быть получен только огромными усилиями работников обоих отделов в течение от нескольких часов до нескольких дней (в зависимости от размера компании). Они должны будут формировать отчеты, доступные их системам (Учет заказов - Работы по Клиентам, Бухгалтерия - Клиенты/Затраты/Доходы), далее - догадываться, какой клиент как называется в каком отчете (названия клиентов в обеих программах могут различаться), далее - поднимать документы по затратам и доходам (счета, приходники), чтобы соотнести затраты и доходы из бухгалтерии с совершенными работами из программы Учета заказов.
В результате рутинные вопросы управленческого учета на предприятии отнимают массу оплачиваемого времени сотрудников и не дают руководству информации, необходимой для принятия решений в ситуациях, которые ставит перед ним жизнь. Несмотря то, что вся нужная информация у предприятия есть, получить ответ на требуемый вопрос зачастую невозможно или крайне сложно. Можно сказать, что управлять предприятием в такой ситуации приходится практически "вслепую".
Если бы эти приложения были интегрированы, этой проблемы бы не было. Ответ на подобный вопрос занял бы несколько минут (т.е. время формирования соответствующего отчета).
менно поэтому у руководства компаний все чаще и чаще возникает задача интеграции существующих на предприятии "лоскутных" программных продуктов в единое информационное пространство - Корпоративную Информационную Систему (КИС).
КИС обычно создается для:
осуществления перехода на качественно новый уровень принятия оперативных и стратегических управленческих решений, вследствие наличия полной и оперативной информации о деятельности предприятия;
достижения прозрачности, максимальной контролируемости и управляемости деятельностью компании для владельцев и топ-менеджеров предприятия;
увеличения реальных доходов компании в результате наведения порядка в операциях учета и контроля за финансовыми и материальными потоками (например, выставлении счетов и контроля за дебиторской задолженностью);
сокращения времени между произведением работ и выставления счетов клиентам, а также контроля сроков оплаты этих счетов;
снижения финансовых потерь из-за ошибок в оплате счетов от подрядчиков и поставщиков, а также из-за выплат штрафов и договорных санкций вследствие отсутствия контроля за работой сотрудников;
возможности ведения качественной и подробной аналитики, позволяющей определять наиболее выгодные направления развития бизнеса.
При этом подход к созданию КИС, основанный на интеграции приложений, позволяет:
сохранить ранее сделанные инвестиции;
сократить временные и финансовые затраты на поддержку и развитие информационного пространства компании;
использовать для решения конкретных задач наиболее эффективные системы отдельных производителей;
легко расширять и развивать отдельные возможности существующих информационных систем с уже накопленными в них данными.
КИС дает Вам (в любой необходимый Вам момент) адекватную картину Вашего бизнеса, а с помощью подхода интеграции существующих приложений вы получаете ее с наименьшими затратами.
Варианты реализации
Интеграция "каждый с каждым"
Это традиционный подход к интеграции систем, заключающийся в создании специализированных интерфейсов обмена данными для каждой пары обменивающихся приложений.
Такой подход хорош для небольшого количества приложений. При большом их числе он практически не работает. Кроме того, он не позволяет строить КАЧЕСТВЕННО НОВЫЕ запросы к ОБЬЕДИНЕННЫМ данным, т.е. КАЧЕСТВЕННОГО выигрыша от объединения данных нет.
Интеграция на уровне пользовательских интерфейсов.
Подход основан на том, что приложения могут использовать друга так же, как их используют люди, а именно (с помощью специальных инструментов) через пользовательский интерфейс (screen scraping). Наиболее распространенный вариант - HTML-scraping, при котором специальный инструмент (например, Composite Application Platform компании CrossWeave), идентифицирует компоненты HTML-документа, полученного в результате работы веб-приложения, и предоставляет эти компоненты для повторного использования и интеграции.
Такой подход может успешно применяться для сравнительно простых Web - приложений, но в последнее время он все больше вытесняется Web- сервисами (см. ниже «Интеграция при помощи WEB-сервисов»)
Интеграция на уровне данных
Один из самых распространенных в настоящее время подходов - создание хранилищ данных (datawarehouses). Подразумевает поддержку данных в специальных хранилищах независимо от бизнес-логики, их породившей. Доступ к хранилищам могут получать различные приложения. При этом подходе очень важное значение принимает наличие хорошо документированной (и редко изменяющейся) модели данных.
Есть у него и свои недостатки, связанные в первую очередь с:
повышенными требованиями (а значит, стоимостью решения) к аппаратному обеспечению серверов хранилища.
необходимостью переделывать существенную (всю работу с БД) часть приложений (следовательно, увеличение стоимости и возможность внесения ошибок).
необходимостью единой схемы данных для разнородных приложений, что существенно ограничивает гибкость и развитие систем.
Интеграция на уровне корпоративных приложений
Интеграция на уровне приложений (EAI, Enterprise Application Integration) подразумевает совместное использование исполняемого кода, а не (в отличие от предыдущего подхода) внутренних данных приложения. Программы разбиваются на компоненты, которые интегрируются с помощью стандартизованных программных интерфейсов и специального связующего ПО.
При таком подходе из этих компонентов создается универсальное программное ядро, которое используют все приложения. Для каждого приложения создается только один интерфейс для связи с этим ядром, что существенно облегчает задачу интеграции. Полученную в результате систему легче поддерживать и расширять. Повторное использование функций в рамках имеющейся среды позволяет значительно снизить время и стоимость разработки приложений.
Кроме того, EAI интегрирует приложения, не внося в них каких-либо модификаций, что гарантирует отсутствие ошибок в их работе.
Недостатком этого подхода является сложность (заранее точно не оцениваемая) и, соответственно, стоимость работ.
Интеграция при помощи Web-сервисов
Самый современный и быстро развивающийся подход к интеграции приложений. Он основан на обеспечении стандартного для Web-служб интерфейса доступа к приложениям и данным. Например, используя стандартный протокол доступа к объектам SOAP (Simple Object Access Protocol), браузер пользователя может сравнить цены на нескольких сайтах и предоставить клиенту сравнительный отчет.
Web-сервисы напоминают подход EAI, но с одним существенным отличием - они существенно более стандартизованы. В большинстве случаев EAI -решения разрабатываются как частные для связи конкретных продуктов. Соответственно, подключить к существующему EAI -решению еще одну систему - большая, трудная и долговременная задача.
Поскольку Web-сервисы основаны на общих для W3C -консорциума стандартах, они могут работать всюду, где есть WWW.
Результаты построения КИС на основе интеграции:
Возможность осуществлять оперативное управление компанией.
Сохранение инвестиций в обучение персонала, имеющиеся системы и оборудование.
Возможность осуществлять планомерное развитие общекорпоративной информационной системы, интегрируя в нее функциональные компоненты, исходя из приоритетов развития бизнеса компании и потребностей функциональных подразделений, т.е. возможность синхронизировать развитие системы с развитием бизнеса.
Возможность при необходимости заменить любой функциональный компонент другим, более соответствующим текущим бизнес-потребностям.
Возможность инвестировать в развитие информационных технологий не сразу, а поэтапно, на каждом этапе соотнося вложенные средства с полученным бизнес-эффектом.
Возможность снижения общей стоимости автоматизированного рабочего места, включая затраты на создание системы, поддержку рабочих мест и обучение пользователей.
Резкое снижение времени сбора информации, необходимой для принятия управленческих и бизнес - решений.
Ликвидация противоречивости данных от различных служб.
Сокращение времени и трудозатрат на ведение учетных операций.
Ведение консолидированного управленческого учета по нескольким филиалам.
Снижение затрат рабочего времени на формирование промежуточных отчетов, на сверку информации между подразделениями.
Универсального способа интеграции приложений, в одинаковой степени удовлетворяющего всем рассмотренным выше критериям, не существует. Ниже перечислены основные стили интеграции приложений, известные на момент написания этой книги.
§ Передача файла. Взаимодействие между приложениями осуществляется с помощью файлов, в которые помещаются общие данные.
Общая база данных. Взаимодействие между приложениями осуществляется с помощью базы данных, в которой сохраняется общая информация.
§ Удаленный вызов процедуры. Взаимодействие между приложениями осуществляется с помощью удаленного вызова процедур, использующихся для выполнения действий или обмена данными.
§ Обмен сообщениями. Взаимодействие между приложениями осуществляется с помощью системы обмена сообщениями, которые используются для обмена данными и выполнения действий.
Как отмечалось ранее, не существует универсального подхода к интеграции приложений, однако существует способ, оптимальный в рамках конкретного интеграционного сценария. Каждый стиль интеграции имеет свои преимущества и недостатки. Интеграционное решение может основываться на использовании нескольких различных стилей.
В организации маршрутов взаимодействия интегрируемых систем выделяется два подхода. Во-первых, это прямое согласование интегрированных систем по принципу «каждая с каждой», или «точка-точка». Во-вторых, это связь через центральный узел; данную подобную звезде архитектуру, как правило, называемую «хаб + спицы». Топология определяет логические пути взаимодействия и передачи данных между интегрированными системами и не зависит от физической архитектуры информационной системы.
Точка-точка
Данный подход предполагает взаимодействие интегрированных систем напрямую. Достоинствами подхода являются отсутствие необходимости в дополнительном программном обеспечении, простота и прозрачность. И все-таки есть и отрицательные стороны. Первое - интегрированные приложения должны обмениваться информацией используя одинаковые методы взаимодействия и форматы вызовов данных. В процессе изменения какого-либо приложения (если оно повлекло за собой изменение интерфейса взаимодействия данного приложения) возникает необходимость видоизменять или хотя бы перенастраивать все интегрированные с ним системы. Второе - в информационной системе предприятия появляется очень много связей, каждую из которых необходимо проверять и поддерживать в работоспособном состоянии. Стоимость сопровождения интегрированной таким способом информационной системы предприятия становится непозволительно высокой если взаимодействующих приложений слишком много. Но в то же время подход «точка-точка» используется достаточно широко. Обычно это происходит в тех случаях, когда при согласовании определенных приложений необходимо передавать многочисленные объемы данных или обеспечивать нормированное время взаимодействия, а также если используемые на предприятии приложения имеют встроенные средства взаимодействия (это часто случается при введении нескольких систем от одного поставщика, а также если в процессе разработки заказных программных систем или внедрении новых к ним изначально предъявляется условие по взаимодействию с уже имеющимися системами). Однако здесь таится опасность так называемой «ползучей» интеграции, которая делает возможной ситуацию, при которой необходимость поменять систему XYZ неожиданно обнаруживает, что сделать этого нельзя, поскольку справочник оргструктуры и сотрудников вашего предприятия, исторически ведущийся в XYZ, каждую ночь реплицируется еще в десяток систем.
Хаб и спицы
Согласованность по принципу «точка-точка» создает в инфраструктуре предприятия чересчур много связей и ставит условием взаимодействие интерфейсов и форматов данных между согласующимися приложениями. Такие отрицательные моменты призвана разрешить архитектура взаимодействия, в которой все приложения непосредственно связаны только с центральным узлом, который решает следующие задачи:
· организация маршрутизации согласованности между объединенными приложениями;
изменение форматов файлов и данных;
· гарантия согласования приложений с использованием различных методов и протоколов взаимодействия.
