Low-code платформы: панацея или рискованная ставка?

Low-code платформы (Low code application platforms, LCAP) возникли как реакция на сложность и многообразие современных средств разработки ПО.


Согласно Gartner, одним из самых известных игроков в этой области является Mendix. Продажа Siemens за космические $700 млн. это подтверждает. Так что я буду использовать эту платформу как пример, хотя аналогичные выводы будут верны и для Outsystems, Appian, Kony, Betty Blocks и других.


image


Итак, ориентируя продажи на топ-менеджеров, вендоры low code платформ обещают, что даже простые пользователи смогут самостоятельно создавать бизнес-приложения.


То есть разработчики больше не нужны?!


Нуу…, через несколько лет Mendix вынужден признать:


text
"Сейчас разработчики нужны больше, чем когда-либо"


Вот это поворот!


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


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


Отличный инструмент для прототипирования


Mendix — это действительно отличный вариант для автоматизации простых процессов или создания прототипов, доступный аналитикам или продвинутым пользователям.


Визуальный редактор позволяет описать модель данных, быстро создать экраны с помощью набора виджетов и шаблонов и даже описать логику с помощью так называемых microflows:


text


По завершении можно в один клик развернуть свое приложение в облаке Mendix и начать с ним работу. Так просто, что похоже на магию! И похоже, это неплохо продается.


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


Медленная разработка


Любая логика — будь то вычисления или взаимодействие с пользователем — должна быть описана в блок-схеме (microflow), как показано выше.


Здесь есть несколько проблем.


Во-первых, это долго. Очевидно, быстрее написать 10 строк кода в хорошей IDE, чем перетаскивать, настраивать и соединять десятки блоков.


Во-вторых, читаемость. Блоки выглядят красиво, но что значит это Sub_RegistrationValidation? Понять это не провалившись внутрь блока невозможно. Как только количество блоков вырастет до нескольких десятков, разобраться в логике станет крайне сложно.


Как альтернативу для сложных случаев, Mendix поддерживает вызовы Java кода из microflows. Код можно писать в Eclipse, что в целом неплохо, хотя многие предпочли бы более популярную IDE. Минус в отсутствии прозрачности: все точки входа находятся в microflows, так что логика разбросана между двумя слабо связанными средами. Как результат, отладка и отслеживание зависимостей затруднены.


Последнее, что я хотел упомянуть — это контроль версий.


Хорошая новость в том, что он есть. Плохая — в том, что он представляет собой урезанный вариант Subversion. Забудьте о git flow.


Отсутствие контроля


Любой, кто знаком с экосистемой Java, не может недооценивать силу open source. Когда где-то в стеке появляется ошибка, вы видите, в какой части кода это произошло. Код можно отладить, чтобы точно понять, что происходит. Можно загуглить решение. Можно отправить pull request. В крайнем случае, можно форкнуть библиотеку. Вы полностью контролируете проект.


