Gestione dei metadati per sistemi di dati pluridecennali

Il campo TRANS-AMT-CD in un programma COBOL è in produzione dal 1981. La voce FD lo definisce come PIC S9(9)V99 COMP-3Si tratta di un campo numerico decimale compresso con segno, undici cifre, con due cifre decimali implicite. Questi sono i metadati tecnici. I metadati aziendali, ovvero cosa significhi effettivamente TRANS-AMT-CD, in quale valuta sia denominato, se le due cifre decimali implicite rappresentino centesimi o punti base, se un valore negativo rappresenti un credito o un debito e come debba essere interpretato un valore pari a zero, non sono presenti nel codice sorgente. Erano contenuti in un documento di specifiche funzionali stampato nel 1981, archiviato in un armadio e da allora mai più visto. I due sviluppatori che originariamente sapevano cosa significasse TRANS-AMT-CD sono entrambi andati in pensione nel 2014.

Questa è la situazione dei metadati che ogni organizzazione con sistemi di dati pluridecennali si trova ad affrontare, ed è la situazione dei metadati che i moderni framework di governance dei dati non sono stati progettati per gestire. Collibra, Alation, Atlan e tutte le altre piattaforme di catalogo dati aziendali sono eccellenti nella gestione dei metadati per i dati già descritti, i database cloud con schemi documentati, i data warehouse con semantica di colonna definita, gli endpoint API con specifiche OpenAPI. Non sono progettate per ricostruire metadati che non sono mai stati formalmente acquisiti, che esistono solo nel comportamento di programmi scritti prima che la gestione dei metadati diventasse una disciplina e che sono stati modificati da decine di sviluppatori nel corso di quattro decenni senza che nessuno aggiornasse un registro centrale del significato di ciascun campo.

La gestione dei metadati per sistemi di dati che risalgono a decenni fa non è lo stesso problema della gestione dei metadati per i sistemi moderni. Richiede un approccio fondamentalmente diverso, che inizia con l'estrazione dei metadati dagli artefatti di origine anziché con l'acquisizione dei metadati dai sistemi connessi.

I tre livelli dei metadati legacy

Comprendere il problema dei metadati nei sistemi che si estendono per decenni richiede di riconoscere che i metadati in questi ambienti esistono su tre livelli distinti, ognuno con diversa estraibilità, diversa completezza e diverse implicazioni di governance.

I metadati tecnici rappresentano il livello più facilmente estraibile. Descrivono la struttura fisica dei dati: nomi dei campi, tipi di dati, lunghezze, posizioni all'interno dei record, specifiche di precisione numerica e relazioni tra i campi all'interno di un layout di record. Negli ambienti COBOL, i metadati tecnici risiedono negli artefatti del codice sorgente: le voci FD definiscono i layout dei record, i membri COPY definiscono le strutture dati riutilizzabili, le clausole SELECT definiscono l'organizzazione dei file e i metodi di accesso, e le istruzioni JCL DD definiscono i dataset associati a ciascuna esecuzione del programma. Questo livello è in linea di principio leggibile da una macchina, un parser in grado di comprendere la sintassi COBOL può estrarlo dal codice sorgente, ma è distribuito su migliaia di file sorgente anziché essere centralizzato in un registro di schema.

I metadati operativi descrivono il modo in cui i dati si muovono all'interno del sistema: quali programmi producono quali dataset, quali programmi li utilizzano, in quale sequenza e attraverso quali trasformazioni. Negli ambienti mainframe, i metadati operativi sono distribuiti tra i flussi di job JCL (che definiscono le sequenze di esecuzione e le associazioni dei dataset), i grafi delle chiamate di programma (che definiscono il flusso di dati tra i programmi) e la configurazione dello scheduler (che definisce le tempistiche e le dipendenze). Questo livello è anche estraibile automaticamente dagli artefatti sorgente, sebbene l'estrazione richieda la comprensione non solo dei singoli programmi, ma anche delle relazioni tra di essi.

