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

В 2004 году к двум прежним расшифровкам аббревиатуры EDA прибавилась третья. Традиционно под тремя буквами EDA чаще подразумевали автоматизацию проектирования электронных компонентов (electronic design automation), реже — анализ данных в статистике (exploratory data analysis), а теперь добавилось и нечто новое — event driven architecture, означающее «архитектура корпоративных информационных систем, движимая или стимулируемая происходящими в ней и вне ее событиями». Термин EDA в последней трактовке был предложен экспертами Gartner и, думается, это не очередной короткоживущий маркетинговый жупел, как иногда случается в практике уважаемых аналитических компаний, а серьезная перспектива на ближайшие годы.

Сам факт интерпретации событий в среде, где существует система, можно считать определенным достижением, объективно отражающим закономерности развития информационных систем на пути от фрагментарной автоматизации отдельных функций к полноценным системам автоматизированного управления бизнес-процессами. Рано или поздно надо начать учитывать динамику окружающей среды. До сих пор развитие шло в основном не от внешних требований, а от технологических возможностей. Давным-давно автоматизация бизнеса начиналась с использования компьютера в его наиболее естественной функции, он был инструментом расчета (например, расчета заработной платы), простейшей аналитики. Появляющиеся технологии постепенно раскрывали возможности компьютеров, появились базы данных, и компьютер в большей степени стал инструментом для работы с данными. Затем сетевые технологии открыли коммуникационные возможности компьютеров, они дали толчок развитию интерактивных средств, в том числе порталов, потом в ход пошли мобильные устройства, беспроводная связь и т. д. Параллельно начались работы по созданию комплексных систем, появились на свет ERP, CRM и другие многочисленные их родственники, которые на самом деле к управлению, как таковому, никакого отношения не имели и не имеют.

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

EDA на фоне АСУ ТП

Попробуем точнее определить место, на которое претендует EDA в общем «информационно-технологическом» ландшафте. В качестве иллюстрации стоит обратить внимание на происходящее за последние три-четыре года идеологическое сближение систем автоматизации бизнеса с автоматизированными системами управления технологическими процессами (АСУ ТП). Разумеется, здесь не может быть прямых аналогий, понятно, что в бизнес-системах все гораздо сложнее, что управленческие задачи находятся на совершенно ином уровне, а также объемы и структура данных совершенно иные, и вдобавок среда менее детерминирована, и в контуре управления человек занимает гораздо большее место, и многое другое. Но тем не менее аналогий достаточно.

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

Как ни странно, но эта азбучная истина, излагаемая в любом вузовском курсе теории автоматического регулирования, мало известна специалистам по бизнес-менеджменту. Может быть, поэтому ничего подобного в бизнес-системах прежде не было. Лишь совсем недавно появились первые средства моделирования, с помощью которых стало возможным реализовать управление бизнес-процессами (Business Process Management, BPM). Наибольший интерес представляют нотация для описания процессов BPMN и язык BPEL (Business Process Exchange Language), но есть и другие близкие им средства. Существующие подходы к реализации BPM опираются, главным образом, на сервис-ориентированные архитектуры (Service-Oriented Architecture, SOA); не случайно изначально BPEL назывался BEPL4WS, т. е. Business Process Exchange Language for Web-Services. Появление сервисов в качестве средства для объединения слабосвязанных приложений можно назвать знаковым событием; за этим кроется признание того обстоятельства, что сложность современных систем вышла за пределы возможностей традиционных подходов к интеграции приложений. Сервисы, или связи, — это то, на чем строятся сложные социальные, биологические и даже физические системы. От прямых связей связи, основанные на сервисном механизме, отличаются меньшей жесткостью; подобные системы так и называют — «слабосвязанные». Будучи связанными в общую архитектуру SOA, сервисы образуют механизм взаимодействия между приложениями, который, например, может быть построен на основе сервисной корпоративной шины (Enterprise Service Bus, ESB). К сожалению, в обсуждении сервисов чаще внимание уделяется технологиям их реализации, протоколам и стандартам, а не логике их применения. Сказывается хроническая болезнь современной компьютерной отрасли, недостаток системности во взглядах, или иначе — холистического мышления.

