Just One More Article About SOA and BPM.

Что такое SOA?
Это небо
Плачущее небо
Под ногами

Давеча посетил Oracle Tech Forum 2007 с целью посмотреть на текущую ситуацию с SOA и BPM с точки зрения Oracle. Было много интересных (и не очень ;-) докладов, особенно заинтересовали описания реальных проектов.
В связи с этим возникло желание немного рассказать о Service-Oriented Architecture (SOA) и Business Process Management (BPM) тем, кто с такого рода решениями не сталкивался, но интересуется современными трендами в IT. Так же назревает некоторая необходимость прояснить терминологию.
Базовую информацию можно найти в википедии: SOA и BPM.

SOA

Текущие реалии и история
Чтобы современному разработчику понять, откуда такой интерес к SOA и BPM, необходимо представлять, какие основные свойства присущи современным КИС (корпоративным информационным системам). Буквально недавно наблюдалась эпоха ERP - эдаких информационных Голиафов, очень крупных систем, в рамках которых пытались автоматизировать деятельность всего предприятия. Помимо этого, штатные программисты компании писали свои программы для автоматизации, так как оказалось, что купленная ERP все-таки не так хороша; при поглощениях/слияниях наследовался парк ПО купленной компании. Так что рано или поздно к идее, что всю деятельность можно автоматизировать средствами одной системы, возникли серьезные претензии ;-)
Компания рано или поздно вставала перед фактом: в её IT-среде наблюдается зоопарк различных систем, от корпоративных ERP до мини-утилиток. Все это написано разными людьми в разное время, при этом интеграция этих систем реализована по принципу "одна с несколькими", а интерфейсы этих систем и механизм их взаимодействия крайне плохо документирован. В дальнейшем так и будем называть эту сложившуюся ситуацию зоопарком систем.

Рис. 1

Для компаний, оказавшихся в такой ситуации с унаследованными (legacy) системами, стало очевидно, что сегодня мы живем в постмодернистском IT-мире - новых систем в парке компаний становится сравнительно немного, а большая часть усилий уходит на интеграцию существующих. Сплошная эклектика ;-) Задача современного разработчика чаще всего не писать, а объединять...
Так же надо учитывать недовольство IT-менеджеров сегодняшними ERP-системами. Дело в том, что эти ERP - попытка создать универсальную ИС предприятия. При этом видение бизнеса, по сути, бизнесмену навязывается вендором ERP-системы. Это может ударить по одному из важнейших рыночных преимуществ компании - уникальности.
Этот тезис позаимствован из очень интересной и спорной книги Блеск и нищета информационных технологий. Почему ИТ не являются конкурентным преимуществом, но, несмотря на всю спорность, доля здравого смысла здесь есть.
Так же универсальность ERP зачастую идет рука об руку с закостенелостью, невозможностью быстрого изменения в соответствии с требованиями ситуации. Гибкость (agility), открытость изменениям - одно из важнейших требований современного бизнеса.

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

• Повысить гибкость КИС, а, следовательно, и бизнеса
• Снизить затраты на поддержку КИС
• Сделать основные концепции КИС понятными менеджменту, сблизить менеджмент и IT
  

Концепции SOA
Для решения поставленных задач как раз и подходит SOA:

SOA определяется как программная архитектура, основанная на хорошо структурированной типологии интерфейсов, их применении, а также на тех задачах, которые эти интерфейсы решают.
Gartner Group, 1996

У SOA довольно много определений, в том числе и приведенное, но все эти определения объединяет общая идея: изначальная ориентация не на структуру ИС, а на функциональность, при этом она должна быть четко описана и заменяема. Здесь-то и всплывают сервисы - заменяемые функциональные единицы с четко описанными интерфейсами.

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