Metadati aziendali o semantici è lo strato meno estraibile e più prezioso. Risponde alle domande a cui i metadati tecnici non possono rispondere: cosa significa TRANS-AMT-CD cosa significano realmente in termini commerciali? Quali sono i valori validi per ACCT-TYPE-CD e cosa significa ciascun valore? Quale regola aziendale determina quando CUST-STATUS-FLG transizioni da A a IQuesto livello esiste, quando esiste, nei documenti di specifica, nella memoria degli sviluppatori, nel sapere istituzionale detenuto da dipendenti che potrebbero essere andati in pensione e nella logica procedurale dei programmi che applicano le regole aziendali tramite istruzioni IF e blocchi EVALUATE anziché tramite vincoli di database.

La sfida relativa ai metadati per i sistemi che si estendono su più decenni risiede nel fatto che questi tre livelli sono stati gestiti in modo diverso, o non gestiti affatto, nel corso dei decenni di evoluzione del sistema. I metadati tecnici sono stati acquisiti nel codice sorgente, ma non sono mai stati formalizzati in un dizionario dati. I metadati operativi erano impliciti nei flussi di lavoro JCL, ma non sono mai stati documentati come record di derivazione. I metadati aziendali sono stati documentati nelle specifiche al momento dello sviluppo iniziale e non sono mai stati aggiornati con l'evoluzione dei sistemi.

Il problema della deriva dei metadati

Ogni anno che un sistema pluridecennale opera senza una gestione sistematica dei metadati, il divario tra i metadati presenti nella documentazione formale e quelli che riflettono il comportamento effettivo del sistema si allarga. Questo divario si verifica attraverso quattro meccanismi:

Evoluzione del significato del campo. Un settore che nel 1978 era definito con un determinato significato commerciale potrebbe aver acquisito ulteriori significati nel corso dei decenni successivi. ACCT-TYPE-CD In origine, il campo potrebbe aver distinto i conti correnti dai conti di risparmio. Nel corso di quarant'anni, potrebbero essere stati aggiunti ulteriori codici per rappresentare i conti del mercato monetario, i certificati di deposito, i conti IRA e i conti di deposito a garanzia; ogni aggiunta è documentata solo nel codice del programma che gestisce il nuovo valore del codice, non in alcuna definizione di campo centrale. Il nome e il tipo del campo sono rimasti invariati; il suo significato semantico è diventato sostanzialmente più complesso.

Riutilizzo silenzioso. A volte i campi vengono riutilizzati senza essere rinominati. Un campo che veniva utilizzato per uno scopo diventa scomodo da estendere e uno sviluppatore utilizza un valore precedentemente inutilizzato di un campo flag adiacente per codificare un'informazione diversa. TRANS-FLAG-1 Ora è possibile codificare tre concetti diversi in contesti di programma differenti, distinguibili solo esaminando quali programmi leggono il campo e in quali condizioni. I metadati tecnici, nome del campo, tipo, lunghezza, non forniscono alcuna indicazione che il campo sia semanticamente sovraccarico.

Accumulo di REDEFINES. Come discusso nei contesti di analisi VSAM, le clausole REDEFINES sovrappongono la stessa memoria fisica con diverse interpretazioni dei campi. Ogni variante di REDEFINES può essere stata aggiunta in un momento diverso della storia del sistema, da sviluppatori diversi e per scopi aziendali differenti. Il significato semantico completo di una gerarchia di REDEFINES, quale variante si applica e quando, e cosa significano i campi di ciascuna variante, può essere ricostruito solo analizzando tutti i programmi che accedono a ciascuna variante e le condizioni in cui lo fanno.

Divergenza del copybook. Quando un copybook COBOL standard viene modificato per soddisfare un nuovo requisito, i programmi che includevano il copybook e non sono stati aggiornati per gestire il nuovo campo potrebbero comportarsi in modo errato o semplicemente ignorare il nuovo campo. Nel corso di decenni di evoluzione, diverse versioni di quello che nominalmente è lo stesso copybook possono esistere in librerie diverse, con programmi diversi che utilizzano versioni diverse. I metadati per un campo definito nel copybook possono differire tra i programmi a seconda della versione del copybook che ciascun programma include.

Cosa non possono fare i moderni strumenti di metadati per i dati legacy

Il mercato dei cataloghi di dati aziendali è maturato notevolmente. Collibra, Alation, Atlan, Microsoft Purview e Informatica Axon sono piattaforme sofisticate per la gestione dei metadati negli ambienti dati moderni. Eccellono in: individuazione automatica degli schemi dai database connessi, tracciamento della provenienza dei dati a livello di colonna nelle pipeline ETL, gestione di glossari aziendali con definizioni di termini curate e visualizzazione di metriche di qualità dei dati insieme ai record di metadati.

Cosa non possono fare questi strumenti per i sistemi COBOL e mainframe che risalgono a decenni fa:

Non possono connettersi a ciò che non possono vedere. I cataloghi moderni scoprono i metadati tramite connettori, connessioni JDBC ai database, integrazioni API con servizi cloud e integrazioni di scanner con piattaforme supportate. I file VSAM, i programmi COBOL e i flussi di lavoro JCL non dispongono di connettori di catalogo standard. Il catalogo non può scoprire ciò a cui non ha accesso tramite meccanismi. I dati gestiti da questi sistemi sono di fatto invisibili al catalogo, il che significa che i record di provenienza per le analisi cloud a valle, che derivano da questi dati, sono incompleti o assenti.

Non possono estrarre metadati che esistono solo nel codice. Un catalogo dati connesso a un database DB2 può leggere lo schema del database, le definizioni delle tabelle, i nomi delle colonne, i tipi di dati e gli indici. Non può leggere il programma COBOL che popola la tabella DB2 per capire quali regole aziendali governano il popolamento, quali varianti REDEFINES esistono nel record di origine o quali nomi di condizioni a livello 88 definiscono la validità semantica di ciascun campo. I metadati a livello di codice, il livello in cui risiede effettivamente il significato aziendale dei dati legacy, richiedono l'analisi del codice, non la scansione del catalogo.

Non è possibile ricostruire un significato che non è mai stato catturato. Anche con un'estrazione di metadati tecnici perfetta, il significato aziendale dei campi che non sono mai stati formalmente documentati non può essere ricostruito automaticamente. Questo livello richiede una combinazione di analisi del codice (per far emergere le regole aziendali che i programmi applicano ai dati, che fungono da proxy per il significato aziendale) e revisione umana (per convalidare il significato ricostruito rispetto alla conoscenza istituzionale finché tale conoscenza è ancora esistente).

L'approccio di ricostruzione dei metadati

Per i sistemi pluridecennali in cui i metadati formali non sono mai stati acquisiti o si sono discostati significativamente dalla realtà attuale, la gestione dei metadati richiede una fase di ricostruzione prima di una fase di governance. L'approccio di ricostruzione estrae i livelli recuperabili e identifica le lacune in cui è necessaria la conoscenza umana.

Fase 1: Estrazione dei metadati tecnici dagli artefatti di origine.

Analizza ogni voce FD COBOL, membro COPY, clausola SELECT e istruzione DD JCL per produrre un inventario dei metadati tecnici a livello di campo:

cobolo

* Source FD entry -- technical metadata extraction target
FD  TRANSACTION-FILE
    LABEL RECORDS ARE STANDARD
    RECORD CONTAINS 200 CHARACTERS.
