Что такое low-code/no-code платформа и CRM, CRM+, ERP
Суть low-code/no-code (далее просто low-code) в том, чтобы снизить порог создания/изменения информационной системы до уровня бизнес аналитика или даже продвинутого пользователя. Это когда вендор не просто создаёт платформу со встроенным языком и его сотрудники заявляют о том, что сделают для клиента «всё или почти всё» — low-code платформа, это когда бизнес-аналитики или выделенные ответственные на стороне клиента (его сотрудники) могут это «почти всё» сделать сами.
Что входит в понятие на платформе можно «почти всё»?
Ключевые сотрудники – это «носители/владельцы знаний о процессах компании». Именно предоставление в их руки инструмента, позволяющего! полностью! создавать/изменять информационную систему предприятия, приводит к:
1. Формат данных, пользовательские данные
Платформа должна иметь средства конфигурирования данных. Причем без программирования. И конфигурированию должны быть доступны не только «пользовательские данные», но и справочники и реестры, представляющие основу конфигурации + системные – к примеру, контрагенты, физ. лица и пр. Или наоборот: есть вендоры, которые дают возможность конфигурирования ограниченного количества видов данных + создавать свои справочники – это неправильно. Ограничения — это компромисс за деньги клиента.
Все данные должны иметь, условно говоря, равные права, отображаться в виде дерева (потому что есть дочерние реестры/справочники) и бизнес-аналитик покупателя платформы должен иметь возможность без ограничений этими данными управлять.
В текущий момент развития рынка ИТ в РФ много компаний – поставщиков CRM научились добавлять свои справочники. Просто добавления с компромиссом недостаточно, чтобы называться полноценной платформой.
Основные моменты
a) Визуализация данных перед конечным пользователем.
Работая с фильтрами, отчетами, шаблонами и пр. пользователь должен видеть данные в удобном виде, с названиями, которые ему понятны. Данные должны быть видны не только по таблице запроса, но и по связанным таблицам (прямым и обратным ссылкам). Пользователь должен иметь возможность при фильтрации, выборке, построении отчетов, запросов условно говоря «проваливаться» вглубь связанных данных на любой уровень.
При этом система должна сама брать на себя функции преобразования конечного запроса в SQL. Система должна быть построена таким образом, что пользователь может «дотянуться» до всех данных, включая системные и «экзотические», как, например логи. Это позволяет получать отчетность по всей интересующей информации и в визуализированном виде это легко и удобно.
2. Вычисления
Платформа, которая позволяет внедренцу (бизнес-аналитику) управлять нагрузкой на сервер базы данных должна делить вычисления на разные виды по нагрузке.
В low-code платформе бизнес-аналитик должен иметь функционал, который позволяет ему используя, как пример, приведенное выше дерево атрибутов, составить алгоритм вычисления на понятном доступном языке и понятных и доступных названиях атрибутов, реестров и пр.
b) При этом, здесь же допускается код на T-SQL.
Код на T-SQL снимает ограничения по сложности вычислений, делая платформу более широкой, чем «для бизнес-аналитика». По сути это снова «отсутствие ограничений». Low-code платформа не должна быть средством только для бизнес-аналитиков – она должна закрывать потребности разработки на платформе готового решения, включая код на встренном языке и, к примеру, T-SQL. Но бизнес-аналитик на low-code платформе должен иметь возможность закрыть бОльшую часть типовых задач.
Система должна позволять бизнес-аналитику создавать расчет итогов и ключевых показателей, необходимых для формирования дашбордов, информирования пользователей о количестве задач (пример) и пр. Т.е. формировать общекорпоративные, не привязанные к конкретным записям вычисления. Также важно (ниже будет рассмотрено) эти итоговые показатели отображать в интерфейсе (в визуализации) в виде индикаторов, крупных цифр и пр.
По сути «представления» – это некий «табличный конструктор». Его доступность бизнес-аналитикам или продвинутым пользователям позволяет собирать таблицы из нескольких таблиц, т.е. создавать представления, которые не хранятся в БД. Представления и их разработка очень важны в анализе и сопоставлении данных, в т.ч. маркетологами. В концепции low-code это означает, что сложные конструкции, которые обычно длительный срок собираются программистами, теперь бизнес-аналитиками могут создаваться «мышкой» в короткие сроки, к тому же и быстро меняться.
e) Агрегаты (регистры)
Существует большое количество вычислений по расписанию (ночью), а также подготовка итогов и расчетов для сложных отчетных форм, также требующих большой нагрузки сервера и которые имеет смысл также проводить ночью. Отчеты этого типа не требуют on-line актуализации данных. С точки зрения пользователя агрегирование – это подготовка готовых отчетов с уже готовыми результатами, чтобы запрос такого отчета не приводил к вычислениям, а выдавал уже готовую форму с результатами в течение 1 – 2 сек.
Промежуточный вывод: low-code проектирование готовой конфигурации с точки зрения данных – это закрытие без программирования силами бизнес-аналитика всех вопросов формата БД для бизнеса любого размера и сложности + обязательная при этом скорость разработки, которая получается очень высокой.
3. Интерфейсы десктоп/web
a) Доступность для дизайна
Одним из главных в дизайне интерфейса является принципиальная доступность этой функции бизнес-аналитику, причем, конечно, без программирования. Это значит, что есть компонентный состав (о нём ниже) и есть «мышка», которой можно расставить на форме всё, как требуется, а свойства, функции и пр. задать, к примеру, в инспекторе объектов или в карточках объектов. Сложность форм в low-code платформе не должна быть ничем ограничена.
Применительно к современным CRM и ERP системам дизайнер интерфейсов должен быть, как для десктопа (если система поставляется в десктопном варианте), так и для web.
b) Нарисовал и оно работает
Работа того, что только что было отрисовано – очень важный аспект. Зачастую, в платформах для того, чтобы отрисованный интерфейс работал, код необходим. Пусть и не большой. Это не low-code платформы, даже, если вендор так пытается её представить.
Система в своих свойствах и сообщениях пользователю о критических событиях должна подразумевать настройку формы в таком виде, что при задании необходимых свойств и связей объектов на ней – всё сразу начинает показывать данные и работать. Никак иначе. Никакого, пусть даже минимального кода.
c) Компонентный состав
Компонентный состав дизайнера интерфейсов должен покрывать все современные задачи визуализации и работу с данными. Кроме стандартного, должно быть:
d) Карточки записей
Каждое подразделение может иметь свои взгляды и требования к карточкам записей. Менеджерам по продажам необходимо видеть карточку клиента по-своему, бухгалтерии по-своему, руководству также по-своему.
В low-code платформах для реализации этой возможности должны быть настройки с копированием карточки из одной группы пользователей в другую, при этом, с созданием в каждой их них уникального внешнего вида. Это должно производиться БЕЗ применения встроенного языка.
e) Выход на встроенный язык
При всём сказанном, встроенный язык лишним не будет. Но это дополнение к возможностям low-code:
Там, где необходимы особенно сложные сценарии и где настроек по какой-то причине не хватает или надо управлять свойствами компонентов, расчетов и пр. в зависимости от действий пользователей и это не может быть положено на графическую карту процессов – пожалуйста, может быть доступен и хорошо, когда доступен встроенный язык, как средство глубокой кастомизации.
4. Отчеты, дашборды, аналитика
5. Шаблоны документов, рассылок, нотификаций
Собственно, как и в дизайнере отчетов, так и в подготовке шаблонов документов на основе MS Word и MS Excel необходима доступная всем и пользователям в т.ч. визуализация данных, описанная выше. Пользователь в платформе low-code не должен знать названия таблиц в БД, полей и пр. Ему должен быть доступен исчерпывающий визуальный инструментарий доступа ко всем данным, без знания SQL.
Здесь же следует отметить, что правильным является предоставление бизнес-аналитику возможности оперировать, как прямыми ссылками на таблицы, так и обратными. Это позволяет вставлять в шаблоны MS Word – к примеру, в договора таблицы спецификации.
6. Управление процессами
На рынке много систем, заявляющих о наличии инструментов управления процессами. Часто под этим понимают, к примеру, последовательную раздачу задач, или ветвление только одного типа (да/нет, что по сути условный переход).
Платформы low-code должны обладать мощными, доступными без программирования графическими редакторами карт процессов, где бизнес-аналитик должен иметь возможности моделирования:
1. Событий в БД и от этого:
7. Управление доступом и логированием
Осуществление наполнением системы штатными интерфейсами и условно «новыми» может и должно быть доступно без программирования. Включая настройки иконок и загрузку их коллекций.
Аналогично доступ и его ограничения.
8. Управление личным кабинетом клиентов и данными на сайте
Аналогично и управление журналом аудита (логирование)
Ввиду роста грамотности пользователей. Ввиду того, что тем, кто программировал на Фортране, скоро на пенсию. Уверен, что именно за системами управления корпоративными сложными системами типа «платформа low-code» будущее.
Речь НЕ идёт о том, что произойдёт отказ от программирования. Как показано выше – везде может и должен быть шлюз/доступ/другой уровень для того, чтобы определенные вопросы реализовывались на встроенных языках и SQL.
Речь о том, что компаниям платформы low-code выгодны по объективным причинам и тренд на, собственно, говоря более простым языком: автоматизацию работы внедренцев/бизнес-аналитиков – на упрощение и ускорение их работы, очевиден.
Имея средства управления форматом данных, вычислениями без программирования, распределения нагрузки на сервер через планирование вычислениями; имея возможности визуализации данных, как с точки зрения рабочего места той или иной группы пользователей + визуализации и аналитичности данных для лиц, принимающих решения; имея возможность настраивать процессы в графическом движке с элементами документообота и раздачей задач – бизнес-аналитик может закрыть собой очень большой объём внедрения информационной системы высокого уровня сложности.
LowCode vs NoCode: в чем разница и когда их нужно использовать
NoCode и LowCode (способы создания продукта без написания кода с нуля) безусловно на одной стороне баррикад — оба экономят вам время и деньги по сравнению с традиционной разработкой. Там, где на обычном коде приложение или платформа будет писаться 3 месяца, на No/Low Code оно соберется за месяц.
Но даже между такими похожими понятиями есть отличия. О них сегодня и поговорим.
А вещает, как обычно, студия NoCode/LowCode-разработки Zero To One.
А еще мы запустили телеграм-канал о новостях из мира бизнеса и стартапов. Каждое утро говорим о главных событиях: кто сколько привлек, кто кого купил и какие стартапы сейчас поднимают самые большие раунды. Подписывайтесь!
NoCode — способ разработки сайтов и приложений без использования кода. Вместо этого продукт собирается как конструктор из уже существующих инструментов. Это помогает не только создавать проект намного быстрее, но и сокращать затраты на разработку в 3-4 раза по сравнению с обычным кодом.
В ситуациях, когда для какой-то из функций не хватает NoCode-инструментов, недостающие опции дописываются обычным кодом. Такой способ создания приложений и сайтов и называется LowCode.
Два этих типа разработки идеально подходят для запуска MVP и тестирования гипотез. Возможность быстро менять продукт, основываясь на обратной связи от пользователей, помогает бизнесу быстрее найти лучшие решения и масштабировать их.
Главное сходство между LowCode и NoCode — возможность создать сайт или мобильное/веб-приложение быстро. Оба этих способа разработки помогают бизнесу не терять время на старте, что критически важно для любого продукта.
Далее идет не менее важный момент — у разработки на No/Low Code куда ниже порог входа, чем у обычного кода. И там, где для создания сайта нужно искать разработчика, владеющего несколькими языками (и потом держать его в штате, чтобы поддерживать работу сервиса), с NoCode/LowCode можно привлечь студию для разработки, а позже контролировать работу продукта самостоятельно или легко найти для этого специалиста, так как достаточно будет просто знания интерфейса инструментов. При этом решение одной и той же задачи на коде может быть разным, отсюда сложность во взаимозаменяемости специалистов. В No/Low Code же все решается правильной работой с сервисом и пониманием как можно большего количества возможностей инструмента.
И LowCode, и NoCode завязаны на работе в основном с интеграциями и визуальной составляющей, а код — на написании всего продукта с нуля, а не только отдельных функций, как у LowCode. Так что здесь имеет смысл сказать о меньшем шансе возникновения ошибок, особенно на старте. Там, где код начнет ломаться на N тысячах посетителей, NoCode инструменты спокойно справятся с ситуацией, так как уже написаны разработчиками и протестированы тысячами клиентов.
Важно: безусловно, NoCode решения подходят не для всех продуктов и не на всех этапах. Например, пока что мало способов реализовать продукт с ИИ на NoCode или обеспечить работу с большими данными, которые потом можно будет перенести, сохранив логику их сбора. Но для первичного запуска продукта на рынок и тестирования гипотез в больших компаниях NoCode — лучшее решение из существующих.
NoCode быстр и удобен, но не очень гибок в плане адаптации под специфичные пользовательские потребности или особенности дизайна. У нас в студии редко случаются ситуации, когда возможностей NoCode не хватает, однако от этого ни один продукт не застрахован — все достаточно индивидуально и зависит от потребностей клиента.
Да, в сборке продукта на сервисах порог входа все еще намного ниже, чем у обычной разработки. Но при этом, если сравнивать LowCode и NoCode — для первого все таки потребуется разработчик. Именно поэтому собрать какой-никакой продукт самостоятельно без глубокого знания программирования можно только в NoCode. Для большего все-таки придется привлекать специалиста.
Если NoCode — история по большей части для MVP, то с LowCode вы запросто сможете собрать продукт, который будет расти вместе с вашим бизнесом.
Low-code платформы поддерживают масштабируемые архитектурные шаблоны: развертывание с помощью контейнерных сервисов, микросервисы, поддержку открытости и расширяемости, а также облачное развертывание с помощью AWS, Azure, Google Cloud и т.д.
Такие решения не упираются в возможности платформы, а адаптируются под потребности бизнеса. Разработка при этом все равно будет занимать меньше времени, чем могла бы занять при написании кода с нуля.
При выборе решения часто возникает заблуждение, что NoCode сервисы слишком ограничены в функционале, а LowCode только немного развязывает вам руки. На самом деле даже с NoCode можно собирать большие сложные мобильные приложения и сайты, а уж с LowCode возможности практически не ограничены. Примеры можно найти в этой статье или в нашем чат-боте в телеграме. Особенно NoCode/LowCode подходит для теста гипотез и MVP.
А если вы все еще не уверены, подойдет ли вам No/Low Code — можно записаться к нам в Zero To One на бесплатную консультацию. За полчаса обсудим ваш проект и поймем, как быстро его можно сделать, за сколько и с какими инструментами 🙂
Забавно, как придумывают что-то новое, для чего-то старого. Например, раньше были уборщицы, стали менеджеры по клинингу. Раньше школьники клепали говносайты на ucoz, они гордо называли себя админами, а разрабы только улыбались в ответ. Сейчас они стали nocode-разработчики, а если что исправили в css, уже low code-разработчики! Мамочки в декрете, клепающие сайты на tilda, или как здесь на webflow, теперь так и именуются.
Я ничего против не имею, т.к. и сам работаю исключительно с wordpress, но это все-таки немножечко глупо 🙂
Школьники подросли, а кто-то из них пошел в маркетологи =)
Сделать и сделать хорошо — это всё-таки разные вещи 🙂
Называть себя разработчиком, сделав один кривой сайт на Тильде — занятие сомнительное.
Ну так есть и те, кто напишут один простой скрипт, скопипастив 99% с открытого источника, и назовут себя кодерами. Но ведь это не значит, что: а) они кодеры; б) называть себя кодером — глупо в целом.
Аналогий можно привести много.
Главный критерий — профессионализм.
Мир сильно сложнее, серьёзные платформы позволяют не искать кучу месяцев java dev или подобного для создания системы, гораздо проще найти или даже выучить человека на зп в несколько раз ниже и с возможностью быстрой замены под такую платформу. Статья по делу и lowcode платформы позволяют реально много.
И всё же. Не ясно, когда использовать No Code, когда Low Code, когда сразу нужны разработчики. Не хватает «земных» примеров. Например, если я пеку торты на заказ и хочу дать возможность заказчику «собрать» свой дизайн? А потом подключить карту для оплаты? А если я студия клининга? А если я создаю сервис по цифровизации бизнеса своих клиентов (SaaS решение, например. облачный CRM или что-то типа того).
в нашем чат-боте в телеграме
задолбали эти боты!
Не признаю тостеры 🙂
Если мне человек предлагает коммуникацию, то я ожидаю видеть личную коммуникацию (как упомянутые вами соцсети). А предложение «идите общайтесь с нашим ботом» звучит (ИМХО!) «идите читайте наши манифесты на стене туалета
Копипастят одно и тоже. Лучше вот так.
Компьютер, на самом низком уровне опирирует исключительно трёх мерным измерением. И текст и картинки и все остальное 2d-эшное которое мы видим на экране, это частный случай того самого 3d. Кроме того на уровне машины нет понятия вектор, там все растр. Информация о каждом отображаемое на экране пиксиле формируется с помощью программ называемых шейдеры. Язык грейдеров это отдельный язык, который предполагает отдельных разработчиков.
Формировать отображение с помощью грейдеров очень сложно, долго, а значит дорого, поэтому не удивительно, что со временем стали появляться программы абстракции, которые позволяют любому человеку заниматься цифровым творчеством. Например всем известные Фотошоп или 3dmax. Никто сегодня в здравом уме не скажет, что с их помощью невозможно сделать то, что можно с помощью кодинга шейдеров.
И это плавно подводит к тому, что подобные ноукоде платформы, это не бесполезная игрушка, а кульминация программирования. При грамотной реализации нужда в написании кода отпадет вовсе.
Если же кто-то считает, что харклрднее писать кодом, то могу сказать одну истину. Каждый, разработчик в гемдеве когда-то считал также. Типа, какой я программист, если не могу сделать все в коде. Но пролетали года и желание вечно кодить сменилось на желание делать. А сделать быстро можно только в графическом редакторе. Представьте открывающуюся крышку коробки. В редакторе это делать десять минут, а в коде с преобразованием матриц можно и за несколько дней также красиво не сделать.
К тому же, в мобильной разработке и в десктопе интерыейсы всегда создают с помощью графического редактора. А анрилэнджин вообще ноукоде редактор. А разве в разы более сложная логика в играх не лучшее доказательство жизниспособности ноукоде платформ?
Короче, те кто считает, что это ерунда, дико ошибается.
Почему во всех статьях про No-Code, все время идет сравнение с неким «обычным кодом»? Есть злой способ разработки с помощью какого-то абстрактного кода, который требует много дорогостоящих специалистов и много часов. И есть добрый такой же абстрактный no-code, который дешевый и быстрый.
Советую опробовать ноукод платформу AppMaster.io https://appmaster.io/. Думаю, у них неплохой функционал, многие там разрабатывают рабочие приложения с исходным кодом.
В декабре я устроил эксперимент: опубликовал в Linkedin пост с предложением бесплатной консультации. Откликнулось несколько ребят, с которыми мы неплохо поболтали.
Low-code с точки зрения разработчиков — есть ли плюсы для инженеров?
В прошлой статье о low-code в enterprise-решениях я обращался к бизнесу. Однако на «Хабре» бóльшая часть пользователей — инженеры (Кэп!), и в комментариях к статье я увидел резонное количество типичных возражений по LCDP (low-code development platforms). И пока те, кто не знает про Эффект Даннинга — Крююгера, уже ищут кнопку dislike, давайте разберем наиболее частые заблуждения и мысли.
На мой взгляд, наиболее частые заблуждения следующие.
Кто-то думает, что low-code — это использование готовых продуктов (а не философия разработки)
Под low-code понимают развитые code-first платформы. Кто-то из коллег приводил в пример даже WordPress.
В low-code отсутствует нормальный DevOps (code review, versioning, deploy, etc.), нормальное переиспользование кода и прочие абстракции. Ну и вообще, low-code это для каких-то типовых решений (для которых предназначен no-code).
Разработчикам лучше писать код с готовой ценностью, а не разрабатывать конструкторы.
«Low-code можно не понимать, это какой-то артефакт. Мы продолжим кодить как обычно». Впрочем, некоторые разработчики и про DevOps до сих пор не всё понимают и думают, что это должность. Так что с low-code ситуация не уникальна.
Почему я решил поднять тему low-code и перспектив развития IT-отрасли? По образованию я физик и предприниматель. В середине 90-х был собственником ISP (интернет-провайдера), после этого был в должностях от инженера в «Билайне» до управляющего партнера компании, специализирующейся на создании ПО по автоматизации (текущая должность, на которой я 7 лет). И сейчас интересно поразмышлять о том, что будет завтра.
Кратко о состоянии отрасли
Уровень абстракции кода растет. Начиная с машинных команд, уходя в процедурное программирование и отказываясь от управления памятью, с повышением количества фреймворков и развитием высокоуровневых языков, что будет завтра? Будет ли уровень абстракции разработки повышаться ещё, и если будет, то каким образом?
При этом, потребность в новых продуктах и автоматизации растёт. Дефицит специалистов в отрасли сейчас легко отследить на примере роста окладов: он опережает рост производительности труда в IT-сфере.
Кроме того, чем дольше одна команда разработки остаётся на проекте, тем глубже она погружается в операционное сопровождение проекта: большее количество фич порождает большее количество необходимых правок.
Расходы на разработку увеличиваются, и одновременно возникает конфликт интересов: бизнесу нужно меняться быстрее, а разработчики хотят интересных задач. Но бóльшая часть изменений у бизнеса — неинтересная.
На подобные вызовы IT-отрасль всегда отвечала повышением уровня абстракции и упрощением разработки. «Эпоху ассемблера» сменила «эпоха C++», затем наступила эпоха высокоуровневых языков с полным отсутствием управления памятью и ресурсами — и далее количество фреймворков и библиотек только увеличивалось.
Нет никаких предпосылок к изменению этого тренда. Давайте порассуждаем, сможет ли low-code продолжить его.
Low-code — это не философия?
В Рунете каждая статья о low-code заканчивается комментариями о несовершенстве конкретного продукта (продуктов). Отдельно о продуктах поговорим чуть ниже, а для начала предлагаю подумать о концепции low-code в целом.
Философия code-first
Разработчики поставляют заказчику конечную ценность. Вёрстка элементов, новые поля в сущностях, логика расчёта и потоки интеграции — всё это реализуется через программный код. Да, у него бывают какие-то настройки, которые иногда позволяют вносить изменения без привлечения разработчиков. Но на бо́льшую часть change requests всё-таки отвечают разработчики.
У разработчиков тут может возникать два желания.
Как бы нам писать только интересный код, а скучные операционные задачи («кнопку подвинуть») передать кому-нибудь другому? К нам для операционных моментов пусть обращаются лишь в редких кейсах, количество которых в идеале должно уменьшаться и дальше.
Если нас и просят об операционных изменениях, пусть делают это более конкретно. На коммуникацию должно уходить меньше времени. И хотелось бы, чтобы разбираться в собственном коде, который, возможно, полгода никто не трогал, было проще.
В code-first реализовать эти желания сложно.
Философия low-code
Представьте, что вы поставляете клиенту не непосредственно конечную ценность, а конструктор для реализации этой ценности. Нет, конечно, первичный функционал в вашем конструкторе придётся реализовать вам для целей отладки. Но при этом вы сможете создавать такие вызовы, функции и компоненты, которые.
Являются самодокументируемыми в подавляющем большинстве случаев.
В каждом компоненте есть настройки, которые делают его переиспользуемым.
Здесь важно отметить, что в code-first платформах тоже много настроек, и они даже разнесены по компонентам. Однако на практике их применение не позволяет снять с разработчика бо́льшую часть операционной работы.
Из этого и других компонентов можно собирать принципиально новую ценность для бизнеса. Технически это всё те же интерфейсы, компоненты бизнес-процессов и интеграции, но для бизнеса это принципиально разный функционал.
Если требуется какая-то очень эксклюзивная логика (один из компонентов отсутствует) и эта логика явно не будет переиспользуемой, вы сможете вставить нужный компонент, написав небольшой кусочек кода. В отличие от code-first систем, здесь не нужно писать весь модуль или микросервис — вы вставите код в нужный фрагмент без сервисной обвязки («сахара»). Часто такой код легко читается не только разработчиком, но и опытным менеджером или бизнес-аналитиком и состоит из 2–20 строк.
Сталкиваясь с новым требованием, вы или собираете новый функционал в уже созданном конструкторе, или дописываете в нём активити и компоненты, если они отсутствуют.
Если посмотреть на low-code разработку глазами code-first разработчика, то меняется в первую очередь уровень абстракции компонентов. Кроме привычных сервисов, библиотек, конструкторов, есть ещё один, более высокий уровень абстракции — абстракция бизнес-логики.
Это справедливо и при использовании готовых LCDP, и при разработке в парадигме low-code.
Low-code путают с развитыми code-first платформами
В дискуссиях я раз за разом сталкиваюсь с тем, что под low-code понимаются просто очень гибкие системы. Например, «Битрикс» — потому что «в нём же есть бизнес-процессы и моделирование таблиц» — или WordPress.
LCDP — это такая платформа, в которой всё сделано на базе конструктора, ведь если это не так, рано или поздно поддержание такой платформы перейдёт в code-first.
Я бы обозначил следующие критерии LCDP.
Ядро системы содержит только элементы конструктора и всё, что к нему относится, т. е. вам не придётся применять code-first подход для реализации того, для чего предназначена LCDP.
В графическом редакторе можно вставить код там, где он нужен. А в некоторых платформах можно и слегка переопределить код текущего компонента.
Приведу излюбленные нами примеры.
ETL / ESB Talend, WSO2 — low-code механизмы для построения интеграций.
Mendix, Pega, Appian, OutSystems, Caspio — как платформы для создания приложений разного класса.
Reify, Builder.io, Bildr — для фронта.
Из новичков 2021 года — Corteza (полностью open-source, Go + Vue.js), Amazon Honeycode.
Для игроманов — давно ли вы смотрели на Unity и продукты на его основе? Видели ли Construct?
Российские — ELMA BPM, Creatio (разработка «Террасофт») и Comindware, универсальная CUBA Platform, Jmix.
Продукты особо крупных вендоров — Microsoft Power Apps, Oracle APEX, Salesforce Platform, IBM BAS, SAP BTP.
Частично open-source — Builder.io (фронт), Bonita, Joget.
Есть и пограничные случаи. Например, Pimcore, которая в части фронта, workflow, моделирования инфомоделей с калькулируемыми полями является по своей сути low-code (с некоторыми оговорками, но это не тема данной статьи). Если же пытаться делать что-то за рамками этого, вы свалитесь в традиционное поддержание монолита.
Или тот же «Битрикс». В нём удобно моделировать данные и строить бизнес-процессы, в которые при желании упаковывается PHP-код в low-code стиле (т. е. без длинных инициализаций). Однако огромный объём коробочного функционала, созданного не в LCDP-стиле, и отсутствие развитых инструментов low-code в других частях приводят к традиционному code-first.
Короче, если вы слышите, что «мы пробовали low-code платформу — и у нас ничего не получилось», советую разобраться в деталях. Может быть:
это была действительно плохая LCDP (такого — сколько угодно);
команда пыталась писать в LCDP больше кода, чем нужно. Вместо переиспользуемости — один кастомный компонент, куда вставляется огромная портянка кода, мы встречали такое!
Low-code не содержит традиционных средств контроля, привычных разработчику (code review, deploy)
Это миф. Вы найдёте эти компоненты в подавляющем большинстве платформ. Многие (Mendix, Pega) имеют собственные CI с элементами low-code.
Хотя, безусловно, проводить ревью не всегда просто. Если с кодом компонентов всё понятно — там всё так же, как и в традиционном code-first, — то по поводу того, что можно сделать в конструкторе…
Представьте, вы разработали на Unity ходилку-стрелялку, поменяли стены, добавили горы, а потом сохранили и отправили всё это на ревью. Понятно, что версионировать изменение каждой стены вы не станете, и у вас будут огромные версии изменений, разобраться в которых в принципе будет достаточно сложно. Тем более когда дело касается визуальных изменений и вставок кода. Процесс ревью это осложняет в той мере, в какой увеличивается количество изменений за один коммит.
С переиспользуемостью тоже обычно всё в порядке: можно использовать процессы в качестве подпроцессов, можно из одной «джобы» вызывать другие и пр. Если есть желание сделать хорошо — с переиспользуемостью проблем не будет.
Разработчикам лучше писать код с готовой ценностью, а не разрабатывать конструкторы
Разработчики обычно брезгливо относятся к самой идее того, что могут что-то накликать мышкой. Между тем подавляющее большинство задач разработчика — не rocket science, а рутина. Та самая, которой заниматься неинтересно и от которой хочется побыстрее избавиться.
В рамках проекта вы ограничены в выборе задач. Маловероятно, что к вам будут попадать исключительно интересные и креативные (это подразумевает, что кто-то другой займётся скучными задачами, и тогда всё вышесказанное применимо и к этому бедному человеку). Совсем не заниматься мелкими, а порой и однотипными, скучными вопросами почти невозможно. Просто потому, что кто-то ими должен заниматься.
Как ситуация поменяется в рамках LCDP? Скучные задачи никуда не денутся и будут возникать с той же частотой, но, вместо того чтобы тратить на них уйму часов, вы сможете закрывать их в разы быстрее или вообще передавать не разработчику. Зачем писать ещё одну интеграцию между системами, когда вы быстрее сделаете её через ETL-решения? Зачем забивать спринт созданием нового экрана, если это может накликать дизайнер?
Чем быстрее вы закрываете скучные задачи, тем больше времени у вас освобождается на более интересные. Более того, вы статистически чаще будете получать интересные задачи, потому что «перерыв» на рутину сократится в разы.
А что с реально талантливыми разработчиками, теми, кто любую самую сложную задачу делает изящно и быстро?
Сдав задачу в виде кода и получив через полгода change request, они сталкиваются со следующим:
надо вспомнить, как тут что написано;
надо бы отрефакторить — код быстро устаревает.
Но очень редкая команда подписывается под рефакторинг. И редкий бизнес-пользователь поймёт, почему минорную правку ему оценили в несколько дней.
Что в итоге? Мы хотели писать интересный код, но через какое-то время ничего интересного не пишем. Нам остаются операционка и угрызения совести за то, что тут всё уже не очень красиво.
Если же вы мыслите в плоскости LCDP, дело не ограничивается только более быстрым решением рутинных задач. Рефакторинг происходит не на уровне конечных ценностей, а на более высоком уровне абстракции — на уровне реализации компонента конструктора. Как следствие, вам приходится больше думать и больше проектировать. Меньше областей остаются без вашего надзора, сделать плохо поддерживаемую задачу в LCDP намного сложнее ввиду того, что как минимум плохой нейминг или плохую логику могут обнаружить даже не разработчики. Сам подход заставляет вас больше мыслить абстракциями.
Лирическое отступление. Многие тимлиды конкретно для себя решают эту задачу так: реализацией занимаются другие члены команды, а они думают. Ни к чему хорошему это не приводит. Такие тимлиды часто начинают скучать по коду, а команда в целом становится более хрупкой. Антихрупкость таких людей обеспечивается за счёт хрупкости других членов команды, которые выступают в качестве машинисток. Этому пороку могут быть подвержены и традиционные, и low-code разработчики.
Low-code можно не понимать, это какой-то артефакт. Лучше продолжим кодить как обычно
Можно не думать о будущем разработки, если допустить, что:
количество задач для разработчиков будет расти не медленнее, чем количество самих разработчиков и субститутов разработки (с учётом повышающейся производительности труда);
бизнес сможет оплачивать растущие аппетиты разработки и не разорится при этом (т. е. ROI в IT всегда будет положительным);
другие типы инвестиций не будут конкурировать с инвестициями в IT.
Давайте проведём мысленный эксперимент и прикинем, насколько всё это вероятно в реальной жизни.
Количество задач для разработчиков будет расти не медленнее, чем количество самих разработчиков и субститутов разработки
Сейчас дефицит разработчиков в мире — около 10 %. Я не могу предсказать будущее, но могу представить, какие условия нужны, чтобы этот дефицит оставался всегда.
Первое: производительность разработчиков не должна повышаться настолько, чтобы она могла компенсировать разницу в дефиците (т. е. на 10 % относительно нынешней производительности).
Второе: количество разработчиков не должно расти быстрее, чем количество задач. Дополнительное условие — количество субститутов разработки не должно снижать этот дефицит.
А это противоречит фундаментальному закону спроса и предложения, ведь спрос всегда балансируется предложением до равновесного значения.
Что мы видим сейчас?
Огромное количество людей или думают о переквалификации в IT, или уже находятся в процессе переквалификации. По данным опросов, каждый пятый разработчик не имеет профильного образования и пришёл в IT после окончания курсов. И это не считая повальных курсов программирования даже с детского сада и школы и всё увеличивающегося потока студентов IT-специальностей в вузах. IT начинает отбирать потенциальных специалистов у других специальностей. Этот маховик раскручивается медленно, но верно.
В отчётах инвестиционных банков рынок no-code решений (которые являются прямыми субститутами разработки) уже сейчас выглядит примерно так. И если вы посмотрите на этот список, то увидите, что количество продуктов растёт. Наберите в поисковике «название любой компании low-code/no-code» — и вы поймёте, что почти все — от российского «Сбера» до американской Apple — думают о том, как существенно повысить производительность труда в разработке.
В конце концов, дисбаланс на рынке труда легко прослеживается на соотношении стоимости управленцев (на которых лежит бóльшая ответственность и на которых завязаны мультипликаторы) и мидлов (на которых ответственности существенно меньше). Разрыв по доходам — в 3–4 раза, и это не случайность.
При 20 миллионах разработчиков в мире одна только Индия поставляет на рынок по миллиону разработчиков ежегодно (с ежегодным увеличением этого количества), т. е. существует некоторая вероятность, что в будущем дефицит разработчиков может не сохраниться. Есть и более радикальные суждения: у Германа Грефа, например, или у футуролога Герда Леонгарда.
Бизнес сможет оплачивать растущие аппетиты разработки и не разорится при этом
Чем дороже разработка, тем больше разрыв между технологическими компаниями и всеми остальными. Те, остальные, вынуждены встраиваться в экосистемы гигантов. А экосистемы гигантов имеют очень высокую производительность труда (в силу объёмов). Это само по себе заставляет компании уходить в чужие экосистемы.
Было время, когда затраты на IT были несущественными. Но программное обеспечение становится всё более сложным и разнообразным, и стоимость ИТ-инфраструктуры является значимым фактором для стартапов и одной из основных статей бюджета. Чем дороже IT, тем больше субститутов для инвестиций.
Другие типы инвестиций не будут конкурировать с инвестициями в IT
Почему в IT сейчас много денег? Организации видят в цифровизации хорошо окупаемые инвестиции. Волна цифровизации пройдёт (все компании будут в какой-то степени диджитализированы, а прочие уйдут с рынка), нужно будет сопровождать и поддерживать применённые решения. При всё растущей стоимости IT не встанет ли вопрос о поиске иных источников заработка?
Не станет ли на каком-то этапе стоимость IT столь значимой, что будет автоматически отсекать бо́льшую часть новых — ныне рентабельных — проектов?
В заключение
Я рекомендую разработчикам посмотреть в сторону low-code и как минимум выполнить несколько задач на любой из таких платформ — для расширения собственных границ.
Мы должны понимать область применимости, видеть срез текущих возможностей и изучать что-то новое, ведь на то мы и инженеры, чтобы смотреть на новые технологии глазами практиков. Возможно, вы не найдёте ни одной LCDP, которая решила бы ваши задачи, но как минимум исследовать этот тренд для развития инженерной эрудиции сегодня может быть полезно.
