Можно ли применять low-code в крупных ИТ-проектах

Конечно, применять low-code инструменты в крупных проектах можно. Иногда оптимальным будет начать разработку с быстрого внедрения и проверки гипотезы на основе таких конструкторов. Но на скором масштабировании решения уже возникнет достаточное для принятия решения о полноценной разработке количество проблем. В связи с этим платформы, применяющие low-code, занимают отдельную нишу в архитектуре крупных компаний. Оптимально это локальное/внутрикомандное обслуживание процессов, где частота изменений и их критичность не имеют большого влияния на конечный продукт. И иногда возможно использование на этапе проверки концепта или минимально жизнеспособного продукта (MVP), но на ограниченном объеме клиентской базы.

К проблемам, которые могут возникнуть при проектировании архитектуры для клиентских процессов с использованием low-code платформы, можно отнести такие области как ограниченность функционала, масштабирование, стабильность, безопасность, стоимость, зависимость от площадки и ограниченный рынок экспертов. Например, возможна реализация простой страницы заполнения ответов на вопросы в рамках продукта с использованием заранее настроенного на свой дизайн CMS-инструмента с использованием low-code. Это позволяет минимизировать затраты на разработку и оптимизировать срок выхода MVP-части проекта с новым продуктом. Но на старте сразу же необходимо запланировать полноценную версию собственной разработки в связи с необходимостью интеграции в усложненный процесс — который должен остаться неизменным или лучшим по качеству и скорости для клиента — с использованием дополнительных систем, таких как платформы, проводящие скоринг, или полноценные АБС-системы, которые обладают повышенными требованиями к безопасности. Также в случае апгрейда или масштабирования такого MVP при использовании только конструктора потребуются сначала специалисты с глубоким погружением в устройство и возможности платформы, которые при анализе изменений могут внести пару правок в процесс из-за особенностей low-code систем. Затем возникнут вопросы масштабирования, которые могут стать затратными даже при использовании микросервисов. Написание автотестов займет более длительное время из-за недостатка инструментов и наличия внутренней логики платформы. Все это плюс стоимость лицензий и поддержка от вендора станут большой нагрузкой на бюджет на длинной дистанции.

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

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