Современные тенденции развития

ЛЕКЦИЯ 21

СОВРЕМЕННЫЕ ТЕНДЕНЦИИ РАЗВИТИЯ ИНФОРМА­ЦИОННЫХ СИСТЕМ УПРАВЛЕНИЯ ПРЕДПРИЯТИЕМ.

Предприятие как единый объект автоматизации.

Прежде всего нужно отметить, что ERP – это не класс систем управления (хотя иногда складывается именно такое мнение), а методология организации бизнес-процессов предприятия. Поэтому для российских условий внедрение подобной технологии подразумевает коренные изменения вcей деятельности компании. Важной особенностью проектирования систем управления предприятием на принципах ERP является направленность на планирование ресурсов производства. Вот почему большинство функций учета, реализованных в этих системах, служат лишь дополнением к основной задаче — составлению планов поставок материалов, производства и пр.

Вообще ERP (Enterprise Resource Planning) означает планирование ресурсов предприятия. Чтобы понять, для чего предназначены системы автоматизации, построенные по этому принципу, надо вспомнить историю их развития. В 60—70-х годах ХХ в. был разработан стандарт управления предприятием, получивший название MRP (Material Requirements Planning) — планирование потребностей в материалах для производства. Дальнейшая его эволюция и привела к появлению стандарта ERP. Системы MRP создавались для производственных предприятий и очень редко использовались при планировании материальных потребностей организаций, оказывающих различные услуги Довольно часто составляющей MRP-систем являлась система планирования производственных мощностей CRP (Capacity Requirements Planning) Очевидно, что данный стандарт разрабатывался только как средство оптимизации и учета движения материалов на производстве. При последующем развитии системы был сформирован стандарт MRPII (Manufacturing Resource Planning) — планирование ресурсов предприятия.

Но на этом развитие информационных систем управления предприятием не закончилось. На смену MRPII пришел новый стандарт – тот самый ERP. Однако он ориентирован уже на работу с сетью удаленных производственных и непроизводственных объектов. Обладая всеми перечисленными в MRPII возможностями, ERP-системы включают еще и механизм планирования потребностей при распределенных запасах (DRP-I/DRP-II — Distribution Requirements Planning), позволяющий определить потребность в пополнении запасов в случае территориально распределенных автономных складов. И кроме того, эти системы допускают обновление аппаратной и программной платформы (в отличие от MRP/MRPII).

Последним словом в развитии систем управления предприятием является стандарт CSRP (Customer Synchronized Resource Planning) — планирование ресурсов во взаимодействии с покупателем. Иногда в литературе этот стандарт называют ERPII. Его отличает направленность на потребителя: если раньше построение системы было связано с необходимостью оптимизации внутренних процессов компании, то теперь эта проблема решена, и на первый план выходит структуризация процессов взаимосвязей с внешними субъектами. Подобные системы имеют такие функциональные блоки, как CRM (Customer Relationship Management) — управление взаимодействием с покупателями; SCM (Supply Chain Management) — управление цепочками поставок, логистика; BI (Business Intelligence) — поддержка принятия решений и KM (Knowledge Management) — управление знаниями.

Нельзя не сказать несколько слов о САПР (Системах автоматизированного проектирования), без которых не могло обойтись ни одно промышленное предприятие, чья продукция требует конструкторской документации. Современные технологии САПР для предприятий представлены системами CAD/CAM/CAE/PDM (Сomputer Aided Design, Manufacturing, Engineering, Product Data Management). Эти системы позволяют обойтись без "бумажной" документации, осуществляя прямую связь между процессами разработки изделия и его производства, что позволяет повысить качество продукции и сократить период разработки.

Постепенно между MRP II и ERP образовалась промежуточная группа систем, называемая MES (Manufacturing Execution Systems). Она возникла вследствие обособления задач, не относящихся ни к одной из ранее определенных групп. К системам MES принято относить приложения, отвечающие:

• за управление производственными и людскими ресурсами в рамках технологического процесса,
• планирование и контроль последовательности операций технологического процесса,
• управление качеством продукции,
• хранение исходных материалов и произведенной продукции по технологическим подразделениям,
• техническое обслуживание производственного оборудования,
• связь систем ERP и SCADA/DCS.

Рекомендуемые материалы

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

Второй путь возникновения систем MES — снизу, от АСУТП. Так произошло отделение тактических задач оперативного управления технологическими процессами от стратегических задач ведения процесса в целом. В частности, в химической, металлургической, пищевой и некоторых других отраслях промышленности можно выделить задачи управления технологическими последовательностями (batch control). Их суть — в обеспечении выпуска продукции в нужном объеме с заданными технологическими характеристиками при наличии возможности перехода на новый вид продукции. Отделились и задачи ведения архива значений технологических переменных с возможностью восстановления производственных ситуаций прошедших периодов и анализа нештатных ситуаций. Появились программы обучения технологического персонала и оптимизации ведения технологических процессов.

На пути к интеграции

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

