Сегодня еще трудно представить себе крупных администраторов (CEO, CFO, CKO, CIO...), сидящими перед специализированными экранами, т.е. примерно так, как выглядят операторы сложных технических систем, например, Центра управления полетами космических аппаратов. Но экран на столе руководителя рано или поздно превратится из атрибута интерьера в инструмент — созданы практически все необходимые условия для появления предприятий, работающих в режиме реального времени.

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

Я попытался писать о родственности кибернетических принципов управления в технике и в организациях еще в 1997 году [1, 2], когда появились возможности включения человека в контур управления в виде первых опытов использования intranet-технологий, но тогда этот взгляд вызвал, если мягко сказать, то скептическое отношение. Прошло пять лет и вот, наконец, на корпоративном горизонте появилось нечто похожее на кибернетическое представление о системе управления, поучившее должное название RTE (Real Time Enterprise), т. е. предприятие, работающее в режиме реального времени. Такое управление основывается на отслеживании процессов событий (managing event-driven business process) и создании соответствующих технологий управлении потоками работ (workflow).

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

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

Вот почему почти все аргументы, приводимые в пользу эффективности действующих информационных систем, более похожи на шаманские камлания. За последние несколько лет подобная пропаганда исчерпала кредит доверия и больше не убеждает тех, кто распоряжается ИТ-бюджетами. Как следствие — потеря темпа в информационной индустрии. Сегодня требуются практические шаги, демонстрирующие эффективность применения компьютерных систем в бизнесе. Это ключевой вопрос для всей отрасли, особенно сейчас, когда почти во всем мире снижается объем инвестиций в ИТ. О том, как концепция RTE меняет отношение с теми, кто принимает решения, как она влияет на возврат инвестиций, можно прочесть в [3].

Так уж повелось в последние годы, что лакмусовой бумажкой для любой новации стало отношение к ней крупнейшей аналитической компании Gartner Group. Вот и сейчас все ждут, что скажет оракул по имени Gartner относительно перспективности RTE. Мнение оказалось сугубо положительным: темы, связанные с RTE, оказались одними из наиболее актуальных на последних симпозиумах, проводимых Gartner в 2002 году, где обсуждаются перспективы информационных технологий на ближайшие годы. По словам вице-президента Gartner Джеми Попкина, сказанным им в октябре, его компания считает RTE одной из ключевых областей для исследования и намеревается посвятить ей ближайшие месяцы. В [4] перечислены аргументы, приводимые Gartner в пользу RTE с точки зрения тех преимуществ, которые дает бизнесу такой подход к построению систем. Они вполне очевидны: это сокращение потерь, повышение конкурентоспособности и повышение эффективности принятия решений.

Примерно то же самое можно было бы отнести и к массе уже известных технологических приемов, поэтому, при всем уважении к Gartner, пока сказанное аналитиками этой компании по проблематике не убеждает, слишком много общих фраз. Гораздо интереснее может оказаться специализированный симпозиум «Создание предприятия, работающего в режиме реального времени», организуемый в декабре компанией DCI (www.dci.com). Любопытно, что среди его основных докладчиков будет легендарный Винод Хостла, идеи которого легли в свое время в основание компании Sun Microsystems. Взгляды Хостла на концепцию RTE изложены в работе Real Time Enterprises, а Continuous Migration Approach, которую можно найти на сайте компании DCI. Сейчас Хостла входит в элиту венчурных капиталистов Кремниевой долины, и к его мнению серьезно прислушиваются. Свои взгляды на роль RTE для современного бизнеса он изложил в меморандуме [5], который можно найти сразу на нескольких сайтах.

RTE и интеграция бизнес-процессов

