Nel contesto delle architetture software moderne, non basta più definire un buon modello architetturale iniziale. È necessario garantire che quel modello resti coerente durante l’intero ciclo di vita del sistema. Senza un controllo continuo, l’architettura Enterprise rischia di trasformarsi in qualcosa di non più governabile, difficile da mantenere, poco agile e drammaticamente lento da virare.

In ambienti distribuiti, cloud-native e soggetti a evoluzione continua, l’architettura tende infatti a divergere rapidamente rispetto al design originario. È in questo scenario che acquista rilevanza il paradigma di Architecture as Code (AaC): parliamo della possibilità di definire, versionare, validare e governare l’architettura con logiche sempre più simili a quelle adottate nel ciclo di vita del software.

Top-down: architettura guidata da governance, principi e regole

L’approccio top-down parte dalla governance architetturale: principi, standard, ADR, pattern architetturali, reference, etc, organizzate in un architecture repository, costituiscono la “fonte di” verità” che guida la progettazione di soluzioni architetturali.

In questa logica l’architettura viene definita “by design”, usando linguaggi più strutturati e formali, come l’Architecture Definition Language (es. C4-Model), e introducendo controlli continui già nelle fasi iniziali. In altre parole: prima si stabilisce come il sistema dovrebbe essere fatto, poi si cerca di garantire che resti coerente con quella visione. Il punto chiave è che queste regole non restano in un documento, ma diventano vincoli codificati e verificabili.

In questa prospettiva, il contributo centrale di Architecture as Code è portare l’architettura dentro il software development lifecycle. L’architettura non è più un artefatto statico, esterno al delivery, ma diventa un oggetto versionato e continuamente validabile. Abilita automatismi e controlli sia in fase di design sia in fase di implementazione, con l’obiettivo di verificare in modo continuo la conformità del design rispetto a principi, pattern e decisioni architetturali codificate nel repository.

Fitness function e validazione continua dell’architettura

Uno degli aspetti più interessanti è l’uso delle fitness function come meccanismo di validazione architetturale. Le regole architetturali vengono formalizzate e trasformate in controlli eseguibili: possono essere testate automaticamente in fase di design, integrate in CI/CD, applicate in fase di build e persino come gate di deployment.

Questo significa trattare l’aderenza architetturale come una proprietà testabile, e non come un semplice obiettivo dichiarativo.

Dal punto di vista operativo, il vantaggio è evidente: si passa da una governance documentale a una governance eseguibile, riducendo il rischio che l’implementazione diverga progressivamente dai principi enterprise.

Bottom-up: ricostruire l’architettura reale dalle evidenze tecniche

Se il top-down rappresenta la dimensione intenzionale del sistema, il bottom-up rappresenta quella osservabile. Infatti, l’approccio bottom-up parte dall’analisi di ciò che esiste realmente: codice, metriche, asset di deployment, configurazioni runtime, telemetria, informazioni derivate da API o da metriche infrastrutturali e applicative. L’obiettivo è ricostruire l’architettura as-is, ovvero il modello effettivo del sistema in esecuzione o dell’ecosistema tecnico implementato.

È un approccio più “osservativo”, che parte dalle evidenze tecniche e prova a ricomporre il disegno effettivo del sistema. Attraverso le evidenze raccolte, è possibile capire quali componenti comunicano tra loro, con quale protocollo, attraverso quali namespace o punti di transito. Quindi possiamo ricostruire un architecture model fondato su dati osservabili. Questo permette non solo di descrivere l’esistente, ma anche di confrontare runtime, build-time e design-time per identificare eventuali incoerenze definite Architecture Drift.

Il valore vero? La combinazione dei due approcci

L’architettura acquista capacità di governo quando riusciamo a mettere in relazione il modello progettato con quello osservato. Questo confronto permette di trasformare l’architettura da rappresentazione teorica a sistema di controllo continuo della complessità.
Ecco perché il vero valore emerge dalla combinazione tra approccio top-down e approccio bottom-up.