С Mendix об этом можно забыть. Это закрытый коммерческий фреймворк, и что происходит внутри него — настоящий черный ящик. Все, что вам остается, — купить платную поддержку или ждать, что кто-то поможет на форуме с ~200 вопросами в месяц (сравните с тегом #spring на stackoverflow!).


Зависимость от вендора


Mendix наверняка довольно часто этим попрекают. Они даже опубликовали статью о том, что на самом деле нет никакой зависимости. Если читать между срок, она гласит:


Вы можете получить свои данные, DDL, UI ресурсы и код (microflow волшебным образом преобразованные в Java код).


Будет ли это исполняться или компилироваться без рантайма и API Mendix? Можно ли это поддерживать и развивать? Вопросы риторические. На самом деле потребуется полностью все переписать. Вы зависите от проприетарной платформы. Вы не владеете созданной вами системой.


Ограниченная масштабируемость


Маркетинг Mendix ориентирован на крупнейшие компании, поэтому термин "масштабируемость" постоянно мелькает в маркетинговых материалах.


В 2017 году Mendix представили stateless runtime — то есть вся информация о сессии либо хранится на стороне клиента, либо в персистентном хранилище.


Теоретически это означает неограниченную горизонтальную масштабируемость. Звучит здорово, но как обычно есть нюанс — база данных.


База данных практически всегда оказывается узким местом в корпоративном приложении. Итак, что же хранит данные за множеством stateless-серверов Mendix? Никаких сюрпризов — это старая добрая реляционная база данных. В облаке Mendix — PostgreSQL. Более того, сгенерированный Mendix DDL, скажем мягко, не совсем оптимален. Например, я видел промежуточную таблицу, которая обычно используется для моделирования отношений N:M, созданную для отношения 1:N.


Вопрос масштабируемости можно было бы решить стандартными методами: оптимизацией структуры БД, кэшированием или даже используя такие решения, как Citus. Но такой возможности естественно нет.


Единственным способом масштабирования БД остается масштабирование с использованием реплик для чтения (например, Amazon RDS). Но для записи это не сработает.


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


Кадровый вопрос


Поиск квалифицированных кадров — всегда сложная задача. Казалось бы, в этом Mendix — мечта любого менеджера, ведь требования к квалификации резко снижаются.


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


Цены


Последнее, но не менее важное. Стоимость лицензии на одно приложение начинается от $1875 в месяц при условии подписки на три года, лицензия ограничена 50 внутренними пользователями.


Цена корпоративной лицензии с возможностью локального развертывания начинается от $7825, а это почти $100 000 в год.


Среднего размера предприятие с несколькими сотнями пользователей будет ежегодно оплачивать счета на десятки миллионов рублей.


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


Тогда почему LCAP все еще популярны?


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


Планирование бюджета, бесконечные согласования, отсутствие людей, готовых брать ответственность — думаю, это многим знакомо.


Самое забавное, что первое, что приходит в голову, когда ИТ проекты движутся слишком медленно, — это нанять еще больше разработчиков и, конечно же, менеджеров. Стоит ли говорить, что это только ухудшает ситуацию. Я знаю пару банков, в которых более 10 000 (!!!) разработчиков, и по меньшей мере половина из них занимается бесполезной работой.


В отчаянии руководители предприятий ищут решение в таких "волшебных палочках", как LCAP, якобы способных решить все проблемы.


Как выбираться из этого замкнутого круга — тема для отдельной статьи. Но это вопрос управления, а не технологий.


Не вдаваясь в подробности, если вам удастся создать небольшую квалифицированную команду из 3-10 полностью вовлеченных в проект человек, с прямым контактом с ЛПР, вы получите отличные результаты быстрее и дешевле, чем ожидаете.


Каковы альтернативы?


Сейчас есть огромный выбор инструментов и фреймворков для разработчиков.


Например, Spring Framework — самая популярная open-source технология для создания корпоративного ПО, которая отлично сочетается с веб-фреймворками вроде React или Angular. А такие инструменты, как Spring Initializr и JHipster, значительно упростили создание проектов за последние несколько лет.


Если вы хотите получить результат быстрее, стоит рассмотреть RAD инструменты, такие как CUBA Platform.


Она создана на основе того же Spring Framework, дополняет его визуальными инструментами разработки и огромным количеством готовых компонентов. Пожалуй, это ближайшая альтернатива LCAP, обеспечивающая гибкость и комфортный процесс разработки.


Окончательный выбор должен зависеть от поставленной задачи, а также навыков команды и ваших предпочтений.


Заключение


Low-code платформы отлично подходят для прототипирования. Они сокращают разрыв между бизнес-пользователями и IT, что позволяет быстро получить работающий прототип и сформировать видение будущей системы.


Поскольку пользователей прототипа очень мало, затраты на этом этапе тоже невелики. И именно в этот момент стоит остановиться!


При использовании LCAP для разработки полноценной системы скорость работы неизбежно упадет, и вы будете зависеть от дорогой, ограничивающей вас проприетарной платформы.

Haulmont
Создаем современные корпоративные системы

Similar posts

Comments 113

    +12
    Послушайте, ну неужели на это кто-то покупается? Почитайте мой древний уже пост про BPMN, там почти все те же проблемы описаны, и они имеют место в полный рост. Совершенно та же фигня — пока мы прототипируем, рисовать картинки со стрелочками красиво и круто. Как только мы начинаем делать что-то реальное — мощности языка стрелочек перестает хватать, нам нужен второй/третий/пятый язык, и профессиональные разработчики на нем — потому что писать в виде стрелочек разработчики в жизни не могут, ибо у этого метода есть кучка недостатков, которые пока никто не преодолел.
      +4
      Учитывая что это хорошо продаётся (обычно менеджерам старшего звена) крупным компаниям, то значит они на это ведутся.

      Я видел одну такую компанию, по факту покупатель low-code платформы просто аутсорсит свой ит-штат на поставщика такой платформы (постоянные консультации и кастомные фичи по заказу). Так что даже в самом худшем случае кодеры никуда не денутся, посто они будут работать на эту платформу.
        +2
        Я работал на такую контору — поставщика. Это выглядит так — тебя спрашивают, вот у нас тут намечается заказ, на чем будем делать UI? А пока разработчики думают, им уже формулируют ответ: делать будем на продукте XYZ, мы уже продали на него лицензию. И все.
        +4

        Однако покупаются. Судя по HH, разработчики на Pega требуются в Альфа-Банке и ВТБ.

          +1
          К сожалению да, покупается. Особенно на западе. Пост обязательно почитаю, спасибо.
            +4
            К сожалению, да. Работая по контракту в компании из первой пятёрки производителей электроники, я познакомился с Mendix, на основе которого, на полном серьёзе, писалась CRM + Workflow management. Источниками данных были агрегирующий сервер PowerBi и APIшка одного из корпоративных ресурсов. Как оно пролезло? Через менеджмент, купившийся на посулы LCP об экономии ресурсов на разработчиков. А благодаря строгой иерархии 99% сотрудников даже помыслить не могли о том, чтобы сказать хоть слово поперёк. В итоге получился забагованный кадавр, внедрение которого так и не было завершено.
              +2
              Круто, реальный кейс! Это была западная компания насколько я понимаю?
                +4
                Да. Я эту штуку пытался девопсить. Парадоксальная картина — отличное железо с хорошим «низкоуровневым» софтом, и полная дичь на уровне приложений и утилит. От некоторых решений я выглядел, как известный мем с куряшим Мэтью Макконахи.

                Упомянутое ПО на Mendix должно было решать проблемы управления проектами для субподрядчиков. Как только появлялась необходимость выйти за рамки тривиального CRUDа, начинались танцы, так как сама парадигма LCP говорит нам «ешь-что-дали». А выход за рамки был нужен, т.к. бизнес-процессы от региона к региону отличались весьма радикально. Юнит-тесты есть, но свои. Голый код на Java писать можно в action'ах, но Mendix Studio это не поощряет, намекая, что LCP это много кликать мышкой, а если ты хочешь писать код, то ты делаешь что-то не так. UI приложения выглядел крайне топорно, в результате чего UX субподрядчиков выражался, в основном, нецензурными лексическими конструкциями.

                Умножим всё это на проблемы доставки фиксов из-за отсутствия привычного git flow, проблемы тестирования в CI/CD, а также реально новую среду, в которую разработчиков засовывали насильно. Субъективно человеко-ресурсов было потрачено ничуть не меньше, чем если бы приложение писалось традиционными методами в команде, которая натаскана на выбранный стэк технологий.
                  0
                  Спасибо, крайне интересно. Полностью повторяет мои ощущения и проекцию на реальный проект, хотя я игрался с Mendix только пару месяцев в исследовательских целях.
                    0
                    Но уверен, что лица, принимавшие решения, получили свой бонус за внедрение прогрессивной технологии?
                      +1
                      Вы явно знакомы с корпоративной культурой :) Номинация в категории «инновации», а также бонусы за оптимизацию бизнес-процессов. Разумеется, включая скрытые плюшки в виде job visibility и job security (в данном контексте под «security» имеется в виду обеспечение работой себя любимого, ибо больше в этот стэк никто не хочет лезть или не обладает достаточными уровнем знаний). Проталкивание разработки напоминало форсинг мемов на имиджбордах — все понимают, что это отстой, но остановиться уже не могут.
                –2
                При чем здесь BPMN( BPMS )? Это не в каком месте не lowcode. Так и любой фрэймворк или СУБД можно к lowcode отнести.
                Наличие BPMS( а иначе зачем вообще BPMN ) как части системы упрощает понимание как же у вас в реальности работает бизнес логика «высокого уровня».
                Объем кода при этом меньше не становиться( если конечно не писать свой движок выполнения бизнес процессов ), но система становиться более прозрачной и ее легче модифицировать.
                  +1
                  >При чем здесь BPMN( BPMS )?
                  При том, что на нем точно также претендуют сделать всю логику. Да-да, есть такие вендоры.
                  0
                  В 1992-м году, принимая меня на первую в жизни работу, начальник сказал: «Жалко мне вас, сегодняшних студентов. Пока доучитесь, программирование вымрет и будет заменено CASE (computer-aided software engineering)». С тех пор прошло почти 30 лет — а мы все программируем и программируем…
                  +4
                  Во-первых, это долго. Очевидно, быстрее написать 10 строк кода в хорошей IDE, чем перетаскивать, настраивать и соединять десятки блоков.


                  Не поверите, но многие 1Совцы считают, что мышкой у них получается быстрее программировать, чем в нормальной IDE. На вопрос, как они потом мышкой делают merge (даже без привязки gitflow), к сожалению, пока никто внятного ответа не дал.
                    +4
                    1Совцы все-таки пишут код. Мышкой они интерфейс рисуют. Это ближе к классическому RAD. По возможностям и скорости разработки любому low code до 1С как до Китая…
                      +1
                      Нет. Они именно мышкой создают программные объекты, вроде справочников и регистров. И даже запросы по их утверждению мышкой пишут (хотя там по сути чистый SQL с парой небольших фич, вроде автоматической группировки по всем использованным полям в виртуальных таблицах регистров).

                      И интерфейс у них уже давно с относительным позиционированием (а не олдскульный WYSIWYG), и задается как иерархия контейнеров. Но его тоже мышкой пишут.
                        +3
                        Объекты, регистры и даже простые запросы — это довольно близко к «декларативщине». Здесь нет логики, и поэтому на мой взгляд нет ничего плохого в том, чтобы описывать их в визуальной среде. Это может даже быть удобнее и быстрее кода в каких-то случаях. То же касается и интерфейса, неважно с относительным или абсолютным позиционированием.

                        Логику они все же пишут в коде, а не блок схемами.
                          0
                          Ну вы же понимаете, что «декларативщина», как и «простые» запросы — штука относительная. И говорить, что в этом всем нет логики это немного странно на мой взгляд.

                          Чем по вашему логика группировки данных (регистры) или логика запросов (запросы) — меньшая логика, чем логика проверки ограничений (например что остаток меньше 0), которая в 1С задается в коде?
                            +1
                            Если честно, я не спец по 1С, не знаю, почему ограничения там задаются в коде. В Java полно вариантов задавать их декларативно, вот тут неплохой обзор.

                            Я имел в виду сравнение с алгоритмами. Код с ветвлениями, условиями, вызовами функций и т.п. Что-то вроде (фантазирую) «проверить остатки, если недостаточно проверить дату следующего поступления или отменить другой заказ, если этот клиент имеет приоритет».
                              0
                              Ну эти варианты это только ограничения на значения полей таблиц (то есть CRUD или типа того). Имеется ввиду более сложные ограничения (именно например остаток + резерв
                              больше 0 если по складу нужно проверять положительный остаток). Вот тут чуть подробнее.

                              Хотя впрочем учитывая что в SQL с этим не справились, ожидать того же от 1С было бы достаточно глупо.

                              В любом случае ограничения это тоже декларативная логика по сути, но ничего — задается кодом. А регистры мышкой.
                                0
                                «проверить остатки, если недостаточно проверить дату следующего поступления или отменить другой заказ, если этот клиент имеет приоритет»

                                Собственно именно поэтому в 1С ограничения и задаются в коде. Т.к. простые случаи все-таки встречаются довольно редко.

                                В Java полно вариантов задавать их декларативно, вот тут неплохой обзор.

                                Именно в платформе 1С есть некоторый аналог описанных например в Transaction listeners валидаторов, в виде подписок на события (т.е. некоторая процедура, которая срабатывает перед/при записи объекта в БД, в том числе, на нее можно навесить проверку и транзакцию отменять). Активно используется в типовой «Библиотеке подсистем».
                          0
                          Не совсем. Там есть еще такая штука как СКД: habr.com/ru/company/1c/blog/336258. И там классическое визуальное программирование.
                            +4
                            В визуальном программировании как таковом нет ничего плохого. Там где оно уместно, это действительно может и время экономить и порог входа снижать. Имхо, в конструкторе отчетов оно как раз уместно. Смысл в том, что low code платформы пихают его везде, не особо предоставляя альтернативу.
                              +2
                              В визуальном программировании как таковом нет ничего плохого

                              Как вы правильно заметили, когда его не начинают использовать везде где только можно без альтернативы. То есть как дополнительный механизм — почему нет. Но как у основного механизма у ВП проблем очень много. Вот тут я немного касался этой темы.
                                0
                                Как основной тоже можно и даже нужно, но тогда, когда речь идёт не о дискретных данных (принять сообщение, положить в базу, посчитать статистику...), а о потоках данных (пропустить радиосигнал через фильтр, вычесть модулирующий, пропустить через дешифратор...). Всё это можно и кодом, но гораздо менее наглядно и, вследствие этого, с бОльшей вероятностью ошибки.
                          0
                          что характерно, 1С изначально позиционировался как low code platform, на которой бухгалтера сами будут писать учёт.
                            +1
                            Ну SQL тоже так в свое время позиционировался, как тут в комментариях уже отмечали. Впрочем уровень абстрагирования он повысил, так что честь ему и хвала за это. Без SQL многие вещи делались бы куда сложнее и дольше.
                              +1
                              Ну надо уточнять, что платформа 1С так позиционировалась до 7 версии. С выходом 7ой (и уж тем более 8ой) версии, разговоры про «бухгалтера сами» закончились.
                              А те редкие бухи, которые умудряются до сих пор работать на 1С 6, так сами и настраивают печатные формочки и проводки.
                              +1
                              Блин, ох уж этот merge. Вот приходишь ты на работу после отпуска, например. Спрашиваешь, «как тут дела», и коллеги тебе говорят — мы тут в твоем компоненте (который типа диаграмма со стрелочками) пофиксили один небольшой баг. И единственный вменяемый способ узнать, что именно поменяли — это экспортировать проект в XML (компонент нельзя), и поиском найти там компонент, а потом сделать diff, где будет куча мусора, потому что квадратики еще подвигали немного, или раскрасили в другой цвет — на работу это не влияет, а вот мусор в диффе создает еще какой. Про привязку этих изменений к Jira вообще речь не заходит.
                              +2
                              О да, открываешь настройки этих Low Code систем и видишь такое:
                              Configuration UI


                              И это называется Fast configuring new data structure!
                                +2
                                Например, Spring Framework — самая популярная open-source технология для создания корпоративного ПО, которая отлично сочетается с веб-фреймворками вроде React или Angular.

                                Какая вообще разница фронтенду, что там на бэкенде крутится: Spring, ASP.NET, Django, Symfony, Rails или что-либо ещё?

                                  0
                                  Никакой в общем-то. Это один из примеров.
                                  0
                                  даже простые пользователи смогут самостоятельно создавать бизнес-приложения

                                  Напоминает SQL. А в итоге получим ещё один тип вакансий на рынке для разработчиков.

                                    +2

                                    Только SQL в конечном счёте более-менее пришёл к общему знаменателю (разумеется, специфические возможности СУБД остались), а вот Low code — типичный вендор-лок.

                                      0
                                      Не о вендор-локе речь, а о том, что SQL предназначался для менеджеров и бизнесменов.
                                    0
                                    Есть множество задач, которые надо выполнять регулярно, но с частотой до 10 раз в день, например. И вот тут похожие решения вполне имеют право на жизнь.
                                    Другое дело, что правильнее выбрать что то из open source BPMN. Хоть и похоже во многом, но BPMN — это стандарт.
                                    То есть запилили по сути прототип (сильно неоптимальный), но так как задача хоть и регулярная, но нагрузки не создает — переписывать просто не целесообразно.
                                    Я, например, точно знаю, что большая часть моих отчетов на SQL не оптимизирована. Но я и не собираюсь тратить время на их оптимизацию. Сейчас, например, делаю отчет. Его будут запускать несколько раз в год. И ВСЕМ вообще без разницы, отработает он за 5 секунд или за 50 секунд.
                                      0

                                      самый лучший вариант я так понял это собирать на этих схемах часто меняющуюся бизнес логику. интересно, есть такой инструмент для .net который можно было бы использовать в проектах на c#?

                                        0

                                        Windows Workflow Foundation

                                        0
                                        Все это нужно и неплохо продается для корпоративного ПО. Т.е. вы в принципе правильно заметили что 3-10 толковых людей способны сделать то-же самое гораздо эффективнее, но тут наверное надо сделать оговорку — если они имеют доступ ко всем компонентам системы. А если это не так, то тут начинаются и проблемы
                                        Из примеров которые встречал недавно в больших компаниях:
                                        1 — покупка нового обычного двух-процессорного сервера(около 20к-30k на сайте Dell) — оценка бюджета 0.5млн$. На вопрос — откуда такая цифра — нужны резервы, спец по по управлению, места в стойке, услуги по настройке, лицензии на управляющий софт и т.д
                                        2 — развертывание новой версии системы с 1 новой фукнцией — несколько месяцев работы
                                        3 — Разработка нового сайта для управления партнерами(их несколько тысяч, до этого управление велось в Excel — по сути одна таблица) — около 1 млн$, почему так много — нужно привлекать несколько комманд — железо, безопастность, юристов и т.д. для каждой будет менеджер проектов, наверху координатор все координировать
                                        4 — добавление поля в таблицу на SQL — около недели работы(несколько уровней согласования, оформление заявки для внешней фирмы и т.д.)
                                        Т.е. в этих то случаях используя Low code платформы пользовать сам может сделать то что нужно за гораздо меньший бюджет(это называется citizen developer), сейчас этот рынок растет довольно сильно
                                          0
                                          Т.е. в этих то случаях используя Low code платформы пользовать сам может сделать то что нужно за гораздо меньший бюджет(это называется citizen developer)

                                          Это каким образом он это сделает, если у него доступа нет? Ново купленный сервер сам собой настроится, если кнопочку в системе нажать? Я вообще не уловил связь ваших примеров и Low code.
                                            0
                                            Ну продают это так что пользователь может сам набросать нужный ему функционал. К примеру сделать форму ввода для каких-нибудь данных, получая данные с других систем, прописать какие-то триггеры в системах.
                                            Но факт что сейчас это топ. К примеру с последних конференций Microsoft показывают истории про механика который сделал PowerApp(это low code от Microsoft) который позволяет с телефона отправлять сканы повреждений машины, данные о клиенте и их оценивать
                                          +1
                                          Не совсем согласен с противопоставлением в статье Low-code платформ и фреймворки/платформы для разработчиков.
                                          На мой взгляд, low-code это просто следующий шаг развития макросов для электронных таблиц/правил сортировки писем в ящике/CMS-систем/разнообразных конструкторов опросов в интернете (я даже не буду пытаться перечислить все разнообразные сервисы вроде IFTTT). Еще одна зверушка в зоопарке костылей и велосипедов, уже доступных и привычных пользователям.
                                          И да, на долгой дистанции и хотя бы среднем бизнесе (при наличии команды разработки или денег на ее найм) использовать такое решение будет крайне глупо. Но из этих инструментов пользователи реально могут собирать несложные решения для своих процессов не привлекая к этому разработчиков.

                                          P.S. если уж на то пошло, то иногда покупая «сложное готовое решение, на профессиональном фреймворке», компания оказывается владельцем вот такого же набора костылей, но уже «собранного командой профессионалов» и за совершенно другие деньги =)
                                            +1
                                            Посмотрите маркетинговые материалы low code платформ. Их как раз противопоставляют фреймворкам. Года 2-3 назад на голубом глазу говорили, что разработчики больше не нужны. Сейчас поаккуратнее, но посыл тот же.
                                            И да, продают их практически исключительно крупному бизнесу. Для остальных стоимость запредельная. Если память не изменяет мне, бОльшая часть клиентов Mendix платит более $1M в год.
                                            А ценность для крупного бизнеса именно в обходе того бардака, который описал DenisTrunin выше. Поэтому и продают их не ИТшникам, а бизнесу.
                                              0
                                              Посмотрите маркетинговые материалы low code платформ. Их как раз противопоставляют фреймворкам

                                              Сужу по тем материалам, что я видел, но тот же MS Power Apps описывается как «пользователь сможет легко сделать то, что раньше мог сделать только разработчик» и «разработчик может сэкономить свое время и расширить возможности платформы». Не сказать что наглая ложь, хотя понятно что с оговорками.
                                              Но вообще, противопоставление не совсем фреймворкам. А «low-code самостоятельно VS. spring + разработчик» или «low-code сегодня VS. изучать JAVA и более крутое решение завтра». Т.е. упор на «просто», «быстро» (без «дешево» и «качественно»).

                                              Для остальных стоимость запредельная

                                              Глянул стоимость Mendix — 2000 у.е. на пользователя в месяц, это конечно мощно. Но не у всех такие ценники, есть и вполне демократические.

                                              Про то, что разработчики не нужны так вообще годами рассказывают. С другой стороны — модная тема была пару-тройку лет назад, про «программирование — вторая грамотность». Вот такие платформы как раз на эту идею хорошо ложатся.
                                                0
                                                Не, прайс все-таки помягче. Примерно $100 за юзера в месяц. То есть начинается от $1850 за 50 юзеров, но это версия с ограничениями. И вот плюс минус такие цены как раз у всех. Зато для разработчиков бесплатно ))
                                                +1
                                                >А ценность для крупного бизнеса именно в обходе того бардака
                                                Дело в том, что бардак — он зачастую возникает не просто так. Люблю я очень одну историю, как я был разработчиком интеграционной шины.

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

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

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

                                                Мораль — иногда реализация это полная фигня, 5 строк кода, а вот понять, что именно нужно сделать, чтобы пять или шесть систем продолжали бы совместно работать — это гораздо сложнее.
                                                  0
                                                  И занимались они этим пару месяцев. И полчаса на правки кода. И с первого раза не получилось.

                                                  Присутствовал на совещании, где представители двух команд разработки (одна внутренняя, вторая — аутсорсеры) решали кто должен к пересылаемым между двумя системами данным применять метод String.Trim. Все были очень серьезны, фиксировали все договоренности на бумаге и т.д.
                                                  А пользователь бы это реализовал за 5 минут. Так что тут как в анекдоте — «случаи бывают разные».
                                                    0
                                                    Разные — да, бывают. Но однако бардак (на мой взгляд минимум) более типичен для случаев, когда бизнес большой и старый, и много разных систем, в том числе написанных очень давно, и не гибких даже по отдельности. И одной только гибкостью он не лечится.
                                                      0
                                                      И вот на этом благодатном поле взошел еще один цветок… RPA :) Но это уже другая история!
                                              +12
                                              Менеджеры: Нам нужно по быстрому набросать прототип гуя.
                                              Разработчик: Технологии, фреймворки?
                                              Менеджеры: %tech_name%, модный, современный, руководство одобрило.
                                              Разработчик: Это пойдет в прод?
                                              Менеджеры: Ни в коем случае, только демо/черновик. Побыстрее.
                                              * Разработчик заглядывает в контракт в поиске условий увольнения без привязанности к отзывам пользователей, находит
                                              Разработчик: Хорошо, вот сроки.

                                              Менеджеры: Демо понравилось, давай в прод.
                                              Разработчик: Это черновик. Он медленный и неподдерживаемый. Надо переписать.
                                              Менеджеры: Некогда. Оно работает? Работает. В прод.
                                              * Разработчик открывает линкедын.
                                              Разработчик: Да на здоровье.

                                              Менеджеры: Пользователи жалуются на приложение. Оно тормозит и жрет ресурсы.
                                              Разработчик: Я предупреждал. Переписать нахрен.
                                              Менеджеры: Некогда. Уже в проде, нужен саппорт того, что есть.
                                              * Разработчик увольняется.
                                                +1
                                                Жизненно! :)
                                                +2
                                                Магия…
                                                два часа назад у меня было собеседование (по телефону) на должность Solutions Architect (Presale) в Mendix… а тут бах — статья :D

                                                К моему сожалению, эти стрелочки очень нравятся уровню Си и они диктуют — смотри, готовое решение, сейчас возьмём, накликаем и готово… а тут команда будет пахать полгода… лучше 100.000 € заплатим.

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

                                                В итоге разрабы в шоке, продакт оунер заткнулся.
                                                Profit.
                                                  0
                                                  В какой стране была вакансия если не секрет? Согласились? :)
                                                    0
                                                    Германия, к сожалению (наверное) нет, т.к. 60% и более времени в разъездах… а у меня семья.
                                                      +1
                                                      Я думаю, что не стоит об этом жалеть. Врядли вы гордились бы тем, что продаете, а это важно и для продаж и просто для самоуважения.
                                                  +1
                                                  Это все уже пройдено по сто пятьдесять тысяч раз по кругу. Еще в конце девяностых носились с RUP, когда идеалом было — программировать мышкой. Но реальность оказалась сложнее.
                                                  Радует что не оставляют попытки упростить процесс разработки, но к сожалению это все еще слишком слабо формализованный процесс, чтобы можно было его «втискивать» в подобные инструменты.
                                                    0
                                                    Borland с ее Delphi сделала много для упрощения. Но почила в бозе не в последнюю очередь из-за копеечной, казалось бы, цены инструмента порядка $1000. Оказалось, что чем вкладываться в рабочее место, все равно дешевле нанять толпу, которая будет кодить в блокноте. Даже MS не могла это побороть и выкатила Express студию да опенсурсный неткорь. Бабло победило простоту.
                                                      +4
                                                      История Delphi немного сложнее. Borland был знатно раскулачен Microsoft, который перекупил костяк компании для разраотки Visual Studio, что в итоге привело к первой юзабельной версии. После этого Delphi стагнировал много лет, и пропустил вспышку web-а. Когда все улетело в интернеты и браузеры Delphi совсем и угас.
                                                    0
                                                    Стоимость лицензии на одно приложение начинается от $1875 в месяц при условии подписки на три года

                                                    Не то чтобы очередь выстроится, но желающих поработать программистов будет достаточно. Мы находим и на $1500. Это при том что неквалифицированному сотруднику за работу с системой тоже придется платить хотя бы $1000, итого $2800 в месяц, а за такой ценник уже и очередь настоящих программистов подвалит: ) За $100 в месяц конечно шикарная была бы идея.
                                                      0
                                                      Лицензирование привязано к пользователям, не разработчикам. $1850 это минимум за 50 юзеров в месяц.
                                                        0
                                                        Это тоже дороговато, но в принципе нормальная цена. Зарегился, прошел туториал. Решение как понял целиком облачное. Когда платформа накроется медным тазом, все нажитое пропадет. За такие деньги сомнительное удовольствие. Но красиво.
                                                      0
                                                      Поверьте, все не так однозначно, я сама дочь офицера!(с) тоже Low Code developer!

                                                      Я понимаю и разделяю боль автора статьи, но, IMHO, тут слишком много обобщений. Во-первых, в статье, о которой идет речь, говориться именно об Enterprise Low-Code Application Platforms, и лидером называют Microsoft PowerApps. Mendix вполне себе известный игрок, но явно не дотягивает ни до Microsoft, ни до SalesForce. Делать выводы об ущербности Low-Code по факапам одного игрока, даже известного игрока, даже по эпичным факапам — не очень корректно.

                                                      Для Low Code есть своя ниша. Да, она довольно узкая и специфичная. И в ней использование этих платформ (по крайней мере тех, о которых я могу судить — PowerApps, SalesForce, FileMaker) себя прекрасно оправдывает. И конечно не стоит доверять на слово маркетологам и продавцам о том, что это серебрянная пуля, которая решает все проблемы — а что, им когда-то вообще можно было доверять?
                                                        0
                                                        Ради справедливости, про лидерство Microsoft PowerApps утверждает не автор, а Gartner — знатные булшитеры и трендмейкеры в одном лице.

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

                                                          Так это вопрос к продавцам и к тем, кто им верит, а не реальным best practices. Спору нет, маркетинг-булшит абсолютное зло — но это касается чуть ли не любой современной технологии программирования… Да и вообще технологии.

                                                            0
                                                            И да и нет. Одно дело — подход open source, когда продукт берут, потому что он хороший. И берут его не менеджеры, а инженеры. В этом случае нет смысла вбивать технологии в глотки менеджерья. Если продуктом трудно заинтересовать инженеров, нужно идти выше и рассказывать сказки. Так что это не только «вопрос к продавцам».
                                                          +1
                                                          Gartner утвердает что Mendix — лидер, смотрите картинку с «магическим квадратом» вначале статьи. Конечно, LCAP разные. SalesForce в первую очередь вообще про расширение CRM и других их продуктов, а не про разработку с нуля. А вот OutSystems похож на Mendix. Конечно, у них есть своя ниша — те же прототипы. Но совсем не та, где их позиционируют.
                                                            0

                                                            Я не только картинку посмотрел, но и оригинал статьи нашел. Там черным по английскому рассказывается о том, насколько круты MS с их PowerApps и почему по их мнению это лидер. Про Mendix там вообще ни слова, только на картинке и есть.

                                                              0
                                                              А скиньте ссылку на оригинал пожалуйста.
                                                          +2
                                                          Маркетологи изобрели велосипед ДРАКОН?
                                                          image
                                                            0
                                                            Идея low-code имеет право на жизнь.
                                                            Другое дело — реализация. В современных продуктах я не встречал красивых реализаций.
                                                            В 90-е был язык Clarion (сейчас сильно сдулся).
                                                            В нем раздельная схема базы и UI, визуальная настройка массы пропертей UI, шустрый компилятор, а также развитый язык шаблонов кодогенерации.
                                                            Значительно ускорял разработку. Позволял небольшим командам вести массу продуктов.
                                                              0
                                                              ну если вспомнить наш Дракон — то можно и в космос слетать на таком
                                                                0
                                                                У меня лично вполне себе положительный опыт работы с low-code фреймворками.

                                                                Я лично писал на DevExpress XAF, и он прекрасно подходит для внутренних проектов. Да не очень шустрый, но там из коробки есть и авторизации/аутентификации, аудит, разграничение прав, всякие отчетики, дэшбордики. На нем можно буквально за неделю сделать приемлимую CRM.

                                                                (И таки нет, я на них не работаю смайл)
                                                                  +2
                                                                  DevExpress это все-таки в сторону RAD, а не Low Code. То есть — готовые компоненты и инструменты быстрой разработки, но логику вы пишете в коде. Эта концепция применима гораздо шире, чем low/no code которые претендуют на создание приложений вообще без программирования.
                                                                    0
                                                                    Вы правы, однако логику в DevExpress можно на очень глубоком уровне описывать в Model Editorе и классами с аттрибутами. Я абсолютно уверен, что можно написать средней руки CRM не написав ни строчки кода, лишь описав классы и их связи.
                                                                    Да, Visual Studio понадобиться, да человек должен будет понимать, что такое программирование, но скорость разработки в разы выше, чем у программирования блок схемами. Благо, без кода все-равно ни там, ни там не обойдется.
                                                                  –2
                                                                  Отличный вброс. Особенно с учётом того, что вы работаете в компании, которая занимается заказной разработкой корпоративных систем и конкурирует с Low-code платформами. Я не пользовался Mendix и, возможно, там и правда всё так плохо. Да, у большинства Low-code платформ нотация моделирования бизнес-процессов далека от стандарта BPMN, и их схема процессов изобилуют техническими элементами (интеграции, элементы работы с формами и данными и т.д.), которые бизнес прочитать не в состоянии – ваш скриншот отличный тому пример. Я работаю в Comindware и вставлю свои пять копеек с отсылкой на нашу Low-code платформу — www.comindware.com/ru/platform. В платформе Comindware используется нотация BPMN 2.0, так что бизнес-процессы прозрачны и читаемы. Толковый бизнес-аналитик строит модель бизнес-процесса, создаёт прототип бизнес-приложения, проверяет прототип на пользователях и (да!) отдаёт на доработку программистам. Не возможно обойтись без программирования, но напряг программистов можно и нужно сократить. Вы говорите «написать 10 строк кода в хорошей IDE, чем перетаскивать, настраивать и соединять десятки блоков» — а зачем у вас программист пользуется инструментом, созданным для бизнес-аналитиков? Бизнес-аналитик, который знает BPMN, запросто соберёт бизнес-процесс и, кроме того, толковый бизнес-аналитик знает, что нормальный бизнес-процесс не должен состоять из десятков блоков – сложные процессы разбиваются на подпроцессы и вся картина остаётся наглядной. Кроме того, если у Low-code платформы есть API, то никто не мешает при необходимости накодить внешние функции и обращаться к ним из блоков диаграммы. У нас ещё в самой платформе можно скрипты добавлять «на раз два». Итого, не нужно Low-code платформой заменять фреймворки/платформы для разработчиков, используйте её по назначению всё будет отлично.
                                                                    +2
                                                                    Так напишите статью, в которой разъясните, в чем конкретно заблуждается автор, и как классно строить приложения с использованием Low-code платформ. В частности, как вы решаете проблемы с системами контроля версий. Многим будет интересно, я думаю.
                                                                      0
                                                                      %username%, чукча не писатель. Передал тем кто может сделать.
                                                                      0
                                                                      Ваш сайт встречает разработчиков вот таким пассажем:
                                                                      Дополнительная информация о Comindware Business Application Platform доступна по запросу

                                                                      Минуточку, а где же ваша документация? Или это кот в мешке?
                                                                        –1
                                                                        Сайт делают маркетологи и, наверное, так у них конверстится лучше. Меня лично тоже бесит отсутствие прайсинга и документации на продуктовых сайтах. Ссылки на какую-то нашу документацию всё же можно найти тут в блоке «Размещение и лицензирование» – www.comindware.com/ru/platform остальное уже отдают сейлзы после запроса.
                                                                      +1
                                                                      Я ждал подобный комментарий )) Начну с того, что мы не конкурируем с Low Code платформами. Системы, которые мы делаем, просто невозможно сделать на известных мне LCAP. Далее, сразу оговорюсь что не использовал Comindware и что-то не вижу на сайте даже возможность попробовать. Стесняетесь? Mendix, Outsystems, Bizagi и другие честнее в этом.

                                                                      Продираясь через маркетинговые перлы на вашем сайте, осмелюсь предположить, что ваша платформа – это классическая BPMS плюс набор готовых решений, и вы видимо сознательно пытаетесь «примазаться» к хайповой теме low code. Я понимаю, когда это делают маркетологи, но не на хабре же!

                                                                      У BPMS есть своя понятная ниша. Но статья же про другой класс систем. Даже больше, статья как раз о том, что не надо вестись на маркетинговый bullshit про «в 4 раза быстрее» и «идеальный фундамент для цифровой трансформации предприятия». Надо понимать, что применимость и гибкость подобных инструментов крайне ограничена. Ни на BPMS, ни на Low Code платформе невозможно построить не то что ERP, даже простую удобную CRM типа AmoCRM.

                                                                      И последнее, у вас на сайте говорится, что разработчику достаточно реализовать 10-20% системы, остальное все аналитики мышкой накликают. Это прекрасно. А вот расскажите теперь как именно это делается? Какой язык, среда, где точки входа, как организован контроль версий? А то ведь какой сюрприз – на сайте ни документации, ни примеров.

                                                                        +1
                                                                        Согласен.

                                                                        Как же меня бесят SaaS решения, на сайте которых нет ни простейших демо, ни даже цен. Всё это является всего лишь попыткой срубить бабла. Напишет Вася Пупкин — мы ему за 100 баксов продадим. Напишет человек из крупной фирмы — мы ему вломим за это же самое решение сто тысяч.

                                                                        Стыдно такими быть. Увольте нафиг всех сейлзов, сделайте вменяемую ценовую политику, покажите демо — и я уверен, клиентов будет только больше.
                                                                          0
                                                                          Ну строго говоря на сайте SAP (лицензий) или условного EPAM (человеко-часов) цен тоже нет. Все же сложные бизнес-решения это не семечки продавать, там дикое количество неизвестных параметров.

                                                                          Хотя с отсутствием демо, детальных примеров и вариантов использования согласен. Обычно это показатель маркетинг булшита максимального уровня.
                                                                            +1
                                                                            Строго говоря, SAP (ну по крайней мере еще недавно) не был SaaS платформой. Равно как и EPAM. Ну и да, то что у SAP нет цен лишь говорит, что как компания SAP фиговенькая.
                                                                            Вот захожу на www.atlassian.com/ru/software/jira/pricing
                                                                            и вижу сайт здоровой компании. И демо доступ без рабочего емейла и автоматом дают.

                                                                            А вот это сайт раковой компании
                                                                            www.comindware.com/ru/company/contact-us/?product=platform&form=getaquote

                                                                            Цен нет, демо тоже нет (только после обработки сейлзов)
                                                                              0
                                                                              Ну я захожу на сайт боинга или ibm'а и тоже не вижу там прайсов.

                                                                              Все же некорректно сравнивать полусервисные компании (где сервис являются важной неотъемлемой частью продукта) с компаниями продающими коробочные решения, в стиле «ешьте что дают». Безотносительно от того какой подход из них правильный (если так вообще можно говорить).
                                                                                +1
                                                                                Вот тут тоже полуправда.
                                                                                Цены на Боинги весьма известная величина. Да, их нет на сайте, потому что у них там нет калькулятора, а цена сильно зависит от комплектации. Но даже гугл знает ответ в вакууме:
                                                                                Boeing 737 Next Generation 737-600/-700/-800/-900
                                                                                Unit cost (2019 US$ million) -700: $89.1; -800: $106.1; -900ER: $112.6

                                                                                А что касается IBM, то тут все очень плохо. По уровню донности IBM и SAP находятся на самом дне вместе. Дорого, плохо, медлено. Зато откаты платят исправно. За что и любят.
                                                                                  0
                                                                                  Просто на сайте компании, в которой работает NitroJunkie тоже цен нет (но какая-то демка есть), вот он и обижается на «донность» и «раковость».
                                                                                    0
                                                                                    Ну если IBM и SAP — «донные» компании чего обижаться то. Человек реально думает что их покупают только за откаты. И видимо не совсем понимает как этот рынок вообще работает.

                                                                                    Ну и у Боинга тоже нет цен. А среднюю температуру по больнице и для компании, в которой я работаю тоже несложно найти. Хотя конкретно то над чем я работаю вообще бесплатно. Так что тут я согласен с euroUK :)

                                                                                    И это не говоря уже о том, что у тех же авиакомпаний, цена за одни и те же места (!) может в несколько раз поменяться в течении пары дней. И это не говоря про бизнес-класс и всякие мили за которые его можно купить. Ну и все тоже самое также касается например отелей и тонны других рынков.
                                                                                      +1
                                                                                      Я в отрасли с 2006 года, видел на своем веку и SAP и IBM. Я не отрицаю, что в свое время компании были пионерами отрасли и крутыми. Но уже давно, продукцию этих компаний покупают по трем причинам:
                                                                                      1) Чтобы снять с себя ответственность или из-за лени (еще никого не уволили за то, что он купил IBM)
                                                                                      2) Потому что откаты с миллиарда больше, чем откаты с 20 миллионов.
                                                                                      3) 20летнее легаси

                                                                                      Других причин покупать в 2020х годах решения типа SAP просто нет, никакой экономической выгоды чтобы окупиться они просто не принесут.
                                                                                        0
                                                                                        Я тоже в отрасли очень давно (с года так 2000). И там много причин почему его покупают, и откаты лишь одна из возможных, хотя и не основная (так как решение такого масштаба как правило принимает собственник, а откат ему давать бесполезно).

                                                                                        Но все же справедливости ради нужно отметить, что для сложных бизнес-приложений сильно лучших альтернатив САПу в принципе то и нет. С точки зрения платформы ничего радикально лучшего не придумали (у САП свой высокоуровневый DSL довольно неплохо подходящий для конвеерной разработки бизнес-логики, как его называют сами саперы «Foxpro на стероидах»), а за долгие годы существования накоплено много готовых решений и опыта, пусть и не всегда удачного.

                                                                                        То есть я не спорю что «говно мамонта», все дела. Но что по вашему сильно лучше? Сложное бизнес-решение на Node.Js или Java Spring? Я вас умоляю. Delphi + Oracle / PostgreSQL. Такое же говно мамонта. .Net или надстройки над Python (аля Odoo)? Ну да местами лучше, местами хуже (все же с DSL в многих местах тяжело соревноваться), но даже никакого x2 (не говоря уже о x10) нет. Местные игроки аля 1С? У них своих скелетов еще больше чем у SAP.

                                                                                        А в плане готовых решений они все уступают SAP и часто значительно (это во многих случаях признают даже те кто в конечном итоге выбирают не SAP'кие решения).
                                                                                          0
                                                                                          Я лично не видел, чтобы в компаниях самих бы САП допиливали. Сколько видел — это были сплошь SAP интеграторы. У которых 1 мэндэй стоит столько же, сколько у пяти 1Cников.
                                                                                          При этом, в тех компаниях где я видел SAP, он не использовался и на 10%.
                                                                                          Также не стоит забывать сколько стоит железо, чтобы SAP хоть как-то работал и мы посчитаем, что любое решение, включая самописное, будет дешевле и быстрее.

                                                                                          Что касается стэка, мне сложно что-то говорить как шарписту, но мое ИМХО .netcore3 + EFCore + PostgreSQL меня удовлетворяют на 100% по скорости разработки, развертывания и работы.
                                                                                            0
                                                                                            Я если честно вообще не понимаю смысла допиливать в компании что-то своими силами. Это глупо по огромному количеству причин, начиная от того что компании приходится обладать компетенциями (в том числе по найму) в непрофильном для нее бизнесе (все равно что если бы ИТ-компания наоборот держала в штате бы электриков, строителей и сантехников) и заканчивая, тем что многие проекты имеют волнообразную нагрузку, то есть в активной фазе нужно в 5 раз больше людей, чем в пассивной.
                                                                                            При этом, в тех компаниях где я видел SAP, он не использовался и на 10%.

                                                                                            Компании разные бывают и процент фейлов в крупных компаниях аля SAP у большинства его конкурентов не меньший.
                                                                                            Что касается стэка, мне сложно что-то говорить как шарписту, но мое ИМХО .netcore3 + EFCore + PostgreSQL меня удовлетворяют на 100% по скорости разработки, развертывания и работы.

                                                                                            Ну если вам нужно будет разрабатывать очень сложные по функционалу приложения (далеко уходящие от CRUD и простых ORM), то эта связка даже SAP с его ABAP не обгонит. Не говоря о том, что у SAP уже готового кода вагон и маленькая тележка.
                                                                                              +1
                                                                                              А я, если честно, не понимаю зачем компаниям нанимать сторонних интеграторов по следующим причинам:
                                                                                              1) Отсутствие компетенций в написании ТЗ приводит к тому, что компания заказчик заплатит два или три раза, прежде чем результат хоть как-то будет походить на требуемый.
                                                                                              2) Заказчик будет платить джунам по цене синьоров (у него же нет компетенций чтобы оценивать уровень владения инструментом). Я видел такое у всех крупных интеграторов.
                                                                                              3) Без четкого понимания, заказчик будет платить за то, как интегратору удобнее реализовывать систему (были на тот момент команды на Go без работы — будет у клиента на Go)
                                                                                              4) Интегратор сделает все возможное, чтобы заказчик не слез с иглы, даже на другого интегратора. Даже если у SAP готового кода вагон — то интегратор сделает свою версию
                                                                                              5) Программист в штате может решать и другие задачи, коих в компаниях и со 100 сотрудниками может быть тьма. Если для них нет задач, то компании пойдет любое коробочное решение, а не интегратор.
                                                                                              6) Не стоит забывать, что SAP не может ничего зафейлить, так как он ничего не продает лично. А его вендеры и фейлят, и сроки срывают легко и просто.

                                                                                              Ну и что касается сложных приложений. Любое мое приложение, на любом объеме данных будет работать в разы быстрее, чем SAP. Потому что я делаю схемы БД и бизнес логику под задачи, а не обмазываюсь 15 уровнями абстракции фреймворков разного уровня. (И да, я работал через netcore3 + EFCore + MS SQL с десятками миллиардов записей)
                                                                                              0
                                                                                              Я лично не видел, чтобы в компаниях самих бы САП допиливали.

                                                                                              Альфа-Банк. Просто по причине жадности интеграторов.

                                                                                            0
                                                                                            Еще SAP покупают, чтобы увеличить капитализацию компании. Инвесторы точно также покупаются на рекламу типа «Best runs SAP». Соответственно, работает логическая цепочка: «Best runs SAP» => компания — best => стоимость компании выше.
                                                                              +1
                                                                              А сейчас производители BPMS тоже любят называть себя Low Code платформами — хайп и маркетинг. :)
                                                                              Вот пример:
                                                                              ELMA4: новая low-code платформа для быстрого построения корпоративных приложений

                                                                              С моей точки зрения, между этими терминами (BPMS and Low Code) разницы особой нет. Но, наверно, потому, что если в Low Code нет BPMN — то покупать такой «чемодан без ручки» будет разве что «эффективный менеджер». По крайней мере я так считаю. :)

                                                                              Ну и, разумеется, крайне глупо на таких инструментах пытаться реализовать ERP, CRM или просто калькулятор.
                                                                                –1
                                                                                Всё таки конкурируете: у клиента один бюджет и отнесёт он его либо вам, либо вендору Low-code, либо вендору «коробки». Low-code как концепция – это решение для бизнеса, который как раз хочет минимизировать зависимость от вендора. В случае заказной разработки, как мы все знаем, это та ещё «игла», подсев на которую клиент постоянно платит разработчику за доработку и новый функционал, причём по рейту, который устанавливает исполнитель, и получая результат в сроки, устанавливаемые тем же самым исполнителем. Про «простые удобные CRM-коробки» хочу отметить, что если бы они действительно подходили компаниям, то их бы не появлялось на рынке как грибов после дождя, а вокруг Salesforce не сформировалась бы целая индустрия доработок, модулей и т.д. По поводу невозможно построить ERP|CRM, на сколько мне известно на нашей платформе делали и то и то, причем довольно сложное и удобное, под что не возможно найти решения на рынке. По поводу языка и контроля версий это C# и GIT. Напишите в личку, если интересно поговорить или потыкаться в триалке нашей платформы – организую.
                                                                                  0
                                                                                  Low-code как концепция – это решение для бизнеса, который как раз хочет минимизировать зависимость от вендора.
                                                                                  — простите, но это очень смешно. У вас нет лицензионных платежей? Решение на Comindware можно мигрировать на другую платформу?

                                                                                  По поводу невозможно построить ERP|CRM, на сколько мне известно на нашей платформе делали и то и то, причем довольно сложное и удобное
                                                                                  — пруфов не видно. Но даже допустим. И какое там соотношение между кликами мышками и кодом на C#? Я на 146% уверен, что в таком случае это «каша из топора».

                                                                                  потыкаться в триалке нашей платформы
                                                                                  — спасибо за предложение, но тратить время на изучение малораспространенного закрытого продукта не готов. Я не так давно довольно много времени потратил на изучение известных представителей мира Low Code (Mendix) и BPMS (Bizagi), собственно часть выводов отражена в статье.

                                                                                  В случае заказной разработки, как мы все знаем, это та ещё «игла»
                                                                                  — От такого поворота даже я ох… нел (с)

                                                                                  Впрочем, в полемику custom dev vs product vs platform dev я не буду вступать. Наша компания работает по всем трем моделям. Мы (компания Haulmont) создатели как довольно популярной RAD платформы с открытым кодом (CUBA Platform), так и продуктов (Тезис ECM), а также занимаемся заказной разработкой. Поверьте, я прекрасно знаю особенности и применимость каждого из сценариев.
                                                                                    0
                                                                                    Всё таки конкурируете: у клиента один бюджет и отнесёт он его либо вам, либо вендору Low-code, либо вендору «коробки».


                                                                                    Да, гвозди так же с конкурируют с саморезами, а мясо с овощами.
                                                                                  0
                                                                                  Что такое Low Code? Это когда с помощью графических элементов описываешь некий алгоритм.

                                                                                  Насколько я знаю, единственный широко распространенный стандарт, описывающий набор графических символов, «программу» из которых можно запустить на исполнение — это BPMN. Более того, этот стандарт существует уже довольно много лет. Следовательно, системы, в которых нет BPMN или которые обещают, что программисты не понадобятся (на BPMN, чтобы заработало, все равно надо писать программу))) — просто очередной вариант «сравнительно честного способа отъема денег».
                                                                                  Остапов Бендеров во все времена хватало. :)))
                                                                                    +1
                                                                                    На самом деле это не совсем верно. Low code — это совокупность средств для разработки без использования кода. Это и деплоймент, и визуальная разработка интерфейсов, и визуальная разработка логики, в общем случае не важно на базе какого стандарта. Кстати, microflows в Mendix основаны как раз на BPMN. Отличие Mendix от BPMS — в том что эта платформа предназначена для разработки произвольных приложений, а не только крутящихся вокруг процессов. Здесь BPMN используется для описания элементов логики (например, загрузить определенных данные и открыть форму при нажатии на кнопку), а не для описания «долгоиграющего» процесса. Соответственно, они предоставляют кучу специализированных стенсилов (типов узлов) и настроек для решения задач, обычно решающихся в коде.

                                                                                    То есть стандарт один, но используется он совершенно по-разному.
                                                                                      0
                                                                                      Можно переформулировать:
                                                                                      «Low code — это совокупность средств для разработки с использованием графических элементов. Это и деплоймент, и визуальная разработка интерфейсов, и визуальная разработка логики.»

                                                                                      То есть первое, что надо понимать — код мы все равно пишем. В виде стрелочек и прямоугольников или в виде слов и цифр — но в любом случае пишем. Глупо думать, что человек без специальной подготовки сможет придумать и записать даже относительно простой алгоритм. И не важно, будет записываться алгоритм буквами или прямоугольниками.
                                                                                      Второе — очень желателен общепризнанный стандарт. То, что Mendix сделал microflows на основе BPMN — это как раз недостаток. В первых двух буквах BPMN четко указана направленность этого стандарта (Business Process Model and Notation), это не универсальный стандарт и сомневаюсь, что его использование в других сферах будет эффективно.
                                                                                      Третье — описывать некоторые (довольно многие) вещи с помощью графических элементов — неудобно.

                                                                                      Если суммировать — попытка сделать инструмент «для разработки произвольных приложений» с помощью только графических элементов, предназначенный для пользователей вообще без знаний или с очень минимальными знаниями в области программирования…
                                                                                      Это к Остапу Бендеру. :)))

                                                                                      Тот же BPMN пользователи с минимальной подготовкой могут понимать «в целом» — как это работает и находить ошибки в логике с точки зрения бизнеса. Но самостоятельно написать относительно сложный бизнес процесс — уже не могут. Нужна более серьезная подготовка. Как минимум несколько дней. И в любом случае многие «низкоуровневые» вещи нужно будет написать на обычном языке программирования (Java, Python...), иначе будет жесть.
                                                                                        0
                                                                                        Справедливости ради, в Mendix подняли уровень абстракции очень высоко, и _простые_ системы действительно может написать пользователь без особой подготовки. Они серьезно в это вложились. Продукт по-своему мощный и у него есть своя область применения — прототипы и простейшие системы. Проблемы начинаются, когда его пытаются натянуть на что-то более сложное.

                                                                                        P.S. В использовании BPMN в microflows ничего плохого не вижу.
                                                                                          +2
                                                                                          Я про другое пытаюсь сказать.
                                                                                          В принципе невозможно (по крайней мере сейчас, до изобретения сильного ИИ или чего то сопоставимого) создать программу любой сложности (даже самую простую) без того, чтобы придумать в голове и записать в каком либо понятном компьютеру виде алгоритм.
                                                                                          Те же макросы в Ексель — это тоже программа с кодом.

                                                                                          Пока алгоритм относительно простой — можно рассчитывать, что справится пользователь с минимальной подготовкой. Мы (люди) все немного программисты. :)
                                                                                          Но как только сложность алгоритма увеличивается — уже не важно, будут графические значки или английские слова — пользователь без подготовки его не реализует. Да, можно привести примеры, когда способный человек несколько недель (месяцев) сидел, разбирался и реализовал довольно сложную вещь. Но ведь это и есть обучение программированию! :)))

                                                                                          А BPMN — он в первую очередь про бизнес процессы. Разумеется, он относительно универсален, но использовать во всех задачах…
                                                                                          Для систем, которые не про бизнес процессы — нужно придумать свой язык и сделать стандартом. Пока этого не сделали — серьезно вкладываться в такие системы и хоть сколько нибудь серьезные задачи с их помощью решать — не целесообразно. Альтернативы есть (обычные языки программирования со своими стандартами).

                                                                                          А про свою область применения полностью согласен. Каждый инструмент должен использоваться в правильной (подходящей для него) области.
                                                                                          Я, например, специализируюсь на финансах. Любимый инструмент всех финансистов — Ексель. Кстати, считается, что его можно начинать использовать с минимальным обучением, что в целом правда. Для многих задач Ексель — прекрасный инструмент. Но как только его начинают использовать для неподходящих задач — сразу вылазит множество косяков, которые в рамках Екселя побороть невозможно. Ну не подходит он для очень многих задач.
                                                                                          Хотя ежики все равно продолжают плакать, колоться, но упорно есть кактус…
                                                                                    0
                                                                                    Итак, ориентируя продажи на топ-менеджеров, вендоры low code платформ обещают, что даже простые пользователи смогут самостоятельно создавать бизнес-приложения.
                                                                                    То есть разработчики больше не нужны?!

                                                                                    Возможно, что дело в конкретной нише и даже в конкретном вендоре, но я не вижу причин говорить о том, что Low-code это сплошной риск.
                                                                                    Про бизнес не знаю, но в области встраиваемых систем реального времени тот же Matlab/Simulink является low-code платформой, позволяющей создавать свои приложения для систем управления, без подключения программистов. При этом программистам, естественно, тоже отводится свое место, но уже не в качестве основных разработчиков функциональности, а в качестве системщиков. Про Дракон тут тоже упоминали.


                                                                                    Или вот сравнительно недавно я тоже занялся low code на Node Red по причине того, что мне захотелось сделать свою логику управления для умного дома, а вникать во всякие javascript мне просто не захотелось. Заметили, как похожа графика? Результат порадовал и сейчас серъезно задумываюсь над тем, чтобы использовать Node-Red в production в серьезном IoT-проекте. И да, я собираюсь подключить сторонних разработчиков к моему проекту, но потом большинство сопроводиловки вести своими ресурсами.

                                                                                      0
                                                                                      Вы совершенно правы. Речь о претензии на разработку корпоративного ПО (aka кровавый энтерпрайз). В то же время есть множество ниш где low code прекрасно работает.
                                                                                        0
                                                                                        В то же время есть множество ниш где low code прекрасно работает.

                                                                                        Чтобы немного конкретизировать — есть много ниш, где low code прекрасно заходит прямо здесь и сейчас. Т.е. меняет подход к разработке в настоящее время и во многом благодаря тому, что подтянулись соответствующие технологии, а люди достаточно обленились.


                                                                                        Возможно, в корпоративном ПО происходит та же ситуация, но вы просто неправильно выбрали момент или вендора?

                                                                                          +2
                                                                                          У меня на прошлой работе в Голландии человек писал приложения на PowerApps типа отпусков и больничных.

                                                                                          Судя по тому, как он плевался (мы сидели рядом) и сколько времени на это потратил, то я в свое удовольствие уже бы десяток сайтов на своем стэке бы сделал. Кода там было бы больше конечно, зато дешевле и быстрее.
                                                                                            0
                                                                                            Тут правда следует уточнить: он первый раз на PowerApps вообще что-то разрабатывал или нет? Все-таки важно сравнивать людей с одинаковым уровнем компетенции в соответствующей технологии.
                                                                                            0
                                                                                            Наиболее репрезентативных вендоров я изучал, выводы собственно в статье…
                                                                                        +2
                                                                                        Да, идея фикс «программирование без программистов» по-прежнему не дает покоя менеджерам.

                                                                                        Mendix сейчас активно продвигается здесь в Голландии (что не мудрено, поскольку он в Голландии и разработан) в крупных организациях — банки, министерства.

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

                                                                                        Эта идея, конечно не нова. Книга Джеймса Мартина «Applications Development Without Programmers» была издана еще в 1981 году.

                                                                                        Вспоминаются 90-е годы прошлого века, когда предшественники таких low-code платформ активно продвигались под лозунгами «Языки 4-го поколения», RAD (Rapid Application Development) и CASE (Computer-aided software engineering).

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

                                                                                        Я работал в 2013 году в одной финансовой компании, в которой 25% всего программного обеспечения было сделано на Uniface.

                                                                                        Один коллега тогда перешел с Uniface на C#, хотя и сильно потерял при этом в зарплате. По его словам, Uniface с точки зрения программиста — совершенно бесперспективная вещь. Язык программирования так и застрял в своем развитии в начале 90-х.

                                                                                        В финансовой компании хотят это все перевести на Java или .NET, но денег нет. Так и приходится все это поддерживать. При этом Uniface-разработчики стоят дороже .NET-разработчиков.

                                                                                        Кстати, в этой же компании еще 25% программ были созданы при помощи еще одной подобной системы — Blueriq (раньше она называлась Aquima). Ее разработчики использовали «революционную» идею о том, что данные должны храниться не в базе данных, а в одном большом XML-файле. Теперь тоже хотят от всего этого избавиться и тоже денег на это нет.

                                                                                        Но история никого ничему не учит, и вот у нас уже повсюду активно продвигаются Mendix и Betty Blocks — последний писк моды (еще одна голландская разработка).
                                                                                          –2
                                                                                          Стоило бы указать, что это перевод. Оригинал Low Code Platforms — a Dangerous Bet
                                                                                            0
                                                                                            Это не перевод. Это моя статья, опубликованная на двух языках и нескольких площадках. Причем Хабр был первый.

                                                                                          Only users with full accounts can post comments. Log in, please.