Технологические лидеры выражают беспокойство по поводу способности приложений low-code/no-code решать ключевые бизнес-задачи, сообщает портал ZDNet.

Какой объем работ по разработке ПО можно смело выносить за пределы ИТ-отдела? Этот вопрос до сих пор остается без ответа. Всем нравится концепция разработки low-code/no-code — даже ИТ-отделам. Особенно им. Разгружая айтишников, она предоставляет конечным пользователям возможность проявить собственную инициативу. Но все должны действовать с осторожностью, поскольку этот подход может работать не во всех условиях.

Недавний опрос Jitterbit «2023 State of Automation:How Low-Code Application Platforms Disrupt the IT Status Quo and Ignite Digital Growth» показал, что 85% организаций заинтересованы в продвижении ИТ-решений low-code/no-code, и чуть более половины из них не против того, чтобы сотрудники вне ИТ-отдела использовали платформы low-code для создания приложений. Исследование также показало, что ИТ-руководители переживают по поводу способности low-code решать ключевые бизнес-задачи, и в меньшей степени их волнуют вопросы безопасности и доступности данных.

В то же время, у организаций может не остаться иного выбора, кроме как двигаться вперед в направлении low-code/no-code, чтобы преодолеть постоянный дефицит технологических кадров. «Они могут использовать эти мощные инструменты автоматизации задач для более быстрого и качественного их выполнения, высвобождая при этом время разработчиков, чтобы они могли сосредоточиться на более сложных инициативах, — говорит Робин Штайн, партнер PwC Labs. — Смена парадигмы мышления в отношении разработки ПО и принятие концепции low-code/no-code — это ключ к раскрытию потенциала за счет использования сотрудников, не относящихся к основной ИТ-функции».

На данном этапе организации начинают разбираться, «что платформы low-code/no-code могут решить и заменить, а что нет, — говорит Доминик Роуз, вице-президент по стратегии платформ LeanIX. — Например, они хорошо работают при объединении существующих ИТ-решений, таких как ERP, с решениями, ориентированными на удовлетворение цифровых потребностей клиентов». Однако, по его словам, это не лучший подход для создания масштабируемых корпоративных решений: «Вы не сможете решить все проблемы клиентов с помощью шаблонных решений. По этой причине компании должны найти лучшие способы извлечь максимум пользы из существующих платформ, чтобы уменьшить потребность в стандартных обходных путях».

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

Катализатором движения в пользу low-code и no-code стала нехватка технических навыков, «а также массовый переход к гибридной работе, — соглашается Судхир Мехта, глобальный вице-президент Optra Engineering в Lexmark International. — Присущая ему гибкость для быстрого решения бизнес-задач с меньшими техническими накладными расходами предоставляет возможность нетехническому сотруднику быстро выполнять задачи с ограниченной инженерной или ИТ-поддержкой».

Одна из оговорок заключается в том, что нативная цифровая среда может быть более благоприятной для применения подхода low-code/no-code, чем устоявшиеся системы. «Low-code или no-code более распространены среди компаний с нативными облачными и совершенно новыми приложениями, созданными с нуля, — отмечает Мехта. — Этот подход хорошо сочетается с облачными операциями. И менее заметен в компаниях, которые все еще используют унаследованные и локальные приложения». Конечно, приложения low-code/no-code могут быть подключены к слою презентации или управления в рамках унаследованных систем, добавляет Мехта.

Тем не менее, ИТ-специалисты должны быть начеку, поскольку стратегия, направленная на то, чтобы вывести разработку на уровень бизнес-пользователей, сопряжена с определенными рисками. «Технологические лидеры должны стратегически гибридно подходить к стратегии low-code или no-code — используя как эти инструменты, так и технологии полного стека», — говорит Штайн. Постройте эту среду на основе «четких стратегии выпуска приложений и границ использования тех или иных технологий, — добавляет она. — Развертывание технологий low-code и no-code не устранит необходимость в надежной ИТ-команде».

Распространение приложений low-code/no-code также чревато низкой производительностью, предостерегает Роуз. «Вы хотите, чтобы ваше решение или продукт работали гладко для ваших клиентов. Когда вы полагаетесь на поставщиков, которые помогают воплотить эти продукты или решения в жизнь, вы в конечном итоге полагаетесь на их план-графики и обновления, чтобы быть уверенными, что располагаете качественным продуктом. Важно не затормозить прогресс в функциональности», — отмечает он.

По словам Роуза, low-code/no-code также может страдать недостаточной креативностью. «Разработка — это не изолированная техническая деятельность. Создание продуктов, которые хорошо служат клиентам, — это мастерство, которое во многих случаях требует квалифицированного разработчика».

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

Автоматизация в вакууме — это не ответ на все вопросы, отмечает Мехта: «Необходимо учитывать всю цепочку, с которой связаны эти приложения. Если действие запущено, но общий процесс нарушен, то подход low-code/no-code не поможет устранить пробелы. Вот почему архитекторы по-прежнему играют решающую роль, поскольку они могут заглянуть за пределы отдельных приложений и убедиться, что общая архитектура остается применимой и отвечает общей цифровой трансформации».