Qui entra in gioco il concetto di ciclo di governance continua (Architecture Governance as code). Il processo è piuttosto netto: si raccolgono gli elementi top-down e bottom-up, si confrontano, si misura la differenza (Drift Detection) tra ciò che è stato progettato e ciò che realmente è in esecuzione in produzione. Si apre quindi una fase di classificazione e decisione. Ogni drift viene categorizzato, prioritizzato e associato a un livello di severity. Poi viene portato all’attenzione degli stakeholder per decidere come intervenire.

La drift detection è una capability chiave di questo paradigma. Non si tratta solo di rilevare una discrepanza, ma di inserirla in un processo strutturato di governance. In questo contesto, il drift è la deviazione tra architettura progettata e architettura rilevata. Una volta identificata, può portare a 3 esiti principali:

• aggiornamento della produzione per riallinearla al design
• aggiornamento del design e delle decisioni architetturali per riflettere il comportamento ritenuto corretto
• tracciamento della deviazione come debito tecnico.

Dalla documentazione statica a un architecture repository eseguibile

Gli approcci tradizionali hanno un limite evidente: molte linee guida architetturali restano ancora confinate in documenti lunghi e poco strutturati, spesso scritti in linguaggio naturale, e quindi difficili da trasformare in controlli automatici e ripetibili. Per questo è fondamentale estendere la logica dell’“as code” anche alla governance architetturale: codificare principi, pattern, ADR, Standard, reference, e vincoli in forma dichiarativa e versionata, così da costruire un architecture repository “as code”. Questo repository diventa il riferimento comune che abilita un modello standard di raccordo tra approccio top-down e approccio bottom-up, rendendo possibile confrontare intenzione progettuale e realtà osservata in modo continuo.

Questo approccio combinato apre a una governance molto più matura: l’architettura può essere versionata e validata. In più, il processo di drift detection può essere ulteriormente automatizzato. In termini pratici, significa aumentare il livello di automazione sia nella verifica della conformità architetturale sia nella rilevazione delle deviazioni operative.

Implicazioni per Enterprise architecture e Platform engineering

In chiave più ampia, questo paradigma ha implicazioni importanti per chi, come noi, si occupa di enterprise architecture, software design, architecture governance, DevSecOps e Platform engineering. Architecture as Code ci permette di collegare in un unico framework operativo repository di regole, pipeline di validazione, osservabilità runtime e processi decisionali. Non è soltanto una tecnica di modellazione: è un meccanismo per rendere l’architettura una parte attiva del delivery e del controllo di qualità del sistema.

In ambienti complessi, permette di ridurre l’erosione architetturale, aumentare la tracciabilità delle decisioni, formalizzare meglio la compliance tecnica e rendere il design meno dipendente da artefatti descrittivi non eseguibili. In sostanza, si introduce una governance architetturale evidence-based, in cui la conformità viene misurata (e non solo presunta) e continuamente riallineata.

Dall’architettura “dichiarata” all’architettura “governata”

In un contesto in cui sistemi e piattaforme evolvono continuamente, l’architettura non può più essere trattata come un deliverable statico prodotto una volta sola. Deve diventare un processo continuo, integrato nel ciclo di delivery e supportato da evidenze tecniche misurabili.

Architecture as Code abilita esattamente questo passaggio: dalla governance basata su documentazione alla governance basata su regole eseguibili, validazione automatica e osservabilità. Il takeaway è semplice: top-down definisce l’intento, bottom-up descrive la realtà, ma è la loro combinazione che permette di governare davvero la complessità e prevenire l’architecture drift. Per le organizzazioni che vogliono scalare DevOps e cloud-native in modo sostenibile, il prossimo passo è iniziare a trattare l’architettura come un asset vivo: versionato, verificabile e continuamente riallineato.

Questo è il secondo di tre blog post nati da un intervento alla Moka Conference 2026
Hai perso il primo post? Eccolo e buona lettura!