Правда ли, что low-code нельзя применять в enterprise-решениях: разбираемся с основными возражениями

Бизнес регулярно требует каких-то правок. Иногда минорных, например добавить атрибут или переместить кнопку, а иногда — более значимых, требующих разработки чего-то принципиально нового.

В традиционной парадигме code-first разработкой функционала и всеми правками занимается разработчик. Проигрывают при этом все. Разработчики — потому что по мере роста проекта они всё больше занимаются минорными правками и всё меньше — переиспользуемым кодом. Бизнес — потому что вынужден ждать изменения. Нам известны случаи, когда разработчики заняты минорными доработками, а в листе ожидания компании тем временем накапливается по 50 и более проектов.

В концепции low-code разработчик создаёт не конечную ценность, а конструктор для её сборки. Собирать или переконфигурировать ценность в конструкторе быстрее и проще: этим могут заниматься не только разработчики, но и бизнес-аналитики или конечные пользователи с навыками разработки (те, кого Gartner называет citizen developers). Более того, для некоторых задач такие конструкторы уже есть: например, бессмысленно делать конструктор интеграций или API, когда существуют Talend, Mule, WSO2.

Каждая low-code система ориентирована на решение определённых специфичных задач: моделирование и исполнение бизнес-процессов, моделирование данных, проектирование и разработка интеграций, моделирование игр, конструирование фронтенд-интерфейсов и т. д.

Концепция low-code известна с 90-х годов, но сейчас она стала особенно актуальной, поскольку позволяет сократить период time to market, ускорить разработку новых бизнес-процессов и внесение изменений в уже существующие.

В low-code потребность в разработчиках для корректировок бизнес-требований минимальна. Они нужны для реализации новых элементов конструктора и для конфигурирования первичной ценности с целью проверки правильности элементов конструктора.

Отсюда появляется первое возражение enterprise-бизнеса.

Одинаковых компаний не бывает. Одни и те же бизнес-процессы даже у компаний в одном сегменте могут быть выстроены с использованием разной логики. Поэтому нам легко понять опасения владельца продукта, что low-code конструктора не хватит для нужного ему функционала.

На деле же code-first ограничивает возможности реализации специфичных процессов сильнее, чем low-code.

Если вы выбираете парадигму code-first, то работаете с некой коробкой или разрабатываете эту коробку. Она насыщена определёнными сущностями, функционалом, терминами.

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

Ответственность за результат размоется. На претензию: «Почему вы сделали неудобно?» — разработчики будут отвечать: «Почему вы так плохо описали требования?» Разработчики утонут в change-реквестах, бизнес будет игнорировать часть требований. Команда разработки станет «бутылочным горлышком» всех изменений — следовательно, по теории ограничений вам придётся строить другие процессы с учётом этого.

Частью функционала коробки вы не будете пользоваться, ещё часть будет подходить вам при адаптации бизнес-процессов под коробку.

В итоге появятся новые, не свойственные вашему бизнесу термины, в ряде случаев интерфейсы управления будут избыточно сложны, в ряде случаев с какими-то нюансами придётся мириться.

Да, можно возразить, что в таких продуктах — «лучшие практики». Однако эти практики могут не соответствовать текущей культуре компании, и в результате «лучшие практики» превратятся в карго-культ.

Сравните это с работой в парадигме low-code. Low-code решения не предлагают «лучшие практики»: при помощи конструктора вы проектируете решение, которое максимально соответствует особенностям вашего бизнеса.

При этом разработчики не сосредоточены на бесконечных минорных правках. Они занимаются новым функционалом и новыми элементами конструкторов, исследуют инженерные подходы. Разработка с каждым днём делает конструктор всё более разнообразным и удобным для бизнеса.

Что же касается «лучших практик», то многие low-code решения имеют уже сконструированные приложения, например CRM или готовые интеграции. Но при этом готовые решения практически никогда не являются фиксированной системной особенностью — всё можно поменять. Уходят в прошлое возражения про системные атрибуты и сложность переопределения части коробки.

У low-code платформ есть несколько моделей монетизации. Например, в Talend монетизация осуществлена за счёт мест разработчиков: неважно, сколько интеграций у вас уже запущено, — важно, сколько людей работают над внесением изменений в них. При этом в контуре продуктивных серверов у вас нет лицензируемых частей.

А часть решений действительно являются SaaS и оплачиваются по пользователям. Давайте разберём именно этот кейс.

Мы сталкиваемся с этим возражением довольно часто. У бизнеса вызывает опасение тот факт, что low-code решение хранится «где-то в облаке, на чьих-то серверах, мы его не контролируем».

На это возражение есть несколько ответов.

Во-первых, не все low-code системы обязательно разворачивать именно в облаке. Поставщики этих решений предоставляют заказчику выбор: облачное решение или решение внутри вашей экосистемы, а часть решений даже имеют открытый исходный код (Strapi, Pimcore, Corteza, Builder). Обычно лицензия для разворачивания на серверах в контуре компании стоит дороже, но такая возможность всё же есть.

Во-вторых, даже облачные решения потенциально можно разместить на приватных облаках. Такую опцию, например, предлагает Power BI из экосистемы Microsoft: «ваш» Power BI может быть размещён на выделенных серверах платформы Azure, в отдельной части дата-центра.

У e-Commerce low-code также есть планы, согласно которым они могут предоставлять клиентам приватные облака.

Если же вы сами решили перестроить in-house разработку в low-code парадигму, то с точки зрения безопасности у вас и вовсе ничего не меняется.

Как раз напротив: многие low-code системы по умолчанию предназначены для работы с highload. Обработка тысяч запросов в секунду для них не является критичной. К таким решениям относятся, например, Talend, Honeycode, Creatio, Strapi, Pimcore.

Мы замечаем обратное: часто эксклюзивная разработка, в теории предназначенная для высоких нагрузок, имеет огромный объём наследия, рефакторить которое сложно и дорого. В противовес этому многие low-code конструкторы раз за разом отлаживают скорость компонентов. Тут нужно оговориться, что low-code может избавить от многих технических проблем, но от ошибок проектирования информационных моделей, бизнес-процессов и прочего, что также влияет на итоговую производительность, не избавлена ни концепция low-code, ни парадигма code-first.

Один нюанс: не всегда у бизнеса есть корректное представление о том, что такое highload. Он обращается к ИТ-подрядчику с запросом на высоконагруженный проект, но на практике оказывается, что речь идёт о крупном подразделении с серьёзным оборотом. Например, B2B-портал, который обслуживает 3000 клиентов в день, или B2C интернет-магазин с миллионом посетителей в месяц даже не приближается к тому, что принято считать highload. Тут нет десятков тысяч одновременных сложных транзакций на запись и, скорее всего, в ближайшей перспективе не будет.

Пока ваш проект не подошёл к условной границе в 5000 транзакций в секунду, рано беспокоиться о том, поддерживают ли выбранные системы highload. Лучше сконцентрироваться на других вопросах и бизнес-целях.

Но даже если у вас действительно highload-проект, это не исключает возможности применения low-code. Мы знаем достаточно крупные экосистемы, которые построены из небольших «кусочков». Например, у «Тинькофф» есть множество отдельных BPMS (Camunda), каждая из систем работает со своим набором бизнес-процессов. Это сделано не столько потому, что выбранное решение «не потянет» highload, сколько для лучшего контроля и отказоустойчивости.

Концепция low-code достаточно универсальна. Да, для выбора конкретного решения нужно изучить его возможности и аналоги, но в этом low-code не отличается от других концепций.

Однако есть ситуации, когда сама концепция low-code может не подходить бизнесу.