1. Если вы разрабатываете в low code парадигме, то это неважно.
2. Если вы используете уже существующие low code, то важно не обобщать, а смотреть конкретно. Я приводил скрины Talend — в нем есть version control. И всё что делается визуально, конвертится в код, который может далее использоваться как угодно в контроле. Другое дело, что сами компоненты генерят кучу кода, который сложно валидировать. Для этого есть инструменты визуального контроля. Тут безусловно другие принципы, и применять codefirst подход к более высокому уровню абстракции это как жаловаться сегодня из «уровня абстракции ассемблера», что в современных высокоуровневых языках не видна работа с памятью и машинными командами.
2.1. И ещё одно соображение, что изменения внутри конструктора вовсе не всегда должны проходить версионный контроль, потому что есть понятие «последняя миля автоматизации». Это как git к редактору уровня в игре прикручивать — ну в теории можно, но рельно ли нужно? git нужен к движку.
во-первых, я говорил про парадигму, а не про конкретные решения. Никто не мешает вам писать ваше решение с нуля в парадигме «я делаю конструктор, в котором я сделаю какую-то ценность».
Во-вторых, low code он потому и low code — там есть код, но его мало. И системы предназначены для вставок low code
Показательно, что в английском coder и software engineer это разные, а в переводе у нас это и то и то «программист».
Бизнес давно ищет ответ.
Производительность труда в IT падает, и это меня тоже беспокоит. С другой стороны, законы Адама Смита никогда в истории человечества не нарушались, не нарушатся и сейчас. Аналитика IDC — до 2024 нужно 0,5 млрд приложений. Де-факто к бизнесу нужно по разработчику. Это невозможно! Значит, бизнес и будет разработчиком. Но не в том смысле, в котором хотят сегодня кодеры.
Есть еще проблема, которую разработчики забывают — поддержка текущего софта. Написать что-то новенькое это прям приятно, а как его поддерживать — ой, ну это пусть кто-то другой. Или давайте теперь рефакторить. Или мониторинг давайте сейчас специально накручивать и т.п.
Что это будет? Возможно, это будет low code (к которому сейчас много вопросов, но он улучшается день ото дня). Только в России — Elma, Comindware. В мире и Amazon Honeyode, и Ms Powerapps и т.п. Возможно, это будет в далеком будущем какой-то process mining (app mining) полностью переосмысленный. Но что-то будет, и это будет интересно!
Важно то, что клиент получит на схеме именно тот бизнес-процесс, который работает у него.
Откаты операции — это ещё один блок на действие.
Да, схема будет сложнее (если не обеспечивать согласовательный уровень, что возможно), но мы и не предполагаем что BPMS будет использоваться на схемах из трёх блоков — тут важнее визибилити и принцип гарантированной независимости и унификации общения между микросервисами.
Микросервисный подход хорош для крупных проектов, а его удобно оркестрировать BPMS. Вот основная ценность для бизнеса. Бизнес не питает иллюзий что их процессы из 10 блоков (хотя если реально нужно «в 10 блоков», то это можно сделать, обеспечив схему сначала на согласовательном уровне — на верхнем уровне будет очень просто, но каждый блок будет в свою очередь более сложным и т.п.)
В BPMS проектах не может быть мало разработчиков потому что проекты крупные.
Нам кажется, что jBPM может применяться на меньших по размеру проектах ввиду того что он обеспечит больше скорости изменений процессов внутри.
Кроме того, не забывайте, Camunda бесплатная с очень урезанным функционалом. В jBPM можете начать без лицензий.
ну это относительно. Есть если у вас есть микросервисы и оркестратор, значит это уже само по себе предполагает что у вас большое количество функционала, а организация и компетенция команды такая, что компания и команда понимает процессное управление, что само по себе делает требования к софту более сложным, внимание к it более пристальным и как следствие, больше задач на поддержку.
jBPM дешевле в сопровождении и да, что-то там может поддерживаться не разработчиками. У Camunda более строгое отношение к бизнес-процессам (поощряется все проводить через деплой). Чувствую, нужно написать разбор jBPM vs Camunda, мы это сделаем.
Конечно поддерживает, Camunda — одно из самых совершенных BPMS на сегодняшний момент. У нас не на всех примерах ест события и транзакции просто потому, что хочется показать сам принцип.
По поводу бесплатной версии — да, можно пользоваться бесплатной версией. Много чего не будет, но вот мы знаем что ребята из Тинькофф пишут собственные средства которые дополняют функционал и являются опенсорс (excamad например). Если вы — очень крупное предприятие, вы можете использовать бесплатную версию Camunda и написать что нужно самостоятельно.
Если вам нужны все функции Camunda Enterprise но вы не очень крупная организация (как правило вопрос не денег а внутренних политик по лицензиям), попробуйте jBPM — он «всего» раз в 5 медленнее, что для многих случаев не столь критично (т.к. сама скорость бизнес-процесса может сильнее зависить от скорости микросервисов и потери BPMS на этом фоне не очень существенны).
Обычно бизнес это и не рисует, а это разрабатывается кодом и деплоится так же как и всё остальное, но визуально, наглядно. Действительно, бизнес может что-то поменять, но на крупных проектах все их модификации пройдут «код-ревью» и весь деплой как обычно.
За контракты и общий контекст ответственна BPMS. Откаты там где необходимо конечно нужно рисовать, мы накидали тестовый бизнес-процесс для рассказа возможностей и общего понимания того, как можно оркестрировать микросервисы — это была цель статьи.
Пока монолит небольшой, это не проблема. Со временем, монолит раздувается. Встаёт вопрос рефакторинга. В крупных системах с кучей кастомной логики (ещё на базе какой-нибудь коробки — например Magento) обновления ядра — проблема (ведь нужно отрефакторить все модули с учетом того что добавлено в ядро вендором).
Еще одна проблема монолита — TDD, который значительно более трудоёмкий (а иногда даже настолько трудоёмкий что бессмысленный). А чем больше функционала, тем больше вероятность регрессии.
Речь же не идёт о маленьких проектах — у нашей компании в портфеле таких почти нет.
BPMN позволяет видеть бизнесу то, как проходит бизнес-процесс. Многие сложные операции (вроде таймеров, транзакций) в коде вообще сложно реализуемыми. В BPMN читаемость и легкость добавления транзакций, таймеров, прерываний такова, что на крупных проектах это сильно выручает.
Еще одна проблема без BPMN — бизнес хочет увидеть документацию по бизнес-процессу. Допустим даже она есть, но может быть что-то пропущено, а что-то забыто, а что-то неясно. В BPMN2.0 это менее вероятно, и когда меняются люди (что в крупных компаниях тоже случается), у бизнеса сохраняется уверенность в том, что понимание бизнес-процессов не ушло вместе с конкретным человеком.
2. Если вы используете уже существующие low code, то важно не обобщать, а смотреть конкретно. Я приводил скрины Talend — в нем есть version control. И всё что делается визуально, конвертится в код, который может далее использоваться как угодно в контроле. Другое дело, что сами компоненты генерят кучу кода, который сложно валидировать. Для этого есть инструменты визуального контроля. Тут безусловно другие принципы, и применять codefirst подход к более высокому уровню абстракции это как жаловаться сегодня из «уровня абстракции ассемблера», что в современных высокоуровневых языках не видна работа с памятью и машинными командами.
2.1. И ещё одно соображение, что изменения внутри конструктора вовсе не всегда должны проходить версионный контроль, потому что есть понятие «последняя миля автоматизации». Это как git к редактору уровня в игре прикручивать — ну в теории можно, но рельно ли нужно? git нужен к движку.
Camunda не является low code bpms.
Во-вторых, low code он потому и low code — там есть код, но его мало. И системы предназначены для вставок low code
Бизнес давно ищет ответ.
Производительность труда в IT падает, и это меня тоже беспокоит. С другой стороны, законы Адама Смита никогда в истории человечества не нарушались, не нарушатся и сейчас. Аналитика IDC — до 2024 нужно 0,5 млрд приложений. Де-факто к бизнесу нужно по разработчику. Это невозможно! Значит, бизнес и будет разработчиком. Но не в том смысле, в котором хотят сегодня кодеры.
Есть еще проблема, которую разработчики забывают — поддержка текущего софта. Написать что-то новенькое это прям приятно, а как его поддерживать — ой, ну это пусть кто-то другой. Или давайте теперь рефакторить. Или мониторинг давайте сейчас специально накручивать и т.п.
Что это будет? Возможно, это будет low code (к которому сейчас много вопросов, но он улучшается день ото дня). Только в России — Elma, Comindware. В мире и Amazon Honeyode, и Ms Powerapps и т.п. Возможно, это будет в далеком будущем какой-то process mining (app mining) полностью переосмысленный. Но что-то будет, и это будет интересно!
Откаты операции — это ещё один блок на действие.
Да, схема будет сложнее (если не обеспечивать согласовательный уровень, что возможно), но мы и не предполагаем что BPMS будет использоваться на схемах из трёх блоков — тут важнее визибилити и принцип гарантированной независимости и унификации общения между микросервисами.
Микросервисный подход хорош для крупных проектов, а его удобно оркестрировать BPMS. Вот основная ценность для бизнеса. Бизнес не питает иллюзий что их процессы из 10 блоков (хотя если реально нужно «в 10 блоков», то это можно сделать, обеспечив схему сначала на согласовательном уровне — на верхнем уровне будет очень просто, но каждый блок будет в свою очередь более сложным и т.п.)
И релизные циклы разные.
Словом, крупному проекту проще быть микросервисным.
Нам кажется, что jBPM может применяться на меньших по размеру проектах ввиду того что он обеспечит больше скорости изменений процессов внутри.
Кроме того, не забывайте, Camunda бесплатная с очень урезанным функционалом. В jBPM можете начать без лицензий.
jBPM дешевле в сопровождении и да, что-то там может поддерживаться не разработчиками. У Camunda более строгое отношение к бизнес-процессам (поощряется все проводить через деплой). Чувствую, нужно написать разбор jBPM vs Camunda, мы это сделаем.
По поводу бесплатной версии — да, можно пользоваться бесплатной версией. Много чего не будет, но вот мы знаем что ребята из Тинькофф пишут собственные средства которые дополняют функционал и являются опенсорс (excamad например). Если вы — очень крупное предприятие, вы можете использовать бесплатную версию Camunda и написать что нужно самостоятельно.
Если вам нужны все функции Camunda Enterprise но вы не очень крупная организация (как правило вопрос не денег а внутренних политик по лицензиям), попробуйте jBPM — он «всего» раз в 5 медленнее, что для многих случаев не столь критично (т.к. сама скорость бизнес-процесса может сильнее зависить от скорости микросервисов и потери BPMS на этом фоне не очень существенны).
За контракты и общий контекст ответственна BPMS. Откаты там где необходимо конечно нужно рисовать, мы накидали тестовый бизнес-процесс для рассказа возможностей и общего понимания того, как можно оркестрировать микросервисы — это была цель статьи.
Еще одна проблема монолита — TDD, который значительно более трудоёмкий (а иногда даже настолько трудоёмкий что бессмысленный). А чем больше функционала, тем больше вероятность регрессии.
Речь же не идёт о маленьких проектах — у нашей компании в портфеле таких почти нет.
BPMN позволяет видеть бизнесу то, как проходит бизнес-процесс. Многие сложные операции (вроде таймеров, транзакций) в коде вообще сложно реализуемыми. В BPMN читаемость и легкость добавления транзакций, таймеров, прерываний такова, что на крупных проектах это сильно выручает.
Еще одна проблема без BPMN — бизнес хочет увидеть документацию по бизнес-процессу. Допустим даже она есть, но может быть что-то пропущено, а что-то забыто, а что-то неясно. В BPMN2.0 это менее вероятно, и когда меняются люди (что в крупных компаниях тоже случается), у бизнеса сохраняется уверенность в том, что понимание бизнес-процессов не ушло вместе с конкретным человеком.