Low-code — это альтернатива традиционным процессам разработки, но эта модель продолжает привлекать не только сторонников, но и критиков. О том, что необходимо учесть лицам, принимающим решения, на портале InformationWeek рассказывает Майк Мейсон, руководитель глобального отдела технологий Thoughtworks.

Инструменты и платформы Low-code позволяют создавать полезные программные системы без необходимости написания и поддержки больших пользовательских баз кода. Некоторые прогнозы говорят, что к 2025 г. до 70% новых приложений могут быть созданы с их помощью, а постоянная нехватка разработчиков заставляет компании искать новые способы ускорения разработки ПО и снижения рабочей нагрузки, и все больше организаций изучают, что они могут получить благодаря Low-code.

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

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

Когда использовать и когда не использовать Low-code

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

Сценарий № 1. Реагирование на нехватку разработчиков

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

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

Сценарий № 2. Поддержка быстрого роста бизнеса

На ранних стадиях расширения бизнеса Low-code может помочь быстро создавать новые возможности и услуги без значительных затрат ресурсов. Однако организации должны понимать, что многие решения, созданные с помощью этих платформ, могут со временем потребовать замены. В противном случае они могут столкнуться с тем, что основные части их инфраструктуры построены на негибком фундаменте.

Сценарий № 3. Создание нового, критически важного для бизнеса ПО

Чем важнее какая-то часть ПО для вашего бизнеса, тем меньше вероятность того, что Low-code является правильным вариантом. Критически важные для бизнеса приложения должны иметь возможность легко масштабироваться, расти и трансформироваться; делать это становится сложнее, если это не согласовано бизнесом и ИТ.

Сценарий № 4. Расширение возможностей бизнес-подразделений

Если ваша цель — предоставить подразделениям бизнеса бóльшую технологическую автономию и дать возможность вашей команде стать гражданскими разработчиками, использование инструментов Low-code — отличный способ. Этот инструментарий прост для новых пользователей, и команды могут быстро начать управлять и расширять возможности для удовлетворения собственных потребностей.

Важность баланса

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

Эта версия оказалась очень непрактичной, как с точки зрения нереалистичных ожиданий, которые она возлагает на Low-code, так и с точки зрения того, что она позиционирует Low-code и традиционные процессы разработки как противоположности.

Вопрос не должен звучать так: «Low-code или традиционное кодирование?». Он должен звучать так: «Где Low-code может наилучшим образом поддержать и дополнить наших опытных разработчиков?».

Разрешив и поощрив использование Low-code в правильных случаях, вы сможете ускорить доставку, сократить время цикла и быстро удовлетворить потребности бизнеса без отказа от текущей практики разработки.

Вопросы, требующие ответа перед выбором платформы Low-code

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

Скорее всего, вы захотите провести собственную углубленную оценку, но ответы на следующие вопросы — хорошее начало:

1. Сколько людей будет использовать создаваемое вами ПО? Больше пользователей — больше потребностей, к которым нужно адаптироваться, и больше шансов, что ПО станет критически важным для бизнеса и выйдет за пределы возможностей Low-code.

2. Вы хотите создать основное или вспомогательное (периферийное) ПО? Чем ближе ваше ПО к ядру, тем важнее, чтобы оно оставалось как можно более гибким, масштабируемым и совместимым — что должно заставить вас отказаться от использования Low-code для его создания и поддержки.

3. Может ли вспомогательное ПО, которое вы создаете сегодня, стать критическим по мере его внедрения? Если вы уже знаете, что системы, которые необходимо построить или модернизировать, являются критически важными для бизнеса, они вряд ли станут правильным сценарием использования Low-code, если только вы не готовы принять ограничения этой платформы.

4. Готова ли ваша команда стать гражданскими разработчиками? Чтобы Low-code полностью раскрыл свой потенциал, команды должны обладать определенным уровнем знаний в области ПО, чтобы овладеть им и начать создавать свои собственные возможности.

Low-code: один размер не подходит для всех

Low-code не заменяет кодирование, но для определенного набора сценариев использования является очень мощной технологией. Однако если бы организация отказалась от команды разработчиков и использовала платформы Low-code для предоставления полного контроля над разработкой бизнес-командам, они были бы крайне ограничены в возможностях.

Оптимальные зоны применения Low-code — на периферии, когда результаты проверяются ИТ-экспертами и эта модель используется наряду с традиционными методами и ресурсами разработки.