BPMS или просто программирование?

Question

Что вы предпочитаете (с точки зрения разработчика) при реализации бизнес-процесса?

Система управления бизнес-процессами (BPMS) или просто ваша любимая IDE с необходимыми инструментами и платформами (например, инструментом отчетности)?

В чем, с вашей точки зрения, заключается наибольшее преимущество BPMS по сравнению с IDE с вашими личными инструментами и платформами?

ХОРОШО.Возможно, мне стоит быть более конкретным...Я познакомился с одной конкретной BPMS, которая должна упростить реализацию бизнес-процесса путем настройки правил.Но мне как разработчику тяжело работать с системой.Я хотел бы работать с текстовыми файлами, которые я могу реорганизовать, и я хотел бы иметь возможность выбрать правильную технологию или структуру для своей работы.Вместо этого система заставляет меня настраивать.

Есть правила, по которым я могу использовать Java, но даже в этом случае мне приходится придерживаться системного редактора без IntelliSense и т. д.

Итак, это подводит меня к ответу на мой собственный вопрос - я хотел бы использовать инструменты, к которым я привык, вместо того, чтобы учиться работать с BPMS (по крайней мере, с той, которую я знаю), потому что это меня больше ограничивает, чем помогает. .Знаемая мне BPMS — это структура, из которой трудно выбраться!В настоящее время я бы предпочел инфраструктуру, подобную Grail, любой известной мне BPMS.

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

Answer 1

Не уверен, что именно вы спрашиваете, но выбор BPM vs.простое программирование будет зависеть от требований.«Бизнес-процесс» — относительно расплывчатый термин в разработке программного обеспечения.

Вот несколько критериев для оценки ваших потребностей:

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

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

Между простое программирование и полноценное BPM-решение (например. Пакет Oracle BPM который содержит БПЭЛ, механизм правил, и т. д.), есть промежуточные решения такой как jBPM или Фонд рабочих процессов Windows и, вероятно, многие другие.Эти промежуточные решения часто являются хорошим компромиссом.

Answer 2

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

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

Answer 3

Раньше я работал с Biztalk, а в последнее время — с JBPM.Мое мнение предвзято против BPM по следующим причинам:

1. Крутая кривая обучения:Чтобы процесс работал, я должен понимать, как работает система и редактор.Разработчику достаточно сложно понять систему, не говоря уже о бизнес-пользователе.Перетаскивание и визуальное представление — отличный демонстрационный инструмент.Это, конечно, впечатляет менеджеров (которые в конечном итоге за это платят), но продуктивность разработчика просто падает.

2. Не разработчики меняют рабочий процесс:Я не видел ни одного решения BPM, которое бы делало это безупречно.Хотя это не похоже на код, щелкните правой кнопкой мыши по полю, и вам придется ввести код, иначе он не будет работать.Так что вам определенно нужен разработчик, чтобы сделать это.Самое приятное то, что он не удобен ни для разработчиков, ни для бизнес-пользователей, а просто удобен для пользователей демо-версий.

3. Тестируемость и рефакторинг:Практически невозможно протестировать BPMS.У вас действительно рекламируются «фреймворки модульного тестирования», но большинство из них являются хаками и сложны в использовании.Недавно я попробовал JBPM;В итоге я написал много связующего кода и поддельных обработчиков рабочих процессов, чтобы заставить его работать.Однако для меня решающим фактором является рефакторинг.Если бизнес радикально изменит свое мнение о том, как должен выглядеть бизнес-процесс, то удачи в перестановке блоков, потому что просто переставить их не получится, все переменные, привязанные к блокам, тоже придется переупорядочить.Я бы предпочел мощь IDE и тестов для рефакторинга моего бизнес-процесса.

Если в вашем приложении есть рабочий процесс, вы можете попробовать библиотеку рабочих процессов (с постоянным состоянием или без него).Он по-прежнему будет управлять вашими рабочими процессами без всего того раздувания, которое присуще BPM.Если бизнес-пользователю необходимо понять код, пусть компания подготовит хорошие блок-схемы процессов и переведет их в хороший код, ориентированный на предметную область.Используйте приемочные тесты в стиле огурца, чтобы объединить разработчиков и бизнес.BPM — это просто нечто, что пытается сделать слишком много вещей, но в конечном итоге делает все это плохо.

Answer 4

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

Простое программирование — просто используйте IDE, чтобы взломать код.Положительная сторона:больше контроля.Негатив?Много времени тратится на переписывание шаблонного кода.И вам придется их поддерживать.

Короче говоря, я бы предпочел систему управления бизнес-процессами.Я бы порекомендовал Процессмейкер.Он оснащен интуитивно понятным дизайнером процессов, который позволяет проектировать рабочий процесс с помощью перетаскивания.И вы всегда можете написать курок расширить функциональные возможности процесса.Это также открытый исходный код.