Enterprise Architecture e Sovereignty

Il sistema informativo di una grande azienda italiana racconta quasi sempre la stessa storia. Sopra, applicazioni recenti, spesso cloud native. Sotto, un nucleo di sistemi costruiti in stagioni diverse, con tecnologie diverse, spesso di fornitori diversi, tenuti insieme da integrazioni che nessuno ricorda per intero. 

Il problema emerge quando l'insieme smette di essere governabile: un CIO non riesce più a rispondere con sicurezza a domande semplici come quali processi dipendono da quali sistemi, dove risiedono i dati critici, quali fornitori sono diventati difficili da sostituire, quanto è realmente possibile cambiare rotta. 

Il costo di questa perdita di visibilità è già misurabile. I CIO stimano che il debito tecnico rappresenti tra il 20% e il 40% del valore dell'intero patrimonio tecnologico, con il 10-20% del budget per nuovi prodotti dirottato ogni anno per farvi fronte. Meno di un terzo delle trasformazioni organizzative riesce a migliorare le performance in modo duraturo; per le trasformazioni digitali il dato scende al 16%.

L’88% delle aziende usa l’AI, ma meno del 10% dei processi integra pienamente agenti AI. Quando manca un disegno sistemico alle spalle, il rischio si sposta dal restare fermi al dover fare marcia indietro su ciò che è già in produzione.  

Molte organizzazioni hanno investito in formazione e sperimentazione, con agenti costruiti caso per caso su contesti assemblati ad hoc. Quel valore resta però legato alla persona che lo ha costruito e vive nella sessione di chi lo usa, senza diventare capacità organizzativa: il 79% delle aziende introduce l’AI senza scomporre sistematicamente il workflow da automatizzare, il fattore più correlato all’impatto reale sui risultati di business.  

Quando manca questo disegno, il rischio si sposta dal restare fermi al dover fare marcia indietro su ciò che è già in produzione. Entro il 2027, quattro imprese su dieci dovranno retrocedere o disattivare agenti già rilasciati per problemi di governance emersi solo dopo

Per noi l’Enterprise Architecture non impone standard dall’alto: è una pratica di condivisione della conoscenza tra Direzione ICT, business e fornitori. Estendiamo il perimetro tradizionale di sistemi e dati anche agli agenti e alle decisioni che questi devono poter prendere. I nostri Enterprise Architect entrano già nei primi colloqui conoscitivi e di analisi, prima ancora che il progetto prenda forma. Il ruolo ha oggi una definizione precisa, quella di Forward Deployed Engineer: una persona che lavora dentro il contesto del cliente fin dall'inizio, per far emergere le fonti di valore reali prima di disegnare qualsiasi soluzione. 

1. Mappare le dipendenze, oltre alle applicazioni 

 
Una matrice delle dipendenze che colleghi processi, dati, integrazioni, fornitori e competenze. Se questo elemento cambia, come impatta sul business? Il debito tecnico che emerge da questa mappa non è solo un rischio da segnalare: diventa il criterio con cui decidere cosa modernizzare per primo e cosa, invece, vale la pena mantenere così com'è. 

2. Classificare i dati per valore strategico e livello di controllo 

 
Distinguiamo dati operativi e dati critici, chiarendo proprietà, accesso, vincoli normativi e portabilità — primo passo per un exit plan credibile. 

3. Collegare l’Enterprise Architecture alla strategia 

 
Il lavoro converge in una Business Capability Map, costruita insieme ai responsabili di business: vede ogni iniziativa non solo per i suoi benefici tecnici, ma per i suoi effetti su flessibilità e capacità decisionale futura. 

Questo lavoro non si esaurisce nel disegno iniziale. Manteniamo observability e controllo lungo tutta la vita applicativa, fino alla gestione in esercizio, così le decisioni prese in run restano coerenti con l'architettura definita a monte. E lo facciamo un pezzo alla volta con un percorso costruito insieme al cliente, che coordina le priorità della Direzione IT con le esigenze del business man mano che emergono.

Da governance descrittiva a governance decisionale 

 
Una governance descrittiva si limita a fotografare l’esistente: cataloga sistemi, applicazioni, flussi. Una governance decisionale è in grado di abilitare scelte strategiche, perché rende esplicite le opzioni realmente disponibili, non solo lo stato attuale delle cose.

I benefici toccano più livelli dell'organizzazione, dall'allineamento tra business e IT fino alla libertà di rivedere le proprie scelte tecnologiche nel tempo. Questi i principali: