Новый отчет vFunction «Microservices, Monoliths, and the Battle Against $1.52 Trillion in Technical Debt» показывает, что архитектурная сложность является главным виновником образования технического долга, сообщает портал ITPro Today.

Новое исследование показало, что технический долг, особенно связанный с проблемами архитектуры ПО, оказывает огромное влияние на инновации предприятий и экономику в целом.

vFunction опросила более 1000 руководителей архитектурных и инженерных подразделений, а также руководителей отделов разработки в разных отраслях на предмет технического долга, связанного с архитектурой ПО. Респонденты назвали архитектурный технический долг, вызванный структурными недостатками, отсутствием модульности и нарушением принципов проектирования, самым разрушительным и оказывающим самое сильное влияние видом долга для приложений.

Основные выводы исследования включают:

  • Технический долг обходится экономике США в 1,52 трлн. долл. ежегодно.
  • 51% организаций выделяет более 25% ИТ-бюджета на устранение технического долга.
  • Архитектурный технический долг — самый вредный тип, влияющий на приложения.
  • Монолитные архитектуры сталкиваются с бóльшими проблемами скорости разработки, масштабируемости и отказоустойчивости, чем микросервисные.
  • 40% считают «сдвиг влево» с помощью архитектурной наблюдаемости ключом к повышению отказоустойчивости.

Разрыв между монолитами и микросервисами

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

Компании с монолитной архитектурой в 2,1 раза чаще сталкиваются с проблемами, связанными с низкой скоростью разработки, ограниченной масштабируемостью и низкой отказоустойчивостью.

57% компаний с монолитной архитектурой выделяют более 25% ИТ-бюджета на устранение технического долга, в то время как среди компаний с микросервисной архитектурой таких компаний всего 49%.

Отсутствие четкой ответственности

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

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

По его словам, ответственность варьируется в зависимости от того, кого вы спросите, и разные организации решают эту проблему по-разному. «Лично я считаю, что проблему технического долга должен решать глава ИТ-организации, например CIO; в противном случае она не будет решаться должным образом», — говорит он.

Почему технический долг продолжает оставаться недооцененным

По словам Рафалина, когда речь заходит о техническом долге, предприятия сталкиваются с тем, что он называет синдромом «лягушки в кипятке».

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

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

Хотите быстро решить проблему технического долга? Это вряд ли

Если организации хотят быстро справиться с техническим долгом, с чего им следует начать и что делать?

По словам Рафалина, реальность такова, что проблема технического долга, который накапливался в течение длительного времени, не имеет быстрого решения, особенно если это архитектурный технический долг. Не существует какой-то одной строчки кода или обновления фреймворка, которые решат эти архитектурные проблемы.

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

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

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

«Используя наблюдаемость архитектуры и „смещаясь влево“ для ее улучшения, организации могут сократить количество перебоев, уменьшить проблемы масштабируемости и ускорить темпы разработки, — говорит Рафалин. — Устранение первопричин и совершенствование архитектуры дает преимущества в долгосрочной перспективе».