Il debito tecnico dell'architettura IT è quel tipo di debito tecnico causato da una deriva architetturale derivata da decisioni non ottimali, violazioni dell'architettura del prodotto target definito e anche da best practice architetturali di settore e da compromessi architettonici adottati per velocizzare la software delivery. In questo talk commentiamo il report di Gartner dedicato a questo tema. Per scoprire come modernizzare il vostro IT e risolvere il debito scrivete a sales@profesia.it

1. © 2024 vFunction 1

2. “Entro il 2026,
l’80% del
Technical Debt
sarà Architectural
Technical Debt”
Source: Gartner, Measure and Monitor Technical Debt With 5
Types of Tools, Tigran Egiazarov, Thomas Murphy, 27, February
2023
Per aiutare le loro organizzazioni a
misurare e monitorare con successo il
debito tecnico, i responsabili
dell'ingegneria del software
dovrebbero: prevenire le lunghe
rielaborazioni architettoniche
introducendo strumenti per analizzare
il debito tecnico architetturale e
monitorare la quantità di debito
nell'architettura del software.
“

3. © 2024 vFunction
Affrontare il debito tecnico a livello di
codice è come pulire e riordinare la
casa. Affrontare il debito
architettonico è come fare la
manutenzione del riscaldamento, del
tetto e delle fondamenta. La casa non
cade se è sporca, ma perde e potrebbe
crollare se i problemi strutturali non
vengono trattati. . .
Gartner: How to Manage Architecture Technical Debt Sept 2023
“

4. © 2024 vFunction
Fattori che contribuiscono all'accumulo del debito
tecnico dell'architettura IT
● Refactoring Incompleto dovuto a una issue
urgente o una nuova priorità.
● Le violazioni delle dipendenze Architetturali
portano a una fragilità del sistema e a componenti
altamente accoppiati.
● Scelte di software design povere e inconsistenti,
mancanza di modelli e politiche uniformi o
mancanza di competenze.
● Le licenze il funzionamento e il supporto di
componenti non standard.
● Requisiti non funzionali non identificati, evoluzione
tecnologica, frameworks e languaggi obsoleti
progetti OSS interrotti, lock-in tecnologico
Business Factors
● Decisioni Architetturali per velocizzare il time
to market.
● Priorità costante di personalizzazione e
sviluppo di nuove feature
● Requisiti poco chiari dal business nella fase
iniziale di sviluppo.
● Cambiamenti nel business, mercato o
ambiente.
● incertezza dei casi d’uso dovuti alla mancanza
di conoscenza del mercato o delle esigenze dei
clienti all’inizio dello sviluppo.
Technical Factors
Reference: Gartner: Factors Leading to Architecture Technical Debt (ATD)

5. © 2024 vFunction
Source: Carnegie Mellon University Software Engineering Institute. Neil A. Ernst,
Stephany Bellomo, Ipek Ozkaya, Robert L. Nord, and Ian Gorton, 8/2015
Classifica delle fonti di debito tecnico
Fortune 500 e US Government su un campione di 1.800 professionisti
Ranked #1
Ranked #2
Ranked #3
2024 Roadmap
Supported Today

6. © 2024 vFunction
Sintomi del ATD — Dagli addetti ai lavori
Reference: Building and evaluating a theory of architectural technical debt in software-intensive systems (Elsevier, 2021)
Lo sviluppo richiede molto più tempo del previsto, a volte perché ci si imbatte in un
problema sconosciuto, altre volte perché non si riesce a dimensionare correttamente il
progetto su cui si sta lavorando, perché l'architettura è molto più complessa di quanto ci
si aspettasse.
- Senior Software Engineer
“
Gli sviluppatori non riuscivano a implementare nuove funzionalità, a causa delle
numerose righe di codice implementato; per aggiornare l’applicazione mettevano in atto
una serie di workaround che risultavano però controproducenti a causa del debito
architetturale evidente...
- Chief Technology Officer
“
Non abbiamo mai rispettato un piano di rilascio, li abbiamo spesso posticipati. Pochi giorni
prima del rilascio, ho chiesto alle parti interessate se volevamo andare in produzione. Era
una pessima idea farlo, stavamo ancora correggendo dei bug. Ma non mi sono espresso.
Anche gli stakeholder dovevano rendersi conto che il debito li stava danneggiando".
“

7. © 2024 vFunction
Affrontare il problema "strategico":
Deterioramento del portafoglio applicativo
Cost, Complexity, and Risk Fit, Value and Agility

8. © 2022 vFunction 8
Business Case - Debito tecnico architettonico nel tempo
(con e senza Architectural Observability)
Architecturally Observed
Portfolio of Applications
Unobserved Portfolio of
Applications
Fix
(TODOs)
Release Release Release n…
A
rchitectural
Tech
Debt
Time
Debt
Fix
(TODOs)
Fix
(TODOs)
Debt

9. © 2024 vFunction
Una piattaforma di osservabilità architettonica (AOP) guidata
dall'intelligenza artificiale che osserva continuamente l'architettura delle
applicazioni, consentendo agli architetti di trovare, correggere, gestire e
prevenire il debito tecnico architettonico, migliorando così la modularità, la
scalabilità e la velocità di progettazione.

10. © 2024 vFunction
Code Quality,
SAST DAST
Software
Composition Analysis
(SCA)
APM/
Observability
● Performance monitoring
● Fault/Outage early detection
Software
Architecture
● Business logic
modularity/complexity
● Logical domains mapping
● Architectural Complexity
● Architectural Drift
● Static code quality analysis
(bugs, code smells)
● Static & dynamic security &
vulnerability analysis
● Component mapping
● 3rd party vulnerabilities and upgrades
● Aging frameworks
Gestire il Debito Tecnico nelle Organizzazioni

11. © 2024 vFunction 11
Ruoli e Strutture che Gestiscono il Debito Tecnico

12. © 2024 vFunction
L’assenza di Architectural Observability conduce
al Technical Debt
L’assenza di Architectural Observability ostacola l’innovazione, e contribuisce all’accumulo di
Architectural Technical Debt che portano a un rallentamento della progettazione, scalabilità limitata e
zero elasticità causando costi insostenibili, downtime & una scarsa user experience.
Progettazione
Lenta
Scarsa
esperienza
del
cliente/utente
NRR
in
calo
Scalabilità limitata
(no Elasticity)
Test e Cicli di
rilascio lunghi
Impossibile
soddisfare
Business Reqs
Difficile aumentare
Developers
Diminuzione
Innovazione

13. © 2024 vFunction
One Time
Plan
M
onitor
Operate
D
e
p
l
o
y
Release
T
e
s
t
Build
CI CD
Code
Architectural Observability (AO) – Shift Left for Architects
No AO CI-CD vs. AO CI-CD
Plan
M
onitor
Operate
D
ep
lo
y
Release
Test
Build
C
o
d
e
CI CD
+
A
O
+ TODOs
+
A
O
T
O
D
O
s
Continuous Architectural Observability