Стоит ли доверять low-code/no-code для создания критически важных приложений?

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

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

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

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

Эта функциональность командной строки обеспечивает два преимущества. Первое — это прозрачность кода, что означает, что разработчики могут видеть сгенерированный код и вносить в него изменения. Во-вторых, если опытный пользователь (не разработчик) создал приложение, которое вырастает за рамки его возможностей, он может передать проект разработчикам, которые смогут добавить улучшения или внести изменения.

Платформы low-code, как правило, интегрированы с IDE и другими вещами, поэтому предоставляют разработчикам значительную гибкость.

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

Одним из важных моментов является вопрос о том, следует ли организациям использовать low-code или no-code для создания критически важных приложений? Поскольку возможности платформ различны, правильный ответ: «Это зависит от ситуации».

Когда следует использовать, а когда избегать low-code или no-code

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

«Если вашей команде необходимо разработать какое-то усовершенствование для существующего набора систем, платформа low-code может стать мостом к этому. Это действительно мощный инструмент, особенно когда он позволяет „залезть в кишки“, — говорит Блэр Хэнли Фрэнк, главный аналитик консалтинговой компании ISG. — В то же время вы принимаете на себя риск как предприятие, потому что чем глубже проникают эти системы, тем более центральное место они занимают в бизнес-процессах и тем больше вы зависите от необходимости лицензирования и обслуживания этих систем для поддержания работоспособности бизнеса».

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

Опыт страховой компании

Около шести лет назад Брюс Баттлс, директор по цифровым каналам в компании медицинского страхования Humana, был отрицательно настроен по отношению к low-code/no-code, но в итоге он оказался неправ.

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

Теперь у компании есть в общей сложности семь приложений, все они построены на low-code-платформе OutSystems. Первое из них позволяет 40 тыс. независимых страховых агентов, продающих планы медицинского страхования, получать ранний доступ к информации, необходимой для оказания помощи своим клиентам, поскольку политика страхования меняется каждый год. Традиционно эти страховые агенты получали целые библиотеки PDF-файлов.

Баттлс осознал проблему и задумался о приложении как альтернативе PDF-файлами, но он не думал, что low-code — подходящий инструмент, поскольку аудитория составляла 40 тыс. агентов, а значит, платформа должна была быть масштабируемой. Его также беспокоила сложность данных.

Впервые в истории компании его команда объединила три основных набора данных. Первый содержал информацию о планах из 12 различных внутренних систем. Второй — информацию о 1500 агентах, их фотографии, рынки и региональные карты. Третий набор данных представлял собой всю информацию в сетях, связанную с планами Humana. Если бы он воспользовался традиционной разработкой приложения, ему был бы предоставлен восьмимесячный срок и бюджет, который он отказался сообщить. Используя low-code, он создал приложение за восемь недель и за четверть первоначально заявленной стоимости.

«Я сказал: „Поехали“, потому что у нас не было другой альтернативы. Восемь месяцев могли легко превратиться в двенадцать, а если сложить доллары и сроки, это становилось непомерно дорого. Компания не могла себе этого позволить. Я никого не виню в скептическом отношении к low-code. Я бы и сам не поверил, если бы не пережил это», — поделился Баттлс.

Пять лет спустя ударил COVID-19. К тому времени команда Баттлса создала приложение для поиска аптек и находилась в процессе создания приложения для поиска поставщиков. Однако в колл-центр посыпались звонки с вопросами о том, как найти место тестирования на COVID. Хуже того, для ответов на эти вопросы использовалась огромная электронная таблица. Неудивительно, что это не давало хороших результатов.

Команда Баттлса использовала результаты работы над поиском поставщиков, чтобы заменить электронную таблицу приложением, которое помогло бы колл-центру сэкономить время и избежать разочарований клиентов. Более того, застрахованные получили возможность просто зайти на сайт Humana и быстро найти место тестирования, минуя колл-центр. Приложение было создано за четыре недели по сравнению с шестью-девятью месяцами, которые, по расчетам Баттлса, потребовались бы для его создания традиционным способом.

Важность безопасности

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

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

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

«Безопасность должна быть предметом обсуждения для каждого продукта или проекта, причем необходимо рассмотреть все ее уровни. Какова правильная стратегия? Каковы инструменты, процессы и люди правильные? Я думаю, что „умные“ организации действительно рассматривают безопасность как ключевую тему», — говорит Эллиотт.

Очевидно не стоит забывать о безопасности данных и конфиденциальности, которые регламентируют GDPR и CCPA.

«Данные, с которыми вы работаете, вероятно, не менее важны, чем платформа, на которой вы работаете, — отмечает Рэнди Поттер, главный архитектор консалтинговой компании Capgemini Americas. — Если вы посмотрите на крупных поставщиков, они очень внимательны к проблемам безопасности, поэтому вы можете последовать их примеру и использовать то, что они делают в области безопасности. Я действительно считаю, что нужно быть крайне осторожным в вопросах видимости и прозрачности — поднять капюшон и заглянуть под него, чтобы иметь возможность делать конкретные настройки, а также отслеживать и контролировать».

Тем не менее, злоумышленники никогда не спят. Они постоянно придумывают новые способы компрометации приложений и платформ. Это требует от поставщиков платформ быть бдительными и проактивными в отношении безопасности как собственно платформ, так и приложений, созданных на их основе. Например, по словам Баттлса, используемая им платформа указывает на проблемы в коде и даже блокирует развертывание, чтобы обеспечить качество кода и безопасность.

Однако если злоумышленник все-таки проникнет в одну из платформ low-code/no-code, как он это сможет сделать?

«Здесь есть два сценария. Вы создаете приложение, которое раскрывает слишком много данных, поэтому оно уязвимо для утечки данных, хотя больший риск заключается в том, что злоумышленник может обнаружить проблему в самой платформе, — говорит Матиас Маду, технический директор платформы безопасного кодирования Secure Code Warrior. — Если вы разработчик, вы находитесь под давлением, чтобы сделать требуемую функциональность, поэтому я думаю, что лучшим способом продвижения вперед является более активная забота о качестве, включая аспекты безопасности».

Кроме того, по его словам, предприятия не должны стесняться излагать поставщикам платформ low-code/no-code свои требования к безопасности.

«Я думаю, что мы слишком часто строим код поверх кода, чтобы защитить его, но в конечном итоге мы должны озаботиться первопричиной слома кода, — говорит Маду. — Надо убедиться, что разработчик знает, что он делает. Чтобы следующая строка кода быть разработана с учетом безопасности, с учетом качества, в расчете на то, чтобы в дальнейшем было меньше проблем».