Так заведено, что сложные проекты требуют серьезных инструментов. К примеру, финтех-продукты холдинга IDF Eurasia, в том числе и Своего Банка, где я работаю, разрабатываются на далеко не самых простых языках Java и Kotlin. И, казалось бы, использование сложных форм — это само собой разумеющееся. Но из головы никак не выходят low-code инструменты, минимизирующие объем работ для запуска функционала, о которых без устали говорит IT-сообщество. Вот и на Хабре уже, казалось бы, все писано-переписано. Но давайте все же еще поразмышляем))

Low-code vs. Pro-code: чем они отличаются и зачем нужны?

Для начала необходимо разделить между собой понятия low-code инструментов и их собратьев Pro-code. 

Под low-code инструментами понимаются платформы, которые позволяют реализовать продукт или его часть с использованием готовых форм и операций с параметрами или с применением внутреннего DSL (предметно-ориентированного языка программирования).

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

Например, такой подход можно применить для создания и обновления лендингов. Разработанный фронтенд-командой дизайн можно настроить в системе управления контентом (CMS), таких как WordPress или Joomla, что позволит бизнес-маркетологу создавать и изменять страницы в течение нескольких часов.

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

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

Риски и подводные камни low-code при использовании в крупных проектах

Но как бы не казалось простым и удобным разработка с использованием “лоу-кода”, нужно понимать, что само внедрение в большие проекты требует очень серьезной предварительной работы. При создании шаблона, который будет использоваться во множестве разных мест - требуется учесть особенности платформы и то, как в дальнейшем он будет применяться. На какие устройства будет применяться шаблон - только сайт или ещё и Android/iOS устройства, планшеты и т.д.? В какие базы данных будет складироваться информация и в каком объеме? И множество других вопросов. Если упустить такие вещи из виду, то могут возникнуть проблемы при его изменении или применении в случаях отличных от первоначального запуска.

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

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

Наш опыт использования low- и pro-code

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

В проекте «Свой Банк» мы используем Camunda для работы со сложными процессами блокировки операций клиентов. Эти процессы включают обработку нескольких систем и множества объектов, где ошибки недопустимы. Camunda позволяет нам сосредоточиться на интеграциях и сценариях, предоставляя готовые возможности для повторного выполнения шагов в случае ошибок или сбоев какого-либо сервиса. Кроме того, она предлагает удобный интерфейс для мониторинга и отладки процессов, которые оформлены в понятной нотации как для бизнес-, так и для IT-специалистов.

Также в команде Web Development (Marketing) используют low-code систему готовых компонентов (на основе плагина для WordPress AFC Pro). Бизнес-маркетолог собирает страницу из элементов, выбирает их порядок, наполняя каждый контентом, текстом и изображениями.

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

Коллаборация pro-code и low-code инструментов

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

Где внедрить low-code, чтобы не было больно?

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

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

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

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