Переосмысление технологического долга: баланс риска и ценности в ИТ-системах

Технологический долг, также известный как технологический дефицит, — это термин с различными определениями. От стоимости обновления технологии до последствий неправильного принятия решений — неадекватность стратегических технологических мер отражает нереализованный потенциал.

Согласно отчету Deloitte за 2022 год, одним из факторов, способствующих дефициту технологий, является отсутствие у членов совета директоров знаний, позволяющих задавать обоснованные вопросы и согласовывать технологии со стратегией. В разработке программного обеспечения это подразумевает затраты на дополнительную работу в результате выбора ограниченного решения, а не принятия долгосрочного подхода.

Случаи дефицита технологий, такие как инцидент с Southwest Airlines в конце 2022 года, связаны с устаревшей системой расписания. Как ИТ-директор, объясняющий технологический долг, необходимо учитывать некоторые аспекты:

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

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

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

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

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

Включение платформ no-code таких как AppMaster.io способствует быстрой разработке приложений без ущерба для качества или актуальности. Предоставляя платформу для создания визуально структурированной схемы, бизнес-логики и endpoints REST API и WSS, AppMaster позволяет предприятиям создавать масштабируемые и эффективные приложения, снижая при этом риски, связанные с технологическим долгом.