Articolo del Mese - Aprile 2014

Le architetture per ridurre il debito tecnico

by Mike Rosen

Analogamente ai debiti finanziari, nelle aziende e soprattutto nei reparti IT, vi sono anche quelli tecnici, derivanti da scelte frettolose o errate. Ma la soluzione c’è: adottare l’architettura giusta

Tutti i recenti discorsi sui debiti sovrani che si leggono sulla stampa mi hanno fatto pensare a un altro tipo di debito, più vicino e più familiare a un architetto di sistemi: il “debito tecnico” tuttora presente nell’IT e nelle aziende. Ma di cosa si tratta? Steve McConnell spiega che il «debito tecnico si riferisce al ritardo nel lavoro tecnico che si verifica quando vengono prese scorciatoie tecniche, di solito per seguire tempistiche software guidate dai calendari. Proprio come accade con i debiti finanziari, alcuni debiti tecnici possono essere relativi a scopi aziendali importanti, ma altri sono semplicemente controproducenti».
Un’altra valida definizione è quella di Martin Fowler: «Fare le cose in maniera sbrigativa ci mette in condizione di avere un debito tecnico, che è simile a quello finanziario. Come accade con un indebitamento finanziario, anche quello tecnico prevede gli interessi, sotto forma di sforzi in più che dobbiamo fare negli sviluppi futuri a causa della scelta di fare le cose di fretta. Possiamo scegliere di continuare a pagare gli interessi, oppure possiamo pagare tutto subito, ridisegnando il progetto da uno sommario a quello migliore. Anche se il costo iniziale è maggiore, si avrà un guadagno derivante dal dover pagare interessi ridotti nel futuro». Nonostante queste definizioni si concentrino sullo sviluppo di nuovo software, il debito tecnico matura nei sistemi se li manteniamo e li facciamo evolvere senza prendere il tempo necessario per rimodellarli in modo che possano accogliere le modifiche. Nel corso del tempo, questo si traduce in sistemi fragili che non possono essere modificati e che non possono soddisfare le esigenze di business in continua evoluzione. Quindi, il costo del debito tecnico non è semplicemente il costo per risolvere il problema, ma è anche il costo che si riflette sul business, dovuto alla presenza di sistemi rigidi e fragili che non possono essere modificati per soddisfare le esigenze di business attuali, oltre alla perdita di opportunità per l’azienda. E probabilmente ognuno di noi conosce sistemi di quel tipo.

IL COSTO DEL DEBITO TECNICO - Una buona quantità di lavoro è già stata impiegata per calcolare il costo del debito tecnico. Per esempio, Sonar propone un prodotto che calcolerà il debito. Nel calcolo di Sonar, il debito è uguale alla somma del costo per sistemare le duplicazioni più il costo per sistemare le violazioni; più il costo per commentare le API pubbliche; più il costo per sistemare le complessità non coperte; più il costo per portare le complessità sotto la soglia. Questa definizione è chiaramente incentrata sul costo per sistemare il debito e non sul costo per l’azienda in termini di perdita di opportunità a causa del debito.
Il debito tecnico ha due forme di base: non intenzionale e intenzionale. Il primo tipo di debito è generalmente il risultato di scarse pratiche di codifica o di project management, mentre i debiti intenzionali nascono sulla base di decisioni esplicite. Una delle fonti da me consultate definisce queste decisioni come “informate”, ma mi chiedo quanto i manager, il business, o gli amministratori IT abbiano una reale conoscenza dell’impatto delle loro decisioni sul debito tecnico dell’azienda.
Il debito tecnico comprende le cose interne che si sceglie di non fare subito (involontariamente o volutamente), ma che ostacoleranno gli sviluppi futuri qualora rimangano incompiute. Tra queste, vi sono il differimento della riprogettazione e non tenere conto delle architetture e degli standard. Va detto che il debito tecnico non comprende le funzionalità rimandate.

COSTO E COMPLESSITÀ - In tutta la letteratura sul debito tecnico, non ho visto alcun riferimento all’architettura: ritengo che questa sia una grave omissione. Uno degli obiettivi dell’architettura è quello di evitare costi e complessità inutili (e di conseguenza il debito tecnico). Ma come può essere utile in questo l’architettura? L’architettura definisce gli standard per le piattaforme, i dati, la sicurezza e per tante altre cose. Non seguire gli standard comporta incongruenze, ridondanze e ulteriori costi operativi, come dire una sorta di debito che potrà continuare a generare interessi.
L’architettura aiuta invece ad affrontare la complessità, soprattutto quella a livello di impresa (piuttosto che quella a livello di progetto individuale). La complessità a livello di azienda comporta un debito tecnico in termini di integrazione di sistemi, oltre che di ridondanza e incoerenza dei sistemi. Anche in questo caso, si tratta di forme di debito tecnico. Per fare un altro esempio, l’architettura contribuisce a garantire l’allineamento dei sistemi con gli obiettivi e le strategie di business, oltre che a evitare i costi dei sistemi non allineati. In conclusione, l’architettura può contribuire ad affrontare molti dei fattori che sono identificati nei calcoli dei costi (duplicazioni, violazioni, complessità…). Oppure, dall’altro lato della medaglia, possiamo usare i calcoli dei costi del debito tecnico per quantificare parte del valore dell’architettura in termini di riduzione del debito e di annullamento di costi. C’è da sperare che riusciremo a gestire questi aspetti meglio del nostro governo.