Привет. Я Андрей Путин, управляющий партнёр ИТ-интегратора kt.team. В последнее время мы всё чаще предлагаем своим крупным клиентам использовать в ИТ-архитектуре low-code решения. Их функционал позволяет быстро вносить изменения в интеграции и бизнес-процессы. Это критично для бизнеса, учитывая динамику изменений на рынке.
Forbes называет low-code трендом в первых строчках, в пользу использования low-code говорит статистика IDC, а низкая скорость изменений при традиционной разработке несёт угрозу бизнесу. Но несмотря на всё это, бизнес масштаба enterprise с осторожностью и даже недоверием относится к парадигме low-code. По мнению его представителей, прикладную разработку для крупных компаний можно осуществлять или на коробочных решениях, или с нуля. А инструментарий low-code «не соответствует масштабам задач enterprise и не обеспечивает достаточного уровня защиты коммерческой информации».
Сегодня мы разберём основные возражения по использованию low-code систем у бизнеса масштаба enterprise и выясним, насколько они справедливы.
Немного о парадигме low-code
Бизнес регулярно требует каких-то правок. Иногда минорных, например добавить атрибут или переместить кнопку, а иногда — более значимых, требующих разработки чего-то принципиально нового.
В традиционной парадигме code-first разработкой функционала и всеми правками занимается разработчик. Проигрывают при этом все. Разработчики — потому что по мере роста проекта они всё больше занимаются минорными правками и всё меньше — переиспользуемым кодом. Бизнес — потому что вынужден ждать изменения. Нам известны случаи, когда разработчики заняты минорными доработками, а в листе ожидания компании тем временем накапливается по 50 и более проектов.
В концепции low-code разработчик создаёт не конечную ценность, а конструктор для её сборки. Собирать или переконфигурировать ценность в конструкторе быстрее и проще: этим могут заниматься не только разработчики, но и бизнес-аналитики или конечные пользователи с навыками разработки (те, кого Gartner называет citizen developers). Более того, для некоторых задач такие конструкторы уже есть: например, бессмысленно делать конструктор интеграций или API, когда существуют Talend, Mule, WSO2.
Каждая low-code система ориентирована на решение определённых специфичных задач: моделирование и исполнение бизнес-процессов, моделирование данных, проектирование и разработка интеграций, моделирование игр, конструирование фронтенд-интерфейсов и т. д.
Концепция low-code известна с 90-х годов, но сейчас она стала особенно актуальной, поскольку позволяет сократить период time to market, ускорить разработку новых бизнес-процессов и внесение изменений в уже существующие.
В low-code потребность в разработчиках для корректировок бизнес-требований минимальна. Они нужны для реализации новых элементов конструктора и для конфигурирования первичной ценности с целью проверки правильности элементов конструктора.
Отсюда появляется первое возражение enterprise-бизнеса.
Возражение № 1. «Наши процессы слишком специфичны»
Одинаковых компаний не бывает. Одни и те же бизнес-процессы даже у компаний в одном сегменте могут быть выстроены с использованием разной логики. Поэтому нам легко понять опасения владельца продукта, что low-code конструктора не хватит для нужного ему функционала.
На деле же code-first ограничивает возможности реализации специфичных процессов сильнее, чем low-code.
Представим, что вы выбираете парадигму code-first и работаете с некой коробкой или разрабатываете эту коробку. Она насыщена определёнными сущностями, функционалом, терминами.
Чем мощнее этот стартовый функционал коробки, тем сложнее будет вносить изменения в систему. Чем больше изменений вы будете вносить, тем меньше людей в принципе будут понимать, что и как работает: сложность вносимых изменений будет повышаться, и неважно, микросервисная у вас архитектура или монолитно-модульная.
Ответственность за результат размоется. На претензию: «Почему вы сделали неудобно?» — разработчики будут отвечать: «Почему вы так плохо описали требования?» Разработчики утонут в change-реквестах, бизнес будет игнорировать часть требований. Команда разработки станет «бутылочным горлышком» всех изменений — следовательно, по теории ограничений вам придётся строить другие процессы с учётом этого.
Частью функционала коробки вы не будете пользоваться, ещё часть будет подходить вам при адаптации бизнес-процессов под коробку.
В итоге появятся новые, не свойственные вашему бизнесу термины, в ряде случаев интерфейсы управления будут избыточно сложны, в ряде случаев с какими-то нюансами придётся мириться.
Да, можно возразить, что в таких продуктах — «лучшие практики». Однако эти практики могут не соответствовать текущей культуре компании, и в результате «лучшие практики» превратятся в карго-культ.
Сравните это с работой в парадигме low-code. Low-code решения не предлагают «лучшие практики»: при помощи конструктора вы проектируете решение, которое максимально соответствует особенностям вашего бизнеса.
При этом разработчики не сосредоточены на бесконечных минорных правках. Они занимаются новым функционалом и новыми элементами конструкторов, исследуют инженерные подходы. Разработка с каждым днём делает конструктор всё более разнообразным и удобным для бизнеса.
Что же касается «лучших практик», то многие low-code решения имеют уже сконструированные приложения, например CRM или готовые интеграции. Но при этом готовые решения практически никогда не являются фиксированной системной особенностью — всё можно поменять. Уходят в прошлое возражения про системные атрибуты и сложность переопределения части коробки.
Возражение № 2. «Лицензии на low-code системы дорого стоят»
У low-code платформ есть несколько моделей монетизации. Например, в Talend монетизация осуществлена за счёт мест разработчиков: неважно, сколько интеграций у вас уже запущено, — важно, сколько людей работают над внесением изменений в них. При этом в контуре продуктивных серверов у вас нет лицензируемых частей.
А часть решений действительно являются SaaS и оплачиваются по пользователям. Давайте разберём именно этот кейс.
1. Разное восприятие расходов на лицензии и разработку мешает объективно сравнивать их.
Покупка лицензий и оплата разработки проходят по разным «центрам задач» и по-разному отражаются на экономике проекта. Это мешает сравнивать расходы на паритетных началах, в рамках проекта стоимость лицензий кажется более заметной.
2. Лицензии дешевле, чем разработка с нуля.
Покупая лицензию на любой продукт — неважно, является ли он low-code, — вы платите за готовый продукт, с помощью которого будете решать задачи. Как правило, стоимость лицензии ниже, чем у проекта по созданию самописного продукта с аналогичным наполнением и функционалом. А в случае с low-code решениями риск несоответствия функционала задачам неактуален: функциональность конструктора оценить проще, чем узнать все нюансы уже готового функционала.
3. У лицензий простая экономика без фактора неопределённости.
Вам сразу понятно, сколько вы заплатите за количество пользователей low-code решения. А сколько предстоит платить за разработку нового функционала, сложно предположить заранее. Ведь нужно учесть трудозатраты владельца продукта и большее время ожидания функционала, часто даже зарплаты разработчиков компании не являются частью бюджета функционала. Бывает, что крупный бизнес даже не считает эти затраты, и они размываются в общем бюджете.
4. В low-code вы покупаете не только инструменты визуальной разработки, но и лучшие практики конструирования процессов.
Никто не может знать, как удобнее построить бизнес-процесс в вашей организации. Но при этом есть практики реализации типовых действий, которые помогут вам выстроить более прозрачный и управляемый процесс за меньшее количество итераций.
Например, low-code ESB-системы задают некоторые паттерны проектирования интеграций в части логирования, мышления терминами «поток»/«линия» и т. д. Low-code бизнес-процессы задают стандарты проектирования процессов. Разрабатывая аналогичный бизнес-процесс своими силами, вы, скорее всего, придёте к таким же практикам, но не сразу. Вспомните, например, часто ли ваши менеджеры пользуются BPMN при согласовании процессов? А использование LCAP позволяет сократить путь поиска оптимального решения в разы.
Возражение № 3. «Всё в облаке, это небезопасно»
Мы сталкиваемся с этим возражением довольно часто. У бизнеса вызывает опасение тот факт, что low-code решение хранится «где-то в облаке, на чьих-то серверах, мы его не контролируем».
На это возражение есть несколько ответов.
Во-первых, не все low-code системы обязательно разворачивать именно в облаке. Поставщики этих решений предоставляют заказчику выбор: облачное решение или решение внутри вашей экосистемы, а часть решений даже имеют открытый исходный код (Strapi, Pimcore, Corteza, Builder). Обычно лицензия для разворачивания на серверах в контуре компании стоит дороже, но такая возможность всё же есть.
Во-вторых, даже облачные решения потенциально можно разместить на приватных облаках. Такую опцию, например, предлагает Power BI из экосистемы Microsoft: «ваш» Power BI может быть размещён на выделенных серверах платформы Azure, в отдельной части дата-центра.
У e-Commerce low-code также есть планы, согласно которым они могут предоставлять клиентам приватные облака.
Если же вы сами решили перестроить in-house разработку в low-code парадигму, то с точки зрения безопасности у вас и вовсе ничего не меняется.
Возражение № 4. «Концепция low-code не предназначена для highload-проектов»
Как раз напротив: многие 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 не отличается от других концепций.
Однако есть ситуации, когда сама концепция low-code может не подходить бизнесу.
Если вы готовы подстраиваться под существующую коробку. В этот пункт обычно попадают второстепенные бизнес-процессы и любые «пассивы». Например, какая разница, как гибко у нас начисляется зарплата или конфигурируется СКУД, если у этой гибкости нет никакого мультипликатора для бизнеса?
Разработку принципиально новых (инновационных) технологических решений в ряде случаев нельзя реализовывать в философии low-code. Важно понимать, что здесь идёт речь именно о технологических инновациях, а не инновациях в области бизнес-моделей.
Если вы ИТ-команда и вам сложно переучивать сотрудников на новый уровень абстракции, а дальнейшее сопровождение и внесение изменений в проект не подразумеваются.
Если у вас нет времени на перестройку (проект нужно запустить «вчера») или вы сталкиваетесь с огромным наследием старого кода.
Если у вас нет выбора. Например, вы часть корпорации, а набор технологий задан сверху. Так, много штаб-квартир используют Magento как стандарт e-Commerce, и региональные офисы тоже вынуждены использовать Magento.
Если вы хотите сохранить статус-кво и любые изменения парадигмы идут вразрез с вашими целями.
