- Визуальное моделирование и выполнение бизнес-процессов.
- Набор готовых компонент для построения гибких бизнес-процессов.
- Взаимодействие с пользователем для выполнения ручных действий.
- Гибкость конфигурирования бизнес-процессов.
- Поддержка версионности бизнес-процессов.
Это не все, что можно упомянуть, но достаточно типичный набор преимуществ платформы.
На самом ли деле все так безоблачно? Не пора ли всем выбросить старые инструменты, и полностью перейти на новую платформу?
Я хотел бы рассказать о том, какие проблемы могут вас ожидать в процессе внедрения, а точнее — при разработке реальных приложений. Мои впечатления основаны на опыте работы с платформой 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. Она также отсутствует де-факто. Вы не можете перенести изменения из одной ветки в другую, из одной версии в другую, в том числе — выборочно, сохранив изменения, внесенные в обеих ветках. Практически это лишает ветки какого-либо смысла.
Соответственно, когда мы говорим о гибкости бизнес процессов — мы всегда должны иметь в виду только что рассмотренную проблему. Мы можем менять процесс как угодно гибко — но мы очень редко при этом будем точно знать, что конкретно поменялось. И когда что-то сломается — поиски причины могут вылиться в длительные раскопки в коде.
Итак, кратко просуммирую еще раз некоторые проблемы:
- Визуальное моделирование и выполнение бизнес-процессов — частично. Модель не отражает реальности для аналитика, и неудобна для разработчика.
- Набор готовых компонент для построения гибких бизнес-процессов — нет. Средства создания компонентов неадекватны.
- Поддержка версионности бизнес-процессов — частично. Средства неадекватны.
Другими словами, бизнес процессы в виде BPMN диаграмм, являются достаточно гибкими и простыми в понимании скажем для аналитиков, но при этом диаграммы весьма ограничены как средство разработки.
А что у других?
Так сложилось, что в текущем проекте мне пришлось столкнуться с очень в чем-то похожим продуктом. Это MS Business Intelligence Development Studio, и то, что в ней разрабатывают — SQL Server Integration Services. И вот что очень характерно — этот совершенно другой продукт, сделанный другой компанией для других задач, пытается в чем-то достичь тех же целей, и сталкивается ровно с теми же проблемами.
- Визуальное моделирование ETL процессов относительно хорошо работает, пока пишешь их с нуля. Как только пытаешься перейти от версии к версии — знакомые проблемы, такие же как и у BPMN.
- Также плохо с поиском и навигацией внутри проекта.
- Создание повторно используемых компонентов в таком же зачаточном состоянии. Переиспользование — близко к нулю.
- Все также плохо с рефакторингом, с применением сторонних инструментов для работы над проектом.
Какой вывод я для себя сделал — думаю вполне понятно. Буду держаться подальше от подобных инструментов, по мере возможности. Если же у вас сложились другие впечатления о практической работе с BPM, или скажем SSIS, я предлагаю рассказать о них в комментариях, и надеюсь, что обсуждение будет нам все полезно.
Комментарии (46)
filkt
22.10.2016 21:50+4Надеюсь мой комментарий на сочтут за грубость,
What the fuck am I reading?
sshikov
22.10.2016 21:52Не сочтут, но может все-таки поясните, в чем проблема?
На мой взгляд, если вы скажем не поняли, о чем пост — ну так и что? Есть много разных тем, далеко не все из них должны быть понятны всем — как и интересны, впрочем.
AstorS1
22.10.2016 21:58Мне показалось, что это было намёком о том, что статью было бы предпочтительнее разместить не в «Разработке», а хотя бы в «Управлении».
sshikov
22.10.2016 22:04Я возможно плохо сформулировал, но этот пост ни разу не об управлении. Речь идет о вполне конкретных программных продуктах, на базе которых разрабатываются BPM системы. И о том, что сама эта парадигма процессов, которые пытаются рисовать в виде картинок, очень плохо годится для того, чтобы в ней разрабатывать. А если уж совсем просто — о том, что программировать в картинках получается как правило плохо.
Так что нет, это вовсе не про управление и совсем не для управленцев.
freetitelu
22.10.2016 22:54+1Сама-то по себе идея идет в верном направлении, т.к. человек мыслит больше образами, чем символами. К примеру, есть вполне работоспособные прикладные реализации «программирования мышкой» типа блюпринтов в «Unreal Engine». Только тут, при взаимодействиях, идет столкновение квалификаций. С одной стороны заказчик, которому до лампочки все эти абстракции. А с другой — код таки должен решать его проблемы и без понятий, которые не засунешь в картиночки, не обойтись. Лучше старых добрых «многабукаф» пока не придумали.
Vjatcheslav3345
24.10.2016 12:29А есть такие BPM-системы, в которых отказались от графики в пользу кода?
freetitelu
25.10.2016 11:33(Ну как бы графика — это фича BPM) BPM — инструмент управления автоматизацией бизнес-процессов таким образом, чтобы это управление осуществлялось силами сотрудников, не имеющими образования в сфере программирования. Там, где его не хватает, появляется еще что-то для расширения (или в обход) BPM. То есть, если формат, выбранный конкретной системой не решает задачу, программировать все же придется (к примеру, для интеграции с внешними системами, или для создания не предусмотренного изначальными разработчиками пользовательского интерфейса). И это не значит, что BPM отказалась от графики. Просто в конкретном случае пилят костыли.
sshikov
25.10.2016 19:31Я бы так ответил — есть системы, где взаимоотношения между кодом и «картинками» более правильные для разработки. Например, тот же Apache Camel, где по сути мы имеем в основе т.н. EIP, Enterprise Integration Patterns, почти такие же диаграммы, что и в BPMN.
Разница в том, что первичным является DSL (как скажем java, так и xml), из которого строится диаграмма. А когда вы хотите на нее посмотреть — вы можете это сделать в виде картинки. Вы можете их в таком виде поотлаживать, или посмотреть статистику по квадратикам. А вот редактировать диаграмму в картинках совершено лишнее.
prolis
22.10.2016 23:17Это статья типа ещё один что-то не понял и решил этим незнанием поделиться. Ну не смогли экземляр процесса загнать в бесконечный цикл штатными средствами или продолжить выполнение потока по триггеру/событию — спросите где-нибудь, а не пишите в духе «bpm от а до я».
sshikov
23.10.2016 09:40-1Я за три с половиной года всего-то поучаствовал примерно в десятке проектов для десятка банков РФ, начиная со Сбербанка и заканчивая Тиньковым, а по дороге еще Райффайзен с РСХБ например захватили. И все еще не понял. Ну зато вы-то видимо все поняли?
Можете поделиться своими сокровенными знаниями о том, как это круто? Как легко рефакторить диаграммы? Как быстро понять, какие измеения за неделю внесли в ваш процесс? Как слить две ветки изменний? Как легко писать юнит-тесты, наконец.
Я с радостью почитаю.
prolis
23.10.2016 17:58-1Вопросы дизайна и деплоя процессов решаются ещё «на берегу» при выборе bpm-инструментария. Если процесс внесения изменений в процесс состоит из сброса графических схем программисту, то это опять же, проблема самого процесса управления процессами, а не всей управленческой концепции BPM.
sshikov
23.10.2016 18:18Ничего не понял из вашего ответа. Вы похоже про что-то другое говорите, совсем.
realbtr
22.10.2016 23:20Можно и чайником гвозди забивать, конечно. BPM имеет очень утилитарное назначение, которое некоторые энтузиасты наивно пытаются расширить. BPM это способ абстрагировать бизнес-логику взаимодействия с системой от реализации прикладного функционала. Ошибки в проектировании архитектуры и необоснованный энтузиазм разработчиков часто соблазняют заменить саму архитектуру неким BPM суррогатом. Если Вы не консультант-аналитик, внедряющий корпоративную систему, BPM — не Ваш инструмент. Разработчик должен уметь разрабатывать сервисы, модули и компоненты, управляемые BPM.
NikitOS9
23.10.2016 08:35было дело участвовал в процессе интеграции одной из этих bpmn с банковской конторой, понял так;
например приходит новый работник к большую контору, можно ему выдать кучу инструкций как и в каком порядке выполнять свою работу, слать задания по мылу, скайпу, словами и тд… но как быстро он прочитает эти инструкции и запомнит все правильно.
либо занести юзера в bpmn систему, при выдаче ему нового задания оно появляется с списке заданий юзера, по мере выполнения этапов задание будет продвигаться, этапы могут зависеть от задач других юзеров и тд…
есть общий алгоритм работы предприятия, он разбивается на подзадачи, которые могут еще более мелко делиться, юзеры выполняют свои части и в итоге типа все знают что делать, отмечают ход выполнения заданий, либо не выполнения и причину.
получается еще один способ систематизировать большую сложную систему предприятия.
ну и для начала нужно правильно составить описание все процессов и разные связиsshikov
23.10.2016 09:50Вы смотрите на это с другой стороны. Да, для бизнеса все возможно так и выглядит. Я же рассказываю историю с точки зрения разработчика.
Во-первых, описание большого процесса нельзя составить сразу — оно строится постепенно, от версии к версии — как любой достаточно сложный программный продукт. Во-вторых, очень желательно, чтобы повторяющиеся куски процесса можно было оформить как готовый компонент, и потом переиспользовать их в других местах.
И вот со всем этим у схемок и картинок — большие проблемы.
NikitOS9
23.10.2016 10:27+1я участвовал как разработчик, рассказываю свое понимание зачем нужны подобные системы.
по нормальному, составлять модели бизнес процессов должны люди которые в теме работы данного предприятия, а не разработчики.
эти картинки и схемы нужны на стадии как раз составления бизнес процессов, дальше их видеть не обязательно, юзеру приходят только его задания, абстракции вобщем.sshikov
23.10.2016 13:49+2А что изменится, если составлять будут люди в теме?
дальше их видеть не обязательно
Простите, но это означает, что процесс у вас никогда не меняется. А так не бывает.
Представьте скажем вот такой простой случай — сидят у вас два человека в теме, и рисуют диаграммы. Потом вы на них смотрите, и видите, что они делают в сущности одно и тоже. В нормальной среде разработки вы можете а) сравнить два куска кода между собой б) выполнить рефакторинг, выделив повторяющиеся куски в) натравить на код анализ, который например покажет вам copy&paste.
Так вот, ничего из этого вам для диаграмм (BPMN тут частный случай, с другими все примерно также) не доступно. А код, который развивается путем copy&paste, и не рефакторится, практически неизбежно со временем становится говнокодом. И перестает поддерживаться.
NikitOS9
23.10.2016 16:34>Простите, но это означает, что процесс у вас никогда не меняется. А так не бывает.
походу понимание так и не пришло,
да хоть 100 раз в неделю пусть меняется, юзерам это пофик к ним приходят конкретные задания, а что там творится с диаграммами в целом они даже могут не знать.sshikov
23.10.2016 17:09+2Юзерам это да, пофиг. А вот IT и разработчикам — вовсе нет. Вот простой кейс, ваш процесс скажем сломался. Вчера работало. Перед вами стоит задача — найти причину и пофиксить.
В случае "нормального" классического кода я вам скажу, что буду делать — я залезу в Git, и посмотрю, какие коммиты были, кто и зачем их делал, какие части системы они затронули. Я тупо сравню код, наконец. А теперь расскажите мне, как вы сравниваете BPMN? Только очень прошу — не надо про то, что это XML, потому что это НЕ xml. Если вы вынуждены лезть на уровень xml, чтобы понять, что именно изменилось в процессе — ваша IDE для разработки процессов — барахло.
И имено про такие инструменты я и пишу. Которые не умеют скажем сравнивать две версии процесса.
NikitOS9
23.10.2016 17:18что значит процесс сломался, ломается инструмент которым процесс создается и отслеживается.
VolCh
23.10.2016 23:48Процесс — это, по сути, программа, выбирающая что юзеру показать, что у него спросить. Вчера после имени клиента спрашивала фамилию, а сегодня спрашивает сразу телефон.
absente
23.10.2016 09:41Я бы понял, если вы обхаяли 1C, сравнив его с другими языками программирования. Но BPM это лишь концепция, описание.
Какой вывод я для себя сделал — думаю вполне понятно. Буду держаться подальше от подобных инструментов, по мере возможности.
Я так понял, вы не будет теперь заниматься разработкой, связанной с автоматизацией бизнес-процессов?
Какой разработкой вы решили заниматься?sshikov
23.10.2016 09:44Вы название IBM BPM в самом начале видели? А конкретные версии? Это вовсе не концепция. Это конкретный продукт, платформа для создания систем. И все что тут написано, как вы выражаетесь, "для обхаивания" к нему относится в полной мере. Это в обсновном про него. Хотя насколько я знаю скажем Pega — там ровно тоже самое.
sshikov
23.10.2016 09:59Да, и ответ на вопрос — отойдя в строну от решений IBM, в том числе от их "шины", которая входит в состав BPM в том числе, я практически сразу отметил для себя, что Open Source решения в данном случае совсем не уступают коммерческим. И уж точно намного удобнее в разработке. Например Apache Camel, в качестве основы для построения своей шины.
А будет позарез нужен BPM — возьму Activity. Даром. Там много чего нет, и там есть все теже присущие концепции недостатки, кстати. Но там все равно проще.
Dimly
23.10.2016 19:38Ой, ну вот таки сразу 1С крайняя.
Вы знаете, а завидуйтека молча. 1С хают только те кто не умеет ей пользоваться. У меня она ни разу не вызывала негативных откликов. Разрабы платформы — да, язык и невероятно удобная среда разработки и отладки — нет. И многих преимуществ 1С весьма не хватает у всех остальных.
BPM может быть и концепция, но вот Oracle BPMN это уже таки реализация. И честно говоря — пост имеет своей целью «резюме».
Визуальное моделирование и выполнение бизнес-процессов — частично. Модель не отражает реальности для аналитика, и неудобна для разработчика.
Набор готовых компонент для построения гибких бизнес-процессов — нет. Средства создания компонентов неадекватны.
Поддержка версионности бизнес-процессов — частично. Средства неадекватны.
По первым двум пунктам согласен целиком, несмотря на то что работаю с продуктом Oracle. То что продается как «фишка» — участие аналитиков в разработке путем создания макета процесса, на деле оказывается сладкой упаковкой пустышки. Потому что после реализации конечная модель едва ли похожа на упрощенное представление аналитиков.
А вот простейший контроль версий, тот же Git, прикрученный к среде разработки — позволяет отследить кто когда что менял. Детали же проделанных изменений обязаны быть в сопроводительных документах. Если разработчики только меняют код, и не документируют его ни комментариями (что в BPMN нереально) ни дополнительной документаций — вините не среду разработки, а разработчиков.
kefirfromperm
24.10.2016 08:29Мы сравнивали много: IBM BPM, JBoss BPM Suite (jBPM), Pega, Activiti, Bonita. Кровавыми слезами разработчиков не заставляла плакать только Bonita, но и у неё есть все те же недостатки, которые описаны в статье.
NikitOS9
23.10.2016 10:03еще существуют BPMN Process Simulation Tool, описывается модель процессов и запускается симуляция, это должно выявлять неоптимальные узлы.
можно выставить желаемые значения в узлы и ждать условия их появлений и тд…sshikov
23.10.2016 13:57Вы как будто пытаетесь меня убедить, что процессы и их формализация полезны.
Так я с этим и не спорю, что характерно. Я лишь пытался показать, что существующие инструменты работы с ними, в частности BPMN, страдают рядом принципиальных недостатков, которые мешают делать из диаграммы процесса работающий софт.
NikitOS9
23.10.2016 16:40кого убеждать и зачем
>Если же у вас сложились другие впечатления о практической работе с BPM, или скажем SSIS, я предлагаю рассказать о них в комментариях, и надеюсь, что обсуждение будет нам все полезно.
вот этим я занимался и прочитать ссылку на sql.ru ниже стоит, многое прояснится
NikitOS9
23.10.2016 10:43достаточно хорошо чел высказался по теме в этом сообщении, в целом там весь топик полезный имхо
http://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=1141037&msg=18646109
BansheeRotary
23.10.2016 15:30+2Полностью согласен с изложенным. Сам неоднократно сталкивался с этой проблемой — в основном в визуальных инструментах ETL, но и в BPM системах тоже. Визуальный инструмент разработки красив на презентациях, обеспечивает быстрый quick start для людей, не имеющих опыта написания кода, но в мало-мальски сложном внедрении быстро становится ограничением — не хватает хорошей отладки, гибкости, абстракций. Кроме того, когда начинаешь дописывать код, часть системы, управляемая визуальным конструктором, обычно остается плохо документированным черным ящиком, с которым приходится работать методом проб и ошибок.
С другой стороны, понятно, откуда это все берется — любой заказчик старается избегать кода при внедрении, и для вендора проще сделать визуальный конструктор (причем в некоторых случаях реально абы-как), чем объяснять, как должен выглядеть зрелый процесс поддержки конфигурации системы.
Допускаю, что могут быть кейсы, где визуальные конструкторы хороши, но они тогда должны покрывать 95% нужной функциональности — а это точно не про enterprise внедрения.
nApoBo3
23.10.2016 17:09+2ИМХО или автор не разобрался или работал с плохими инструментами. У BPM есть проблемы, но со статьей они коррелируются слабо.
Визуальное моделирование не преследует цель во всех подробностях изобразить процесс. Его задача мост между кодом и бизнес процессом. Всегда есть компромисс между сокрытием деталей реализации в коде и отображении их в процессе. Если мы его не соблюдаем, мы получил или не читаемый процесс перегруженный деталями реализации или не понятный процесс с целый слоем бизнес логики сокрытым на уровне кода. При разработке «классических» приложений с бизнес логикой в коде, такой проблемы нет, бизнес логика скрыта от пользователя всегда, и как это не прискорбно, очень часто представляет из себя нагромождение костылей. Почему так, потому что когда мы пытаемся формализовать процесс выплывает такая куча нюансов, что учесть их все в стройной не противоречивой модели очень и очень сложно, вот их и закапывают в код. Потом это становиться не поддерживаемой, или поддерживаемой за безумные деньги, системой. С bpm такой фокус не проходит, эта проблемы переноситься с этапа поддержки, на этап проектирования. Это вызывает множество проблем, поскольку заказчику или сразу видно, что процесс не соответствует реальности, или что не читаем и содержит костыли на каждом шагу. Такое продать сложно, проще указать в ТЗ требования, а потом реализовать их через одно место и все довольны.
По остальным пунктам, единственно что соответствует действительности, это отсутствие средств рефакторинга.
Bpmn это не диаграмма, и не графический файл, а текст, xml подобный документ, все доступное для любого текста доступно и для bpm, версионность, jira, find and replace, все естественно есть.
Нужны плагины, не устраивает IDE, нет проблем пишите плагины или вообще напишите полностью свой инструмент. Для примера BPMN можно «разрабатывать» в eclipse.
В используемом нами движке есть не только версионность процесса, на уровне git, но и параллельное исполнение процессов разных версий и средство миграции процессов с одной версии на другую.
Покрытие тестами. Хм, с тем движком с которым работаем мы bpm процесс замечательно покрывается тестами.
Оценка трудозатрат на рисование bpm диаграммы вообще странный пункт, а как вы оцениваете в своих проектах трудозатраты на документирование и описание бизнес процессов заказчика. Это собственно говоря одно и тоже, за исключение специфического языка описания.
Асинхронное взаимодействие, чем оно будет отличаться от аналогичного в «классическом» приложении? В bpm это будет выглядеть или как сервис таск плюс ожидание сообщения, или как отправка и получение сообщения. За ним стоит повесить любую очередь, хоть то же rabbitMQ. Пример с сортировкой списка вообще странный, сортировка списка не есть часть бизнес процесса, она замечательно скрывается на уровне кода.
Похоже или у автора инструменты из кровавого энтерпрайз в которых сюда нельзя туда нельзя и все посыпано сверху SAP'ом, или он не умеет их готовить.
Как мне кажется, главная проблема bpm это высокая сложность описания процесса с сохранением его читабельности. Плюс восприятие, код не нужен, что в корне не верно.
sshikov
23.10.2016 17:19Хм. Я честно говоря, даже не знаю, что вам ответить. С одной стороны, вы вроде считаете, что автор не разобрался, и как бы возражаете ) А с другой — изложенные вами в последнем абзаце проблемы — это по сути и есть те проблемы, о которых я пытался написать, только в профиль, с другой точки зрения.
Плюс восприятие, код не нужен, что в корне не верно.
Ну вот скажем эта. Имено что код нужен, что диаграммы сами по себе не являются законченным работающим процессом. В тех процессах, что я видел и делал, кода было процентов 80% наверное. И только в виде кода можно делать компоненты, которые потом можно повторно переиспользовать — попытки делать их в виде процессов приводят к ужас-ужас.
Ну и так, для ясности — я все-таки излагал свой опыт работы на IBM BPM, и он довольно не новый (я это написал почти три года назад). Если на вашем движке сейчас все уже не так — остается только порадоваться.
nApoBo3
23.10.2016 20:19Ну вот скажем эта. Имено что код нужен, что диаграммы сами по себе не являются законченным работающим процессом. В тех процессах, что я видел и делал, кода было процентов 80% наверное. И только в виде кода можно делать компоненты, которые потом можно повторно переиспользовать — попытки делать их в виде процессов приводят к ужас-ужас.
А зачем делать их в виде процессов? BPMN существует не для замены языкам типа java.sshikov
23.10.2016 21:06Ну как бы вопрос стоит немного иначе — при опредеделенном размере процессов (а мы на такой размер вылезали на каждом первом проекте) конструкция в целом перестает быть обозримой. Я согласен, что частично это последствия того, что у IBM (Lombardi) принято делать в виде BPMN диаграмм все подряд, включая например обработчики событий UI. И возможно на других движках все было бы приличнее. Диаграммы более компактные, логика — в java, или веб-сервисах.
Но так или иначе — повторяющиеся фрагменты процессов на практике все равно бывают, и хочется их как-то оформить. То как это можно сделать — не всегда адекватно потребностям.
Altaisoft
23.10.2016 21:06Мне не приходилось внедрять BPM на практике, изучал его только теоретически — читал книги, спецификацию BPMN, смотрел продукты типа BizAgi, читал ругательные статьи о том, что BPMN не имеет под собой математического формализма, — и пытался понять, как всё это может быть мне полезно. Так что этот комментарий можно считать диванным теоретизированием.
Статья перекликается с постом The Churn by Robert C. Martin: http://blog.cleancoder.com/uncle-bob/2016/07/27/TheChurn.html Среди всего прочего, Роберт Мартин указывает на то, что всякий новый язык или технология неизбежно лишены тех средств разработки, анализа кода, тестирования и рефакторинга, что уже созданы для языков предыдущего поколения, и потому продуктивность разработки на новом языке по определению ниже. Ну, для BPM проблема усложняется ещё и добавлением дополнительных измерений, как вы указали.
А теперь следующий вопрос. А почему, собственно, нужно бросаться из крайности в крайность и отказываться от нормальных средств разработки? BPMN-диаграмма — это исполняемая программа, написанная на визуальном языке. Пользователи и аналитики в большинстве случаев не могут изменять эту диаграмму так, чтобы при этом покрывать изменения юнит-тестами и гарантировать, что в остальных частях системы ничего не сломается. Таким образом, модифицирующая функция BPM не очень работает. Но зато визуальная схема, то есть, — функция документирования и мониторинга, — сама по себе была бы очень полезна для понимания логики системы и происходящих в ней сию секунду процессов даже в самых простых системах, где внедрять BPM никто и не собирался, а рисовать это всё руками не имеет смысла. Почему бы не сделать следующим образом.
- Логика процесса реализуется в коде приложения на разработанном для этих целей DSL, имеющем такие сущности как задача, условие, цикл, начало или конец процесса, подпроцесс. Контроль типов, статический анализ, отладка, тестирование, рефакторинг — всё на месте. Пример библиотеки для Python: viewflow. Не искал ещё аналога для Scala, — думаю, там можно сделать многократно красивее.
- Такие вещи, как определение текущего шага для данного пользователя, или вывод всей схемы в графическом виде с иллюстрацией её состояния в реальном времени — делаются автоматически, что резко упрощает документирование системы. Разумеется, возможны аннотации типа стилей схемы или расположения квадратиков, но в целом визуальная схема целиком определяется тем, что в коде написано.
У BPM есть одна (потенциальная) возможность, которая вроде бы есть шаг вперёд по сравнению с традиционной разработкой: если изменить процесс с версии 1 на версию 2, то в зависимости от возможности и необходимости можно либо 1) продолжать выполнять старые уже запущенные процессы на версии 1, а новые запускать уже на версии 2, — либо 2) перевести старые процессы на версию 2 прямо в процессе выполнения. Мне представляется, что такую возможность можно и без BPM реализовать, это зависит исключительно от того, насколько хорошо система разбита на компоненты и как они друг с другом взаимодействуют. Запустить две копии одного компонента, где в одной будет старый код, а в другой новый, и разделять по ним процессы — совсем не за гранью возможного. И всё это — с контролем типов, рефакторингом, etc.
Что вы думаете о таком подходе, и как вы относитесь к перспективам использования DSL в системах автоматизации бизнес-процессов в принципе?
sshikov
23.10.2016 21:15+2Собственно, если мне придется сегодня делать бизнес-процессы снова, я примерно так и стал бы поступать, как вы предлагаете. Т.е., в виде BPMN/диаграмм вообще делать минимально необходимое для понимания пользователями описание процесса. А еще лучше — именно DSL. Показ схемы в виде картинок — на основе анализа кода. Т.е. схема — вторична, а код первичен. Это примерно то, что я сегодня имею например в Apache Camel.
И это тот вариант, к которому постепенно приходишь. Просто в рамках конкретной реализации и ему следовать было достаточно сложно.
Ну и насчет миграции. Далеко не всегда это возможно. Во-первых, запущенный процесс версии 1 может быть на таком шаге, которого в версии 2 вообще нет. И во-вторых, у новой версии процесса могут быть новые данные, которые старая версия не хранила. И взять их далеко не всегда возможно — скажем, потому, что предыдущих шагов, которые их создают, процесс не выполнял. Так что миграция — это не то чтобы миф, но далеко не всегда возможное в реальности действие.
ncix
23.10.2016 21:30+2Я некоторое время назад перешел из классической разработки в разработку под одну bpm-платформу в компании-интеграторе. Задачи у заказчиков на самом деле абсолютно те же что и в любом другом бизнесе. Только отличается масштаб и стоимость на 2-3 порядка. И есть некоторые правила игры, которые кроются за загадочным, одетым в дорогой костюм, словом «бизнес-аналитик». На самом деле эти ребята ничего такого сверхъестественного не знают и не умеют — системное мышление, знание практик и обязательно трендовых кодовых словечек, вроде BPM, BI, SFA, шины, которые сыпятся из их ртов как из рога изобилия. Зачарованный заказчик отдает немалые деньги, а потом самые обычные программеры седеют, пытаясь понять чего нужно делать, успеть во «вчерашние» сроки, обойти все грабли и стены в платформе чтобы впилить нужную заказчику «хотелку».
Там выше упомянули 1С, это очень хороший пример того, что бизнес-аналитик может быть программером и это очень эффективное сочетание навыков. По факту любой более-менее опытный 1С-ник является бизнес-аналитиком, только еще и сам потом все это реализует в коде. Ну и ездит на машине подешевле и одет попроще.
Но большой бизнес хочет «больших» систем, просто таковы правила игры. Которые кстати уже трещат по швам.
dim2r
23.10.2016 23:21Интересно, есть ли в природе инстументарий, который проверяет непротиворечивость требований бизнеса?
Например, есть такие требования:
1)«для всех договоров из продукта1 делать проводки на счет 123»
2) «для всех договоров для физ лиц делать проводки на счет 456»
нужно что бы автоматически нашлось противоречие, так как могут быть договора продукта1 для физ лиц. Как делать проводки при этом — непонятно.kefirfromperm
24.10.2016 11:52Этим занимаются системы класса BRMS (Business Rule Management Systems). Там обычно по приоритету применяются правила. Ну или задается стратегия разрешения конфликтов.
asushko
24.10.2016 12:20Рекомендовал бы вам посмотреть тематику «Ad-hoc process» и «Ad-hoc Workflow».
Это довольно сырая и неизученная область моделирования бизнес процессов, идейные вожди в этой области Aalst, Alonso. По ихнему мнению, при увеличении гибкости бизнес процессов, возрастает ихняя сложность, элементарная жизненная закономерность.
Из этого следует, чтоб увеличить гибкость процессов, необходимо разбить процесс на возможно простые и легко замещающие себя части.
Те чтобы добиться «гибкости» бизнес процессов, необходимо продумать стратегию борьбы со «сложностью».
Есть классификация бизнес процессов по возрастанию гибкости, соответственно ихней сложности:
http://static.flickr.com/5136/5531596297_7a1f3e3b1c.jpg
Соответственно Вам стало не комфортно на первом уровне и вы пытаетесь перескочить на следующий, уволакивая за собой уровень «сложности» с предыдущего, который не подходит к следующему.
Чтоб комфортно себя чувствовать на определенном уровне сложности, необходимо решить какая степень гибкости бизнес процессов необходима под поставленные задачи и отсюда решить хватит ли ресурсов решить проблемы со сложностью для данного уровня гибкости. Те необходимо соблюсти баланс этих двух понятий, выстроить мост между «сложностью» и «гибкостью» бизнес процессов.
Касательно описанных проблем, добавил бы необходимость проверки модели бизнес процесса после внесенных изменений на ее «живучесть», в эволюции не всегда без уродов. Дабы исключить при перескакивании на новую версию элементарных dead или livelock
A-Stahl
> Программирование*
> BPM
Я боюсь спросить, но всё-таки спрошу, а что это вообще такое этот ваш ВРМ (это вообще аббревиатура кириллическая или латинские литеры)? А то мне, программисту, из контекста первого абзаца не понятно. Какие-то бизнес-процессы. Попроще можно? Для сишников…
sshikov
Business Process разумеется. Есть варианты прочтения буквы M, но обычно все-таки management.
freetitelu
ну очевидно же, что это beats per minute… вообщем что-то про Управление в музыкальной индустрии )