Pro-code — наше сердце и душа, но люди и процессы бывают разными. Наши необязательные low-code-функции расширяют спектр применений, не мешая разработчикам.
Разработчики часто спрашивают меня о стратегии развития продуктов Camunda. Особенно во время запуска Camunda 8 они выражали обеспокоенность тем, что мы якобы «забыли свои корни» или «отказались от удобства для разработчиков» — именно те качества, за которые нас любят. Появилось мнение, что мы «прыгнули в поезд low-code», потому что у нас теперь есть финансирование и мы хотим «гнаться за большими деньгами». Как разработчик в душе, я могу вас уверить — это совсем не так. Позвольте объяснить нашу стратегию в этом посте.
TL;DR: Мы остаёмся на 100% дружелюбными к разработчикам, и pro-code — это наше всё (можно сказать, наш хлеб с маслом). Но люди, создающие процессные решения, бывают разными — как и сами процессы, которые нужно автоматизировать. Для некоторых сценариев low-code действительно имеет смысл, и здорово, что мы можем их поддерживать. Но low-code-функции в Camunda являются необязательными и никак не мешают pro-code-разработке.
Например, код вашего worker’а может быть преобразован в переиспользуемый Connector (или заменён готовым), который настраивается прямо в BPMN-модели с помощью шаблонов элементов. Но вы можете этого не делать и продолжать работать исключительно в привычной среде разработки. Эта гибкость позволяет использовать Camunda в самых разных сценариях и не загоняет бизнес-подразделения в сомнительные low-code-решения только потому, что в ИТ не хватает ресурсов.
Но давайте по порядку…
Camunda 8 любит разработчиков
Прежде всего, Camunda 8 фокусируется на разработчиках не меньше, а возможно, даже больше, чем предыдущие версии. Главная идея создания Camunda как продукта — уйти от громоздких BPM или low-code-платформ, непригодных для серьёзных инженерных проектов (см. историю Camunda). Это по-прежнему актуально. Camunda создавалась, чтобы сделать оркестрацию процессов частью инструментария профессиональных разработчиков. Особенно в Camunda 8 мы уделили много внимания качественному опыту для разработчиков и удобной модели программирования. Более того, теперь мы выходим за пределы Java-экосистемы. Да, есть ещё над чем поработать (например, интеграция со Spring пока не входит в состав поддерживаемых компонентов, но это в планах на 2024 год), но в целом это тот же опыт, что был всегда. Примеры кода — ниже (их можно найти на GitHub).
Пример worker-кода (Java Delegate):
@JobWorker(type = "payment")
public void retrievePayment(ActivatedJob job) {
// Вызов удалённого сервиса и т.п.
String orderId = job.getVariablesMap().get("orderId");
paymentRestClient.invoke(...);
}Spring Boot Starter в качестве зависимости:
<dependency>
<groupId>io.camunda</groupId>
<artifactId>spring-zeebe-starter</artifactId>
<version>${camunda.version}</version>
</dependency>Единственное реальное отличие между Camunda 7 и 8 — это то, что движок оркестрации теперь запускается как отдельный Java-процесс. То есть Spring Boot Starter запускает не сам движок, а клиент, подключающийся к нему. Почему это хорошо — я уже писал отдельно, но вкратце: это позволяет изолировать ваш код от движка, упростить архитектуру проекта (например, при настройке движка или разрешении конфликтов между версиями сторонних зависимостей).
Кроме того, отказ от реляционной базы данных в архитектуре дал нам возможность серьёзно улучшить масштабируемость и производительность — с Camunda 8 мы поддерживаем сценарии, недоступные в Camunda 7 (например, тысячи экземпляров процессов в секунду, geo-redundant active/active дата-центры и пр.).
Общее заблуждение: Camunda 8 обязательно работает только в облаке. Это не так. Вы можете запустить движок у себя и выбрать удобный способ управления. Облачный (SaaS) вариант — это лишь дополнительная возможность, которая избавляет от забот по администрированию и эксплуатации. Но использовать её или нет — решать вам. Это общая философия Camunda 8: мы даём больше возможностей, которые вы можете использовать, если захотите. Но никого не заставляем ими пользоваться.
Лучший пример новых возможностей — это наши low-code-ускорители (например, коннекторы). Давайте коротко разберёмся, почему мы вообще добавили low-code, а затем — как коннекторы действительно могут помочь.
Клиенты используют Camunda для множества сценариев
Из общения с клиентами мы узнали, что они хотят использовать Camunda для широкого спектра сценариев. Многие из них — это ключевые бизнес-процессы: онбординг клиентов, выполнение заказов, урегулирование претензий, обработка платежей, трейдинг и т.д. Но есть и более простые процессы — менее сложные, не критичные, не слишком ценные, но их всё равно нужно автоматизировать. Это имеет экономический смысл или нужно для удовлетворения ожиданий клиентов. Примеры: изменение мастер-данных (адреса, реквизитов), установка лимитов на переводы, ежегодные отчёты о пробеге для страховок, компенсации за задержки и прочее.
Раньше организации часто даже не рассматривали возможность использовать Camunda для таких процессов, поскольку не могли позволить себе запускать и укомплектовывать полноценные проекты по разработке ПО ради простых и не слишком критичных задач.
Кроме того, для подобных решений по автоматизации простых процессов предъявляются иные нефункциональные требования. Если суперважные и сложные процессы всегда реализуются при участии ИТ-команды — чтобы обеспечить соответствие качества ожиданиям и стабильную работу системы, — то в случае с менее критичными задачами требования мягче. Если такой процесс «упадёт», это не станет катастрофой. Если его взломают, об этом вряд ли напишут в заголовках новостей. Если в нём обнаружатся странные баги, это будет просто досадно. Поэтому вполне допустимо применять другой подход к созданию решений для таких менее критичных процессов.
Категоризация сценариев использования
Главное — осознанно подходить к выбору подхода и не применять неподходящие методы к конкретному процессу. Мы видим, что хорошо работает следующий способ — разделить процессы на три категории:
Красная зона (Red):
Процессы, критически важные для организации. Они обычно сложны в автоматизации и должны работать в масштабируемой среде. Показатели производительности и информационная безопасность имеют большое значение, могут применяться требования регуляторов. Речь часто идёт об основных сквозных бизнес-процессах, но и другие процессы тоже могут попасть в эту категорию.
Для таких сценариев требуется профессиональная разработка с применением лучших индустриальных практик: контроль версий, автоматическое тестирование, CI/CD. Организация также стремится внедрить управление: определить допустимые инструменты, стандарты качества и т.д.Жёлтая зона (Yellow):
Процессы менее критичны, но сбои в них всё же серьёзно влияют на деятельность организации. Здесь необходим умеренный уровень управления, но нужно признать, что решения не будут такими же качественными, как в красной зоне, в основном из-за нехватки разработчиков.Зелёная зона (Green):
Простые автоматизации, часто ограниченные рамками одного подразделения или даже одного человека. Это, как правило, быстрые «заплатки», облегчающие повседневную работу. Если такие решения перестанут работать, вся организация, скорее всего, даже не заметит этого. Для таких некритичных сценариев организация может позволить себе полную свободу действий: как правило, здесь нет ни управления, ни контроля качества.
Хотя процессы из красной зоны традиционно реализуются с помощью Camunda, а зелёные — с помощью офисных инструментов или low-code-решений (например, Airtable или Zapier), именно жёлтая зона представляет особый интерес. Это длинный «хвост» процессов, которые тоже нужно автоматизировать — с определённым уровнем управления, обеспечением качества и безопасностью.
Мы уже знаем организации, которые используют Camunda для таких жёлтых сценариев. Чтобы это стало возможным и чтобы упростить создание решений, они разработали low-code-инструменты поверх Camunda. Яркий пример — Goldman Sachs, которые построили довольно обширную платформу на базе Camunda 7 (примечание: в более поздних презентациях они также упоминают различие между кейсами из core banking и длинным «хвостом» более простых процессов по всей компании). В общении с этими клиентами мы заметили повторяющийся паттерн и использовали этот фидбек для проектирования расширений продукта, которые эти организации могли бы использовать «из коробки» (если бы они существовали на момент начала работы). И мы спроектировали это решение так, чтобы оно не мешало профессиональным разработчикам ПО при реализации сценариев из красной зоны, связанных с критичными core-процессами.
Я не буду вдаваться в подробности по всем этим low-code-ускорителям в этом посте, но речь в основном идёт о Connectors, расширенных формах, работе с данными, out-of-the-box опыте использования таких инструментов, как Tasklist, и браузерных интерфейсах.
Для меня важно ещё раз подчеркнуть ранее упомянутый паттерн: эти ускорители — это предложение, вы не обязаны их использовать. И если посмотреть глубже, то они вовсе не являются мистическими чёрными ящиками. Connector, например, — это «всего лишь» переиспользуемый job worker с целенаправленной панелью свойств (если вас интересует код — посмотрите любой из наших готовых коннекторов), причём панель свойств может даже быть сгенерирована из Java-кода. Camunda Marketplace помогает сделать этот переиспользуемый функционал доступным и легко находимым. Существующие Connectors доступны с исходным кодом и могут быть расширены при необходимости.
Демократизация и ускорение с помощью коннекторов
Существует две основные причины использовать коннекторы.
Разработчики программного обеспечения могут просто стать более продуктивными, используя их, и это то, что мы называем ускорением. Например, может быть просто быстрее использовать Twilio Connector вместо того, чтобы разбираться с REST API для отправки SMS и как лучше вызывать его из Java. Как уже упоминалось, если это не так для вас, например, потому что у вас есть внутренняя библиотека, которую вы просто используете, чтобы скрыть сложность работы с Twilio — отлично, тогда просто продолжайте использовать её. Также, если вы хотите написать больше JUnit-тестов, может быть проще написать интеграционный код на Java самостоятельно. Это нормально! Вас не заставляют использовать Connectors, это лишь предложение, и если это упрощает вам жизнь — используйте их.
Другое, более важное преимущество заключается в том, что это позволяет более разнообразному кругу людей участвовать в создании решений, что называется демократизацией. Например, технически подкованный сотрудник из бизнеса, вероятно, сможет собрать простой процесс с помощью Connectors, даже если он не умеет программировать. Напомню, здесь речь идёт о длинном хвосте простых процессов (жёлтых).
Мощный паттерн заключается в том, что разработчики ПО наделяют другие роли в организации возможностью создавать решения. Один из способов это сделать — создать Центр компетенций, где создаются кастомные коннекторы, специально адаптированные под нужды организации. И затем эти коннекторы используются другими ролями для сборки процессов. Одним из больших преимуществ является то, что ваша IT-команда контролирует, как создаются и используются коннекторы, что позволяет им внедрять важные правила управления, например, в области информационной безопасности или работы с конфиденциальной информацией (что является серьёзной проблемой в типичных low-code-решениях).
Также можно собрать команду из разных ролей для создания решения: разработчик сосредоточится на технических задачах настройки Connectors, а сотрудники с бизнес-фокусом — на модели процесса. И, конечно, между этими крайностями существует множество промежуточных вариантов.
Это сопоставимо с ситуацией, которую мы знаем по поставщикам программного обеспечения, внедряющим Camunda в свой продукт для возможности кастомизации. Их программное решение обычно поставляется с моделью процесса по умолчанию, а консультанты могут настраивать процессы под нужды конечного клиента в рамках определённых ограничений, заложенных командой разработчиков.
Избегаем опасной зоны при оптимизации поставщиков и унификации инструментов
Многие организации сейчас пытаются сократить количество поставщиков и используемых инструментов. Это понятно по многим причинам, но становится рискованным, если игнорируются различные нефункциональные требования зелёных, жёлтых и красных процессов.
Например, отделы закупок могут не захотеть использовать несколько инструментов для автоматизации процессов. Но для них разница между Camunda и low-code-платформой неочевидна, поскольку обе решают задачу автоматизации процессов.
Для красных сценариев использования клиенты всё ещё могут легко обосновать, почему они не могут использовать low-code-инструменты — потому что такие инструменты просто не подходят для профессиональной разработки программного обеспечения. Но для жёлтых случаев это становится намного сложнее объяснить. Это может привести к ситуации, когда low-code-инструменты, предназначенные для зелёных процессов, начинают использоваться для жёлтых. Это может сработать для очень простых жёлтых процессов, но легко становится рискованным, если процессы становятся более сложными или если требования к стабильности, отказоустойчивости, удобству сопровождения, масштабируемости или информационной безопасности со временем возрастают. Вот почему я считаю это серьёзной опасной зоной для компаний.
Функции ускорения low-code в Camunda позволяют использовать Camunda в большем числе жёлтых сценариев, поскольку вам не нужно привлекать разработчиков для всего. Но если нефункциональные требования возрастают, вы всегда можете их покрыть с помощью Camunda, так как она изначально создавалась и для красных сценариев. Например, вы можете начать добавлять автоматизированные тесты, когда решение начинает становиться слишком нестабильным. Или вы можете масштабировать операционную нагрузку, если сталкиваетесь с неожиданно высоким спросом (вспомните отмены рейсов во время пандемии Covid — это был жёлтый сценарий для авиакомпаний, но он стал крайне важным и потребовал эффективной обработки буквально в течение ночи).
Подводя итог: Лучше нацеливаться на жёлтые сценарии с использованием профессионального (pro-code) решения, такого как Camunda, дополненного low-code-инструментами ускорения, которые вы можете использовать, но не обязаны. Это позволяет избежать рисков, связанных с использованием low-code-решений, которые не справляются с растущими нефункциональными требованиями.
И, возвращаясь к нашей продуктовой стратегии: с Camunda 8 мы много работали над тем, чтобы поддерживать ещё более «красные» сценарии (благодаря улучшенной производительности, масштабируемости и отказоустойчивости), а также больше жёлтых сценариев одновременно. Таким образом, вы можете двигаться как влево (красные), так и вправо (жёлтые) одновременно.
Резюме
В сегодняшнем посте я ещё раз подчеркнул, что Camunda была и остаётся дружественной к разработчикам. Pro-code (красные) сценарии — это основа нашего бизнеса, и, честно говоря, это очень интересные задачи, в которых мы можем показать все свои сильные стороны. Это стратегически важно, даже если сейчас вы видите много маркетинговых сообщений о low-code-ускорителях.
Эти low-code-ускорители также позволяют создавать менее сложные решения (жёлтые), где обычно в разработке участвуют представители других ролей (демократизация, ускорение и расширение возможностей). Это помогает снизить риск использования неподходящего инструмента для жёлтых сценариев, что может привести к серьёзным последствиям.
Подписывайтесь на наши телеграм каналы:
Jmix.ru — платформа быстрой разработки B2B и B2G веб-приложений на Java.
BPM Developers — про бизнес-процессы: новости, гайды, полезная информация и юмор.
