Правда ли, что low-code нельзя применять в enterprise-решениях

разбираемся с основными возражениями

2.4.2021

Содержание

Сегодня мы разберём основные возражения по использованию low-code систем у бизнеса масштаба enterprise и выясним, насколько они справедливы.

  • Немного о парадигме low-code
  • Возражение № 1. «Наши процессы слишком специфичны»
  • Возражение № 2. «Лицензии на low-code системы дорого стоят»
  • Возражение № 3. «Всё в облаке, это небезопасно»
  • Возражение № 4. «Концепция low-code не предназначена для highload-проектов»
  • Для каких проектов не подходит low-code
  • Привет. Я Андрей Путин, управляющий партнёр ИТ-интегратора kt.team. В последнее время мы всё чаще предлагаем своим крупным клиентам использовать в ИТ-архитектуре low-code решения. Их функционал позволяет быстро вносить изменения в интеграции и бизнес-процессы. Это критично для бизнеса, учитывая динамику изменений на рынке.

    Forbes называет low-code трендом в первых строчках, в пользу использования low-code говорит статистика IDC, а низкая скорость изменений при традиционной разработке несёт угрозу бизнесу. Но несмотря на всё это, бизнес масштаба enterprise с осторожностью и даже недоверием относится к парадигме low-code. По мнению его представителей, прикладную разработку для крупных компаний можно осуществлять или на коробочных решениях, или с нуля. А инструментарий low-code «не соответствует масштабам задач enterprise и не обеспечивает достаточного уровня защиты коммерческой информации».

    Сегодня мы разберём основные возражения по использованию low-code систем у бизнеса масштаба enterprise и выясним, насколько они справедливы.

    Немного о парадигме low-code

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

    В традиционной парадигме code-first разработкой функционала и всеми правками занимается разработчик. Проигрывают при этом все. Разработчики — потому что по мере роста проекта они всё больше занимаются минорными правками и всё меньше — переиспользуемым кодом. Бизнес — потому что вынужден ждать изменения. Нам известны случаи, когда разработчики заняты минорными доработками, а в листе ожидания компании тем временем накапливается по 50 и более проектов.

    rus: Немного о парадигме low-code | Блог kt.team

    В концепции low-code разработчик создаёт не конечную ценность, а конструктор для её сборки. Собирать или переконфигурировать ценность в конструкторе быстрее и проще: этим могут заниматься не только разработчики, но и бизнес-аналитики или конечные пользователи с навыками разработки (те, кого Gartner называет citizen developers). Более того, для некоторых задач такие конструкторы уже есть: например, бессмысленно делать конструктор интеграций или API, когда существуют Talend, Mule, WSO2.

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

    Концепция low-code известна с 90-х годов, но сейчас она стала особенно актуальной, поскольку позволяет сократить период time to market, ускорить разработку новых бизнес-процессов и внесение изменений в уже существующие.

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

    Отсюда появляется первое возражение enterprise-бизнеса.

    Возражение № 1. «Наши процессы слишком специфичны»

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

    На деле же code-first ограничивает возможности реализации специфичных процессов сильнее, чем low-code.

    Если вы выбираете парадигму code-first, то работаете с некой коробкой или разрабатываете эту коробку. Она насыщена определёнными сущностями, функционалом, терминами.

    rus: Возражение № 1. «Наши процессы слишком специфичны» | Блог kt.team

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

    Ответственность за результат размоется. На претензию: «Почему вы сделали неудобно?» — разработчики будут отвечать: «Почему вы так плохо описали требования?» Разработчики утонут в change-реквестах, бизнес будет игнорировать часть требований. Команда разработки станет «бутылочным горлышком» всех изменений — следовательно, по теории ограничений вам придётся строить другие процессы с учётом этого.

    Частью функционала коробки вы не будете пользоваться, ещё часть будет подходить вам при адаптации бизнес-процессов под коробку.

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

    Да, можно возразить, что в таких продуктах — «лучшие практики». Однако эти практики могут не соответствовать текущей культуре компании, и в результате «лучшие практики» превратятся в карго-культ.

    Сравните это с работой в парадигме low-code. Low-code решения не предлагают «лучшие практики»: при помощи конструктора вы проектируете решение, которое максимально соответствует особенностям вашего бизнеса.

    При этом разработчики не сосредоточены на бесконечных минорных правках. Они занимаются новым функционалом и новыми элементами конструкторов, исследуют инженерные подходы. Разработка с каждым днём делает конструктор всё более разнообразным и удобным для бизнеса.

    Что же касается «лучших практик», то многие low-code решения имеют уже сконструированные приложения, например CRM или готовые интеграции. Но при этом готовые решения практически никогда не являются фиксированной системной особенностью — всё можно поменять. Уходят в прошлое возражения про системные атрибуты и сложность переопределения части коробки.

    Возражение № 2. «Лицензии на low-code системы дорого стоят»

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

    А часть решений действительно являются SaaS и оплачиваются по пользователям. Давайте разберём именно этот кейс.

    1. Разное восприятие расходов на лицензии и разработку мешает объективно сравнивать их.

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

    2. Лицензии дешевле, чем разработка с нуля.

    Покупая лицензию на любой продукт — неважно, является ли он low-code, — вы платите за готовый продукт, с помощью которого будете решать задачи. Как правило, стоимость лицензии ниже, чем у проекта по созданию самописного продукта с аналогичным наполнением и функционалом. А в случае с low-code решениями риск несоответствия функционала задачам неактуален: функциональность конструктора оценить проще, чем узнать все нюансы уже готового функционала.

    3. У лицензий простая экономика без фактора неопределённости.

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

    4. В low-code вы покупаете не только инструменты визуальной разработки, но и лучшие практики конструирования процессов.

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

    Например, low-code ESB-системы задают некоторые паттерны проектирования интеграций в части логирования, мышления терминами «поток»/«линия» и т. д. Low-code бизнес-процессы задают стандарты проектирования процессов. Разрабатывая аналогичный бизнес-процесс своими силами, вы, скорее всего, придёте к таким же практикам, но не сразу. Вспомните, например, часто ли ваши менеджеры пользуются BPMN при согласовании процессов? А использование LCAP позволяет сократить путь поиска оптимального решения в разы.

    Возражение № 3. «Всё в облаке, это небезопасно»

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

    На это возражение есть несколько ответов.

    rus: Возражение № 3. «Всё в облаке, это небезопасно» | Блог kt.team

    Во-первых, не все low-code системы обязательно разворачивать именно в облаке. Поставщики этих решений предоставляют заказчику выбор: облачное решение или решение внутри вашей экосистемы, а часть решений даже имеют открытый исходный код (Strapi, Pimcore, Corteza, Builder). Обычно лицензия для разворачивания на серверах в контуре компании стоит дороже, но такая возможность всё же есть.

    Во-вторых, даже облачные решения потенциально можно разместить на приватных облаках. Такую опцию, например, предлагает Power BI из экосистемы Microsoft: «ваш» Power BI может быть размещён на выделенных серверах платформы Azure, в отдельной части дата-центра.

    У e-Commerce low-code также есть планы, согласно которым они могут предоставлять клиентам приватные облака.

    Если же вы сами решили перестроить in-house разработку в low-code парадигму, то с точки зрения безопасности у вас и вовсе ничего не меняется.

    Возражение № 4. «Концепция low-code не предназначена для highload-проектов»

    Как раз напротив: многие low-code системы по умолчанию предназначены для работы с highload. Обработка тысяч запросов в секунду для них не является критичной. К таким решениям относятся, например, Talend, Honeycode, Creatio, Strapi, Pimcore.

    rus: Возражение № 4. «Концепция low-code не предназначена для highload-проектов» | Блог kt.team

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

    Один нюанс: не всегда у бизнеса есть корректное представление о том, что такое highload. Он обращается к ИТ-подрядчику с запросом на высоконагруженный проект, но на практике оказывается, что речь идёт о крупном подразделении с серьёзным оборотом. Например, B2B-портал, который обслуживает 3000 клиентов в день, или B2C интернет-магазин с миллионом посетителей в месяц даже не приближается к тому, что принято считать highload. Тут нет десятков тысяч одновременных сложных транзакций на запись и, скорее всего, в ближайшей перспективе не будет.

    Пока ваш проект не подошёл к условной границе в 5000 транзакций в секунду, рано беспокоиться о том, поддерживают ли выбранные системы highload. Лучше сконцентрироваться на других вопросах и бизнес-целях.

    Но даже если у вас действительно highload-проект, это не исключает возможности применения low-code. Мы знаем достаточно крупные экосистемы, которые построены из небольших «кусочков». Например, у «Тинькофф» есть множество отдельных BPMS (Camunda), каждая из систем работает со своим набором бизнес-процессов. Это сделано не столько потому, что выбранное решение «не потянет» highload, сколько для лучшего контроля и отказоустойчивости.

    Для каких проектов не подходит low-code

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

    Однако есть ситуации, когда сама концепция low-code может не подходить бизнесу.

    1. Если вы готовы подстраиваться под существующую коробку. В этот пункт обычно попадают второстепенные бизнес-процессы и любые «пассивы». Например, какая разница, как гибко у нас начисляется зарплата или конфигурируется СКУД, если у этой гибкости нет никакого мультипликатора для бизнеса?

    2. Разработку принципиально новых (инновационных) технологических решений в ряде случаев нельзя реализовывать в философии low-code. Важно понимать, что здесь идёт речь именно о технологических инновациях, а не инновациях в области бизнес-моделей.

    3. Если вы ИТ-команда и вам сложно переучивать сотрудников на новый уровень абстракции, а дальнейшее сопровождение и внесение изменений в проект не подразумеваются.

    4. Если у вас нет времени на перестройку (проект нужно запустить «вчера») или вы сталкиваетесь с огромным наследием старого кода.

    5. Если у вас нет выбора. Например, вы часть корпорации, а набор технологий задан сверху. Так, много штаб-квартир используют Magento как стандарт e-Commerce, и региональные офисы тоже вынуждены использовать Magento.

    6. Если вы хотите сохранить статус-кво и любые изменения парадигмы идут вразрез с вашими целями.

    Другие статьи

    Смотреть все

    Как B2B-портал избавляет маркетинг и менеджмент от головных болей: 9 примеров

    Подробнее

    Введение в MDM- и PIM-системы на примере Akeneo и Pimcore

    Подробнее

    Сколько по времени занимает внедрение ESB, каковы выходы на каждом этапе?

    Подробнее

    Смотреть все

    Мы используем файлы cookie, чтобы предоставить наилучшие возможности сайта

    Ок

    Ваша заявка отправлена успешно

    Отправить снова

    Давайте обсудим ваш проект

    С вами свяжутся персональные менеджеры

    Форма для связи

    Что-то пошло не так! Пожалуйста, попробуйте еще раз.
    Ваша заявка отправлена успешно!

    Отправить снова

    Что-то пошло не так! Пожалуйста, попробуйте еще раз.

    Контакты

    +7 917 125-96-34

    Whats App:

    @kt_team_it

    Telegram:

    +7 495 204-14-33

    Телефон:

    Назначить встречу

    Забронировать время встречи с помощью Google Calendar