Metadatahantering för datasystem som spänner över flera decennier

Fältet TRANS-AMT-CD i ett COBOL-program har varit i produktion sedan 1981. FD-posten definierar det som PIC S9(9)V99 COMP-3, ett packat decimalt förtecken numeriskt fält, elva siffror, två implicita decimaler. Det är de tekniska metadata. Affärsmetadata, vad TRANS-AMT-CD egentligen betyder, vilken valuta den är denominerad i, om de två implicita decimalerna betyder cent eller baspunkter, om ett negativt värde representerar en kredit eller en debet, och hur ett nollvärde ska tolkas, finns ingenstans i kodbasen. Det fanns i ett funktionellt specifikationsdokument som trycktes 1981, arkiverades i ett arkivskåp och har inte setts sedan dess. De två utvecklare som ursprungligen visste vad TRANS-AMT-CD betyder gick båda i pension 2014.

Det här är den metadatasituation som alla organisationer med datasystem som sträcker sig över flera decennier står inför, och det är den metadatasituation som moderna ramverk för datastyrning inte utformades för att hantera. Collibra, Alation, Atlan och alla andra plattformar för företagsdatakataloger är utmärkta på att styra metadata för data som redan är beskriven, molndatabaser med dokumenterade scheman, datalager med definierad kolumnsemantik, API-slutpunkter med OpenAPI-specifikationer. De är inte utformade för att rekonstruera metadata som aldrig formellt registrerades, som bara existerar i beteendet hos program som skrivits innan metadatahantering var en disciplin, och som har modifierats av dussintals utvecklare under fyra decennier utan att någon har uppdaterat en central post över vad varje fält betyder.

Metadatahantering för datasystem som sträcker sig över flera decennier är inte samma problem som metadatahantering för moderna system. Det kräver en fundamentalt annorlunda strategi, en som börjar med metadatautvinning från källartefakter snarare än metadataintag från anslutna system.

De tre lagren av äldre metadata

Att förstå metadataproblemet i system som spänner över flera decennier kräver att man inser att metadata i dessa miljöer finns i tre distinkta lager, vart och ett med olika extraherbarhet, olika fullständighet och olika styrningsimplikationer.

Tekniska metadata är det mest extraherbara lagret. Det beskriver datas fysiska struktur: fältnamn, datatyper, längder, positioner inom poster, numeriska precisionsspecifikationer och relationerna mellan fält inom en postlayout. I COBOL-miljöer finns tekniska metadata i källkodsartefakter: FD-poster definierar postlayouter, COPY-medlemmar definierar återanvändbara datastrukturer, SELECT-klausuler definierar filorganisation och åtkomstmetoder, och JCL DD-satser definierar de dataset som är associerade med varje programkörning. Detta lager är i princip maskinläsbart, en parser som förstår COBOL-syntax kan extrahera det från källkoden, men det är distribuerat över tusentals källfiler snarare än centraliserat i ett schemaregister.

Operativa metadata beskriver hur data rör sig genom systemet: vilka program producerar vilka datamängder, vilka program konsumerar dem, i vilken sekvens och genom vilka transformationer. I stordatormiljöer distribueras operativa metadata över JCL-jobbströmmar (som definierar exekveringssekvenser och datamängdsassociationer), programanropsgrafer (som definierar dataflöden mellan program) och schemaläggningskonfigurationen (som definierar timing och beroenden). Detta lager är också maskinextraherbart från källartefakterna, även om extraheringen kräver förståelse inte bara för enskilda program utan även för relationerna mellan dem.

Affärs- eller semantiska metadata är det minst extraherbara och mest värdefulla lagret. Det besvarar de frågor som tekniska metadata inte kan: vad gör TRANS-AMT-CD egentligen betyder det i affärstermer? Vilka är de giltiga värdena för ACCT-TYPE-CD och vad betyder varje värde? Vilken affärsregel avgör när CUST-STATUS-FLG övergångar från A till IDetta lager existerar, när det överhuvudtaget existerar, i specifikationsdokument, i utvecklarminne, i institutionell kunskap som innehas av anställda som kan ha gått i pension, och i den procedurella logiken i program som tillämpar affärsregler genom IF-satser och EVALUATE-block snarare än genom databasbegränsningar.

