Zarządzanie metadanymi dla systemów danych obejmujących wiele dekad

Pole TRANS-AMT-CD w programie COBOL jest produkowany od 1981 roku. Wpis FD definiuje go jako PIC S9(9)V99 COMP-3, spakowane pole numeryczne ze znakiem, jedenaście cyfr, dwa domniemane miejsca po przecinku. To są metadane techniczne. Metadane biznesowe, czyli co tak naprawdę oznacza TRANS-AMT-CD, w jakiej walucie jest denominowane, czy dwa domniemane miejsca po przecinku oznaczają centy, czy punkty bazowe, czy wartość ujemna oznacza kredyt, czy debet, i jak należy interpretować wartość zerową, nie istnieją nigdzie w bazie kodu. Istniały w dokumencie specyfikacji funkcjonalnej, który został wydrukowany w 1981 roku, zarchiwizowany w szafie na dokumenty i od tamtej pory nie był widziany. Dwóch programistów, którzy pierwotnie wiedzieli, co oznacza TRANS-AMT-CD, przeszło na emeryturę w 2014 roku.

Z taką sytuacją metadanych mierzy się każda organizacja z systemami danych działającymi przez wiele dekad, a nowoczesne ramy zarządzania danymi nie zostały zaprojektowane do jej rozwiązania. Collibra, Alation, Atlan i każda inna platforma katalogów danych przedsiębiorstw doskonale radzą sobie z zarządzaniem metadanymi, które są już opisane – bazami danych w chmurze z udokumentowanymi schematami, magazynami danych ze zdefiniowaną semantyką kolumn, punktami końcowymi API ze specyfikacjami OpenAPI. Nie zostały one zaprojektowane do rekonstrukcji metadanych, które nigdy nie zostały formalnie zarejestrowane, istnieją jedynie w działaniu programów napisanych przed upowszechnieniem się zarządzania metadanymi, i które zostały zmodyfikowane przez dziesiątki programistów przez cztery dekady bez aktualizacji centralnego zapisu znaczenia każdego pola.

Zarządzanie metadanymi w systemach danych obejmujących wiele dekad nie stanowi tego samego problemu, co zarządzanie metadanymi w systemach współczesnych. Wymaga ono zasadniczo innego podejścia, które zaczyna się od ekstrakcji metadanych z artefaktów źródłowych, a nie od pobierania metadanych z systemów połączonych.

Trzy warstwy starszych metadanych

Aby zrozumieć problem metadanych w systemach obejmujących wiele dekad, należy uznać, że metadane w tych środowiskach istnieją w trzech odrębnych warstwach, z których każda charakteryzuje się inną możliwością ekstrakcji, innym poziomem kompletności i innymi implikacjami w zakresie zarządzania.

Metadane techniczne to warstwa o największej możliwości ekstrakcji. Opisują one fizyczną strukturę danych: nazwy pól, typy danych, długości, pozycje w rekordach, specyfikacje precyzji numerycznej oraz relacje między polami w układzie rekordu. W środowiskach COBOL metadane techniczne występują w artefaktach kodu źródłowego: wpisy FD definiują układy rekordów, elementy COPY definiują struktury danych wielokrotnego użytku, klauzule SELECT definiują organizację plików i metody dostępu, a instrukcje JCL DD definiują zestawy danych powiązane z każdym uruchomieniem programu. Ta warstwa jest zasadniczo czytelna dla maszyn – parser rozumiejący składnię języka COBOL może ją wyodrębnić z kodu źródłowego, ale jest ona rozproszona w tysiącach plików źródłowych, a nie scentralizowana w rejestrze schematów.

Metadane operacyjne opisują sposób przepływu danych w systemie: które programy generują jakie zbiory danych, które programy je wykorzystują, w jakiej kolejności i poprzez jakie transformacje. W środowiskach mainframe metadane operacyjne są rozproszone w strumieniach zadań JCL (które definiują sekwencje wykonywania i powiązania zbiorów danych), grafach wywołań programów (które definiują przepływ danych między programami) oraz konfiguracji harmonogramu (która definiuje czas i zależności). Tę warstwę można również wyodrębnić z artefaktów źródłowych na poziomie maszyny, choć ekstrakcja wymaga zrozumienia nie tylko poszczególnych programów, ale także relacji między nimi.