Прежде всего напомним, что задачу объединения АСУТП и АСУП условно относят к системам уровня MES. Стремление связать системы типа SCADA/DCS с системами верхнего уровня ERP/MRP II существовало всегда. Каковы же условия этой задачи? Если проанализировать все требования, выдвигаемые пользователями и разработчиками систем управления предприятием, то можно выделить два основных:

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

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

Стандартизация

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

Еще один нюанс — период обновления программных продуктов в промышленности намного больше. Здесь пока нет своего аналога Microsoft, который диктовал бы такой стремительный темп развития. Однако, несмотря на очевидные подводные камни, положительный опыт стандартизации офисных пакетов неизбежно открывает путь введения стандартов на разработку промышленных приложений. Под этим не следует понимать переход к использованию одной операционной системы, базы данных или сетевого протокола, например TCP/IP, поскольку все это никоим образом не гарантирует возможности обмена данными между промышленными приложениями.

Первым шагом в направлении стандартизации была попытка создать однородные протоколы для связи с производственным оборудованием. Современные решения в области стандартизации связаны прежде всего с фирмой Microsoft. Это в первую очередь технология OPC (OLE for Process Control), т. е. OLE (Object Linking and Embedding) для технологического управления. Она представляет собой стандартный метод для доступа к периферийным устройствам, системам SCADA/MMI или другим промышленным приложениям, основанным на технологиях OLE, COM (Component Object Model) и DCOM (Distributed COM). В общих словах OPC представлена набором стандартных объектов, методов и свойств, отвечающих требованиям промышленных приложений реального времени. Эти требования включают в себя синтаксис для доступа к объектам, эффективную передачу данных от оборудования к приложениям, способность клиента работать с несколькими серверами одновременно и поддержку конфигурации сервера. Программные пакеты на основе OPC легко интегрировать в бизнес-приложения, поддерживающие OLE.

Первая версия OPC вышла в 1995 г. Она не претендовала на стандарт, но была призвана сыгратьроль пробного камня для всех заинтересованных сторон. Основной упор был сделан на сбор данных. Более сложные задачи: сигнализация (оповещение о наступлении технологических событий), отслеживание трендов (последовательностей значений параметров, отражающих поведение технологического процесса), моделирование — отложены на будущее. К сожалению, набор продуктов, разработанных по новому стандарту, весьма и весьма ограничен. Сегодня судьба OPC — в руках производителей промышленных приложений. Последний "хит" от Microsoft в этой области анонсирован в сентябре 1997 г. Имя ему — Windows DNA (Windows Distributed interNet Applications Architecture). Эта архитектура также основана на объектно-ориентированной COM-технологии создания функциональных пользовательских компонентов. Новая идея — разработка спецификаций по отдельным отраслям и сегментам промышленности (Vertical Industry Specifications) — не лишена логики и позволит сконцентрироваться на нескольких областях производства, где наиболее популярны программные продукты, поддерживающие COM. Это можно расценивать как признание поражения всех попыток выработать общий промышленный стандарт.

Таким образом, похоже, что будущее стандартизации — в руках Microsoft.

Связующее ПО

После неудачи General Motors на пути стандартизации для решения задачи интеграции был создан консорциум, в который вошли крупные автомобильные производители (Renault, Mercedes-Benz и др.), представители авиационной промышленности и некоторые фирмы бытовой электроники (Bosch, Siemens Automation и др.). Он получил название AIT (Advanced Information Technology). С его помощью была разработана интеграционная платформа CCE (Common Computing Environment). Данная среда позволяет приложениям независимо от протоколов, операционных систем, баз данных и методов доступа общаться друг с другом. Развитие этой идеи привело к возникновению архитектуры CORBA (Common Object Request Broker Architecture), также одобренной консорциумом AIT.

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

Но не все так хорошо, как кажется. Отметим некоторые недостатки внедрения связующего ПО:

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

В процессе исследования вопроса выяснилось, что для многих фирм — поставщиков промышленного оборудования и программных пакетов идея использования связующего ПО все же ближе, чем идея стандартизации. Отделение современного программирования от реалий операционных систем и протоколов, как видимо, неизбежно и очень быстро происходит во всех областях. Трудности реализации успешно преодолеваются с помощью среды межобъектных запросов (Object Request Broker — ORB).

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

Консорциум OMG (Object Management Group), основанный в 1989 г., взял на себя труд разработать теорию объектно-ориентированной технологии для развития распределенных компьютерных систем. Основное направление деятельности консорциума можно сформулировать так: развитие общей архитектурной платформы для объектно-ориентированных приложений на основе открытых спецификаций. Его девиз звучал бы, наверное, более патетически: "Архитектура для объединения мира".

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

Версия 1.1 спецификации CORBA была выпущена OMG в 1991 г. В ней были определены язык описания интерфейса (Interface Definition Language — IDL) и интерфейсы прикладного программирования (Application Programming Interfaces — API), сделавшие доступным взаимодействие клиент—объект в среде ORB. Суть модели в следующем. Клиент запрашивает сервисы у объекта (который выступает в качестве сервера) через хорошо определенный интерфейс (последний специфицирован в IDL). Для доступа к объекту клиент создает запрос, т. е. сообщение, содержащее информацию о действии, ссылку на сервис, параметры.

