Фреймворк трансформации бизнес-вопроса в Low-code решение
Алексей Трефилов, CEO ELMA Global о том, как запрос от бизнеса трансформируется в решения, как разные команды уживаются вместе, какие задачи там находятся, и как в этом участвует Low-code.
Алексей Трефилов, CEO ELMA Global |
Если посмотреть на то, как себя сегодня позиционируют разного рода ИТ-компании, то очень часто можно увидеть модное словосочетания Low-code платформа. Почему бизнес начинает склоняться к выбору данных решений? Почему провайдеры софта выносят концепт на передний план?
Low-code — первый инструмент, который смог объединить разработчиков и конечных пользователей систем. Фактически, это единый язык, на котором могут разговаривать и бизнес-, и ИТ-департаменты. Отсюда вытекает и следующий ответ на поставленные вопросы: трансформация бизнес-запроса в конечный продукт — ИТ-решение, теперь происходит быстрее и гибче, а само Low-code решение остается «живым» и способным на дальнейшее развитие и масштабирование.
На основании 15-летнего опыта мы сложили грамматику языка Low-code в правила — систему и фреймворк воплощения изменений. Мы сформулировали, как запрос от бизнеса трансформируется в решения, как формируются команды разработки, как внутри распределяются задачи, и как это все максимально эффективно функционирует вместе.
На рисунке ниже я собрал диаграмму, которая отображает, как должен обрабатываться запрос. Любой поступающий запрос проходит ассессмент на уровне бизнеса. Проверяется, как он согласуется со стратегией, в какие сроки нужна реализация, какие реальные потребности он закрывает.
Затем собираются технические критерии, которые позволят принять решение. Они складываются в большую таблицу для скоринга, где будут рассматриваться, например, тип запроса, необходимость интеграции с другими системами, требования к интерфейсам, нагрузке и другие данные.
Следующий этап: принятие решения, для этого мы в ELMA подключаем к вопросу Центр компетенции Low-code, команды разработчиков и архитекторов. Если запрос проходит верификацию всеми командами и проходит по критериям скоринг-таблицы, то он попадает дальше в разработку Low-code. Может быть принято решение собрать продукт с нуля или же использовать и кастомизировать уже готовый.
Если принято решение, что все-таки берем решение в разработку Low-code, то необходимо определиться с командой: будут делать решение партнеры, либо же мы сами. При этом не обязательно делать все самостоятельно и увеличивать команду, но что точно не рекомендуется — это отдавать полностью разработку третьей стороне, потому что Центр компетенций — экспертиза хотя бы в лице одного человека, должен всегда оставаться в контуре вендора. Он сможет здраво формировать запросы, не изобретать велосипеды и не идти против политики конкретных продуктов.
Последний этап — итеративная разработка. Правильная разработка должна идти в три потока.
- Первый поток — это no-code разработка силами Low-code разработчиков. Они работают преимущественно в конструкторах бизнес-процессов и интерфейсов, не программируют, могут дополнять функционал скриптами.
- Второй поток — доработки конструктора. Подключается команда разработки, которая создает новые блоки для работы Low-code разработчиков.
- Третий поток — глубокая кастомизация. Работы выполняют Dev-команды, которые совсем не работают с конструкторами, они создают микросервисы и расширяют функциональность самой платформы.
На этапе приемки происходит и отладка процессов. Так как работает 3 потока различных команд, где есть не только технические специалисты, необходимо нивелировать потенциальные риски от специалистов без технического бэкграунда, которые могут не оптимально использовать продукт. Здесь подключается команда Dev, которая средствами отладчиков проводит тестирования.
Важный момент, который не всегда учитывают при разработке на Low-code платформе и который не реализуется Low-code специалистами, потому что вне зоны их компетенций, — развертывание решения. Для этого ELMA365 в 2023 году был создан набор инструментов. Например, силами DevTeam можно построить полноценный CI/CD в системе, сделать интеграцию с GitLab, разбирать пакеты передачи данных, что позволяет настроить и автотестирование и code review. Помимо прочего создан и инструмент масштабирования — BPM/ECM HUB, который, по сути, дает возможность разрезать систему на отдельные подсистемы. А также есть инструменты диагностики для обеспечения быстродействия или передаче на третью сторону.
Таким образом, можно подытожить, что важно правильно следовать грамматике языка, разрабатывать в несколько потоков в соответствии с компетенциями, которые есть у команд, использовать сильные стороны и не использовать слабые.
Не нужно забывать, что каждая команда делает свое дело. Параллельно происходит как No-code разработка, так и классическая.
Обхождение недостатков Low-code в ELMA365
Поговорим о классических недостатках, которые приписывают Low-code: ограниченная кастомизируемость, возникающие сложности при масштабировании и высоких нагрузках, ограничения в техническом росте команд, слабая архитектура, если решение собрано не техническими специалистами. Также в недостатки выносят и вопросы безопасности, узкий рынок узкопрофильных специалистов и vendor lock-in — бизнес-модель, когда создается намеренная зависимость потребителя от продуктов и услуг одного поставщика.
ELMA365 — не просто Low-code, это платформа для автоматизации, и мы во многом обходим ограничения на уровне платформы. Проектируя решения, важно полностью понимать возможности платформы и не ходить в зону слабости Low-code.
Мы понимаем важность кастомизации. В ближайшее время мы представим продукт SystELMA, это набор инструментов для брендирования продукта. SystELMA позволяет делать максимум возможностей по графической адаптации без программирования.
Что касается масштабирования, то в крупных проектах мы стараемся сейчас отходить от создания конфигурационных монолитов, но при помощи ELMA HUB мы можем рассекать конфигурацию на несколько независимых потоков, будь то холдинговая структура или отраслевое направление. Это позволяет управлять и нагрузкой, и отказоустойчивостью.
Также часто Low-code упрекает в ограниченном техническом росте команды разработки. Кто знаком с ELMA365 немного лучше, знают, что здесь есть возможности кастомизации глубокие не только на уровне Low-code, а на уровне самой платформы. И мы позволяем самостоятельно разрабатывать микросервисы фактически на любом языке. Здесь программист может создавать в той среде, в которой ему удобно, и расширять возможности уже платформы, а не конфигурации, и таким образом мы уже получаем все красивое и аккуратное.
Большое внимание сейчас уделяется тому, чтобы обеспечить качественную CI/CD доставку результата. Можно строить конвейеры доставки результата, для этого мы используем системы контроля версий вроде того же GitLab. И сейчас мы готовы зарелизить продукт, с помощью которого появится возможность настроить CI/CD внутри системы, то есть не нужно будет разворачивать конфигурацию. Сравнивать конфигурации, смотреть изменения в дереве, которое позволяет полностью визуализировать конфигурацию, что и куда выгружается, какие изменения будут. Также это может работать на версиях системы, которая имеет разные версии и настроить миграцию.
Что же касается вопросов безопасности и Vendor Lock. Здесь я не скажу, что есть какое-то супер волшебство по Vendor Lock. В любом случае придется довериться какому-то продукту. Глупо бояться всего на свете, вы все равно зависите от партнеров. И тут встает вопрос, на каких партнеров ставить. Потому что, наверное, лучше поставить на партнера, который больше 10 лет на рынке, выпускает регулярно релизы, и где решение построено на безопасных технологиях, находится в реестрах.
Сегодня появляется много новых продуктов, и может у них есть классные идеи, но есть ли у них инфраструктура, будут ли они существовать через 2-3 года? Это и есть риск.
По поводу ограниченного контингента исполнителей. На сегодняшний день мы являемся одним из таких самых громких имен в Российском IT. У нас более 200 партнеров, все крупные интеграторы работают с ELMA. С партнерами мы сотрудничаем, выдаем сертификаты. Поэтому я думаю, что найти исполнителя сегодня для формирования экспертизы совершенно не сложно в контексте внедрения ELMA365.
Еще раз хочу подчеркнуть, что ELMA365 — не просто Low-code платформа. На карте продуктов от Gartner, где представлено то, как в целом выглядит рынок, так получилось, что ELMA365 закрывает практически все группы продуктов одной системой.
И если еще раз вспомнить треугольник принятия решения, то ELMA365 включает в себя и некоторые коробочные решения, потому что кроме Low-code и платформы есть огромное количество готовых подпродуктов: CRM, документооборот, есть огромное количество конфигураций. По сути ELMA365 — это система, которая в том числе помогает «добежать последнюю милю» — имеет в экосистеме готовые решения, а не просто голую платформу.
Структура команды на проектах внедрения Low-code
Я уже говорил, что команде нужно подстроиться, нужно измениться, чтобы разговаривать на языке Low-code. Команда также подвергается значительной трансформации, чтобы соответствовать концепту, языку.
Уже довольно давно инновации — это ИТ. Сегодня получилось так, что ИТ и бизнес — это одно целое хотя бы на уровне мышления, того, как это должно реализовываться.
Но это не значит, что нам больше не нужны программисты или программисты сами создадут решения. Нужен симбиоз команд и необходим грамотный процесс, который организует раскрытие сильных сторон продуктов и нивелирует слабые стороны. Поэтому очень важно работать с командой, структурой и процессами.
Подведу итог
Low-code — это язык инноваций, он является способом восприятия мира и ответом, который позволяет очень быстро достичь результата в создании нового ИТ-продукта. При этом нужно следовать неким правилам языка, не использовать инструмент как придется, а придерживаться правильного фреймворка, чтобы все получилось.
Переходите на сайт, чтобы узнать больше об экосистеме Low-code продуктов ELMA365 и оформить демодоступ на 14 дней.