Процесс встречается с данными

Тексты на тему BPMS в первую очередь акцентируют внимание на бизнес-процессах: схемы, нотации, оркестровка и хореография… Во вторую очередь внимание обычно уделяется разработке экранных форм к шагам процесса и функциональности пользовательского портала. Еще дальше на периферии – бизнес-правила и интеграция. И совсем не в фокусе обычно оказывается моделирование данных на этапе разработки и манипулирование данными в ходе исполнения процесса.

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

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

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

Что же это за подходы?

1. Плоский список атрибутов

Для каждого шаблона бизнес-процесса разработчик может задать список атрибутов, указав для каждого тип – число, строка, дата-время, список значений…

В современных BPMS этот подход не используется в виду крайней примитивности, но его можно встретить в устаревших workflow-системах, которые, однако, могут позиционироваться вендором как BPMS.

2. XML-документ

Разработчику предоставляется возможность определить собственные типы данных и сложные структуры данных. Например, клиентский заказ можно смоделировать как объект, ссылающийся на справочник клиентов и имеющий многострочную часть со списком товаров заказа, в свою очередь ссылающихся на номенклатурный справочник. На физическом уровне все атрибуты процесса сворачиваются в один XML-документ, который записывается в поле TEXT реляционной СУБД.

Такой подход реализован в BPMS от IBM, Oracle, TIBCO, и при первом знакомстве он выглядит очень привлекательно: удобная графическая среда моделирования структуры данных, собственные типы данных. В рамках демонстрации или пилотного проекта можно очень быстро смоделировать процесс данные и представить заказчику работающий прототип.

Однако в дальнейшем, в промышленной эксплуатации, возможны серьезные проблемы:

1) Неудовлетворительное быстродействие

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

Как будет вестись поиск на физическом уровне? Надо извлечь из база данных XML-документ, содержащий значения атрибутов, разобрать его, найти элемент «номер счета» и сравнить его с искомым. И так перебором по всем активным экземплярам процессов. Хорошо если их десяток. А если десятки тысяч - не затянется ли поиск в этом случае?

Сравниваем с тем, как эту задачу решает обычная реляционная СУБД: индекс на поле «номер счета» и практически мгновенный результат – поиск перебором не используется, время поиска слабо зависит от числа записей.

2) Нарушения ссылочной целостности

Единая и целостная база данных – «святой Грааль» разработчиков информационных систем. Доступ к данным может быть ограничен административно (правами), но технически все со всем надежно провязано. Единая база данных гарантирует, что если, скажем, процесс продажи ссылается на запись клиента, то последняя не может быть удалена – СУБД этого не позволит.

При хранении же данных в виде россыпи XML-документов ссылочная целостность, вообще говоря, не гарантирована.

3) Проприетарные интерфейсы

Данные, хранящиеся в реляционной БД стандартным образом, в виде строк и столбцов, максимально открыты для доступа. Вы можете быть уверены, что сможете при необходимости организовать к ним доступ, например, из корпоративной BI-системы – необходимые коннекторы там гарантированно найдутся.

В ответ вам могут сказать, что у BPMS есть API, через который можно добраться до данных. Это так, но во-первых, чтобы воспользоваться API, придется программировать – сравните с настройкой коннектора, в которой надо просто заполнить несколько полей: тип сервера, адрес, имя базы данных, имя пользователя и пароль.

Во-вторых, что вы будете делать, если сторонняя система, в свою очередь, представляет собой «черный ящик» - механизм взаимодействия со стандартной СУБД в нее заложен, а возможность запрограммировать доступ к произвольному внешнему источнику данных не предусмотрен?

3. Сущность-атрибут-значение

Известно, что любые сколь угодно сложные данные можно представить в виде таблицы из трех столбцов:

• идентификатор объекта
• идентификатор типа атрибута
• значение указанного атрибута для указанного объекта

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

Но при широкомасштабном использовании такая организация данных создает серьезные проблемы. Например, если на SQL легко можно реализовать join-запрос, соединяющий десяток таблиц, то в схеме “объект-атрибут-значение” такой запрос и запрограммировать на порядок сложнее, чем написать select в SQL, и быстродействие с ростом числа объектов быстро стремится к нулю.

