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.
Mike Rosen
Mike Rosen è director per l’Enterprise Architecture presso il Cutter Consortium e direttore editoriale del SOA Institute. Ha esperienza pluriennale nell’architettura e nella progettazione di applicazioni e oltre 20 anni di esperienza nello sviluppo di prodotti per tecnologie distribuite come DCE, CORBA, DCOM, J2EE, Web Services, Transaction Processing e Messaging. È speaker di fama internazionale e autore di numerose pubblicazioni, tra cui “Applied SOA: Architecture and Design Strategies”. È stato chief enterprise architect presso IONA Technologies, dove era responsabile dello sviluppo dell’intera architettura di prodotto della piattaforma di Web Services di nuova generazione di IONA e della creazione dell’architettura di riferimento per la realizzazione di applicazioni su questa piattaforma.
Mike Rosen presenterà a Roma per Technology Transfer i seminari “Allineare Business e IT: un approccio Business Architecture” il 5 e 6 maggio 2014 e “Le scelte architetturali che funzionano” il 7 e 8 maggio 2014.