01  TRANSACTION-RECORD.
    05  TRANS-DATE          PIC 9(8).          *> YYYYMMDD format
    05  TRANS-TYPE-CD       PIC XX.            *> See 88-level values
        88 TRANS-PAYMENT    VALUE 'PM'.
        88 TRANS-REFUND     VALUE 'RF'.
        88 TRANS-ADJUSTMENT VALUE 'AJ'.
        88 TRANS-REVERSAL   VALUE 'RV'.
    05  TRANS-AMT-CD        PIC S9(9)V99 COMP-3.
    05  TRANS-CURRENCY-CD   PIC X(3).          *> ISO 4217
    05  TRANS-DETAIL        REDEFINES TRANS-TYPE-CD.
        10  TRANS-MERCH-ID  PIC X(12).
        10  TRANS-AUTH-CD   PIC X(6).
        10  FILLER          PIC X(84).

Da questa singola voce FD, l'estrazione dei metadati tecnici produce: nomi dei campi, tipi di dati, lunghezze, posizioni, la precisione decimale compressa di TRANS-AMT-CD (9 cifre, 2 cifre decimali, con segno), i quattro valori semantici di TRANS-TYPE-CD come definito dai nomi delle condizioni di livello 88 e dalla struttura REDEFINES che crea due interpretazioni sovrapposte dei byte 10-105 del record.

I nomi delle condizioni a 88 livelli sono particolarmente preziosi come metadati: TRANS-PAYMENT, TRANS-REFUND, TRANS-ADJUSTMENT, TRANS-REVERSAL sono quattro elementi del vocabolario aziendale che il codice COBOL stesso fornisce, più significativi del sottostante PM, RF, AJ, RV valori che un catalogo dati in fase di scansione del database visualizzerebbe.

Fase 2: Estrazione dei metadati operativi dalle dipendenze del programma.

Costruisci la mappa della provenienza operativa tracciando i flussi di dati attraverso il grafico delle dipendenze del programma:

• Quali programmi scrivono a TRANSACTION-FILE (produttori)
• Quali programmi leggono da TRANSACTION-FILE (consumatori)
• Quali fasi del job JCL richiamano ciascun produttore e consumatore, in quale sequenza?
• Quali dataset e database a valle ricevono dati trasformati da TRANSACTION-FILE

Questa mappa di derivazione rappresenta i metadati operativi necessari agli strumenti di catalogazione dati per la visualizzazione della derivazione, ma che non possono essere generati senza accesso al codice sorgente del programma e al JCL.

Fase 3: Estrazione delle regole aziendali come proxy per i metadati semantici.

Le regole aziendali codificate nella logica COBOL PROCEDURE DIVISION sono proxy per il significato aziendale. Un programma che convalida TRANS-AMT-CD per garantire che rientri in determinati intervalli prima dell'elaborazione fornisce prove sull'intervallo valido del campo. Un programma che converte TRANS-AMT-CD Convertire i dati in un'unità diversa prima di scriverli in un sistema a valle rivela una convenzione decimale o di unità implicita.

L'estrazione di queste regole aziendali tramite l'analisi del codice produce un insieme di metadati semantici inferiti: gli intervalli di validazione applicati a ciascun campo, le trasformazioni che si verificano tra origine e destinazione e le condizioni in base alle quali vengono eseguiti i diversi percorsi del codice. Questi metadati semantici inferiti sono imprecisi, mostrano cosa fanno i programmi con i dati, non necessariamente cosa i dati intendessero significare, ma sono recuperabili dal codice in un modo che non è possibile dal documento di specifica originale.

Fase 4: Validazione umana e arricchimento semantico.

I metadati tecnici e operativi estratti e i metadati semantici inferiti costituiscono la base per le sessioni di validazione umana con esperti del dominio e sviluppatori in pensione. L'obiettivo è convertire la semantica inferita in semantica confermata, convalidando che TRANS-AMT-CD significa ciò che il codice suggerisce che significhi, identificando i casi in cui il comportamento del codice non riflette più il significato aziendale previsto e acquisendo la conoscenza istituzionale sulla storia del settore che l'analisi del codice non è in grado di recuperare.

