Обсуждение возможностей low-code систем и выгод от их использования

Low-code системы — это не про автоматизацию

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

В 2004 году была разработана BPMN 1.0 - нотация управления бизнес-процессами (BPMN — Business project model and notation), с годами эволюционировавшая, и в 2014 году появилась версия BPMN 2.0, которая задала стандарт моделирования бизнес-процессов, применяемый и по сей день. BPMN 2.0 является эталоном инструмента моделирования, связующим звеном между этапом проектирования бизнес-процессов и реализацией в среде исполнения.

Исключительной особенностью нотации BPMN 2.0 явились ранее не используемые функциональные возможности, такие, как обработка исключительных ситуаций (ошибок) и поддержка ветвлений, которые привели вид линейных процессов (это главный посыл к подходу workflow - прохождения бизнес-процесса от стартового события к конечному) к зацикленным, что явилось предтечей нынешних roll-back транзакций в среде исполнения. С появлением этой версии нотации автоматизация бизнес-процессов стала уверенно шагать по планете.

Пионерами, которые применили на практике идею имплементации спроектированных бизнес-процессов, это BPMS (Business project management system), заложив в основу концепцию уменьшения затрат и повышения производительности.

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

• разрыв между моделированием процессов, проектированием и исполнением в процессе разработки;
• удлинение сроков реализации внесения изменений (полный цикл от внесения изменений в модель процесса до этапа тестирования).

На этой волне появились решения, продающие себя как Low-code системы быстрой автоматизации бизнес-процессов в противовес проверенным временем BPMS. Главный маркетинговый лозунг таких решений заключается в тезисе «быстрой (уже готовой) имплементации смоделированного (бизнесом) типового бизнес-процесса». На флаг вывешивается лозунг: зачем рисовать отдельный бизнес-процесс и затем отдельно заниматься его имплементацией, когда можно сократить процесс разработки путем автоматизированной передачи модели процесса в исполняемую среду. Идея звучит прекрасно! Видится, что технология представляет собой некий инструмент (конструктор), который выступает в роли «и жнец и на дуде игрец». Фактически происходит передача ответственности за валидацию, исполнение, создание концептуальных бизнес-сущностей, создания визуальных форм, переходов между формами, обработки исключительных ситуаций, раздачи разрешений в рамках ролевой модели на инструмент, который выступает в роли черного ящика в стиле «машины Тьюринга» - такого универсального и такого удобного, коего грезит любой заказчик со времен появления ИТ. Про ответственность бизнеса, моделирующего процесс, мы не упоминаем. Казалось бы, треугольник Хопкинса достигнут - быстро, дешево, качественно. Но в чем же собака зарыта?

Для начала систематизируем исторический подход появления low-code систем:

Что продают нам low-code платформы и как в действительности это интерпретировать

В официальных источниках основной упор на профицит современных low-code систем и платформ в отличии от классических (устаревающих) bpms делается на следующие аспекты:

Ускорение внедрения и изменений

Постулат: использование готовых инструментов и конструкторов позволяют производить внедрение и внесение изменений существенно быстрее.

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

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

Снижение зависимости от разработчиков

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

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

Снижение затрат на разработку и поддержку

Постулат: минимизация затрат на доработки и сопровождение ввиду отказа от узкоспециализированых разработчиков в сторону готовой платформы (инструмента) с визуальными компонентами и готовой функциональностью.

Реальность: Ответ простой. Готова ли компания, занимающаяся внедрением, сложить с себя ответственность и переложить ее на конструктор, который не обладает кастомизированной функциональностью? В данном случае речь идет о валидации процессов, трансформации в сущности базы данных, реализации всех заявленных гейтов и веток, всех исключений, ролевого доступа на уровне данных и прочего.

Надежность и катастрофоустойчивость

Постулат: обычно речь идет о микросервисной архитектуре, которая отвечает требованиям катастрофоустойчиости и надежности.

Реальность: На практике, зачастую, надежность и катастрофоустойчивость таких решений достигается средствами docker-kubernetes. «Модно-молодежно». На набор микросервисов (в экстремальных случаях один микросервис), выделяется единый образ docker. За падением docker-образа следует поднятие следующего образа. Все бы прекрасно, но... Сомнительная надежность системы, функционирующей в режиме постоянных сбоев и восстановлений. Акцент смещен не в сторону «не упасть», а в сторону «подняться после падения». Такой подход к надежности, основанный на постоянном восстановлении после сбоев, а не на их предотвращении, создает иллюзию надежности, пряча реальные проблемы за бесконечными перезапусками, увеличивает совокупную стоимость владения (TCO) и создает риски для критичных процессов.

Тема слишком обширная, чтобы развивать ее в рамках данной статьи. Мы выделили лишь один из самых очевидных аспектов, прямо влияющих на ТСО.

Гибкость, скорость, эффективность

Постулат: в совокупности с вышесказанным low-code подход обеспечивает все требования бизнеса нынешнего времени.

Реальность: Вопрос серьезный, требует пристального анализа и экспертизы. Как известно, за красивой картинкой дьявол кроется в деталях.

Можно выделить следующие аспекты, проработав которые, каждый сам сделает выводы для себя:

