Давно прочитал в журнале Компьютерра статью "Автоматизация хаоса". 1999 год!!! В google полно документов на эту тему. Пару слов хочется черкнуть от себя. В большинстве проектов, на которых приходилось работать, так или иначе возникает эта тема.
Хотя и не очень явно.

В тех проектах, где я работал, задача разрабатываемой системы сводится как к какой-то числодробилке. Да - в kubernetes, да - большие объемы данных, да - разбиение сложной обработки по микросервисам, но в этих системах нет человека. Но без человека, все-таки, не обходится. И когда доходит до принятия решения человеком, автоматизация заканчивается. Сам бизнес-процесс распадается на череду каких-то лишних телодвижений. Возникают какие-то стикеры, записочки для памяти, документы других систем. Эти артефакты просматриваются вручную, согласовываются с коллегами через различные каналы связи и т.п. приколы. А почему бы в этот момент, когда действительно нужно решение человека, не предоставить необходимую информацию в удобном, отфильтрованном виде?

После различных опытов со всякими Documentum и т.п. подобными системами, пришел к выводу, что все это как-то тяжеловато, требует кучу времени, квалификации и ДЕНЕГ. Что хочется?

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

В общем, как бы вплести компьютер в рабочие отношения. И вот нашлась Camunda (https://camunda.com/, https://camundarus.ru/). В двух словах что такое Camunda - есть схема бизнес-процесса (БП) состоящего из этапов и конечных точек процесса. Конечных точек может быть несколько. Сам БП в качестве этапа может включать запуск другого БП.
Среда легковесная, доступная для настройки, полностью подвластная разработчику JAVA (и не только), без тяжелых настроек среды.

На одном из проектов мне удалось применить Camunda и увидеть всю мощь. Изначально, как архитектурное решение задачи, в проекте был использован karaf (Karaf в микросервисе Kubernetes). И подразумевалось, что плагины karaf как-то помогут решить задачу изменчивости проекта, процессов. Стояла задача обеспечить автоматизацию бизнес-процессов (до которых еще нужно было дойти) и документооборот между головной организацией и ее дилерами/партнерами. Партнеры могут иметь какую-то свою собственную инфраструктуру или не иметь. Некоторые партнеры имели свой собственный весьма мощный, развитый ИТ ландшафт (решения MS, Kubernetes, VPN и т.п.), со своими ограничениями и возможностями, у некоторых только пара компьютеров. У некоторых на сервис завязаны отделы сотрудников, у некоторых только один человек.

Сама разработка этапов разделена по разработчикам. Этапы и разработчики слабо завязаны на результаты разработки друг-друга. И решить все эти загадки помогла camunda. Ниже пример ОДНОГО ИЗ бизнес-процессов:

Нужна поддержка специалиста/менеджера, находящегося внутри предприятия. И совсем необязательно наличие ИТ образования у этого человека. Разработчик должен договориться с этим специалистом, объяснив суть работы Camunda на уровне "кубиков", ее базовых составных частей:

• тип процесса
• кратко про экземпляр процесса
• начало процесса
• один или несколько исходов
• этапы процесса(task). Типы этапов: автоматический или требующий принятия решения человеком
• ветвления
• что-то сказать о контексте всего бизнес-процесса и контексте конкретного этапа. Очень возможно, что для получения контекста, нужен будет доступ к каким-то внешним системам (другие системы, базы данных и т.п.).

Текущее состояние бизнес-процессов Camunda.

https://camunda.com/platform/tasklist/

Тестирование бизнес-процессов.

• через behave-test
• еще пример

Конспект по внедрению Camunda.

• Зная возможности Camunda, транслировать вопросы заказчику через аналитиков. При этом придется подготовить аналитиков и КРАТКО рассказать про основные возможности, чтобы разработчик и аналитик говорили на одном языке. И с другой стороны, аналитик при общении с заказчиком держал картинку Camunda в голове.
• Разъяснить разработчикам ключевые термины Camunda: id ТИПА бизнес процесса, id ЗАПУЩЕННОГО процесса, состояние (id этапа) процесса. В этом поможет Camunda Task List.
• Как выполнить переход на следующий этап БП
• Рассказать об этапах, где БП ждет ответа от пользователя и автоматических этапах
• Разработчикам показать связь Tomcat и Camunda
• Разработчикам рассказать о размещении Camunda в СУБД
• Тестирование БП
• С devops инженерами обсудить размещение в Kubernetes. В конкретном проекте, Camunda с бизнес-процессами были выделены отдельный микросервис. Но может работать как application в Tomcat.
• При накате новых версий схем бизнес-процессов, все предыдущие процессы должны быть завершены. Или новую версию bpmn схемы разместить по новому пути (???).
• Есть такая штука Software development lifecycle (SDLC). Картинка пояснит суть лучше слов:
  
  
  Ничего нового, но удерживая картинку перед глазами (не только своими), есть план разговора при обсуждении задач, оценки на какой стадии задача, прикинуть что нужно для решения задачи, сколько времени займет внедрение той или иной фичи. И, может быть главное, устанавливает "правила игры". Пример для backend разработчика:
  

  Цель	Продолжительность	Участники
  Анализ требований, понятна ли задача (берем в разработку?)	1 час - 1 день	аналитик+разработчик
  Прикинуть дизайн	1 - 2 час, но с ограничением уложиться в спринт	разработчик (возможно с devops инженером)
  Собственно разработка + unit тесты	по результатам п 1,2	разработчик
  Интеграционное тестирование	0,5 дня - 1 день	тестировщик+разработчик+devops инженер
  Деплой в пререлиз (удаление "фиче" ветки и т.п. зачистка)	В конце спринта (в идеале)	devops инженер

Примеры:
Camunda+Kubernetes
Простенький пример реализации
И еще один
https://github.com/camunda/camunda-bpm-examples/tree/master/spring-boot-starter/example-simple
https://www.baeldung.com/spring-boot-embedded-camunda

Пара наблюдений:

• Camunda можно использовать как АЛГОРИТМ обработки данных (или как ПАТТЕРН), где обрабатываемые данные привязаны к потоку/задаче/состояние. Сами этапы независимы и есть "мета" средства алгоритмизации: старт/конец процесса, if/else/for, передача переменных, переход в другой алгоритм (call/goto). Т.е. применить Camunda как такое средство программирования/автоматизации, НЕ нацеленное на автоматизацию БИЗНЕС процессов именно с участием ЧЕЛОВЕКА. Что-то типа, алгоритма микросервисов.
• При анализе существующих бизнес-процессов, стало видно где они несовершенны. Определяясь с входными/выходными данными этапов, сами бизнес-процессы изменялись, совершенствовались, уменьшалось количество ручных операций(что нормально), НО это привело к сокращению сотрудников(!). Конечно, это неудивительно, к этому и шли, но с другой стороны, как-то все это глобально и жестковато получилось (высвобождение сотрудников "скрипач не нужен", новые приемы работы и т.п.). Люди годами работали и внезапно стали СОВСЕМ не нужны.
• Среди инструментов автоматизации рабочих процессов, отдельно хочется упомянуть Camel. Это не совсем BPM, даже совсем не BPM, но может быть очень полезен.