La motivazione standard per investire nella qualità dei dati si basa sul rischio operativo: l'84% delle organizzazioni subisce interruzioni misurabili a causa di una scarsa qualità dei dati e oltre un quarto perde più di 5 milioni di dollari all'anno come conseguenza diretta. La risposta standard è un programma di gestione della qualità dei dati che misura accuratezza, completezza, coerenza, tempestività, validità e unicità rispetto a soglie predefinite, e un pannello di controllo di metriche che monitora se i dati che transitano attraverso i sistemi operativi soddisfano gli standard definiti.
Questo framework standard non è stato progettato per un progetto di modernizzazione. Il trasferimento dei dati da un mainframe basato su COBOL a una piattaforma cloud-native non rappresenta un problema di qualità operativa in corso. Si tratta di un evento di trasformazione con requisiti specifici di pre-migrazione, rischi specifici durante la migrazione e necessità specifiche di validazione post-migrazione, che le dimensioni standard della qualità dei dati affrontano solo parzialmente. Il framework di valutazione della qualità dei dati appropriato per un progetto di modernizzazione differisce da quello appropriato per il monitoraggio operativo in tre modi fondamentali: deve valutare l'idoneità alla migrazione anziché l'idoneità alle operazioni correnti, deve valutare il rischio di migrazione anziché il tasso di errore operativo e deve produrre prove per il processo di validazione della migrazione che confermino se i dati trasformati si comportano in modo equivalente ai dati di origine.
Prima lo schema, poi il punteggio
SMART TS XL Individua ogni voce FD, gerarchia REDEFINES e campo COMP-3 nell'intero portfolio COBOL.
SCOPRI DI PIÙ…Perché i framework standard per la qualità dei dati sono insufficienti per la modernizzazione
Le sei dimensioni del framework DAMA (Data Management Body of Knowledge), ovvero accuratezza, completezza, coerenza, tempestività, validità e unicità, misurano la qualità dei dati rispetto ai requisiti operativi. Un record accurato al 95%, completo al 98% e coerente al 99% soddisfa le soglie di qualità operativa per la maggior parte dei sistemi. Potrebbe non essere idoneo alla migrazione e potrebbe non produrre risultati corretti nel sistema di destinazione.
L'insufficienza non risiede nelle dimensioni in sé, ma in ciò che misurano e in ciò che tralasciano rispetto allo scopo specifico di un progetto di modernizzazione.
L'idoneità alla migrazione non è la stessa cosa dell'idoneità operativa. Un record VSAM con un campo decimale compresso COMP-3 valido che funziona correttamente in COBOL potrebbe migrare in modo errato a un database di destinazione se il campo di destinazione è definito come FLOAT anziché DECIMAL, un errore di precisione che supera i controlli di qualità operativi perché i programmi COBOL che leggono il campo originale calcolano risultati corretti dalla rappresentazione COMP-3, ma produce errori di arrotondamento nel sistema di destinazione che utilizza l'aritmetica in virgola mobile. Il punteggio di qualità operativa era elevato; il punteggio di idoneità alla migrazione è basso.
I contratti impliciti sui dati del sistema sorgente sono invisibili agli strumenti di qualità esterni. I programmi COBOL impongono la qualità dei dati tramite codice procedurale, controlli di intervallo nelle istruzioni IF, convalida del formato nei blocchi EVALUATE e regole di calcolo nelle istruzioni COMPUTE. Queste regole di qualità risiedono nel codice sorgente, non nei dati stessi. Gli strumenti di qualità dei dati esterni che profilano i dati senza analizzare i programmi che li producono non possono rilevare questi vincoli impliciti e, di conseguenza, non possono determinare se il sistema di destinazione impone vincoli equivalenti.
La predisposizione all'IA introduce una terza dimensione, oltre all'idoneità operativa e alla migrazione. Gartner prevede che il 60% dei progetti di IA non supportati da dati predisposti per l'IA verrà abbandonato entro il 2026. "Dati predisposti per l'IA" non è sinonimo di "dati puliti" secondo la definizione operativa. Un modello di IA non sa che il "Ricavi" nel sistema finanziario esclude i rimborsi, mentre il "Ricavi" nel CRM no; li tratta entrambi come la stessa metrica e sfrutta questa incoerenza. I progetti di modernizzazione che rientrano in una trasformazione basata sull'IA o sull'analisi dei dati devono valutare la qualità dei dati in base a un terzo criterio: se i dati migrati produrranno risultati affidabili nei carichi di lavoro di IA e analisi a valle.
Le dimensioni della qualità dei dati specifiche per la modernizzazione
Un quadro di riferimento per la valutazione della qualità dei dati nei progetti di modernizzazione estende le sei dimensioni standard con cinque valutazioni specifiche per la migrazione:
Le sei dimensioni standard (applicate al contesto migratorio)
Precisione, il grado in cui i dati rappresentano correttamente l'entità o l'evento del mondo reale che descrivono. Nel contesto della migrazione, l'accuratezza deve essere valutata sia rispetto alla rappresentazione del sistema sorgente che rispetto alla rappresentazione del sistema di destinazione. Un importo finanziario memorizzato come PIC S9(11)V99 COMP-3 In COBOL, rappresenta un valore con due cifre decimali implicite in formato decimale compresso. Lo stesso valore memorizzato come DECIMAL(13,2) nel database di destinazione rappresenta lo stesso valore. Lo stesso valore memorizzato come FLOAT(8) rappresenta un valore approssimativamente corretto, ma non identico, per i valori che non possono essere rappresentati esattamente in virgola mobile binaria.
Completezza : il grado in cui tutti i dati richiesti sono presenti. I programmi COBOL utilizzano frequentemente campi FILLER, byte di riempimento e valori sentinella (tutti spazi, tutti zeri, HIGH-VALUES) come equivalenti funzionali di NULL che non si traducono letteralmente nella semantica NULL di SQL. Una valutazione di completezza per la migrazione deve identificare questi valori null funzionali, ovvero valori fisicamente presenti ma che rappresentano l'assenza di dati significativi, e determinare come vengono mappati alla gestione dei valori null del sistema di destinazione.
La coerenza indica il grado di assenza di contraddizioni nei dati tra diversi set di dati o all'interno di un singolo set di dati. Per i dati provenienti da mainframe, la coerenza tra i programmi è particolarmente importante: la stessa entità aziendale (un cliente, un account, una polizza) può essere rappresentata in più file VSAM o tabelle DB2 gestite da programmi diversi. Ogni programma possiede una propria registrazione dello stato attuale dell'entità. La valutazione della coerenza deve accertare se queste rappresentazioni coincidono o identificare le discrepanze che devono essere risolte prima che la migrazione produca un set di dati di destinazione coerente.
Tempestività : il grado in cui i dati riflettono la realtà attuale entro un intervallo di tempo accettabile. Per i dati mainframe elaborati in batch, la tempestività è determinata dal ciclo di elaborazione: un batch mensile crea dati aggiornati entro un mese. Il requisito di tempestività del sistema di destinazione, che potrebbe necessitare di dati quasi in tempo reale per carichi di lavoro analitici che il sistema di origine non è stato progettato per supportare, crea un divario di tempestività che la sola migrazione non può colmare.
Validità, il grado in cui i dati si conformano ai vincoli di formato e tipo definiti. I nomi delle condizioni di livello 88 di COBOL creano vincoli di validità semantica che non vengono catturati dal sistema dei tipi di dati: un campo definito come PIC 9(2) Nel programma COBOL, un campo può essere valido solo se contiene valori compresi tra 01 e 12 (mesi) o tra 01 e 31 (giorni), con validità garantita dalla condizione di livello 88. Gli strumenti esterni di analisi della qualità dei dati che profilano il campo lo interpretano come un campo numerico a due cifre; non rilevano il vincolo semantico che rende i valori 00 e 13-99 non validi nel contesto.
Unicità , ovvero il grado in cui le entità di dati sono rappresentate una sola volta. La dimensione dell'unicità per i dati COBOL richiede la comprensione del fatto che i file VSAM KSDS impongono l'unicità della chiave primaria a livello di file, ma che la stessa entità logica può apparire in più file VSAM gestiti da programmi diversi, con chiavi diverse. La risoluzione delle entità tra file, ovvero la determinazione se il CUSTOMER-RECORD in CUSTMSTR.VSAM e l'ACCOUNT-HOLDER in ACTHLD.VSAM rappresentano la stessa persona reale, è un problema di unicità che non può essere valutato esaminando un file isolatamente.
Le cinque dimensioni specifiche della migrazione
L'integrità strutturale è il grado in cui la struttura fisica dei dati corrisponde alle definizioni di schema previste dai programmi. I dati COBOL vengono memorizzati secondo le specifiche della clausola PIC; i byte fisici su disco o nei record VSAM devono essere conformi a queste specifiche affinché i programmi possano interpretarli correttamente. I fallimenti di integrità strutturale, ovvero i record in cui un campo COMP-3 contiene sequenze di bit non valide per il formato decimale compresso, o in cui un campo numerico contiene caratteri non numerici, sono spesso presenti nei dati legacy e invisibili ai programmi che non utilizzano mai i valori non validi. Questi fallimenti si verificano quando gli strumenti di conversione tentano di leggere tali campi.
Copertura delle varianti dello schema : il grado in cui il punteggio di qualità dei dati tiene conto di tutte le varianti REDEFINES nello schema di origine. Come discusso nel contesto dell'analisi della struttura dei file VSAM, un record VSAM può avere più layout sovrapposti definiti tramite clausole REDEFINES. Una valutazione standard della qualità dei dati che profila il layout del record di base non considera le caratteristiche qualitative delle varianti REDEFINES, inclusi i valori nel campo discriminatore che determinano quale variante si applica a ciascun record e la validità dei valori di campo di ciascuna variante nelle condizioni appropriate.
Coerenza tra programmi : il grado di coerenza dei valori dei dati tra programmi che mantengono rappresentazioni sovrapposte delle stesse entità aziendali. Questa dimensione è specifica degli ambienti mainframe, dove la stessa entità è gestita da più programmi tramite dataset condivisi. Una regola aziendale implementata in modo diverso in due programmi, perché uno è stato aggiornato quando la regola è cambiata e l'altro no, produce un'incoerenza tra programmi che risulta invisibile a qualsiasi valutazione della qualità dei dati effettuata su un singolo programma.
Qualità rispetto alla precisione : il grado in cui i dati numerici possono essere rappresentati nel sistema di destinazione con una precisione equivalente. Questa dimensione si riferisce in particolare ai campi COMP-3, COMP e COMP-5, comuni nei programmi COBOL, che richiedono una mappatura del tipo di destinazione rispetto alla precisione. Una valutazione della qualità che identifica tutti i campi numerici e verifica se i loro valori rientrano nell'intervallo e nella precisione del tipo di campo di destinazione è un controllo di qualità specifico per la migrazione, non eseguito dagli strumenti di profilazione standard.
Il punteggio di prontezza alla migrazione è una valutazione composita che indica se ogni entità dati è pronta per la migrazione così com'è, se richiede una correzione preliminare alla migrazione o se necessita di una trasformazione sul sistema di destinazione per ottenere un comportamento equivalente. Il punteggio di prontezza alla migrazione è il risultato combinato delle dimensioni precedenti: un record che ottiene un punteggio elevato in termini di accuratezza, completezza, coerenza, validità, unicità, integrità strutturale, copertura delle varianti dello schema, coerenza tra programmi e qualità basata sulla precisione è pronto per la migrazione. Un record che non soddisfa una qualsiasi di queste dimensioni richiede di essere eliminato, pulito, trasformato, escluso o accettato con rischio documentato.
Calcolo del punteggio di qualità composito
Il punteggio composito di qualità dei dati per un progetto di modernizzazione è una media ponderata dei punteggi delle singole dimensioni, dove i pesi riflettono l'importanza relativa di ciascuna dimensione nel contesto specifico della migrazione:
| Dimensioni | Peso standard | Adeguamento per i dati finanziari | Aggiustamento per l'obiettivo di analisi |
|---|---|---|---|
| Precisione | 25% | 30% (precisione critica) | 20% |
| Completezza | 20% | 15% | 25% (l'IA necessita di funzionalità complete) |
| Consistenza | 15% | 20% (regolamentare) | 20% |
| Validità | 15% | 15% | 10% |
| Unicità | 10% | 10% | 15% (deduplicazione per l'IA) |
| Tempestività | 5% | 5% | 10% (freschezza per le modelle) |
| Integrità strutturale | 5% | 2% | 0% (post-conversione) |
| Copertura variante dello schema | 3% | 2% | 0% |
| coerenza tra i programmi | 1% | 1% | 0% |
| qualità attenta alla precisione | 1% | 1% | 0% |
Ogni dimensione viene valutata con un punteggio da 0 a 100 e il punteggio composito è la somma ponderata. Il punteggio composito determina la classificazione della predisposizione alla migrazione:
| Punteggio composito | Preparazione alla migrazione | Disposizione raccomandata |
|---|---|---|
| 90-100 | l'Esposizione | Esegui la migrazione con convalida standard |
| 75-89 | Pronto con monitoraggio | Esegui la migrazione con una convalida post-migrazione avanzata. |
| 60-74 | Condizionale | Risolvere i guasti specifici delle dimensioni prima della migrazione |
| 40-59 | Non pronto | È necessario un significativo intervento di bonifica preliminare alla migrazione. |
| Sotto 40 | Problemi critici di qualità | Non effettuare la migrazione finché l'analisi delle cause principali e la relativa risoluzione non saranno completate. |
Misurazione pratica: il flusso di lavoro della valutazione
La valutazione della qualità dei dati per un progetto di modernizzazione segue un flusso di lavoro specifico che si differenzia dal monitoraggio della qualità operativa:
Fase 1: Individuazione e documentazione dello schema. Prima di poter analizzare qualsiasi dato, è necessario conoscere lo schema che lo definisce. Per i dati mainframe, ciò significa analizzare le voci FD, i membri COPY e le clausole SELECT di ogni programma COBOL che accede a ciascun dataset. La fase di individuazione dello schema produce: l'inventario completo dei campi con tipi di dati, lunghezze e specifiche COMP; tutte le gerarchie REDEFINES e le relative condizioni discriminanti; i nomi delle condizioni di livello 88 e i relativi vincoli semantici; e le regole di qualità dei dati a livello di programma incorporate nella logica PROCEDURE DIVISION.
Fase 2: Profilazione dei dati rispetto allo schema scoperto. Profilare ciascun dataset rispetto allo schema scoperto nella Fase 1, non rispetto a uno schema presunto o documentato. Profilare per: frequenze equivalenti nulle (spazi, zeri, VALORI ALTI nei campi in cui è prevista la semantica NULL); distribuzioni degli intervalli di valori rispetto ai vincoli di livello 88; integrità strutturale (modelli di bit COMP-3 validi, rappresentazioni COMP-5 valide); coerenza tra campi (campi data in cui i valori del giorno superano il massimo per il mese indicato); e coerenza tra record (record correlati che dovrebbero concordare sugli attributi condivisi ma non lo fanno).
Fase 3: Valutazione della coerenza tra i programmi. Per ogni entità aziendale rappresentata in più programmi o set di dati, valutare la coerenza tra le rappresentazioni. Ciò richiede: identificare quali programmi mantengono rappresentazioni sovrapposte (attraverso la mappatura delle dipendenze); estrarre i record per ogni rappresentazione di ciascuna entità; confrontare i valori che dovrebbero essere coerenti; e documentare le discrepanze con la loro frequenza e gravità.
Fase 4: Analisi dell'impatto sulla precisione. Per ogni campo COMP-3 e numerico binario, calcolare le implicazioni sulla precisione della mappatura del tipo di campo di destinazione. In particolare: identificare eventuali valori nei dati di origine che non possono essere rappresentati esattamente nel tipo di campo di destinazione; quantificare l'errore di arrotondamento che risulterebbe dalla conversione del tipo; e determinare se l'errore di arrotondamento è accettabile in base al caso d'uso successivo (la rendicontazione normativa rispetto alle analisi interne ha soglie di tolleranza diverse).
Fase 5: Valutazione delle dimensioni e calcolo del punteggio composito. Applicare i punteggi delle dimensioni e ponderarli in base al tipo di dati e al contesto di destinazione della migrazione. Generare il punteggio composito e la classificazione di prontezza alla migrazione per ciascun set di dati e per l'intero portfolio.
Fase 6: Pianificazione della correzione. Per i set di dati che ottengono un punteggio inferiore alla soglia di prontezza per la migrazione, produrre un piano di correzione che identifichi: gli elementi di dati specifici che non hanno superato i controlli di qualità; il volume dei record interessati; la regola aziendale o la trasformazione che correggerebbe l'errore; e il controllo di convalida che confermerà il completamento della correzione.
Modelli SQL per la misurazione della qualità dei dati
Una valutazione pratica della qualità richiede misurazioni eseguibili. I seguenti modelli SQL implementano i controlli di qualità più comuni specifici per la modernizzazione sui dati estratti dai sistemi legacy e trasferiti in un ambiente di staging:
sql
-- 1. Completeness: detect functional nulls (spaces/zeros as NULL equivalents)
SELECT
COUNT(*) AS total_records,
SUM(CASE WHEN TRIM(CUSTOMER_NAME) = ''
THEN 1 ELSE 0 END) AS functional_null_name,
SUM(CASE WHEN ACCOUNT_BALANCE = 0
AND ACCOUNT_STATUS NOT IN ('ACTIVE','CLOSED')
THEN 1 ELSE 0 END) AS suspicious_zero_balance,
ROUND(100.0 * SUM(CASE WHEN TRIM(CUSTOMER_NAME) = ''
THEN 1 ELSE 0 END)
/ COUNT(*), 2) AS functional_null_pct
FROM staging_customer_master;
-- 2. Validity: check 88-level equivalent constraints (month range)
SELECT
COUNT(*) AS total_records,
SUM(CASE WHEN TRANSACTION_MONTH NOT BETWEEN 1 AND 12
THEN 1 ELSE 0 END) AS invalid_month_count,
SUM(CASE WHEN TRANSACTION_DAY NOT BETWEEN 1 AND 31
THEN 1 ELSE 0 END) AS invalid_day_count,
SUM(CASE WHEN TRANSACTION_YEAR < 1900
OR TRANSACTION_YEAR > 2100
THEN 1 ELSE 0 END) AS invalid_year_count
FROM staging_transaction_header;
-- 3. Precision impact: identify values that lose precision in FLOAT conversion
SELECT
RECORD_KEY,
ORIGINAL_AMOUNT,
CAST(CAST(ORIGINAL_AMOUNT AS FLOAT) AS DECIMAL(13,2)) AS float_roundtrip,
ABS(ORIGINAL_AMOUNT -
CAST(CAST(ORIGINAL_AMOUNT AS FLOAT) AS DECIMAL(13,2)))
AS precision_loss
FROM staging_financial_amounts
WHERE ABS(ORIGINAL_AMOUNT -
CAST(CAST(ORIGINAL_AMOUNT AS FLOAT)
AS DECIMAL(13,2))) > 0.005
ORDER BY precision_loss DESC;
-- 4. Cross-program consistency: compare entity representations across programs
SELECT
a.CUSTOMER_ID,
a.CUSTOMER_NAME AS name_in_custmstr,
b.ACCOUNT_HOLDER_NAME AS name_in_acthld,
a.CUSTOMER_ADDRESS AS addr_in_custmstr,
b.MAILING_ADDRESS AS addr_in_acthld,
CASE WHEN a.CUSTOMER_NAME <> b.ACCOUNT_HOLDER_NAME
THEN 'NAME_MISMATCH' ELSE 'OK' END AS name_consistency,
CASE WHEN TRIM(a.CUSTOMER_ADDRESS) <> TRIM(b.MAILING_ADDRESS)
THEN 'ADDRESS_MISMATCH' ELSE 'OK' END AS addr_consistency
FROM staging_customer_master a
JOIN staging_account_holder b
ON a.CUSTOMER_ID = b.CUSTOMER_ID
WHERE a.CUSTOMER_NAME <> b.ACCOUNT_HOLDER_NAME
OR TRIM(a.CUSTOMER_ADDRESS) <> TRIM(b.MAILING_ADDRESS)
ORDER BY a.CUSTOMER_ID;
-- 5. Uniqueness: identify duplicates on logical keys
SELECT
CUSTOMER_ID,
COUNT(*) AS occurrence_count,
MIN(RECORD_TIMESTAMP) AS first_occurrence,
MAX(RECORD_TIMESTAMP) AS last_occurrence
FROM staging_customer_master
GROUP BY CUSTOMER_ID
HAVING COUNT(*) > 1
ORDER BY occurrence_count DESC;Il quadro di riferimento Quality Gate per le ondate migratorie
Un programma di modernizzazione in genere migra a ondate, ovvero gruppi di applicazioni e set di dati che si spostano insieme. Il framework di valutazione della qualità dei dati guida le decisioni relative alla composizione delle ondate:
Criteri di ammissibilità per ogni ondata di migrazione: un set di dati è idoneo per un'ondata di migrazione solo quando il suo punteggio di qualità complessivo supera la soglia minima dell'ondata. Per le applicazioni di Livello 1 (mission critical), la soglia minima è 85. Per le applicazioni di Livello 2, è 75. Questo impedisce la migrazione di applicazioni mission critical su dati che non sono stati adeguatamente qualificati.
Controllo qualità preliminare: prima dell'inizio di ogni fase di migrazione, una scansione di qualità finale conferma che il punteggio di qualità dei dati non si sia deteriorato rispetto alla valutazione iniziale. La qualità dei dati può peggiorare tra la valutazione iniziale e l'esecuzione della migrazione se il sistema di origine continua a funzionare e ad accumulare nuovi record che non soddisfano gli standard di qualità identificati durante la valutazione.
Validazione dell'equivalenza post-migrazione: dopo ogni ondata di migrazione, il framework di qualità fornisce la base di riferimento per il confronto: ogni punteggio dimensionale calcolato sui dati di origine viene ricalcolato sui dati migrati e la differenza tra i punteggi di origine e di destinazione costituisce il report sulla qualità della migrazione. Una migrazione che ha prodotto un dataset di destinazione con minore accuratezza, minore completezza o minore coerenza tra i programmi rispetto all'origine ha introdotto un degrado della qualità che deve essere analizzato prima di procedere all'ondata successiva.
Come SMART TS XL Supporta la valutazione della qualità dei dati per la modernizzazione
Le dimensioni di qualità specifiche della migrazione, la copertura delle varianti di schema, la coerenza tra programmi, la qualità basata sulla precisione e l'integrità strutturale dipendono tutte da un livello di comprensione del codice sorgente dell'applicazione che gli strumenti standard di qualità dei dati non possiedono. Richiedono di sapere cosa i programmi che producono i dati definiscono come valido, quali campi sono COMP-3 e richiedono una mappatura di destinazione basata sulla precisione e quali programmi mantengono rappresentazioni sovrapposte delle stesse entità aziendali.
SMART TS XL'S analisi statica del codice Fornisce il livello di individuazione dello schema: analizza ogni voce FD, membro COPY e clausola SELECT nell'intero portfolio COBOL per produrre l'inventario completo dello schema, tutte le definizioni dei campi, tutte le gerarchie REDEFINES, tutti i vincoli a 88 livelli e tutte le specifiche di precisione COMP-3. Questo inventario è il fondamento richiesto dalle dimensioni di qualità specifiche della migrazione e non può essere derivato dai dati stessi.
La mappatura delle dipendenze tra applicazioni consente la valutazione della coerenza tra programmi: creando una mappa che indica quali programmi gestiscono quali dati, quali programmi scrivono su quali dataset VSAM e quali dataset contengono rappresentazioni sovrapposte delle stesse entità aziendali, la mappa delle dipendenze identifica le coppie e i gruppi che richiedono una valutazione della coerenza tra programmi. Senza questa mappa, la dimensione della coerenza tra programmi non può essere valutata perché il valutatore non sa quali programmi e dataset rappresentano le stesse entità.
La capacità di analisi dell'impatto rende il framework di controllo qualità operativo su larga scala: quando viene rilevato un problema di qualità in uno specifico set di dati, l'analisi dell'impatto identifica ogni applicazione, programma e processo aziendale che dipende da tale set di dati, determinando la portata delle conseguenze a valle del problema di qualità e dando priorità alla risoluzione in base al numero di programmi dipendenti interessati.
La funzionalità di ricerca aziendale rende l'inventario della qualità interrogabile durante l'intero programma di migrazione: è possibile trovare ogni programma che legge uno specifico file VSAM (per definire l'ambito della valutazione della coerenza tra i programmi), ogni campo definito come COMP-3 (per creare un inventario della qualità che tenga conto della precisione) e ogni nome di condizione di livello 88 (per enumerare i vincoli di validità semantica che gli strumenti esterni non possono visualizzare). Questa funzionalità di ricerca supporta sia la valutazione iniziale della qualità sia il monitoraggio continuo che garantisce che la qualità non si degradi tra la valutazione e l'esecuzione della migrazione.
Per le organizzazioni che conducono modernizzazione dell'eredità programmi, SMART TS XLL'analisi di [nome dell'autore/i] colma il divario tra i framework di qualità dei dati progettati per il monitoraggio operativo e i requisiti di qualità specifici per la migrazione che determinano se i progetti di modernizzazione producono i risultati corretti. Le dimensioni standard della qualità dei dati sono necessarie. Le estensioni specifiche per la migrazione sono ciò che le rende sufficienti.
Conclusione: la qualità per la migrazione non è la stessa cosa della qualità per le operazioni.
Il panorama della qualità dei dati nel 2026 è ricco di framework, strumenti e metriche progettati per la gestione operativa dei dati. Le dimensioni DAMA sono ben consolidate e ampiamente implementate. Gli strumenti, come Great Expectations, Monte Carlo, Collibra e dbt, sono maturati significativamente. L'approccio standard di definizione delle regole di qualità, profilazione dei dati e monitoraggio rispetto alle soglie funziona bene per lo scopo operativo per cui è stato concepito.
I progetti di modernizzazione richiedono qualcosa di diverso. Richiedono una valutazione della qualità che consideri l'idoneità alla migrazione, non l'idoneità operativa. Richiedono la comprensione del codice sorgente che produce i dati, non solo dei dati stessi. Richiedono un'analisi dei campi numerici attenta alla precisione, la copertura delle varianti REDEFINES e la valutazione della coerenza tra i programmi, dimensioni che i framework di qualità operativa non affrontano perché i sistemi operativi non le richiedono.
Le organizzazioni che ottengono risultati di migrazione corretti sono quelle che sviluppano i propri framework di valutazione della qualità dei dati specificamente per la migrazione, estendendoli successivamente al monitoraggio operativo. La qualità dei dati per la migrazione non è un sottoinsieme della gestione della qualità dei dati operativi. È una disciplina a sé stante, con le proprie dimensioni, le proprie soglie e i propri requisiti di validazione, e trattarla come tale è ciò che permette ai programmi di modernizzazione di mantenere le promesse tecniche.
