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

Возражение № 1. «Наши процессы слишком специфичны»

Возражение № 2. «Лицензии на low-code системы дорого стоят»

Возражение № 3. «Всё в облаке, это небезопасно»

Возражение № 4. «Концепция low-code не предназначена для highload-проектов»

Для каких проектов не подходит low-code

Время на прочтение: 9 мин. Привет. Я

Андрей Путин, управляющий партнёр ИТ-интегратора kt.team. В последнее время мы всё чаще предлагаем своим крупным клиентам использовать в ИТ-архитектуре low-code решения.

Их функционал позволяет быстро вносить изменения в интеграции и бизнес-процессы.

Но несмотря на всё это, бизнес масштаба enterprise с осторожностью и даже недоверием относится к парадигме low-code.

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

А инструментарий low-code «не соответствует масштабам задач enterprise и не обеспечивает достаточного уровня защиты коммерческой информации».

Сегодня мы разберём основные возражения по использованию low-code систем у бизнеса масштаба enterprise и выясним, насколько они справедливы.

Одни и те же бизнес-процессы даже у компаний в одном сегменте могут быть выстроены с использованием разной логики.

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

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

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

Она насыщена определёнными сущностями, функционалом, терминами.

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

Чем больше изменений вы будете вносить, тем меньше людей в принципе будут понимать, что и как работает:

• сложность вносимых изменений будет повышаться
• и неважно
• микросервисная у вас архитектура
• монолитно-модульная

Ответственность за результат размоется. На претензию: «Почему вы сделали неудобно?»

- разработчики будут отвечать: «Почему вы так плохо описали требования?»

Разработчики утонут в change-реквестах, бизнес будет игнорировать часть требований. Команда разработки станет «бутылочным горлышком»

всех изменений - следовательно, по теории ограничений вам придётся строить другие процессы с учётом этого.

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

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

При этом разработчики не сосредоточены на бесконечных минорных правках.

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

Разработка с каждым днём делает конструктор всё более разнообразным и удобным для бизнеса.

Что же касается «лучших практик», то многие low-code решения имеют уже сконструированные приложения, например CRM или готовые интеграции.

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

Уходят в прошлое возражения про системные атрибуты и сложность переопределения части коробки.

Разное восприятие расходов на лицензии и разработку мешает объективно сравнивать их. Покупка лицензий и оплата разработки проходят по разным «центрам задач» и по-разному отражаются на экономике проекта. Это мешает сравнивать расходы на паритетных началах, в рамках проекта стоимость лицензий кажется более заметной.

На это возражение есть несколько ответов. Во-первых, не все low-code системы обязательно разворачивать именно в облаке.

Поставщики этих решений предоставляют заказчику выбор:

• облачное решение или решение внутри вашей экосистемы
• а часть решений даже имеют открытый исходный код (Strapi
• Pimcore
• Corteza
• Builder)

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

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

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

Как раз напротив: многие low-code системы по умолчанию предназначены для работы с highload.

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

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

Один нюанс: не всегда у бизнеса есть корректное представление о том, что такое highload.

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

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

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

Лучше сконцентрироваться на других вопросах и бизнес-целях.

Но даже если у вас действительно highload-проект, это не исключает возможности применения low-code.

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

Это сделано не столько потому, что выбранное решение «не потянет» highload, сколько для лучшего контроля и отказоустойчивости.

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

Если вы ИТ-команда и вам сложно переучивать сотрудников на новый уровень абстракции, а дальнейшее сопровождение и внесение изменений в проект не подразумеваются.

Если у вас нет времени на перестройку (проект нужно запустить «вчера») или вы сталкиваетесь с огромным наследием старого кода.

Если вы хотите сохранить статус-кво и любые изменения парадигмы идут вразрез с вашими целями.