L’Architettura come destino: perché la Business Agility non si compra, si progetta

 
C’è un momento preciso, nelle riunioni di board o negli steering committee dei grandi programmi di trasformazione digitale, che conosco bene. È l’istante in cui sullo schermo compare il diagramma dell’architettura IT: un mosaico di rettangoli, simboli e acronimi che condensano, in forma astratta, la complessità di un modello concettuale capace di collegare strategia, processi, dati e tecnologie, definendo come l’azienda funziona oggi e come può evolvere domani. In quel preciso secondo, ho notato spesso che molti top manager avvertono un’irresistibile urgenza di controllare le notifiche sul cellulare. 

Non si tratta di disinteresse, né di superficialità. È la manifestazione spontanea di una frattura semantica: per troppo tempo l’Enterprise Architecture è stata raccontata come una rappresentazione tecnica della complessità dei Sistemi Informativi, una disciplina per specialisti, focalizzata su standard e controlli tecnologici, ma codificata in un linguaggio estraneo alle logiche decisionali del board. 

Per dirla senza giri di parole: è stata percepita come un virtuosismo di modellazione, indispensabile per far girare la macchina, ma non come un vero asset strategico capace di generare valore e abilitare nuovi scenari competitivi. 

Nell’era della pressione concorrenziale continua e dell’Intelligenza Artificiale, distogliere lo sguardo da quello schema è però un lusso che nessun board può più permettersi. Oggi, l’architettura non può essere considerata un dettaglio tecnico di supporto, ma l'elemento strutturale che definisce, e in ultima istanza scrive, il destino competitivo dell’organizzazione. 

La sfida per CIO e leadership tecnologica non è chiedere al board di diventare esperto di tecnologia, ma imparare a tradurre l’architettura nel linguaggio del business: portare al tavolo non diagrammi tecnici, ma alternative strategiche comprensibili, argomentate sulla base di mindset, competenze e leve economiche su cui il vertice fonda le proprie decisioni. 

Se non riusciamo a rendere evidente come i sistemi sono progettati per evolvere (o per fallire), stiamo di fatto delegando la strategia al caso o, peggio, stiamo ipotecando il futuro dell’azienda legandolo a un debito tecnico che diventerà via via più insostenibile. 

Tuttavia, vorrei sgombrare il campo da un equivoco frequente, soprattutto per chi guida realtà con un’importante eredità tecnologica. Ripensare l’architettura non significa indebolire la governance costruita negli anni, ma rafforzare la capacità di prevedere gli impatti, gestire la complessità e ridurre i rischi strutturali. Nei contesti più regolamentati e interdipendenti, l’obiettivo non è “cambiare tutto”, ma preservare la continuità operativa mentre si crea lo spazio per evolvere. 

Riportare l’architettura al centro delle decisioni strategiche consente proprio questo: trasformare il cambiamento da reazione tattica a processo governato, trasparente e allineato alle priorità del business. Quando il modo in cui i sistemi sono progettati diventa chiaro e comprensibile, l’impresa acquisisce una leva concreta per orientare in modo sicuro e prevedibile il proprio futuro digitale. 

Per capire la gravità del momento, bisogna mettersi nei panni di chi governa la tecnologia nelle grandi imprese tradizionali. Nei servizi finanziari, nelle utility, nelle telco, nella grande distribuzione e nel manufacturing complesso, il cuore dell’efficienza operativa è racchiuso in un patrimonio applicativo custom costruito in anni: motori di pricing, sistemi di pianificazione, logiche di supply chain, regole di autorizzazione e controllo. 

È lì che risiede la vera business logic dell’azienda: non nelle presentazioni, ma nell’insieme di eccezioni, vincoli regolamentari e decisioni stratificate che definiscono come il business funziona davvero, giorno per giorno. 

Per molti CIO ed Enterprise Architect questo patrimonio è allo stesso tempo l’asset più prezioso e il vincolo più pesante. Dopo anni spesi a garantirne l’affidabilità e a contenerne i costi, oggi sono chiamati a trasformarlo sotto una pressione inedita: clienti che si aspettano esperienze fluide, pure-player digitali che alzano l’asticella competitiva, l’irruzione dell’Intelligenza Artificiale e richieste di time-to-market sempre più brevi. 

