Все новости от 8 декабря 2003 г.

Когда нужна универсальная платформа EAI?

Современные российские компании все чаще сталкиваются с необходимостью интеграции корпоративных приложений (Enterprise Application Integration, EAI).

Глеб Ладыженский

Одной из фирм, предлагающих полный спектр продуктов для решения этой проблемы, является корпорация Oracle. В середине ноября мы побеседовали об этом с Питером Перрегаардом, cтаршим вице-президентом по технологиям Oracle в регионе ЕМЕА, и Глебом Ладыженским, руководителем отдела технического консалтинга представительства Oracle в России и странах СНГ. Разговор получился интересным и затронул самые злободневные вопросы области EAI -- роль и место серверов приложений, цели интеграционных проектов и методы оценки их рентабельности.

PC Week: Хотелось бы начать с немного философского вопроса, который, однако, часто задается: зачем интегрировать системы, когда можно купить единый пакет управления?

Питер Перрегаард: Конечно, мы бы хотели, чтобы все использовали только Oracle E-Business Suite. Но это -- пакет горизонтальных приложений. Ни его возможностей, ни возможностей SAP R/3 и прочих никогда не хватит для удовлетворения всех потребностей различных компаний.

Питер Перрегаард

Возьмем, к примеру, банк. Здесь нужны средства управления данными по депозитам и сберегательным счетам. Авиакомпании, естественно, нуждаются в пакете для управления бронированием авиабилетов.

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

PC Week: Интересно, а есть ли какие-то российские примеры такой интеграции ERP-системы Oracle с действующей инфраструктурой?

Глеб Ладыженский: Да, конечно, у нас практически любое внедрение Oracle E-Business Suite сопровождается интеграцией его в окружение существующих приложений. И, как правило, необходимо обеспечить интерфейс между приложениями.

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

Можно привести пример страховых компаний, скажем, РОСНО, она была первой компанией со своей системой учета договоров, где проходила интеграция с Oracle E-Business Suite.

Сейчас еще одна страховая компания -- "КапиталЪ Страхование" приняла решение о создании единой корпоративной системы, которая объединит управление компанией и непосредственное ведение страховой деятельности.

Проект предусматривает интеграцию Oracle E-Business Suite с системой TIA, автоматизирующей основные процессы страховой деятельности от продаж до перестрахования и урегулирования убытков и также построенной на платформе Oracle.

PC Week: Когда вы решаете интегрировать системы, то можно идти разными путями. Но, глядя на рынок, мы видим, что вендоры все больше функций по интеграции встраивают в серверы приложений, отказываясь от классических систем MOM (Message Oriented Middleware -- межплатформное ПО, ориентированное на обмен сообщениями). Оправданно ли это?

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

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

PC Week: Но и большинство систем MOM имеет графические инструменты. Кроме того, производители начинают строить системы MOM на базе серверов приложений.

Этим путем идет и Oracle в своих платформах Oracle 9iAS/ 10gAS Integration. Однако по соображениям производительности это не кажется эффективным решением. В чем же тогда дело?

П. П.: Мы возвращаемся к вопросу, что такое интеграция. Понятно, что если вы приобретете специальные выделенные интеграционные инструменты, то они будут работать более эффективно, чем так называемый интеграционный пакет.

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

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

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

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

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

Серверы приложений становятся все более и более важными потому, что они способны охватывать все уровни интеграции.

PC Week: Давайте поговорим об интеграции на базе бизнес-процессов. Если вы ее начинаете, то она, как правило, требует организационных изменений. А их в рамках интеграционного проекта сделать непросто. Не означает ли это, что область ее применения ограничена этими организационными рамками?

П. П.: Нет, я так не думаю. Я не согласен с тем, что потребуются организационные изменения в бизнес-процессах в случае процессно-ориентированной интеграции.

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

PC Week: Обычно люди, начинающие интеграцию на предприятии, хотят решить какую-то простую прикладную задачу: есть два набора записей о клиентах в двух разных приложениях. Требуется сделать так, чтобы они всегда были согласованы.

