Не будет ни CRM, ни ECM, один сплошной Low-code (на самом деле нет)

7
Не будет ни CRM, ни ECM, один сплошной Low-code (на самом деле нет)

Все внезапно заговорили о Low-code платформах. Что это за зверь? Откуда они взялись? История Low-code платформ восходит к 90-м годам, к языкам 4GL и RAD. Помните, была такая штука VisualAge от голубого гиганта? Выглядело очень революционно – берем и создаем приложение без строчки кода, программисты больше не нужны. – Ну-ну, сказали программисты и пошли кодить.

Идея, как это часто бывает, опередила свое время. Для подобных продуктов не было целевой аудитории. Потому что настоящему разработчику все эти визуальные приблуды не нужны, ему проще написать код на C++, Java и чем угодно. А ненастоящих разработчиков – всех этих бизнес-аналитиков, продвинутых пользователей – тогда не было в товарных количествах.

Ибо даже пользуясь визуальным конструктором, надо понимать, что на самом деле он генерит код, который исполняется. И если ты не понимаешь, как в принципе все работает, то рабочее приложение не создашь. В общем, тогда идея не взлетела и о ней надолго забыли. Кстати, VisualAge не умер совсем, а превратился в Eclipse Framework, но это уже другая история.

Раз-два и в продакшн

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

Миллион программистов, которых нам якобы не хватает, из ниоткуда враз не возьмется. И как же быть? Потенциально этот разрыв могли бы заполнить «ненастоящие» разработчики – специалисты, понимающие предметную область. Иногда они даже могут написать небольшой кусок кода для конкретной задачи, только им нужен соответствующий инструмент, обычная IDE им не подходит. Потому что они мыслят не в терминах классов и библиотек, а в объектах и процессах – документах, договорах, заявках, заказах, товарах и так далее.

BPM – чемодан без ручки (как было раньше)

Параллельно развивалась история BPM. Сначала тема управления бизнес-процессами возникла чисто как концепция. Можно было поговорить в высоких кабинетах о методологии процессного управления, нарисовать красивые схемы и повесить на стену. Обычно этим все и заканчивалось – дальше IDE в руки и кодить. Потому что процесс сам себя не исполнит, ему нужны экранные формы, артефакты, документы, роли, пользователи, права – а это большой объем рутинной работы, и все равно надо кодить.

Появление BPMS, то есть систем, годных не только для моделирования, но и для исполнения бизнес-процессов, не спасло ситуацию. Сложно сказать почему. Вроде идея хорошая, но получалось сложно и дорого, и рынок оставался узковат. Сложно сказать почему. Я думаю, это из-за универсальности. BPM-системам приходилось конкурировать с кучей прикладных систем, каждая из которых делала свою работу лучше. Возьмите хоть документооборот – конечно, можно все сделать и на BPM, но зачем, когда есть СЭД?

В общем, BPM долгое время оставался эдаким чемоданом без ручки. О нем все любили поговорить, а как внедрять, так давай процессы хардкодить. Так было раньше, а сейчас совсем другое дело. Сейчас BPM стал ключевым элементом Low-code платформ, именно на процесс нанизывают всю остальную функциональность, что весьма логично.

Откуда пришла вторая волна Low-code

Как мы говорили выше, идея Low-code появилась давно, но первое поколение подобных продуктов не вызвало энтузиазма пользователей. Сейчас мы видим вторую волну, которая пришла, откуда не ждали. В лоукодеры подались поставщики разных специализированных систем, типа CRM и ECM (или, по-нашему, СЭД). Заказчики требовали от них все большей гибкости, значит, нужно было все больше всяких настроек. Ну не делать же отдельную ветку кода под каждого клиента, это же будет кошмар с поддержкой.

И постепенно эти специальные системы превратились в универсальные конструкторы любых бизнес-приложений. Действительно, а что нужно бизнесу? – Формы и списки, и чтоб можно было добавить разные кнопочки, назначить роли.

Факты? Пожалуйста. Мы знали Salesforce как CRM-систему, теперь это Low-code платформа. Аналогичная метаморфоза произошла и с Террасофт – когда та осознала, что ее продукт bpm’online (который был на самом деле CRM) теперь тоже платформа «малокодовой» разработки, то она даже поменяла его название на Creatio. Подтягиваются на эту поляну и поставщики СЭД. Так, например, Docsvision уже давно себя позиционирует как Low-code, недавно ELMA тоже заявила о себе в этом качестве. Остальные пока не артикулируют этот месседж явно, однако по сути они тоже платформы разработки чего угодно, давно не только СЭД или CRM.

BPM-щики тоже двинули в Low-code, та же Pega, например. Это логично, ибо голые процессы никому не нужны, нужно работающее приложение с нормальным интерфейсом. BPMS тоже обзавелись разнообразными конструкторами и наработали экспертизу в разных предметных областях.

Взгляните на магический квадрат Gartner по Low-code-платформам. Вы увидите много имен, знакомых ранее по другим квадратам. То есть, можно сказать, что Low-code - это этап эволюции различных прикладных систем, когда они достигают высокого уровня кастомизации. В общем, не будет больше ни CRM, ни ECM, ни ERP, ни BPM – один сплошной Low-code!

Быть Фордом или Феррари

Означает ли пришествие Low-code платформ, что обычная разработка больше не нужна? Конечно нет. Это две разные концепции, которые будут сосуществовать и конкурировать. Как Форд и Феррари. У корпоративных заказчиков есть огромный спрос на большое количество разработок – изрядную часть этого спроса можно покрыть Low-code системами, как Форд покрывает рынок массовых автомобилей.

