La promessa originaria della trasformazione digitale era, almeno in parte, quella di distribuire. Distribuire capacità di calcolo, applicazioni, dati, servizi e processi, superando l’idea di un’infrastruttura aziendale chiusa dentro il perimetro fisico dell’organizzazione e costruendo ecosistemi molto più flessibili, interoperabili e scalabili. È esattamente ciò che è accaduto sul piano operativo. Sul piano infrastrutturale, però, il risultato è stato più ambiguo: mentre le imprese moltiplicavano applicazioni, SaaS, API, piattaforme e fornitori, una quota crescente di questa apparente diversità finiva per poggiare sugli stessi nodi tecnologici.

È qui che il concentration risk assume una dimensione strategica. Il problema non consiste semplicemente nel dipendere da un fornitore esterno, né coincide con la necessità di verificare la sicurezza della propria supply chain digitale. La questione è più profonda: aziende convinte di avere costruito ecosistemi diversificati possono scoprire che fornitori apparentemente indipendenti condividono, a monte, la stessa infrastruttura cloud, lo stesso servizio di autenticazione, lo stesso CDN, la stessa piattaforma DNS, lo stesso componente software o una medesima infrastruttura di pagamento.

La diversificazione visibile, in altre parole, può nascondere una concentrazione invisibile.

Il paradosso della diversificazione digitale

Negli ultimi anni molte organizzazioni hanno correttamente lavorato per ridurre la dipendenza da singoli sistemi e singoli fornitori. Sono aumentate le applicazioni specialistiche, le integrazioni, i servizi cloud e le piattaforme verticali, mentre interi processi sono stati distribuiti attraverso ecosistemi tecnologici sempre più articolati.

Osservata dalla superficie, questa architettura sembra offrire una naturale diversificazione del rischio. Un CRM proviene da un vendor, il sistema documentale da un altro, la piattaforma HR da un terzo, i servizi di comunicazione da un quarto e quelli dedicati alla sicurezza da altri ancora. Il problema emerge quando l’analisi smette di fermarsi al primo livello della catena.

Vendor differenti possono utilizzare lo stesso hyperscaler. Servizi differenti possono affidarsi allo stesso identity provider. Applicazioni senza alcuna relazione commerciale tra loro possono dipendere dalla medesima infrastruttura DNS o da componenti software condivisi. Persino fornitori che un’azienda considera reciprocamente alternativi possono avere alle proprie spalle dipendenze tecnologiche quasi identiche.

È questa sovrapposizione a trasformare un normale incidente tecnico in un potenziale evento sistemico. Non conta più soltanto quanto sia resiliente ogni singolo fornitore, ma quanto siano correlate le dipendenze dell’intero ecosistema.

Il correlated failure cambia la geometria del rischio

La gestione tradizionale del rischio tende a ragionare per elementi relativamente separati: si valuta un servizio, se ne misura la criticità, si analizza il fornitore e si predispongono eventuali strategie di continuità. Questo modello continua a essere necessario, ma diventa insufficiente quando più elementi considerati indipendenti possono fallire contemporaneamente per la stessa causa.

Il concetto di correlated failure descrive precisamente questa condizione. Due o più servizi non sono realmente indipendenti se condividono una dipendenza critica capace di renderli indisponibili nello stesso momento.

La conseguenza, dal punto di vista manageriale, è rilevante perché modifica la percezione stessa della ridondanza. Avere due fornitori non significa necessariamente avere due alternative. Avere più applicazioni non significa aver distribuito il rischio. Avere procedure di backup o continuità differenti non garantisce resilienza se tali procedure dipendono, direttamente o indirettamente, dallo stesso punto infrastrutturale.

Il concentration risk nasce quindi anche da una sorta di illusione architetturale: ciò che appare separato nei contratti, nelle dashboard e negli organigrammi tecnologici può essere fortemente interconnesso nella realtà operativa.

Ed è proprio questa distanza tra rappresentazione organizzativa e infrastruttura reale a rendere il fenomeno particolarmente difficile da governare.

Conoscere il fornitore non basta più

Per anni la maturità nella gestione delle terze parti è stata associata alla capacità di conoscere meglio i propri vendor: solidità, sicurezza, livelli di servizio, continuità operativa, conformità e gestione degli incidenti. Oggi questa conoscenza deve necessariamente estendersi oltre il perimetro contrattuale immediato.

La domanda non è più soltanto “da chi dipendiamo?”, ma “da chi dipendono coloro dai quali dipendiamo?”.

La differenza può sembrare semantica, mentre è profondamente strategica. Significa passare da una rappresentazione lineare della catena di fornitura digitale a una lettura reticolare delle dipendenze, nella quale ogni servizio costituisce un nodo collegato ad altri nodi e alcune infrastrutture finiscono inevitabilmente per assumere un peso sproporzionato.

