Антитренды: как low-code превращается в хаос и убытки

Автоматизация без стратегии

Многие компании используют low-code без архитектурного замысла, что приводит к хаосу и удорожает поддержку, особенно при обновлениях. По словам Дмитрия Коряковского, руководителя направления продуктовой разработки LDM, многие считают low-code «простым и легким в использовании инструментом». Поэтому, вместо того чтобы проработать стратегию, клиенты начинают собирать решения «на лету». В итоге «штамповка хаотичных приложений приводит к тому, что компания получает вместо ИТ-экосистемы «лоскутное одеяло», которое трудно поддерживать или дорабатывать».

Владимир Тарасенко, коммерческий директор ТУРБО, называет это явление «островками автоматизации вместо цифровой стратегии». Он уточняет: «Достаточно часто low-code используется без архитектурного замысла. Это превращается в хаос, что удорожает поддержку, и особенно критично в части обновлений. В ТУРБО этот сценарий исключен: архитектура продумана таким образом, чтобы low-code дополнял и развивал функционал там, где это действительно нужно».

Константин Саратцев, директор направления Insight, Goodt, подчеркивает, что «когда речь идет про ИТ-ландшафт, на первое место всегда ставится архитектура, а на второе место — процессы вокруг этой архитектуры, которые и призваны создавать новые ИТ-подходы, в том числе и low-code».

Иллюзия, что «разработчик больше не нужен»

Существует иллюзия, будто бизнес-аналитики могут самостоятельно создавать приложения без участия ИТ-специалистов. Владимир Тарасенко отмечает, что это «приводит к нестабильным приложениям и проблемам с безопасностью». Он настаивает на необходимости баланса: бизнес должен получить инструмент визуальной сборки, а ИТ-отдел — контроль качества и масштабируемости решений.

Екатерина Герасимова, руководитель продукта BPMSoft, уточняет: «Конечно, уместно различать сценарии. Простые сервисы вроде формы обратной связи, опросов, Email-рассылок действительно можно внедрять локально силами самих подразделений. Но как только речь заходит о корпоративных решениях, где задействованы учетные записи сотрудников, персональные данные клиентов или интеграции с ERP и CRM, участие ИТ становится принципиально необходимым».

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

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

Вера в универсальность low-code

Зачастую пользователи верят, что на low-code можно сделать все, включая критично нагруженные системы. По словам Владимира Тарасенко, такие обещания «обычно превращаются в дорогие доработки и разочарование». Он утверждает, что low-code дает реальный выигрыш в скорости и гибкости для дополнительной пользовательской аналитики, а не для жестко регламентированных учетных процессов.

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

По мнению BPMSoft, поднятая проблема выглядит как противоречие между гибкостью и методологией. Екатерина Герасимова объясняет: «Некоторые клиенты выступают за системы, которые содержат встроенные лучшие практики и удерживают пользователя в рамках бизнес-процесса. В этом контексте чрезмерная гибкость low-code может быть воспринята как недостаток». Она отмечает, что на ранних стадиях зрелости избыточная гибкость мешает — поэтому в BPMSoft есть продукт «Старт», ограничивающий кастомизацию, но обеспечивающий рабочий набор процессов.

В Goodt делают акцент на архитектурном аспекте: low-code «технологически предназначен для работы с микросервисной архитектурой, именно в такой конфигурации он максимально эффективен». При попытке состыковать low-code с монолитными решениями, составляющими основу ИТ-инфраструктуры большинства компаний, получается «костыльное решение», которое невозможно нормально масштабировать.

Сергей Фокин, менеджер продукта CDP CleverData Join, дополняет: «При выборе инструментария для сложных бизнес-задач ключевым фактором является баланс между скоростью и гибкостью. Low-code-платформы отлично справляются с типовыми процессами и быстрым прототипированием. Однако при работе с уникальными требованиями, особенно там, где критичны производительность, безопасность и интеграция в сложные инфраструктуры, их применение может столкнуться с объективными ограничениями».

Low-code для «быстрых формочек»

Еще один распространенный миф — собранные «на коленке» прототипы быстро превращаются в промышленные системы. В действительности именно этот тезис часто звучит в публикациях как претензия к технологии. В BPMSoft считают его заблуждением: «В low-code прототип изначально — это не макет в PowerPoint, а рабочая форма, процесс, дашборд. Дальше все зависит от характера задачи: стратегический процесс разумно провести через тестовую среду, но масса сценариев допускает быстрые изменения без сложных циклов». Таким образом, проблема «нежизнеспособных прототипов» связана не с платформой, а с организационным развитием процессов в компании.

