Самым большим минусом 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 проектах, и увидите как мир станет светлее.
Самым большим минусом 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 проектах, и увидите как мир станет светлее.