Questa fase è vincolata nel tempo dalla disponibilità di competenze specifiche del settore: ogni anno che passa, una parte sempre maggiore di queste conoscenze va in pensione con le persone che le detengono.

La lacuna nei metadati legacy al confine del sistema moderno

Il deficit di metadati creato da sistemi risalenti a decenni fa non rimane confinato all'ambiente legacy. Si propaga a valle: ogni sistema analitico, data warehouse e pipeline di machine learning che utilizza dati provenienti da sistemi legacy eredita tale lacuna di metadati.

Un data warehouse cloud che riceve un'estrazione notturna di file flat da un programma batch COBOL ha, nelle sue definizioni di colonna, qualsiasi nome il team di ingegneria dei dati abbia scelto di dare alle colonne quando ha creato la pipeline ETL. Se il campo originale era TRANS-AMT-CD e lo sviluppatore ETL ha denominato la colonna di destinazione transaction_amount, il data warehouse sembra avere metadati completi: nome della colonna, tipo di dati, descrizione aziendale aggiunti al catalogo. Ciò che il catalogo non registra è che transaction_amount originato da TRANS-AMT-CD in TRANSACTION-FILE, che viene prodotto da un programma COBOL chiamato TRNSRC01, che viene eseguito nel job JCL TRANSDAY ogni notte alle 2 del mattino, e che applica una specifica conversione di valuta che è stata codificata nel 1987 sulla base di una convenzione di cambio che potrebbe non essere più attuale.

Il record dei metadati a valle sembra completo. La linea di discendenza è interrotta al confine legacy. Qualsiasi carico di lavoro analitico o di IA che dipende dalla comprensione della provenienza e del significato di transaction_amount presenta una lacuna in quanto la storia effettiva dell'origine di quel valore non è documentata.

La scoperta di Gartner secondo cui il 60% dei progetti di IA non supportati da dati pronti per l'IA verrà abbandonato entro il 2026 è in parte un'affermazione sui metadati. I modelli di IA che consumano transaction_amount I modelli, senza sapere che la loro origine risiede in un campo COBOL decimale compresso con una cifra decimale implicita, denominato in una valuta che potrebbe essere stata convertita utilizzando una convenzione di cambio del 1987, si addestrano su dati la cui provenienza è opaca. Il modello non può sapere di dover diffidare o adattarsi a questo contesto perché i metadati che lo comunicherebbero non esistono in alcun catalogo a cui il modello o la sua pipeline di dati possano accedere.

Creazione di un programma di gestione dei metadati per sistemi legacy

Un programma di gestione dei metadati per sistemi di dati pluridecennali presenta quattro componenti che lo distinguono dalle implementazioni standard dei cataloghi di dati aziendali:

Componente 1: Estrazione dei metadati dal codice sorgente. Prima che qualsiasi strumento di catalogazione possa gestire i metadati legacy, questi devono essere estratti dagli artefatti sorgente in cui risiedono. Tale estrazione deve includere: voci FD e copybook (metadati tecnici per le strutture dati), clausole SELECT (organizzazione dei file e metodo di accesso), istruzioni JCL DD (associazioni di dataset e caratteristiche dei file) e nomi di condizioni di livello 88 (vocabolario di valori semantici incorporato nel codice sorgente). L'output è un inventario di metadati a livello di campo che può essere caricato in un catalogo come punto di partenza per l'arricchimento dei dati aziendali.

Componente 2: Ricostruzione della provenienza dei dati. La provenienza dei dati per i sistemi legacy deve essere ricostruita a partire dall'analisi delle dipendenze tra programmi, anziché dal tracciamento della provenienza tramite strumenti ETL. La mappa della provenienza traccia i dati dal programma COBOL di origine, attraverso programmi di trasformazione intermedi, fino ai destinatari finali, inclusi i processi ETL che li forniscono ai moderni sistemi analitici. Questa ricostruzione colma il divario di provenienza al confine con i sistemi legacy, collegando i metadati delle colonne del data warehouse cloud ai metadati delle voci FD COBOL attraverso una catena documentata di dipendenze tra programmi.