Metadatautmaningen för system som spänner över flera decennier är att dessa tre lager har hanterats olika, eller inte hanterats alls, under årtionden av systemutveckling. Tekniska metadata registrerades i källkoden men formaliserades aldrig till en datalexikon. Operativa metadata var implicit i JCL-jobbströmmar men dokumenterades aldrig som en avstamningspost. Affärsmetadata dokumenterades i specifikationer vid tidpunkten för den initiala utvecklingen och uppdaterades aldrig allt eftersom systemen utvecklades.

Problemet med metadatadrift

Varje år som ett system som sträcker sig över flera decennier fungerar utan systematisk metadatahantering, vidgas gapet mellan de metadata som finns i formell dokumentation och de metadata som återspeglar systemets faktiska nuvarande beteende. Denna förskjutning sker genom fyra mekanismer:

Fält betyder evolution. Ett område som definierades med en affärsmässig betydelse år 1978 kan ha ackumulerat ytterligare betydelser under efterföljande årtionden. ACCT-TYPE-CD kan ursprungligen ha åtskilt checkkonton från sparkonton. Under fyrtio år kan ytterligare koder ha lagts till för att representera penningmarknadskonton, depositionsbevis, IRA-konton och spärrkonton, där varje tillägg endast dokumenterats i programkoden som hanterar det nya kodvärdet, inte i någon central fältdefinition. Fältets namn och typ är oförändrade; dess semantiska betydelse har blivit betydligt mer komplex.

Tyst återanvändning. Fält får ibland ett nytt syfte utan att byta namn. Ett fält som användes för ett ändamål blir obekvämt att utöka, och en utvecklare använder ett tidigare oanvänt värde från ett angränsande flaggfält för att koda en annan information. TRANS-FLAG-1 kan nu koda tre olika koncept i olika programkontexter, vilka endast kan särskiljas genom att undersöka vilka program som läser fältet och under vilka förhållanden. De tekniska metadata, fältnamn, typ, längd, ger ingen indikation på att fältet är semantiskt överbelastat.

REDEFINES-ackumulering. Som diskuterats i VSAM-analyskontexter överlagrar REDEFINES-klausuler samma fysiska lagring med olika fälttolkningar. Varje REDEFINES-variant kan ha lagts till vid en annan tidpunkt i systemets historia, av olika utvecklare, för olika affärsändamål. Den fullständiga semantiska betydelsen av en REDEFINES-hierarki, vilken variant som gäller när, vad varje variants fält betyder, kan bara rekonstrueras genom att analysera alla program som har åtkomst till varje variant och de villkor under vilka de gör det.

Avvikelse i kopieboken. När en vanlig COBOL-kopiebok modifieras för att tillgodose ett nytt krav, kan program som inkluderade kopieboken och inte uppdaterades för att hantera det nya fältet bete sig felaktigt eller helt enkelt ignorera det nya fältet. Under årtionden av utveckling kan flera versioner av vad som nominellt är samma kopiebok finnas i olika bibliotek, med olika program som använder olika versioner. Metadata för ett fält som definieras i kopieboken kan skilja sig åt mellan program beroende på vilken version av kopieboken varje program inkluderar.

Vad moderna metadataverktyg inte kan göra för äldre data

Marknaden för företagsdatakataloger har mognat avsevärt. Collibra, Alation, Atlan, Microsoft Purview och Informatica Axon är sofistikerade plattformar för att styra metadata i moderna datamiljöer. De utmärker sig på: automatisk identifiering av scheman från anslutna databaser, spårning av datalinjer på kolumnnivå över ETL-pipelines, underhåll av affärsordlistor med kurerade termdefinitioner och framtagning av datakvalitetsmått tillsammans med metadataposter.

Vad dessa verktyg inte kan göra för COBOL- och stordatorsystem som spänner över flera decennier:

