Ogni organizzazione enterprise possiede un patrimonio IT articolato: applicazioni, componenti software, infrastrutture, server, ambienti cloud, repository, pipeline, release, processi di business, strumenti di ticketing, documentazione tecnica, standard architetturali.

Una modifica tecnica può avere impatti funzionali. Un nodo infrastrutturale può sostenere più applicazioni. Una tecnologia obsoleta può essere distribuita in punti diversi dell’ecosistema. Un dato mancante può impedire una valutazione corretta del rischio. Per questo, nei contesti IT complessi, la conoscenza del patrimonio tecnologico deve essere un sistema vivo, aggiornato, interrogabile e governabile.

È qui che entrano in gioco Configuration Management System (CMS), database a grafo e Architecture as Code.

Oltre l’inventario statico

Molte organizzazioni dispongono di inventari applicativi, CMDB, strumenti di change management o repository documentali. Questi strumenti sono necessari, ma spesso non bastano.

Un inventario tradizionale può dire che un’applicazione esiste. Può contenere il nome del responsabile, la tecnologia utilizzata, l’ambiente di esecuzione o qualche informazione amministrativa. Ma raramente riesce a restituire una visione dinamica e relazionale dell’intero ecosistema.

In un contesto enterprise, le domande più importanti sono quasi sempre relazionali:

• quali processi di business dipendono da questa applicazione?
• quali componenti software sono coinvolti in una determinata release?
• su quali server gira un certo servizio?
• quali applicazioni usano una tecnologia non più conforme?
• quali team sono responsabili di determinati componenti del sistema?
• quali asset ereditano una criticità alta?
• se un nodo fisico non è disponibile, quali servizi vengono impattati?

Rispondere a queste domande richiede una rappresentazione delle connessioni.

Il CMS come sistema di conoscenza IT

Il CMS possiamo considerarlo come un sistema capace di centralizzare la conoscenza del patrimonio IT e di renderla interrogabile. Non un archivio statico compilato manualmente una volta per tutte, ma un sistema ricostruito e aggiornato quotidianamente a partire da sorgenti operative considerate autoritative.

Questa distinzione è fondamentale. Un CMS efficace non deve limitarsi a conservare dati: al contrario, deve raccoglierli, integrarli, verificarli e metterli in relazione. Deve permettere ai team di lavoro (architettura, change, DevOps, sicurezza e governance) di consultare una visione comune dell’ecosistema IT.

Il suo valore emerge quando diventa la base per condurre attività come:

• analisi degli impatti;
• governo delle architetture;
• supporto al change management;
• analisi del rischio;
• verifica della qualità dei dati;
• tracciabilità end-to-end;
• valutazioni di compliance;
• razionalizzazione applicativa e infrastrutturale.

In questo senso, il CMS diventa un’infrastruttura di conoscenza.

Perché un database a grafo?

La scelta di rappresentare il patrimonio IT attraverso un database a grafo, come Neo4j, è particolarmente coerente con questo tipo di esigenza. Un grafo è composto da nodi e relazioni. I nodi rappresentano entità: applicazioni, componenti, server, progetti, processi, repository, release, tecnologie. Le relazioni rappresentano i legami tra queste entità: “dipende da”, “gira su”, “appartiene a”, “viene rilasciato in”, “supporta”, “utilizza”, “è collegato a”.

Questa struttura è molto adatta a descrivere un sistema IT enterprise, perché permette di modellare non solo “che cosa esiste”, ma anche “come le cose sono collegate”. La forza del grafo consiste nella possibilità di interrogare le relazioni.

Per esempio, partendo da un server, possiamo risalire alle applicazioni ospitate, ai componenti software coinvolti, ai processi di business serviti e ai team responsabili. Oppure, partendo da una tecnologia, possiamo identificare tutte le applicazioni che la utilizzano e valutare gli impatti di migrazione o dismissione.

Il grafo consente quindi di passare da una conoscenza frammentata a una conoscenza navigabile.

Dalla frammentazione alla value chain dei dati

In un ecosistema enterprise, le informazioni sono distribuite tra più sorgenti. Parliamo di strumenti di gestione progettuale, repository di codice, sistemi di certificazione software, piattaforme di service management, strumenti di enterprise architecture, fonti infrastrutturali, ambienti cloud e piattaforme interne di gestione dei configuration item e delle release. Ogni sistema conosce bene una parte della realtà, ma nessuno la possiede per intero.

Il principio è riconoscere che ogni sistema è autoritativo per il proprio dominio. Un sistema può essere la fonte di verità per i progetti. Un altro per la storia del codice. Un altro per i processi di business o per le applicazioni funzionali. Un altro ancora per gli asset infrastrutturali oppure per i configuration item e i target di rilascio.

La value chain dei dati serve a estrarre, modellare e caricare queste informazioni nel grafo, rispettando il ruolo di ciascuna fonte. Il risultato è una visione unificata costruita a partire da fonti distribuite.

È qui che il CMS genera valore perché trasforma silos informativi in una rappresentazione coerente del sistema.

La qualità del dato come requisito di governance

Un CMS basato su grafo è potente solo se i dati sono affidabili. Per questo, la qualità del dato non è un dettaglio tecnico, ma un requisito di governance. Infatti, se una relazione è mancante, una tecnologia è censita male o un configuration item non è collegato al relativo progetto, l’intero modello perde capacità decisionale.

Detto in poche parole: un dato sbagliato può portare a decisioni sbagliate; dati mancanti possono produrre decisioni cieche.