Спецификация CORBA 2.0, "родившаяся" в декабре 1994 г., определила информационный обмен между приложениями различных фирм. Она добавила к уже освоенным высотам возможность обмениваться данными через Интернет по протоколу IIOP (Internet Inter-ORB Protocol) и платформенную независимость. Ее внедрение позволяет пользоваться преимуществами Интернет без перестройки промышленной системы.

И все-таки архитектура OMG/CORBA более зрелая, чем OPC и тем более Windows DNA. Уже существуют многочисленные ее реализации, применение которых в промышленности делает приложения независимыми от используемых устройств, сетей, операционных систем и компьютеров. Возникают заманчивые перспективы свободного развития приложений, с одной стороны, и общей инфраструктуры — с другой. Правда, если наступит эра всеобщей стандартизации по версии Microsoft, то CORBA останется не у дел. Но, пока она не наступила, CORBA, пожалуй, лучшее решение для объединения в единый комплекс автоматических систем управления различных уровней с учетом того, что некоторые из них устарели, а другие не подчиняются никаким стандартам и предлагают уникальные решения.

Глобальные промышленные серверы

Третий путь — вполне самостоятельное направление, цель которого — удовлетворить в одном "сверхпродукте" или комплексе продуктов одной фирмы-производителя все потребности современного промышленного предприятия — своего рода скатерть-самобранка от автоматизации. Многие фирмы — производители систем SCADA движутся сейчас в этом направлении, и мне кажется, что больше всех здесь преуспела фирма Wonderware, выпустившая продукт FactorySuite. Кроме возможностей систем SCADA, в нем реализованы функции Batch Control, программирование логических контроллеров, ведение проектов, контроль качества продукции и некоторые функции автоматизации административного управления. Фирма Intellution, помимо систем SCADA, предлагает пакет типа Batch Control и пакеты с Интернет-функциями. Список фирм можно продолжить. Но все их предложения еще так далеки от полного комплексного решения задач автоматизации. Трудно представить, чтобы в ближайшее время появилась компания, способная решить все задачи предприятия на современном техническом уровне. Но кто знает?..

EDA — архитектура,управляемая событиями

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

Однако комплект деталей для сборки постоянно расширяется. С появлением средств моделирования бизнес-процессов (business process modeling, BPM) и вве­дением в оборот архитектуры, управ­ляе­мой событиями (event driven architecture, EDA), он наконец приобре­тает черты завершенно­сти. Подходы, реализованные в BPM и, EDA вводят естественный порядок. Они поз­воляют сначала по­строить модель, а затем объединить отдельные фрагменты в единую систему, адаптиро­ванную к усло­виям внешней среды.

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

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

Этой тенденции уделяют большое внимание в ана­литической компании Gartner. Эксперты компании полагают, что в ближайшее время EDA окажется в центре внимания ИТ-отрасли. Кроме того, идеи EDА позволят лучше осознать, что такое архитектура, ори­ентированная па сервис (service oriented architecture, SOA). Совместно SOA и EDA позволят сформировать подходы к предпри­ятию, управ­ляемому в режиме ре­ального времени.

МЕМОРАНДУМ ШУЛЬТЕ

Термин EDA предложил Рой IПульте, аналитик ком­пании Gartner, в опубликованном 9 июля 2003 года отчете с длинным названием «Повышение значимости событий для интеграции приложений. В будущем приложения станут в большей степени управляться событиями, чем современные. Пять движущих сил». Этот документ неожиданно быстро оказался в списке наиболее цитируемых работ по интеграции приложе­ний, а его автор приобрел широкую известность сре­ди специалистов.

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

I. Стратегии бизнеса требуют создания систем, учитываю­щих поток внешних событий. Биз­нес-процессы, подчиненные событиям, — это не просто ускорение или улучшение существующих процессов; такие процессы принципиально отлича­ются от «обычного бизнеса». Важно то, что они орга­нично воспринимаются практикующими менеджера­ми и аналитиками Одно из немаловажных преимуществ заключается в том, что появляется возможность опе­ративно исправлять ошибки, вполне возможные в человеческой деятельности, но способные нарушить традиционные процессы.

II. SOA —промежуточный этап на пути к EDA. Активная миграция в направлении архитектур, ориентированных па сервисы, позволяет проложить путь к адаптации событийных приложений и интеграции, поскольку они реализуются на основе распределенных слабосвязанных компонентов, которые характерны для SОA (можно указать, в частности, на такие свойства, как модульность, ин­капсуляция, документированный интерфейс). Однако Шульте считает, что SOA в большей степени привязана к клиент-серверной архитектуре, а потому SOA и EDA хотя и родственные, взаимодопол­няющие явления, по не разные уровни одной иерархии.   

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

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