Un’azienda potrebbe, per esempio, classificare dieci piattaforme SaaS come dieci dipendenze differenti e distribuire conseguentemente il proprio rischio. Se sette di quelle piattaforme utilizzassero lo stesso provider infrastrutturale o condividessero un servizio critico comune, la fotografia effettiva sarebbe molto diversa da quella riportata nella tradizionale vendor map.

Il problema, peraltro, non riguarda esclusivamente l’IT. Se un nodo condiviso sostiene contemporaneamente processi commerciali, logistici, amministrativi e di relazione con il cliente, la sua indisponibilità smette di essere un semplice incidente tecnologico e diventa rapidamente un problema di continuità aziendale.

Dalla vendor map alla dependency map

È probabilmente qui che dovrà evolvere una parte importante della governance tecnologica nei prossimi anni. Le organizzazioni dispongono spesso di inventari applicativi, registri dei fornitori, classificazioni dei servizi critici e procedure di business continuity, ma molto più raramente possiedono una rappresentazione realmente dinamica delle dipendenze condivise.

Una dependency map dovrebbe permettere di comprendere non soltanto quale applicazione supporta un determinato processo, ma quali infrastrutture consentono a quell’applicazione di funzionare, quali servizi esterni intervengono nella sua erogazione e quali di questi ricompaiono all’interno di altri processi aziendali.

Il valore strategico non consiste nell’ottenere una cartografia tecnologica perfetta, obiettivo difficilmente realistico in ecosistemi complessi e continuamente mutevoli, quanto nell’individuare i nodi la cui centralità potrebbe generare effetti sproporzionati rispetto alla loro apparente rilevanza.

In questo scenario anche la nozione di “servizio critico” deve essere parzialmente ripensata. Un componente apparentemente secondario può diventare estremamente critico non per la funzione che svolge singolarmente, ma perché viene utilizzato contemporaneamente da decine di altri servizi.

La criticità, quindi, non è più soltanto una proprietà del singolo asset: diventa una proprietà della rete di relazioni nella quale quell’asset è inserito.

La resilienza non coincide con l’aggiunta di un altro provider

La risposta più immediata al rischio di concentrazione potrebbe sembrare la moltiplicazione dei fornitori, ma sarebbe una semplificazione pericolosa. Una strategia multi-vendor o multi-cloud, per esempio, produce resilienza soltanto quando genera una reale indipendenza tra le alternative disponibili; in caso contrario rischia di aumentare complessità, costi e superficie operativa senza eliminare le dipendenze fondamentali.

La questione strategica non è quindi quanti provider siano presenti, ma quanto siano realmente indipendenti i percorsi attraverso i quali vengono erogate le funzioni critiche.

Questo porta la resilienza digitale su un terreno più maturo rispetto alla semplice ridondanza. Significa progettare scenari di continuità considerando il fallimento simultaneo di servizi differenti, interrogarsi sulle dipendenze comuni, verificare se i meccanismi di emergenza utilizzino infrastrutture realmente alternative e comprendere quali processi aziendali verrebbero coinvolti da un singolo evento a monte.

È un cambiamento importante anche per il management, perché sposta il concentration risk fuori dal dominio esclusivamente tecnico. Quando una parte significativa del business dipende da pochi nodi infrastrutturali, la questione riguarda investimenti, continuità operativa, procurement, compliance, sicurezza e capacità dell’organizzazione di mantenere margini di autonomia decisionale.

Rendere visibile ciò che oggi rimane dietro i servizi

La prossima fase della maturità digitale potrebbe essere meno legata all’aggiunta di nuove tecnologie e molto più alla capacità di comprendere le relazioni tra quelle già presenti. Dopo anni nei quali la velocità di adozione è stata uno dei principali indicatori della trasformazione, diventa necessario misurare anche la struttura delle dipendenze che quella velocità ha prodotto.

Non significa immaginare organizzazioni completamente indipendenti dai grandi ecosistemi tecnologici, né inseguire un’autosufficienza difficilmente compatibile con l’economia digitale contemporanea. Significa, piuttosto, trasformare una dipendenza inconsapevole in una dipendenza conosciuta, misurata e governabile.

Perché il vero rischio della concentrazione non nasce necessariamente dal fatto che esistano pochi grandi nodi sui quali poggia una parte significativa dell’economia digitale. Nasce quando le organizzazioni non sanno quanto quei nodi siano diventati centrali per il proprio funzionamento.

La domanda da portare quindi nei tavoli di governance non riguarda semplicemente il numero dei fornitori presenti nel portafoglio tecnologico. È molto più scomoda, perché obbliga a guardare oltre i confini contrattuali e dentro l’architettura reale dell’ecosistema: quanti dei tuoi fornitori “diversi” dipendono, in realtà, dalla stessa infrastruttura?

La resilienza del prossimo ciclo digitale potrebbe dipendere proprio dalla capacità di rispondere a questa domanda prima che sia un incidente a farlo al posto nostro.