Как писать меньше кода при создании корпоративных приложений? Разбираемся в отличиях традиционного подхода и Low-Code

В чем ценность Low-code

Ключевые преимущества Low-code инструментария выводят все этапы разработки корпоративного приложения на качественно новый уровень

Начнем с ключевой ценности Low-code для бизнеса – ускорения создания корпоративных приложений.

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

Low-code BPM позволяет разрешить эту ситуацию и выровнять ее. Это значит, что корпоративные приложения теперь создаются достаточно быстро, и очередь из потребностей бизнеса в автоматизации не формируется. Эту ценность сложно переоценить, потому что внешняя среда меняется крайне стремительно, всем нужна ускоренная автоматизация.

Еще одна важная мысль, которую стоит иметь в виду – сравнение подходов к автоматизации. Не секрет, что автоматизировать тот или иной бизнес-процесс или деятельность компании можно разными способами:

• Внедрение коробочного решения. Это значит, что покупается коробочное решение, которое затем настраивается за минимальное количество времени. Здесь можно говорить о низкой стоимости владения и быстрых сроках автоматизации, но у коробочных решений есть один фатальный недостаток – это усредненный функционал. Такой функционал, как правило, использует большинство компаний и, таким образом, они становятся похожи. Уникальные бизнес-процессы компании внутри коробки просто невозможно реализовать. Многих такое положение дел не устраивает, потому что именно в уникальных бизнес-процессах кроются конкурентные преимущества.
• Самостоятельная разработка. В этом случае компания сама разрабатывает корпоративное приложение. Так же к самостоятельной разработке можно отнести адаптацию под себя ERP-систем – SAP, 1С и др. Самостоятельная разработка считается дорогой, потому что необходимо держать большое количество ИТ-специалистов и разработчиков в штате. Автоматизация в этом случае может занимать годы.
• Применение Low-code BPM-системы. Стоимость разработки в этом случае снижается многократно, и высококвалифицированные штатные специалисты не нужны. Low-code – это про быструю автоматизацию.

Чем традиционная разработка отличается от Low-code подхода

Давайте сравним традиционный подход к разработке с Low-code подходом. Для этого посмотрим на стандартный процесс разработки, который состоит из 5-ти шагов:
1) формирование требований
2) разработка
3) стабилизация
4) развертывание
5) эксплуатация и поддержка

Далее расшифруем каждый из шагов:

• Формирование требований: На этом шаге пишется техническое задание на внешний или внутренний проект. Аналитики работают с бизнес-заказчиками и переводят язык бизнеса на формальный язык ИТ.
• Разработка: Этап начинается после утверждения технического задания, которое затем передается разработчикам. Разработка – длительный и трудоемкий процесс, может занимать от нескольких месяцев до года и более.
• Стабилизация. Этот этап подразумевает тестирование системы представителями бизнеса. Бизнес-пользователи обживаются в новой ИТ-системе, проходят все сценарии ее использования и формируют фитбэк ИТ-специалистам.
• Развертывание: на этом этапе тестирование завершено, и необходимо обновить текущую информационную систему, либо развернуть совершенно новую систему на нашем продуктивном ландшафте. Это по сути накатывание ИТ-системы на сервера, ее развертывание и массовое подключение пользователей.
• Эксплуатация и поддержка: корпоративное приложение находится в продуктивной среде, его нужно поддерживать с точки зрения всевозможных доработок, выделения вычислительных мощностей и обеспечения доступности в режиме 24/7 с заданными параметрами отклика.

Это 5 этапов классической разработки информационной системы в бизнесе. Далее рассмотрим каждый из этих этапов в отдельности и покажем, как они меняются при переходе на Low-code.

В классическом подходе формирование требований – это продолжительная и трудоемкая процедура. Компании необходимо иметь хороших аналитиков, которые, во-первых, понимают бизнес-язык, во-вторых, понимают язык ИТ.

Задача аналитиков на этом этапе – написание качественного ТЗ. С этим, как правило, возникают сложности, поскольку информационной системы еще нет, и бизнес не может детально сформулировать свои требования. Аналитики вынуждены оставлять «белые пятна» в техническом задании с пометкой «бизнес формализует требования по ходу проекта».

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

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

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

Этап разработка - самый трудоемкий из всего цикла создания корпоративного приложения. В классическом подходе команда получает техническое задание и далее разрабатывает информационную систему с нуля или на базе ERP-системы. Часто бывает такое, что в командах разработчиков происходит ротация. Это значит, что если разработчик срочно понадобился на проекте «В», он снимается с проекта «А». Смена состава команды удлиняет разработку. И, конечно, те самые «белые пятна», которые были оставлены аналитиками при формировании ТЗ, начинают влиять на процесс разработки и сроки.

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

Как выглядит подход с точки зрения Low-code: меняются требования к команде разработчиков, кодирования становится меньше. Более того, Low-code BPM соответствует Agile подходу в разработке. Это значит, что можно двигаться спринтами с детализацией требований по месту, и при этом иметь работающее корпоративное приложение - в рамках спринтов происходит усложнение разрабатываемого приложения.

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

Стабилизация. В классическом подходе, разработчики выдают тестовую систему, и в рамках стабилизации тестовая группа пользователей проверяет корпоративное приложение.

С чем в этом случае может столкнуться тестовая группа пользователей и сами разработчики?

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

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

Стабилизация с помощью Low-code проходит гораздо проще и быстрее. Необходимые изменения в корпоративное приложение можно вносить в режиме реального времени при встрече с заказчиком.

Развертывание на продуктивных серверах предполагает массовое подключение пользователей к системе. Это происходит после того, как завершена тестовая эксплуатация и система принята тестовой группой пользователей.

Обновление продуктивной среды - это сложная процедура, которая подразумевает регламенты управления обновлениями и изменениями.

Запуск нового приложения сопряжен с рисками, связанными с текущим ИТ-ландшафтом, интеграцией системы с другими системами.

Low-code BPM облегчает процедуру развертывания. Например, в ELMA365 Low-code BPM реализована архитектурная изоляция приложений. Это значит, что при обновлении приложения или целого раздела целостность системы не теряется, и информационная система работает без сбоев. Более того, обновление отдельного приложения происходит в режиме реального времени и не подразумевает остановку системы.

Традиционно Low-code BPM подразумевает разделение сред разработки, тестирования, продуктивной эксплуатации и автоматизированный перенос отдельных приложений между этими средами.

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

Вновь обратимся к примеру ELMA365 Low-code BPM - она использует микросервисную архитектуру. Это дает возможность "упаковать" отдельные микросервисы в контейнеры (Docker), а использование платформы Kubernetes дает непревзойденную гибкость управления вычислительными мощностями.

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

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