Более сложные «событийные» приложения, которые используют контентно-зависимую маршрути­зацию сведении о событиях и средства управления бизнес-процессами, могут быть реализованы спе­циализиро­ванными интеграционными брокерами. Такие инс­трументы появятся не раньше 2006 года.

Самые сложные формы событийных приложений потребуют использования методов обработки сложных событий (complex event processing, СЕР).

IV.       Процесс стандартизации уже начинается. Обще­принятых стандартов для EDA пока не существует, но есть надежда, что они появятся в течение несколь­ких лет. «Ледоколом» эффективной стандартизации в этой сфере может служить достигший зрелости про­цесс стандартизации SOA. Хотя общее представление об архитектуре SOA и ее преимуществах теоретичес­ки было получено еще в начале 90-х годов, потребовалось почти десять лет (в том числе около пяти лет —на выра­ботку стандартов для Web-сервисов), чтобы она обрела зримые черты. Есть основания полагать, что при­знаваемые большинством производителей стандарты на схемы обмена сообщениями в СЕР, как и языки описания событий (event-processing language, ЕРЕ) могут появиться уже в 2007 году.

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

СЛЕДУЮЩАЯ БОЛЬШАЯ ВЕЩЬ

Год спустя после появлении отчета Роя Шульце компа­ния Gartner опубликовала документ, озаглав­ленный «Миссия и будущее интеграции, версия 2» (2.0 The Mission and Future of Integration). В нем событийный подход к проектированию систем назван «следующей большой вещью», только теперь речь идет об архитек­туре бизнеса, а не о системной архитектуре, как сле­довало из отчета Шультс.

В этой работе Gartner содержится ответ на ряд ключевых вопросов. Прежде всего, обсуждается, ка­кое влияние окажут SOA и ЕDA на интеграцию при­ложений и какие изменения привнесут SOA и EDA в практику проектирования средств интеграции при­ложений. Предпосылкой к возникновению этих воп­росов служит изменившаяся роль интеграции при­ложении. Надо признать, интеграция при­ложений в единую систему еще не стала основной задачей раз­работчиков систем. Так, В 1998 году интеграция стимулировалась прежде всего необходимостью внедре­ния систем планирования ресур­сов предприятия, в 2000-м — модой на системы управления отношени­ями с клиентами, наконец, в 2004-м — усилившими­ся в Соединенных Штатах требованиями к контролю над деятельностью предприятий.

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

 Существуют три основных подхода к интегра­ции приложений, два из которых вполне триви­альны, Первый базируется па простом согласовании данных (data consistency). Второй является бо­лее слож­ным,  многоступенчатым процессом (multistep process) и основан на согласованной техно­логической це­почке, состоящей из связанных между собой опера­ций. Оба подхода имеют право на существование, но лишь третий, названный композитными приложени­ями (composite applications), действительно позволя­ет создавать системы, управляемые событиями. При его использовании неза­висимые прило­жения коопе­рируются для выполнения одного бизнес-процесса. Композитные при­ложения можно рассматривать как развитии многоступенчатого процесса, интегрирующего не­сколько уровней цепо­чек.

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

В подходах SOA и EDA много общего, поскольку они представляют собой способы комбинации раз­нообразных программных компонентов в большие распределенные приложения. Однако есть сущест­венное структурное различие, SOA — что двунаправ­ленная коммуникации типа «запрос-ответ», делеги­рующая работу подчиненным процедурам, а в ЕDA используется однонаправлен­ный обмен сообщени­ями. Соответственно, EDA является дополнением, а не заменой SOA. В ка­честве основной технологии при практической реализации SOA и EDA, скорее всего, будет исполь­зо­ваться корпоративная сервисная шина (enterprise service bus, ESB). О том, что это действи­тельно так, можно су­дить по вниманию компаний IBM и Microsoft к данной группе технологий, включаю­щей я себя серверы при­ложений и инструментальные платформы для прило­жений. Анали­тики Gartner предсказывают, что в 2006 году IBM выведет на рынок продукт WebSphere ESB; со своей стороны, Microsoft включит соответствующую технологию Indigo в состав Longhorn, следую­щего по­коления операционных систем Windows в 2006-м или в 2007 году.

СОБЫТИЯ И СЕРВИСЫ — ДВЕ СТОРОНЫ МЕДАЛИ

Часто SOA и EDA различают но трем параметрам — по связанности приложении, режиму обмена сооб­щениями между ними и уровню синхронизации при­ложений.

 Перечислим свойства, характерные для SOA.

Слабая связанность. SOA позволяет разработчикам,  провайдерам и потребителям сервисов взаимо­дейс­твовать вне зависимости от использованных ими тех­нических решений и с минимальным зна­нием друг о друге — достаточно умения идентифицировать и ис­пользовать необходимый сервис.

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

Синхронность. SOA поддерживает синхронный ре­жим сервиса, то есть при отработке запроса обе сто­роны находятся в режиме взаимодействия.

EDA, в первом приближении, отличается по этим показателям иными характеристиками.

