Есть небольшая неточность относительно lanes. Это может быть что угодно, например знаки зодиака.
Lanes are used to organize and categorize Activities within a Pool. The meaning of the Lanes is up to the modeler. BPMN does not specify the usage of Lanes. (страница 305 стандарта)
Как посмотреть. Мы используем либу ту же самую, bpmn js.
В отличии от других тулов на этой либе, у нас есть оргструркура и провязка с исполнителями задач, учёт элементов архитектуры (справочники систем/документов/своих), выгрузка регламентов, Business capability map, комментарии, rest API, интеграция с Camunda 7 и ещё куча свистелок, чтобы было удобно пользоваться.
Привет, спасибо за высокую оценку нашего инструмента Stormbpmn. В комментариях спрашивают про стоимость - перечисленный функционал бесплатный, ограничений на количество моделей нет.
Согласен, это и есть та методологическая часть, которая местами сроди магии и в которую очень сложно попасть. Но я в этом не вижу проблемы- ну есть разночтения, ну взял их устранил, уточнив описание или типа такого
Bpmn на имеет никакого отношения к разработке программных комплексов, не удивительно что он плох в этом смысле и что его не хватает, чтобы понять что делать ( не функций, не правил, не классов, не атрибутов там нет).
BPMN применяется для описания бизнес-процессов, что по описанию и является +- набором действий и их последовательностью (но не набором состояний) и определенным методологическим взглядом на то, как этот набор и последовательность сформировать и почему.
В 5% случаев при разработке софта окажется, что мы автоматизируем бизнес-процесс и можно подумать над тем, чтобы взять XML из bpmn и запихнуть в BPM-движок, но в 80% случаев хватит и FSM. Ни в каком из вариантов это не освобождает нас от описания и программирования функций, правил, классов и атрибутов.
Тем не менее BPMN в течение 12 лет разрабатывался и существует при поддержке OMG и организаций уровня HP, IBM, Accenture; они находят в его существовании ценность.
Думается, что последовательность действий и визуальный способ объяснить ее однозначно ценны сами по себе, особенно в тех организациях, которые применяют процессный подход.
В целом смысл существования Bpmn так и определен в самом стандарте:
Thus, BPMN creates a standardized bridge for the gap between the business process design and process implementation.
Ну и там же:
BPMN is constrained to support only the concepts of modeling that are applicable to Business Processes. This means that other types of modeling done by organizations for business purposes is out of scope for BPMN. Therefore, the following are aspects that are out of the scope of this specification:
• Definition of organizational models and resources
• Modeling of functional breakdowns
• Data and information models
• Modeling of strategy
• Business rules models
Так что в целом если кажется что BPMN не уместен в каком-то месте, то не кажется.
Э, так вы написали с 10м инстансами процессов, я подумал что про разные дифинишины. Но тут я уже хз, смотреть надо, я видел что такое нормально работает. Камунда это вообще не про рпс (если не брать с инмемори), а про инстансы в день. Мало организаций, где 10 миллионов заказов в час.
А перепутать легко, если начать логи в двх из кафки лить через камунду, то на второй день станет грустно .
На Jpoint в этом году, рассказывал как раз как не перепутать
У нас в организации такое есть, универсальный совет такой:
Не делать одну здоровенную камунду, а делать н-камунд. То, что хочется переиспользовать - выносить в либы.
Отказаться от визуального программирования, если оно есть. Перейти на моделирование бизнес-процессов, а не флоу.
Не использовать контекст, использовать только бизнес-ки, который является сссылкой на обрабатываемую сущность в соседней системе. В прочем пару айдишников можно добавить, как раз для корреляций.
Не использовать встроенные корреляции по переменным, максимум по бизнес-ки. В иделае написать свою обвязку для корреляций, мы так сделали в итоге.
Затюнить Job Executor
Перейти на External Task в жирных или долгих подключениях.
Миграции в общем виде автоматизировать нельзя, потому что в общем виде невозможно предугадать изменения бизнес-процессов.
Вот то что точно можно сказать, что эти советы очень сложно найти в доке и они контринтуитивны, особенно с контекстом.
Поэтому если у вас всегда FSM и не пахнет сетями Петри, то Camunda не нужна - у нее спект применения сильно уже, чем кажется на первый взгляд
С BPM-движками и с BPMS-системами есть подводные камни, в основном методологические. Использование этих инструментов в качестве штуки для визуального программирования гарантированно приводит к экспоненциальному росту сложности, как раз из за
необходимости банальные a && !b рисовать как шлюзы.
Но если выбрать нормальную методологию, и использовать BPMN не для визуального программирования, а для управления бизнес-процессами, то обычно получается хорошо. Хорошая методология — это такая, в которой на схеме есть значимые для процесса действия (с бизнесовой точки зрения) и скрыта их реализация, а наоборот — на схемах обязательно нет технический действий, которые не имею бизнесового смысла (те самые a&&!b)
Встроенный в камунду иногда используем. Есть неудобства, которые нас не устроили — не весь DMN поддерживается, сложно дебажить и наши правила огромного размера, в них сложно ориентироваться.
Скорее наоборот, это Camunda вызывает код на Java, а не наоборот. За несколько лет только один раз человек отказался работать с Camunda, потому что хотел делать «нормальный код, а не стрелочки двигать». Но за счёт того что это привычный всем спринг и котлин, такого сопротивления, как с IBM, конечно нет.
Есть небольшая неточность относительно lanes. Это может быть что угодно, например знаки зодиака.
Lanes are used to organize and categorize Activities within a Pool. The meaning of the Lanes is up to the modeler. BPMN does not specify the usage of Lanes. (страница 305 стандарта)
Ребята молодцы, рад что консультация была полезна!
По факту реально от камунды в проде нужна только интерпретация BPMN, апихи админские да job executor. Все остальное в помойку.
К сожалению узнать об этом с улицы невозможно, поэтому так много разочарованных в Camunda.
Справедливо
В таблице речь о средствах моделирования. Camunda modeler в k8s не устанавливается.
Как посмотреть. Мы используем либу ту же самую, bpmn js.
В отличии от других тулов на этой либе, у нас есть оргструркура и провязка с исполнителями задач, учёт элементов архитектуры (справочники систем/документов/своих), выгрузка регламентов, Business capability map, комментарии, rest API, интеграция с Camunda 7 и ещё куча свистелок, чтобы было удобно пользоваться.
Привет, спасибо за высокую оценку нашего инструмента Stormbpmn. В комментариях спрашивают про стоимость - перечисленный функционал бесплатный, ограничений на количество моделей нет.
Согласен, это и есть та методологическая часть, которая местами сроди магии и в которую очень сложно попасть. Но я в этом не вижу проблемы- ну есть разночтения, ну взял их устранил, уточнив описание или типа такого
Bpmn на имеет никакого отношения к разработке программных комплексов, не удивительно что он плох в этом смысле и что его не хватает, чтобы понять что делать ( не функций, не правил, не классов, не атрибутов там нет).
BPMN применяется для описания бизнес-процессов, что по описанию и является +- набором действий и их последовательностью (но не набором состояний) и определенным методологическим взглядом на то, как этот набор и последовательность сформировать и почему.
В 5% случаев при разработке софта окажется, что мы автоматизируем бизнес-процесс и можно подумать над тем, чтобы взять XML из bpmn и запихнуть в BPM-движок, но в 80% случаев хватит и FSM. Ни в каком из вариантов это не освобождает нас от описания и программирования функций, правил, классов и атрибутов.
Тем не менее BPMN в течение 12 лет разрабатывался и существует при поддержке OMG и организаций уровня HP, IBM, Accenture; они находят в его существовании ценность.
Думается, что последовательность действий и визуальный способ объяснить ее однозначно ценны сами по себе, особенно в тех организациях, которые применяют процессный подход.
В целом смысл существования Bpmn так и определен в самом стандарте:
Thus, BPMN creates a standardized bridge for the gap between the business process design and process implementation.
Ну и там же:
BPMN is constrained to support only the concepts of modeling that are applicable to Business Processes. This means that other types of modeling done by organizations for business purposes is out of scope for BPMN. Therefore, the following are aspects that are out of the scope of this specification:
• Definition of organizational models and resources
• Modeling of functional breakdowns
• Data and information models
• Modeling of strategy
• Business rules models
Так что в целом если кажется что BPMN не уместен в каком-то месте, то не кажется.
Э, так вы написали с 10м инстансами процессов, я подумал что про разные дифинишины. Но тут я уже хз, смотреть надо, я видел что такое нормально работает. Камунда это вообще не про рпс (если не брать с инмемори), а про инстансы в день. Мало организаций, где 10 миллионов заказов в час.
А перепутать легко, если начать логи в двх из кафки лить через камунду, то на второй день станет грустно .
На Jpoint в этом году, рассказывал как раз как не перепутать
У нас в организации такое есть, универсальный совет такой:
Не делать одну здоровенную камунду, а делать н-камунд. То, что хочется переиспользовать - выносить в либы.
Отказаться от визуального программирования, если оно есть. Перейти на моделирование бизнес-процессов, а не флоу.
Не использовать контекст, использовать только бизнес-ки, который является сссылкой на обрабатываемую сущность в соседней системе. В прочем пару айдишников можно добавить, как раз для корреляций.
Не использовать встроенные корреляции по переменным, максимум по бизнес-ки. В иделае написать свою обвязку для корреляций, мы так сделали в итоге.
Затюнить Job Executor
Перейти на External Task в жирных или долгих подключениях.
Миграции в общем виде автоматизировать нельзя, потому что в общем виде невозможно предугадать изменения бизнес-процессов.
Вот то что точно можно сказать, что эти советы очень сложно найти в доке и они контринтуитивны, особенно с контекстом.
Поэтому если у вас всегда FSM и не пахнет сетями Петри, то Camunda не нужна - у нее спект применения сильно уже, чем кажется на первый взгляд
А где прочитать предметную критику? Я ж ее и пытась из вас вытащить. Голдманс сакс гоняет 10 миллирадов инстансов в день, и у них все хорошо.
Пробовал, ада не встречал.
А что за ад в кишках у camunda?
Камунда это не bpms система, это bpm движок. Ее нельзя с другими продуктами сравнивать.
необходимости банальные a && !b рисовать как шлюзы.
Но если выбрать нормальную методологию, и использовать BPMN не для визуального программирования, а для управления бизнес-процессами, то обычно получается хорошо. Хорошая методология — это такая, в которой на схеме есть значимые для процесса действия (с бизнесовой точки зрения) и скрыта их реализация, а наоборот — на схемах обязательно нет технический действий, которые не имею бизнесового смысла (те самые a&&!b)
С друлс тоже самое.
А как бы замена архитектора принесла столько же профита, сколько и замена движка?
Здесь заслуга не только от Camunda, скорее она просто хорошо подошла под наш замысел проектирования, тут я с вами согласен.