Il risultato è spesso un portafoglio applicativo crescente e frammentato, stratificato da decenni di decisioni tattiche, implementato in tecnologie eterogenee e spesso obsolete, dove ogni modifica comporta rischi operativi significativi.  

Questo scenario è confermato dalle evidenze dell’Osservatorio Cloud Transformation. Security e Compliance sono le principali priorità segnalate dalle grandissime aziende italiane: il 72% delle imprese ha avviato progetti di cybersecurity e gestione dei rischi informatici, mentre il 39% si è concentrato sull’adeguamento alle nuove normative europee (Osservatorio Cloud Transformation, 2025 [1]) 

Di fronte a questa complessità, la reazione tipica oscilla fra due estremi: da un lato il continuare a “tenere insieme” l’esistente con soluzioni tattiche che nel tempo finiscono per diventare sempre meno percorribili e più costose; dall’altro l’illusione del salto generazionale, affidato a replatforming radicali, migrazioni massive al cloud in logica “lift and shift” o all’adozione di suite SaaS con la speranza che la tecnologia esterna possa, da sola, risolvere problemi che sono invece intrinsecamente architetturali e organizzativi. 

È una reazione comprensibile, e in alcuni casi può anche rappresentare un passaggio necessario. Tuttavia, quando non è accompagnata da un reale cambio di paradigma nel pensiero architetturale, il rischio è quello di ottenere risultati solo parziali. Spesso ci si ritrova semplicemente a sostituire una forma di complessità con un’altra: un monolite on-premise può lasciare il posto a un “monolite distribuito” sul cloud, talvolta persino più oneroso da governare; oppure l’adozione di molteplici soluzioni SaaS può portare a una frammentazione dei processi e dei dati, generando nuove isole informative difficili da integrare davvero. 

Il risultato non è agilità, ma una nuova forma di rigidità, più sofisticata e meno visibile. La trappola non è il software vecchio: è l’idea che l’architettura sia un progetto “con un inizio e una fine”, invece che un sistema vivente che deve evolvere continuamente (Mainetti, S. 2024) [2].

Se il “grande rifacimento” è spesso un miraggio costoso, ma allo stesso tempo non è più possibile restare immobili di fronte alle esigenze di evoluzione, la domanda è: qual è l’alternativa concreta? 

La risposta non sta nell’ennesimo nuovo insieme di tecnologie, ma in un doppio salto di paradigma. 

Il primo è strategico: la progettazione architetturale deve diventare una leva di management condivisa dal vertice aziendale, non una pratica tecnica confinata all’IT. L’Enterprise Architecture va liberata dal ruolo di funzione di audit per assumere quello di strumento decisionale primario (Ross, J. W., Weill, P., & Robertson, D. C., 2006) [4]. 

Il secondo è culturale: non possiamo continuare a utilizzare questa leva con le vecchie logiche predittive, disegnando un’ipotetica Architettura Target pluriennale come se il contesto non cambiasse. In mercati dove gli equilibri si spostano ogni trimestre, la stabilità statica di un piano rigido è il rischio maggiore, non un punto di forza. 

È qui che entra in gioco il concetto, ben descritto in (Ford, N., Parsons, R., & Kua, P., 2022) [3], di Architettura Evolutiva. Un’architettura evolutiva non è semplicemente un sistema che “si può modificare” (con tempo e budget sufficienti, lo sono tutti), ma un sistema progettato strutturalmente per il cambiamento incrementale: l’evoluzione non è un’eccezione da gestire, ma il principio guida del design. 

I principi chiave di questo approccio sono tre. Il primo è la modularità, che permette di intervenire su una parte del sistema senza rischiare di compromettere tutto il resto: come ristrutturare una stanza senza dover abbattere l’intera casa. Il secondo è la scelta tecnologica mirata, perché non esiste una piattaforma in grado di rispondere efficacemente a ogni esigenza: ogni componente deve poter adottare la tecnologia più adatta al proprio scopo, senza vincoli “totalizzanti”. Il terzo è l’introduzione delle Fitness Functions, una sorta di “cruscotto vitale” che monitora costantemente se l’architettura sta evolvendo nella direzione giusta, misurando aspetti come la velocità di modifica, la resilienza del sistema o la facilità con cui è possibile integrare nuove capacità, inclusa l’AI.