Отсутствие связи. В EDА публикатор сообщении не знает, кто является подписчиком, и наоборот. Взаимодействие oграничивается обменом данными, и между отдельными подсистемами не устанав­ливается каких-либо тесных отношений.

Обмен сообщениями в режиме «публикация-подписка». EDА поддерживает отношения «многих со многими», то есть публикатор делает сообщение известным всем входящим в есть, а те, кто подпи­саны на сообщении или авторизованы, могут их получать,

Асинхронность. EDA поддерживает режим, в котором сообщение посылается без ожидания немед­ленной реакции на него. Из перечисленных несовпадений делается вывод, что перед нами — два со­вершенно разных явлении. Но так ли это? Чтобы лучше разобраться в том, что общего между ЕDA и SOA и чем они различаются, вернемся к основополагающим вещам — событиям, серви­сам и архитектуре.

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

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

Архитектура, Согласно стандарту IEEE P1471/D5.3, архитектура программного обеспечения явля­ется основополагающим руководством для построении какой-либо системы, реализованным в виде ее ком­понентов, их отношений между тобой и с внешней средой, а также принципов проектирования и эволю­ции системы

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

SOA КАК ОСНОВА EDA.

События, сервисы и архитектура образуют единое целое. События — это форма проявления жизни, они происходят в реальном мире. Сервисы — один из воз­можных спо­собов (если не единственный) установле­ния взаимодействия между компонентами сложных систем. Наконец, архитектура опреде­ляет, как такие системы строятся.

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

SOA и EDA.

В отчете компании ZapThink, датированным октябрем 2004 года, рассмотрены че­тыре возможных способа реализации SOA: простой обмен сообщениями, «публикация/подписка», марш­рутиза­ция сообщений о событиях и надежный обмен сообщениями. Здесь сервис рассматривается как част­ный случай события.

Первым механизмом реализации SOA стал не­посредственный обмен сообщениями между провайде­ром и потребителем сервисов (replay/request). Предполагается, что потребитель посылает запрос в виде сообщения и ждет ответного сообщения, содер­жащего нужный сервис. Сообщение заказ­чика долж­но содержать обратный адрес и спецификацию же­лаемого действия. Ответное сооб­щение поставщика может содержать желаемые сведения или, к примеру, быть пустым.

Механизм «публикация/подписка » в некото­рых случаях ассоциируют с EDA, хотя он точно так же может быть использован и для создания SОA. Потребитель подписывается па сведения об опреде­лен­ных категориях событии, описывая средствами метаданных интересующие его события. Провай­дер сервисов или промежуточное звено анализирует заяв­ку и передает сведения о событиях подпис­чику.

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

SOA И EDA И ПОДДЕРЖКА СИСТЕМ РЕАЛЬНОГО ВРЕМЕНИ

В апреле 2004 года состоялась Internet-конференция «Сервисы и события — секретные составляю­щие эф­фективного предприятия», организованная аналити­ческой компанией ebizQ. Еe основным итогом стало признание участвовавшими в ней экспертами того факта, что только подходы на ос­нове SOA и ЕDA могут обеспечить предприятиям эффективное ведение биз­неса.

Эти два архитектурных подхода позволят сблизить системы управления бизнесом с требовани­ями ре­ального времени, то есть построить предпри­ятие, работающее в режиме реального времени (real-time enterprise, RTE),

В этом смысле SOA и EDA взаимно дополняют друг друга. Архитектура SOA позволяет легко и быстро со­здавать новые и перестраивать имеющиеся ресурсы в соответствии с меняющимися условиями бизнеса. Архитектура ЕDA, со своей стороны, позволяет авто­матически и без вре­менных задержек инкорпориро­вать данные о происходящих событиях.

 

IBM И EDA

Принятие корпорацией IBM нового технологическо­го направления является если не необходимым, то уж точно достаточным условием для подтверждения его истинности. На появление EDA корпора­ция отве­тила объявлением инициативы IBM Common Event Infrastructure (CEI). В нынешнем виде СЕ1 представля­ет собой модульный набор для обработки событий, реализующий следующие функ­ции;

-транспортировка событий (event transport);

-шина распространения событий (event bus distribution);

-обеспечение жизнеспособности событий (event persistence);

-подписка на события (event subscription);

-модернизация событий (event updates);

-очереди событий (event queries);

-метаданные событий (event metadata).

CEI использует общую базу событий Common Base Event (CBЕ), основанную на системе обмена со­общени­ями, которая имеется в IBM WebSphere, и использует концентратор обмена сообщениями, вы­полненный по технологии ESB. Рассмотрение CEI с большей сте­пенью детализации выходит за рамки данной статьи; эта инициатива упомянута лишь для подтверждения серьезности идеи созда­ния корпо­ративных информа­ционных систем, способных функционировать в со­ответствии с пото­ком внешних событий.

НОВЫЕ ТЕХНОЛОГИИ ИНТЕГРАЦИИ

