Хорошая статья. Только с low code, некоторые BPM начали заигрывать намного раньше, чем в 2019. Если кто ещё помнит Intalio BPMS, то они позиционировались как "zero code" платформа, для которой разработчики были не нужны. Так что для чего это было сделано было понятно как минимум лет за 10 до LCAP. А вот термина "citizen developer" тогда ещё действительнр не было, но такие "разработчики" реально уже были.
Если постить в 2025 статьи из 2023 без перепроверки, можно ввести читателей в заблуждение. С релизом Camunda 8 они официально объявили, что отходят от OpenSource парадигмы, и переключаются на cloud. Так что утверждение, что Camunda это OpenSource не соответствует действительности. Да, Camunda 7 всё ещё поддерживается, но уже объявлен её End Of Life. Недавно они перенесли его с 2027 на 2030, но всё же, новых фитч уже не будет. Вообще довольно странно, почему при том, что и Camunda и Flowable это по сути близнецы, в РФ про Flowable мало кто слышал, а вот Camunda по прежнему продолжает активно использоваться.
Самым большим минусом FreeCAD, который не позволял ему полноценно конкурировать с коммерческими продуктами была нерешённая проблема топологический наименований (Topological Naming Problem). В FreeCAD 1.0 её вроде как решили. Провёл несколько экспериментов, и действительно, там где модели обычно ломались, больше ошибок не выкидывается. Но FreeCAD стал работать заметно медленнее своей предыдущей версии. Надеюсь это исправят. Но даже сейчас с ним работать уже можно. Так что даёшь FreeCAD в массы!
Кубики можно и в паинте рисовать :) Но в том то и дело, что BPMN это не только про кубики. По нему есть официальный экзамен, в котором есть вопросы связанные с ИТ и бизнес сферой. По самой нотации там вопросов может 30% только. Вы верно заметили, что в BPM проекте редко нужны разработчики выше мидла, и когда появляется не тривиальная задача срабатывает правило Паретто. Вот только тут появляется вопрос специализации. Разработчики в BPM проектах должны ориентироваться на системную итнеграцию, а когда появляется что-то не тривиальное- нужно привлекать специалистов соответствующего профиля. Те, кто продвигают low code инструменты заведомо лгут, что можно обойтись без дорогостоющих разработчиков. Для какой-нибудь демки и презентации может сгодиться, а потом наступает момент жёсткой истины, и заказчик сталкивается с необходимостью подлючать людей, на которых он не рассчитывал. Подстройка под архитектуру BPMS или внесение изменений в неё может быть намного сложнее, чем написание нового функционала. Наступает разочарование. Как пример- почти в каждой BPMS есть встроенный дизайнер пользовательских форм. Раньше в Камунде его не было, но недавно добавили. На презентациях продавцы шустро создают на них работающие примеры, а когда начинается реальная работа, всплывает, что в дизайнере нет выподающего списка, или форму нельзя динамически менять. И тут в проекте появляется веб разработчик, на которого никто не рассчитывал, или (что чаще бывает) системных интеграторов пытаются перевести на веб разработку, что ни к чему хорошему не приводит.
Camunda никогда не позиционировалась как low/no code платформа, даже наоборот, у них есть статья, где они принципиально дистанцируются от этого термина. Так что без навыков в ИТ в Camunda проекте делать нечего. Другое дело то, что для реализации бизнес-логики на java требуются разработчики уровня архитектора, а они обычно не понимают, зачем нужен BPMN, разбираться в нём не хотят, и пытаются избавиться от как им кажется лишнего движка. С другой стороны, аналитики, владеющие BPMN не могут понять, нафига им джависты в звании архитектора, когда бизнес-логику, в 80% случаев состоящую из трансформации одного формата данных в другой можно реализовать на питоне.
8я версия это плод жадности владельцев проекта. Способ уйти от OpenSource и перевода в клауд. Camunda, как форк от jBPM унаследовала его способ описания бизнес-логики через Java, однако в Камунде появился функциоал воркеров, который позволяет автоматизировать задачи хоть на питоне. Но в проектах с какой-то маниакальной упроностью продолжают использовать джаву. Опытные джависты реально не понимают, зачем нужен ещё один слой, не хотят в этом разбираться, или попросту саботируют работу. А новичкам в этом разобраться сложно. Это погубило уже ни один проект. А потом мы видим комментарии из серии "камунда маст дай". Прекратите использовать джаву в BPM проектах, и увидите как мир станет светлее.
Хорошая статья. Только с low code, некоторые BPM начали заигрывать намного раньше, чем в 2019. Если кто ещё помнит Intalio BPMS, то они позиционировались как "zero code" платформа, для которой разработчики были не нужны. Так что для чего это было сделано было понятно как минимум лет за 10 до LCAP. А вот термина "citizen developer" тогда ещё действительнр не было, но такие "разработчики" реально уже были.
Если постить в 2025 статьи из 2023 без перепроверки, можно ввести читателей в заблуждение. С релизом Camunda 8 они официально объявили, что отходят от OpenSource парадигмы, и переключаются на cloud. Так что утверждение, что Camunda это OpenSource не соответствует действительности. Да, Camunda 7 всё ещё поддерживается, но уже объявлен её End Of Life. Недавно они перенесли его с 2027 на 2030, но всё же, новых фитч уже не будет. Вообще довольно странно, почему при том, что и Camunda и Flowable это по сути близнецы, в РФ про Flowable мало кто слышал, а вот Camunda по прежнему продолжает активно использоваться.
Самым большим минусом FreeCAD, который не позволял ему полноценно конкурировать с коммерческими продуктами была нерешённая проблема топологический наименований (Topological Naming Problem). В FreeCAD 1.0 её вроде как решили. Провёл несколько экспериментов, и действительно, там где модели обычно ломались, больше ошибок не выкидывается. Но FreeCAD стал работать заметно медленнее своей предыдущей версии. Надеюсь это исправят. Но даже сейчас с ним работать уже можно. Так что даёшь FreeCAD в массы!
Кубики можно и в паинте рисовать :) Но в том то и дело, что BPMN это не только про кубики. По нему есть официальный экзамен, в котором есть вопросы связанные с ИТ и бизнес сферой. По самой нотации там вопросов может 30% только. Вы верно заметили, что в BPM проекте редко нужны разработчики выше мидла, и когда появляется не тривиальная задача срабатывает правило Паретто. Вот только тут появляется вопрос специализации. Разработчики в BPM проектах должны ориентироваться на системную итнеграцию, а когда появляется что-то не тривиальное- нужно привлекать специалистов соответствующего профиля. Те, кто продвигают low code инструменты заведомо лгут, что можно обойтись без дорогостоющих разработчиков. Для какой-нибудь демки и презентации может сгодиться, а потом наступает момент жёсткой истины, и заказчик сталкивается с необходимостью подлючать людей, на которых он не рассчитывал. Подстройка под архитектуру BPMS или внесение изменений в неё может быть намного сложнее, чем написание нового функционала. Наступает разочарование. Как пример- почти в каждой BPMS есть встроенный дизайнер пользовательских форм. Раньше в Камунде его не было, но недавно добавили. На презентациях продавцы шустро создают на них работающие примеры, а когда начинается реальная работа, всплывает, что в дизайнере нет выподающего списка, или форму нельзя динамически менять. И тут в проекте появляется веб разработчик, на которого никто не рассчитывал, или (что чаще бывает) системных интеграторов пытаются перевести на веб разработку, что ни к чему хорошему не приводит.
Camunda никогда не позиционировалась как low/no code платформа, даже наоборот, у них есть статья, где они принципиально дистанцируются от этого термина. Так что без навыков в ИТ в Camunda проекте делать нечего. Другое дело то, что для реализации бизнес-логики на java требуются разработчики уровня архитектора, а они обычно не понимают, зачем нужен BPMN, разбираться в нём не хотят, и пытаются избавиться от как им кажется лишнего движка. С другой стороны, аналитики, владеющие BPMN не могут понять, нафига им джависты в звании архитектора, когда бизнес-логику, в 80% случаев состоящую из трансформации одного формата данных в другой можно реализовать на питоне.
8я версия это плод жадности владельцев проекта. Способ уйти от OpenSource и перевода в клауд. Camunda, как форк от jBPM унаследовала его способ описания бизнес-логики через Java, однако в Камунде появился функциоал воркеров, который позволяет автоматизировать задачи хоть на питоне. Но в проектах с какой-то маниакальной упроностью продолжают использовать джаву. Опытные джависты реально не понимают, зачем нужен ещё один слой, не хотят в этом разбираться, или попросту саботируют работу. А новичкам в этом разобраться сложно. Это погубило уже ни один проект. А потом мы видим комментарии из серии "камунда маст дай". Прекратите использовать джаву в BPM проектах, и увидите как мир станет светлее.