Пришло время подумать о том, что и в течение какого времени должны уметь делать ваши приложения low- и no-code, пишет на портале InformationWeek Мэри Шеклет, президент консалтинговой компании Transworld Data.

По прогнозам Gartner, в 2025 г. 70% приложений, разрабатываемых компаниями, будут либо low-code, либо no-code, и почему бы компаниям не перейти на эти методологии? В модели low- и no-code полномочия по разработке приложений передаются непосредственно в руки конечных пользователей, которым больше не нужно ждать, пока ИТ-отдел найдет на них время.

Создавать такие приложения тоже просто. С генератором приложений no-code вам нужно лишь навести курсор и кликнуть на ресурсы и операции, которые вы хотите включить, ввести правила, и все готово.

Генераторы приложений low- и no-code имеют долгую историю. Изначально они были известны как генераторы отчетов 3GL и 4GL, которые на протяжении десятилетий предоставляли пользователям (и ИТ-специалистам) простые способы быстрого создания отчетов, не требующих сложной логики и интеграции с базовой ИТ-инфраструктурой.

Упереться в стену

Как и их 3GL- и 4GL-предки, приложения no- и low-code быстро разрабатываются и развертываются. Они также имеют одно важное ограничение по сравнению с 3GL/4GL: требуют вмешательства ИТ-специалистов, когда необходимы улучшения для совместимости с ИТ-инфраструктурой.

Это одна из причин, по которой no- и low-code приложения вполне могут пойти по стопам своих предшественников 3GL и 4GL. Какое-то время они хороши, но через некоторое время их полезность сходит на нет из-за необходимости усовершенствований и более тесной ИТ-интеграции. Затем их кладут на полку.

Как это происходит? Вот пример:

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

Финансисты задаются вопросом: «Кроются ли первопричины в операционных сбоях на производстве или в несовершенстве компонентов, которые закупаются у третьих сторон?».

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

Управление приложениями low- и no-code

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

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

Пользователям не нравится терять контроль над приложениями, а ИТ-отделу не очень хочется добавлять новые приложения в очередь на усовершенствование и обслуживание. Что же можно сделать, чтобы справиться с этим?

Один из способов — установить для всего предприятия рекомендации по оптимальному использованию приложений low- и no-code.

Первый шаг — установление ограничений на использование приложений.

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

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

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

Соображения по поводу окончания срока службы

Решение о том, когда следует отказаться от приложения no- или low-code, также является важной темой.

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

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

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

Резюме

No- и low-code приложения открывают перед компаниями огромные возможности для более быстрого выполнения ИТ-работы. Они также расширяют возможности пользователей.

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

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