Metadane biznesowe lub semantyczne Jest najmniej ekstrahowalną i najbardziej wartościową warstwą. Odpowiada na pytania, na które nie mogą odpowiedzieć metadane techniczne: co TRANS-AMT-CD Co to właściwie znaczy w kategoriach biznesowych? Jakie są prawidłowe wartości dla ACCT-TYPE-CD I co oznacza każda wartość? Jaka reguła biznesowa określa, kiedy CUST-STATUS-FLG przejścia z A do ITa warstwa istnieje, o ile w ogóle istnieje, w dokumentach specyfikacji, w pamięci programistów, w wiedzy instytucjonalnej posiadanej przez pracowników, którzy mogli przejść na emeryturę, oraz w logice proceduralnej programów, które wymuszają reguły biznesowe za pomocą instrukcji IF i bloków EVALUATE, a nie za pomocą ograniczeń bazy danych.

Wyzwaniem dla metadanych w systemach wielodekadowych jest to, że te trzy warstwy były zarządzane w różny sposób lub wcale przez dekady ewolucji systemu. Metadane techniczne były zapisywane w kodzie źródłowym, ale nigdy nie zostały sformalizowane w słowniku danych. Metadane operacyjne były domyślnie zawarte w strumieniach zadań JCL, ale nigdy nie były dokumentowane jako zapis pochodzenia. Metadane biznesowe były udokumentowane w specyfikacjach w momencie początkowego rozwoju i nigdy nie były aktualizowane w miarę rozwoju systemów.

Problem dryfu metadanych

Z każdym rokiem, gdy system działający przez wiele dekad funkcjonuje bez systematycznego zarządzania metadanymi, luka między metadanymi zawartymi w formalnej dokumentacji a metadanymi odzwierciedlającymi rzeczywiste, bieżące zachowanie systemu pogłębia się. Ten dryf następuje poprzez cztery mechanizmy:

Pole oznaczające ewolucję. Dziedzina, której w 1978 r. przypisano jedno znaczenie biznesowe, mogła nabrać dodatkowych znaczeń w kolejnych dekadach. ACCT-TYPE-CD pierwotnie rozróżniano rachunki bieżące od oszczędnościowych. Przez czterdzieści lat mogły zostać dodane dodatkowe kody reprezentujące rachunki rynku pieniężnego, certyfikaty depozytowe, rachunki IRA i rachunki powiernicze, a każdy taki dodatek został udokumentowany wyłącznie w kodzie programu obsługującym nową wartość kodu, a nie w definicji pola centralnego. Nazwa i typ pola pozostały niezmienione; jego znaczenie semantyczne stało się znacznie bardziej złożone.

Ciche ponowne wykorzystanie. Pola są czasami zmieniane bez zmiany nazwy. Pole, które było używane do jednego celu, staje się niewygodne w rozszerzaniu, a programista wykorzystuje wcześniej nieużywaną wartość sąsiedniego pola flagi do zakodowania innej informacji. TRANS-FLAG-1 może teraz kodować trzy różne koncepcje w różnych kontekstach programów, możliwe do rozróżnienia jedynie poprzez analizę, które programy odczytują dane pole i w jakich warunkach. Metadane techniczne, takie jak nazwa pola, typ i długość, nie wskazują na przeciążenie semantyczne pola.

Akumulacja REDEFINES. Jak omówiono w kontekstach analizy VSAM, klauzule REDEFINES nakładają się na tę samą pamięć fizyczną z różnymi interpretacjami pól. Każdy wariant REDEFINES mógł zostać dodany w innym momencie historii systemu, przez różnych programistów, do różnych celów biznesowych. Pełne znaczenie semantyczne hierarchii REDEFINES, czyli określenie, który wariant ma zastosowanie, kiedy i co oznaczają pola każdego wariantu, można zrekonstruować jedynie poprzez analizę wszystkich programów uzyskujących dostęp do każdego wariantu oraz warunków, w jakich to robią.

Rozbieżność w kopiach. Gdy standardowy kopiarz COBOL zostanie zmodyfikowany w celu dostosowania do nowego wymagania, programy, które zawierały ten kopiarz i nie zostały zaktualizowane w celu obsługi nowego pola, mogą zachowywać się nieprawidłowo lub po prostu ignorować nowe pole. W ciągu dziesięcioleci ewolucji, w różnych bibliotekach mogły istnieć różne wersje tego samego kopiarza, a różne programy mogły korzystać z różnych wersji. Metadane dla pola zdefiniowanego w kopiarzu mogą się różnić w zależności od programu, w zależności od wersji kopiarza zawartej w danym programie.

Czego nowoczesne narzędzia do metadanych nie potrafią zrobić w przypadku starszych danych

Rynek katalogów danych przedsiębiorstw znacząco dojrzał. Collibra, Alation, Atlan, Microsoft Purview i Informatica Axon to zaawansowane platformy do zarządzania metadanymi w nowoczesnych środowiskach danych. Doskonale sprawdzają się w: automatycznym wykrywaniu schematów z połączonych baz danych, śledzeniu pochodzenia danych na poziomie kolumn w procesach ETL, utrzymywaniu słowników biznesowych z opracowanymi definicjami terminów oraz prezentowaniu metryk jakości danych obok rekordów metadanych.

Czego te narzędzia nie potrafią zrobić w przypadku systemów COBOL i mainframe działających przez wiele dekad:

Nie mogą połączyć się z tym, czego nie widzą. Nowoczesne katalogi odnajdują metadane za pomocą konektorów, połączeń JDBC z bazami danych, integracji API z usługami w chmurze oraz integracji skanerów z obsługiwanymi platformami. Pliki VSAM, programy COBOL i strumienie zadań JCL nie posiadają standardowych konektorów katalogowych. Katalog nie może odkryć czegoś, do czego nie ma mechanizmu dotarcia. Dane zarządzane przez te systemy są praktycznie niewidoczne dla katalogu, co oznacza, że ​​rekordy pochodzenia dla analiz chmurowych w dół strumienia, które pochodzą z tych danych, są niekompletne lub nieobecne.

Nie mogą wyodrębnić metadanych, które istnieją tylko w kodzie. Katalog danych połączony z bazą danych DB2 może odczytać schemat bazy danych, definicje tabel, nazwy kolumn, typy danych i indeksy. Nie może jednak odczytać programu COBOL, który wypełnia tabelę DB2, aby zrozumieć, jakie reguły biznesowe rządzą wypełnianiem, jakie warianty REDEFINES istnieją w rekordzie źródłowym ani jakie nazwy warunków 88-poziomowych definiują semantyczną poprawność każdego pola. Metadane na poziomie kodu, warstwa, w której faktycznie znajduje się biznesowe znaczenie starszych danych, wymagają analizy kodu, a nie skanowania katalogu.

Nie są w stanie odtworzyć znaczenia, które nigdy nie zostało uchwycone. Nawet przy doskonałej ekstrakcji metadanych technicznych, znaczenia biznesowego pól, które nigdy nie zostały formalnie udokumentowane, nie da się odtworzyć automatycznie. Ta warstwa wymaga połączenia analizy kodu (aby ujawnić reguły biznesowe, które programy stosują do danych, będące odpowiednikami znaczenia biznesowego) i weryfikacji przez człowieka (aby zweryfikować zrekonstruowane znaczenie w odniesieniu do wiedzy instytucjonalnej, póki ta wiedza jeszcze istnieje).

Podejście do rekonstrukcji metadanych

W przypadku systemów działających przez wiele dekad, w których formalne metadane nigdy nie zostały zebrane lub znacznie odbiegają od obecnej rzeczywistości, zarządzanie metadanymi wymaga fazy rekonstrukcji przed fazą zarządzania. Podejście rekonstrukcji polega na wyodrębnieniu warstw odzyskiwalnych i identyfikacji luk, w których wymagana jest wiedza człowieka.

Faza 1: Ekstrakcja metadanych technicznych z artefaktów źródłowych.

Przeanalizuj każdy wpis COBOL FD, element COPY, klauzulę SELECT i polecenie JCL DD, aby utworzyć inwentarz metadanych technicznych na poziomie pola:

kobol

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

Na podstawie tego pojedynczego wpisu FD ekstrakcja metadanych technicznych generuje: nazwy pól, typy danych, długości, pozycje, spakowaną precyzję dziesiętną TRANS-AMT-CD (9 cyfr, 2 miejsca po przecinku, ze znakiem), cztery wartości semantyczne TRANS-TYPE-CD zgodnie z definicją 88-poziomowych nazw warunków i strukturą REDEFINES, która tworzy dwie nakładające się interpretacje bajtów 10-105 rekordu.

Nazwy stanów 88-poziomowych są szczególnie cenne jako metadane: TRANS-PAYMENT, TRANS-REFUND, TRANS-ADJUSTMENT, TRANS-REVERSAL są to cztery elementy słownictwa biznesowego, które sam kod COBOL zapewnia i które są bardziej znaczące niż podstawowy PM, RF, AJ, RV wartości, które zobaczyłby katalog danych skanujący bazę danych.

Faza 2: Ekstrakcja metadanych operacyjnych z zależności programu.

Zbuduj mapę linii operacyjnej, śledząc przepływy danych przez graf zależności programu:

• Do których programów zapisują TRANSACTION-FILE (producenci)
• Które programy czytają z TRANSACTION-FILE (konsumenci)
• Które kroki pracy JCL wywołują każdego producenta i konsumenta, w jakiej kolejności
• Które zestawy danych i bazy danych downstream otrzymują dane przekształcone z TRANSACTION-FILE

Mapa pochodzenia to operacyjne metadane, których narzędzia katalogu danych potrzebują do wizualizacji pochodzenia, ale nie mogą utworzyć bez dostępu do kodu źródłowego programu i JCL.

Faza 3: Ekstrakcja reguł biznesowych jako substytut metadanych semantycznych.

Reguły biznesowe zakodowane w logice COBOL PROCEDURE DIVISION są odpowiednikami znaczenia biznesowego. Program, który weryfikuje TRANS-AMT-CD Aby upewnić się, że mieści się w określonych zakresach przed przetwarzaniem, dostarcza dowodów na prawidłowy zakres pola. Program, który konwertuje TRANS-AMT-CD do innej jednostki przed zapisaniem jej w systemie niższego rzędu ujawnia domniemaną konwencję dziesiętną lub jednostkową.

Wyodrębnienie tych reguł biznesowych poprzez analizę kodu generuje zestaw wywnioskowanych metadanych semantycznych: zakresy walidacji stosowane do każdego pola, transformacje zachodzące między źródłem a celem oraz warunki wykonywania różnych ścieżek kodu. Te wywnioskowane metadane semantyczne są nieprecyzyjne, pokazują, co programy robią z danymi, niekoniecznie co dane te miały oznaczać, ale można je odzyskać z kodu w sposób, w jaki nie jest to możliwe w oryginalnym dokumencie specyfikacji.

Faza 4: Walidacja przez człowieka i wzbogacanie semantyczne.

Wyekstrahowane metadane techniczne i operacyjne oraz wywnioskowane metadane semantyczne stanowią podstawę sesji walidacyjnych prowadzonych przez ekspertów dziedzinowych i odchodzących na emeryturę programistów. Celem jest przekształcenie wywnioskowanej semantyki w potwierdzoną semantykę, co pozwoli na jej walidację. TRANS-AMT-CD oznacza to, co sugeruje kod, identyfikując przypadki, w których zachowanie kodu nie odzwierciedla już zamierzonego znaczenia biznesowego, i rejestrując wiedzę instytucjonalną na temat historii obszaru, której analiza kodu nie jest w stanie odtworzyć.

Faza ta jest ograniczona czasowo dostępnością wiedzy specjalistycznej w danej dziedzinie: z każdym rokiem większa część tej wiedzy odchodzi na emeryturę wraz z ludźmi, którzy ją posiadają.

Luka w metadanych dziedzictwa na granicy współczesnego systemu

Deficyt metadanych generowany przez systemy działające przez wiele dekad nie ogranicza się do środowiska starszego. Rozprzestrzenia się on w dół: każdy system analityczny, magazyn danych i proces uczenia maszynowego, który pobiera dane ze starszych systemów, dziedziczy lukę w metadanych.