Закрытые монолитные платформы

Опасения, что платформа в формате «все в одной коробке» со временем плохо интегрируется с другими системами и превращает компанию в заложника одного вендора, также часто звучат в обсуждениях. В BPMSoft уточняют: «Все зависит от конкретной платформы и ее интеграционных возможностей. В BPMSoft мы делаем акцент именно на универсальных средствах интеграции. Платформа поддерживает как инструменты low-code и готовые коннекторы, так и более широкие инструменты, позволяющие гибко разрабатывать собственные сервисы. Выбор инструмента зависит от объема данных, зрелости компании и требований к скорости интеграции».

Екатерина Герасимова подчеркивает: «Low-code, наоборот, может выступать интеграционным слоем между разными корпоративными системами. Что касается риска оказаться заложником, он определяется стратегией поставщика. При выборе платформы важно смотреть не только на цену. Надежность определяется зрелостью вендора, дорожной картой продукта, референсными проектами и экосистемой партнеров».

Goodt добавляет: «В основе ИТ-инфраструктуры большинства компаний сегодня лежат монолитные западные решения, считавшиеся золотым стандартом. Состыковка low-code с монолитом может дать до 15–20% эффекта в моменте, но в перспективе это проигрышный способ: любое изменение ломает конструкцию и масштабировать ее невозможно».

Игнорирование стандартов и сообществ

Закрытые решения без API и поддержки комьюнити быстро упираются в потолок. Как говорит Дмитрий Коряковский, «сложно интегрировать новые сервисы, найти специалистов и масштабировать систему».

Екатерина Герасимова отмечает, что при выборе платформы важно смотреть не только на функциональность, но и на экосистему вокруг продукта. «Мы уделяем большое внимание развитию нашей экосистемы: у нас широкая партнерская сеть, сообщество сертифицированных пользователей, школа low-code, программа сотрудничества с университетами. Партнерская сеть постоянно растет, что гарантирует доступность специалистов и поддержку рынка».

С точки зрения интеграции ограничений тоже нет: «платформа поддерживает открытые протоколы, включая отраслевой стандарт OData, а также конструктор вебхуков, позволяющий ускорить и упростить интеграции. При наличии доступа можно реализовать подключение к любой внешней системе», — подчеркивают в BPMSoft.

Константин Саратцев предупреждает: поскольку low-code-решения часто подразумевают функционирование в облаке, на первый план выходят вопросы информационной безопасности. При незащищенных коннекторах или API существует «реальный риск потери критически важных данных». Также он отмечает киберриски, связанные с непреднамеренными ошибками при работе с данными: «неправильно настроенные права доступа могут привести к масштабным искажениям данных, что пагубно отразится на процессах и потребует сил на откат».

Сергей Фокин из CleverData Join добавляет: «Нужно понимать, что low-code — это не только визуальный конструктор, но и жесткие рамки платформы. Сложные, высоконагруженные системы часто упираются в ограничение возможностей. Кроме того, успешная реализация и, что важнее, долгосрочная поддержка low-code-решений требуют от команды заказчика серьезной экспертизы — как в предметной области, так и в нюансах самого инструмента».

Как итог

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

Как отмечают в BPMSoft, гибкость и методология не противоречат друг другу: «на разных этапах развития компании акцент смещается от готовых практик к глубокой настройке. Задача low-code и поставщиков решений — сопровождать клиента на всем пути».

Константин Саратцев резюмирует: «Ключевое конкурентное преимущество любого бизнеса сейчас — это хорошо отлаженные ИТ-процессы. Поэтому при выборе решения на экспериментальной платформе предпочтение следует отдавать проверенным и надежным разработчикам с хорошей историей и опытом, которые проводят регулярные тестирования и имеют ИБ-сертификаты».

И, как заключают в CleverData Join, «для нестандартных задач, где важны точечная оптимизация, надежность и полное соответствие архитектурным требованиям, более предсказуемый и экономически обоснованный результат в долгосрочной перспективе часто показывают классические подходы к разработке. Они позволяют создать решение без архитектурных компромиссов, исключая избыточность и потенциальные уязвимости, заложенные в универсальных инструментах».

Таким образом, будущее low-code зависит от зрелости архитектурных подходов и грамотного управления, а не от слепой веры в «волшебную таблетку».