Комментарии 113
Послушайте, ну неужели на это кто-то покупается? Почитайте мой древний уже пост про BPMN, там почти все те же проблемы описаны, и они имеют место в полный рост. Совершенно та же фигня — пока мы прототипируем, рисовать картинки со стрелочками красиво и круто. Как только мы начинаем делать что-то реальное — мощности языка стрелочек перестает хватать, нам нужен второй/третий/пятый язык, и профессиональные разработчики на нем — потому что писать в виде стрелочек разработчики в жизни не могут, ибо у этого метода есть кучка недостатков, которые пока никто не преодолел.
Учитывая что это хорошо продаётся (обычно менеджерам старшего звена) крупным компаниям, то значит они на это ведутся.
Я видел одну такую компанию, по факту покупатель low-code платформы просто аутсорсит свой ит-штат на поставщика такой платформы (постоянные консультации и кастомные фичи по заказу). Так что даже в самом худшем случае кодеры никуда не денутся, посто они будут работать на эту платформу.
Я видел одну такую компанию, по факту покупатель low-code платформы просто аутсорсит свой ит-штат на поставщика такой платформы (постоянные консультации и кастомные фичи по заказу). Так что даже в самом худшем случае кодеры никуда не денутся, посто они будут работать на эту платформу.
К сожалению да, покупается. Особенно на западе. Пост обязательно почитаю, спасибо.
К сожалению, да. Работая по контракту в компании из первой пятёрки производителей электроники, я познакомился с Mendix, на основе которого, на полном серьёзе, писалась CRM + Workflow management. Источниками данных были агрегирующий сервер PowerBi и APIшка одного из корпоративных ресурсов. Как оно пролезло? Через менеджмент, купившийся на посулы LCP об экономии ресурсов на разработчиков. А благодаря строгой иерархии 99% сотрудников даже помыслить не могли о том, чтобы сказать хоть слово поперёк. В итоге получился забагованный кадавр, внедрение которого так и не было завершено.
Круто, реальный кейс! Это была западная компания насколько я понимаю?
Да. Я эту штуку пытался девопсить. Парадоксальная картина — отличное железо с хорошим «низкоуровневым» софтом, и полная дичь на уровне приложений и утилит. От некоторых решений я выглядел, как известный мем с куряшим Мэтью Макконахи.
Упомянутое ПО на Mendix должно было решать проблемы управления проектами для субподрядчиков. Как только появлялась необходимость выйти за рамки тривиального CRUDа, начинались танцы, так как сама парадигма LCP говорит нам «ешь-что-дали». А выход за рамки был нужен, т.к. бизнес-процессы от региона к региону отличались весьма радикально. Юнит-тесты есть, но свои. Голый код на Java писать можно в action'ах, но Mendix Studio это не поощряет, намекая, что LCP это много кликать мышкой, а если ты хочешь писать код, то ты делаешь что-то не так. UI приложения выглядел крайне топорно, в результате чего UX субподрядчиков выражался, в основном, нецензурными лексическими конструкциями.
Умножим всё это на проблемы доставки фиксов из-за отсутствия привычного git flow, проблемы тестирования в CI/CD, а также реально новую среду, в которую разработчиков засовывали насильно. Субъективно человеко-ресурсов было потрачено ничуть не меньше, чем если бы приложение писалось традиционными методами в команде, которая натаскана на выбранный стэк технологий.
Упомянутое ПО на Mendix должно было решать проблемы управления проектами для субподрядчиков. Как только появлялась необходимость выйти за рамки тривиального CRUDа, начинались танцы, так как сама парадигма LCP говорит нам «ешь-что-дали». А выход за рамки был нужен, т.к. бизнес-процессы от региона к региону отличались весьма радикально. Юнит-тесты есть, но свои. Голый код на Java писать можно в action'ах, но Mendix Studio это не поощряет, намекая, что LCP это много кликать мышкой, а если ты хочешь писать код, то ты делаешь что-то не так. UI приложения выглядел крайне топорно, в результате чего UX субподрядчиков выражался, в основном, нецензурными лексическими конструкциями.
Умножим всё это на проблемы доставки фиксов из-за отсутствия привычного git flow, проблемы тестирования в CI/CD, а также реально новую среду, в которую разработчиков засовывали насильно. Субъективно человеко-ресурсов было потрачено ничуть не меньше, чем если бы приложение писалось традиционными методами в команде, которая натаскана на выбранный стэк технологий.
Спасибо, крайне интересно. Полностью повторяет мои ощущения и проекцию на реальный проект, хотя я игрался с Mendix только пару месяцев в исследовательских целях.
Вы явно знакомы с корпоративной культурой :) Номинация в категории «инновации», а также бонусы за оптимизацию бизнес-процессов. Разумеется, включая скрытые плюшки в виде job visibility и job security (в данном контексте под «security» имеется в виду обеспечение работой себя любимого, ибо больше в этот стэк никто не хочет лезть или не обладает достаточными уровнем знаний). Проталкивание разработки напоминало форсинг мемов на имиджбордах — все понимают, что это отстой, но остановиться уже не могут.
При чем здесь BPMN( BPMS )? Это не в каком месте не lowcode. Так и любой фрэймворк или СУБД можно к lowcode отнести.
Наличие BPMS( а иначе зачем вообще BPMN ) как части системы упрощает понимание как же у вас в реальности работает бизнес логика «высокого уровня».
Объем кода при этом меньше не становиться( если конечно не писать свой движок выполнения бизнес процессов ), но система становиться более прозрачной и ее легче модифицировать.
Наличие BPMS( а иначе зачем вообще BPMN ) как части системы упрощает понимание как же у вас в реальности работает бизнес логика «высокого уровня».
Объем кода при этом меньше не становиться( если конечно не писать свой движок выполнения бизнес процессов ), но система становиться более прозрачной и ее легче модифицировать.
В 1992-м году, принимая меня на первую в жизни работу, начальник сказал: «Жалко мне вас, сегодняшних студентов. Пока доучитесь, программирование вымрет и будет заменено CASE (computer-aided software engineering)». С тех пор прошло почти 30 лет — а мы все программируем и программируем…
Во-первых, это долго. Очевидно, быстрее написать 10 строк кода в хорошей IDE, чем перетаскивать, настраивать и соединять десятки блоков.
Не поверите, но многие 1Совцы считают, что мышкой у них получается быстрее программировать, чем в нормальной IDE. На вопрос, как они потом мышкой делают merge (даже без привязки gitflow), к сожалению, пока никто внятного ответа не дал.
1Совцы все-таки пишут код. Мышкой они интерфейс рисуют. Это ближе к классическому RAD. По возможностям и скорости разработки любому low code до 1С как до Китая…
Нет. Они именно мышкой создают программные объекты, вроде справочников и регистров. И даже запросы по их утверждению мышкой пишут (хотя там по сути чистый SQL с парой небольших фич, вроде автоматической группировки по всем использованным полям в виртуальных таблицах регистров).
И интерфейс у них уже давно с относительным позиционированием (а не олдскульный WYSIWYG), и задается как иерархия контейнеров. Но его тоже мышкой пишут.
И интерфейс у них уже давно с относительным позиционированием (а не олдскульный WYSIWYG), и задается как иерархия контейнеров. Но его тоже мышкой пишут.
Объекты, регистры и даже простые запросы — это довольно близко к «декларативщине». Здесь нет логики, и поэтому на мой взгляд нет ничего плохого в том, чтобы описывать их в визуальной среде. Это может даже быть удобнее и быстрее кода в каких-то случаях. То же касается и интерфейса, неважно с относительным или абсолютным позиционированием.
Логику они все же пишут в коде, а не блок схемами.
Логику они все же пишут в коде, а не блок схемами.
Ну вы же понимаете, что «декларативщина», как и «простые» запросы — штука относительная. И говорить, что в этом всем нет логики это немного странно на мой взгляд.
Чем по вашему логика группировки данных (регистры) или логика запросов (запросы) — меньшая логика, чем логика проверки ограничений (например что остаток меньше 0), которая в 1С задается в коде?
Чем по вашему логика группировки данных (регистры) или логика запросов (запросы) — меньшая логика, чем логика проверки ограничений (например что остаток меньше 0), которая в 1С задается в коде?
Если честно, я не спец по 1С, не знаю, почему ограничения там задаются в коде. В Java полно вариантов задавать их декларативно, вот тут неплохой обзор.
Я имел в виду сравнение с алгоритмами. Код с ветвлениями, условиями, вызовами функций и т.п. Что-то вроде (фантазирую) «проверить остатки, если недостаточно проверить дату следующего поступления или отменить другой заказ, если этот клиент имеет приоритет».
Я имел в виду сравнение с алгоритмами. Код с ветвлениями, условиями, вызовами функций и т.п. Что-то вроде (фантазирую) «проверить остатки, если недостаточно проверить дату следующего поступления или отменить другой заказ, если этот клиент имеет приоритет».
Ну эти варианты это только ограничения на значения полей таблиц (то есть CRUD или типа того). Имеется ввиду более сложные ограничения (именно например остаток + резерв
больше 0 если по складу нужно проверять положительный остаток). Вот тут чуть подробнее.
Хотя впрочем учитывая что в SQL с этим не справились, ожидать того же от 1С было бы достаточно глупо.
В любом случае ограничения это тоже декларативная логика по сути, но ничего — задается кодом. А регистры мышкой.
больше 0 если по складу нужно проверять положительный остаток). Вот тут чуть подробнее.
Хотя впрочем учитывая что в SQL с этим не справились, ожидать того же от 1С было бы достаточно глупо.
В любом случае ограничения это тоже декларативная логика по сути, но ничего — задается кодом. А регистры мышкой.
«проверить остатки, если недостаточно проверить дату следующего поступления или отменить другой заказ, если этот клиент имеет приоритет»
Собственно именно поэтому в 1С ограничения и задаются в коде. Т.к. простые случаи все-таки встречаются довольно редко.
В Java полно вариантов задавать их декларативно, вот тут неплохой обзор.
Именно в платформе 1С есть некоторый аналог описанных например в Transaction listeners валидаторов, в виде подписок на события (т.е. некоторая процедура, которая срабатывает перед/при записи объекта в БД, в том числе, на нее можно навесить проверку и транзакцию отменять). Активно используется в типовой «Библиотеке подсистем».
Не совсем. Там есть еще такая штука как СКД: habr.com/ru/company/1c/blog/336258. И там классическое визуальное программирование.
В визуальном программировании как таковом нет ничего плохого. Там где оно уместно, это действительно может и время экономить и порог входа снижать. Имхо, в конструкторе отчетов оно как раз уместно. Смысл в том, что low code платформы пихают его везде, не особо предоставляя альтернативу.
В визуальном программировании как таковом нет ничего плохого
Как вы правильно заметили, когда его не начинают использовать везде где только можно без альтернативы. То есть как дополнительный механизм — почему нет. Но как у основного механизма у ВП проблем очень много. Вот тут я немного касался этой темы.
Как основной тоже можно и даже нужно, но тогда, когда речь идёт не о дискретных данных (принять сообщение, положить в базу, посчитать статистику...), а о потоках данных (пропустить радиосигнал через фильтр, вычесть модулирующий, пропустить через дешифратор...). Всё это можно и кодом, но гораздо менее наглядно и, вследствие этого, с бОльшей вероятностью ошибки.
что характерно, 1С изначально позиционировался как low code platform, на которой бухгалтера сами будут писать учёт.
Ну SQL тоже так в свое время позиционировался, как тут в комментариях уже отмечали. Впрочем уровень абстрагирования он повысил, так что честь ему и хвала за это. Без SQL многие вещи делались бы куда сложнее и дольше.
Ну надо уточнять, что платформа 1С так позиционировалась до 7 версии. С выходом 7ой (и уж тем более 8ой) версии, разговоры про «бухгалтера сами» закончились.
А те редкие бухи, которые умудряются до сих пор работать на 1С 6, так сами и настраивают печатные формочки и проводки.
А те редкие бухи, которые умудряются до сих пор работать на 1С 6, так сами и настраивают печатные формочки и проводки.
Блин, ох уж этот merge. Вот приходишь ты на работу после отпуска, например. Спрашиваешь, «как тут дела», и коллеги тебе говорят — мы тут в твоем компоненте (который типа диаграмма со стрелочками) пофиксили один небольшой баг. И единственный вменяемый способ узнать, что именно поменяли — это экспортировать проект в XML (компонент нельзя), и поиском найти там компонент, а потом сделать diff, где будет куча мусора, потому что квадратики еще подвигали немного, или раскрасили в другой цвет — на работу это не влияет, а вот мусор в диффе создает еще какой. Про привязку этих изменений к Jira вообще речь не заходит.
О да, открываешь настройки этих Low Code систем и видишь такое:
И это называется Fast configuring new data structure!
Configuration UI
И это называется Fast configuring new data structure!
даже простые пользователи смогут самостоятельно создавать бизнес-приложения
Напоминает SQL. А в итоге получим ещё один тип вакансий на рынке для разработчиков.
Есть множество задач, которые надо выполнять регулярно, но с частотой до 10 раз в день, например. И вот тут похожие решения вполне имеют право на жизнь.
Другое дело, что правильнее выбрать что то из open source BPMN. Хоть и похоже во многом, но BPMN — это стандарт.
То есть запилили по сути прототип (сильно неоптимальный), но так как задача хоть и регулярная, но нагрузки не создает — переписывать просто не целесообразно.
Я, например, точно знаю, что большая часть моих отчетов на SQL не оптимизирована. Но я и не собираюсь тратить время на их оптимизацию. Сейчас, например, делаю отчет. Его будут запускать несколько раз в год. И ВСЕМ вообще без разницы, отработает он за 5 секунд или за 50 секунд.
Другое дело, что правильнее выбрать что то из open source BPMN. Хоть и похоже во многом, но BPMN — это стандарт.
То есть запилили по сути прототип (сильно неоптимальный), но так как задача хоть и регулярная, но нагрузки не создает — переписывать просто не целесообразно.
Я, например, точно знаю, что большая часть моих отчетов на SQL не оптимизирована. Но я и не собираюсь тратить время на их оптимизацию. Сейчас, например, делаю отчет. Его будут запускать несколько раз в год. И ВСЕМ вообще без разницы, отработает он за 5 секунд или за 50 секунд.
самый лучший вариант я так понял это собирать на этих схемах часто меняющуюся бизнес логику. интересно, есть такой инструмент для .net который можно было бы использовать в проектах на c#?
Все это нужно и неплохо продается для корпоративного ПО. Т.е. вы в принципе правильно заметили что 3-10 толковых людей способны сделать то-же самое гораздо эффективнее, но тут наверное надо сделать оговорку — если они имеют доступ ко всем компонентам системы. А если это не так, то тут начинаются и проблемы
Из примеров которые встречал недавно в больших компаниях:
1 — покупка нового обычного двух-процессорного сервера(около 20к-30k на сайте Dell) — оценка бюджета 0.5млн$. На вопрос — откуда такая цифра — нужны резервы, спец по по управлению, места в стойке, услуги по настройке, лицензии на управляющий софт и т.д
2 — развертывание новой версии системы с 1 новой фукнцией — несколько месяцев работы
3 — Разработка нового сайта для управления партнерами(их несколько тысяч, до этого управление велось в Excel — по сути одна таблица) — около 1 млн$, почему так много — нужно привлекать несколько комманд — железо, безопастность, юристов и т.д. для каждой будет менеджер проектов, наверху координатор все координировать
4 — добавление поля в таблицу на SQL — около недели работы(несколько уровней согласования, оформление заявки для внешней фирмы и т.д.)
Т.е. в этих то случаях используя Low code платформы пользовать сам может сделать то что нужно за гораздо меньший бюджет(это называется citizen developer), сейчас этот рынок растет довольно сильно
Из примеров которые встречал недавно в больших компаниях:
1 — покупка нового обычного двух-процессорного сервера(около 20к-30k на сайте Dell) — оценка бюджета 0.5млн$. На вопрос — откуда такая цифра — нужны резервы, спец по по управлению, места в стойке, услуги по настройке, лицензии на управляющий софт и т.д
2 — развертывание новой версии системы с 1 новой фукнцией — несколько месяцев работы
3 — Разработка нового сайта для управления партнерами(их несколько тысяч, до этого управление велось в Excel — по сути одна таблица) — около 1 млн$, почему так много — нужно привлекать несколько комманд — железо, безопастность, юристов и т.д. для каждой будет менеджер проектов, наверху координатор все координировать
4 — добавление поля в таблицу на SQL — около недели работы(несколько уровней согласования, оформление заявки для внешней фирмы и т.д.)
Т.е. в этих то случаях используя Low code платформы пользовать сам может сделать то что нужно за гораздо меньший бюджет(это называется citizen developer), сейчас этот рынок растет довольно сильно
Т.е. в этих то случаях используя Low code платформы пользовать сам может сделать то что нужно за гораздо меньший бюджет(это называется citizen developer)
Это каким образом он это сделает, если у него доступа нет? Ново купленный сервер сам собой настроится, если кнопочку в системе нажать? Я вообще не уловил связь ваших примеров и Low code.
Ну продают это так что пользователь может сам набросать нужный ему функционал. К примеру сделать форму ввода для каких-нибудь данных, получая данные с других систем, прописать какие-то триггеры в системах.
Но факт что сейчас это топ. К примеру с последних конференций Microsoft показывают истории про механика который сделал PowerApp(это low code от Microsoft) который позволяет с телефона отправлять сканы повреждений машины, данные о клиенте и их оценивать
Но факт что сейчас это топ. К примеру с последних конференций Microsoft показывают истории про механика который сделал PowerApp(это low code от Microsoft) который позволяет с телефона отправлять сканы повреждений машины, данные о клиенте и их оценивать
Не совсем согласен с противопоставлением в статье Low-code платформ и фреймворки/платформы для разработчиков.
На мой взгляд, low-code это просто следующий шаг развития макросов для электронных таблиц/правил сортировки писем в ящике/CMS-систем/разнообразных конструкторов опросов в интернете (я даже не буду пытаться перечислить все разнообразные сервисы вроде IFTTT). Еще одна зверушка в зоопарке костылей и велосипедов, уже доступных и привычных пользователям.
И да, на долгой дистанции и хотя бы среднем бизнесе (при наличии команды разработки или денег на ее найм) использовать такое решение будет крайне глупо. Но из этих инструментов пользователи реально могут собирать несложные решения для своих процессов не привлекая к этому разработчиков.
P.S. если уж на то пошло, то иногда покупая «сложное готовое решение, на профессиональном фреймворке», компания оказывается владельцем вот такого же набора костылей, но уже «собранного командой профессионалов» и за совершенно другие деньги =)
На мой взгляд, low-code это просто следующий шаг развития макросов для электронных таблиц/правил сортировки писем в ящике/CMS-систем/разнообразных конструкторов опросов в интернете (я даже не буду пытаться перечислить все разнообразные сервисы вроде IFTTT). Еще одна зверушка в зоопарке костылей и велосипедов, уже доступных и привычных пользователям.
И да, на долгой дистанции и хотя бы среднем бизнесе (при наличии команды разработки или денег на ее найм) использовать такое решение будет крайне глупо. Но из этих инструментов пользователи реально могут собирать несложные решения для своих процессов не привлекая к этому разработчиков.
P.S. если уж на то пошло, то иногда покупая «сложное готовое решение, на профессиональном фреймворке», компания оказывается владельцем вот такого же набора костылей, но уже «собранного командой профессионалов» и за совершенно другие деньги =)
Посмотрите маркетинговые материалы low code платформ. Их как раз противопоставляют фреймворкам. Года 2-3 назад на голубом глазу говорили, что разработчики больше не нужны. Сейчас поаккуратнее, но посыл тот же.
И да, продают их практически исключительно крупному бизнесу. Для остальных стоимость запредельная. Если память не изменяет мне, бОльшая часть клиентов Mendix платит более $1M в год.
А ценность для крупного бизнеса именно в обходе того бардака, который описал DenisTrunin выше. Поэтому и продают их не ИТшникам, а бизнесу.
И да, продают их практически исключительно крупному бизнесу. Для остальных стоимость запредельная. Если память не изменяет мне, бОльшая часть клиентов Mendix платит более $1M в год.
А ценность для крупного бизнеса именно в обходе того бардака, который описал DenisTrunin выше. Поэтому и продают их не ИТшникам, а бизнесу.
Посмотрите маркетинговые материалы low code платформ. Их как раз противопоставляют фреймворкам
Сужу по тем материалам, что я видел, но тот же MS Power Apps описывается как «пользователь сможет легко сделать то, что раньше мог сделать только разработчик» и «разработчик может сэкономить свое время и расширить возможности платформы». Не сказать что наглая ложь, хотя понятно что с оговорками.
Но вообще, противопоставление не совсем фреймворкам. А «low-code самостоятельно VS. spring + разработчик» или «low-code сегодня VS. изучать JAVA и более крутое решение завтра». Т.е. упор на «просто», «быстро» (без «дешево» и «качественно»).
Для остальных стоимость запредельная
Глянул стоимость Mendix — 2000 у.е. на пользователя в месяц, это конечно мощно. Но не у всех такие ценники, есть и вполне демократические.
Про то, что разработчики не нужны так вообще годами рассказывают. С другой стороны — модная тема была пару-тройку лет назад, про «программирование — вторая грамотность». Вот такие платформы как раз на эту идею хорошо ложатся.
>А ценность для крупного бизнеса именно в обходе того бардака
Дело в том, что бардак — он зачастую возникает не просто так. Люблю я очень одну историю, как я был разработчиком интеграционной шины.
В проекте были задействованы примерно пять или чуть больше систем банка, расположенные в разных физических сетях, построенные на разных технологиях, и связанные аж двумя шинами минимум (наша — одна из двух).
Так вот — работы по изменению кода там было на пять строк кода. Но при этом аналитики двух систем — источника и приемника, собирались вместе решать, как же нам все это сделать. И занимались они этим пару месяцев. И полчаса на правки кода. И с первого раза не получилось.
Вот вспоминаю это — и каждый раз представляю, как бы пользователь сам бы это реализовал бы, в графической форме, в виде стрелочек… тяп-ляп за пять минут бы.
Мораль — иногда реализация это полная фигня, 5 строк кода, а вот понять, что именно нужно сделать, чтобы пять или шесть систем продолжали бы совместно работать — это гораздо сложнее.
Дело в том, что бардак — он зачастую возникает не просто так. Люблю я очень одну историю, как я был разработчиком интеграционной шины.
В проекте были задействованы примерно пять или чуть больше систем банка, расположенные в разных физических сетях, построенные на разных технологиях, и связанные аж двумя шинами минимум (наша — одна из двух).
Так вот — работы по изменению кода там было на пять строк кода. Но при этом аналитики двух систем — источника и приемника, собирались вместе решать, как же нам все это сделать. И занимались они этим пару месяцев. И полчаса на правки кода. И с первого раза не получилось.
Вот вспоминаю это — и каждый раз представляю, как бы пользователь сам бы это реализовал бы, в графической форме, в виде стрелочек… тяп-ляп за пять минут бы.
Мораль — иногда реализация это полная фигня, 5 строк кода, а вот понять, что именно нужно сделать, чтобы пять или шесть систем продолжали бы совместно работать — это гораздо сложнее.
И занимались они этим пару месяцев. И полчаса на правки кода. И с первого раза не получилось.
Присутствовал на совещании, где представители двух команд разработки (одна внутренняя, вторая — аутсорсеры) решали кто должен к пересылаемым между двумя системами данным применять метод String.Trim. Все были очень серьезны, фиксировали все договоренности на бумаге и т.д.
А пользователь бы это реализовал за 5 минут. Так что тут как в анекдоте — «случаи бывают разные».
Менеджеры: Нам нужно по быстрому набросать прототип гуя.
Разработчик: Технологии, фреймворки?
Менеджеры: %tech_name%, модный, современный, руководство одобрило.
Разработчик: Это пойдет в прод?
Менеджеры: Ни в коем случае, только демо/черновик. Побыстрее.
* Разработчик заглядывает в контракт в поиске условий увольнения без привязанности к отзывам пользователей, находит
Разработчик: Хорошо, вот сроки.
…
Менеджеры: Демо понравилось, давай в прод.
Разработчик: Это черновик. Он медленный и неподдерживаемый. Надо переписать.
Менеджеры: Некогда. Оно работает? Работает. В прод.
* Разработчик открывает линкедын.
Разработчик: Да на здоровье.
…
Менеджеры: Пользователи жалуются на приложение. Оно тормозит и жрет ресурсы.
Разработчик: Я предупреждал. Переписать нахрен.
Менеджеры: Некогда. Уже в проде, нужен саппорт того, что есть.
* Разработчик увольняется.
Разработчик: Технологии, фреймворки?
Менеджеры: %tech_name%, модный, современный, руководство одобрило.
Разработчик: Это пойдет в прод?
Менеджеры: Ни в коем случае, только демо/черновик. Побыстрее.
* Разработчик заглядывает в контракт в поиске условий увольнения без привязанности к отзывам пользователей, находит
Разработчик: Хорошо, вот сроки.
…
Менеджеры: Демо понравилось, давай в прод.
Разработчик: Это черновик. Он медленный и неподдерживаемый. Надо переписать.
Менеджеры: Некогда. Оно работает? Работает. В прод.
* Разработчик открывает линкедын.
Разработчик: Да на здоровье.
…
Менеджеры: Пользователи жалуются на приложение. Оно тормозит и жрет ресурсы.
Разработчик: Я предупреждал. Переписать нахрен.
Менеджеры: Некогда. Уже в проде, нужен саппорт того, что есть.
* Разработчик увольняется.
Магия…
два часа назад у меня было собеседование (по телефону) на должность Solutions Architect (Presale) в Mendix… а тут бах — статья :D
К моему сожалению, эти стрелочки очень нравятся уровню Си и они диктуют — смотри, готовое решение, сейчас возьмём, накликаем и готово… а тут команда будет пахать полгода… лучше 100.000 € заплатим.
Но выкатывается это к сожалению только в то, что в итоге, стрелки рисуются год, система диктует возможности продукта, а не наоборот. А тот кто принял решение, назад не пойдёт — ибо лицом в грязь…
В итоге разрабы в шоке, продакт оунер заткнулся.
Profit.
два часа назад у меня было собеседование (по телефону) на должность Solutions Architect (Presale) в Mendix… а тут бах — статья :D
К моему сожалению, эти стрелочки очень нравятся уровню Си и они диктуют — смотри, готовое решение, сейчас возьмём, накликаем и готово… а тут команда будет пахать полгода… лучше 100.000 € заплатим.
Но выкатывается это к сожалению только в то, что в итоге, стрелки рисуются год, система диктует возможности продукта, а не наоборот. А тот кто принял решение, назад не пойдёт — ибо лицом в грязь…
В итоге разрабы в шоке, продакт оунер заткнулся.
Profit.
Это все уже пройдено по сто пятьдесять тысяч раз по кругу. Еще в конце девяностых носились с RUP, когда идеалом было — программировать мышкой. Но реальность оказалась сложнее.
Радует что не оставляют попытки упростить процесс разработки, но к сожалению это все еще слишком слабо формализованный процесс, чтобы можно было его «втискивать» в подобные инструменты.
Радует что не оставляют попытки упростить процесс разработки, но к сожалению это все еще слишком слабо формализованный процесс, чтобы можно было его «втискивать» в подобные инструменты.
Borland с ее Delphi сделала много для упрощения. Но почила в бозе не в последнюю очередь из-за копеечной, казалось бы, цены инструмента порядка $1000. Оказалось, что чем вкладываться в рабочее место, все равно дешевле нанять толпу, которая будет кодить в блокноте. Даже MS не могла это побороть и выкатила Express студию да опенсурсный неткорь. Бабло победило простоту.
История Delphi немного сложнее. Borland был знатно раскулачен Microsoft, который перекупил костяк компании для разраотки Visual Studio, что в итоге привело к первой юзабельной версии. После этого Delphi стагнировал много лет, и пропустил вспышку web-а. Когда все улетело в интернеты и браузеры Delphi совсем и угас.
Стоимость лицензии на одно приложение начинается от $1875 в месяц при условии подписки на три года
Не то чтобы очередь выстроится, но желающих поработать программистов будет достаточно. Мы находим и на $1500. Это при том что неквалифицированному сотруднику за работу с системой тоже придется платить хотя бы $1000, итого $2800 в месяц, а за такой ценник уже и очередь настоящих программистов подвалит: ) За $100 в месяц конечно шикарная была бы идея.
Ради справедливости, про лидерство Microsoft PowerApps утверждает не автор, а Gartner — знатные булшитеры и трендмейкеры в одном лице.
По тем кейсам, которые мне известны, лоукоды продавались именно как панацея, а не как «узкоспециализированная и спецефичная» вещь — что в последствии повлекло завышенные ожидания и крах. Именно на это и делает акцент автор. Одна из ключевых мыслей тут, как я ее понимаю, именно вредоносность «заноса» технологий сверху, т.к. ниже по иерархии маркетниг-булшит не очень работает.
По тем кейсам, которые мне известны, лоукоды продавались именно как панацея, а не как «узкоспециализированная и спецефичная» вещь — что в последствии повлекло завышенные ожидания и крах. Именно на это и делает акцент автор. Одна из ключевых мыслей тут, как я ее понимаю, именно вредоносность «заноса» технологий сверху, т.к. ниже по иерархии маркетниг-булшит не очень работает.
И да и нет. Одно дело — подход open source, когда продукт берут, потому что он хороший. И берут его не менеджеры, а инженеры. В этом случае нет смысла вбивать технологии в глотки менеджерья. Если продуктом трудно заинтересовать инженеров, нужно идти выше и рассказывать сказки. Так что это не только «вопрос к продавцам».
Gartner утвердает что Mendix — лидер, смотрите картинку с «магическим квадратом» вначале статьи. Конечно, LCAP разные. SalesForce в первую очередь вообще про расширение CRM и других их продуктов, а не про разработку с нуля. А вот OutSystems похож на Mendix. Конечно, у них есть своя ниша — те же прототипы. Но совсем не та, где их позиционируют.
Маркетологи изобрели велосипед ДРАКОН?
Идея low-code имеет право на жизнь.
Другое дело — реализация. В современных продуктах я не встречал красивых реализаций.
В 90-е был язык Clarion (сейчас сильно сдулся).
В нем раздельная схема базы и UI, визуальная настройка массы пропертей UI, шустрый компилятор, а также развитый язык шаблонов кодогенерации.
Значительно ускорял разработку. Позволял небольшим командам вести массу продуктов.
Другое дело — реализация. В современных продуктах я не встречал красивых реализаций.
В 90-е был язык Clarion (сейчас сильно сдулся).
В нем раздельная схема базы и UI, визуальная настройка массы пропертей UI, шустрый компилятор, а также развитый язык шаблонов кодогенерации.
Значительно ускорял разработку. Позволял небольшим командам вести массу продуктов.
ну если вспомнить наш Дракон — то можно и в космос слетать на таком
У меня лично вполне себе положительный опыт работы с low-code фреймворками.
Я лично писал на DevExpress XAF, и он прекрасно подходит для внутренних проектов. Да не очень шустрый, но там из коробки есть и авторизации/аутентификации, аудит, разграничение прав, всякие отчетики, дэшбордики. На нем можно буквально за неделю сделать приемлимую CRM.
(И таки нет, я на них не работаю смайл)
Я лично писал на DevExpress XAF, и он прекрасно подходит для внутренних проектов. Да не очень шустрый, но там из коробки есть и авторизации/аутентификации, аудит, разграничение прав, всякие отчетики, дэшбордики. На нем можно буквально за неделю сделать приемлимую CRM.
(И таки нет, я на них не работаю смайл)
DevExpress это все-таки в сторону RAD, а не Low Code. То есть — готовые компоненты и инструменты быстрой разработки, но логику вы пишете в коде. Эта концепция применима гораздо шире, чем low/no code которые претендуют на создание приложений вообще без программирования.
Вы правы, однако логику в DevExpress можно на очень глубоком уровне описывать в Model Editorе и классами с аттрибутами. Я абсолютно уверен, что можно написать средней руки CRM не написав ни строчки кода, лишь описав классы и их связи.
Да, Visual Studio понадобиться, да человек должен будет понимать, что такое программирование, но скорость разработки в разы выше, чем у программирования блок схемами. Благо, без кода все-равно ни там, ни там не обойдется.
Да, Visual Studio понадобиться, да человек должен будет понимать, что такое программирование, но скорость разработки в разы выше, чем у программирования блок схемами. Благо, без кода все-равно ни там, ни там не обойдется.
Отличный вброс. Особенно с учётом того, что вы работаете в компании, которая занимается заказной разработкой корпоративных систем и конкурирует с 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 платформой заменять фреймворки/платформы для разработчиков, используйте её по назначению всё будет отлично.
Так напишите статью, в которой разъясните, в чем конкретно заблуждается автор, и как классно строить приложения с использованием Low-code платформ. В частности, как вы решаете проблемы с системами контроля версий. Многим будет интересно, я думаю.
Ваш сайт встречает разработчиков вот таким пассажем:
Минуточку, а где же ваша документация? Или это кот в мешке?
Дополнительная информация о Comindware Business Application Platform доступна по запросу
Минуточку, а где же ваша документация? Или это кот в мешке?
Сайт делают маркетологи и, наверное, так у них конверстится лучше. Меня лично тоже бесит отсутствие прайсинга и документации на продуктовых сайтах. Ссылки на какую-то нашу документацию всё же можно найти тут в блоке «Размещение и лицензирование» – www.comindware.com/ru/platform остальное уже отдают сейлзы после запроса.
Я ждал подобный комментарий )) Начну с того, что мы не конкурируем с Low Code платформами. Системы, которые мы делаем, просто невозможно сделать на известных мне LCAP. Далее, сразу оговорюсь что не использовал Comindware и что-то не вижу на сайте даже возможность попробовать. Стесняетесь? Mendix, Outsystems, Bizagi и другие честнее в этом.
Продираясь через маркетинговые перлы на вашем сайте, осмелюсь предположить, что ваша платформа – это классическая BPMS плюс набор готовых решений, и вы видимо сознательно пытаетесь «примазаться» к хайповой теме low code. Я понимаю, когда это делают маркетологи, но не на хабре же!
У BPMS есть своя понятная ниша. Но статья же про другой класс систем. Даже больше, статья как раз о том, что не надо вестись на маркетинговый bullshit про «в 4 раза быстрее» и «идеальный фундамент для цифровой трансформации предприятия». Надо понимать, что применимость и гибкость подобных инструментов крайне ограничена. Ни на BPMS, ни на Low Code платформе невозможно построить не то что ERP, даже простую удобную CRM типа AmoCRM.
И последнее, у вас на сайте говорится, что разработчику достаточно реализовать 10-20% системы, остальное все аналитики мышкой накликают. Это прекрасно. А вот расскажите теперь как именно это делается? Какой язык, среда, где точки входа, как организован контроль версий? А то ведь какой сюрприз – на сайте ни документации, ни примеров.
Продираясь через маркетинговые перлы на вашем сайте, осмелюсь предположить, что ваша платформа – это классическая BPMS плюс набор готовых решений, и вы видимо сознательно пытаетесь «примазаться» к хайповой теме low code. Я понимаю, когда это делают маркетологи, но не на хабре же!
У BPMS есть своя понятная ниша. Но статья же про другой класс систем. Даже больше, статья как раз о том, что не надо вестись на маркетинговый bullshit про «в 4 раза быстрее» и «идеальный фундамент для цифровой трансформации предприятия». Надо понимать, что применимость и гибкость подобных инструментов крайне ограничена. Ни на BPMS, ни на Low Code платформе невозможно построить не то что ERP, даже простую удобную CRM типа AmoCRM.
И последнее, у вас на сайте говорится, что разработчику достаточно реализовать 10-20% системы, остальное все аналитики мышкой накликают. Это прекрасно. А вот расскажите теперь как именно это делается? Какой язык, среда, где точки входа, как организован контроль версий? А то ведь какой сюрприз – на сайте ни документации, ни примеров.
Согласен.
Как же меня бесят SaaS решения, на сайте которых нет ни простейших демо, ни даже цен. Всё это является всего лишь попыткой срубить бабла. Напишет Вася Пупкин — мы ему за 100 баксов продадим. Напишет человек из крупной фирмы — мы ему вломим за это же самое решение сто тысяч.
Стыдно такими быть. Увольте нафиг всех сейлзов, сделайте вменяемую ценовую политику, покажите демо — и я уверен, клиентов будет только больше.
Как же меня бесят SaaS решения, на сайте которых нет ни простейших демо, ни даже цен. Всё это является всего лишь попыткой срубить бабла. Напишет Вася Пупкин — мы ему за 100 баксов продадим. Напишет человек из крупной фирмы — мы ему вломим за это же самое решение сто тысяч.
Стыдно такими быть. Увольте нафиг всех сейлзов, сделайте вменяемую ценовую политику, покажите демо — и я уверен, клиентов будет только больше.
Ну строго говоря на сайте SAP (лицензий) или условного EPAM (человеко-часов) цен тоже нет. Все же сложные бизнес-решения это не семечки продавать, там дикое количество неизвестных параметров.
Хотя с отсутствием демо, детальных примеров и вариантов использования согласен. Обычно это показатель маркетинг булшита максимального уровня.
Хотя с отсутствием демо, детальных примеров и вариантов использования согласен. Обычно это показатель маркетинг булшита максимального уровня.
Строго говоря, SAP (ну по крайней мере еще недавно) не был SaaS платформой. Равно как и EPAM. Ну и да, то что у SAP нет цен лишь говорит, что как компания SAP фиговенькая.
Вот захожу на www.atlassian.com/ru/software/jira/pricing
и вижу сайт здоровой компании. И демо доступ без рабочего емейла и автоматом дают.
А вот это сайт раковой компании
www.comindware.com/ru/company/contact-us/?product=platform&form=getaquote
Цен нет, демо тоже нет (только после обработки сейлзов)
Вот захожу на www.atlassian.com/ru/software/jira/pricing
и вижу сайт здоровой компании. И демо доступ без рабочего емейла и автоматом дают.
А вот это сайт раковой компании
www.comindware.com/ru/company/contact-us/?product=platform&form=getaquote
Цен нет, демо тоже нет (только после обработки сейлзов)
Ну я захожу на сайт боинга или ibm'а и тоже не вижу там прайсов.
Все же некорректно сравнивать полусервисные компании (где сервис являются важной неотъемлемой частью продукта) с компаниями продающими коробочные решения, в стиле «ешьте что дают». Безотносительно от того какой подход из них правильный (если так вообще можно говорить).
Все же некорректно сравнивать полусервисные компании (где сервис являются важной неотъемлемой частью продукта) с компаниями продающими коробочные решения, в стиле «ешьте что дают». Безотносительно от того какой подход из них правильный (если так вообще можно говорить).
Вот тут тоже полуправда.
Цены на Боинги весьма известная величина. Да, их нет на сайте, потому что у них там нет калькулятора, а цена сильно зависит от комплектации. Но даже гугл знает ответ в вакууме:
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 находятся на самом дне вместе. Дорого, плохо, медлено. Зато откаты платят исправно. За что и любят.
Цены на Боинги весьма известная величина. Да, их нет на сайте, потому что у них там нет калькулятора, а цена сильно зависит от комплектации. Но даже гугл знает ответ в вакууме:
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 находятся на самом дне вместе. Дорого, плохо, медлено. Зато откаты платят исправно. За что и любят.
Просто на сайте компании, в которой работает NitroJunkie тоже цен нет (но какая-то демка есть), вот он и обижается на «донность» и «раковость».
Ну если IBM и SAP — «донные» компании чего обижаться то. Человек реально думает что их покупают только за откаты. И видимо не совсем понимает как этот рынок вообще работает.
Ну и у Боинга тоже нет цен. А среднюю температуру по больнице и для компании, в которой я работаю тоже несложно найти. Хотя конкретно то над чем я работаю вообще бесплатно. Так что тут я согласен с euroUK :)
И это не говоря уже о том, что у тех же авиакомпаний, цена за одни и те же места (!) может в несколько раз поменяться в течении пары дней. И это не говоря про бизнес-класс и всякие мили за которые его можно купить. Ну и все тоже самое также касается например отелей и тонны других рынков.
Ну и у Боинга тоже нет цен. А среднюю температуру по больнице и для компании, в которой я работаю тоже несложно найти. Хотя конкретно то над чем я работаю вообще бесплатно. Так что тут я согласен с euroUK :)
И это не говоря уже о том, что у тех же авиакомпаний, цена за одни и те же места (!) может в несколько раз поменяться в течении пары дней. И это не говоря про бизнес-класс и всякие мили за которые его можно купить. Ну и все тоже самое также касается например отелей и тонны других рынков.
Я в отрасли с 2006 года, видел на своем веку и SAP и IBM. Я не отрицаю, что в свое время компании были пионерами отрасли и крутыми. Но уже давно, продукцию этих компаний покупают по трем причинам:
1) Чтобы снять с себя ответственность или из-за лени (еще никого не уволили за то, что он купил IBM)
2) Потому что откаты с миллиарда больше, чем откаты с 20 миллионов.
3) 20летнее легаси
Других причин покупать в 2020х годах решения типа SAP просто нет, никакой экономической выгоды чтобы окупиться они просто не принесут.
1) Чтобы снять с себя ответственность или из-за лени (еще никого не уволили за то, что он купил IBM)
2) Потому что откаты с миллиарда больше, чем откаты с 20 миллионов.
3) 20летнее легаси
Других причин покупать в 2020х годах решения типа SAP просто нет, никакой экономической выгоды чтобы окупиться они просто не принесут.
Я тоже в отрасли очень давно (с года так 2000). И там много причин почему его покупают, и откаты лишь одна из возможных, хотя и не основная (так как решение такого масштаба как правило принимает собственник, а откат ему давать бесполезно).
Но все же справедливости ради нужно отметить, что для сложных бизнес-приложений сильно лучших альтернатив САПу в принципе то и нет. С точки зрения платформы ничего радикально лучшего не придумали (у САП свой высокоуровневый DSL довольно неплохо подходящий для конвеерной разработки бизнес-логики, как его называют сами саперы «Foxpro на стероидах»), а за долгие годы существования накоплено много готовых решений и опыта, пусть и не всегда удачного.
То есть я не спорю что «говно мамонта», все дела. Но что по вашему сильно лучше? Сложное бизнес-решение на Node.Js или Java Spring? Я вас умоляю. Delphi + Oracle / PostgreSQL. Такое же говно мамонта. .Net или надстройки над Python (аля Odoo)? Ну да местами лучше, местами хуже (все же с DSL в многих местах тяжело соревноваться), но даже никакого x2 (не говоря уже о x10) нет. Местные игроки аля 1С? У них своих скелетов еще больше чем у SAP.
А в плане готовых решений они все уступают SAP и часто значительно (это во многих случаях признают даже те кто в конечном итоге выбирают не SAP'кие решения).
Но все же справедливости ради нужно отметить, что для сложных бизнес-приложений сильно лучших альтернатив САПу в принципе то и нет. С точки зрения платформы ничего радикально лучшего не придумали (у САП свой высокоуровневый DSL довольно неплохо подходящий для конвеерной разработки бизнес-логики, как его называют сами саперы «Foxpro на стероидах»), а за долгие годы существования накоплено много готовых решений и опыта, пусть и не всегда удачного.
То есть я не спорю что «говно мамонта», все дела. Но что по вашему сильно лучше? Сложное бизнес-решение на Node.Js или Java Spring? Я вас умоляю. Delphi + Oracle / PostgreSQL. Такое же говно мамонта. .Net или надстройки над Python (аля Odoo)? Ну да местами лучше, местами хуже (все же с DSL в многих местах тяжело соревноваться), но даже никакого x2 (не говоря уже о x10) нет. Местные игроки аля 1С? У них своих скелетов еще больше чем у SAP.
А в плане готовых решений они все уступают SAP и часто значительно (это во многих случаях признают даже те кто в конечном итоге выбирают не SAP'кие решения).
Я лично не видел, чтобы в компаниях самих бы САП допиливали. Сколько видел — это были сплошь SAP интеграторы. У которых 1 мэндэй стоит столько же, сколько у пяти 1Cников.
При этом, в тех компаниях где я видел SAP, он не использовался и на 10%.
Также не стоит забывать сколько стоит железо, чтобы SAP хоть как-то работал и мы посчитаем, что любое решение, включая самописное, будет дешевле и быстрее.
Что касается стэка, мне сложно что-то говорить как шарписту, но мое ИМХО .netcore3 + EFCore + PostgreSQL меня удовлетворяют на 100% по скорости разработки, развертывания и работы.
При этом, в тех компаниях где я видел SAP, он не использовался и на 10%.
Также не стоит забывать сколько стоит железо, чтобы SAP хоть как-то работал и мы посчитаем, что любое решение, включая самописное, будет дешевле и быстрее.
Что касается стэка, мне сложно что-то говорить как шарписту, но мое ИМХО .netcore3 + EFCore + PostgreSQL меня удовлетворяют на 100% по скорости разработки, развертывания и работы.
Я если честно вообще не понимаю смысла допиливать в компании что-то своими силами. Это глупо по огромному количеству причин, начиная от того что компании приходится обладать компетенциями (в том числе по найму) в непрофильном для нее бизнесе (все равно что если бы ИТ-компания наоборот держала в штате бы электриков, строителей и сантехников) и заканчивая, тем что многие проекты имеют волнообразную нагрузку, то есть в активной фазе нужно в 5 раз больше людей, чем в пассивной.
Компании разные бывают и процент фейлов в крупных компаниях аля SAP у большинства его конкурентов не меньший.
Ну если вам нужно будет разрабатывать очень сложные по функционалу приложения (далеко уходящие от CRUD и простых ORM), то эта связка даже SAP с его ABAP не обгонит. Не говоря о том, что у SAP уже готового кода вагон и маленькая тележка.
При этом, в тех компаниях где я видел SAP, он не использовался и на 10%.
Компании разные бывают и процент фейлов в крупных компаниях аля SAP у большинства его конкурентов не меньший.
Что касается стэка, мне сложно что-то говорить как шарписту, но мое ИМХО .netcore3 + EFCore + PostgreSQL меня удовлетворяют на 100% по скорости разработки, развертывания и работы.
Ну если вам нужно будет разрабатывать очень сложные по функционалу приложения (далеко уходящие от CRUD и простых ORM), то эта связка даже SAP с его ABAP не обгонит. Не говоря о том, что у SAP уже готового кода вагон и маленькая тележка.
А я, если честно, не понимаю зачем компаниям нанимать сторонних интеграторов по следующим причинам:
1) Отсутствие компетенций в написании ТЗ приводит к тому, что компания заказчик заплатит два или три раза, прежде чем результат хоть как-то будет походить на требуемый.
2) Заказчик будет платить джунам по цене синьоров (у него же нет компетенций чтобы оценивать уровень владения инструментом). Я видел такое у всех крупных интеграторов.
3) Без четкого понимания, заказчик будет платить за то, как интегратору удобнее реализовывать систему (были на тот момент команды на Go без работы — будет у клиента на Go)
4) Интегратор сделает все возможное, чтобы заказчик не слез с иглы, даже на другого интегратора. Даже если у SAP готового кода вагон — то интегратор сделает свою версию
5) Программист в штате может решать и другие задачи, коих в компаниях и со 100 сотрудниками может быть тьма. Если для них нет задач, то компании пойдет любое коробочное решение, а не интегратор.
6) Не стоит забывать, что SAP не может ничего зафейлить, так как он ничего не продает лично. А его вендеры и фейлят, и сроки срывают легко и просто.
Ну и что касается сложных приложений. Любое мое приложение, на любом объеме данных будет работать в разы быстрее, чем SAP. Потому что я делаю схемы БД и бизнес логику под задачи, а не обмазываюсь 15 уровнями абстракции фреймворков разного уровня. (И да, я работал через netcore3 + EFCore + MS SQL с десятками миллиардов записей)
1) Отсутствие компетенций в написании ТЗ приводит к тому, что компания заказчик заплатит два или три раза, прежде чем результат хоть как-то будет походить на требуемый.
2) Заказчик будет платить джунам по цене синьоров (у него же нет компетенций чтобы оценивать уровень владения инструментом). Я видел такое у всех крупных интеграторов.
3) Без четкого понимания, заказчик будет платить за то, как интегратору удобнее реализовывать систему (были на тот момент команды на Go без работы — будет у клиента на Go)
4) Интегратор сделает все возможное, чтобы заказчик не слез с иглы, даже на другого интегратора. Даже если у SAP готового кода вагон — то интегратор сделает свою версию
5) Программист в штате может решать и другие задачи, коих в компаниях и со 100 сотрудниками может быть тьма. Если для них нет задач, то компании пойдет любое коробочное решение, а не интегратор.
6) Не стоит забывать, что SAP не может ничего зафейлить, так как он ничего не продает лично. А его вендеры и фейлят, и сроки срывают легко и просто.
Ну и что касается сложных приложений. Любое мое приложение, на любом объеме данных будет работать в разы быстрее, чем SAP. Потому что я делаю схемы БД и бизнес логику под задачи, а не обмазываюсь 15 уровнями абстракции фреймворков разного уровня. (И да, я работал через netcore3 + EFCore + MS SQL с десятками миллиардов записей)
Еще SAP покупают, чтобы увеличить капитализацию компании. Инвесторы точно также покупаются на рекламу типа «Best runs SAP». Соответственно, работает логическая цепочка: «Best runs SAP» => компания — best => стоимость компании выше.
А сейчас производители BPMS тоже любят называть себя Low Code платформами — хайп и маркетинг. :)
Вот пример:
ELMA4: новая low-code платформа для быстрого построения корпоративных приложений
С моей точки зрения, между этими терминами (BPMS and Low Code) разницы особой нет. Но, наверно, потому, что если в Low Code нет BPMN — то покупать такой «чемодан без ручки» будет разве что «эффективный менеджер». По крайней мере я так считаю. :)
Ну и, разумеется, крайне глупо на таких инструментах пытаться реализовать ERP, CRM или просто калькулятор.
Вот пример:
ELMA4: новая low-code платформа для быстрого построения корпоративных приложений
С моей точки зрения, между этими терминами (BPMS and Low Code) разницы особой нет. Но, наверно, потому, что если в Low Code нет BPMN — то покупать такой «чемодан без ручки» будет разве что «эффективный менеджер». По крайней мере я так считаю. :)
Ну и, разумеется, крайне глупо на таких инструментах пытаться реализовать ERP, CRM или просто калькулятор.
Всё таки конкурируете: у клиента один бюджет и отнесёт он его либо вам, либо вендору Low-code, либо вендору «коробки». Low-code как концепция – это решение для бизнеса, который как раз хочет минимизировать зависимость от вендора. В случае заказной разработки, как мы все знаем, это та ещё «игла», подсев на которую клиент постоянно платит разработчику за доработку и новый функционал, причём по рейту, который устанавливает исполнитель, и получая результат в сроки, устанавливаемые тем же самым исполнителем. Про «простые удобные CRM-коробки» хочу отметить, что если бы они действительно подходили компаниям, то их бы не появлялось на рынке как грибов после дождя, а вокруг Salesforce не сформировалась бы целая индустрия доработок, модулей и т.д. По поводу невозможно построить ERP|CRM, на сколько мне известно на нашей платформе делали и то и то, причем довольно сложное и удобное, под что не возможно найти решения на рынке. По поводу языка и контроля версий это C# и GIT. Напишите в личку, если интересно поговорить или потыкаться в триалке нашей платформы – организую.
Low-code как концепция – это решение для бизнеса, который как раз хочет минимизировать зависимость от вендора.— простите, но это очень смешно. У вас нет лицензионных платежей? Решение на Comindware можно мигрировать на другую платформу?
По поводу невозможно построить ERP|CRM, на сколько мне известно на нашей платформе делали и то и то, причем довольно сложное и удобное— пруфов не видно. Но даже допустим. И какое там соотношение между кликами мышками и кодом на C#? Я на 146% уверен, что в таком случае это «каша из топора».
потыкаться в триалке нашей платформы— спасибо за предложение, но тратить время на изучение малораспространенного закрытого продукта не готов. Я не так давно довольно много времени потратил на изучение известных представителей мира Low Code (Mendix) и BPMS (Bizagi), собственно часть выводов отражена в статье.
В случае заказной разработки, как мы все знаем, это та ещё «игла»— От такого поворота даже я ох… нел (с)
Впрочем, в полемику custom dev vs product vs platform dev я не буду вступать. Наша компания работает по всем трем моделям. Мы (компания Haulmont) создатели как довольно популярной RAD платформы с открытым кодом (CUBA Platform), так и продуктов (Тезис ECM), а также занимаемся заказной разработкой. Поверьте, я прекрасно знаю особенности и применимость каждого из сценариев.
Всё таки конкурируете: у клиента один бюджет и отнесёт он его либо вам, либо вендору Low-code, либо вендору «коробки».
Да, гвозди так же с конкурируют с саморезами, а мясо с овощами.
Что такое Low Code? Это когда с помощью графических элементов описываешь некий алгоритм.
Насколько я знаю, единственный широко распространенный стандарт, описывающий набор графических символов, «программу» из которых можно запустить на исполнение — это BPMN. Более того, этот стандарт существует уже довольно много лет. Следовательно, системы, в которых нет BPMN или которые обещают, что программисты не понадобятся (на BPMN, чтобы заработало, все равно надо писать программу))) — просто очередной вариант «сравнительно честного способа отъема денег».
Остапов Бендеров во все времена хватало. :)))
Насколько я знаю, единственный широко распространенный стандарт, описывающий набор графических символов, «программу» из которых можно запустить на исполнение — это BPMN. Более того, этот стандарт существует уже довольно много лет. Следовательно, системы, в которых нет BPMN или которые обещают, что программисты не понадобятся (на BPMN, чтобы заработало, все равно надо писать программу))) — просто очередной вариант «сравнительно честного способа отъема денег».
Остапов Бендеров во все времена хватало. :)))
На самом деле это не совсем верно. Low code — это совокупность средств для разработки без использования кода. Это и деплоймент, и визуальная разработка интерфейсов, и визуальная разработка логики, в общем случае не важно на базе какого стандарта. Кстати, microflows в Mendix основаны как раз на BPMN. Отличие Mendix от BPMS — в том что эта платформа предназначена для разработки произвольных приложений, а не только крутящихся вокруг процессов. Здесь BPMN используется для описания элементов логики (например, загрузить определенных данные и открыть форму при нажатии на кнопку), а не для описания «долгоиграющего» процесса. Соответственно, они предоставляют кучу специализированных стенсилов (типов узлов) и настроек для решения задач, обычно решающихся в коде.
То есть стандарт один, но используется он совершенно по-разному.
То есть стандарт один, но используется он совершенно по-разному.
Можно переформулировать:
«Low code — это совокупность средств для разработки с использованием графических элементов. Это и деплоймент, и визуальная разработка интерфейсов, и визуальная разработка логики.»
То есть первое, что надо понимать — код мы все равно пишем. В виде стрелочек и прямоугольников или в виде слов и цифр — но в любом случае пишем. Глупо думать, что человек без специальной подготовки сможет придумать и записать даже относительно простой алгоритм. И не важно, будет записываться алгоритм буквами или прямоугольниками.
Второе — очень желателен общепризнанный стандарт. То, что Mendix сделал microflows на основе BPMN — это как раз недостаток. В первых двух буквах BPMN четко указана направленность этого стандарта (Business Process Model and Notation), это не универсальный стандарт и сомневаюсь, что его использование в других сферах будет эффективно.
Третье — описывать некоторые (довольно многие) вещи с помощью графических элементов — неудобно.
Если суммировать — попытка сделать инструмент «для разработки произвольных приложений» с помощью только графических элементов, предназначенный для пользователей вообще без знаний или с очень минимальными знаниями в области программирования…
Это к Остапу Бендеру. :)))
Тот же BPMN пользователи с минимальной подготовкой могут понимать «в целом» — как это работает и находить ошибки в логике с точки зрения бизнеса. Но самостоятельно написать относительно сложный бизнес процесс — уже не могут. Нужна более серьезная подготовка. Как минимум несколько дней. И в любом случае многие «низкоуровневые» вещи нужно будет написать на обычном языке программирования (Java, Python...), иначе будет жесть.
«Low code — это совокупность средств для разработки с использованием графических элементов. Это и деплоймент, и визуальная разработка интерфейсов, и визуальная разработка логики.»
То есть первое, что надо понимать — код мы все равно пишем. В виде стрелочек и прямоугольников или в виде слов и цифр — но в любом случае пишем. Глупо думать, что человек без специальной подготовки сможет придумать и записать даже относительно простой алгоритм. И не важно, будет записываться алгоритм буквами или прямоугольниками.
Второе — очень желателен общепризнанный стандарт. То, что Mendix сделал microflows на основе BPMN — это как раз недостаток. В первых двух буквах BPMN четко указана направленность этого стандарта (Business Process Model and Notation), это не универсальный стандарт и сомневаюсь, что его использование в других сферах будет эффективно.
Третье — описывать некоторые (довольно многие) вещи с помощью графических элементов — неудобно.
Если суммировать — попытка сделать инструмент «для разработки произвольных приложений» с помощью только графических элементов, предназначенный для пользователей вообще без знаний или с очень минимальными знаниями в области программирования…
Это к Остапу Бендеру. :)))
Тот же BPMN пользователи с минимальной подготовкой могут понимать «в целом» — как это работает и находить ошибки в логике с точки зрения бизнеса. Но самостоятельно написать относительно сложный бизнес процесс — уже не могут. Нужна более серьезная подготовка. Как минимум несколько дней. И в любом случае многие «низкоуровневые» вещи нужно будет написать на обычном языке программирования (Java, Python...), иначе будет жесть.
Справедливости ради, в Mendix подняли уровень абстракции очень высоко, и _простые_ системы действительно может написать пользователь без особой подготовки. Они серьезно в это вложились. Продукт по-своему мощный и у него есть своя область применения — прототипы и простейшие системы. Проблемы начинаются, когда его пытаются натянуть на что-то более сложное.
P.S. В использовании BPMN в microflows ничего плохого не вижу.
P.S. В использовании BPMN в microflows ничего плохого не вижу.
Я про другое пытаюсь сказать.
В принципе невозможно (по крайней мере сейчас, до изобретения сильного ИИ или чего то сопоставимого) создать программу любой сложности (даже самую простую) без того, чтобы придумать в голове и записать в каком либо понятном компьютеру виде алгоритм.
Те же макросы в Ексель — это тоже программа с кодом.
Пока алгоритм относительно простой — можно рассчитывать, что справится пользователь с минимальной подготовкой. Мы (люди) все немного программисты. :)
Но как только сложность алгоритма увеличивается — уже не важно, будут графические значки или английские слова — пользователь без подготовки его не реализует. Да, можно привести примеры, когда способный человек несколько недель (месяцев) сидел, разбирался и реализовал довольно сложную вещь. Но ведь это и есть обучение программированию! :)))
А BPMN — он в первую очередь про бизнес процессы. Разумеется, он относительно универсален, но использовать во всех задачах…
Для систем, которые не про бизнес процессы — нужно придумать свой язык и сделать стандартом. Пока этого не сделали — серьезно вкладываться в такие системы и хоть сколько нибудь серьезные задачи с их помощью решать — не целесообразно. Альтернативы есть (обычные языки программирования со своими стандартами).
А про свою область применения полностью согласен. Каждый инструмент должен использоваться в правильной (подходящей для него) области.
Я, например, специализируюсь на финансах. Любимый инструмент всех финансистов — Ексель. Кстати, считается, что его можно начинать использовать с минимальным обучением, что в целом правда. Для многих задач Ексель — прекрасный инструмент. Но как только его начинают использовать для неподходящих задач — сразу вылазит множество косяков, которые в рамках Екселя побороть невозможно. Ну не подходит он для очень многих задач.
Хотя ежики все равно продолжают плакать, колоться, но упорно есть кактус…
В принципе невозможно (по крайней мере сейчас, до изобретения сильного ИИ или чего то сопоставимого) создать программу любой сложности (даже самую простую) без того, чтобы придумать в голове и записать в каком либо понятном компьютеру виде алгоритм.
Те же макросы в Ексель — это тоже программа с кодом.
Пока алгоритм относительно простой — можно рассчитывать, что справится пользователь с минимальной подготовкой. Мы (люди) все немного программисты. :)
Но как только сложность алгоритма увеличивается — уже не важно, будут графические значки или английские слова — пользователь без подготовки его не реализует. Да, можно привести примеры, когда способный человек несколько недель (месяцев) сидел, разбирался и реализовал довольно сложную вещь. Но ведь это и есть обучение программированию! :)))
А BPMN — он в первую очередь про бизнес процессы. Разумеется, он относительно универсален, но использовать во всех задачах…
Для систем, которые не про бизнес процессы — нужно придумать свой язык и сделать стандартом. Пока этого не сделали — серьезно вкладываться в такие системы и хоть сколько нибудь серьезные задачи с их помощью решать — не целесообразно. Альтернативы есть (обычные языки программирования со своими стандартами).
А про свою область применения полностью согласен. Каждый инструмент должен использоваться в правильной (подходящей для него) области.
Я, например, специализируюсь на финансах. Любимый инструмент всех финансистов — Ексель. Кстати, считается, что его можно начинать использовать с минимальным обучением, что в целом правда. Для многих задач Ексель — прекрасный инструмент. Но как только его начинают использовать для неподходящих задач — сразу вылазит множество косяков, которые в рамках Екселя побороть невозможно. Ну не подходит он для очень многих задач.
Хотя ежики все равно продолжают плакать, колоться, но упорно есть кактус…
Итак, ориентируя продажи на топ-менеджеров, вендоры low code платформ обещают, что даже простые пользователи смогут самостоятельно создавать бизнес-приложения.
То есть разработчики больше не нужны?!
Возможно, что дело в конкретной нише и даже в конкретном вендоре, но я не вижу причин говорить о том, что Low-code это сплошной риск.
Про бизнес не знаю, но в области встраиваемых систем реального времени тот же Matlab/Simulink является low-code платформой, позволяющей создавать свои приложения для систем управления, без подключения программистов. При этом программистам, естественно, тоже отводится свое место, но уже не в качестве основных разработчиков функциональности, а в качестве системщиков. Про Дракон тут тоже упоминали.
Или вот сравнительно недавно я тоже занялся low code на Node Red по причине того, что мне захотелось сделать свою логику управления для умного дома, а вникать во всякие javascript мне просто не захотелось. Заметили, как похожа графика? Результат порадовал и сейчас серъезно задумываюсь над тем, чтобы использовать Node-Red в production в серьезном IoT-проекте. И да, я собираюсь подключить сторонних разработчиков к моему проекту, но потом большинство сопроводиловки вести своими ресурсами.
Вы совершенно правы. Речь о претензии на разработку корпоративного ПО (aka кровавый энтерпрайз). В то же время есть множество ниш где low code прекрасно работает.
В то же время есть множество ниш где low code прекрасно работает.
Чтобы немного конкретизировать — есть много ниш, где low code прекрасно заходит прямо здесь и сейчас. Т.е. меняет подход к разработке в настоящее время и во многом благодаря тому, что подтянулись соответствующие технологии, а люди достаточно обленились.
Возможно, в корпоративном ПО происходит та же ситуация, но вы просто неправильно выбрали момент или вендора?
У меня на прошлой работе в Голландии человек писал приложения на PowerApps типа отпусков и больничных.
Судя по тому, как он плевался (мы сидели рядом) и сколько времени на это потратил, то я в свое удовольствие уже бы десяток сайтов на своем стэке бы сделал. Кода там было бы больше конечно, зато дешевле и быстрее.
Судя по тому, как он плевался (мы сидели рядом) и сколько времени на это потратил, то я в свое удовольствие уже бы десяток сайтов на своем стэке бы сделал. Кода там было бы больше конечно, зато дешевле и быстрее.
Наиболее репрезентативных вендоров я изучал, выводы собственно в статье…
Да, идея фикс «программирование без программистов» по-прежнему не дает покоя менеджерам.
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 — последний писк моды (еще одна голландская разработка).
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 — последний писк моды (еще одна голландская разработка).
Стоило бы указать, что это перевод. Оригинал Low Code Platforms — a Dangerous Bet
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Low-code платформы: панацея или рискованная ставка?