Magazyn danych w chmurze, który otrzymuje conocny ekstrakt z pliku płaskiego z programu wsadowego COBOL, ma w definicjach kolumn nazwy wybrane przez zespół inżynierów danych podczas tworzenia potoku ETL. Jeśli oryginalne pole było… TRANS-AMT-CD a programista ETL nadał nazwę kolumnie docelowej transaction_amountMagazyn danych wydaje się mieć kompletne metadane: nazwę kolumny, typ danych, opis działalności dodane do katalogu. Katalog nie rejestruje jednak tego, że transaction_amount pochodzący z TRANS-AMT-CD in TRANSACTION-FILE, który jest produkowany przez program COBOL o nazwie TRNSRC01, który działa w zadaniu JCL TRANSDAY każdej nocy o 2 w nocy, stosując określoną konwersję waluty, która została ustalona na stałe w 1987 r. na podstawie konwencji kursowej, która może być nadal aktualna, ale nie musi.

Rekord metadanych downstream wygląda na kompletny. Pochodzenie jest przerwane na granicy dziedzictwa. Każde obciążenie analityczne lub AI, które zależy od zrozumienia pochodzenia i znaczenia transaction_amount ma lukę, w której nie jest udokumentowana faktyczna historia pochodzenia tej wartości.

Odkrycie Gartnera, że ​​60% projektów AI, które nie są wspierane przez dane gotowe na AI, zostanie porzuconych do 2026 r., jest częściowo stwierdzeniem opartym na metadanych. Modele AI, które wykorzystują transaction_amount Nie wiedząc, że pochodzi ono z wypełnionego pola dziesiętnego w języku COBOL z domniemanym miejscem po przecinku, wyrażonego w walucie, która mogła zostać przeliczona zgodnie z konwencją kursową z 1987 roku, trenują na danych o niejasnym pochodzeniu. Model nie może wiedzieć, czy powinien nie ufać danym ani dostosować się do tego kontekstu, ponieważ metadane, które by go komunikowały, nie istnieją w żadnym katalogu, do którego model lub jego potok danych ma dostęp.

Tworzenie programu zarządzania metadanymi dla systemów starszych

Program do zarządzania metadanymi dla systemów danych obejmujących wiele dekad składa się z czterech komponentów, które różnią się od standardowych wdrożeń katalogów danych przedsiębiorstwa:

Komponent 1: Ekstrakcja metadanych z kodu źródłowego. Zanim jakiekolwiek narzędzie katalogowe będzie mogło zarządzać starszymi metadanymi, metadane muszą zostać wyodrębnione z artefaktów źródłowych, w których się znajdują. Ekstrakcja ta musi obejmować: wpisy FD i copybooki (techniczne metadane dla struktur danych), klauzule SELECT (organizacja plików i metoda dostępu), instrukcje JCL DD (skojarzenia zbiorów danych i charakterystyka plików) oraz nazwy warunków 88-poziomowych (słownik wartości semantycznych osadzony w kodzie źródłowym). Wynikiem jest inwentaryzacja metadanych na poziomie pól, którą można załadować do katalogu jako punkt wyjścia do wzbogacenia danych biznesowych.

Komponent 2: Rekonstrukcja linii. Linia danych dla starszych systemów musi zostać zrekonstruowana na podstawie analizy zależności programów, a nie śledzenia linii danych narzędzi ETL. Mapa linii danych śledzi dane od źródłowego programu COBOL, poprzez pośrednie programy transformacyjne, aż do ich docelowych odbiorców, w tym procesów ETL, które dostarczają je do nowoczesnych systemów analitycznych. Ta rekonstrukcja niweluje lukę w linii danych na granicy starszego systemu, łącząc metadane kolumn magazynu danych w chmurze z metadanymi wejściowymi COBOL FD poprzez udokumentowany łańcuch zależności programów.

