Привет. Я Андрей Путин, управляющий партнер ИТ-интегратора kt.team. В последнее время мы все чаще предлагаем нашим крупным клиентам использование low-code решений в их ИТ-архитектуре.
Их функционал позволяет быстро вносить изменения в интеграции и бизнес-процессы.
Это критично для бизнеса, учитывая динамику изменений на рынке.
Forbes называет low-code тенденцией в первых строках он говорит в пользу использования low-code Статистика IDC , а низкие темпы изменений в традиционном развитии представляют угрозу для бизнеса.
Но, несмотря на все это, предприятия масштаба предприятия относятся к парадигме low-code с осторожностью и даже недоверием.
По словам ее представителей, разработка приложений для крупных компаний может осуществляться как с использованием пакетных решений, так и с нуля.
А low-code инструменты «не соответствуют масштабу задач предприятия и не обеспечивают достаточный уровень защиты коммерческой информации».
Сегодня мы разберем основные возражения против использования low-code систем для бизнеса масштаба предприятия и выясним, насколько они справедливы.
Немного о парадигме low-code
Бизнес регулярно требует некоторых изменений.Иногда незначительные, например, добавление атрибута или перемещение кнопки, а иногда и более существенные, требующие разработки чего-то принципиально нового.
В традиционной парадигме «код прежде всего» разработчик несет ответственность за разработку функциональности и внесение всех изменений.
В этом случае проигрывают все.
Разработчики — потому что по мере роста проекта они все больше занимаются мелкими правками и все меньше — повторным использованием кода.
Бизнес – потому что вынужден ждать перемен.
Мы знаем случаи, когда разработчики заняты мелкими доработками, а в листе ожидания компании тем временем накапливается 50 и более проектов.
В концепции low-code разработчик создает не конечное значение, а конструктор для его сборки.
Собирать или переконфигурировать значение в конструкторе происходит быстрее и проще: это могут делать не только разработчики, но и бизнес-аналитики или конечные пользователи с навыками разработки (те, кого Gartner называет гражданскими разработчиками).
Более того, для некоторых задач такие конструкторы уже существуют: например, нет смысла создавать интеграционный или API-конструктор, когда существуют Talend, Mule, WSO2. 
Каждая low-code система ориентирована на решение определенных конкретных задач: моделирование и выполнение бизнес-процессов, моделирование данных, проектирование и разработка интеграций, игровое моделирование, проектирование интерфейсов и т.д. Концепция low-code известна еще с 90-х годов, но сейчас она стала особенно актуальной, поскольку позволяет сократить время выхода на рынок, ускорить разработку новых бизнес-процессов и внесение изменений в существующие.
В low-code необходимость корректировки бизнес-требований разработчиками минимальна.
Они необходимы для реализации новых элементов конструктора и настройки первичного значения для проверки правильности элементов конструктора.
Вот здесь и появляется первое возражение предпринимательского бизнеса.
Возражение №1: «Наши процессы слишком специфичны».
Нет двух одинаковых компаний.
Одни и те же бизнес-процессы даже для компаний одного сегмента могут быть построены с использованием разной логики.
Поэтому нам легко понять опасения владельца продукта, что low-code-конструктора будет недостаточно для нужного ему функционала.
Фактически, принцип «сначала код» ограничивает возможность реализации конкретных процессов больше, чем «low-code».
Давайте представим, что вы выбираете парадигму code-first и работаете с определенной коробкой или разрабатываете эту коробку.
Он полон определенных сущностей, функций и терминов.
Чем мощнее этот стартовый функционал коробки, тем сложнее будет внести изменения в систему.
Чем больше изменений вы внесете, тем меньше людей в принципе будут понимать, что и как работает: сложность вносимых изменений будет возрастать, и неважно, будет ли ваша архитектура микросервисной или монолитно-модульной.
Ответственность за результат размывается.
На жалобу: «Почему вы сделали неудобноЭ» — разработчики ответят: «Почему вы так плохо описали требованияЭ» Разработчики утонут в запросах на изменения, бизнес проигнорирует некоторые требования.
Команда разработчиков станет узким местом всех изменений — поэтому, согласно теории ограничений, вам придется строить другие процессы с учетом этого.
Вы не будете использовать часть функционала коробки; другая часть подойдет вам при адаптации бизнес-процессов под коробку.
В результате появятся новые термины, не характерные для вашего бизнеса, в некоторых случаях интерфейсы управления окажутся слишком сложными, а в некоторых случаях придется мириться с некоторыми нюансами.
Да, вы можете возразить, что в таких продуктах есть «лучшие практики».
Однако эти практики могут не соответствовать нынешней корпоративной культуре, и в результате «лучшие практики» превратятся в карго-культ. Сравните это с работой в парадигме 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 вы покупаете не только инструменты визуальной разработки, но и лучшие практики проектирования процессов.
Никто не может знать, как удобнее выстроить бизнес-процесс в вашей организации.
Но в то же время существуют практики реализации стандартных действий, которые помогут вам за меньшее количество итераций построить более прозрачный и управляемый процесс.
Например, системы ESB с низким кодом устанавливают некоторые шаблоны проектирования интеграции с точки зрения ведения журналов, мышления в терминах «потока» / «линии» и т. д. Бизнес-процессы с низким кодом устанавливают стандарты для проектирования процессов.
Разработав подобный бизнес-процесс самостоятельно, вы, скорее всего, придете к тем же практикам, но не сразу.
Например, как часто ваши менеджеры используют BPMN при координации процессов? А использование LCAP позволяет сократить путь к поиску оптимального решения в несколько раз.
Возражение №3: «Все находится в облаке, это небезопасно».
С этим возражением мы сталкиваемся довольно часто.
Бизнес обеспокоен тем, что low-code решение хранится «где-то в облаке, на чьих-то серверах, мы его не контролируем».
На это возражение есть несколько ответов.
Во-первых, не все системы low-code необходимо развертывать в облаке.
Поставщики этих решений предоставляют клиенту выбор: облачное решение или решение внутри вашей экосистемы, а некоторые из решений даже имеют открытый исходный код (Strapi, Pimcore, Corteza, Builder).
Обычно лицензия на развертывание на серверах внутри компании обходится дороже, но такой вариант все же существует. Во-вторых, даже облачные решения потенциально могут размещаться в частных облаках.
Такой вариант, например, предлагает Power BI из экосистемы Microsoft: «ваш» Power BI может размещаться на выделенных серверах платформы Azure, в отдельной части дата-центра.
У электронной коммерции с низким кодом также есть планы по предоставлению клиентам частных облаков.
Если вы сами решите перестроить собственную разработку на парадигму low-code, то с точки зрения безопасности вообще ничего не изменится.
Возражение №4. «Концепция low-code не предназначена для высоконагруженных проектов»
Совсем наоборот: многие low-code системы по умолчанию рассчитаны на работу с highload. Обработка тысяч запросов в секунду для них не критична.К таким решениям относятся, например, Talend, Honeycode, Creatio, Strapi, Pimcore. Мы замечаем обратное: зачастую эксклюзивная разработка, теоретически рассчитанная на высокие нагрузки, имеет огромное количество наследства, рефакторить которое сложно и дорого.
Напротив, многие проектировщики low-code отлаживают скорость компонентов снова и снова.
Здесь необходимо оговориться, что low-code позволяет избавиться от многих технических проблем, но ни концепция low-code, ни парадигма code-first не свободны от ошибок в проектировании информационных моделей, бизнес-процессов и прочего, что также влияют на конечную производительность.
Один нюанс: бизнес не всегда имеет правильное представление о том, что такое highload. Он обращается к ИТ-подрядчику с запросом на высоконагруженный проект, но на практике оказывается, что речь идет о большом отделе с серьезной текучкой кадров.
Например, B2B-портал, который обслуживает 3000 клиентов в день, или B2C-интернет-магазин с миллионом посетителей в месяц даже близко не приближается к тому, что считается высокой нагрузкой.
Десятков тысяч одновременных сложных транзакций записи нет и, скорее всего, не будет в ближайшем будущем.
Пока ваш проект не достигнет условного предела в 5000 транзакций в секунду, волноваться о том, поддерживают ли выбранные системы высокую нагрузку, рано.
Лучше сконцентрироваться на других вопросах и бизнес-целях.
Но даже если у вас действительно высоконагруженный проект, это не исключает возможности использования low-code. Мы знаем довольно крупные экосистемы, которые строятся из маленьких «кусочков».
Например, у Тинькофф много отдельных BPMS (Camunda), каждая из систем работает со своим набором бизнес-процессов.
Это сделано не столько потому, что выбранное решение не справится с высокой нагрузкой, сколько для лучшего контроля и отказоустойчивости.
Для каких проектов low-code не подходит?
Концепция low-code достаточно универсальна.Да, для выбора конкретного решения нужно изучить его возможности и аналоги, но в этом плане low-code ничем не отличается от других концепций.
Однако бывают ситуации, когда сама концепция low-code может не подойти для бизнеса.
- Если Готовы ли вы адаптироваться к существующей коробке? .
Этот пункт обычно включает в себя второстепенные бизнес-процессы и любые «обязательства».
Например, какая разница, насколько гибко мы рассчитываем зарплату или настраиваем СКУД, если эта гибкость не имеет никакого бизнес-мультипликатора?
- Разработка принципиально новых (инновационных) технологических решений в некоторых случаях это невозможно реализовать в рамках философии low-code. Важно понимать, что речь идет именно о технологических инновациях, а не инновациях в сфере бизнес-моделей.
- Если вы ИТ-команда и вы сложно переобучить сотрудников на новый уровень абстракции , и дальнейшая поддержка и изменения проекта не подразумеваются.
- Если у вас есть нет времени восстанавливать (проект нужно запустить «вчера») или вы столкнулись с огромным наследием старого кода.
- Если у вас есть нет выбора.
Например, вы являетесь частью корпорации, а набор технологий указан сверху.
.Так, многие штаб-квартиры используют Magento в качестве стандарта электронной коммерции, а региональные офисы также вынуждены использовать Magento.
- Если вы хочу сохранить статус-кво и любые изменения парадигмы идут вразрез с вашими целями.
-
Как Конвертировать Мтс В Avi На Mac
19 Oct, 24 -
Crispr-Cas9 Впервые Протестирован На Людях
19 Oct, 24 -
Разработка Многоканальных Sdr
19 Oct, 24 -
Запуск Visual Studio 2010 В России
19 Oct, 24 -
Sql Server 2008 Частично Реализует Winfs.
19 Oct, 24