1. Моделирование исполняемого процесса и по сей день возлагается на человека - лица несущего ответственность.
2. Возложение валидации, с точки зрения исполнения модели процесса, на инструмент, не является гарантией, что сама модель оптимизирована и жизнеспособна.
3. Вопрос отладки и мониторинга исполнения экземпляров процессов, устранения инцидентов, и завершения («прибивания») подвисших процессов — все это остается за конечным исполнителем, а не за платформой.
4. Отвечает ли ролевая модель всем уровням запросов — разграничение прав доступа на уровне данных, персонализированные настройки доступа?
5. Упор делается на простые типизированные процессы. Как только речь заходит о видоизменении процессов в сторону добавления большого количества веток реагирования или реализации сложных нетипизированных индивидуальных процессов, то речь идет о «разработке на заказ».
6. Применение дополнительной прослойки в виде хранения запущенных инстансов процессов напрямую влияет на скорость работы приложения и отказоустойчивость. Обеспечивают ли заявленные требования системы, продвигающие такие технологии.

Решение на технологии LeanDI-Core

Компания LeanDI-core в вопросах автоматизации бизнес-процессов занимается разработкой программного обеспечения на платформе и технологии LeanDI-Core со встроенными конструкторами, что повышает скорость разработки. Подход «разработка от данных» позволяет делать акцент на глубоком анализе и проработке физической модели данных, которые обеспечивают целостность, непротиворечивость и полноту без избыточности.

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

Ускорение разработки достигается применением встроенного конструктора, который из описания модели данных генерирует следующие ключевые компоненты:

• ENTITY — бизнес-объекты уровня приложения
• AGV (Abstract grid view) — гриды/описи, формы представления списочных структур (объектов) в табличном представлении со стандартными возможностями фильтрации, CRUD, выгрузка в excel/csv
• AEF (Abstract edit form) — формы представления бизнес-объекта в режимах: создания, просмотра, изменения
• Подключаемый модуль/домен к платформе LeanDI-Core

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

Более наглядно можно посмотреть на схеме:

 

	LeanDI	Low-code системы
Контроль данных	6NF-модель с допущениями LeanDI-Core. Прозрачная и полностью подконтрольная	Модель часто скрыта или ограничена платформой
Гибкость	Генерация кода /функциональности/ для CRUD-приложений. Неограниченная кастомизация для сложной бизнес-логики	Ограничена готовыми блоками, коих может быть великое множество
Отладка и тестирование	Полный цикл тестирования: unit, автоматизированное, автоматическое, ручное, нагрузочное. Обязательный прогон по базе регрессионных тестов.	Ручное и нагрузочное тестирование. Остальные варианты либо затруднены, либо невозможны (комментарии разработчиков low-code систем).

Актуальность подхода LeanDI-Core при разработке медицинских информационных систем и КИИ

Особую значимость описанные преимущества методологии LeanDI-Core приобретают при разработке информационных систем, подпадающих под регулирование как критической информационной инфраструктуры (КИИ), так и в частности — медицинских информационных систем (МИС).

Государственный курс на цифровую трансформацию устанавливает для таких систем строжайшие стандарты к доступности (более 99.9%), скорости обработки (транзакции менее 50 мс) и сохранности данных (149-ФЗ, 152-ФЗ, отраслевые нормативы). Недопустимость простоев в работе МИС, необходимость обеспечения полноты, целостности и непротиворечивости медицинских данных выводят на первый план требования контроля, надежности и управляемости на всех этапах жизненного цикла системы.

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

• Скрытая модель данных и отсутствие полного контроля над транзакциями ставят под угрозу выполнение требований по сохранности и целостности данных.
• Иллюзия отказоустойчивости. Подход, базирующийся на бесконечных перезапусках контейнеров, не может гарантировать стабильность работы, требуемой для критических систем.
• Увеличение ТСО. Ограниченные возможности по кастомизации приводят к уникальной заказной разработке в попытках разорвать ограничения.
• Отсутствие быстрой адаптации. Медицинские workflow уникальны и часто не поддаются формализации в терминах bpm-notation, что ставит под сомнение уместность применения bpm-движков при разработке МИС.

Методология и framework LeanDI-Core изначально базируются на принципах, позволяющих обеспечивать строгое выполнение требований регуляторов:

Сквозное проектирование от данных, основанное на шестой нормальной форме (6NF с допущениями LeanDI) и якорном моделировании. Это гарантирует непротиворечивость, версионность, атомарность и консистентность данных на уровне модели, что критически важно для достоверности медицинских сведений.

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

Экономичная, но настоящая отказоустойчивость. Технология «LeanDI-application cluster» реализует на уровне приложения отказоустойчивый кластер, обеспечивая доступность свыше 99.99% за счет избыточности данных и мгновенного переключения при сбоях, без привязки к дорогостоящим проприетарным кластерным решениям на уровне СУБД.

Опыт внедрения решений на LeanDI-Core в здравоохранении (например, прикладной пакет «jMR/jPP» и разрабатываемая РМИАЦ МЗ РТ аналитическая система электронного здравоохранения в Республике Татарстан) подтверждает, что система продолжает работу в штатном режиме даже в условиях потери связи с отдельными узлами или «облачными» ресурсами, что является частой «болевой точкой» многих современных МИС.