De kan inte ansluta till det de inte kan se. Moderna kataloger upptäcker metadata via kopplingar, JDBC-kopplingar till databaser, API-integrationer med molntjänster, skannerintegrationer med plattformar som stöds. VSAM-filer, COBOL-program och JCL-jobbströmmar har inga standardkatalogkopplingar. Katalogen kan inte upptäcka det den inte har någon mekanism att nå. De data som hanteras av dessa system är i praktiken osynliga för katalogen, vilket innebär att de härledande posterna för nedströms molnanalys som härrör från dessa data är ofullständiga eller saknas.

De kan inte extrahera metadata som bara finns i kod. En datakatalog som är ansluten till en DB2-databas kan läsa databasschemat, tabelldefinitioner, kolumnnamn, datatyper och index. Den kan inte läsa COBOL-programmet som fyller i DB2-tabellen för att förstå vilka affärsregler som styr populationen, vilka REDEFINES-varianter som finns i källposten eller vilka villkorsnamn på 88-nivå som definierar den semantiska giltigheten för varje fält. Metadata på kodnivå, det lager där den affärsmässiga innebörden av äldre data faktiskt finns, kräver kodanalys, inte katalogskanning.

De kan inte rekonstruera betydelse som aldrig har registrerats. Även med en perfekt teknisk metadataextraktion kan den affärsmässiga betydelsen av fält som aldrig formellt dokumenterats inte rekonstrueras automatiskt. Detta lager kräver en kombination av kodanalys (för att framhäva de affärsregler som programmen tillämpar på data, vilka är proxyer för affärsmässig betydelse) och mänsklig granskning (för att validera rekonstruerad betydelse mot institutionell kunskap medan den kunskapen fortfarande finns).

Metoden för rekonstruktion av metadata

För system som sträcker sig över flera decennier och där formella metadata aldrig har registrerats eller har avvikit avsevärt från den nuvarande verkligheten, kräver metadatahantering en rekonstruktionsfas innan en styrningsfas. Rekonstruktionsmetoden extraherar de återställningsbara lagren och identifierar de luckor där mänsklig kunskap krävs.

Fas 1: Extraktion av teknisk metadata från källartefakter.

Parsa varje COBOL FD-post, COPY-medlem, SELECT-klausul och JCL DD-sats för att skapa en teknisk metadatainventering på fältnivå:

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).

Från denna enda FD-post producerar teknisk metadataextraktion: fältnamn, datatyper, längder, positioner, den packade decimalprecisionen för TRANS-AMT-CD (9 siffror, 2 decimaler, med tecken), de fyra semantiska värdena för TRANS-TYPE-CD såsom definieras av villkorsnamnen på 88 nivåer, och REDEFINES-strukturen som skapar två överlappande tolkningar av byte 10-105 i posten.

Villkorsnamnen på nivå 88 är särskilt värdefulla som metadata: TRANS-PAYMENT, TRANS-REFUND, TRANS-ADJUSTMENT, TRANS-REVERSAL är fyra affärsvokabulärelement som själva COBOL-koden tillhandahåller, mer meningsfulla än de underliggande PM, RF, AJ, RV värden som en datakatalog som skannar databasen skulle se.

Fas 2: Extraktion av operativa metadata från programberoenden.

Bygg den operativa härledningskartan genom att spåra dataflöden genom programberoendegrafen:

• Vilka program skriver till TRANSACTION-FILE (producenter)
• Vilka program läser från TRANSACTION-FILE (konsumenter)
• Vilka JCL-jobbsteg anropar varje producent och konsument, i vilken sekvens
• Vilka nedströmsdataset och databaser som tar emot data som transformerats från TRANSACTION-FILE

Denna härstamningskarta är de operativa metadata som datakatalogverktyg behöver för härstamningsvisualisering men inte kan konstruera utan åtkomst till källkoden och JCL.

Fas 3: Extraktion av affärsregler som semantisk metadataproxy.