Новое поколение технологий, унифицирует архитектурные стили EDA вклю­чающие в себя различные стили инфраструктурного (серверы прило­жений, брокеры, очереди) и при­кладного (ERP, CRM и т.п) программного обеспечения.

К первому поколению Web-сервисов относят во мно­гом успешные инициативы, преследовавшие целью открытие существующих систем для внешнего взаи­модействия. Новое поколение Web-сервисов основано па обмене документами, осмысленно спроектирован­ных интерфейсах. В этой «ин­карнации» Web-сервисы обещают стать самой рас­пространенной технологией реализации как сервис-ориентированных, так и управляемых сообщениями систем.

В качестве естественного способа обретения сервис-ориентированных возможностей в стиле брокера многие разработчики используют язык выполнения бизнес-процессов BPEL (Business Process Execution Language). BPEL описывает XML-нотацию, позволяющую представить абстрактную мо­дель бизнес-процесса (явные ин­формационные потоки, связывающие системы) и сooтветствующий этой модели алгоритм. Последний может быть представлен в виде исполняемого Web-сервиса, имею­щею описание интерфейса на языке WSDL, кото­рый тесно связан с BPEL,

BPEL — «язык программирования SOA» — предлагает стандарт­ную альтернативу собственным язы­кам интеграции ус­таревающих брокеров EAI.

Классическая демонстрация возможностей BPEL основана на процессе заказа туристической пу­тевки, включающем в себя бронирование авиабилетов, номера в гостинице и оплату. Сложность за­ключается в опти­мизирующих ограничениях, определяющих необхо­димость минимизации суммар­ной стоимости поездки. Эти ограничения распространяются на стоимость би­летов и мест в гостини­цах, которая мо­жет варьировать­ся, асами билеты (места) на определенные дни —даже оказаться полностью распро­данными. Только после оп­ределении оптимальных дат путешествия и успешного бронирования про­цесс произво­дит оплату по кредит­ной карте, а если это невозможно, отменяет бронь и из­вещает об ошибке. Локаль­ная память, ветвление, циклы и обработка исключений позво­ляют полностью автома­тизировать процесс при помощи ВРEL..Отдельным немаловажным аспектом этого приме­ра является обеспечение такой гибкости инфраструк­туры, которая позволяет добавлять новые интегрируе­мые сер­висы (новые авиали­нии и гостиничные сети), изменять параметры уже ис­пользуемых (например, ад­реса взаимодействия) и удалять сервисы из рассмотре­ния процессом без внесения изменений в его структуру. Предпочтительно, чтобы владельцу процесса (турагенту) во­обще не приходилось само­стоятельно реагировать на каждое изменение на стороне контрагента.

Для поддержки самообслуживания партнеров хоро­шо подходит реестр сервисов на базе стандарта Universal Description, Discovery and Integration (UDD1). Используя этот подход, авиалинии и гости­ницы, с которыми у владельца процесса бронирования установлены дело­вые отношения, получают от него разрешение на автономную публикацию своих сервисов и управление ими в партнерском реестре сервисов турагента. Клиент этих сервисов, процесс бронирования, при обработке запро­сов обращается в реестр для обнаружения доступных сервисов, после чего оперирует ими в оответствии с бизнес-ло­гикой.

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

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

РОССИЙСКАЯ ДЕЙСТВИТЕЛЬНОСТЬ

Сегодня, , ни одна из российских систем автоматизации не отвечает полностью требованиям, предъявляемым к ERP-системам. Дело в том, что стандарт ERP в первую очередь предназначен для планирования и оптимизации деятельности компании: исходя из этих предпосылок и разрабатывается информационный комплекс; отечественные же системы нацелены на фактический учет деятельности. Таким образом, одни описывают организацию «как должно быть», вторые — «как есть». Прежде всего это связано с российской спецификой развития рынка программных продуктов: сам рынок систем автоматизации начал развиваться лишь в 90-х годах ХХ в., и изначально затребованными оказались не системы планирования и управления, а системы материального и финансового учета. Если за рубежом проблема учета уже давно решена и перед предприятиями остро стоят задачи оптимального планирования деятельности как одного из важнейших преимуществ в конкурентной борьбе, в России наблюдается не только вакуум на рынке отечественных систем управления: российские предприятия в большинстве своем «не доросли» до таких решений.

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

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

Решение booklogic основано на продуктах UnilSpace, предназначенных для эксплуатации в удален­ном ре­жиме. «Гостевая» модель позволяет пользователям раз­мещать сервисы в выделенном центре дан­ных, осна­щенном каналами связи, аппаратными средствами и имеющем достаточный обслужи­вающий персонал, ко­торые было бы нецелесообразно воссоздавать каждому из клиентов. Размещен­ные на площадке booklogic ти­повые сервисы обеспечивают предоставление библио­графической и цеповой информации, прием коммер­ческих документов и т. д. На стороне интегрируемых организа­ции оста­ется только клиентская функциональ­ность, которая синхронизирует состояние их внутрен­них инфор­мационных системе состоянием сервисов booklogic.