Perché tutto questo è urgente proprio ora? Perché l’Intelligenza Artificiale, e in particolare l’emergere dell’Agentic AI (agenti autonomi che prendono decisioni), ha infranto il presupposto di prevedibilità su cui abbiamo costruito l’IT negli ultimi trent’anni. 

Fino a ieri, il software era sostanzialmente deterministico: a parità di input, il comportamento era sempre lo stesso. Con l’AI, questo paradigma salta: i modelli apprendono, cambiano, si degradano, vanno monitorati, versionati, sostituiti in esercizio (model drift). L’AI consuma dati in flusso, non solo dati “a stock” depositati in data warehouse statici. Le applicazioni diventano composte dinamicamente: assemblano servizi e capacità, invece di essere codificate una volta per tutte. 

Le analisi sul paradigma della Agentic Organization (McKinsey & Company. 2025) [5] mostrano la crescita di sistemi in cui agenti AI lavorano accanto alle persone. In questo scenario, gli agenti non sono più “tool intelligenti”, ma veri utenti dell’architettura. 

Immaginiamo un agente che gestisce la supply chain: legge gli stock, prevede la domanda, ordina componenti. Non ha bisogno di interfacce grafiche, ma di API affidabili, dati coerenti in tempo reale e tracciabilità delle decisioni per garantire auditabilità. 

Se l’architettura è ancora una collezione di monoliti disconnessi, con dati duplicati e incoerenti, l’agente AI è destinato a fallire o, peggio, a prendere decisioni sbagliate. Il rischio concreto è la nascita di “nuovi silos dell’AI”: chatbot e wrapper “intelligenti” costruiti sopra sistemi incapaci di esporre le informazioni corrette. È l’equivalente di costruire un attico di lusso su fondamenta che stanno cedendo: può impressionare in demo, ma amplifica il debito tecnico. 

La via d’uscita non è mettere l’AI ovunque, ma costruire progressivamente un’architettura componibile, in cui le singole capacità di business (es. “Calcola Prezzo”, “Verifica Disponibilità”, “Valuta Rischio”) sono esposte come moduli indipendenti, riutilizzabili sia da persone sia da agenti. 

Affrontare uno scenario così fluido con un’architettura rigida significa provare a manovrare un transatlantico in un torrente di montagna: non importa quanto potente sia il “motore AI” che acquistate, se la struttura non è progettata per cambiare direzione, l’impatto è solo questione di tempo.

A complicare il quadro si aggiunge il tema della governance, in una duplice accezione: economica e normativa. Partiamo dai costi, un tema che spesso emerge con forza nelle discussioni di approfondimento manageriale, ben oltre quanto rilevato dalle semplici survey. La dipendenza crescente dagli hyperscaler ha creato una evidente asimmetria di potere negoziale: assistiamo a variazioni unilaterali dei contratti e a un aumento dei costi dei servizi che non sempre corrisponde a un aumento del valore estratto. Se l’architettura è monolitica o rigidamente legata a servizi proprietari di un singolo provider (vendor lock-in), l’azienda perde la sua sovranità economica: subisce i prezzi senza poter reagire. 

Anche qui, l’architettura non è neutra. Un approccio evolutivo e modulare abilita una gestione finanziaria proattiva (FinOps): non solo permette di monitorare i consumi, ma offre la flessibilità tecnica per spostare carichi di lavoro o cambiare servizi se le condizioni economiche diventano sfavorevoli. Il controllo dei costi smette di essere un esercizio contabile a posteriori e diventa una capacità di design. 

Parallelamente, c'è la pressione della conformità. L’introduzione massiva dell’AI e il crescente peso della regolamentazione (GDPR, AI Act, DORA…) spingono molte imprese verso un modello difensivo. Questo scenario è confermato dalle evidenze dell’Osservatorio Cloud Transformation: Security e Compliance sono le principali priorità segnalate dalle grandissime aziende italiane (Osservatorio Cloud Transformation, 2025 [1]). 

