Le aziende globali sono sulla buona strada per spendere oltre mille miliardi di dollari in servizi di cloud pubblico entro il 2026. La giustificazione di tale spesa si basa su proiezioni che vanno da convincenti a straordinarie: una ricerca di IDC mostra un ROI del 334% in tre anni e un periodo di ammortamento di dieci mesi per le organizzazioni che implementano la modernizzazione in modo efficace. I benchmark di AWS citano una crescita del fatturato del 43% e una riduzione della spesa IT del 33% per carichi di lavoro completamente modernizzati. I numeri sono reali. Rappresentano risultati raggiungibili. Il problema è che la maggior parte delle organizzazioni non li sta raggiungendo.
I dati di PwC mostrano che il 54% delle aziende riporta un valore minimo dagli investimenti nel cloud, nonostante la crescente adozione. Flexera rileva che l'84% delle organizzazioni considera la visibilità dei costi una priorità assoluta, eppure solo il 38% monitora attivamente il ROI del cloud in tutte le unità aziendali. Gartner riporta che i budget per il cloud superano le previsioni in media del 17%. Il divario tra ciò che la modernizzazione del cloud promette e ciò che le organizzazioni effettivamente sperimentano non è un fallimento tecnologico. È un fallimento in termini di visibilità, e inizia ben prima che il primo carico di lavoro venga migrato.
Prima di tutto, sappi cosa stai spostando.
SMART TS XL Prima di iniziare la migrazione, vengono mappate tutte le dipendenze, i componenti non funzionanti e i rischi strutturali.
Maggiori InformazioniLa scomoda verità sul fallimento della modernizzazione del cloud
Le organizzazioni stanno spendendo miliardi per le migrazioni al cloud, eppure molte non riescono a ottenere il ROI promesso. Spostare i carichi di lavoro sul cloud senza affrontare i problemi di visibilità operativa, costi incontrollati e strumenti frammentati non fa altro che aggravare la situazione. Vale la pena soffermarsi sull'espressione "moltiplicare il problema". La migrazione al cloud non neutralizza il debito tecnico, e il debito tecnico non scompare nel cloud; semplicemente, aumenta.
Lo schema di fallimento è ricorrente in tutti i settori. I team adottano Kubernetes e l'architettura basata sui servizi senza l'osservabilità, la maturità CI/CD o l'allineamento del team necessari per supportarla. Il risultato: un monolite distribuito con complessità operativa ma senza alcun vantaggio. Un'organizzazione che migra un monolite legacy senza comprenderne la struttura interna, le dipendenze e i flussi di dati non ottiene la flessibilità del cloud. Si ritrova invece con bollette del cloud più salate e gli stessi problemi architetturali da cui cercava di fuggire.
L'insegnamento più importante tratto dai programmi falliti è che i fallimenti sono per lo più di natura organizzativa, non tecnica. La tecnologia funziona. Spesso, invece, le strutture organizzative, gli incentivi e i processi decisionali non sono adeguati. Una responsabilità poco chiara, KPI errati e team privi dell'autorità o delle competenze necessarie per l'esecuzione: queste sono le cause principali dei fallimenti che emergono dalle analisi post-mortem. Ma dietro ogni fallimento organizzativo si cela un problema di informazione: la migrazione è stata pianificata senza una conoscenza precisa di ciò che veniva migrato.
Che cos'è realmente il divario di osservabilità?
Nel contesto del cloud, l'osservabilità si riferisce alla capacità di comprendere lo stato interno di un sistema a partire dai suoi output esterni, ovvero di rispondere alle domande "cosa sta succedendo e perché" basandosi sui dati di telemetria. L'osservabilità è diversa dal monitoraggio. Il monitoraggio avvisa dell'indisponibilità di un servizio. L'osservabilità, invece, fornisce la causa del guasto, il primo punto di connessione al servizio che ha smesso di funzionare e la catena di dipendenze tra i servizi guasti al momento del guasto.
Il divario di osservabilità nei programmi di modernizzazione del cloud non riguarda principalmente la telemetria, le metriche, i log e le tracce in fase di esecuzione dopo il deployment dell'applicazione. Riguarda piuttosto un divario precedente e ben più rilevante: l'assenza di visibilità strutturale sull'applicazione prima dell'inizio della migrazione.
Questo precedente divario di osservabilità ha tre dimensioni:
Cosa contiene effettivamente l'applicazione. La documentazione descrive ciò per cui il sistema è stato progettato. Il codice sorgente effettivo riflette quindici anni di modifiche, soluzioni alternative e decisioni non documentate che nessun diagramma architetturale può rappresentare. Un piano di migrazione basato sulla documentazione è un piano di migrazione basato su una mappa incompleta.
Come i componenti si connettono tra loro. Le dipendenze tra moduli, servizi e sistemi determinano la sequenza di migrazione, il rischio e la reale portata di qualsiasi modifica proposta. Le organizzazioni che definiscono le opportunità del cloud attraverso iniziative isolate, anziché una trasformazione a livello di portfolio, vedono i vantaggi derivanti dalle nuove implementazioni vanificati dalle spese di gestione continue dei sistemi invariati. Una valutazione isolata produce una comprensione frammentata e migrazioni che scoprono le dipendenze tra i componenti a metà dell'esecuzione, quando la scoperta è più costosa.
Cosa comporterà effettivamente la migrazione. Senza un modello di dipendenza strutturale, la valutazione dell'impatto si riduce a una stima. La stima dell'impatto produce piani di migrazione con una portata sconosciuta. Ed è proprio in una portata sconosciuta che le proiezioni sul ritorno sull'investimento (ROI) del cloud sono destinate a fallire.
Dove si crea il divario: prima, durante e dopo la migrazione
Prima della migrazione: l'illusione della valutazione
La maggior parte dei programmi di migrazione al cloud inizia con una fase di valutazione. I primi 90 giorni sono dedicati alla valutazione: inventario del patrimonio dati, punteggio di predisposizione all'IA, definizione della baseline FinOps e analisi delle lacune di governance. Questo approccio sembra sistematico. In pratica, tuttavia, la valutazione è quasi sempre superficiale per quanto riguarda il codice applicativo.
Gli strumenti di rilevamento dell'infrastruttura inventariano i server. Gli strumenti di scansione del portfolio producono punteggi di complessità. Ma l'analisi strutturale effettiva del codice applicativo, ovvero quali funzioni esistono, come si richiamano a vicenda, quali componenti condividono dati tramite file o database anziché API esplicite, quale codice è obsoleto e può essere escluso completamente dall'ambito di applicazione, questa analisi viene raramente eseguita perché gli strumenti per effettuarla su portfolio di linguaggi di programmazione aziendali non fanno parte del toolkit standard dei fornitori di soluzioni di migrazione.
Mancanza di osservabilità fin dal primo giorno. I dashboard relativi allo stato di salute della pipeline, alla qualità dei dati e ai costi, aggiunti dopo il lancio, costano tre volte di più rispetto alla loro implementazione iniziale. Lo stesso principio si applica all'osservabilità strutturale del portfolio applicativo: il costo di scoprire la complessità architetturale dopo l'inizio della migrazione è di gran lunga superiore al costo di scoprirla prima.
Durante la migrazione: il problema della scoperta delle dipendenze
Il momento più costoso in un programma di migrazione al cloud è quando una dipendenza sconosciuta prima della migrazione viene scoperta a metà dell'esecuzione. Il team si è impegnato a rispettare una tempistica. L'infrastruttura è stata predisposta. I contratti con i fornitori di servizi di migrazione sono stati stipulati. E poi, improvvisamente, emerge come complicazione imprevista un copybook COBOL condiviso utilizzato da 300 programmi, o uno schema di database condiviso da cui leggono 12 servizi, o un job batch che alimenta sei client a valle tramite un'interfaccia file.
Senza un'osservabilità unificata e un'automazione intelligente, la modernizzazione del cloud spesso sposta questi problemi in un ambiente distribuito più complesso anziché risolverli. Il monolite si scompone in microservizi. Le dipendenze implicite tra i suoi componenti diventano chiamate di rete tra servizi distribuiti. Il problema dell'osservabilità non viene eliminato, ma distribuito, il che lo rende più difficile da individuare.
Dopo la migrazione: il crollo della visibilità dei costi
L'84% delle organizzazioni identifica la gestione della spesa per il cloud come la sfida principale, con budget che superano le previsioni del 17%. Allo stesso tempo, il 69% dei responsabili IT segnala sforamenti di budget nella spesa per il cloud.
Gli sforamenti di budget del cloud sono direttamente riconducibili al divario di osservabilità pre-migrazione. I carichi di lavoro che erano stati stimati come semplici candidati per una migrazione "lift-and-shift" si rivelano richiedere un refactoring. Le applicazioni che erano state considerate di piccole dimensioni generano elevati costi di trasferimento dati perché nessuno ha mappato i flussi di dati a monte e a valle durante la fase di valutazione. Il codice obsoleto migrato insieme al codice attivo viene eseguito in container che vengono fatturati al millisecondo. Misurare il tempo di attività del sistema anziché i risultati aziendali significa che i team ottimizzano per i risultati sbagliati.
Secondo Flexera, solo il 38% delle aziende monitora attivamente il ROI del cloud in tutte le unità aziendali. Le organizzazioni non possono monitorare un ROI che non possono misurare, né possono misurarlo rispetto a una base di riferimento che non hanno definito con precisione prima dell'inizio della migrazione.
L'osservabilità strutturale necessaria ai programmi di migrazione
Colmare il divario di osservabilità richiede un tipo di analisi diverso da quello fornito dalla scoperta dell'infrastruttura. Richiede l'analisi del codice sorgente effettivo di ogni applicazione nell'ambito della migrazione e la costruzione di un modello strutturale che rappresenti:
Inventario completo. Ogni programma, funzione, modulo, copybook, schema, job stream e procedura, inclusi quelli non presenti nella documentazione, che in ambienti aziendali di grandi dimensioni rappresentano spesso il 20-30% del conteggio effettivo.
Mappatura delle dipendenze tra linguaggi diversi. Come un servizio Java si connette a un programma COBOL che legge da una tabella DB2 popolata da un job batch JCL. Le dipendenze che attraversano i confini tra i linguaggi sono quelle che gli strumenti di infrastruttura non riescono a rilevare e che causano le sorprese più costose durante le migrazioni.
Identificazione del codice obsoleto. I componenti senza riferimenti in entrata da alcun percorso di esecuzione in produzione possono essere completamente esclusi dall'ambito della migrazione. La modernizzazione dei sistemi legacy nel 2026 richiede il passaggio da sistemi rigidi e monolitici ad architetture moderne, agili e scalabili, ma la migrazione del codice obsoleto al cloud genera costi per infrastrutture che non servono a nessuno scopo di produzione.
Classificazione della complessità. I componenti ad alta complessità e ad alto grado di interconnessione sono quelli più costosi da migrare e quelli che con maggiore probabilità generano sforamenti di budget. Identificarli in fase di valutazione, anziché scoprirli durante l'esecuzione, fa la differenza tra un budget di migrazione con un'adeguata riserva per imprevisti e uno basato su ipotesi ottimistiche.
Ambito di impatto per qualsiasi modifica proposta. Prima di modificare, rifattorizzare o spostare qualsiasi componente, il modello strutturale risponde alla domanda: cos'altro influirà su questa modifica? Tale risposta trasforma il rischio sconosciuto in un elenco strutturato e numerabile di componenti che richiedono convalida.
Perché il divario di osservabilità è maggiore per i sistemi legacy e mainframe
Gli ambienti cloud che crescono attraverso migrazioni rapide e non controllate accumulano rischi nelle lacune tra strumenti, team e responsabilità. Per le organizzazioni che migrano portafogli di applicazioni web moderne, questa lacuna è significativa. Per le organizzazioni che migrano carichi di lavoro mainframe, COBOL, JCL, PL/I, RPG, è spesso decisiva.
Le applicazioni mainframe accumulano una complessità tale che nessuna scansione dell'infrastruttura può rilevarla. Logica di business incorporata in paragrafi COBOL modificati da una dozzina di sviluppatori nel corso di trent'anni. Flussi di job JCL con percorsi di esecuzione condizionali che vengono eseguiti solo in presenza di specifiche condizioni di business. Copybook inclusi simultaneamente da centinaia di programmi, dove la ridenominazione di un singolo campo influenza ogni programma della catena. Dataset che fungono da contratti dati impliciti tra programmi che non si richiamano mai esplicitamente.
La strategia "lift-and-shift" è la causa principale dei fallimenti nella modernizzazione. Riprogettare la piattaforma senza riprogettare l'architettura significa semplicemente spostare il debito tecnico. Questo è particolarmente vero per i carichi di lavoro mainframe. Convertire un programma COBOL in Java senza comprenderne la struttura interna, le dipendenze e i flussi di dati produce codice Java con gli stessi problemi strutturali del COBOL originale, ma ora in esecuzione su un'infrastruttura cloud con fatturazione continuativa.
L'osservabilità strutturale necessaria per colmare questo divario, sia per i mainframe che per i portfolio multilingue, richiede strumenti in grado di comprendere simultaneamente ogni linguaggio presente nell'ambiente e di tracciare le dipendenze al di là dei confini linguistici, che rappresentano i punti ciechi più pericolosi.
La connessione FinOps: non puoi governare ciò che non puoi vedere
FinOps è una disciplina di gestione finanziaria che assegna la responsabilità della spesa cloud a livello di team e di carico di lavoro, sostituendo la fatturazione opaca con una governance dei costi granulare e fruibile. Ogni framework FinOps, dalla governance dei tag alla rendicontazione e all'addebito, fino all'ottimizzazione della capacità riservata, si basa sulla conoscenza di ciò che si sta eseguendo e dei relativi costi.
Le organizzazioni che falliscono nell'implementazione di FinOps sono quelle che non hanno creato un inventario strutturale prima della migrazione. Non riescono a etichettare le risorse in modo accurato perché non sanno a quale carico di lavoro appartiene ciascuna risorsa. Non riescono ad assegnare la responsabilità dei costi perché la proprietà dei componenti migrati non è mai stata definita in base alla struttura effettiva dei componenti. Non riescono a dimensionare correttamente la capacità riservata perché non sanno quali carichi di lavoro sono stabili e quali variabili, il che richiede la comprensione della funzione del carico di lavoro, non solo del suo consumo di risorse.
Ciò che manca è una strategia che colleghi la definizione del budget, l'osservabilità e le attività di migrazione al cloud a risultati concreti, come la crescita aziendale, l'esperienza utente e il time-to-market. Tale collegamento non può essere realizzato senza una solida base strutturale: un modello accurato del portfolio applicativo prima ancora di redigere il piano di migrazione.
Come SMART TS XL Colma il divario di osservabilità pre-migrazione
SMART TS XL Fornisce il livello di osservabilità strutturale necessario per la valutazione della migrazione al cloud, ma che gli strumenti di rilevamento dell'infrastruttura non sono in grado di produrre. Analizzando il codice sorgente effettivo di ogni applicazione del portfolio, in linguaggi come COBOL, JCL, Java, Python, RPG, PL/I, SQL e linguaggi moderni, crea un modello di dipendenza unificato che rende visibile l'invisibile prima dell'inizio della migrazione.
L' analisi di modernizzazione dei sistemi legacy inizia con un inventario completo: ogni programma, copybook, schema e flusso di lavoro presente nell'ambiente, inclusi i componenti non documentati. Questo rappresenta l'effettivo ambito di migrazione, derivato dal codice anziché da stime.
La mappatura delle dipendenze dell'applicazione traccia ogni relazione tra componenti attraverso ogni confine di linguaggio, dal servizio Java che richiama il programma COBOL che legge dalla tabella DB2 popolata dal job batch JCL. Questo grafico delle dipendenze tra linguaggi è la base per la sequenza delle ondate di migrazione: i componenti senza dipendenze a monte vengono migrati per primi; i componenti da cui dipendono molti altri vengono migrati per ultimi, dopo che i loro dipendenti sono pronti.
La funzionalità di analisi d'impatto trasforma il grafico delle dipendenze in una pianificazione di migrazione operativa: prima di spostare o rifattorizzare qualsiasi componente, è necessario elencare tutti gli altri componenti che saranno interessati, definire l'ambito dell'attività di validazione e identificare i componenti che presentano il rischio di migrazione più elevato. Questo trasforma l'approccio "lo scopriremo durante l'esecuzione" in un programma strutturato e basato su dati concreti, con un ambito definito in ogni fase.
La funzionalità di ricerca aziendale rende l'intero modello strutturale interrogabile durante l'intero programma di migrazione: è possibile trovare in pochi secondi ogni utilizzo di una specifica funzione, ogni programma che legge da un determinato dataset, ogni componente che sarà interessato da una modifica dello schema, attraverso milioni di righe di codice in qualsiasi combinazione di linguaggi. Questa funzionalità di ricerca è ciò che mantiene il modello strutturale utile durante un programma di migrazione pluriennale, anziché trasformarlo in un artefatto di valutazione una tantum destinato a diventare obsoleto.
Ridurre il divario prima dell'apertura del bilancio
In questo contesto, i CIO più efficaci non sono necessariamente quelli con i budget di modernizzazione più elevati. Sono piuttosto coloro che sanno quantificare con la stessa precisione il costo dell'inazione e quello dell'azione. La stessa precisione si applica al divario di osservabilità. La questione non è se l'analisi strutturale pre-migrazione costi tempo e denaro. Certo che li costa. La questione è se tale costo sia inferiore al costo di scoprire la complessità strutturale durante l'esecuzione della migrazione, e in tutte le organizzazioni che hanno condotto questo esperimento, la risposta è sempre affermativa.
Le aziende che definiranno il prossimo decennio non saranno quelle che hanno implementato più tecnologia, bensì quelle che hanno compreso appieno il suo funzionamento. Il ROI della modernizzazione del cloud non è principalmente una questione di cloud, ma di conoscenza. Sapete cosa contiene il vostro portfolio applicativo? Sapete come sono interconnessi i suoi componenti? Sapete quali conseguenze avrà una modifica a qualsiasi componente? Le organizzazioni in grado di rispondere a queste domande prima dell'inizio della migrazione sono quelle i cui programmi di modernizzazione del cloud raggiungono il ROI previsto dal business case. Le altre scoprono solo le lacune nelle proprie fatture cloud.
