Architettura IT e manager di business

È noto che i sistemi IT sono più costosi da mantenere che da acquistare/costruire, specialmente quando il loro ciclo di vita si misura in anni. A grandi linee possiamo affermare che un euro speso per l'acquisto costa fino a sette volte di più per l'esercizio. È chiaro che per risparmiare non occorre (solo) intervenire su quel primo euro: occorre anche ricordare che ma le scelte architetturali fatte oggi influenzeranno la manutenibilità nel futuro.

I sistemi IT non concepiti per evolversi diventano costose camicie di forza che finiscono per ostacolare l'impresa.

Le conseguenze più grandi di una scelta architetturale errata sono strategiche, quindi certe scelte non devono essere appannaggio del solo reparto IT: il contributo dei manager di linea non IT diventa fondamentale. L'architettura di un progetto deve quindi conciliare il punto di vista IT con quello commerciale, per garantire un'armonia di intenti tra i due.

Gli errori nelle decisioni architetturali creano un debito tecnico il cui interesse è pagato dall'azienda in termini di maggiori costi di manutenzione e di minore agilità aziendale, e purtroppo il debito tecnico non è come un debito in banca: se quest'ultimo non posso pagarlo nei tempi pattuiri, vado dal direttore e negozio un nuovo piano di rientro, anche a interessi maggiori. Il debito tecnico è invece come un debito con la mafia: ti svegli all'improvviso in piena notte con un energumeno vicino al letto che ti punta una pistola; nella migliore delle ipotesi ti gambizza, altrimenti ti spara in fronte.

Una scelta che riguarda l'architettura IT è pertanto una scelta tra compromessi: un'azienda potrebbe promuovere sistemi ottimali dal punto di vista operativo (che ad esempio minimizza i costi) per poi ritrovarsi a pagare successivamente alcune conseguenze strategiche reali, oppure potrebbe promuovere sistemi flessibili al prezzo di conseguenze operative reali subito (costi più alti e tempi di implementazione più lunghi).

Per fare un esempio concreto, la decisione tra deployment on-premise o on-cloud dovrebbe bilanciare i costi di oggi con la variabilità economica di domani: concentrare la scelta solo su un mero paragone economico tra "quanto mi costano N server on-premise VS quanto mi costano M server su Azure/AWS" è miope.

Ovviamente questo è solo un esempio tra tanti cui applicare la logica del "soddisfa i requisiti odierni ma pianifica per le aspettative di domani".

Reparto IT e linee di business devono quindi trovare, anzi creare le opportunità per lavorare sinergicamente nel prendere decisioni migliori che bilancino le conseguenze operative (idoneità di intenti - correttezza, prestazioni, affidabilità-, sicurezza e manutenibilità) con le conseguenze strategiche (scalabilità e possibilità di evolvere).