Разговоры о программировании без программистов идут постоянно. За последние 14 лет моей работы в IT идёт уже вторая волна любви к low-code решениям. Если вы дольше наблюдаете IT-рынок, то наверняка вспомните ещё пару подъёмов этой темы.
Не-программистов, которые создают бизнес-приложения в визуальных редакторах, назвали Citizen Integrator или Citizen Developer. Слоганы продавцов этой темы сводятся к следующему:
...with no-code/low-code platforms, anyone can build applications without software expertise, significantly faster, and at a fraction of the cost.
В этой статье я хочу разобраться насколько правдивы эти обещания, а также где и как стоит применять low-code платформы, чтобы не выстрелить себе в ногу.
Зачем бизнесу low-code платформы?
Текущий всплеск интереса к low-code скорее всего связан в тем, что дорогие программисты стали еще дороже, но и дорогих в свободном доступе на рынке не найдешь. Не-IT-компании не могут нанять вообще никого стоящего, а проекты при этом делать надо. Даже аутсорсеров найти непросто, потому что их кадры тоже размываются из-за желания крупных компаний развивать собственное IT и для этого идет найм сотнями, тысячами и тысячами.
Цифровая трансформация прорвалась даже в те компании, которые до последнего момента пытались обходить ее стороной. В итоге IT-проекты есть, деньги есть, а рук нет. Что делать? Кажется выгодным использовать low-code/no-code платформу, чтобы дешевые и многочисленные не-айтишники могли создавать бизнес-приложения.
На эту тему в Москве недавно прошла конференция «LOW-CODE 2021», где программный директор серии практических конференций издательства «Открытые системы» Дмитрий Волков написал такую вводную:
«Апологеты преподносят low-code как главный инструмент масштабной цифровой трансформации. Критики указывают на лоскутность, низкую производительность, отсутствие должной интеграции, проблемы с обслуживанием доморощенных решений, безопасностью и надежностью. Поэтому, прежде чем применять low-code/no-code, посетите нашу конференцию»
Я побуду в роли критика, но, заодно, опишу способ применения low-code платформы, при котором это применение будет эффективно и оправдано.
Причина провала предыдущих подходов к low-code
Low-code подкупает, когда видишь реализацию простой системы без кода и понимаешь, что ее создали в визуальном редакторе без программиста. А это дешево и быстро. Возникает естественное желание смасштабировать этот подход на все задачи бизнеса.
Приступ любви к low-code заканчивается тем, что low-code подход не может преодолеть проблему увеличения сложности, которая нелинейно растет во время создания IT-решения. В случае с визуальным программированием сложность растет слишком быстро, и система становится неуправляемой.
До определенного момента (до пересечения графиков) такое решение будет обгонять обычный подход по скорости разработки, т.е. вы быстрее выйдете на рынок. Но плюсы визуального программирования быстро заканчиваются и "визуальное" решение стремильно переходит в неуправляемое месиво.
Романтика low-code разбивается о суровую действительность, где IT должно помогать бизнесу создавать большие и сложные IT-системы с постоянно меняющимися требованиями и при этом выдерживать множество внутренних и внешних SLA.
Выглядит так, что для «простых» проектов low-code может подойти, а для «сложных» перестает работать. Давайте определим, что такое простая и сложная IT-система:
- Простая система – решение локального уровня для пары сотрудников. Тетя Маша из бухгалтерии хочет, чтобы ей приходила СМС, когда в почту прилетает письмо от шефа. Она идет в Zapier и «программирует» себе пару триггеров и интеграций. Бизнес от этой автоматизации не зависит, логики минимум. Если требования тети Маши поменяются, то изменения можно будет легко внести самой тете Маше. Если триггер сломается, то никто в компании и среди клиентов бизнеса этого не ощутит.
- Сложная система – решение на уровне бизнеса, критичное для бизнеса. Например, это тарификация заказов в Ozon, система управления заказами в Leroy Merlin, логистика доставки в маркетплейсе и т.п. От этих систем зависит прибыль бизнеса и репутация бренда. Такие системы часто меняются и изменения нужно вносить быстро и безопасно, т.е. уметь качественно и быстро тестировать. Эти системы подвергаются колебательным нагрузкам, их нужно уметь горизонтально масштабировать.
Простые системы можно и нужно делать на low-code платформах без программистов, а вот со сложными возникают проблемы, которые никак не могут решить создатели low-code платформ:
- Рефакторинг и уменьшение технического долга или невозможно, или затруднено. При этом изменения в бизнесе нужно успевать вносить в системы. Бизнесу все равно сделали систему программисты, написав код, или аналитики, накидав квадратиков в визуальном редакторе. Изменения нужно вносить быстро и безопасно. На данный момент ни одна low-code платформа не имеет средств рефакторинга хотя бы приближенных к уровню продвинутых IDE.
- Автотестирование невозможно или крайне затруднено. Без автотестов невозможно безопасно вносить изменения. Если нет автотестов, то мы возвращаемся в те доисторические времена, когда для релиза одной фичи нужен полный ручной регресс всей системы. Бизнес, который умеет считать деньги, не будет за это платить.
- Высокие нагрузки, кастомные интеграции и безопасности. Эти задачи требуют квалифицированных инженеров и не могут быть полностью решены визуальном программированием, которое ориентируется на решение типовых задач.
Отдельно надо сказать, что если система создана в визуальном редакторе и ее решили перевести в обычный код, то нужно написать всю систему заново. В случае, если система изначально написана кодом, то возможна частичная замена кода или рефакторинг.
Получается, что сложное решение на low-code платформе – это «readonly-код» с очень высокой стоимостью внесения изменений. Это ли надо бизнесу?
РДС (Россия делает сама)
А может проблема в том, что low-code платформы слишком универсальные? Логичным ответом на это будет желание создать свою платформу, под себя.
Я общаюсь с разными компаниями и вижу, что внутри они создают собственные low-code решения. Кроме желания создавать ПО без программистов, есть еще естественная эволюция микросервисной архитектуры в оркестратор бизнес-сервисов.
Но при создании low-code платформы для себя появляется фактор стоимости. Затраты на разработку такой платформы, на мой взгляд, неоправданно высокие. Из чего состоят затраты:
- Чтобы создать платформу для программирования без программистов, нужны очень хорошие программисты и проектировщики. То есть изначально нужно 1) привлечь, 2) удержать, чтобы экспертиза не потерялась, и 3) долго оплачивать профессиональную и дорогую команду айтишников.
- Платформа не может остановиться на первой версии, поэтому команда будет разрабатывать платформу… всегда и платить этой команде нужно много и долго.
- Пользователи этой платформы тоже получают зарплату. Хоть это и не перегретые программисты, но это продвинутые пользователи ПО и платить им нужно соответствующие деньги.
- Поддержка пользователей, организация их обучения новым версиям тоже стоит денег и времени.
- Чем шире low-code платформа используется в компании, тем больше кейсов она должна покрывать, т.е. она должна становится универсальней и гибче. А чем универсальней решение, тем оно дороже, т.е. такая платформа будет постоянно «дорожать».
При этом у собственной low-code платформы остаются всё те же проблемы с рефакторингом, тестированием, нагрузками и т.д. Эти проблемы остаются, потому что их решение стоит еще дороже, чем стоимость десятка таких low-code платформ.
Как мне кажется, единственный шанс окупить всю эту историю с созданием собственного решения, это продажа внутренней low-code платформы на внешнем рынке, потому что сама себя внутри компании эта платформа вряд ли когда-то окупит.
Когда применение low-code оправдано
Мы уже поняли, что сама по себе low-code платформа не принесет успеха в создании сложной IT-системы. Тем не менее у low-code платформ есть важная характеристика, которую хочется использовать – это визуализация алгоритма. То, что скрыто за строчками кода при обычном программировании, нарисовано в виде схемы в low-code платформе. Это дает возможность аналитиками, владельцам продукта, программистам, проектировщиками общаться на одном языке, глядя на схему процесса.
Работающим подходом является комбинация 1) low-code платформы для визуализации процесса и 2) реализация всех функций этого процесса в виде обычного ПО. Мы применяем для этого BPMN-движки типа Camunda и микросервисную архитектуру. На BPMN описывается процесс, а микросервисы реализуют нужные функции, включая интеграцию, работу с нагрузками, автотесты.
Здесь важно, что BPMN-движок не является самодостаточным, он только организует процесс, оркестрирует. Мы не пишем код внутри Camunda, чтобы потом не упереться в отсутствие рефакторига и автотестов.
В комбинации low-code + обычное ПО тоже есть сложности. Если подойти к процессу без должного опыта и внимания, то можно создать неподдерживаемое месиво из квадратиков и стрелочек. Тут нужны профессионалы, которые отлично знают нотацию BPMN, хорошие аналитики, готовые разложить процесс на части и учесть все исключительные ситуации. Откуда тогда экономия?
Экономия времени и денег получается за счёт декларативного описания процесса:
- Его видно, поэтому проще коммуницировать внутри команды и с пользователями.
- Его могут создать не-программисты и делают это довольно успешно после прохождения обучения по BPMN-движку.
- Всегда актуальная документацию в виде схемы бизнес-процесса. Это как автодокументация, генерируемая по коду, только здесь наоборот код, генерируемый по документации. Они никак не могут разойтись и всегда соответствуют друг другу.
- BPMN – довольно популярная нотация, т.е. знатоки есть среди разных профессией. При этом эта нотация всеобъемлющая, ею можно покрыть всё, что вам нужно для работы.
Кроме этого, BPMN-движок из коробки реализует часть рутинных операций, которые программистам писать уже не надо, например, таймеры, переходы между этапами и т.п.
Вывод
Пока я делаю вывод, что серьёзную IT-систему не создать без хороших инженеров исключительно на low-code платформе. Low-code оправдано применять для простых интеграций не критичных для бизнеса.
Тем не менее у low-code платформ есть характеристики, которые стоит взять на вооружение. Если грамотно встроить low-code платформу в разработку ПО, то можно нивелировать минусы и сэкономить за счет плюсов.
Ссылки
Оригинал статьи на Хабре https://habr.com/ru/post/645713
Комментариев нет:
Отправить комментарий