Человек месяца

Круглый стол “Стратегия электронного взаимодействия”

В конце осени прошлого года представительство Oracle в России провело эксклюзивный круглый стол “Стратегии электронного взаимодействия” (/ru/events/archive/report_omef2003.html). В этом мероприятии участвовали представители 30 клиентов и партнеров Oracle, которым старший вице-президент Oracle по региону EMEA Питер Перрегаард рассказал о современных тенденциях развития интеграционных технологий в Европе. Российский опыт Oracle по стратегиям электронного взаимодействия представил директор по техническому консалтингу Oracle в странах СНГ Глеб Ладыженский. Заказчики Oracle из различных отраслей обменялись опытом и знаниями в области стратегий электронного взаимодействия и интеграции информационных ресурсов компании.

В этом выпуске “Oracle Magazine/Русское Издание” приводятся:

• выдержки из вступительной презентации Г. Ладыженского и
• выступление П.Перрегаарда, старшего вице-президента Oracle по региону EMEA, в ходе состоявшейся дискуссии.

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

Г. Ладыженский,
директор по техническому консалтингу
Oracle Россия и СНГ

“Стратегия электронного взаимодействия”

Прежде всего, необходимо сказать, почему тема “Стратегия электронного взаимодействия” выдвинулась на первый план в нашей работе и стала темой сегодняшнего дня. Дело в том, что служба технического консалтинга представительства Oracle в России и странах СНГ принимает участие в разработке и реализации масштабных проектов корпоративных информационных систем как напрямую, так и совместно с нашими партнерами. Примерно год назад мы заметили пристальное внимание наших заказчиков и партнеров к решению задач электронного взаимодействия. Это внимание было вызвано не конъюнктурными соображениями. Оно шло от реальных проблем, с которыми сталкивались технические службы заказчиков в их повседневной работе. То есть, не мы сами выдвинули эту тему на первый план, ее приоритетность - следствие реальных процессов интеграции, которые стали востребованы в больших проектах.

Сначала нужно договориться о терминах. Термин “интеграция” крайне семантически перегружен и, хотя в оригинале именно integration (интеграция). С содержательной же точки зрения более правильно использовать термин “взаимодействие” (interaction). Именно по этой причине мы назвали наш круглый стол “Стратегии электронного взаимодействия”. Разработка стратегии предполагает предварительный анализ предметной области, поскольку самая стратегия будет существенно зависеть от категории и масштаба решаемой задачи.

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

• Класс A: организация взаимодействия прикладных программных систем, работающих в рамках организации: государственной структуры или бизнес-корпорации;
• Класс B: обеспечение взаимодействия информационных систем различных (двух или более) ведомств или корпораций, федеральных или муниципальных структур.

И если интеграция бизнесов на российском рынке происходит далеко не такими высокими темпами, как в США или Европе, то задача взаимодействия информационных систем государственных структур приобрела в последнее время наивысший приоритет. Более того, наиболее успешные в деле автоматизации российские ведомства (МНС РФ, ГТК РФ) перешли к практическому решению этого класса задач. При выборе методологии, технологии и платформы электронного взаимодействия в конкретном проекте необходимо обязательно иметь в виду, к какому классу относится решаемая задача. Кстати, в одной и той же организации могут решаться параллельно задачи обоих классов.

Интеграция в рамках одной организации (задачи класса A) вызвана традиционным подходом к автоматизации, когда для каждого департамента, исходя из его важности, влияния и финансовых возможностей, приобретались готовые или разрабатывались собственными силами программные системы. Нужно учитывать, что каждая программная система опирается на собственную модель данных, модель процессов и построена на технологическом стеке (набор средств базового ПО). Неоднородность технологического стека как раз и порождает проблемы интеграции. Добавим, что обособленность прикладных систем часто получалась вследствие укрупнения и слияния организаций.

Коротко перечисляя традиционные решения проблем интеграции:

• передача данных посредством файлов;
• разработка программ интеграции “точка-точка”;
• интеграция баз данных посредством шлюзов (transparent gateways);
• выравнивание технологических стеков (миграция унаследованных баз данных в стандартные),

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

Также коротко перечисляя новые подходы к интеграции:

• передача данных посредством сообщений (Message Oriented Middleware - MOM);
• технология интеграции корпоративных приложений (Enterprise Application Integration – EAI);
• технология Web-сервисов;
• интеграция при разработке промышленного ПО:
• интегрированный набор корпоративных приложений (ERP, CRM, SCM) Oracle E-Business Suite;
• консолидация (однородный технологический стек):
• консолидация серверов и баз данных;
• технология распределенной обработки данных (GRID Computing),