Или нужно синхронизовать данные в двух территориально распределенных базах. Подобные задачи нельзя было решить на уровне интеграции данных, так как БД спрятаны в приложениях.

И поэтому требуется использовать MOM. Но если вы предлагаете людям глобальное решение, они этого могут не понять. Они размышляют в терминах тех проблем, которые у них есть.

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

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

Г. Л.: Я бы добавил. Дело в том, что MOM -- категория, которая существует уже достаточно давно и используется в ряде случаев для синхронизации данных в системе. Но ее недостаток заключается в том, что для ее внедрения необходим высокий объем программирования.

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

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

PC Week: Но если мы возьмем тот же Oracle Integration, или IBM Business Integration InterСhange Server, или еще какой-нибудь продукт серии Hub And Spoke, то получим концепцию обобщенных бизнес-объектов и графические инструменты -- эти технологии позволяют вести интеграцию уже не программисту, а бизнес-аналитику.

Задача сводится к настройке и преобразованию данных, а не непосредственно к кодированию. Что же касается сервера приложений (который лежит в основе Oracle Integration), то он используется (как кажется) не совсем по назначению.

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

Г. Л.: Просто сервер приложений уже перешел рамки первоначального узкого определения как некого "движка" для поддержки трехуровнего приложения.

По сути, сейчас сервер приложений -- это уже программная платформа, я бы назвал ее mid-tier platform (платформа промежуточного слоя), которая позволяет решать очень многие задачи, в том числе и задачи интеграции.

А J2EE "движок", находящийся в этом серверном приложении, как раз и является ядром для решения подобных задач, в том числе и задач взаимодействия приложений.

Необходима платформа, способная решить достаточно много задач. Именно mid-tier, потому что на уровне обработки данных мы такую платформу имеем в виде реляционных СУБД. Собственно, это ответ на вопрос -- нам необходима инфраструктура программ, т. е. консолидация mid-tier.

PC Week: Если говорить о решении Oracle Integration, то помимо сервера приложений оно опирается еще на СУБД компании. Это, возможно, добавляет надежности и масштабируемости, но накладывает жесткие требования на аппаратное обеспечение. Насколько оправдан такой подход?

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

В результате обеспечивается серьезная экономия на стоимости ПО. Но наиболее выгодная часть grid-вычислений -- это возможность управления вашими данными более разумным способом.

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

PC Week: Следующий мой вопрос касается Web-сервисов. Сейчас эту концепцию активно продвигают все вендоры ПО. Нам обещают, что все будет сделано на Web-сервисах. Но кажется, что у области применения этой технологии есть естественные границы.

Например, еще никому не удавалось сделать корпоративную систему, состоящую из мелких компонентов. Во-первых, очень сложно разорвать связи внутри цельного приложения.

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

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

П. П.: Полностью согласен. Web-службы, конечно, хороши, когда вы запрашиваете какой-то очень узко определенный сервис, который благодаря им можно интегрировать в любой тип приложения.

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

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

PC Week: В продолжение темы интеграции приложений хотелось бы узнать, предлагает ли Oracle какие-либо методики для расчета возврата инвестиций в проект EAI?

П. П.: Да, такие методики есть. Соответствующий инструмент можно найти на нашем сайте в разделе Infrastructure Consolidation. Вы вводите в поля необходимые параметры: сколько у вас СУБД, серверов, приложений. И система подскажет вам, сколько вы можете сэкономить на консолидации инфраструктуры, причем по всем этим направлениям.

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

Следующая составляющая сбережений -- устранение издержек на поддержание системы. Мы применяем самые простые логические правила, например, учитываем, сколько требуется времени на остановку системы для проведения работ по обслуживанию.

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

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

PC Week: То есть подсчет ведется на основе параметра экономии, а не параметра потенциального увеличения дохода? Вы не оцениваете такие вещи, как время, потерянное на непродуктивные операции остального персонала? Выгоду от более эффективного использования информации?

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