Componente 3: Arricchimento semantico con competenze specifiche del settore. I metadati tecnici estratti forniscono la struttura; il significato aziendale confermato richiede competenze specifiche del settore. Il processo di arricchimento utilizza i metadati tecnici come spunto strutturato per le interviste con gli esperti: "Questo campo è definito come PIC S9(9)V99 COMP-3"È stato validato come non negativo in 14 programmi ed è stato convertito in una scala diversa prima di essere scritto nel database a valle. Puoi confermare cosa rappresenta e cosa significa la conversione?" Questo approccio strutturato utilizza l'analisi del codice per massimizzare il valore informativo di ogni interazione con gli esperti, consentendo un arricchimento più rapido e completo rispetto alle revisioni non strutturate della documentazione.

Componente 4: Integrazione della governance con le moderne piattaforme di catalogo. Una volta estratti, ricostruiti e arricchiti i metadati legacy, è necessario integrarli con la moderna infrastruttura di governance dei metadati. Questa integrazione collega l'inventario dei metadati legacy al catalogo dati aziendale, fornendo: tracciabilità a livello di colonna dalla sorgente COBOL alla destinazione cloud, termini del glossario aziendale collegati alle definizioni dei campi legacy e metadati sulla qualità dei dati per i dataset legacy che popolano lo stesso framework di governance dei metadati di sistema moderni.

Come SMART TS XL Estrae i metadati legacy

SMART TS XL Il programma affronta le prime due componenti del sistema di gestione dei metadati legacy, ovvero l'estrazione dei metadati del codice sorgente e la ricostruzione della provenienza, applicando un'analisi statica all'intero portfolio di COBOL, JCL e copybook.

La funzionalità di analisi statica del codice analizza ogni voce FD, membro COPY, clausola SELECT e definizione di livello 88 nell'intero portfolio COBOL, producendo l'inventario dei metadati tecnici a livello di campo: ogni nome di campo, tipo di dati, lunghezza, specifica COMP, appartenenza a REDEFINES e nome di condizione di livello 88 per ogni programma e copybook nell'ambiente. Per un portfolio di migliaia di programmi COBOL, questa estrazione produce in poche ore l'inventario dei metadati tecnici che la documentazione manuale richiederebbe anni per essere prodotta, ammesso che sia possibile produrla completamente.

La mappatura delle dipendenze dell'applicazione crea la mappa di derivazione operativa: ogni relazione programma-dataset (quali programmi producono quali dataset e quali li utilizzano), ogni dipendenza programma-programma (quali programmi chiamano quali altri e quali dati fluiscono tra di loro) e ogni relazione JCL-programma (quali fasi del job richiamano quali programmi e in quale sequenza). Questa mappa di derivazione è il livello di metadati operativi che colma il divario tra i sistemi sorgente legacy e i record di derivazione del catalogo dati moderno.

La funzionalità di espansione JCL traccia l'intera catena di esecuzione di ogni job JCL: risolve i riferimenti PROC, espande i parametri simbolici e crea i metadati operativi completi per la produzione e il consumo di ciascun dataset, il contesto di pianificazione, i job dipendenti e la sequenza di esecuzione che determina le caratteristiche di tempestività e aggiornamento di ciascun dataset.

La funzionalità di ricerca aziendale rende l'inventario dei metadati estratti interrogabile all'interno del programma di gestione dei metadati: è possibile trovare ogni campo definito come COMP-3 (campi sensibili alla precisione che richiedono un'attenta mappatura dei target), ogni programma che legge un campo specifico (identificando tutti i consumatori di un dato specifico per l'arricchimento semantico e la tracciabilità), ogni nome di condizione di livello 88 che corrisponde a un termine aziendale specifico (mappando il vocabolario aziendale alle definizioni dei campi tecnici). Questa funzionalità di ricerca supporta il processo di arricchimento semantico, consentendo agli esperti di dominio di trovare tutti gli utilizzi di un campo o valore specifico prima di confermarne il significato aziendale.