La contrapposizione tra compliance e agilità è però, in larga parte, un falso dilemma. È proprio attraverso un’architettura evolutiva che diventa possibile conciliare entrambe: sostituendo i vecchi gate (posti di blocco manuali e discreti nel tempo) con guardrail automatici e continui. 

È la logica della Policy as Code: le regole non sono solo scritte in documenti, ma incorporate nei processi di sviluppo e rilascio. Se un modello è addestrato su dati non anonimizzati, la pipeline blocca il deploy; se un’API non rispetta gli standard di sicurezza, il rilascio fallisce prima ancora della produzione. La sicurezza non è più un freno burocratico, ma una proprietà strutturale dell’architettura. Le evidenze dei report DORA mostrano chiaramente come l’automazione della governance sia correlata a maggiore frequenza di rilascio, minori tempi di recupero e maggiore stabilità operativa (DORA, DevOps Research and Assessment, 2024) [6]. 

In questo modo, la governance smette di essere un apparato ispettivo che rallenta, e diventa un abilitatore di velocità sicura: la Business Agility non nasce “nonostante” la governance, ma attraverso una governance finalmente progettata per il cambiamento continuo, introducendo un controllo più solido, continuo e affidabile, meno dipendente da interventi manuali e più resistente alla complessità dei sistemi legacy. 

Arrivati a questo punto del ragionamento, è naturale che un CEO o un CIO di una realtà legacy possa pensare: “Tutto sensato, ma per noi è ingestibile.” È una reazione comprensibile, quasi fisiologica. La complessità accumulata negli anni, la quantità di vincoli tecnici e organizzativi, l’urgenza dei progetti in corso: tutto sembra remare contro qualsiasi tentativo di ripensamento profondo. 

Eppure, è proprio per rispondere a questa sensazione di “ingovernabilità” che vale la pena fermarsi un momento e osservare il quadro complessivo delle forze in gioco. 

Le pressioni competitive, la complessità del legacy, la discontinuità introdotta dall’AI e il crescente peso della compliance non sono fenomeni isolati: agiscono insieme, e nel farlo impongono un diverso modo di progettare l’impresa. L’immagine che segue rappresenta questo insieme come un Modello delle Forze e dei Fondamenti dell’Architettura Evolutiva. 

L’idea centrale è semplice: nessuna di queste forze può essere affrontata con un approccio statico. Per questo servono fondamenti architetturali capaci di generare adattamento continuo: modularità orientata al valore, osservabilità delle prestazioni, guardrail automatici che sostituiscono i controlli manuali, e un percorso di evoluzione incrementale che evita big bang rischiosi. 

L’immagine rappresentata in figura è il modo più diretto per rendere esplicita la relazione fra pressioni esterne e capacità interne. Da una parte le spinte che obbligano l’impresa a muoversi; dall’altra i principi che le permettono di farlo senza perdere stabilità, sicurezza e coerenza. 

• Modularità orientata alle capacità di business (Packaged Business Capabilities, PBC) 

La scomposizione del sistema non avviene più per moduli tecnici, ma in base alle capacità di business che l’azienda deve esprimere (ad esempio: “Calcola Prezzo”, “Verifica Pagamento”, “Gestisci Reso”, …). Questo permette di evolvere una singola capacità senza dover toccare l’intero sistema, riducendo drasticamente rischio e complessità. 

• Guardrail automatici, non gate manuali (Policy-as-Code) 

La governance non si basa più su approvazioni puntuali e controlli manuali, ma su regole codificate e automatizzate. Le policy-as-code impediscono in modo proattivo deviazioni da standard di sicurezza, compliance e qualità, consentendo ai team di muoversi più velocemente senza compromettere il controllo. 

• Architettura osservabile (Continuous Evolutionary Metrics) 

