Управление долгом за архитектурные технологии

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

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

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

Если бы была рекомендована более совершенная платформа, в приложении Lotus Notes не потребовалось бы много логики. Исходный код было сложно поддерживать. Улучшения структуры данных привели к серьезному рефакторингу базового кода, не говоря уже о запуске серверных заданий для преобразования существующих данных. Не заставляйте меня рассказывать о создании отчета.

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

Давайте немного подробнее рассмотрим концепцию архитектурных и технологических долгов на макроуровне.

Архитектурный технический долг (ATD)

Библиотека архитектурно-технического долга (ATD) Университета Карнеги-Меллон дает следующее определение ATD:

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

В документе «Краткий ответ: как управлять техническим долгом архитектуры» (опубликовано 22 сентября 2023 г.) Gartner Group определяет ATD следующим образом:

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

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

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

Для обеспечения качества кода, наблюдаемости и SCA существуют проверенные инструменты, такие как Sonarqube, Datadog, New Relic, GitHub и Snyk. Однако сегмент архитектуры программного обеспечения отстает и не имеет проверенных решений.

Это прискорбно, учитывая тот факт, что ATD неизменно является самым крупным и наиболее разрушительным типом технического долга, как указано в документе « Измерить? Управляй этим? Игнорируй это? Специалисты по программному обеспечению и технический долг », исследование 2015 года, опубликованное Карнеги-Меллоном.

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

Если не принять меры, ATD может продолжать расти с возрастающей скоростью, как показано на этой простой иллюстрации:

Без смягчения последствий долг архитектуры в конечном итоге достигнет критической точки для измеряемого базового решения.

Управление АТД

Прежде чем мы сможем справиться с АТД, мы должны сначала понять проблему. Десмонд Туту однажды мудро сказал: «Есть только один способ съесть слона: по кусочку».

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

Shift-left можно реализовать двумя разными способами при управлении ATD:

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

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

Архитектурная наблюдательность

Архитектурная наблюдаемость дает инженерным командам возможность постепенно устранять архитектурные отклонения в своих сервисах на макроуровне. Фактически, в начале этого года газета Wall Street Journal сообщила, что стоимость устранения технического долга составила 1,52 триллиона долларов США в статье «Невидимая проблема стоимостью 1,52 триллиона долларов: неуклюжее старое программное обеспечение».

Чтобы добиться успеха, инженерное лидерство должно полностью соответствовать следующим организационным целям:

• Устойчивость — быстрое восстановление после неожиданных инцидентов.
• Масштабируемость — масштабирование в соответствии с требованиями клиентов.
• Velocity — предоставление функций и улучшений в соответствии с ожиданиями продукта.
• Пригодность для облака — преобразование устаревших решений в эффективные предложения облачных услуг.

Недавно я обнаружил платформу vFunction для наблюдения за архитектурой, управляемую искусственным интеллектом, которая ориентирована на следующие результаты:

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

Кроме того, платформа vFunction обеспечивает дополнительное преимущество, предоставляя путь миграции для перехода от монолитных решений к облачным решениям. Как только команды модернизируют свои платформы, они смогут постоянно наблюдать за их постоянным дрейфом. Если у компаний уже есть микросервисы, они могут использовать vFunction для обнаружения сложности в распределенных приложениях и устранения зависимостей, влияющих на отказоустойчивость и масштабируемость. В любом случае, после реализации, команды инженеров смогут смягчить ATD задолго до того, как будет достигнута критическая точка.

На приведенном выше рисунке команды разработчиков могут уменьшить технический долг в рамках каждого выпуска благодаря реализации платформы vFunction и лежащему в ее основе подходу «сдвиг влево».

Заключение

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

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

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

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

Если вам интересно узнать больше о решении vFunction, вы можете прочитать о них больше здесь .

Хорошего дня!