Поделиться
СОА преподносит неприятные сюрпризы
Концепция СОА, приобретающая все большую популярность, на самом деле оказывается не такой прозрачной, как представляется в начале. Для многих проектов, реализующих сервис-ориентированную архитектуру, очень важно обеспечить высокий уровень удобства и дружественности интерфейсов, к которым пользователь привык в классических системах "клиент-сервер". Задача, кажущаяся на первый взгляд простой, в реальности далеко не тривиальна. Например, неожиданным открытием может оказаться высокая трудоемкость реализации такого интерфейса.Всякому, кто сталкивается с ситуацией выбора пути дальнейшего развития информационной системы (ИС), будь то в масштабе предприятия, корпорации или всего лишь одного отдела, знакомо состояние своеобразного "информационного шока". Оно наступает после знакомства со всем многообразием существующих на рынке и предлагаемых для использования методик, технологий, продуктов и инструментов сферы ИТ. Все они находятся большей частью в отношениях конкуренции, и вендоры не слишком озабочены построением концепции их совместного использования.
Руководитель службы ИТ для снижения рисков в этих условиях вынужден искать некоторый "мейнстрим", который позволил бы ему и его ИС "продержаться на плаву" как можно дольше. Следующим открытием для него становится тот факт, что ни один из рыночных продуктов в одиночку не в состоянии обеспечить этот "мейнстрим" и необходим некоторый комплекс взаимосвязанных продуктов. Поиск такого комплекса решений, его формирование, зачастую происходящее по ряду случайных причин, в высокой степени определяют дальнейшие успех или неудачу той или иной ИС.
СОА не является здесь исключением и также нуждается в поддержке других технологий. Одной из них, появившейся практически одновременно с СОА, является концепция BPM (Business Process Management). Что же такое BPM и как он связан с СОА?
Соотношение и взаимосвязь СОА и BPM
Концепция СОА предполагает (как мы уже говорили ранее) построение информационных систем как набора сервисов, которые для выполнения какой-либо полезной работы требуют активации со стороны клиентов. Понятно, что среди них могут быть другие сервисы, но также понятно и то, что в конечном итоге для каждого протекающего в системе процесса должен существовать родительский клиент, активизация которого происходила бы по событию, пришедшему в систему извне.
Всякому, кто сталкивается с ситуацией выбора пути дальнейшего развития информационной системы (ИС), будь то в масштабе предприятия, корпорации или всего лишь одного отдела, знакомо состояние своеобразного "информационного шока"
В большинстве существующих ИС класса управления предприятием (ERP) такие события инициируются в системе действиями пользователя. А поскольку исходно в концепции СОА о наличии у сервисов пользовательского интерфейса ничего не говорится, то у нас возникает явная необходимость в таком клиенте верхнего уровня, который взял бы на себя ещё и функцию общения с пользователем.
Последовательность действий по такому взаимодействию и обработке данных информационной системой с целью получить полезный результат есть ни что иное, как бизнес-процесс. Таким образом концепция BPM логично возникает в связи с концепцией СОА.
Итак, если мы опишем необходимый нам бизнес-процесс на некотором языке, (таковым сейчас стандартно является BPEL – Business Process Execution Language) и запустим его на исполнение, то интерпретатор BPEL совместно с СОА-ландшафтом обеспечат нам реализацию этого бизнес-процесса. Вопрос о том, было ли исполнение БП изначально инициировано пользователем или в системе был сконфигурирован автоматизированный "стартер", запускающий процесс по некоторому событию (по времени, например), не является принципиальным. Главное, что после того, как он запущен на исполнение, операторы, сервисы и системы работают совместно над реализацией, представляя собой некую человеко-машинную систему. Возникает "композитное приложение", состоящее из сервисов, объединенных единым бизнес-процессом.
Приведенная схема логически стройна, и всё было бы прекрасно, если бы не отрицательные заключения специалистов, пытающихся применить ее на практике. Эти заключения неоднозначны, поскольку что-то иногда получается. Но следует признать, что общий баланс скорее отрицательный. И это проблема не только BPM. Это становится также и проблемой реализации СОА. Попробуем провести более глубокий анализ.
Разноликие бизнес-процессы
Если попытаться понять, какие бывают бизнес-процессы, то становится очевидным, что они очень различны. Приведем примеры.
Бронирование и покупка билетов в интернете – это БП, который реализуется во взаимодействии с практически неподготовленным оператором – потребителем услуги. Он жестко регламентирован, и система неуклонно проводит пользователя по четко прописанной процедуре. Сам процесс носит явный транзакционный характер: билет будет забронирован или не забронирован, третьего не дано. Качество реализации такого БП обычно весьма высокое. Система полностью контролирует пользователя и не позволяет ему совершить никаких процедурных ошибок. Конечно, реализация такого БП сложна и является весьма затратной.
Другой пример – это работа в системе управления предприятием бухгалтера, выясняющего причины расхождения баланса, или снабженца, планирующего поставки. Эти БП практически не формализуемы, они носят творческий характер. Все, что необходимо от системы, это предоставление оператору набора необходимых инструментов. Как ими воспользоваться, оператор решит сам.
Эти два примера являются крайними типами БП. Большинство реальных процессов на предприятии находятся где-то посредине. Но нельзя не заметить, что существующая идеология BPM сильно перекошена под процедурный подход и, возможно, дает хорошие результаты именно там, где необходим именно он. Такие системы можно охарактеризовать как системы с небольшим количеством жестко регламентированных бизнес-процессов, которые исполняются большим количеством слабо подготовленных операторов.
Короткая ссылка