Per le organizzazioni che conducono modernizzazione dell'eredità programmi, SMART TS XLL'estrazione dei metadati fornisce le basi per la pre-migrazione: i metadati tecnici a livello di campo necessari agli strumenti di migrazione per mappare i campi di origine agli schemi di destinazione, la provenienza operativa di cui i programmi di migrazione hanno bisogno per sequenziare correttamente le migrazioni dei dataset e il vocabolario semantico a 88 livelli che consente una mappatura accurata dai valori del codice COBOL alle definizioni dei vincoli relazionali.

L'urgenza di recuperare i metadati prima che la conoscenza vada perduta.

Il problema della ricostruzione dei metadati ha una scadenza naturale che non si applica alla maggior parte delle sfide di governance dei dati: il pensionamento degli sviluppatori che detengono la conoscenza istituzionale che l'analisi del codice non è in grado di recuperare. Quasi un terzo dei programmatori COBOL andrà in pensione entro il 2030. L'età media di un ingegnere mainframe è di 58.7 anni. Ogni anno che passa senza un'estrazione sistematica dei metadati e un arricchimento semantico riduce la finestra temporale in cui è possibile la validazione umana dei metadati recuperati.

I metadati tecnici, le definizioni dei campi, le specifiche dei tipi, le dipendenze dei programmi e la provenienza dei dati sono recuperabili dal codice sorgente a tempo indeterminato, finché il codice sorgente esiste. I metadati semantici, ovvero il significato di ciascun campo in termini aziendali, le decisioni storiche alla base della progettazione dei campi e le convenzioni implicite non documentate dalle specifiche tecniche, sono recuperabili solo dalle persone che li conoscono e solo finché sono disponibili.

Un programma di gestione dei metadati per sistemi pluridecennali che inizia con l'estrazione tecnica e procede all'arricchimento semantico mentre le competenze specifiche del settore sono ancora disponibili, produce una base di metadati completa e recuperabile. Lo stesso programma, se rimandato a quando le conoscenze non saranno più disponibili, produce una base di metadati tecnici che, pur essendo accurata, è incompleta, corretta per quanto riguarda la struttura dei dati, ma tace sul loro significato.

I metadati sono la mappa. Sistemi pluridecennali li hanno seppelliti.

La governance dei dati per i sistemi moderni inizia con metadati aggiornati, accessibili e almeno parzialmente documentati. La governance dei dati per sistemi che durano da decenni inizia con metadati distribuiti su migliaia di file di codice sorgente, parzialmente documentati in specifiche precedenti all'avvento di Internet e parzialmente custoditi nella memoria di sviluppatori prossimi alla pensione.

Il percorso da dati nascosti a dati gestiti passa attraverso l'estrazione, la ricostruzione e l'arricchimento, in quest'ordine. I metadati tecnici estratti dal codice sorgente forniscono l'inventario iniziale. La provenienza operativa ricostruita a partire dalle dipendenze del programma fornisce la mappa di provenienza. L'arricchimento semantico, convalidato da esperti del settore, fornisce il significato aziendale che rende i metadati tecnici utilizzabili per analisi, intelligenza artificiale e governance.

Le moderne piattaforme di catalogazione dati sono la destinazione di questi metadati, non il punto di partenza. Prima che Collibra possa gestirli, Alation possa catalogarli e gli scienziati dei dati possano farvi affidamento, i metadati contenuti in sistemi pluridecennali devono essere prima individuati, nelle voci FD, nei copybook, nei nomi delle condizioni di livello 88 e nelle regole aziendali codificate in quarant'anni di logica della PROCEDURE DIVISION.

La mappa esiste. Bisogna solo saperla leggere.