Беда почти всех современных технологических реформаторов, пытающихся улучшить корпоративные системы, заключается в пренебрежении, а скорее в полном незнании ими более общих теоретических принципов построения систем, в излишней прагматике и сосредоточенности на конкретных практических решениях. Так, при анализе огромного объема западной литературы, связанной с архитектурой корпоративных систем, мне всего один раз встретилось упоминание имени Людвига фон Берталанффи, автора общей теории систем. На таком скудном теоретическом базисе сложилось представление о том, что систему можно представить просто как совокупность компонентов, и зародилось направление, которое называют интеграцией приложений предприятия (enterprise application integration, EAI). Разумеется, система — явление более сложное, чем сумма компонентов, однако в целом EAI можно рассматривать как предтечу RTE. Разработчикам такого рода средств уже понятно, что нужно сделать, но еще не вполне понятно как. В области EAI сложилось несколько направлений.

  • Хорошо известные интеграционные серверы, производимые компаниями SeeBeyond, TIBCO, Vitria и webMethods. Это весьма недешевые механизмы для обмена сообщениями (messaging engine), обеспечивающие высокоскоростной обмен транзакциями и сложную интеграцию. Они обладают богатой функциональностью и представляют собой надежную платформу для объединения корпоративных приложений.
  • Другую, более новую группу образуют интеграционные средства, предназначенные для интеграции бизнес-процессов (business process management integration, BPMi). Согласно своему определению, решения BPMi ориентированы на управление процессами. Наиболее успешно в этом сегменте рынка работают компании Fuego и Staffware.
  • К средствам EAI можно отнести еще и хорошо известные серверы приложений BEA , IBM, iPlanet и другие, но по своей функциональности они уступают перечисленным выше.

С появлением технологий JMS (Java Messaging Service), JCA (Java Connector Architecture) и серверов приложений на основе J2EE (Java 2 Enterprise Edition) стала формироваться технологическая база для RTE. Сегодня еще трудно выстроить строгую и законченную иерархию средств, они развиваются независимыми производителями, напоминая собой отдельные фрагменты общей головоломки, но некоторая систематизация уже возможна. Прежде всего, понятно, что для создания RTE требуется не просто согласованная работа отдельных приложений, создание функциональных описаний на уровне бизнес-процессов.

Если провести аналогию с техническими системами, то средствами описания процессов строится «математическая модель». Пожалуй, наиболее доступные и содержательные работы на тему интеграции бизнес-процессов принадлежат перу Петера Фингера. В частности, в трех выпусках журнала Internet World [6-8] он вместе с соавторами раскрывает основные идеи управления бизнес-процессами. Там показано, что до сих пор в центре внимания были вопросы технической интеграции, описываемые в терминах приложений. Качественно новый подход к интеграции требует совершенного иного типа стратегического программного обеспечения категории Business Process Management System (BPMS). Для создания BPMS существует несколько технологий. Одну из них, язык BPML, развивает общественная организация BPMI.org, есть также язык ebXML BPSS, предлагаемый организацией OASIS, и, наконец, в августе совместно три компании BEA Systems, IBM и Microsoft объявили о создании нового языка BPEL4WS, из названия которого прямо следует его ориентация на Web-службы. Наличие трех несовпадающих между собой подходов обуславливает сложную позиционную борьбу вокруг приятия стандарта Web Service Choreography Interface, предложенного консорциумом W3C в августе 2002 года. WSCI представляет собой язык для описания интерфейсов бизнес-процессов.

Архитектура, ориентированная на сервис

Для существования любой системы необходима соответствующая ей среда, в технических системах подобная среда тривиально проста, это электрические провода, связывающие датчики с котроллерами и исполнительными органами, в природных системах она намного сложнее. При переходе к корпоративным системам, построенным на принципах RTE и стоящим на следующей ступени сложности по отношению к техническим, возникает вопрос, какими свойствами должна обладать среда в данном случае? При поиске ответа на него следует учитывать несколько обстоятельств. С одной стороны, очевидно, что как бы мы не называли систему, в конечном счете, ее компонентами являются отдельные программные приложения, и организация взаимодействия между ними сводится к выбору из нескольких возможных альтернатив обмена данными между программами. Известно пять основных способов межпрограммного взаимодействия [9]:

  • обмен файлами;
  • разделяемый доступ к базам данных;
  • прямой обмен данными (например, по протоколу TCP/IP);
  • удаленный вызов процедур (remote procedure call, RPC);
  • обмен сообщениями (message oriented middleware, MOM).