нельзя сказать, что перечисленные подходы в принципе являются новыми. Новы они для индустрии информационных технологий в нашей стране, просто в своем развитии мы несколько отстаем от развитых стран и пришли к постановке задач электронного взаимодействия только в настоящее время. Помимо тех подходов, которые стали уже фактическим стандартом – это ориентация на передачу данных посредством сообщений, технологии интеграции корпоративных приложений и Web-сервисов, существуют и развиваются подходы, о которых, возможно, известно меньше. Например, вместо того, чтобы интегрировать унаследованные разрозненные системы, можно отказаться от их использования и перейти к применению интегрированного набора корпоративных приложений. Ввиду того, что разработчик корпоративного ПО (то есть, компания Oracle) уже выполнил интеграцию ERP, CRM, SCM-приложений, то заказчику нет необходимости тратить на интеграцию стандартных приложений время и деньги. Что остается в таких проектах – это интеграция Oracle E-Business Suite с другими системами (либо с сохраненными унаследованными, либо с приложениями других производителей – SAP, Siebel, PeopleSoft и другими). Нетрудно видеть, что есть более изощренные способы решения проблемы обособленных прикладных программных систем. Так, ее разрешения можно добиться и на пути консолидации, когда базы данных нескольких прикладных систем консолидируются на одном сервере, либо когда базы данных этих прикладных систем сводятся в одну. Так было сделано в проекте ГАС “Выборы”, где базы данных 10 прикладных систем были объединены в одну базу данных Oracle.

Для выработки стратегии интеграции приложений полезно рассмотреть эволюцию технологий и средств интеграции. Мы видим три этапа эволюции:

• первый был связан с интеграцией баз данных. Спектр средств интеграции хорошо известен. Это - прозрачные шлюзы, механизмы репликации, шлюзы к системам передачи сообщений. Все эти механизмы по большей части не требовали программирования и сводились к действиям, которые выполнял администратор баз данных;
• по мере роста сложностей и возможностей в дело вступал разработчик, который программировал взаимодействие приложений (очень часто по типу взаимодействия “точка-точка”) – и здесь были задействованы технология Java, ПО промежуточного слоя и, в последнее время – Web-сервисы.
• однако реально обеспечением взаимодействия приложений должен заниматься проектировщик, и ориентирован он должен быть не на программирование, а на процессы взаимодействия.

Организация федерального уровня имеет распределенную структуру, охватывающую все территориальные единицы Российской Федерации. На каждом уровне работает подразделение организации, работающее с данными и хранящее данные в базе данных. Задача поставлена таким образом, чтобы построить транспортную среду, обеспечивающую передачу данных между базами данных подразделений различных уровней. Предположим, что проектируемая система будет иметь однородную структуру, то есть на всех ее уровнях используется СУБД Oracle в различных редакциях – стандартной и корпоративной (центр). Standard Edition One – это недорогая редакция Oracle Database для использования исключительно на однопроцессорных компьютерах. В этом случае нет необходимости резервировать бюджет и приобретать отдельно ПО промежуточного слоя – скажем, TIBCO или IBM MQ Series. Дело в том, что в состав Oracle Database (лицензионно и технически) включено ПО промежуточного слоя Advanced Queuing, позволяющее передавать сообщения с данными между БД Oracle, используя хранимые (в той же базе данных) очереди сообщений. Вывод: однородная инфраструктура позволяет напрямую сэкономить средства.

Если говорить о моделях взаимодействия, то их существует несколько, и опираются они на различные принципы. Рассмотрим одну из простых моделей, которая, кстати, используется в качестве базовой в технологиях Oracle. Она называется “Hub and Sopke” – дословно “ступица и спицы”.

Основу любого взаимодействия составляет единый взгляд на данные. Каждая прикладная система имеет свое собственное представление данных. Говоря образно, каждая прикладная система – это особый закрытый мир со своим представлением данных. Чтобы открыть его для внешнего мира, необходимо во внешнем мире построить некоторое представление данных, которое послужит “общим знаменателем” и для других приложений. То есть, для организации взаимодействия необходимо создать общее представление данных; далее в процессе взаимодействия будут выполняться преобразования представления данных в общее представление и наоборот.

Объясним на простом примере, как происходит взаимодействие.

Например, на каком-то этапе работы CRM-приложения выполняется функция Create Customer (создать запись о заказчике). Естественно, что сформированная запись попадает в базу данных CRM-приложения и вызывает соответствующее событие Create Customer. Но эта запись должна обязательно попасть и в ERP-приложение (для этого ранее было указано, что ERP- приложение подписано на событие Create Customer). Адаптер 1 “отлавливает” событие Create Customer в базе данных CRM. Согласно спроектированному процессу, Адаптер 1 формирует запись о новом заказчике и приводит его к общему представлению; формирует JMS-сообщение с телом в виде XML-документа, который содержит запись о новом заказчике и, через очередь сообщений передает сообщение адресату. Адаптер 2 распаковывает JMS-сообщение, выполняет обратные преобразования (из общего представления в представление ERP-приложения) и заносит запись о новом заказчике в базу данных ERP. При этом все данные о необходимых преобразованиях суть метаданные, которые хранятся в базе данных интеграционного сервера.

