Чаще всего BPMS подразделяют на ориентированные на работу с людьми (human-to-human) и ориентированные на оркестровку информационных систем (system-to-system). Иногда дополнительно выделяют ориентированные на работу с документами (document-oriented) и на рассмотрение кейсов, т.е. «дел» (case-oriented).

Это деление отражает различие не только и не столько в назначении, сколько в происхождении конкретных систем. Ведь несмотря на то, что термин BPM получил широкое распространение только примерно с 2003 года, большинство сегодняшних BPMS ведет свою родословную из 90-х:

• human-to-human BPMS «в прошлой жизни» – это workflow-системы
• system-to-system BPMS, как правило, выросли из интеграционных пакетов (EAI framework)
• document- и case-oriented BPMS – это новое название для систем управления документооборотом

Конечно, все разработчики стремятся, сохраняя преимущество в «своей» области, подтянуть остальные как минимум до среднего уровня. Ведь вырожденные случаи, скажем, чисто интеграционных или чисто «человеческих» процессов встречаются относительно редко, и на практике чаще приходится иметь дело со смешанными задачами. Поэтому в конце должна произойти конвергенция и BPMS избавятся от своих «родимых пятен». Но пока существующие системы до идеала – равно успешного решения всего спектра задач – не дотягивают.

Не так давно Кейт Свенсон предложил более конструктивную классификацию – основанную не на предназначении/происхождении систем, а на архитектуре. Он выделяет системы с сохранением процессной модели и системы с трансформацией процессной модели. Эта классификация с разных сторон рассмотрена в серии заметок на его блоге:

1. Model Strategy: Preserving vs. Transforming
2. Model Strategy & Analytics
3. Model Strategy, Round-Trip & Agile Development
4. Model Strategy & Performance
5. Model Strategy & Simulation

В стратегии трансформации процессной модели постулируется, что на разных стадиях жизненного цикла процесса (концептуальное проектирование, моделирование, разработка, внедрение) оптимальными являются разные представления бизнес-процесса. Бизнес-аналитику больше подходит высокоуровневая бизнес-модель, а разработчику требуется что-то более конкретное и точное. Следовательно«бизнес-модель» необходимо трансформировать в «системную модель» - либо путем добавления узлов, либо путем преобразования в совершенно новую диаграмму, на которой будут представлены системные активности, необходимые для реализации в промышленной системе затребованной бизнес-модели.

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

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

Альтернативой является сохранение на протяжении всего жизненного цикла единой модели процесса. В этой стратегии, когда модель переходит от аналитика к программисту, последний ее не меняет, а лишь уточняет – прописывает атрибуты узлов процесса и связывает их с программным кодом. Затем эту же модель использует движок BPMS для запуска экземпляров процесса и исполнения шагов. Это – принцип «что рисуем, то и исполняем», и эту стратегию часто выбирают поставщики BPMS, ориентированных на работу с людьми, и те, в которых реализовано непосредственное исполнение BPMN-диаграммы.

Какая из двух стратегий лучше? Универсального ответа не существует – все зависит от того, с каким бизнес-процессом вы имеете дело и какие аспекты для вас являются приоритетными. Конкретно, Кейт анализирует следующие аспекты:

• Поддержка замкнутого цикла (round-trip). Суть проблемы: небольшие изменения, вносимые в модель процесса бизнес-аналитиком, не должны приводить к необходимости для программиста делать его работу заново. Здесь мы сталкиваемся с задачей, которая в системах контроля версий называется слиянием версий (merging) – в данном случае, со слиянием правок, сделанных аналитиком, с правками, сделанными разработчиком. В стратегии сохранения модели проблемы не возникает, а в стратегии трансформации возникает нетривиальная, хотя и решаемая задача.
• Видимость состояния исполняемого экземпляра процесса и способность реагировать на проблемы, возникающие на этапе исполнения. Возможность вмешаться в ход выполнения уже запущенного процесса и изменить схему уже запущенного процесса является достаточно востребованной. Очевидно, что решать задачу трансформации, нетривиальную саму по себе, не на этапе разработки, а на этапе исполнения – дело крайне затруднительное. Поэтому стратегия сохранения модели в этом аспекте обладает явным преимуществом, за исключением случая короткоживущих процессов с относительно простой логикой.
• Степень полезности аналитических данных. Аналитика, собираемая движком бизнес-процесса, всегда относится к исполняемой модели. Если бизнес-модель нетривиальным образом от нее отличается, то это затрудняет интерпретацию собираемой статистики в терминах бизнес-модели. Очевидно поэтому, что в этом аспекте стратегия сохранения модели имеет преимущество.
• Поддержка имитационного моделирования и оптимизации. Аналогично предыдущему пункту, результаты имитационного моделирования обязаны быть проинтерпретированы в рамках бизнес-, а не исполняемой модели, поэтому трансформация модели представляется нежелательной.
• Поддержка гибкой (agile) итеративной разработки. Фактически, это та же самая поддержка round-trip (п.1), только «на сверхзвуковых скоростях». Необходимость не просто уметь объединять правки аналитика и разработчика, а делать это непрерывно, автоматически и без задержки, делает преимущество стратегии сохранения модели более явными.
• Производительность. Теоретически, в этом аспекте стратегия трансформации имеет преимущество. Но это аналогично преимуществу компилируемых языков (C++, Fortran) перед интерпретируемыми (JavaScript, PHP). Там, где производительность – ключевой параметр (например, в СУБД или научных расчетах), там компилируемые языки имеют преимущество; в остальных случаях большее удобство работы с интерпретируемым или промежуточным (Java) кодом подталкивает к выбору в их пользу.
• Легкость работы для программиста. Программист предпочитает работать в привычной для него среде и с привычным инструментарием. Модели, создаваемые аналитиками, к числу таковых не относятся, поэтому с точки зрения разработчика, стратегия трансформации выглядит предпочтительной. Все зависит от соотношения между объемом работы над моделью и над программным кодом (в частности, от размера и сложности интеграционных задач). Стратегия трансформации будет выглядеть более предпочтительной в проекте, тяготеющем к чисто интеграционному.

Объективности ради следует заметить, что Кейт является заинтересованным лицом, так как продукт его компании – Fujitsu Interstage – очевидно следует стратегии сохранения модели. Чтобы составить более полную картину, рекомендуем познакомиться с аргументами противоположного лагеря. Например, с заметкой «Why BPEL Matters» на блоге Исмаэля Галими из Intalio – пожалуй, самого активного проповедника стратегии трансформации BPMN-BPEL.

=АБ

Комментарии