Система управления выполняет несколько основных функций: она получает сведения об управляемом объекте и окружающей среде, оценивает ситуацию со скоростью, сопоставимой с динамикой объекта и процессов в окружающей среде, вырабатывает необходимое управляющее воздействие и передает его на объект управления. Утверждать, что корпоративные информационные системы в полном объеме умеют выполнять все эти функции, было бы серьезным преувеличением. Но это не навечно —возможны изменения.
Человек начал постигать искусство управления с тех времен, когда первый пастух, взяв в руки хлыст, погнал стадо в нужном ему направлении, или когда первый всадник взобрался на лошадь и поводьями указал ей направление движения. Намного позже, в середине XX века, значимость управления на макроэкономическом уровне продемонстрировал творец японского экономического чуда Эдвард Деминг. Построив необходимую систему управления, он сумел избавить тамошнюю промышленность от присущей ей (сегодня в это невозможно поверить) хронической болезни — низкого качества продукции. Да, в 50-е годы «японское» было синонимом «плохого».
Деминг доказал, что мониторинг, основанный на непрерываемых циклах измерения и обратной связи, может обеспечить повышение качества, снижение издержек и другие конкурентные преимущества. Император Японии наградил Деминга за плодотворную работу в течение полутора десятилетий одним из самых престижных орденов, японские промышленники учредили премию его имени, а труды Деминга стали классикой менеджмента.
Во всех случаях качество управления зависит от того, насколько хорошо управляющий видит объект управления. Появление в 2003-2004 годах концепции архитектуры, управляемой событиями (Event Driven Architecture, EDA), систем мониторинга бизнес-процессов (Business Process Monitoring, BPM) и мониторинга бизнес-активности (Business Activity Monitoring, BAM) может стать таким же поворотным моментом в эволюции корпоративных информационных систем, каким в свое время стало внедрение методов Деминга в Японии. Вместе с EDA, BPM и BAM корпоративные системы приобретают способность видеть и воспринимать события из внешнего мира, что позволяет замкнуть петли обратной связи.
Однако нынешние технологии, поддерживающие идеи EDA, пока обеспечивают обработку только простых или единичных событий. Реализация концепции BAM в полном объеме потребует от систем возможностей обработки сложных событий.
Профессор Лукхэм — человек событий
Имидж компьютерной индустрии заметно меняется, свидетельством чего может служить следующий факт. Одной из наиболее заметных фигур компьютерного мира в 2004 году стал не какой-нибудь удачливый предприниматель или обнаглевший хакер, а «всего лишь» профессор Стэндфордского университета Дэвид Лукхэм. В одном из журналов его даже назвали «человеком событий» (Man of events).
Прежде ничто в многолетней карьере Лукхэма не предвещало столь неожиданного поворота событий, сделавшего его публичной фигурой. Виной всему стала опубликованная в 2002 году книга «Сила событий» (The Power of Events), которую по всем канонам ожидала обычная судьба научного издания — полки библиотек и магазинов. Но с книгой произошло непредвиденное. Она стала катехизисом «стимулированной событиями революции ИТ». Ее рецензировали крупнейшие бизнес-издания, ее десятками экземпляров закупают компании, ее читают в самолетах бизнесмены. Последнее — признак высшего уровня признания ИТ-сообществом.
Все это тем более удивительно, что «Сила событий» — чтение непростое. Книга стала плодом 22-летней преподавательской работы Лукхэма в Стэндфордском университете, а прежде — в учебных заведениях с не менее громкими именами: Гарвардский университет, Калифорнийский университет в Лос-Анджелесе и Массачусетский технологический университет.
Известность в академических кругах пришла к Лукхэму гораздо раньше, в далекие 70-е годы, когда он создавал по заказу оборонного агентства по перспективным разработкам DARPA сверхнадежный объектно-ориентированный язык программирования Ада. Подготовленная им тогда монография ANNA — A Language for Annotating Ada Programs вышла в 1987 году в издательстве Springer. Публикация в этом издательстве — своего рода знак качества, поскольку Springer является одним из самых престижных научных издательских домов.
Дополнительным, но не менее важным результатом работы над проектом языка программирования Ада оказалось создание технологий компиляции, позволившее Лукхэму стать одним из основателей компании Rational Software. Тогда же он пришел к выводу о том, что информационные системы, прежде всего оборонного назначения, должны уметь обрабатывать сложный входной поток событий. Это умозаключение стало предпосылкой к его современным работам.
Разумеется, три десятилетия назад речь шла о потоке событий, связанных с ракетной атакой или с чем-то подобным, но со временем Лукхэм перенес свои представления о сложных событиях на корпоративные информационные системы. Он назвал нынешнее направление своих исследований обработкой сложных событий (Complex Event Processing, CEP). И хотя практическая реализация идей CEP чрезвычайно сложна, автор уверен в их перспективности: «Это — следующий шаг в развитии программного обеспечения. И он должен быть сделан».
Лукхэм подчеркивает, что CEP — не то же самое, что архитектура, управляемая событиями, в трактовке Gartner. Идеи CEP в большей мере приложимы к мониторингу бизнес-активности; EDA и CEP взаимно дополняют друг друга.
BAM как средство от слепоты ИТ
Лукхэм справедливо указывает, что концепция предприятия, управляемого событиями и работающего в режиме реального времени (EDA + RTE), в трактовке Gartner страдает заметной неполнотой. Она, в конечном счете, сводится к способности отрабатывать отдельные простые события; ей не хватает существенной детали — полноценного контура управления. Без петли обратной связи, информирующей о состоянии внешней среды и дающей представление о происходящем, ни о какой полноценной работе в режиме реального времени и речи идти не может.
Нехватка средств мониторинга — явление повсеместное, она обнаруживается даже в таких системах, существование которых без подобных средств, казалось бы, немыслимо. В качестве примера Лукхэм упоминает события хорошо известной энергетической катастрофы, случившейся в августе 2003 года на северо-востоке США. По результатам расследования выяснилось, что диспетчеры энергосистем, вооруженные всеми доступными средствами связи и поддерживаемые системой сбора данных и оперативного диспетчерского управления (Supervisory Control And Data Acquisition System — SCADA), оказались неспособными в прямом смысле слова увидеть происходящее. В одном из многочисленных комментариев их сравнили с диспетчерами воздушного движения, лишенными радиолокаторов.
С проблемой недостаточной осведомленности операторов и других лиц, принимающих решения, то есть с отсутствием обратной связи с объектами управления, связано множество техногенных катастроф. Для обозначения этого феномена Лукхэм ввел термин «слепота ИТ» (IT blindness). Слепота в данном случае — не метафора, а именно неспособность увидеть реальную ситуацию, которая порой порождает тяжелые последствия. В качестве не катастрофического, но весьма болезненного случая подобной слепоты можно привести такой пример. Если при передаче информации о стоимости товара в крупной торговой сети произойдет ошибка, она может быть не сразу обнаружена по причине неэффективной обратной связи, что приведет к многомиллионным убыткам.
Еще одна необходимая составляющая управления — оперативная оценка ситуации (сейчас используют термин instant insight, т.е. буквально «мгновенное озарение»). Практически любое действие человека требует оценки для принятия решения. Лучше всего, когда есть необходимый для этого опыт и заблаговременное представление. Лукхэм считает, что бизнес должен превратиться в «предчувствующее предприятие» (anticipatory enterprise), а таким его могут сделать системы категории BAM.
Системы данной категории призваны преодолеть слепоту ИТ и снабдить их средствами оперативной оценки ситуации. Они должны решать следующие задачи:
- обеспечить возможность мгновенного осознания ситуации, то есть оценки того, как повлияют события (неисправности в сети, состояние баз данных, изменения в Web, изменение показателей каких-то ресурсов) на ход операций в бизнесе;
- осознав ситуацию, принимать решения и передавать управляющие воздействия, которые могут изменить бизнес-процессы;
- фиксировать нарушения или попытки нарушения политик и соглашений об уровне обслуживания;
- накапливать статистику производительности всех операций.
Полноценная реализация механизмов, способных решать все перечисленные задачи, приведет к созданию своего рода «капитанского мостика» предприятия, подобного тому, который показан на рисунке.
Нельзя не заметить очевидного антропоморфизма BAM. Действительно, вся человеческая жизнь состоит из обработки сложных событий и принятия решений. Если вы почувствуете запах горелой пластмассы на кухне и увидите, что чайник стоит на газовой плите наклонно, вы сделаете такой вывод: причина запаха — в горящей ручке чайника, а не в коротком замыкании и горящих проводах. Тогда вы отключите газ, а не электричество. Скорость и глубина понимания определяются коэффициентом интеллектуальности IQ.
В точности то же самое происходит и в корпоративных информационных системах. Здесь анализ сложных событий можно уподобить технологиям бизнес-интеллекта (Business Inelligence, BI), функционирующим в режиме реального времени. Он обеспечивает BAM системой «зрения» и оценки текущей ситуации. Разрабатываемый Дэвидом Лукхэмом подход CEP представляет собой фундаментальную технологию обнаружения и управления событиями на предприятии, управляемом событиями. Задача CEP состоит в обработке множественных потоков простых событий с целью идентификации в них сложных событий. Для реализации CEP может применяться архитектура EDA вкупе с программным обеспечением промежуточного слоя, действующим на основе обмена сообщениями или принципа «публикация-подписка», а также с Web-сервисами и архитектурами, ориентированными на сервисы.
Что изменилось и что изменится?
Естественный вопрос — а с чего это вдруг проявилось столь пристальное внимание к каким-то сложным событиям и предприятиям, управляемым событиями? И еще — к чему это может привести, к чему надо готовиться?
Ответ на первый вопрос достаточно прост. Изменился темп жизни, выросло количество обрабатываемых данных. Эти изменения распространяются и на информационные системы, признаки грядущих перемен в которых очевидны. Несколько лет назад впервые заговорили о вычислениях, управляемых данными (Data Driven Computing), а сейчас центр внимания сместился на потоковую обработку данных в режиме реального времени, и яркий пример тому — работы известного специалиста в области управления данными Майкла Стоунбейкера и его последние системы Mariposa и SreamBase.
Отличную метафору предложил Марк Палмер, вице-президент компании ObjectStore, входящей наряду с Sonic в состав Progress Software. Он сравнил сферу применимости традиционных систем, основанных на реляционных базах и хранилищах данных, с прудом, где обитают декоративные рыбы. Требуется собирать данные об обитателях пруда и периодически их серьезно анализировать, готовить календарные отчеты, которые можно использовать для обоснования затрат на содержание жителей пруда. Продолжая «рыбную» аналогию, Палмер сравнил задачи систем реального времени со сбором данных о косяках лосося, идущего на нерест. Системы реального времени несут новую «философию» отношения к событиям, новую «физику» накопления данных и управления потоками, а все вместе это образует новый стиль вычислений, в основе которых лежит обработка сложных событий.
В своей совместной статье Давид Лукхэм и Марк Палмер формулируют пять основных выводов, относящихся к практической реализации подходов BAM и CEP.
- Должны развиваться математический аппарат и технологии, поддерживающие CEP.
- Особую важность приобретают технологии кэширования данных в оперативной памяти, а обработка данных в режиме реального времени невозможна без доступа к ним в том же режиме.
- Архитектуры grid, предназначенные для хранения данных, и объектно-ориентированные СУБД совместно могут обеспечить обработку больших объемов данных синхронно с темпом событий.
- Преимущество получат архитектуры, ориентированные на сервис, и архитектуры, управляемые событиями.
- Все описанные перемены должны ограничиваться «передним краем» (front-end) и программными средствами промежуточного слоя, а уровень базовых систем (back office), где аккумулирован огромный багаж знаний и опыта, должен остаться неизменным.
Профессор Лукхэм предсказывает, что уже в 2005 году появятся первые коммерческие продукты, поддерживающие идеи CEP, а широкое распространение они получат к 2012 году.