Проектирование процессов взаимодействия выполняется специальным средством – iStudio, позволяющем определить (и сохранить в репозитории) описание всех объектов взаимодействия – приложений, принимающих участие во взаимодействии, планируемых событий в каждой из систем, форматов сообщений.

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

При построении продукта Oracle9i Application Server Integration использовалась модель централизованного сервера интеграции “Hub and Spoke”, подразумевающая следующее:

1. в интеграционном процессе могут участвовать любые информационные системы, доступ к которым возможен программным способом; они обмениваются данными по мере возникновения событий;
2. порция обмена данными, сообщение – это информация в формате XML; низкоуровневые детали взаимодействия с конкретной информационной системой локализованы в специальном программном коде (адаптере); с продуктом поставляются адаптеры для СУБД Oracle9i, наиболее известных пакетов автоматизации бизнеса, таких как Oracle E-Business Suite, SAP R/3, адаптеры для связи по стандартным протоколам (ftp, http, smtp) и набор разработчика заказных адаптеров;
3. через адаптеры сообщения поступают в очередь; в качестве среды передачи, накопления и маршрутизации сообщений используется Oracle9i Advanced Queueing; переданные данные приводятся к единой информационной модели Common View;
4. информация о том или ином событии в конкретной ИС может интересовать несколько других информационных систем; для регистрации перекрестных информационных зависимостей и правильной маршрутизации сообщений используется модель публикации и подписки (publish-subscribe);
5. полученные сообщения могут порождать сложные процессы обработки данных; за алгоритмизацию и управление процессами отвечает компонент Oracle9i Workflow;
6. сообщения, перенаправленные в другие информационные системы, проходят соответствующие адаптеры и достигают конечной цели;
7. все процессы, происходящие в интеграционном сервере, оставляют свои следы в журналах; текущее состояние концентратора, а также детали прошедших операций, просматриваются в средстве управления Oracle9i Enterprise Manager.

Миграция к версии Oracle10G позволяет получить уникальное качество ваших прикладных систем – способность работать в сети распределенной обработки данных организации. Таким образом, сделав инфраструктуру однородной, мы смогли решить задачу интеграции прикладных систем – и весьма экономным способом.

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

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

Далее следуют:

• оценка и выбор технологии, адекватной классифицированной выше задаче;

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

Заканчивая выступление, надо сказать несколько слов об организации взаимодействия информационных систем федеральных, региональных и муниципальных структур. Этот класс задач становится в настоящий момент для Российской Федерации особенно актуальным. Последние технологические достижения ведущих производителей программного обеспечения - компаний IBM, Microsoft, Oracle – по созданию совместно поддерживаемых стандартов – UDDI, SOAP, WSDL - позволяют говорить о том, что в настоящий момент мы технологически готовы к организации электронного взаимодействия между ведомствами. Организационной основой служат процессы и регламенты взаимодействия; имеются международные технологические стандарты (XML, Java, UDDI, SOAP, WSDL, WS-I,…) и стандарты информационного обмена (e-businessXML,…); в качестве технологической платформы - применение Web-сервисов.

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

Из выступлений участников круглого стола “Стратегия электронного взаимодействия”  

П.Перрегаард (старший вице-президент Oracle по региону EMEA) -пер. с англ.

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

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

Ряд выступавших говорил о классах и метаданных, и к нам обращались с просьбой начать обмениваться опытом, который мы наблюдаем в других государственных структурах. Как они подходят к построению так называемых баз метаданных по различным типам данных. И, конечно, одна из проблем, с которыми мы здесь сталкиваемся, состоит в следующем: если вы не найдете способ добиться того, чтобы другие организации сами сочли целесообразным принять участие в создании национальных баз метаданных на XML, сделать это будет очень сложно. Трудно установить в обязательном порядке, как должен выглядеть адрес, и так далее. Поэтому мы видим, что ряд правительств (конкретно я имею в виду правительство Великобритании) вводит стимулы, побуждающие различные организации начать обмениваться информацией. Чтобы эта информация стала активом, который вы сможете продавать. Вот один из путей: вы могли бы платить организации, когда вы фактически проводите поиск и получаете информацию об адресах где-то в центральном правительстве. Кому нужна информация об адресах? Всем предприятиям. Создайте рынок, при котором центральным организациям будет экономически выгодно предоставлять эту информацию предприятиям. Я уверен, что органы власти должны играть ключевую роль в создании такой инфраструктуры. В любом обществе правительство – главный пользователь и главный покупатель информационных технологий. И я совершенно искренне считаю, что вы можете использовать эту силу для того, чтобы обязать поставщиков соблюдать те стандарты, которые вы решите внедрить.

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

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

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

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

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

Г.Ладыженский: Большое спасибо, Питер. Я надеюсь, что это не последний Ваш визит в Москву.