От ИТ-отделов может потребоваться постоянное вмешательство для устранения беспорядка, а бизнес-пользователи могут безнадежно запутаться в управлении своим ПО, пишет на портале ZDNet независимый аналитик Джо Маккендрик.

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

Gartner, например, утверждает, что инструменты low-code (не упоминая в данном случае no-code) будут готовы к использованию на предприятиях в течение года. По прогнозам аналитика Gartner Марка Драйвера, к концу года разработчики вне ИТ-отделов будут составлять не менее 80% пользовательской базы инструментов low-code — по сравнению с 60% в 2021 г. Платформы low-code быстро развиваются, и в ближайшие несколько лет в этих инструментах появится «функциональность гиперавтоматизации», добавляет он. Кроме того, будет наблюдаться тесная интеграция между инструментами low-code и пакетными бизнес-возможностями.

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

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

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

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

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

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