Komponent 3: Wzbogacanie semantyczne przy użyciu wiedzy specjalistycznej z danej dziedziny. Wyekstrahowane metadane techniczne zapewniają strukturę; potwierdzone znaczenie biznesowe wymaga wiedzy specjalistycznej. Proces wzbogacania wykorzystuje metadane techniczne jako ustrukturyzowany punkt odniesienia do wywiadów z ekspertami: „To pole jest definiowane jako PIC S9(9)V99 COMP-3, jest on sprawdzony jako nieujemny w 14 programach i konwertowany na inną skalę przed zapisaniem w bazie danych niższego poziomu. Czy możesz potwierdzić, co on przedstawia i co oznacza konwersja?” To ustrukturyzowane podejście wykorzystuje analizę kodu w celu maksymalizacji wartości informacyjnej każdej interakcji z ekspertem, umożliwiając szybsze i pełniejsze wzbogacenie niż nieustrukturyzowane przeglądy dokumentacji.

Komponent 4: Integracja zarządzania z nowoczesnymi platformami katalogowymi. Po wyodrębnieniu, zrekonstruowaniu i wzbogaceniu starszych metadanych, muszą one zostać zintegrowane z nowoczesną infrastrukturą zarządzania metadanymi. Ta integracja łączy starszy inwentarz metadanych z katalogiem danych przedsiębiorstwa, zapewniając: pochodzenie na poziomie kolumn od źródła COBOL do docelowej chmury, terminy z glosariusza biznesowego powiązane z definicjami pól starszej generacji oraz metadane dotyczące jakości danych dla starszych zestawów danych, które wypełniają te same ramy zarządzania, co nowoczesne metadane systemowe.

W jaki sposób SMART TS XL Ekstrahuje starsze metadane

SMART TS XL zajmuje się dwoma pierwszymi komponentami programu zarządzania starszymi metadanymi, ekstrakcją metadanych z kodu źródłowego i rekonstrukcją pochodzenia, poprzez zastosowanie analizy statycznej do całego portfolio COBOL, JCL i copybook.

Funkcja statycznej analizy kodu analizuje każdy wpis FD, element COPY, klauzulę SELECT i definicję 88-poziomową w całym portfolio COBOL, generując inwentarz technicznych metadanych na poziomie pola: każdą nazwę pola, typ danych, długość, specyfikację COMP, członkostwo REDEFINES i nazwę warunku 88-poziomowego w każdym programie i copybooku w środowisku. W przypadku portfolio tysięcy programów COBOL, ta ekstrakcja generuje w ciągu kilku godzin inwentarz technicznych metadanych, których wygenerowanie w ręcznej dokumentacji zajęłoby lata, gdyby w ogóle można było ją stworzyć w całości.

Mapowanie zależności aplikacji buduje operacyjną mapę pochodzenia: każdą relację program-zestaw danych (które programy generują które zestawy danych i które je wykorzystują), każdą zależność program-program (które programy wywołują które inne i jakie dane między nimi przepływają) oraz każdą relację JCL-program (które kroki zadania wywołują które programy w jakiej kolejności). Ta mapa pochodzenia stanowi operacyjną warstwę metadanych, która wypełnia lukę między starszymi systemami źródłowymi a rekordami pochodzenia współczesnego katalogu danych.

Możliwość rozszerzenia JCL śledzi kompletny łańcuch wykonywania każdego zadania JCL: rozwiązywanie odniesień PROC, rozszerzanie parametrów symbolicznych i tworzenie pełnych metadanych operacyjnych dla produkcji i zużycia każdego zestawu danych, kontekst harmonogramowania, zadania zależne i sekwencję wykonywania, która określa cechy terminowości i świeżości każdego zestawu danych.

Funkcja wyszukiwania w przedsiębiorstwie umożliwia wyszukiwanie w wyodrębnionym zbiorze metadanych w całym programie do zarządzania metadanymi: znajdź każde pole zdefiniowane jako COMP-3 (pola wrażliwe na precyzję, wymagające starannego mapowania docelowego), każdy program odczytujący określone pole (identyfikujący wszystkich odbiorców określonego fragmentu danych w celu wzbogacenia pochodzenia i semantyki), każdą nazwę warunku 88-poziomowego, która pasuje do określonego terminu biznesowego (mapując słownictwo biznesowe na definicje pól technicznych). Ta funkcja wyszukiwania wspiera proces wzbogacania semantycznego, umożliwiając ekspertom dziedzinowym znalezienie wszystkich zastosowań określonego pola lub wartości przed potwierdzeniem ich znaczenia biznesowego.