Le qualità architetturali non sono più verificate a posteriori, ma monitorate in modo continuo attraverso Fitness Functions: metriche che misurano resilienza, lead time to change, cost-to-serve, readiness all’AI e altri indicatori critici del comportamento del sistema. È l’equivalente di un cruscotto vitale che segnala in tempo reale se l’architettura sta evolvendo nella direzione attesa e fornisce la trasparenza necessaria per prendere decisioni economiche consapevoli, inclusa la gestione continua dei costi di consumo.

Arrivati al termine di questo percorso, il messaggio che emerge è chiaro: la Business Agility non è un attributo che si acquista, né un risultato che deriva automaticamente dall’introduzione di nuove tecnologie. L’agilità architetturale non è una scelta stilistica, ma una necessità per mantenere continuità operativa, ridurre rischi strutturali e preservare nel tempo la capacità competitiva dell’impresa 

La tentazione di affrontare la complessità attraverso “grandi sostituzioni tecnologiche” è comprensibile, ma raramente risolutiva. Le forze che oggi ridisegnano il contesto competitivo (pressione del mercato, eredità del legacy, discontinuità introdotta dall’AI e dinamiche regolatorie) non possono essere gestite con modelli statici di progettazione né con architetture nate per un mondo prevedibile. 

L’Architettura Evolutiva offre una risposta diversa: realista, progressiva, sostenibile. Un modello in cui il cambiamento non è un progetto, ma una proprietà strutturale dell’impresa. 

Per questo, l’agilità non si crea adottando framework o strumenti, ma costruendo un sistema capace di adattarsi in modo continuo. Un sistema in cui: 

• le capacità di business possono evolvere senza traumi, 
• la governance è automatizzata e non rallenta l’innovazione, 
• le metriche diventano segnali vitali e non verifiche a posteriori, 
• la modernizzazione non interrompe il business, ma lo accompagna. 
  
  In questo quadro, il ruolo del CIO evolve gradualmente. Non è più il “custode del passato tecnologico”, ma il co-architetto della strategia aziendale, la figura in grado di dimostrare al board che l’architettura non è un costo tecnico: è la condizione necessaria per qualsiasi futuro digitale. 
  
  La domanda cruciale, allora, non è semplicemente: “Quale tecnologia dobbiamo adottare?” La domanda veramente decisiva diventa: “La nostra architettura è progettata per evolvere insieme alle tecnologie che scegliamo?” 
  
  Solo chi saprà rispondere affermativamente potrà sfruttare appieno il potenziale dell’AI, evitare che il debito tecnico freni la crescita, accelerare l’innovazione e mantenere continuità operativa anche in scenari di mercato instabili. 
  
  Nel mondo che abbiamo davanti, la tecnologia rimane un acceleratore formidabile, ma è l’architettura che ne determina la scalabilità, la sicurezza e la capacità di creare valore nel tempo. 
  
  Per questo, l’architettura non è un livello tecnico nascosto: è il fondamento strategico su cui poggiano tutte le scelte future. Ed è per questo che va progettata con cura, con visione e con la consapevolezza che, oggi, la forza competitiva di un’impresa dipende dalla sua capacità di evolvere. 
  
  

Riferimenti 

[1] Osservatorio Cloud Transformation (2025). Il Cloud Tra AI e Sovranità digitale: strategie e politiche industriali per un nuovo ecosistema digitale 2025. School of Management, Politecnico di Milano. 

[2] Mainetti, S. (2024). Dai silos monolitici alla business agility: il ruolo delle architetture evolutive. LinkedIn Pulse. Articolo LinkedIn: https://www.linkedin.com/pulse/dai-silos-monolitici-alla-business-agility-il-ruolo-delle-mainetti-licwf. 

[3] Ford, N., Parsons, R., & Kua, P. (2022). Building Evolutionary Architectures: Automated Software Governance (2nd ed.). O'Reilly Media. 

[4] Ross, J. W., Weill, P., & Robertson, D. C. (2006). Enterprise architecture as strategy: Creating a foundation for business execution. Boston, MA: Harvard Business School Press. 

[5] McKinsey & Company. (2025). The agentic organization: Contours of the next paradigm for the AI era. McKinsey & Company. 

[6] DORA (DevOps Research and Assessment). (2024). Accelerate State of DevOps Report 2024. Google Cloud.