Опыт показывает, что для создания эффективных и сложных систем в наибольшей степени подходят два последних варианта. Но при взгляде с другой стороны, очевидно, что появившиеся в последнее время технологии, которые принято называть Web-службами, так же привлекательны для создания среды. На основе Web-служб может быть создана соответствующая коммуникационная среда, которую сейчас принято назвать «архитектурой, ориентированной на службы» (service oriented architecture, SOA). Что любопытно, в ней могут быть сразу два подхода — и удаленный вызов процедур, и обмен сообщениями. Эти подходы отличаются, в том числе и тем, что первый является синхронным, а второй асинхронным. Отбросив терминологические «навороты», использованием которых так часто злоупотребляют авторы, описывающие новые информационные средства, скажем, что особенность синхронного метода заключается в том, что он обеспечивается вызовом и последующей передачей данных, а асинхронный отличается наличием документа и передачей его в том или ином виде. Если сравнить способ передачи сообщений посредством свиста, известный издревле жителям гор, с Web-службами, построенными на основе стека протоколов UDDI-WSDL-SOAP, несложно заметить между ними общность. Оба они синхронны. Точно так же сравним передаваемую с оказией берестяную грамоту с документо-центричными Web-службами. Идейно эти средства связи почти идентичны, они асинхронны. В приведенных примерах различие обнаружится в технологии, а не в организации процесса обмена данными. Вывод: распространение Web-служб подчиняется отнюдь не более сложным по своей внутренней логике закономерностям, нежели традиционные средства связи.

В любой системе, предоставляющей услуги, начиная от примитивных бытовых (utility) и вплоть до SOA, участвуют две стороны: поставщики (service provider) и потребители (service requestor). Процедура установления связи и поддержания ее в процессе работы могут быть применены эти два альтернативных способа RPC и MOM. Первый предполагает, что поставщик услуг помещает их в некоторое хранилище (репозитарий), к которому обеспечен доступ потребителям. Например, в случае Web-служб для этой цели служит стандарт UDDI. Свойства служб (т.е. их потребительские качества) должны быть так или иначе понятны потребителю, например, они могут быть описаны на языке WSDL. Сами службы находятся в оболочке, выполненной по стандарту SOAP. Со своей стороны пользователь после того, как он иным способом обнаруживает в репозитории нужную ему услугу, «устанавливает с ней связь» (bind the service) и работает напрямую в синхронном режиме. Этот механизм может быть реализован в масштабах Глобальной сети, а может быть — и в масштабах корпоративной сети intranet. Этот, ставший почти каноническим, подход к построению Web-служб реализует механизм RPC. И, что очень важно отметить, после обнаружения услуги в репозитарии между поставщиком и потребителем может быть организован синхронный режим взаимодействия.

Пока менее известен асинхронный обмен сообщениями в рамках Web-служб использованием управляемых очередей средствами Message Oriented Middleware. Преимущества MOM подхода по сравнению с RPC внутри корпоративной системы очень образно изложены в статье Гордона ван Хьюзена, президента компании Sonic Software «Web-службы: повторение CORBA?» [10]. Хотя она была опубликована всего несколько месяцев назад, но успела вызывать оживленную реакцию, и была растиражирована на целом ряде сайтов. Деятельность компании Sonic Software, которая была создана выходцами из BEA Systems, как в свое время сама BEA была образована сотрудниками Sun Microsystems, чрезвычайно интересна.

Литература

  1. Леонид Черняк, Управление кораблем корпорации // БОСС, № 1, 1997
  2. Леонид Черняк, Править? Управлять!, // Connect!, 1997, № 3
  3. John Rauscher, "Real-Time Enterprise: Will your CEO buy it?", www.sunopsis.com/corporate/us/products/ sunopsisv3/real_time1.htm
  4. Real-Time Enterprise Theme at Symposium/ITxpo 2002, http://symposium.gartner.com/story.php.id.2651.s.5.html
  5. Vinod Khosla, Murugan Pal, Real Time Enterprises, A Continuous Migration Approach, 2002, March
  6. Peter Fingar, Howard Smith, Making Business Processes Manageable, Internet World, 2002, April
  7. Peter Fingar, Howard Smith, Business Process Management Systems, Internet World, 2002, May
  8. Peter Fingar, Jeanne Baker, Howard Smith, The Integrated Value Chain: BPML and the Next Frontier. Internet World, 2002, July
  9. Bobby Woolf, Kyle Brown, Patterns of System Integration with Enterprise Messaging
  10. Gordon Van Huizen, Web services: Is it CORBA redux?, Sonic Software