На рынке появилось множество систем, позиционируемых как Low-Code, No-Code и Zero-Code. В чем состоят ключевые различия между этими подходами и технологиями, насколько эти различия кардинальны, какова польза и ценность этих инструментов для бизнеса и на какие перспективы можно рассчитывать тем, кто их применяет, — обо всем этом мы попросили рассказать Виктора Фогельсона, директора по развитию компании «Сакура PRO», разработчика платформы Zero-Code.

— В чем Вы видите ключевые различия между подходами и технологиями Low-Code, No-Code и Zero-Code?

Ключевое различие Low-Code от двух других подходов в том, что No-Code и Zero-Code предполагают полный отказ от ручного кодирования — пользователям предлагается работать только с визуальными формами, конструкциями и настройками.

Платформы с низким уровнем кода чаще всего используется ИТ-специалистами, обладающими некоторыми навыками программирования, для создания пользовательских приложений, в то время как платформы Zero-Code обычно предоставляют возможность не только программистам или разработчикам, но и бизнес-пользователям, не имеющим даже базовых знаний о кодировании, удовлетворять любые свои потребности в разработке бизнес-приложений, начиная с логистики и заканчивая транзакциями с цифровым рублем.

Кстати, немного об истории Low-Code. Еще в 1989 году на рынок вышел очень интересный и прогрессивный для своего времени продукт Lotus Notes — пожалуй, первый широко известный инструментарий Low-Code. Он был ориентирован на создание систем электронного документооборота, а точнее, workflow — для совместной работы с документами.

— Принято считать, что подходы Low-Code, No-Code и Zero-Code кардинально меняют традиционные подходы к разработке программных систем. Насколько Вы с этим согласны?

Что такое «Low» подход? Как метко заметил один архитектор, «Low» — это, с точки зрения математики, нечеткое множество (его определение дал Лотфи Заде). Не «1» (код есть) и не «0» (кода нет), а что-то между. Как ложка дегтя в бочке меда: ее количество важно, но она все равно есть. Вы можете спросить меня: «Сколько ложек дегтя (в нашем случае кода) в вашей бочке меда?» Так как наша «Сакура PRO» — это продукт Zero-Code, у нас мед чистый, без кода.

Традиционный цикл разработки (анализ, затем проектирование, кодирование, тестирование и последующая доработка) остается традиционным даже при использовании Low-Code. Разница лишь в объеме ручного кодирования: Low-Code его сокращает, но полностью от него не избавляет. Процесс ускоряется, но вам все равно требуются технические задания (ТЗ), программисты и тестирование. Сколько это будет «ложек дегтя», каждый производитель платформы решает сам, а дальше мучается бизнес-пользователь, который в сжатые сроки не сможет внедрить необходимый функционал, потому как требуется программирование, а это человеческий фактор, следовательно, быстро сделать все равно не получится.

И важный нюанс: полный отказ от кода обеспечивают только подходы No-Code и Zero-Code. Как я уже сказал, Low-Code лишь оптимизирует процесс, но не отменяет его. Любая из платформ — это инструмент. Zero-Code — платформа с широким набором инструментальных возможностей, она не просто облегчает процесс проектирования, а позволяет любым пользователям и разработчикам, например, без особых усилий подключаться к нескольким источникам данных. Кроме того, платформа Zero-Code заметно упрощает совместную работу над любым проектом.

— С чем связан резко возросший в последние годы интерес к подходам и технологиям Low-Code и No-Code?

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

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

Почему это прорыв? Во-первых, потому, что бизнес-специалисты, часто молодые и продвинутые в части технологий, быстро осваивают инструменты Zero-Code. Во-вторых, повторюсь, не нужны ТЗ, долгая разработка и тестирование — результат создается сразу. В-третьих, ИТ-службы переходят в режим поддержки инфраструктуры, а не ручного кодирования.

Что можно сделать на Zero-Code? Очень многое: ETL-процессы, дашборды, MDM-справочники, отчеты — и все это без посредников и лишних этапов.

Как итог, платформы No-Code и Zero-Code не просто ускоряют разработку — они меняют саму логику создания ПО, передавая инициативу в руки бизнеса.

— Как бы Вы характеризовали положение этих технологий относительно кривой жизненного цикла товара или продукта?

Кривая жизненного цикла продукта редко бывает линейной. Взять тот же iPhone: первые годы продажи росли медленно, а резкий скачок произошел лишь спустя пять лет. Аналогичная ситуация с Low-Code, No-Code и Zero-Code: по данным аналитиков, устойчивый рост этого сегмента начался в 2021–2022 годах, а к 2024–2025 ожидается выход на фазу быстрого роста.

Правда, аналитики часто смешивают Low-Code и No-Code/Zero-Code, хотя разница между ними принципиальна. Zero-Code — это следующая эра в создании приложений. Уверен, что скоро мы увидим еще один квадрант Gartner, который выделит Zero-Code в отдельный сегмент.

Наша практика подтверждает эти тренды. За 34 года работы с крупнейшими корпорациями нашей страны мы глубоко изучили запросы крупного бизнеса и в качестве ответа на них создали собственную платформу Zero-Code.

— Есть ли у подходов и технологий Low-Code, No-Code и Zero-Code какие-либо существенные ограничения, о которых следует помнить?

Что касается Low-Code, то это отсутствие контроля, привязка к поставщику, ограниченная настройка, проблемы безопасности, сложности интеграции, контроля версий и совместной работы. Также есть ограничения по масштабируемости и производительности. При этом полное обучение этим инструментам невозможно.

Но самым большим недостатком Low-Code является отсутствие контроля над базовым автоматически сгенерированным кодом и структурой приложения. Создавая простые приложения, вы, скорее всего, не слишком заботитесь об изменении сгенерированного кода. Некоторые разработчики Low-Code утверждают, что без программирования невозможно адаптировать систему под нужды крупного бизнеса. Наш опыт доказывает обратное, исключение составляют лишь сложные расчетные системы с математическими моделями (где, впрочем, бессильны и все прочие инструменты, в том числе Low-Code).

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

— Немалое число крупных организаций сегодня разрабатывает ПО для своих нужд на заказ. Насколько это эффективно или, наоборот, неэффективно по сравнению с No-Code и Zero-Code?

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

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

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

Другими словами, собственная разработка (если, конечно, речь не идет о компании-разработчике) — это, как правило, дорого, долго и сопряжено с множеством серьезных рисков. К нам последнее время приходит очень много заказчиков с подобным опытом.