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

Question

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

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

Что, на ваш взгляд, является наибольшим преимуществом BPMS по сравнению с IDE с вашими личными инструментами и средами?

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

Существуют правила, в которых я могу использовать Java, но даже тогда я должен придерживаться системного редактора без осмысления и т. Д.

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

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

Answer 1

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

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

Answer 2

Я работал с Biztalk в прошлом и совсем недавно с JBPM. Мое мнение смещено против BPM по следующим причинам:

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

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

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

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

Answer 3

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

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

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

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

Между простым программированием и полнофункциональным BPM-решением (например, Oracle BPM suite , которое содержит BPEL , правило двигатель и т. д.), есть промежуточные решения , такие как jBPM или Windows Workflow Foundation и, возможно, множество других. Эти промежуточные решения часто являются хорошим компромиссом.

Answer 4

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

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

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