Центральным элементом booklogic является реестр UDD1, который позволяет приобщить любой сер­вис к общему виртуальному пространству и обеспечива­ет прозрачность сервисов для всех участни­ков. Место физического расположения системы, предоставляю­щей сервис, теряет значение; интерес пред­ставляют лишь факторы доступности и качества обслужива­ния, которые зачастую завися го: на­дежно­сти кана­лов связи.

Сервисы ассоциируются в реестре с соответствую­щими им провайдерами — несмотря па их физиче­ское предоставление из одного центра данных.

Бизнес-сервисы booklogic оформлены в виде BPEL-процессов, исполняемых на площадке. По­скольку собственного механизма обеспечения возможности постоянного храпения объектов данных в ВPEL не пре­дусмотрено, инфраструктура booklogic дополнена плат­формой создания «гостевых» сервисов дан­ных для их преобразования и долгосрочного хранения. Когда речь идет о критичных для бизнеса про­цессах, провайдер сервисов интеграции не может слепо надеяться на ус­пешное вы­полнение удален­ною вызова — тем более в России, где качество каналов связи сильно варьируется,

Прикладные задачи, решаемые book logic при помо­щи SOA и Web-сервисов, выходят далеко за пре­делы пе­редачи коммерческих документов по модели EDI. Уже сейчас сервисы booklogic обеспечи­вают прозрачность складских остатков в магазинах, консолидацию катало­гов и анализ прайс-листов по­ставщиков.

ИНТЕГРАЦИЯ КАК УСЛУГА

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

В этой сфере, помимо уже обсуждавшихся програм­мных решений, все большую популярность обре­тают провайдеры интеграционных сервисов (integration service provider). Они размещают логику диспетчеризации событий в собственной инфраструктуре, доступной по Internet. Таким образом, поль­зователи избавляются от необходимости управлять одной из сложнейших час­тей своей ИТ-ин­фра­структуры.

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

Появление первого поколения провайдеров интег­рационных сервисов было связано с технологией EDI (Electronic Document Interchange). Тогда эти провайде­ры были операторами сетей VAN (Value Added Network), которые обеспечивали доставку коммерческих до­кументов ЕDI еще без инфраструк­туры Internet. Те из них, которые успешно пережили появление internet, конвертируются в полноцен­ных провайдеров интег­рационных сервисов, добавляя в свои решения ряд интеллекту­альных функций. Среди наиболее извес­тных операторов VAN, работающих сегодня на рын­ке инте­грации, можно на­звать компании GXS, Inovis, ClickCommerce и Sterling Commerce. Они активно по­полняют линейки своих предложений, обеспечивае­мых в удаленном режиме, другими решениями — как прикладными,

ЕRP потеряли, a SOBA еще не приобрели

Кандидат на универсальный интерфейс уже объявлен и выглядит: вполне привлекательно. Речь идет о так называе­мой архитектуру, ориентированной на сервисы (service oriented architecture, SOA), и, соответственно, об ориентированных на сервисы биэнез-прилажениях (Service oriented business application, SOВA). С одной, стороны, это естествен­ное развитие Iatemet-решений для бизнеса, с дру­гой рост интереса к, SOA во многом определяется поддержкой ноной идеологии информацион­ных систем крупнейшими игроками ИТ-рынка, такими как IBM, Microsoft и SAР. Вероятно, они ви­дят возможность монополизировать стандарты на огромном потенциальном рынке.

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

     Рассмотрим идею SOBA с точки зрения современной бизнес-практики

Первая проблема, «подкосившая» победный на первый взгляд марш ERP, — отраслевая специ­фика. Дело в том, что МRР II, ставшая основой для первых ЕRР, — это методоло­гия планирования дискретных, большей частью машино­строительных производсв. Но некорректная реклама и отсутст­вие на Запале общедоступного опыта, связанного с разработкой стандартизованных систем планиро­вания производств различных типов, привели к многочислен­ным неудачным попыткам внедрения систем на других производствах, фактически не поддерживаемых плано­вым механизмом MRP П или его близких аналогов.

Постепенно, обучаясь на собственных ошибках и опираясь на опыт клиентов, разработчики создали мно­гочисленные специализированные модели планирова­ния для различных типов производств. Од­нако действи­тельно качественные индустриально-ориентированные системы появились только в на­чале 2000-х годов. Удивительно, но факт, — все эти проблемы были хоро­шо известны  отечествен­ной эконо­мике. Существенная отраслевая специфика в планировании была идентифицирована в на­шей стране еще в 60-е годы, а соот­ветственно, методологии «промфинтехпланирования» разрабаты­вались сугубо для отдельных отраслей. Кроме того, в планировании была хорошо известны про­блемы межот­раслевой кооперации, разрыва между интереса­ми торговли и производства.

