No-Code и Low-Code. Взгляд инженера и бизнесмена
По слухам, в мире набирает обороты движение No-Code и Low-Code, активно обсуждаются плюсы и минусы этих подходов. Иногда некоторые заявляют: «Будущее программирования — вовсе не кодинг». Давайте попробуем разобрать вопрос по-взрослому, как инженер и как бизнесмен.
Константин, как тогда на ваш взгляд объяснить ситуацию, что low-code платформы прочно поселились, например, в таких решениях как кредитные конвейеры, комплаенс-процессы и многих другие банковских системах, которые в общем и целом являются наверное одними из самых сложных классов информационных-систем, требующих максимально квалифицированных инженеров и архитекторов?
Это вопрос без подвоха, интересно ваше мнение. Я сам много лет посвятил BPMS и как инженер и как предприниматель.
Что такое No-Code и Low-Code? Это какие-то готовые блоки, которые нужно правильно расположить и связать между собой. Если вы работаете в зарегулированной области, где функционал в целом стандартный, нужно просто верно описать правила движения чего-либо по процессу, то вполне логично применение No-Code и Low-Code. Тогда, систему разворачивать будет не разработчик, а другой человек, пусть даже он прошёл дополнительное обучение. То есть шаблонные и рутинные задачи отдаются от разработчика другим специалистам, бизнес сокращает издержки, может развиваться и генерировать новые задачи для разработчиков.
Хорошим примером является 1С. Разработать с нуля бухгалтерскую систему — нетривиальная задача. А вот взять готовую конфигурацию 1С и немного настроить её под конкретное предприятие — уже проще. При этом мы понимаем, что те разработчики, которые разрабатывают платформу 1С, очень сильно отличаются от тех разработчиков, которые конфигурируют решения на 1С. В финансовой сфере — аналогично.
Ещё пример. Написать свою BPMS — это сложно и долго. Сконфигурировать нужные процессы в уже готовой BPMS — уже проще.
Смысл в том, что максимально квалифицированные инженеры и архитекторы работают один раз, а потом поддержка и развитие могут осуществляться менее квалифицированными и дорогими кадрами.
Возможно потому, что у финансового сектора есть деньги на вот это вот всё:
"Вам нужно выработать итоговые требования, развернуть вокруг этой самой Camunda обвязку из микросервисов, большая часть из которых будет интеграционной, встроить это все в архитектурный ландшафт конкретной корпорации, реализовать интеграцию с сервисами подрядчиков и очень много других важных вопросов, где нужно думать, а не писать код."
После того, как "грядки вскопаны", можно и low-кодить. Я с BPMS работал не очень плотно (1 год, Intalio BPMS, лет 10 назад), поэтому это всего лишь моё предположение. Внутри "песочницы" можно делать очень гибко, но интегрировать "песочницу" в окружающий мир - это больно.