7 причин, почему инструменты low-code и no-code не оправдывают ожиданий
По мере того как все больше организаций внедряют платформы и инструменты low-code и no-code, руководителям ИТ-подразделений важно учитывать не только преимущества этих технологий, но и связанные с ними ограничения. Согласно исследованию InfoWorld, потенциальные преимущества low-code и no-code очевидны: более быстрая разработка приложений, снижение затрат и повышение гибкости бизнеса. Однако технология подходит не для всех сценариев, а в некоторых случаях подобные решения могут стать не ускорителем, а препятствием для повышения эффективности.
По прогнозу исследовательской компании Grand View Research, мировой рынок платформ low-code будет расти в среднем примерно на 23 % в год в период с 2023 по 2030 год. Такой рост объясняется возрастающим вниманием компаний к цифровому развитию и автоматизации бизнес-процессов, а также стремлением быстрее внедрять решения и упрощать рабочие процессы.
При этом эксперты, опрошенные в рамках исследования, отмечают: несмотря на привлекательную идею упрощенной разработки, компаниям важно заранее учитывать возможные ограничения платформ low-code и no-code при выборе сценариев их применения.
По прогнозу исследовательской компании Grand View Research, мировой рынок платформ low-code будет расти в среднем примерно на 23 % в год в период с 2023 по 2030 год. Такой рост объясняется возрастающим вниманием компаний к цифровому развитию и автоматизации бизнес-процессов, а также стремлением быстрее внедрять решения и упрощать рабочие процессы.
При этом эксперты, опрошенные в рамках исследования, отмечают: несмотря на привлекательную идею упрощенной разработки, компаниям важно заранее учитывать возможные ограничения платформ low-code и no-code при выборе сценариев их применения.
Семь причин, по которым проекты на low-code терпят неудачу
- Потеря глубины и гибкости.
- Чрезмерное упрощение решений.
- Проблемы с масштабированием.
- Ненадежность больших языковых моделей (LLM).
- Риски информационной безопасности.
- Зависимость от поставщика платформы.
- Недооценка возможностей технологии.
Потеря глубины и гибкости
Одно из главных преимуществ платформ low-code и no-code заключается в том, что они позволяют создавать программные решения людям, не являющимся профессиональными разработчиками. Это значительно расширяет круг сотрудников, способных участвовать в разработке, а также потенциально снижает расходы компании на привлечение программистов.
Однако организациям необходимо понимать, что вместе с упрощением разработки они могут потерять часть гибкости.
Подобные платформы обычно предлагают заранее подготовленные шаблоны и готовые компоненты, благодаря которым можно быстро создавать простые приложения.
«Но такие шаблоны часто не обеспечивают той гибкости и глубины настройки, которые необходимы для создания действительно специализированных решений, максимально соответствующих ожиданиям пользователей».
Для внутренних корпоративных процессов или решения несложных задач подобный подход вполне подходит. Однако для внешних сервисов, где качество взаимодействия с пользователем напрямую влияет на востребованность продукта, возможностей готовых шаблонов зачастую оказывается недостаточно.
Ограничения могут возникать и у опытных разработчиков, которым требуется полный контроль над архитектурой приложения. Одним из способов преодоления подобных ограничений становится использование платформ, поддерживающих расширение функциональности через программные интерфейсы и пользовательские модули.
Однако организациям необходимо понимать, что вместе с упрощением разработки они могут потерять часть гибкости.
Подобные платформы обычно предлагают заранее подготовленные шаблоны и готовые компоненты, благодаря которым можно быстро создавать простые приложения.
«Но такие шаблоны часто не обеспечивают той гибкости и глубины настройки, которые необходимы для создания действительно специализированных решений, максимально соответствующих ожиданиям пользователей».
Для внутренних корпоративных процессов или решения несложных задач подобный подход вполне подходит. Однако для внешних сервисов, где качество взаимодействия с пользователем напрямую влияет на востребованность продукта, возможностей готовых шаблонов зачастую оказывается недостаточно.
Ограничения могут возникать и у опытных разработчиков, которым требуется полный контроль над архитектурой приложения. Одним из способов преодоления подобных ограничений становится использование платформ, поддерживающих расширение функциональности через программные интерфейсы и пользовательские модули.
Чрезмерное упрощение решений
Следующая проблема тесно связана с предыдущей. Когда бизнес-пользователи самостоятельно создают приложения без глубокого понимания архитектуры системы, существует риск, что решение окажется слишком упрощенным и не сможет учесть все особенности реальной задачи.
Один из экспертов привел следующий пример из практики: «Когда понадобилось реализовать уникальные функции, которые должны были выделить продукт на рынке, ограничения платформы стали очевидными.
Особенно сложной оказалась реализация:
Этот опыт наглядно показывает главный компромисс low-code: высокая скорость создания первого рабочего решения часто сопровождается недостаточной гибкостью при развитии продукта до уровня сложной корпоративной системы.
Для платформ корпоративного уровня этот риск во многом зависит от архитектуры решения. Например, Триафлай позволяет начинать проект с готовых моделей данных и типовых компонентов, но при необходимости постепенно усложнять систему:
Один из экспертов привел следующий пример из практики: «Когда понадобилось реализовать уникальные функции, которые должны были выделить продукт на рынке, ограничения платформы стали очевидными.
Особенно сложной оказалась реализация:
- многоуровневых показателей сравнения видео;
- интеллектуальных механизмов улучшения изображения;
- нестандартной логики обработки данных.
Этот опыт наглядно показывает главный компромисс low-code: высокая скорость создания первого рабочего решения часто сопровождается недостаточной гибкостью при развитии продукта до уровня сложной корпоративной системы.
Для платформ корпоративного уровня этот риск во многом зависит от архитектуры решения. Например, Триафлай позволяет начинать проект с готовых моделей данных и типовых компонентов, но при необходимости постепенно усложнять систему:
- добавлять собственные модели расчета показателей;
- строить сложные зависимости между объектами;
- использовать внешние источники данных;
- внедрять специализированную отраслевую логику без полной переработки системы.
Проблемы с масштабированием
«Low-code и no-code великолепно подходят для создания прототипов или проверки минимально жизнеспособного продукта (MVP — первой версии продукта с базовым набором функций), однако очень быстро сталкиваются с трудностями при масштабировании», — считает разработчик программного обеспечения, один из экспертов исследования.
Он приводит пример собственного проекта, который удалось вывести на рынок и получить первого платящего клиента всего за четыре дня благодаря инструментам no-code.
Однако после того как продукт доказал свою востребованность, возникли серьезные проблемы. Платформа оказалась не рассчитана на быстро растущую аудиторию пользователей. В результате команде пришлось:
Эксперты согласны, платформы low-code отлично подходят для небольших приложений с относительно простой логикой, однако крупные корпоративные системы предъявляют значительно более высокие требования. Перед внедрением платформы необходимо заранее оценить ее долгосрочную пригодность для критически важных бизнес-процессов.При этом существуют платформы, изначально ориентированные именно на промышленную эксплуатацию.
В случае "Триафлай" архитектура предусматривает работу с:
Он приводит пример собственного проекта, который удалось вывести на рынок и получить первого платящего клиента всего за четыре дня благодаря инструментам no-code.
Однако после того как продукт доказал свою востребованность, возникли серьезные проблемы. Платформа оказалась не рассчитана на быстро растущую аудиторию пользователей. В результате команде пришлось:
- полностью перестраивать систему;
- переносить всех пользователей на новую платформу;
- решать проблемы с потерей данных;
- устранять простои;
- восстанавливать нарушенные рабочие процессы.
Эксперты согласны, платформы low-code отлично подходят для небольших приложений с относительно простой логикой, однако крупные корпоративные системы предъявляют значительно более высокие требования. Перед внедрением платформы необходимо заранее оценить ее долгосрочную пригодность для критически важных бизнес-процессов.При этом существуют платформы, изначально ориентированные именно на промышленную эксплуатацию.
В случае "Триафлай" архитектура предусматривает работу с:
- большим количеством пользователей;
- значительными объемами данных;
- распределенными источниками информации;
- отраслевыми информационными системами.
Ненадежность больших языковых моделей (LLM)
Сегодня значительная часть разработки с использованием low-code и no-code строится вокруг больших языковых моделей (LLM). Однако, по мнению ряда экспертов, именно это может стать источником новых проблем для организаций.
Cтарший инженер по машинному обучению Amazon Web Services, объясняет, что большие языковые модели прекрасно умеют предсказывать следующее слово или элемент текста, благодаря чему способны создавать тексты и писать программный код. Однако принцип их работы отличается от человеческого мышления.
«Требования к программному продукту очень сложны и постоянно меняются. Чтобы получить приемлемый результат от языковой модели, приходится многократно уточнять запросы».
По его словам, каждая новая попытка требует дополнительных вычислительных ресурсов, а значит — увеличивает стоимость работы.
Еще одна проблема заключается в том, что невозможно один раз передать модели все требования к продукту и ожидать, что она создаст окончательное решение. В реальной разработке требования постоянно изменяются. Например, если попросить ChatGPT написать программный код и затем указать на найденную ошибку, модель нередко предлагает совершенно новый вариант решения вместо того, чтобы аккуратно исправить существующий.
«Представьте, какой хаос может возникнуть, если подобное будет происходить каждый раз при изменении требований к продукту».
Для корпоративной разработки это означает необходимость сохранять инженерный контроль над процессом.
Cтарший инженер по машинному обучению Amazon Web Services, объясняет, что большие языковые модели прекрасно умеют предсказывать следующее слово или элемент текста, благодаря чему способны создавать тексты и писать программный код. Однако принцип их работы отличается от человеческого мышления.
«Требования к программному продукту очень сложны и постоянно меняются. Чтобы получить приемлемый результат от языковой модели, приходится многократно уточнять запросы».
По его словам, каждая новая попытка требует дополнительных вычислительных ресурсов, а значит — увеличивает стоимость работы.
Еще одна проблема заключается в том, что невозможно один раз передать модели все требования к продукту и ожидать, что она создаст окончательное решение. В реальной разработке требования постоянно изменяются. Например, если попросить ChatGPT написать программный код и затем указать на найденную ошибку, модель нередко предлагает совершенно новый вариант решения вместо того, чтобы аккуратно исправить существующий.
«Представьте, какой хаос может возникнуть, если подобное будет происходить каждый раз при изменении требований к продукту».
Для корпоративной разработки это означает необходимость сохранять инженерный контроль над процессом.
Риски информационной безопасности
«Как директор по информационным технологиям, вы должны быть уверены, что технология, которую получает организация, одновременно безопасна и действительно полезна», — говорит директор по информационным технологиям компании Quickbase.
По его словам, далеко не все платформы low-code и no-code изначально проектируются с учетом требований информационной безопасности и корпоративного управления. Особенно остро эта проблема проявляется в строго регулируемых отраслях, например в здравоохранении, где действуют жесткие требования к обработке информации.
Не каждая платформа способна соответствовать подобным требованиям.
Когда решение без программирования начинает использоваться во всей организации или становится доступным внешним пользователям, возникает необходимость тщательно управлять доступом и полномочиями сотрудников.
Эксперт отмечает, что многие компании работают одновременно с большим количеством информационных систем и поставщиков технологий, поэтому им необходимо безопасно объединять данные и предоставлять доступ именно тем сотрудникам, которым это действительно требуется.
Еще более серьезный риск возникает, если сама платформа содержит уязвимость. Наример, если тысячи или миллионы сайтов создаются на основе одного инструмента, даже небольшая ошибка в его программном коде способна сделать уязвимыми огромное количество пользователей одновременно.
«Самое тревожное в этой ситуации заключается в том, что большинство пользователей подобных инструментов не умеют самостоятельно устранять такие уязвимости».
В результате проблема может оставаться открытой достаточно долго. По мере распространения low-code и no-code масштаб подобных рисков потенциально увеличивается. Поэтому эксперт рекомендует придерживаться простого правила: «Человек должен оставаться за рулем, а инструмент — лишь помогать ему».
В команде должен присутствовать хотя бы один специалист, способный проверить создаваемые решения и оценить возможные риски.
По его словам, далеко не все платформы low-code и no-code изначально проектируются с учетом требований информационной безопасности и корпоративного управления. Особенно остро эта проблема проявляется в строго регулируемых отраслях, например в здравоохранении, где действуют жесткие требования к обработке информации.
Не каждая платформа способна соответствовать подобным требованиям.
Когда решение без программирования начинает использоваться во всей организации или становится доступным внешним пользователям, возникает необходимость тщательно управлять доступом и полномочиями сотрудников.
Эксперт отмечает, что многие компании работают одновременно с большим количеством информационных систем и поставщиков технологий, поэтому им необходимо безопасно объединять данные и предоставлять доступ именно тем сотрудникам, которым это действительно требуется.
Еще более серьезный риск возникает, если сама платформа содержит уязвимость. Наример, если тысячи или миллионы сайтов создаются на основе одного инструмента, даже небольшая ошибка в его программном коде способна сделать уязвимыми огромное количество пользователей одновременно.
«Самое тревожное в этой ситуации заключается в том, что большинство пользователей подобных инструментов не умеют самостоятельно устранять такие уязвимости».
В результате проблема может оставаться открытой достаточно долго. По мере распространения low-code и no-code масштаб подобных рисков потенциально увеличивается. Поэтому эксперт рекомендует придерживаться простого правила: «Человек должен оставаться за рулем, а инструмент — лишь помогать ему».
В команде должен присутствовать хотя бы один специалист, способный проверить создаваемые решения и оценить возможные риски.
Зависимость от поставщика платформы
Многие платформы low-code и no-code работают как закрытые экосистемы. Это означает, что после создания большого количества приложений переход к другому поставщику может оказаться чрезвычайно сложным.
Подобная зависимость способна привести к нескольким последствиям одновременно:
В традиционной разработке ситуация выглядит иначе. Если программный код принадлежит самой организации, во многих случаях достаточно заменить отдельные компоненты инфраструктуры или зависимости между библиотеками, не переписывая всю систему целиком. Именно поэтому при выборе платформы важно заранее оценивать степень открытости архитектуры.
Подобная зависимость способна привести к нескольким последствиям одновременно:
- увеличению затрат;
- снижению гибкости;
- риску потерять важные функции, если поставщик изменит условия работы платформы.
В традиционной разработке ситуация выглядит иначе. Если программный код принадлежит самой организации, во многих случаях достаточно заменить отдельные компоненты инфраструктуры или зависимости между библиотеками, не переписывая всю систему целиком. Именно поэтому при выборе платформы важно заранее оценивать степень открытости архитектуры.
Недооценка возможностей технологии
Большинство экспертов говорили о технических ограничениях low-code. Однако существует и противоположная проблема.
Директор по данным и аналитике компании Alteryx, считает, что многие организации недооценивают реальные возможности подобных платформ. По его мнению, во многом это связано с самим названием технологии. Раз платформа называется «разработка с минимальным программированием» или «без программирования», многие автоматически делают вывод, что речь идет о простых инструментах, пригодных лишь для несложных задач.
«Такое предубеждение приводит к ошибочному мнению, будто подобные решения менее мощные или менее функциональные».
На практике современные корпоративные платформы способны решать гораздо более широкий круг задач, чем принято считать. Чтобы получить максимальную отдачу, организациям важно не ограничиваться поверхностным знакомством с инструментом, а обучать сотрудников полноценному использованию его возможностей. Только тогда можно раскрыть потенциал платформы, получить ожидаемый эффект и действительно расширить возможности конечных пользователей.
Для российских корпоративных платформ это особенно актуально. Например, "Триафлай" часто воспринимается исключительно как инструмент быстрой разработки приложений, хотя фактически его возможности значительно шире. Помимо создания прикладных решений, платформа поддерживает построение корпоративных моделей данных, управление показателями, автоматизацию процессов, интеграцию с существующими информационными системами, аналитические панели, сценарное моделирование и развитие решений без полной переработки уже внедренной архитектуры.
Именно поэтому успех внедрения зависит не только от выбора платформы, но и от того, насколько организация понимает ее реальные возможности, ограничения и правильно определяет задачи, для которых она действительно подходит.
Директор по данным и аналитике компании Alteryx, считает, что многие организации недооценивают реальные возможности подобных платформ. По его мнению, во многом это связано с самим названием технологии. Раз платформа называется «разработка с минимальным программированием» или «без программирования», многие автоматически делают вывод, что речь идет о простых инструментах, пригодных лишь для несложных задач.
«Такое предубеждение приводит к ошибочному мнению, будто подобные решения менее мощные или менее функциональные».
На практике современные корпоративные платформы способны решать гораздо более широкий круг задач, чем принято считать. Чтобы получить максимальную отдачу, организациям важно не ограничиваться поверхностным знакомством с инструментом, а обучать сотрудников полноценному использованию его возможностей. Только тогда можно раскрыть потенциал платформы, получить ожидаемый эффект и действительно расширить возможности конечных пользователей.
Для российских корпоративных платформ это особенно актуально. Например, "Триафлай" часто воспринимается исключительно как инструмент быстрой разработки приложений, хотя фактически его возможности значительно шире. Помимо создания прикладных решений, платформа поддерживает построение корпоративных моделей данных, управление показателями, автоматизацию процессов, интеграцию с существующими информационными системами, аналитические панели, сценарное моделирование и развитие решений без полной переработки уже внедренной архитектуры.
Именно поэтому успех внедрения зависит не только от выбора платформы, но и от того, насколько организация понимает ее реальные возможности, ограничения и правильно определяет задачи, для которых она действительно подходит.