Per evitare questo rischio, servono controlli automatici e processi di responsabilizzazione. Un configuration item dovrebbe avere relazioni coerenti con repository, target di deployment, tecnologia, applicazione e processi collegati. Ogni entità dovrebbe avere un owner. Le anomalie dovrebbero essere intercettate. La copertura del CMS dovrebbe essere misurabile. Lo stato delle pipeline di alimentazione dovrebbe essere visibile.

In altre parole, non basta costruire il grafo. È necessario saperlo governare.

Il punto di connessione tra architettura e delivery

Per connettere architettura e delivery si può scegliere di utilizzare una piattaforma custom dedicata alla gestione di soluzioni, configuration item, note di rilascio, tecnologie, building block architetturali, istanze, applicazioni, funzionalità e dati infrastrutturali. In alternativa per fare le stesse cose si possono utilizzare strumenti EA assieme a strumenti di ITSM / CMDB.

La stessa piattaforma supporta anche la creazione delle richieste di rilascio e svolge il ruolo di punto di connessione tra ambiti organizzativi e operativi che spesso tendono a rimanere separati:

• architettura
• catalogo applicativo
• change management
• release management
• DevOps
• governo delle tecnologie
• tracciabilità dei componenti.

Il fatto che ogni configuration item sia collegato a una tecnologia, e che la tecnologia possa a sua volta determinare pipeline per l’inizializzazione del codice, build e deployment, mostra un aspetto molto importante: l’architettura non resta confinata in documenti o diagrammi, ma entra nei processi operativi.

Quando la piattaforma di governo architetturale dialoga con le pipeline, l’architettura diventa eseguibile. È questo il cuore di Architecture as Code, ovvero la capacità di trasformare l’architettura in un insieme di informazioni persistenti, interrogabili, collegate e, quando possibile, azionabili.

Viste architetturali e capacità decisionale

Un ulteriore vantaggio del CMS e del grafo è la possibilità di costruire viste architetturali. Le viste permettono di rappresentare il sistema da angolazioni diverse: applicazioni, building block, tecnologie, layer architetturali, dipendenze, funzionalità, processi di business, infrastrutture.

Una vista può mostrare quali building block appartengono all’architettura di riferimento e quali no. Un’altra può classificare le applicazioni. Un’altra ancora può focalizzarsi su una singola applicazione e mostrare tutti i componenti coinvolti.

Queste viste non sono solo rappresentazioni grafiche. Sono strumenti decisionali. Permettono ai team architetture di valutare coerenza, obsolescenza, dipendenze, impatti e aree di intervento. Permettono ai team di governance di ragionare su dati concreti. Permettono ai responsabili IT di visualizzare una complessità che altrimenti resterebbe nascosta nei sistemi sorgente. In un ecosistema articolato, la visibilità è già una forma di controllo.

Impact analysis: il valore più immediato del grafo

Tra tutti i benefici di un CMS a grafo, l’impact analysis è probabilmente il più intuitivo e immediato.

Nei sistemi enterprise, capire l’impatto di un cambiamento o di un disservizio può richiedere molto tempo. Le informazioni sono spesso distribuite, incomplete o note solo a singole persone. Il grafo riduce questa dipendenza dalla conoscenza tacita. Permette di seguire le relazioni tra asset e rispondere più rapidamente a domande critiche: se un server non è disponibile, quali applicazioni sono coinvolte?
Se una tecnologia deve essere aggiornata, quali componenti devono essere analizzati?
Se un’applicazione viene modificata, quali processi di business possono essere impattati?
Se un configuration item cambia, quali release e quali ambienti sono coinvolti?

Questa capacità è particolarmente importante nei contesti regolati, dove tempi di risposta, tracciabilità e affidabilità delle decisioni sono elementi essenziali.

Dal rischio alla compliance: propagare le informazioni nel grafo

Per un cliente abbiamo affrontato un caso interessante, legato al risk assessment non financial, attraverso il modello RIDA: Riservatezza, Integrità, Disponibilità, Autenticità.

Questi valori vengono assegnati a livello applicativo e poi propagati lungo le relazioni del grafo verso configuration item e server. La logica adottata è di tipo worst case: se un asset è condiviso da più applicazioni, eredita il valore più critico.

Questo approccio è significativo perché mostra come il grafo non serva solo a descrivere dipendenze tecniche, ma anche a trasferire informazioni di rischio.

Il risultato è una prioritizzazione più oggettiva degli asset da proteggere. Abbiamo scelto di lavorare non tanto su percezioni o survey manuali, quanto piuttosto su relazioni aggiornate e tracciabili. Ogni valore può essere motivato e collegato agli elementi che lo determinano.

Anche questo è un esempio di Architecture as Code applicata alla governance: le relazioni architetturali diventano la base per calcolare e propagare criticità.

Una base per automazione, AI e continuous governance

CMS, grafo e Architecture as Code possono diventare la base per molte altre iniziative. Per esempio, un grafo affidabile può alimentare dashboard di governance. Può supportare controlli automatici sulle architetture. Può aiutare a validare merge request. Può fornire contesto a sistemi AI e RAG. Può migliorare la gestione degli incident. Può supportare audit e compliance, indirizzare percorsi di modernizzazione tecnologica. E può rendere più mirate le decisioni sul debito tecnico.

Questa è la direzione più interessante: passare da una governance basata su documenti, riunioni e conoscenza individuale a una governance continua, alimentata da dati, relazioni e automazioni.

L’AI, in particolare, può beneficiare enormemente di questo tipo di base informativa. Un assistente intelligente è tanto più utile quanto più può accedere a fonti strutturate, aggiornate e contestualizzate. Un grafo del patrimonio IT può fornire proprio questo contesto.

 

Questo è il numero 3 di 4 blog post dedicati ad alcune attività che svolgiamo per i nostri clienti.
Non perdere gli altri  blog post della miniserie. Buona lettura!