Воспользуемся еще одной аналогией с АСУ ТП. Современная система управления бизнесом должна работать в режиме реального времени, отсюда еще она аббревиатура — RTE, т. е. Real Time Enterprise. Обычно необходимость в реальном времени аргументируется желанием добиться более высокого качества управления, но сейчас работа в реальном времени становится насущной необходимостью в связи с тем, что по мере развития информационных систем потоки входных данных резко возрастают, самым мощным стимулом может стать распространение методов радиоидентификации изделий RFID. Работа в режиме реального времени АСУ ТП предполагает осуществление сбора данных и выработки управляющих воздействий в одном темпе с динамикой управляемых объектов. Часть данных может собираться по заранее запланированному графику, но некоторые данные, например, сигналы об аварийных или предаварийных ситуациях, какие-то менее критические сигналы являются событиями, на которые должна последовать незамедлительная реакция. По самому своему определению, АСУ ТП должна строиться на принципах EDA. Бизнес-система, работающая в режиме реального времени, — точно так же.

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

Теоретические предпосылки

Значение средств для обработки событий для построения систем реального времени с достаточной полнотой представлено в двух трудах. Это книги с неожиданно близкими названиями. Первая — «Сила текущего момента» (The Power of Now) была издана в 1999 году, ее автором является основатель компании TIBCO Вивек Ранадив. Вторая — «Сила событий» (The Power of Events) написана профессором Стэндфордского университета Дэвидом Лукхэмом и вышла из печати в 2002 году. Лукхэм — автор приобретающей популярность теории обработки сложных событий (Complex Event Processing, CEP). Эта теория является адаптацией для бизнес-приложений исследований, выполненных в рамках Стратегической оборонной инициативы (СОИ).

Первые шаги по направлению к EDA

Основное предназначение архитектуры EDA состоит в том, что она позволяет предприятию распознавать события во внешней среде. Сведения об этих событиях собираются, анализируются и используются для принятия решений. Этот подход позволяет осуществлять не только активное, но и проактивное управление.

Подобная архитектура должна обладать рядом основных характеристик.

  • Асинхронность. EDA поддерживает асинхронный режим взаимодействия, условием которого является способность к приему случайного потока данных и немедленная реакция на них. Если сравнивать с АСУ ТП, то можно найти аналогию с системой прерываний. При возникновении определенного события поисходит прерывание обычного фонового процесса и управление передается соответствующему этому прерыванию модулю.
  • Схема «публикация/подписка». EDA поддерживает взаимодействие многих со многими; это предполагает, что системы публикуют сведения о происходящих в них событиях в сети, и эти же системы могут быть авторизованы на подписку для получения опубликованных сведений.
  • Разделение. EDA не предполагает установление каких-либо тесных отношений между публикаторами и подписчиками. Взаимосвязь между системами ограничена исключительно уровнем обмена сообщениями.

Опередив других, на тему EDA стали высказываться компании Tibco Software и SeeBeyond, специализирующиеся на интеграции приложений. Они увидели в этой архитектуре возможность для создания аналитических инструментов, которые позволили бы управленцам принимать решения более быстро и осмысленно. За привычной словесной эквилибристикой стоит желание создавать так называемые системы мониторинга бизнес-активности (Business Activity Monitoring, BAM). Такие системы BAM отличаются от более традиционных средств бизнес-анализа и хранилищ данных тем, что они ориентированы не на аналитика, который делает прогнозы на основе осмысливания относительно небольшого объема стратегических данных, а на обычного исполнителя, который должен принимать тактические решения, используя для этого текущую информацию. Это совершенно иная задача, и использовать нужно совершенно иные потоки входных данных, главным в ней становится фиксация и накопление данных. Некоторые технологии для создания подобного рода систем уже существуют, прежде всего, это программное обеспечение промежуточного слоя, ориентированное на передачу сообщений; однако основную часть придется делать заново. Одной из первых, сумевших предложить свои решения, подпадающие под определение BAM, была калифорнийская компания Praja, купленная в 2002 году Tibco; после этого Tibco начала предлагать продукт Tibco BusinessFactor.

Непонимание различий между архитектурой системы и ее способностью обрабатывать входной поток случайных событий привело к тому, что многие авторы стали путать роль и место SOA и EDA. Одной из наиболее растиражированных статей стал материал Джейсона Блумберга «SOA + EDA = FUD?» Он задается вопросом, а не является ли ажиотаж вокруг EDA еще одним уровнем ажиотажа, создаваемого вокруг SOA? Недостаточным осознанием значения EDA для создания предприятий, работающих в режиме реального времени, страдают не только журналисты, но и некоторые аналитики. Уточним, что SOA — это один из возможных и наиболее приемлемых на данный момент, на данном уровне развития технологий способов реализации EDA. Если обнаружится какой-то иной способ реализации систем, состоящих из слабосвязанных приложений, то почему бы не использовать его.

Event Driven Architecture

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

Бизнес-событие: изменение состояния предприятия.

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

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

Преимущества

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

Ограничения

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