Если очень постараться, то наверное на Low-code платформе можно запилить и что-то очень навороченное, не уступающее по качеству разработке традиционным методом. Ну да, Форд тоже побеждал Феррари несколько раз, когда было задето эго владельца компании и он бросил на это все ресурсы. Но Феррари никогда не будет делать массовый автомобиль, чтобы победить Форда на его поляне. Более того – недавно Феррари заявила, что также никогда не будет делать электромобиль. Только ручная сборка и ревущий мотор, только хардкор!

Так же и в разработке – конвейер Low-code не решит всех проблем, все так же будет востребована ручная сборка и мастерство программистов, чтобы создавать уникальные продукты.

Дороги хватит на всех!

Фото: depositphotos.com/

4093
Поделиться
Коментарии: 7
  • Григорий Аракелов
    Рейтинг: 177
    АО СИТРОНИКС
    Руководитель проекта
    14.12.2020 10:51

    Только нужно людям объяснять, что low-coder не равно программист. И объяснять в первую очередь самим low-coder'ам.
    А то научатся пару квадратиков рядом ставить и связи к ним подключать и бьют себя в грудь - ЯПрограммист! А как до дела доходит - сливаются. И потом уже нормальным программистам приходится допиливать. Допилят конечно, но у заказчика осадок останется. И отношение будет как к ТыЖПрограммисту.

  • Андрей Лабутин
    Рейтинг: 95
    ОАО "Завод им. В.А. Дегтярева"
    Начальник отдела Разработки системы управления ресурсами организации. Управления информационных технологий
    15.12.2020 09:03

    Low-code будет рулить когда:
    1. созреют очень развитые отраслевые коробочные решения, чтобы объем допиливания или того самого low-code custom был минимален
    2. стоимость железа будет копейки, потому что всё, что генерит low-code не оптимизировано от слова вообще.

    В свое время был опыт проектирования финансовой модели предприятия в BPWin. Довели часть модели до состояния автоматической генерации объектов в ERwin, а после него, безусловно с ручными уточнениями, но без разрыва связи с моделью, автогенерацию объектов в ORACLE. Это был очень-очень хороший опыт, чтобы понять плюсы и минусы low-code - хотя мы тогда и не знали, что такой способ проектирования имеет отношение к low-code, как и о самом понятии low-code не имели представления.

    Самое удивительное, что сейчас, не заявляя об этом, крупные системы, в том числе и класса ERP - заявляясь именно как классическая ERP, всячески продвигают подход quasilow-code, полностью закрывая исходные коды и давая разработчикам взамен визуальные инструменты создания псевдо полей, псевдо объектов, псевдо бизнес-логики, псевдо авторизаций - за которыми рождается тот самый неоптимизированный код с корявой логикой, которая может входить в прямое противоречие с системными логическими и бизнес правилами сервера приложений или СУБД, или клиентской логикой, заложенной в базовой ERP. И ни сами компоненты ERP, ни разработчик - проверить это не состоянии. В ERP такие ограничения на создаваемые объекты просто не заложены, а у разработчиков нет доступа к кодам :)

    Но провести глубинные, серьезные доработки бизнес-процессов такая quasilow-code система не позволит, потому что это может разрушить саму систему. Хочешь усовершенствовать систему планирования - о... нет, это же low-code - всё должно быть только поверхностно.

  • Наталья Горова
    Рейтинг: 194
    GlobalCIO | DigitalExperts
    Редактор
    15.12.2020 11:31

    Андрей, очень интересное мнение, спасибо! Раскрывает материал с новой стороны)

  • Олег Баталов
    Рейтинг: 151
    AO Caspian Beverage Holding
    Начальник отдела информационных технологий
    17.12.2020 16:07

    IT изначально развивали "военные", затем "исследователи" и только потом "бизнес".
    Естественно в корне архитектуры современного IT лежит логика "генералов", кардинально отличающаяся от творчества "предпринимателя".
    То что мы наблюдаем - попытка использовать доступный, но не подходящий инструмент.

    • Игорь Безручкин Олег
      Рейтинг: 30
      НИИЭФА, АО
      Ведущий специалист
      18.12.2020 13:52

      Вы о чём? От "изначально" уже ДАВНО ушли!

      • Олег Баталов Игорь
        Рейтинг: 151
        AO Caspian Beverage Holding
        Начальник отдела информационных технологий
        18.12.2020 14:28

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

        Да, система low-code позволяет снизить стоимость изменений, но только в определенных ее разработчиком пределах.

  • Дмитрий Капинос
    Рейтинг: 291
    МГУ, Экономический факультет
    Предприниматель, консультант в области управления и ИТ, к.э.н., преподаватель МГУ
    28.12.2020 22:51

    Low-code — появился не для того, чтобы тесать программы быстрее и с низкой квалификацией. Совсем наоборот, это проявление объективного усложнения и задач, и процессов, и программ, и прогрессивного разделения труда. И, да, это будущее.

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

    Или как будто любой неспециалист сходу поймёт описание системы в нотации UML или любой другой нотации (к вопросу о привносимой простоте и лёгкости).

    В современной программной разработке, к слову, участников сильно больше, чем аналитик (проектировщик) и программист (кодер). И программист здесь далеко не солирует.

    P.S. «Раз-два и в продакшн» — отсылку к фольклору оценили. )

Предметная область
Отрасль
Управление