Dla organizacji prowadzących modernizacja dziedziczna programy SMART TS XLEkstrakcja metadanych zapewnia podstawę przed migracją: techniczne metadane na poziomie pól, których narzędzia migracji potrzebują do mapowania pól źródłowych na schematy docelowe, operacyjne podstawy, których programy migracji potrzebują do prawidłowego sekwencjonowania migracji zestawów danych, a także 88-poziomowy słownik semantyczny, który umożliwia dokładne mapowanie wartości kodu COBOL na definicje ograniczeń relacyjnych.

Pilność odzyskiwania metadanych przed wycofaniem wiedzy

Problem rekonstrukcji metadanych ma naturalny termin, który nie ma zastosowania do większości wyzwań związanych z zarządzaniem danymi: przejście na emeryturę programistów posiadających wiedzę instytucjonalną, której analiza kodu nie jest w stanie odtworzyć. Prawie jedna trzecia programistów COBOL przejdzie na emeryturę do 2030 roku. Średni wiek inżyniera mainframe wynosi 58.7 lat. Każdy rok bez systematycznej ekstrakcji metadanych i wzbogacania semantycznego zawęża okno, w którym możliwa jest walidacja odzyskanych metadanych przez człowieka.

Metadane techniczne, definicje pól, specyfikacje typów, zależności programów i pochodzenie danych można odzyskać z kodu źródłowego w nieskończoność, tak długo, jak kod źródłowy istnieje. Metadane semantyczne, czyli informacje o znaczeniu każdego pola w terminologii biznesowej, o historycznych decyzjach podjętych przy projektowaniu pól, o domniemanych konwencjach, których specyfikacje techniczne nie dokumentują, można odzyskać tylko od osób, które je znają, i tylko tak długo, jak długo są dostępne.

Program zarządzania metadanymi dla systemów obejmujących wiele dekad, który rozpoczyna się od ekstrakcji technicznej, a następnie przechodzi do wzbogacania semantycznego, gdy wiedza specjalistyczna jest nadal dostępna, tworzy kompletną, odzyskiwalną bazę metadanych. Ten sam program, odłożony na czas po wycofaniu wiedzy, tworzy techniczną bazę metadanych, która jest dokładna, ale niekompletna – poprawna co do struktury danych, ale nie precyzuje ich znaczenia.

Metadane to mapa. Ukryły ją systemy wielodekadowe.

Zarządzanie danymi w nowoczesnych systemach zaczyna się od metadanych, które są aktualne, dostępne i przynajmniej częściowo udokumentowane. W systemach działających przez wiele dekad zarządzanie danymi zaczyna się od metadanych rozproszonych w tysiącach plików kodu źródłowego, częściowo udokumentowanych w specyfikacjach sprzed ery internetu, a częściowo przechowywanych w pamięci programistów zbliżających się do emerytury.

Droga od ukrytego do kontrolowanego prowadzi przez ekstrakcję, rekonstrukcję i wzbogacanie – w tej właśnie kolejności. Metadane techniczne wyodrębnione z kodu źródłowego stanowią początkowy inwentarz. Pochodzenie operacyjne zrekonstruowane na podstawie zależności programowych stanowi mapę pochodzenia. Wzbogacanie semantyczne, potwierdzone wiedzą specjalistyczną, zapewnia znaczenie biznesowe, które sprawia, że ​​metadane techniczne są użyteczne w analityce, sztucznej inteligencji i zarządzaniu.

Nowoczesne platformy katalogów danych są miejscem docelowym tych metadanych, a nie punktem wyjścia. Zanim Collibra będzie mogła nimi zarządzać, Alation je skatalogować, a analitycy danych będą mogli im zaufać, metadane zawarte w systemach wielodekadowych muszą najpierw zostać odnalezione we wpisach FD, w kopiach, w 88-poziomowych nazwach warunków oraz w regułach biznesowych zakodowanych w czterdziestoletniej logice PROCEDURE DIVISION.

Mapa istnieje. Trzeba ją tylko przeczytać.