Реализация SOA
Мы познакомились с базовым определением SOA, и важно понимать, что когда говорят о SOA сегодня, то чаще всего подразумевают именно реализацию. Как же технологически реализовать идею о легкозаменямых взаимодействующих сервисах с четко описанными интерфейсами?
Технологий, позволяющих реализовать концепции SOA, достаточно много. Это различные варианты технологий удаленных вызовов (включая RPC/DCOM, RMI, CORBA, web-services и др.) и технологий обмена сообщениями (MQSeries, MSMQ, JMS). Но наибольшую популярность при реализации SOA-решений сегодня завоевали веб-сервисы. Так что сегодня, говоря SOA, чаще всего подразумеваем web-services ;-)

Рассуждения о том, почему именно они, несколько выходят за рамки данной статьи.
Но реализовать ИС компании как набор веб-сервисов и/или "обернуть" существующие системы ими - это только пол-дела. Остается нерешенной проблема сложности их взаимодействия. Ведь они получаются у нас связаны по принципу "многие ко многим", и с увеличением количества сервисов количество связей между ними растет лавинообразно, что серьезно усложняет систему. К тому же надо учитывать, что при взаимодействии сервисов надо будет трансформировать данные из формата одного сервиса в формат другого. И этих трансформеров понадобится по числу связей.

Рис. 2

Какой же выход из этой ситуации? Выход в централизации сервисов. Соответственно, у нас появится некоторая среда, которая будет хабом, объединяющим сервисы. Эту среду принято называть корпоративной сервисной шиной - Enterprise Service Bus (ESB).
При использовании ESB:

1. Уменьшается количество связей
2. Упрощается замена, добавление и удаление сервисов
3. Для каждого сервиса можно написать только один трансформер данных - в стандартный формат шины
4. Упрощается администрирование сервисов в работе
5. Упрощается мониторинг сервисов
   

Рис. 3

Для управления этой инфраструктурой информационной системы вводится спечиальная роль - администратор ESB. Так же ESB инкапсулирует реестр сервисов.
Что касается механизмов подключения сервисов в шину, то это, скорее всего, будут технологии веб-сервисов (сервисы афишируются как веб-сервисы - их взаимодействие с шиной осуществляется по SOAP, интерфейсы описаны на WSDL, реестр сервисов реализован как UDDI-реестр).
Но есть и альтернативные способы интеграции сервисов и шины. Здесь все зависит от возможностей и технологической реализации шины. В силу специфики блога мы будем рассматривать шины, реализованные на платформе j2ee (но при этом стоит помнить, что существуют ESB, реализованные на других платформах). Если сервисом выступает внешняя КИС, то её можно интегрировать в шину посредством технологии J2CA - коннекторов (адаптеров), так же для интеграции java-based сервисов часто используется технология JMS. В случае, если сервисом выступает СУБД, для интеграции может использоваться JDBC.
В функционал шин зачастую так же входит замечательная возможность автоматизированного оборачивания внешних систем (сервисов) веб-сервисами. Это делается практически без кодирования администратором шины. Таким образом, например, включение СУБД в шину может занять крайне малое время при отсутствии кодирования, с использованием только административной консоли шины.

Резюме
Архитектура SOA позволяет строить гибкие решения и снизить стоимость их поддержки. SOA позовляет сблизить бизнес и IT, решая так же проблему унаследованных систем. Решением проблемы "или приобретать, или разрабатывать" становится "и приобретать, и разрабатывать".
В подавляющем большинстве случаев, когда говорят "SOA", подразумевают ESB и веб-сервисы.

BPM

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

Рис. 4

Как в этом случае происходит оценка эффективности бизнеса? Чаще всего применяется агрегирующий подход - Key Performance Indicators (KPI). KPI рассчитываются за какой-либо период времени (месяц, квартал, год) и показывают эффективность подразделения (количество продаж, степень удовлетворенности клиентов и прочие, специфические для конкретного подразделения или работника). По этим показателям принимаются управляющие решения - от раздачи бонусов до увольнения.
Чем же грешит этот наиболее распространенный подход? Своей агрегативной природой. То есть бизнес мониторится пост-фактум, нет мониторинга в динамике, нет деталей. KPI показывают, что все хорошо, но не понятно, что можно улучшить; KPI показывают, что все плохо, но непонятно, где именно. А самое главное - KPI не позволяют радикально переработать ни бизнес в целом, ни конкретные структуры. В качестве примера приведу иллюстрацию одного из докладчиков на Oracle Tech Forum: зачастую 80% работы делается за 20% времени. Не правда ли, знакомо? ;-) И бизнес чувствует себя отлично, хотя есть еще огромное пространство для повышения эффективности.