Affärsregler kodade i COBOL PROCEDURE DIVISION-logik är proxyer för affärsbetydelse. Ett program som validerar TRANS-AMT-CD för att säkerställa att den faller inom vissa intervall innan bearbetningen ger bevis om fältets giltiga intervall. Ett program som konverterar TRANS-AMT-CD till en annan enhet innan man skriver till ett nedströmssystem avslöjar en underförstådd decimal- eller enhetskonvention.

Att extrahera dessa affärsregler genom kodanalys producerar en uppsättning härledda semantiska metadata: valideringsintervallen som tillämpas på varje fält, de transformationer som sker mellan källa och mål, och de förhållanden under vilka olika kodvägar exekveras. Dessa härledda semantiska metadata är oprecisa, de visar vad program gör med data, inte nödvändigtvis vad data var avsedda att betyda, men de kan återställas från koden på ett sätt som det ursprungliga specifikationsdokumentet inte kan.

Fas 4: Mänsklig validering och semantisk berikning.

De extraherade tekniska och operativa metadata och de härledda semantiska metadata utgör grunden för mänskliga valideringssessioner med domänexperter och pensionerade utvecklare. Målet är att omvandla härledd semantik till bekräftad semantik och validera att TRANS-AMT-CD betyder vad koden antyder att den betyder, identifierar fall där kodens beteende inte längre återspeglar den avsedda affärsmässiga innebörden och fångar upp institutionell kunskap om fälthistorik som kodanalys inte kan återställa.

Denna fas är tidsbegränsad av tillgången på domänexpertis: varje år som går går mer av denna kunskap i pension hos de personer som innehar den.

Det äldre metadatagapet vid den moderna systemgränsen

Metadataunderskottet som skapas av system som spridit sig över flera decennier kvarstår inte i den äldre miljön. Det sprider sig nedströms: varje analyssystem, datalager och maskininlärningspipeline som konsumerar data från äldre system ärver metadatagapet.

Ett molndatalager som tar emot ett nattligt platt filutdrag från ett COBOL-batchprogram har, i sina kolumndefinitioner, det namn som datateknikteamet valde att ge kolumnerna när de byggde ETL-pipelinen. Om det ursprungliga fältet var TRANS-AMT-CD och ETL-utvecklaren namngav målkolumnen transaction_amount, datalagret verkar ha fullständiga metadata: kolumnnamn, datatyp, verksamhetsbeskrivning tillagda i katalogen. Vad katalogen inte registrerar är att transaction_amount kommer ursprungligen från TRANS-AMT-CD in TRANSACTION-FILE, som produceras av ett COBOL-program med namnet TRNSRC01, som körs i JCL-jobbet TRANSDAY varje natt klockan 02:00, och som tillämpar en specifik valutaomvandling som hårdkodades 1987 baserat på en växelkurskonvention som kanske fortfarande är aktuell eller inte.

Den nedströms nedströms metadataposten ser komplett ut. Härstamningen är bruten vid den äldre gränsen. All analytisk eller AI-arbetsbelastning som är beroende av att förstå ursprunget och betydelsen av transaction_amount har en lucka där den faktiska ursprungshistorien för det värdet inte är dokumenterad.

Gartners upptäckt att 60 procent av AI-projekt som inte stöds av AI-klar data kommer att överges fram till 2026 är delvis ett metadatauttalande. AI-modeller som konsumerar transaction_amount utan att veta att det härstammar från ett packat decimalt COBOL-fält med en implicit decimal, denominerat i en valuta som kan ha konverterats med hjälp av en växelkurskonvention från 1987, tränar på data vars ursprung är ogenomskinligt. Modellen kan inte veta att den ska misstro eller justera för detta sammanhang eftersom metadata som skulle kommunicera det inte finns i någon katalog som modellen eller dess datapipeline kan komma åt.

Bygga ett metadatahanteringsprogram för äldre system

Ett metadatahanteringsprogram för datasystem som sträcker sig över flera decennier har fyra komponenter som skiljer sig från standardimplementeringar av företagsdatakataloger:

Komponent 1: Extraktion av metadata från källkod. Innan något katalogverktyg kan styra äldre metadata måste metadata extraheras från källartefakterna där de finns. Denna extraktion måste omfatta: FD-poster och kopior (tekniska metadata för datastrukturer), SELECT-klausuler (filorganisation och åtkomstmetod), JCL DD-satser (datauppsättningsassociationer och filegenskaper) och villkorsnamn på 88 nivåer (semantiskt värdevokabulär inbäddad i källkod). Utdata är en metadatainventering på fältnivå som kan läsas in i en katalog som utgångspunkt för affärsberikning.

Komponent 2: Linjerekonstruktion. Datalinje för äldre system måste rekonstrueras från programberoendeanalys snarare än från ETL-verktygslinjespårning. Linjekartan spårar data från sitt ursprungliga COBOL-program genom mellanliggande transformationsprogram till dess slutliga konsumenter, inklusive ETL-processerna som levererar den till moderna analyssystem. Denna rekonstruktion stänger linjegapet vid den äldre gränsen och kopplar molndatalagrets kolumnmetadata till COBOL FD-postmetadata genom en dokumenterad kedja av programberoenden.

Komponent 3: Semantisk berikning med domänexpertis. Extraherade tekniska metadata ger strukturen; bekräftad affärsmässig innebörd kräver domänexpertis. Anrikningsprocessen använder de tekniska metadata som en strukturerad prompt för expertintervjuer: ”Detta fält definieras som PIC S9(9)V99 COMP-3, den valideras som icke-negativ i 14 program, och den konverteras till en annan skala innan den skrivs till den efterföljande databasen, kan du bekräfta vad den representerar och vad konverteringen betyder?” Denna strukturerade metod använder kodanalys för att maximera informationsvärdet för varje expertinteraktion, vilket möjliggör snabbare och mer fullständig berikning än ostrukturerade dokumentationsgranskningar.

Komponent 4: Styrningsintegration med moderna katalogplattformar. När äldre metadata har extraherats, rekonstruerats och berikats måste de integreras med den moderna infrastrukturen för metadatastyrning. Denna integration kopplar det äldre metadataregistret till företagets datakatalog och tillhandahåller: kolumnnivåavstamning från COBOL-källa till molnmål, affärsordlistar länkade till äldre fältdefinitioner och datakvalitetsmetadata för äldre datamängder som använder samma styrningsramverk som moderna systemmetadata.

Hur SMART TS XL Extraherar äldre metadata

SMART TS XL behandlar de två första komponenterna i det äldre programmet för metadatahantering, extraktion av källkodsmetadata och rekonstruktion av härstamning, genom att tillämpa statisk analys på hela COBOL-, JCL- och copybook-portföljen.

Funktionen för statisk kodanalys analyserar varje FD-post, COPY-medlem, SELECT-klausul och 88-nivådefinition i COBOL-portföljen, vilket producerar den tekniska metadatainventeringen på fältnivå: varje fältnamn, datatyp, längd, COMP-specifikation, REDEFINES-medlemskap och villkorsnamn på 88-nivå i varje program och kopiebok i miljön. För en portfölj med tusentals COBOL-program producerar denna extrahering på några timmar den tekniska metadatainventering som manuell dokumentation skulle kräva år att producera, om den överhuvudtaget kunde produceras fullständigt.

Mappningen av applikationsberoenden bygger den operativa härkomstkartan: varje relation mellan program och dataset (vilka program producerar vilka dataset och vilka konsumerar dem), varje beroende mellan program och program (vilka program anropar vilka andra och vilken data flödar mellan dem) och varje relation mellan JCL och program (vilka jobbsteg anropar vilka program i vilken sekvens). Denna härkomstkarta är det operativa metadatalagret som sluter klyftan mellan äldre källsystem och den moderna datakatalogens härkomstposter.

JCL -expansionsfunktionen spårar hela exekveringskedjan för varje JCL-jobb: lösning av PROC-referenser, expansion av symboliska parametrar och byggande av fullständiga operativa metadata för varje datamängds produktion och förbrukning, schemaläggningskontexten, de beroende jobben och exekveringssekvensen som avgör aktualitets- och aktualitetsegenskaperna för varje datamängd.