4. Атрибуты в базе данных по ссылке

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

Наиболее последовательно такой отказ реализуется следующим образом: все атрибуты переносятся в таблицы реляционной БД, и у процесса остается один служебный атрибут – ссылка на первичный ключ записи в реляционной таблице, выделенной под данный процесс.

В результате такой миграции отмеченные выше проблемы с данными решаются, но увы, появляются новые – связанные с пользовательскими интерфейсами.

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

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

Отдельное «удовольствие» – перенос проекта (точнее, трех проектов) из среды разработки в эксплуатационную среду. Пока вы пользовались встроенными средствами BPMS, вы привыкли к тому, что это делается «от одной кнопки». Только отказавшись от встроенных средств, вы сможете по-настоящему оценить эту функциональность.

Все это очень печально с точки зрения методологии: вместо проекта BPM мы пришли к разработке процессно-ориентированного софтверного приложения.

Вы спросите, в чем разница? В вовлеченности бизнеса и в темпе.

Системы BPMS специально спроектированы таким образом, чтобы обеспечивать и то, и другое: логичная, замкнутая среда, органически увязывающая процессы, данные и пользовательские интерфейсы. Это не значит, что бизнес будет сам вести разработку (хотя такое мнение иногда высказывается, это наивное представление) – это и не требуется; достаточно того, что то, что делают в BPMS бизнес-аналитики и разработчики, обозримо и в целом понятно людям бизнеса. А значит, они способны критиковать, давать поправки и генерировать идеи о том, как на самом деле нам следует вести дела. В этом вся суть BPM, его сила.

Отказавшись от встроенных средств моделирования данных и разработки экранных форм, мы эти преимущества теряем.

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

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

Кроме того, вовлеченность невозможна без поддержания темпа разработки. Вы можете рассчитывать на заинтересованное участие бизнеса в проекте BPM только в том случае, если интервал времени от идеи по усовершенствованию процесса, высказанной бизнесом, до ее реализации, занимает дни, максимум недели. Месяцы – это уже все равно что никогда, потому что энтузиазм бизнеса за это время неминуемо угаснет.

Простота - это один аспект, обеспечивающий вовлеченность, темп - второй. Сменив встроенные в BPMS средства быстрой разработки на более трудоемкие, мы проигрываем и там, и тут.

5. Прямое использование реляционной базы данных

Хранение атрибутов в XML или в виде триплетов объект-атрибут-значение представляют собой попытку построить “СУБД поверх СУБД”. Спрашивается: не проще ли использовать реляционную СУБД напрямую, без надстроек?

Пример реализации такого подхода - система Bizagi BPM Suite. Как и в любой BPMS, в ней реализованы встроенные средства моделирования данных и разработки экранных форм. Точно так же вы моделируете бизнес-объекты, задавая атрибуты и связи между ними, и точно так же потом «набрасываете» атрибуты на холст, размечая экранные формы.

На физическом уровне все совершенно прямолинейно: сущности отображаются в таблицы, атрибуты - в столбцы таблиц. Каждому шаблону процесса соответствует таблица базы данных, а экземпляру процесса – запись в этой таблице. Помимо этих “процессных” таблиц, в базе данных есть справочники, мастер-данные,… - в общем, все, что мы обычно видим в БД корпоративной информационной системы.

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

При таком подходе разработчики процессного приложения не сталкиваются ни с одной из отмеченных выше проблем.

Можно предположить, что проблемы могли быть у разработчиков Bizagi: им пришлось встроить в BPMS функциональность средств разработки логических схем базы данных, реализовать отображение логической схемы в физическую, автоматизировать перенос схемы базы из среды разработки в эксплуатационную с сохранением данных. Но так или иначе, им это удалось – все работает достаточно стабильно.

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

Заключение

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

Но в любом случае, способ организации взаимодействия процессов и данных в системе BPMS является одним из важнейших аспектов ее архитектуры. Заранее просчитывайте плюсы и минусы выбранного вами решения – способы так или иначе компенсировать проблемы можно найти всегда. Хуже всего, когда архитектурные проблемы застают вас врасплох в середине проекта, и вам приходится перекраивать архитектуру в авральном режиме, ставя проект под угрозу провала.

Источник: BPM-блог Анатолия Белайчука