Проблема адаптации программного продукта под кон­кретную производственную ситуацию сего­дня еще более обострилась. Повсеместное распространение таких мето­дологий планирования, как заказ­ное, гибкое производс­тво (agile manufacturing), и довольно старой, но реани­мированной идеи «эконо­мичного производства» (lean manufacturing) привело к технологической уникальнос­ти прак­тически каждой произвдственной системы. И уж тем более почти всегда существенным фактором конку­ренто­способности является уникальность системы уп­равления производством.

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

За последние годы процесс переноса лидерами рын­ка своего производства в сграны Индокитая, Ла­тин­ской Америки, Восточной Европы стал массовым.  Пи этом в большинстве случаев осуществля­ется перенос именно на территорию субподрядчиков, то есть третьих фирм, не входящих непосред­ственно в холдинги «производителя». Более того, товар доставляется, распределяется и прода­ется также треть­ими фирмами. Другими словами, в от­личие от ситуации, которая имели место в пору создания ERP, сейчас продукция и финансовые потоки не проходят непосредственно через предпри­ятие, что, однако, не сни­мает с бизнеса задачу координации и управления потока­ми. Естественно, подобная конфигура­ция никак не укладывается в стандартную ERP-систему, работающую только с внутренними данными предпри­ятия.

Для поддержания деятельности и сложных финансовых и производственных холдингов, многоуров­не­вых дистрибьюторских систем, транснациональных корпораций и объединений были разработаны спе­циальные методологии управления товарными потоками. Подходы к таким системам управле­ния были зафиксированы в концепции логистических цепочек (supply chain). Сегодня она явля­ется до­минирующей концепцией управления бизнесом реального сектора. Типичной стала весьма слож­ная кон­фигурация логистической цепочки (рис, 1), Некую совокуп­ность возможных участников логи­стиче­ских цепочек конкретного предприятия можно назвать «логистичес­ким доменом».

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

Практически все участники логистического домена— это третьи фирмы. Соответственно, на голов­ное предпри­ятие возлагается задача координации всей цепочки поста­вок с точки зрения как логи­стиче­ского, так и финансового менеджмента. Но в таком случае стандартная транзакция «развалива­ется». Более того, появляется новые, ранее не­известные функциональные центры, Такие как показан­ный на рис. 2 центр приема заказов. Или вместо бухгалтерии начинает действовать финансовый центр.

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

В за­висимости от конкретной ситуации одинаковая по структуре логическая транзакция (скажем, заказ то­вара на заводе в Китае, доставка на таможенный склад в Финляндии и дистрибу­ция оттуда по Рос­сии) может происходить при участии (посредничестве) различных участии ков домена. А значит, воз­можны различные финансовые схемы, логические процедуры, протокола взаимодействия. В таком контек­сте теряется принципиальная для обычных транзакционных систем взаимосвязь финансового и матери­ального потоков.Критическую роль обретают информационные пото­ки, не связанные напрямую для головной компа­нии ни с финансами, ни с товаром. Так, с точки зрения управления логистической пеночкой крайне важны "Потенциальные» заказы клиентов или информация о новинках рынков сырья, материалов и комплектующих, а также пока труд­нодоступная аналитическая информация (в частности, постоянно актуализируемые данные о динамике спро­са в торговых точках но отдельным товарам и товарным труппам).

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

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

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

Люди также интересуются этой лекцией: Практическое занятие О.

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

Итак, перечисленные проблемы ни поодиночке, ни в совокупности не могут быть решены за счет модерниза­ции «внутренних» систем, которыми являются ERP-системы. Они требуют перехода к «гиб­ким» динамически взаимодействующим системам, компоненты которых опираются на стандарт­ные протоколы взаимодействия и передачи данных. Видимо, поэтому в компании Gartner и посчи­тали, что ERP-системам осталось жить совсем не­много.

Россия, не выбросив на ERP сотни миллионов, а то и миллиарды долларов, сделала очень разумный шаг. Теперь можно будет вложить средства в действительно современные системы, которые могут стать существен­ным стимулом развития бизнеса и ИТ в будущем. Однако необходимо дождаться появления работоспособных ре­шений «в стиле SOBA» и утверждения, хотя бы де-факто, стандартов SOA. К сожалению, опыт интеграции ERP-приложений оказался не то чтобы неудачным, но уж очень непростым. А это, конечно, затруднит внедрение новых идей приложений, ориентированных на сер­вис.

Возвращаясь к аналогии с мэйнфреймами, можно предположить, что мы не сразу получим откры­тую, сво­бодно интегрируемую архитектуру SOA. Скорее всего, на первых порах это будет архитек­тура, ориентирован­ная на интеграцию с некоторым базовым приложением и аналогичная сущест­вующим решениям, скажем, от Microsoft или SAP. Некоторое «материнское» приложе­ние будет иг­рать роль мэйнфрейма, а для взаимодейс­твия с ним будут предоставляться частично стандарти­зо­ванные, или «полуоткрытые», интерфейсы и сервисы. Взаимодействие же между различными мате­ринскими при­ложениями будет по-прежнему представлять про­блему или ограничиваться узкими рамками общепри­нятых стандартов.

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