Соответственно, требуется методология организации бизнеса, позволяющая оптимизировать его работу и непрерывный мониторинг, плюс максимальная автоматизация. Этим требованиям удовлетворяет процессный подход - BPM.
Итак, мы определились с основными задачами процессного подхода:

• возможность непрерывной оптимизации бизнеса
• непрерывный мониторинг
• максимальная автоматизация

Часто для обозначения бизнес-процессов так же применяется термин workflows.

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

Рис. 5

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

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

Из наиболее известных j2ee-based сред выполнения процессов можно отметить:

• BEA WebLogic Integration и AquaLogic
• IBM BusinessProcess Server
• Oracle BPEL Server
• BPEL Engine в Glassfish
• JBoss jBPM

Говоря про современные стандарты описания и выполнения процессов, следует отметить, что их достаточно много. Подавляющая часть из них - открытые, и лидером по популярности является BPEL (Business Processes Execution Language), читается "бипль".

Следует учитывать, что бизнес-аналитик при моделировании процессов и разработчик - это разные роли, и они могут пользоваться разными нотациями при описании процессов. Это, соответственно, стандарты описания (modeling) и реализации (aka выполнения, execution) процессов.
А что касается наиболее популярных стандартов обеих групп, вот некоторые из них:

• WSFL
• XLANG
• Семейство BPEL
  
• JPD
• JPDL
  

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

Зачастую среды выполнения процессов взаимодействуют с внешними системами посредством технологического API веб-сервисов. Т.е. внешние системы афишируется как веб-сервисы, и в этом случае бизнес-процесс будет синхронно или асинхронно их вызывать. Именно так работает популярнейший стандарт BPEL4WS.
Разработчику теперь необходимо описать процессы в нотации (process integration), принимаемой данной средой выполнения и определить трансформации данных для их приема из внешней системы или для передачи (data integration).
Вместо:

Рис. 6

при применении автоматизированных BPM-решений мы имеем:

Рис. 7

Рис. 8

Как упоминалось, в аспект data integration входят:

• обеспечение технологического взаимодействия внешней системы и среды выполнения процесса (технологические API)
• трансформация данных при передачи в/из внешней системы

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

Мониторинг процессов в BPM
Автоматизированные среды выполнения бизнес-процессов предлагают крайне продвинутые возможности мониторинга. Конкретные возможности продуктов выходят за рамки данной статьи, но здесь важно понять принципиальную вещь: мониторятся не технологические аспекты, а бизнес. Т.е. не uptime сервера или загрузка CPU, а сколько по времени занимает весь или конкретный участок бизнес-процесса, состояния (данные) процессов, и пр. При этом мониторинг ведется в реальном времени.
Благодаря такой детализации появляется возможность дать бесценную информацию аналитикам для дальнейшей оптимизации процессов.

Резюме
Современные автоматизированные BPM-решения вполне успешно решают проблемы, присущие функциональному подходу организации бизнеса:

• возможность непрерывной оптимизации бизнеса
• непрерывный мониторинг
• максимальная автоматизация

SOA и BPM

Терминологическое отступление
Вообще-то SOA и BPM - разные подходы, т.е. это не одно и то же. Но они настолько удачно сочетаются, что, зачастую, говоря SOA, подразумевают её в связке с BPM и наоборот.

SOA + BPM = Love ;-)
Действительно, инфраструктурная гибкость SOA и процессный подход BPM крайне эффективны вместе.

Рис. 9

Здесь под SOA понимается сегодняшнее определение - с использованием ESB.

Выводы
По оценкам Gartner, ни одна технология не завоевывала такую популярность так быстро, как BPM. А преимущества SOA позволяет связке SOA+BPM стать доминирующей архитектурой разработки КИС уже сегодня.