В сети имеется множество публикаций о том, ради чего стоит внедрить BPM в вашей компании. Как обычно формулируются преимущества, которые дает бизнесу внедрение BPM:
- Визуальное моделирование и выполнение бизнес-процессов.
- Набор готовых компонент для построения гибких бизнес-процессов.
- Взаимодействие с пользователем для выполнения ручных действий.
- Гибкость конфигурирования бизнес-процессов.
- Поддержка версионности бизнес-процессов.
Это не все, что можно упомянуть, но достаточно типичный набор преимуществ платформы.
На самом ли деле все так безоблачно? Не пора ли всем выбросить старые инструменты, и полностью перейти на новую платформу?
Я хотел бы рассказать о том, какие проблемы могут вас ожидать в процессе внедрения, а точнее — при разработке реальных приложений. Мои впечатления основаны на опыте работы с платформой IBM Websphere BPM, для определенности — с версиями с 7.5 по 8.5 включительно.
Рассмотрим перечисленные ранее пункты по порядку.
Визуальное моделирование
Чего мы пытаемся добиться? Чтобы аналитики, или даже бизнес-пользователи, могли нарисовать диаграмму процесса, которая затем будет выполнена ровно в таком же виде сервером. Или хотя бы могли понимать суть процесса, посмотрев на диаграмму, нарисованную кем-то другим.
Получаем ли мы то, чего хотели добиться? Скорее нет, чем да.
В чем тут корень проблемы? Я бы сказал, что их два:
- Предлагаемые языки моделирования процессов слишком примитивны для реальных задач, и требуются другие языки, чтобы создать реально рабочий процесс.
- Язык в виде диаграмм, вроде BPMN, плохо вписывается в типичный цикл разработаки программ.
Дело в том, что процесс, который выполняется в рамках BPM системы, почти никогда не сводится только к диаграмме, которую видит бизнес-пользователь или аналитик. К ней еще прилагается множество подробностей, лежащих на разном уровне детализации, которые так или иначе определяют поведение процесса. Это, например, данные, сопровождающие экземпляр процесса, или интеграция процесса с другими существующими системами. Все эти подробности как правило сводятся к коду на другом языке программирования.
Практика показывает, что без этих составляющих процесс практически бесполезен, и в тоже время, они на типичной BPMN диаграмме не видны.
С другой стороны, бизнес-процессы — это программное обеспечение, пусть и несколько необычное. Процессы имеют иметь достаточно длинный цикл разработки и сопровождения, причем удобство сопровождения достаточно быстро становятся важным. Также, весьма важным является управление изменениями в приложении вообще, причем в тесной связи с так называемыми issue tracking системами (например, JIRA). То есть, нам нужно знать, кто, когда, какие именно и зачем вносил изменения в процесс, и в рамках каких задач.
Таким образом, с одной стороны, у бизнес-пользователей создается скорее ложное впечатление, что они понимают логику процесса, часть которой от них скрыта в коде. С точки же зрения разработчиков представление в виде диаграммы лишь усложняет разработку, в первую очередь потому, что диаграммы плохо согласуются с жизненным циклом разработки, в том числе — с управлением изменениями.
Инструментарий
Теперь о поговорим о методах и инструментах для разработчика.
Если для традиционных средств разработки более-менее придуманы средства (например, рефакторинга), метрики и методики измерения, которые позволяют оценивать размеры проекта (в строках кода, обычно), и такие факторы, как покрытие тестами, число потенциальных ошибок на единицу кода, сложность кода, и многое другое, то при переходе к BPM о многом из этого можно забыть. Во всяком случае, мне неизвестны какие либо работы в этом направлении. Это в каком-то смысле отбрасывает разработку на много лет назад. Нужно заново учиться рефакторить, собирать статистику по проектам, и учиться оценивать их сложность и размеры, чтобы правильно планировать разработку.
Так, инструменты для анализа кода и автоматического рефакторинга, на практике не существуют. Хуже всего то, что само создание таких инструментов под большим вопросом. Представим себе достаточно типичный сценарий разработки на более традиционной платформе. У вас есть система версионирования, скажем SVN или Git, есть среда разработки (IDE), и есть другие инструменты. Так вот, если ваша любимая IDE чего-то не умеет, вы можете, как правило, либо разработать для нее расширение, либо применить сторонние инструменты непосредственно для работы с кодом. Например, copy&paste детектор, или любой другой инструмент, множество примеров которых известно нам с момента появления UNIX. Это стало возможным потому, что код вашей программы традиционно является просто текстом. Вы можете воспользоваться любым инструментом, и перенести измененный код обратно в Git, или просто собрать нужную статистику, провести анализ кода, и т.п.
В случае BPM такой подход вам недоступен, или сильно ограничен. Нельзя автоматизировать многие рутинные операции, и не всегда есть доступ для разработки сторонних инструментов автоматизации. Доступ к коду процесса хотя и возможен, но скорее теоретически — вы можете экспортировать процесс в виде набора схем BPMN, и применить различные инструменты для анализа кода — при условии, что сами их и разработаете.
В итоге такая тривиальная на традиционных платформах задача, как единообразное изменение свойств множества элементов диаграммы процесса вместо чего-то вроде Find&Replace выливается в унылую рутинную работу, которую можно сделать только руками, и которая заставляет вас ненавидеть этот инструмент уже через пять минут.
Ну и последнее, но вовсе не по важности. Если для более традиционных проектов вы умеете оценивать размеры создаваемого приложения (в строках кода, например), неформально, или согласно какой-либо модели типа CoCoMo, то в случае BPM вы оказываетесь в непонятной ситуации. У вас минимум два вида кода — диаграммы, и «обычный» язык программирования, возможно даже не один. Сколько времени нужно, чтобы нарисовать диаграмму процесса? От чего это зависит? В чем измерять «размер» и сложность диаграмм? И если для обычного кода вы можете применить известные модели для оценки трудоемкости, то для диаграмм подобные модели не построены и вопросы не имеют ответов.
Набор готовых компонент и повторное использование
Некоторые нужные компоненты для построения процессов: условия, параллельные ветки, ожидания, события конечно же имеются. Только вот их уровень является достаточно низким, а возможности комбинирования, и в итоге, повторного использования готовых компонент, оставляют желать много лучшего.
В процессе эволюции инструментов разработки и языков программирования способы создания повторно используемых компонент давно выработаны и более-менее устоялись. В основном они сводятся к типам данных и функциям над этими типами, а также к средствам композиции этих базовых элементов в законченное приложение.
Попробуйте, для примера, организовать в процессе цикл, пользуясь только стандартным набором средств. Вы как будто вернетесь во времена, когда в книгах по программированию еще рисовали блок-схемы — то есть, лет на 40 назад. Другой весьма типовой, но далеко не тривиальный случай — когда вам нужно организовать асинхронное взаимодействие с внешним для вас сервисом, то есть отправить ему запрос, и потом дождаться ответа. Даже если нужную вам логику вы можете реализовать — у вас вряд ли получится использовать ее повторно в другом похожем процессе, потому что реализация будет разбросана по приложению таким образом, что выделить повторно используемый компонент окажется невозможным. Причем корень зла в данном случае тривиален и лежит на поверхности: BPMN не содержит того, что называется «функции высшего порядка», если говорить терминами ФП. Или generics, если вспомнить ООП и Java. Вы не можете написать обобщенный компонент, например для сортировки списка, абстрагируясь от типа элемента списка. Вы не можете передавать функции (активные компоненты) как параметры. Тут нет способа описать метакомпонент, если можно себе позволить его так назвать.
На сегодня две парадигмы в виде функционального программирования и ООП можно считать преобладающими. В случае же с BPM таковых разработок нет, и текущее состояние теории прямо скажем, плачевное. Фактически, нет даже самой парадигмы — есть лишь некоторые практики, которые лишь с ограничениями могут быть рекомендованы к применению. Более того, если скажем функциональное программирование базируется на математике, и в некоторых случаях правильность программы может быть доказана формально, а в случае ООП и процедурного программирования иногда можно доказать правильность хотя бы частично, в случае BPM я не слышал про подобные работы.
Не определены и подходы к рефакторингу и тестированию процессов. Нет даже самого понятия рефакторинг. Все выгядит так, как будто разработчики инструмента считают, будто процесс строится раз и навсегда, и никогда не развивается. И в нем не бывает ошибок, технического долга, запахов и прочего.
При этом, поскольку процесс зачастую является набором параллельных активностей, и не может быть выполнен вне системы BPM, написание тестов также является задачей на сегодня не решенной. Имеющиеся для этого средства нельзя считать адекватными, при том что на сегодня тестировать можно только сервисы — т.е. синхронные компоненты процесса, для тестирования же самих процессов как BPMN-диаграмм (особенно с параллелизмом) автору никакие средства не известны (хотя они могут быть разработаны, имеющихся API для этого достаточно, но это задача непростая).
Поддержка версионности процесса
Все программы развиваются. Если программа не развивается — это скорее всего никому не нужная программа. Исключения бывают — но они очень редки. Это означает, что BPM процесс может и должен развиваться, и проходить через несколько версий. Эти изменения нужно отслеживать. Иногда мы развиваем две ветки приложения — скажем, багфикс для версии 1, и новую версию 2. Иногда нужно сливать изменения в них в одну версию.
Почему в случае с BPM все это получается плохо?
Во-первых, изменения плохо обозримы. Исходным видом диаграммы является не текст, а картинка. Квадратики, стрелочки, ромбики. И в сравнении с обычным кодом в виде текста, который как правило одномерный, и для которого давно определены всякие операции типа diff/merge/patch и пр., тут добавляется несколько новых измерений. Например, цвет раскраски квадратиков, или их взаимное расположение на листе. Вы получаете значительный уровень информационного шума, просто потому, что часть изменений диаграммы ровным счетом не влияет никак на ее работу.
В итоге, у нас нет такой простой и очевидной возможности, которую со времен unix принято называть словом diff. Вы не можете просто и автоматически сравнить две разные версии процесса между собой, на разных уровнях подробности (т.е. приложение, диаграмма процесса, компонент, часть диаграммы, строка кода на каком-либо языке).
В лучшем случае вы знаете, что такого-то числа такой-то пользователь изменил некий диаграмму. Что именно, зачем, и в чем собственно состояло изменение — вы узнать не можете, или это затруднительно. Все что имеется — это возможность открыть (для чтения), и посмотреть, как выглядела конкретная версия. При этом данный процесс вовсе не быстрый. И самое существенное — вы видите не разницу, вы видите либо одну, либо другую версию кода. Сравнивать и понимать, где есть различия — это ваша задача, и она оказывается совершенно нетривиальной.
И вторая привычная возможность — это merge или хотя бы patch. Она также отсутствует де-факто. Вы не можете перенести изменения из одной ветки в другую, из одной версии в другую, в том числе — выборочно, сохранив изменения, внесенные в обеих ветках. Практически это лишает ветки какого-либо смысла. По той же причине, если какое-то изменение было сохранено и попало в Tip, откатить его обратно можно только на уровне крупного компонента (сервиса), вероятно потеряв при этом другие, полезные изменения.
Таким образом, те средства сравнения и слияния, которые имеются, явно недостаточны.
Соответственно, когда мы говорим о гибкости бизнес процессов — мы всегда должны иметь в виду только что рассмотренную проблему. Мы можем менять процесс как угодно гибко — но мы очень редко при этом будем точно знать, что конкретно поменялось. И когда что-то сломается — поиски причины могут вылиться в длительные раскопки в коде.
Итак, кратко просуммирую еще раз некоторые проблемы:
- Визуальное моделирование и выполнение бизнес-процессов — частично. Модель не отражает реальности для аналитика, и неудобна для разработчика.
- Набор готовых компонент для построения гибких бизнес-процессов — нет. Средства создания компонентов неадекватны.
- Поддержка версионности бизнес-процессов — частично. Средства неадекватны.
Другими словами, бизнес процессы в виде BPMN диаграмм, являются достаточно гибкими и простыми в понимании скажем для аналитиков, но при этом диаграммы весьма ограничены как средство разработки.
А что у других?
Так сложилось, что в текущем проекте мне пришлось столкнуться с очень в чем-то похожим продуктом. Это MS Business Intelligence Development Studio, и то, что в ней разрабатывают — System Integration Services. И вот что очень характерно — этот совершенно другой продукт, сделанный другой компанией для других задач, пытается в чем-то достичь тех же целей, и сталкивается ровно с теми же проблемами.
- Визуальное моделирование ETL процессов относительно хорошо работает, пока пишешь их с нуля. Как только пытаешься перейти от версии к версии — знакомые проблемы, такие же как и у BPMN.
- Также плохо с поиском и навигацией внутри проекта.
- Создание повторно используемых компонентов в таком же зачаточном состоянии. Переиспользование — близко к нулю.
- Все также плохо с рефакторингом, с применением сторонних инструментов для работы над проектом.
Какой вывод я для себя сделал — думаю вполне понятно. Буду держаться подальше от подобных инструментов, по мере возможности. Если же у вас сложились другие впечатления о практической работе с BPM, или скажем SSIS, я предлагаю рассказать о них в комментариях, и надеюсь, что обсуждение будет нам все полезно.
Автор: sshikov
