Marken TRANS-AMT-CD i et COBOL-program har været i produktion siden 1981. FD-posten definerer det som PIC S9(9)V99 COMP-3, et pakket decimalt fortegnsfelt, elleve cifre, to implicitte decimaler. Det er de tekniske metadata. Forretningsmetadataene, hvad TRANS-AMT-CD rent faktisk betyder, hvilken valuta det er denomineret i, om de to implicitte decimaler betyder cent eller basispoint, om en negativ værdi repræsenterer en kredit eller en debet, og hvordan en nulværdi skal fortolkes, findes ingen steder i kodebasen. Det fandtes i et funktionelt specifikationsdokument, der blev trykt i 1981, arkiveret i et arkivskab og ikke er set siden. De to udviklere, der oprindeligt vidste, hvad TRANS-AMT-CD betød, gik begge på pension i 2014.
Dette er den metadatasituation, som enhver organisation med datasystemer, der strækker sig over flere årtier, står over for, og det er den metadatasituation, som moderne datastyringsrammer ikke er designet til at håndtere. Collibra, Alation, Atlan og alle andre virksomhedsdatakatalogplatforme er fremragende til at styre metadata for data, der allerede er beskrevet, clouddatabaser med dokumenterede skemaer, datalagre med defineret kolonnesemantik, API-slutpunkter med OpenAPI-specifikationer. De er ikke designet til at rekonstruere metadata, der aldrig formelt blev registreret, som kun eksisterer i programmers adfærd, der er skrevet, før metadatahåndtering var en disciplin, og som er blevet modificeret af snesevis af udviklere over fire årtier uden at nogen har opdateret en central registrering af, hvad hvert felt betyder.
Metadatahåndtering for datasystemer, der strækker sig over flere årtier, er ikke det samme problem som metadatahåndtering for moderne systemer. Det kræver en fundamentalt anderledes tilgang, en tilgang der starter med metadataudtrækning fra kildeartefakter snarere end metadataindtagelse fra forbundne systemer.
Find mening før den går på pension
SMART TS XL udtrækker tekniske metadata på feltniveau fra FD-poster og kopibøger, før katalogværktøjer kan styre det.
FÅ MERE AT VIDE…De tre lag af ældre metadata
Forståelse af metadataproblemet i systemer med flere årtier kræver en erkendelse af, at metadata i disse miljøer findes i tre forskellige lag, hvert med forskellig udtrækkelighed, forskellig fuldstændighed og forskellige styringsimplikationer.
Tekniske metadata er det mest udtrækkelige lag. Det beskriver den fysiske struktur af data: feltnavne, datatyper, længder, positioner i poster, numeriske præcisionsspecifikationer og relationerne mellem felter i et postlayout. I COBOL-miljøer findes tekniske metadata i kildekodeartefakter: FD-poster definerer postlayouts, COPY-medlemmer definerer genanvendelige datastrukturer, SELECT-klausuler definerer filorganisering og adgangsmetoder, og JCL DD-sætninger definerer de datasæt, der er knyttet til hver programudførelse. Dette lag er i princippet maskinlæsbart, og en parser, der forstår COBOL-syntaks, kan udtrække det fra kildekoden, men det er distribueret på tværs af tusindvis af kildefiler i stedet for centraliseret i et skemaregister.
Operationelle metadata beskriver, hvordan data bevæger sig gennem systemet: hvilke programmer producerer hvilke datasæt, hvilke programmer forbruger dem, i hvilken rækkefølge og gennem hvilke transformationer. I mainframe-miljøer distribueres operationelle metadata på tværs af JCL-jobstrømme (som definerer udførelsessekvenser og datasætassociationer), programkaldsgrafer (som definerer dataflow mellem programmer) og schedulerkonfigurationen (som definerer timing og afhængigheder). Dette lag kan også maskinudtrækkes fra kildeartefakterne, selvom udtrækningen ikke kun kræver forståelse af individuelle programmer, men også relationerne mellem dem.
Forretnings- eller semantiske metadata er det mindst udtrækkelige og mest værdifulde lag. Det besvarer de spørgsmål, som tekniske metadata ikke kan: hvad gør TRANS-AMT-CD betyder det egentlig i forretningsmæssige termer? Hvad er de gyldige værdier for ACCT-TYPE-CD og hvad betyder hver værdi? Hvilken forretningsregel bestemmer hvornår CUST-STATUS-FLG overgange fra A til IDette lag findes, når det overhovedet findes, i specifikationsdokumenter, i udviklerhukommelse, i institutionel viden, der opbevares af medarbejdere, der muligvis er gået på pension, og i den proceduremæssige logik i programmer, der håndhæver forretningsregler gennem IF-sætninger og EVALUATE-blokke i stedet for gennem databasebegrænsninger.
Metadata-udfordringen for systemer, der strækker sig over flere årtier, er, at disse tre lag er blevet administreret forskelligt, eller slet ikke er blevet administreret, gennem årtiers systemudvikling. Tekniske metadata blev registreret i kildekoden, men aldrig formaliseret i en dataordbog. Operationelle metadata var implicitte i JCL-jobstrømme, men blev aldrig dokumenteret som en afstamningspost. Forretningsmetadata blev dokumenteret i specifikationer på tidspunktet for den indledende udvikling og blev aldrig opdateret, efterhånden som systemerne udviklede sig.
Problemet med metadatadrift
Hvert år, hvor et system strækker sig over flere årtier, opererer uden systematisk metadatahåndtering, og kløften mellem de metadata, der findes i formel dokumentation, og de metadata, der afspejler systemets faktiske nuværende adfærd, udvides. Denne forskydning sker gennem fire mekanismer:
Felt betyder evolution. Et felt, der blev defineret med én forretningsmæssig betydning i 1978, kan have akkumuleret yderligere betydninger i løbet af de efterfølgende årtier. ACCT-TYPE-CD kan oprindeligt have skelnet mellem checkkonti og opsparingskonti. I løbet af fyrre år kan der være blevet tilføjet yderligere koder for at repræsentere pengemarkedskonti, indlånsbeviser, IRA-konti og escrow-konti, hvor hver tilføjelse kun er dokumenteret i den programkode, der håndterer den nye kodeværdi, ikke i nogen central feltdefinition. Feltets navn og type er uændret; dets semantiske betydning er blevet væsentligt mere kompleks.
Stille genbrug. Felter får lejlighedsvis et nyt formål uden at blive omdøbt. Et felt, der blev brugt til ét formål, bliver ubelejligt at udvide, og en udvikler bruger en tidligere ubrugt værdi fra et tilstødende flagfelt til at kode et andet stykke information. TRANS-FLAG-1 kan nu kode tre forskellige koncepter på tværs af forskellige programkontekster, som kun kan skelnes ved at undersøge, hvilke programmer der læser feltet, og under hvilke betingelser. De tekniske metadata, feltnavn, type, længde giver ingen indikation af, at feltet er semantisk overbelastet.
REDEFINES-akkumulering. Som diskuteret i VSAM-analysesammenhænge, lægger REDEFINES-klausuler sig oven på den samme fysiske lagring med forskellige feltfortolkninger. Hver REDEFINES-variant kan være blevet tilføjet på et andet tidspunkt i systemets historie, af forskellige udviklere, til forskellige forretningsformål. Den komplette semantiske betydning af et REDEFINES-hierarki, hvilken variant der gælder hvornår, og hvad hver variants felter betyder, kan kun rekonstrueres ved at analysere alle de programmer, der tilgår hver variant, og de betingelser, hvorunder de gør det.
Afvigelse i kopibog. Når en standard COBOL-kopibog ændres for at imødekomme et nyt krav, kan programmer, der inkluderede kopibogen og ikke blev opdateret til at håndtere det nye felt, opføre sig forkert eller simpelthen ignorere det nye felt. Over årtiers udvikling kan der findes flere versioner af, hvad der nominelt er den samme kopibog, i forskellige biblioteker, hvor forskellige programmer bruger forskellige versioner. Metadataene for et felt, der er defineret i kopibogen, kan variere på tværs af programmer afhængigt af hvilken version af kopibogen hvert program inkluderer.
Hvad moderne metadataværktøjer ikke kan gøre for ældre data
Markedet for virksomhedsdatakataloger er modnet betydeligt. Collibra, Alation, Atlan, Microsoft Purview og Informatica Axon er sofistikerede platforme til styring af metadata på tværs af moderne datamiljøer. De udmærker sig ved: automatisk registrering af skemaer fra forbundne databaser, sporing af dataafstamning på kolonneniveau på tværs af ETL-pipelines, vedligeholdelse af forretningsordlister med kuraterede termdefinitioner og fremvisning af datakvalitetsmålinger sammen med metadataposter.
Hvad disse værktøjer ikke kan gøre for COBOL- og mainframe-systemer med flere årtiers mellemrum:
De kan ikke oprette forbindelse til det, de ikke kan se. Moderne kataloger opdager metadata via forbindelser, JDBC-forbindelser til databaser, API-integrationer med cloud-tjenester, scannerintegrationer med understøttede platforme. VSAM-filer, COBOL-programmer og JCL-jobstrømme har ingen standardkatalogforbindelser. Kataloget kan ikke opdage det, det ikke har nogen mekanisme til at nå. De data, der administreres af disse systemer, er reelt usynlige for kataloget, hvilket betyder, at de lineage-poster for downstream cloud-analyser, der stammer fra disse data, er ufuldstændige eller fraværende.
De kan ikke udtrække metadata, der kun findes i kode. Et datakatalog, der er forbundet til en DB2-database, kan læse databaseskemaet, tabeldefinitioner, kolonnenavne, datatyper og indeks. Det kan ikke læse COBOL-programmet, der udfylder DB2-tabellen, for at forstå, hvilke forretningsregler der styrer populationen, hvilke REDEFINES-varianter der findes i kildeposten, eller hvilke betingelsesnavne på 88 niveauer, der definerer den semantiske gyldighed af hvert felt. Metadata på kodeniveau, det lag, hvor den forretningsmæssige betydning af ældre data faktisk findes, kræver kodeanalyse, ikke katalogscanning.
De kan ikke rekonstruere betydning, der aldrig er blevet registreret. Selv med en perfekt teknisk metadataudtrækning kan den forretningsmæssige betydning af felter, der aldrig er blevet formelt dokumenteret, ikke rekonstrueres automatisk. Dette lag kræver en kombination af kodeanalyse (for at afdække de forretningsregler, som programmer anvender på dataene, som er stedfortrædere for forretningsmæssig betydning) og menneskelig gennemgang (for at validere rekonstrueret betydning i forhold til institutionel viden, mens denne viden stadig eksisterer).
Metoden til rekonstruktion af metadata
For systemer med flere årtiers mellemrum, hvor formelle metadata aldrig er blevet registreret eller har afveget væsentligt fra den nuværende virkelighed, kræver metadatahåndtering en rekonstruktionsfase før en styringsfase. Rekonstruktionsmetoden udtrækker de gendannelige lag og identificerer de huller, hvor menneskelig viden er påkrævet.
Fase 1: Udtrækning af teknisk metadata fra kildeartefakter.
Parser alle COBOL FD-poster, COPY-medlemmer, SELECT-klausuler og JCL DD-sætninger for at oprette en teknisk metadataopgørelse på feltniveau:
COBOL
* 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).Fra denne ene FD-post producerer teknisk metadataudtrækning: feltnavne, datatyper, længder, positioner, den pakkede decimalpræcision for TRANS-AMT-CD (9 cifre, 2 decimaler, fortegn), de fire semantiske værdier af TRANS-TYPE-CD som defineret af betingelsesnavnene på 88 niveauer, og REDEFINES-strukturen, der opretter to overlappende fortolkninger af byte 10-105 i posten.
Betingelsesnavnene på 88 niveauer er særligt værdifulde som metadata: TRANS-PAYMENT, TRANS-REFUND, TRANS-ADJUSTMENT, TRANS-REVERSAL er fire elementer af forretningsvokabular, som selve COBOL-koden leverer, der er mere meningsfulde end det underliggende PM, RF, AJ, RV værdier, som et datakatalog, der scanner databasen, ville se.
Fase 2: Udtræk af operationelle metadata fra programafhængigheder.
Byg det operationelle afstamningskort ved at spore datastrømme gennem programafhængighedsgrafen:
- Hvilke programmer skriver til
TRANSACTION-FILE(producenter) - Hvilke programmer læser fra
TRANSACTION-FILE(forbrugere) - Hvilke JCL-jobtrin aktiverer hver producent og forbruger, i hvilken rækkefølge
- Hvilke downstream-datasæt og -databaser modtager data transformeret fra
TRANSACTION-FILE
Dette slægtskort er de operationelle metadata, som datakatalogværktøjer har brug for til slægtsvisualisering, men ikke kan konstruere uden adgang til kildeprogramkoden og JCL.
Fase 3: Udtræk af forretningsregler som semantisk metadata-proxy.
Forretningsregler kodet i COBOL PROCEDURE DIVISION-logik er proxyer for forretningsmæssig betydning. Et program, der validerer TRANS-AMT-CD for at sikre, at det falder inden for bestemte intervaller, før behandlingen giver bevis for feltets gyldige interval. Et program, der konverterer TRANS-AMT-CD til en anden enhed, før der skrives til et downstream-system, afslører en implicit decimal- eller enhedskonvention.
Udtrækning af disse forretningsregler gennem kodeanalyse producerer et sæt af udledte semantiske metadata: valideringsintervallerne anvendt på hvert felt, de transformationer, der forekommer mellem kilde og mål, og de betingelser, hvorunder forskellige kodestier udføres. Disse udledte semantiske metadata er upræcise, de viser, hvad programmer gør med dataene, ikke nødvendigvis hvad dataene var tiltænkt at betyde, men de kan gendannes fra koden på en måde, som det originale specifikationsdokument ikke kan.
Fase 4: Menneskelig validering og semantisk berigelse.
De udtrukne tekniske og operationelle metadata og de udledte semantiske metadata danner grundlag for menneskelige valideringssessioner med domæneeksperter og pensionerede udviklere. Målet er at konvertere udledt semantik til bekræftet semantik og validere, at TRANS-AMT-CD betyder, hvad koden antyder, at den betyder, identificerer tilfælde, hvor kodens adfærd ikke længere afspejler den tilsigtede forretningsmæssige betydning, og indfanger institutionel viden om felthistorik, som kodeanalyse ikke kan gendanne.
Denne fase er tidsbegrænset af tilgængeligheden af domæneekspertise: hvert år der går, går mere af denne viden på pension hos de mennesker, der besidder den.
Det gamle metadatagab ved den moderne systemgrænse
Metadataunderskuddet, der skabes af systemer med flere årtiers mellemrum, forbliver ikke indeholdt i det ældre miljø. Det forplanter sig nedstrøms: ethvert analysesystem, datalager og maskinlæringspipeline, der forbruger data fra ældre systemer, arver metadatahullet.
Et cloud-datalager, der modtager et natligt fladt filuddrag fra et COBOL-batchprogram, har i sine kolonnedefinitioner det navn, som data engineering-teamet valgte at navngive kolonnerne, da de byggede ETL-pipelinen. Hvis det oprindelige felt var TRANS-AMT-CD og ETL-udvikleren navngav målkolonnen transaction_amount, datalageret ser ud til at have komplette metadata: kolonnenavn, datatype, virksomhedsbeskrivelse tilføjet til kataloget. Hvad kataloget ikke registrerer er, at transaction_amount stammede fra TRANS-AMT-CD in TRANSACTION-FILE, som er produceret af et COBOL-program ved navn TRNSRC01, som kører i JCL-jobbet TRANSDAY hver nat kl. 2 om natten, og som anvender en specifik valutaomregning, der blev hardkodet i 1987 baseret på en valutakurskonvention, der måske stadig er gyldig eller ej.
Den downstream metadatapost ser komplet ud. Afstamningen er brudt ved legacy-grænsen. Enhver analytisk eller AI-arbejdsbelastning, der afhænger af forståelsen af oprindelsen og betydningen af transaction_amount har et hul, hvor den faktiske oprindelseshistorie for den pågældende værdi ikke er dokumenteret.
Gartners fund om, at 60 procent af AI-projekter, der ikke understøttes af AI-klare data, vil blive opgivet inden 2026, er delvist en metadata-erklæring. AI-modeller, der forbruger transaction_amount uden at vide, at det stammer fra et pakket decimal COBOL-felt med en implicit decimal, denomineret i en valuta, der muligvis er blevet konverteret ved hjælp af en valutakurskonvention fra 1987, træner på data, hvis oprindelse er uigennemsigtig. Modellen kan ikke vide, hvorvidt den skal have mistillid til eller justere for denne kontekst, fordi de metadata, der ville kommunikere det, ikke findes i noget katalog, som modellen eller dens datapipeline kan tilgå.
Opbygning af et metadatahåndteringsprogram til ældre systemer
Et metadatahåndteringsprogram til datasystemer, der dækker flere årtier, har fire komponenter, der adskiller sig fra standard implementeringer af virksomhedsdatakataloger:
Komponent 1: Udtræk af kildekodemetadata. Før et katalogværktøj kan styre ældre metadata, skal metadataene udtrækkes fra de kildeartefakter, hvor de findes. Denne udtræk skal dække: FD-poster og kopibøger (tekniske metadata til datastrukturer), SELECT-klausuler (filorganisation og adgangsmetode), JCL DD-sætninger (datasætassociationer og filkarakteristika) og 88-niveau betingelsesnavne (semantisk værdivokabular indlejret i kildekode). Outputtet er en metadatafortegnelse på feltniveau, der kan indlæses i et katalog som udgangspunkt for forretningsberigelse.
Komponent 2: Rekonstruktion af afstamning. Dataafstamning for ældre systemer skal rekonstrueres fra programafhængighedsanalyse snarere end fra sporing af ETL-værktøjer. Afstamningskortet sporer data fra det oprindelige COBOL-program gennem mellemliggende transformationsprogrammer til dets endelige forbrugere, herunder de ETL-processer, der leverer dem til moderne analytiske systemer. Denne rekonstruktion lukker afstamningsgabet ved den ældre grænse og forbinder cloud-datavarehuskolonnens metadata med COBOL FD-postmetadataene gennem en dokumenteret kæde af programafhængigheder.
Komponent 3: Semantisk berigelse med domæneekspertise. Udtrukne tekniske metadata giver strukturen; bekræftet forretningsmæssig betydning kræver domæneekspertise. Berigelsesprocessen bruger de tekniske metadata som en struktureret prompt til ekspertinterviews: "Dette felt er defineret som PIC S9(9)V99 COMP-3, den valideres til at være ikke-negativ i 14 programmer, og den konverteres til en anden skala, før den skrives til downstream-databasen. Kan du bekræfte, hvad den repræsenterer, og hvad konverteringen betyder?” Denne strukturerede tilgang bruger kodeanalyse til at maksimere informationsværdien af hver ekspertinteraktion, hvilket muliggør hurtigere og mere komplet berigelse end ustrukturerede dokumentationsgennemgange.
Komponent 4: Integration af styring med moderne katalogplatforme. Når ældre metadata er udtrukket, rekonstrueret og beriget, skal de integreres med den moderne infrastruktur til metadatastyring. Denne integration forbinder det ældre metadatalager med virksomhedens datakatalog og leverer: afstamning på kolonneniveau fra COBOL-kilde til cloud-mål, forretningsordlistetermer knyttet til definitioner af ældre felter og metadata for datakvalitet for ældre datasæt, der udfylder den samme styringsramme som moderne systemmetadata.
Hvordan SMART TS XL Udtrækker ældre metadata
SMART TS XL adresserer de to første komponenter i det ældre metadatahåndteringsprogram, udvinding af kildekodemetadata og rekonstruktion af afstamning, ved at anvende statisk analyse på hele COBOL-, JCL- og copybook-porteføljen.
Funktionen til statisk kodeanalyse analyserer alle FD-poster, COPY-medlemmer, SELECT-klausuler og 88-niveau definitioner på tværs af COBOL-porteføljen og producerer dermed den tekniske metadatafortegnelse på feltniveau: hvert feltnavn, datatype, længde, COMP-specifikation, REDEFINES-medlemskab og 88-niveau betingelsesnavn på tværs af alle programmer og kopibøger i miljøet. For en portefølje med tusindvis af COBOL-programmer producerer denne udtrækning på få timer den tekniske metadatafortegnelse, som manuel dokumentation ville kræve år at producere, hvis den overhovedet kunne produceres fuldstændigt.
Applikationsafhængighedskortlægningen opbygger det operationelle afstamningskort : hver program-til-datasæt-relation (hvilke programmer producerer hvilke datasæt, og hvilke forbruger dem), hver program-til-program-afhængighed (hvilke programmer kalder hvilke andre, og hvilke data flyder mellem dem) og hver JCL-til-program-relation (hvilke jobtrin kalder hvilke programmer i hvilken rækkefølge). Dette afstamningskort er det operationelle metadatalag, der lukker hullet mellem ældre kildesystemer og det moderne datakatalogs afstamningsposter.
JCL -udvidelsesfunktionen sporer den komplette udførelseskæde for hvert JCL-job: løsning af PROC-referencer, udvidelse af symbolske parametre og opbygning af de fulde operationelle metadata for hvert datasæts produktion og forbrug, planlægningskonteksten, de afhængige job og den udførelsessekvens, der bestemmer aktualiteten og friskhedsegenskaberne for hvert datasæt.
Virksomhedssøgningsfunktionen gør det muligt at forespørge på den udtrukne metadataopgørelse i hele metadatastyringsprogrammet: find alle felter defineret som COMP-3 (præcisionsfølsomme felter, der kræver omhyggelig målkortlægning), alle programmer, der læser et specifikt felt (identificerer alle forbrugere af et specifikt dataelement for afstamning og semantisk berigelse), alle betingelsesnavne på 88 niveauer, der matcher et specifikt forretningsudtryk (kortlægning af forretningsvokabular til tekniske feltdefinitioner). Denne søgefunktion understøtter den semantiske berigelsesproces, der gør det muligt for domæneeksperter at finde alle anvendelser af et specifikt felt eller en værdi, før de bekræfter dets forretningsmæssige betydning.
For organisationer, der udfører arvemodernisering programmer, SMART TS XLs metadataudtrækning giver fundamentet før migrering: de tekniske metadata på feltniveau, som migreringsværktøjer skal bruge for at knytte kildefelter til målskemaer, den operationelle afstamning, som migreringsprogrammer skal bruge for at sekventere datasætmigreringer korrekt, og det semantiske ordforråd på 88 niveauer, der muliggør nøjagtig kortlægning fra COBOL-kodeværdier til relationelle begrænsningsdefinitioner.
Det haster med at gendanne metadata, før viden forsvinder
Problemet med metadata-rekonstruktion har en naturlig deadline, der ikke gælder for de fleste udfordringer med data governance: pensioneringen af de udviklere, der besidder den institutionelle viden, som kodeanalyse ikke kan genskabe. Næsten en tredjedel af COBOL-programmører vil gå på pension inden 2030. Den gennemsnitlige alder for mainframe-ingeniører er 58.7 år. Hvert år, der går uden systematisk metadataudtrækning og semantisk berigelse, indsnævres det vindue, hvor menneskelig validering af gendannede metadata er mulig.
De tekniske metadata, feltdefinitioner, typespecifikationer, programafhængigheder og dataafstamning kan gendannes fra kildekoden på ubestemt tid, så længe kildekoden eksisterer. De semantiske metadata, hvad hvert felt betyder i forretningsmæssige termer, hvad de historiske beslutninger bag feltdesign var, og hvad de implicitte konventioner er, som de tekniske specifikationer ikke dokumenterer, kan kun gendannes fra de personer, der kender dem, og kun så længe de forbliver tilgængelige.
Et metadatahåndteringsprogram til systemer med flere årtiers mellemrum, der starter med teknisk udtrækning og fortsætter til semantisk berigelse, mens domæneekspertise stadig er tilgængelig, producerer et komplet, gendanneligt metadatafundament. Det samme program, der udskydes til efter at videnen er ophørt, producerer et teknisk metadatafundament, der er nøjagtigt, men ufuldstændigt, korrekt med hensyn til datastrukturen, tavst om deres betydning.
Metadata er kortet. Systemer fra flere årtier begravede det.
Datastyring for moderne systemer begynder med metadata, der er aktuelle, tilgængelige og i det mindste delvist dokumenterede. Datastyring for systemer, der har flere årtier på bagen, begynder med metadata, der er fordelt på tværs af tusindvis af kildekodefiler, delvist dokumenteret i specifikationer, der er ældre end internettet, og delvist opbevaret i hukommelsen hos udviklere, der nærmer sig pensionering.
Vejen fra nedgravet til styret løber gennem udtrækning, rekonstruktion og berigelse i nævnte rækkefølge. Tekniske metadata udtrukket fra kildekoden giver startopgørelsen. Operationel afstamning rekonstrueret fra programafhængigheder giver provenienskortet. Semantisk berigelse valideret af domæneekspertise giver den forretningsmæssige betydning, der gør de tekniske metadata brugbare til analyser, AI og styring.
Moderne datakatalogplatforme er destinationen for disse metadata, ikke udgangspunktet. Før Collibra kan styre dem, og Alation kan katalogisere dem, og dataforskere kan stole på dem, skal de metadata, som systemer med flere årtier indeholder, først findes i FD-posterne, i kopibøgerne, i betingelsesnavnene på 88 niveauer og i de forretningsregler, der er kodet i fyrre års PROCEDURE DIVISION-logik.
Kortet findes. Det skal bare læses.