Företagssökningsfunktionen gör det extraherade metadataregistret sökbart i hela metadatahanteringsprogrammet: hitta alla fält definierade som COMP-3 (precisionskänsliga fält som kräver noggrann målmappning), alla program som läser ett specifikt fält (identifierar alla konsumenter av en specifik dataenhet för härkomst- och semantisk berikning), varje villkorsnamn på 88 nivåer som matchar en specifik affärsterm (mappar affärsvokabulär till tekniska fältdefinitioner). Denna sökfunktion stöder den semantiska berikningsprocessen, vilket gör det möjligt för domänexperter att hitta alla användningsområden för ett specifikt fält eller värde innan de bekräftar dess affärsmässiga betydelse.

För organisationer som bedriver äldre modernisering program, SMART TS XLs metadatautvinning tillhandahåller grunden före migrering: de tekniska metadata på fältnivå som migreringsverktyg behöver för att mappa källfält till målscheman, den operativa linje som migreringsprogram behöver för att sekvensera datamängder korrekt och den semantiska vokabulären på 88 nivåer som möjliggör korrekt mappning från COBOL-kodvärden till relationella begränsningsdefinitioner.

Det brådskande med metadataåterställning innan kunskapen går i pension

Problemet med metadatarekonstruktion har en naturlig deadline som inte gäller för de flesta utmaningar med datastyrning: pensioneringen av utvecklare som innehar den institutionella kunskap som kodanalys inte kan återställa. Nästan en tredjedel av COBOL-programmerarna kommer att gå i pension år 2030. Den genomsnittliga åldern för stordatortekniker är 58.7 år. Varje år som går utan systematisk metadataextraktion och semantisk anrikning begränsar fönstret inom vilket mänsklig validering av återställda metadata är möjlig.

Tekniska metadata, fältdefinitioner, typspecifikationer, programberoenden och datahärkomst kan återställas från källkoden på obestämd tid, så länge källkoden existerar. Semantiska metadata, vad varje fält betyder i affärstermer, vilka historiska beslut som ligger bakom fältdesignen, och vilka underförstådda konventioner som de tekniska specifikationerna inte dokumenterar, kan endast återställas från de personer som känner till dem, och endast så länge de är tillgängliga.

Ett metadatahanteringsprogram för system som sträcker sig över flera decennier, vilket börjar med teknisk extraktion och fortsätter till semantisk anrikning medan domänexpertis fortfarande finns tillgänglig, producerar en komplett, återställningsbar metadatagrund. Samma program som skjuts upp till efter att kunskapen försvinner, producerar en teknisk metadatagrund som är korrekt men ofullständig, korrekt vad gäller datastrukturen, tyst om dess betydelse.

Metadata är kartan. Flerdecenniers system begravde den.

Datastyrning för moderna system börjar med metadata som är aktuell, tillgänglig och åtminstone delvis dokumenterad. Datastyrning för system som spridit sig över flera decennier börjar med metadata som är distribuerade över tusentals källkodsfiler, delvis dokumenterade i specifikationer som föregår internet och delvis lagrade i minnet hos utvecklare som närmar sig pensionering.

Vägen från nedgrävd till styrd går genom extraktion, rekonstruktion och anrikning, i den ordningen. Tekniska metadata extraherade från källkoden utgör startinventeringen. Operativ härkomst rekonstruerad från programberoenden utgör provenienskartan. Semantisk anrikning validerad av domänexpertis ger den affärsmässiga innebörd som gör de tekniska metadatana användbara för analys, AI och styrning.

Moderna datakatalogplattformar är destinationen för dessa metadata, inte utgångspunkten. Innan Collibra kan styra dem och Alation kan katalogisera dem och dataforskare kan lita på dem, måste de metadata som system som täcker flera decennier först hittas i FD-posterna, i kopieböckerna, i villkorsnamnen på 88 nivåer och i de affärsregler som kodats i fyrtio år av PROCEDURE DIVISION-logik.

Kartan finns. Den behöver bara läsas.