フィールド TRANS-AMT-CD COBOLプログラムでは、1981年から運用されています。FDエントリでは、次のように定義されています。 PIC S9(9)V99 COMP-311 桁のパック 10 進符号付き数値フィールドで、2 桁の暗黙の小数点以下。これが技術的なメタデータです。ビジネス メタデータ、つまり TRANS-AMT-CD が実際に何を意味するのか、どの通貨で表記されているのか、2 桁の暗黙の小数点以下がセントを意味するのかベーシス ポイントを意味するのか、負の値が貸方を表すのか借方を表すのか、ゼロ値をどのように解釈すべきかといった情報は、コード ベースのどこにも存在しません。それは 1981 年に印刷され、ファイル キャビネットに保管され、それ以来誰も見ていない機能仕様書に存在していました。TRANS-AMT-CD の意味を最初に知っていた 2 人の開発者は、どちらも 2014 年に退職しました。
これは、数十年にわたるデータシステムを持つすべての組織が直面するメタデータの状況であり、現代のデータガバナンスフレームワークが対処するように設計されていないメタデータの状況でもあります。Collibra、Alation、Atlan、およびその他のすべてのエンタープライズデータカタログプラットフォームは、既に記述されているデータ、ドキュメント化されたスキーマを持つクラウドデータベース、列のセマンティクスが定義されたデータウェアハウス、OpenAPI仕様を持つAPIエンドポイントのメタデータを管理することに優れています。しかし、これらのプラットフォームは、正式に取得されたことがなく、メタデータ管理が確立される以前に作成されたプログラムの動作にのみ存在し、40年以上にわたって数十人の開発者によって変更されてきたメタデータを再構築するようには設計されていません。各フィールドの意味に関する中央記録は誰も更新されていません。
数十年にわたるデータシステムのメタデータ管理は、現代のシステムのメタデータ管理とは異なる問題です。根本的に異なるアプローチが必要であり、接続されたシステムからメタデータを取り込むのではなく、ソースアーティファクトからメタデータを抽出することから始める必要があります。
レガシーメタデータの3つの層
数十年にわたるシステムにおけるメタデータの問題を理解するには、これらの環境におけるメタデータが3つの異なる層に存在し、それぞれ抽出可能性、完全性、ガバナンス上の影響が異なることを認識する必要がある。
テクニカルメタデータは、最も抽出しやすいレイヤーです。これは、フィールド名、データ型、長さ、レコード内の位置、数値精度指定、レコードレイアウト内のフィールド間の関係など、データの物理構造を記述します。COBOL環境では、テクニカルメタデータはソースコードアーティファクトに存在します。FDエントリはレコードレイアウトを定義し、COPYメンバーは再利用可能なデータ構造を定義し、SELECT句はファイル編成とアクセス方法を定義し、JCL DDステートメントは各プログラム実行に関連付けられたデータセットを定義します。このレイヤーは原則として機械可読であり、COBOL構文を理解するパーサーはソースコードから抽出できますが、スキーマレジストリに一元化されるのではなく、数千のソースファイルに分散されています。
運用メタデータは、データがシステム内をどのように移動するか、つまり、どのプログラムがどのデータセットを生成し、どのプログラムがそれらを消費し、どのような順序で、どのような変換を経て処理されるかを記述します。メインフレーム環境では、運用メタデータは、JCLジョブストリーム（実行順序とデータセットの関連付けを定義）、プログラム呼び出しグラフ（プログラム間のデータフローを定義）、およびスケジューラ構成（タイミングと依存関係を定義）に分散されています。このレイヤーはソースアーティファクトから機械的に抽出することも可能ですが、抽出には個々のプログラムだけでなく、プログラム間の関係性も理解する必要があります。
ビジネスメタデータまたはセマンティックメタデータ は、最も抽出されにくく、最も価値のあるレイヤーです。技術的なメタデータでは答えられない質問に答えます。 TRANS-AMT-CD ビジネス用語では実際には何を意味するのでしょうか？有効な値は何ですか？ ACCT-TYPE-CD それぞれの値は何を意味するのか？どのビジネスルールがそれを決定するのか？ CUST-STATUS-FLG からの移行 A 〜へ Iこの層は、存在する場合、仕様書、開発者の記憶、退職した従業員が保持する組織的知識、およびデータベース制約ではなくIF文とEVALUATEブロックを通じてビジネスルールを適用するプログラムの手続きロジックに存在します。
数十年にわたるシステムにおけるメタデータの課題は、これら3つのレイヤーが、システムの進化の過程でそれぞれ異なる方法で管理されてきたか、あるいは全く管理されてこなかったことにある。技術メタデータはソースコードに記録されていたものの、データ辞書として正式に文書化されることはなかった。運用メタデータはJCLジョブストリームに暗黙的に含まれていたものの、系統記録として文書化されることはなかった。ビジネスメタデータは初期開発時の仕様書に記載されていたものの、システムの進化に伴って更新されることはなかった。
メタデータのずれの問題
数十年にわたって運用されているシステムが体系的なメタデータ管理を行わない場合、公式文書に存在するメタデータと、システムの実際の現在の動作を反映したメタデータとの間のギャップは年々拡大していく。この乖離は、次の4つのメカニズムによって発生する。
分野の意味の進化。 1978年に一つのビジネス上の意味で定義された分野が、その後数十年の間に新たな意味を蓄積していく可能性がある。 ACCT-TYPE-CD 当初は当座預金口座と普通預金口座を区別するために用いられていた可能性がある。40年以上にわたり、マネーマーケット口座、譲渡性預金証書、IRA口座、エスクロー口座を表すコードが追加された可能性があるが、それぞれの追加は、新しいコード値を処理するプログラムコードにのみ記録され、中央フィールド定義には記録されていない。フィールド名と型は変更されていないが、その意味は大幅に複雑化している。
静かな用途転換。 フィールドは、名前を変更せずに別の用途に転用されることがあります。ある用途で使用されていたフィールドを拡張するのが不便になった場合、開発者は隣接するフラグフィールドの未使用値を使用して、別の情報をエンコードすることがあります。 TRANS-FLAG-1 現在では、異なるプログラムコンテキストにおいて、3つの異なる概念がエンコードされている可能性があり、どのプログラムがどのような条件下でそのフィールドを読み込んでいるかを調べることによってのみ区別できます。技術的なメタデータ（フィールド名、型、長さ）からは、そのフィールドが意味的に過負荷状態にあることを示す情報は一切得られません。
REDEFINES の蓄積について。VSAM分析の文脈で説明したように、REDEFINES 句は同じ物理ストレージに異なるフィールド解釈を適用します。各 REDEFINES バリアントは、システムの履歴の異なる時点で、異なる開発者によって、異なる業務目的で追加された可能性があります。REDEFINES 階層の完全な意味、どのバリアントがいつ適用されるか、各バリアントのフィールドが何を意味するかは、各バリアントにアクセスするすべてのプログラムと、それらがアクセスする条件を分析することによってのみ再構築できます。
コピーブックの差異。標準の COBOL コピーブックが新しい要件に対応するために変更された場合、そのコピーブックをインクルードしていて、新しいフィールドを処理するように更新されていないプログラムは、正しく動作しないか、新しいフィールドを無視する可能性があります。数十年にわたる進化の中で、名目上は同じコピーブックの複数のバージョンが異なるライブラリに存在し、異なるプログラムが異なるバージョンを使用している場合があります。コピーブックで定義されているフィールドのメタデータは、各プログラムがインクルードするコピーブックのバージョンによって、プログラム間で異なる場合があります。
最新のメタデータツールではレガシーデータに対してできないこと
エンタープライズデータカタログ市場は著しく成熟しました。Collibra、Alation、Atlan、Microsoft Purview、Informatica Axonは、最新のデータ環境全体でメタデータを管理するための高度なプラットフォームです。これらのプラットフォームは、接続されたデータベースからのスキーマの自動検出、ETLパイプライン全体にわたる列レベルのデータリネージの追跡、厳選された用語定義によるビジネス用語集の維持、メタデータレコードと併せてデータ品質指標を表示することなどに優れています。
これらのツールが数十年にわたるCOBOLシステムやメインフレームシステムに対してできないこと：
カタログは、見えないものには接続できません。最新のカタログは、コネクタ、データベースへのJDBC接続、クラウドサービスとのAPI統合、サポート対象プラットフォームとのスキャナ統合などを通じてメタデータを検出します。VSAMファイル、COBOLプログラム、JCLジョブストリームには、標準のカタログコネクタがありません。カタログは、アクセス手段がないものは検出できません。これらのシステムで管理されるデータは、カタログから事実上見えないため、このデータから派生する下流のクラウド分析用のデータ系列レコードは不完全または欠落しています。
コード内にのみ存在するメタデータを抽出することはできません。DB2データベースに接続されたデータカタログは、データベーススキーマ、テーブル定義、列名、データ型、索引を読み取ることができます。しかし、DB2テーブルにデータを格納するCOBOLプログラムを読み取って、データ格納を制御するビジネスルール、ソースレコードに存在するREDEFINESバリアント、各フィールドの意味的妥当性を定義する88レベルの条件名などを理解することはできません。レガシーデータのビジネス上の意味が実際に存在するコードレベルのメタデータは、カタログのスキャンではなく、コード分析によって取得する必要があります。
記録されていない意味を再構築することはできません。たとえ完璧な技術的メタデータ抽出を行ったとしても、正式に文書化されていないフィールドのビジネス上の意味を自動的に再構築することは不可能です。この層では、コード分析（プログラムがデータに適用するビジネスルールを明らかにするため。これはビジネス上の意味の代理指標となる）と人間によるレビュー（再構築された意味を、その知識がまだ存在するうちに組織の知識と照らし合わせて検証するため）を組み合わせる必要があります。
メタデータ再構築アプローチ
数十年にわたって運用されてきたシステムで、正式なメタデータが一度も取得されていない、あるいは現状から大きく乖離している場合、メタデータ管理にはガバナンス段階の前に再構築段階が必要となります。再構築アプローチでは、復元可能なレイヤーを抽出し、人間の知識が必要となるギャップを特定します。
フェーズ1：ソースアーティファクトからの技術メタデータの抽出。
COBOLのすべてのFDエントリ、COPYメンバー、SELECT句、およびJCLのDDステートメントを解析して、フィールドレベルの技術メタデータインベントリを作成します。
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).この単一のFDエントリから、技術的なメタデータ抽出により、フィールド名、データ型、長さ、位置、パックされた10進精度が生成されます。 TRANS-AMT-CD （9桁、小数点以下2桁、符号付き）の4つの意味値 TRANS-TYPE-CD 88レベルの条件名によって定義され、レコードの10～105バイト目の重複する2つの解釈を作成するREDEFINES構造によって定義されます。
88段階の病名分類は、メタデータとして特に価値があります。 TRANS-PAYMENT, TRANS-REFUND, TRANS-ADJUSTMENT, TRANS-REVERSAL COBOLコード自体が提供するビジネス用語の4つの項目は、基礎となるものよりも意味深い。 PM, RF, AJ, RV データベースをスキャンするデータカタログが見るであろう値。
フェーズ2：プログラムの依存関係から運用メタデータを抽出する。
プログラム依存関係グラフを通してデータフローを追跡することで、運用系統図を作成します。
- どのプログラムが書き込みを行うか
TRANSACTION-FILE（プロデューサー） - どのプログラムが読み取るか
TRANSACTION-FILE(消費者) - どのJCLジョブステップが、どの順序で各プロデューサーとコンシューマーを呼び出すか
- 下流のデータセットとデータベースは、変換されたデータを受け取ります。
TRANSACTION-FILE
この系統図は、データカタログツールが系統図の可視化に必要な運用メタデータですが、ソースプログラムコードとJCLにアクセスできないと構築できません。
フェーズ3：セマンティックメタデータプロキシとしてのビジネスルールの抽出。
COBOL PROCEDURE DIVISION ロジックにエンコードされたビジネスルールは、ビジネスの意味のプロキシです。 TRANS-AMT-CD 処理前に特定の範囲内に収まるようにすることは、フィールドの有効範囲に関する証拠を提供することです。 TRANS-AMT-CD 下流システムに書き込む前に別の単位に変換すると、暗黙の小数点または単位の規則が明らかになります。
コード解析によってこれらのビジネスルールを抽出すると、推論された意味メタデータのセットが生成されます。これには、各フィールドに適用される検証範囲、ソースとターゲット間で行われる変換、および異なるコードパスが実行される条件が含まれます。この推論された意味メタデータは不正確であり、プログラムがデータに対して何を行うかを示すもので、必ずしもデータが意図した意味を示すものではありませんが、元の仕様書では不可能な方法でコードから復元できます。
フェーズ4：人間による検証と意味的拡張。
抽出された技術的および運用上のメタデータと推論された意味メタデータは、ドメインエキスパートや退職する開発者との人間による検証セッションの基礎となります。目標は、推論された意味を確定された意味に変換し、 TRANS-AMT-CD これは、コードが示唆する意味を意味し、コードの動作が意図されたビジネス上の意味を反映しなくなったケースを特定し、コード分析では回復できない現場の履歴に関する組織的な知識を捉えることを意味します。
この段階は、専門知識の入手可能性によって時間的に制約される。年を追うごとに、その知識を持つ人々とともに、より多くの知識が失われていく。
現代システム境界におけるレガシーメタデータのギャップ
数十年にわたって運用されてきたシステムによって生じたメタデータの不足は、レガシー環境内に留まることはありません。それは下流へと伝播し、レガシーシステムからデータを取り込むすべての分析システム、データウェアハウス、機械学習パイプラインが、メタデータのギャップを継承することになります。
COBOLバッチプログラムから毎晩フラットファイル抽出を受け取るクラウドデータウェアハウスの列定義には、データエンジニアリングチームがETLパイプラインを構築したときに列に付けた名前がそのまま反映されます。元のフィールドが TRANS-AMT-CD ETL開発者はターゲット列に名前を付けました transaction_amountデータウェアハウスには、列名、データ型、ビジネスの説明など、カタログに追加された完全なメタデータがあるように見えます。カタログに記録されていないのは、 transaction_amount から発展する TRANS-AMT-CD in TRANSACTION-FILEこれは、COBOL プログラムによって生成され、 TRNSRC01これはJCLジョブで実行されます TRANSDAY 毎晩午前2時に実行され、1987年にハードコーディングされた特定の通貨換算が適用されますが、その換算は、現在も有効かどうか不明な為替レートの慣習に基づいています。
下流のメタデータレコードは完全なようです。履歴はレガシー境界で途切れています。 transaction_amount その価値の実際の起源に関する記述が欠落している。
ガートナーの調査結果によると、AI対応データに裏付けられていないAIプロジェクトの60%は2026年までに放棄されるとのことだが、これは部分的にメタデータに関する記述である。 transaction_amount データが暗黙の小数点を持つパック10進数COBOLフィールドから生成され、1987年の為替レート規則に基づいて換算された可能性のある通貨で表示されていることを知らずに、出所が不透明なデータでトレーニングを行っている。モデルやそのデータパイプラインがアクセスできるカタログには、この状況を伝えるメタデータが存在しないため、モデルはこの状況を疑ったり、調整したりすることができない。
レガシーシステム向けメタデータ管理プログラムの構築
数十年にわたるデータシステム向けのメタデータ管理プログラムは、標準的なエンタープライズデータカタログの実装とは異なる4つの構成要素を持つ。
コンポーネント 1: ソースコード メタデータの抽出。カタログ ツールがレガシー メタデータを管理する前に、メタデータはソース アーティファクトから抽出する必要があります。この抽出では、FD エントリとコピー ブック (データ構造の技術メタデータ)、SELECT 句 (ファイル構成とアクセス方法)、JCL DD ステートメント (データセットの関連付けとファイル特性)、および 88 レベルの条件名 (ソース コードに埋め込まれた意味値語彙) を対象とする必要があります。出力はフィールド レベルのメタデータ インベントリであり、これをカタログにロードしてビジネス エンリッチメントの出発点とすることができます。
コンポーネント2：データリネージの再構築。レガシーシステムのデータリネージは、ETLツールのリネージ追跡ではなく、プログラム依存関係分析に基づいて再構築する必要があります。リネージマップは、データの発信元となるCOBOLプログラムから、中間変換プログラムを経て、最終的なデータ利用者（最新の分析システムにデータを提供するETLプロセスを含む）までを追跡します。この再構築により、レガシー境界におけるリネージのギャップが解消され、文書化されたプログラム依存関係の連鎖を通じて、クラウドデータウェアハウスの列メタデータとCOBOL FDエントリメタデータが接続されます。
コンポーネント3：ドメイン専門知識による意味的強化。 抽出された技術メタデータは構造を提供しますが、確認されたビジネス上の意味にはドメインの専門知識が必要です。エンリッチメントプロセスでは、技術メタデータを専門家へのインタビューのための構造化されたプロンプトとして使用します。「このフィールドは次のように定義されます」 PIC S9(9)V99 COMP-3、14のプログラムで非負であることが検証されており、下流のデータベースに書き込む前に別のスケールに変換されますが、それが何を表しているのか、また変換が何を意味するのか確認していただけますか？この構造化されたアプローチでは、コード分析を使用して各専門家とのやり取りの情報価値を最大化し、非構造化されたドキュメントのレビューよりも迅速かつ完全な情報拡充を可能にします。
コンポーネント4：最新のカタログプラットフォームとのガバナンス統合。レガシーメタデータが抽出、再構築、および強化されたら、最新のメタデータガバナンスインフラストラクチャと統合する必要があります。この統合により、レガシーメタデータインベントリがエンタープライズデータカタログに接続され、COBOLソースからクラウドターゲットまでの列レベルのリネージ、レガシーフィールド定義にリンクされたビジネス用語集、および最新のシステムメタデータと同じガバナンスフレームワークにデータを格納するレガシーデータセットのデータ品質メタデータが提供されます。
認定条件 SMART TS XL レガシーメタデータの抽出
SMART TS XL 従来のメタデータ管理プログラムの最初の2つの構成要素である、ソースコードメタデータの抽出と系統再構築に対応するため、COBOL、JCL、およびコピーブックの全ポートフォリオに静的解析を適用します。
静的コード解析機能は、COBOLポートフォリオ全体にわたるすべてのFDエントリ、COPYメンバー、SELECT句、および88レベル定義を解析し、フィールドレベルの技術メタデータインベントリを生成します。これには、環境内のすべてのプログラムとコピーブックにわたる、すべてのフィールド名、データ型、長さ、COMP仕様、REDEFINESメンバーシップ、および88レベル条件名が含まれます。数千ものCOBOLプログラムからなるポートフォリオの場合、この抽出機能により、手作業によるドキュメント作成では何年もかかる（あるいはそもそも完全に作成できない）技術メタデータインベントリを、わずか数時間で生成できます。
アプリケーション依存関係マッピングは、運用リネージマップを構築します。これには、すべてのプログラムとデータセットの関係（どのプログラムがどのデータセットを生成し、どのプログラムがそれらを消費するか）、すべてのプログラム間の依存関係（どのプログラムが他のどのプログラムを呼び出し、それらの間でどのようなデータが流れるか）、およびすべてのJCLとプログラムの関係（どのジョブステップがどのプログラムをどの順序で呼び出すか）が含まれます。このリネージマップは、従来のソースシステムと最新のデータカタログのリネージレコード間のギャップを埋める運用メタデータレイヤーです。
JCL拡張機能は、すべてのJCLジョブの完全な実行チェーンを追跡します。具体的には、PROC参照の解決、シンボリックパラメータの展開、各データセットの生成と消費、スケジューリングコンテキスト、依存ジョブ、および各データセットの適時性と鮮度特性を決定する実行シーケンスに関する完全な運用メタデータの構築を行います。
エンタープライズ検索機能により、抽出されたメタデータインベントリをメタデータ管理プログラム全体でクエリできるようになります。COMP-3として定義されているすべてのフィールド（精度が重視され、慎重なターゲットマッピングが必要なフィールド）、特定のフィールドを読み取るすべてのプログラム（データ系列と意味的エンリッチメントのために特定のデータのすべての利用者を特定）、特定のビジネス用語に一致する88レベルの条件名（ビジネス語彙を技術的なフィールド定義にマッピング）を検索できます。この検索機能は意味的エンリッチメントプロセスをサポートし、ドメインエキスパートが特定のフィールドまたは値のすべての使用例を、そのビジネス上の意味を確認する前に検索できるようにします。
組織が実施する場合 レガシーの近代化 プログラム、 SMART TS XLのメタデータ抽出は、移行前の基盤を提供します。移行ツールがソースフィールドをターゲットスキーマにマッピングするために必要なフィールドレベルの技術メタデータ、移行プログラムがデータセットの移行を正しく順序付けるために必要な運用リネージ、および COBOL コード値から関係制約定義への正確なマッピングを可能にする 88 レベルのセマンティック語彙です。
知識が失われる前にメタデータを復旧することの緊急性
メタデータ再構築の問題には、ほとんどのデータガバナンスの課題には当てはまらない、自然な期限が存在します。それは、コード分析では復元できない組織的な知識を持つ開発者の退職です。COBOLプログラマーの約3分の1は2030年までに退職します。メインフレームエンジニアの平均年齢は58.7歳です。体系的なメタデータ抽出と意味的強化を行わないまま年数が経過するごとに、復元されたメタデータを人間が検証できる期間は狭まります。
技術的なメタデータ、フィールド定義、型仕様、プログラム依存関係、データ系統などは、ソースコードが存在する限り、ソースコードから無期限に復元可能です。一方、意味的なメタデータ、つまり各フィールドがビジネス用語で何を意味するのか、フィールド設計の背後にある歴史的な決定事項、技術仕様書には記載されていない暗黙の慣習などは、それを知っている人からのみ、しかもその人が利用可能な間だけ復元可能です。
数十年にわたるシステムを対象としたメタデータ管理プログラムにおいて、ドメイン専門知識がまだ利用可能な段階で技術的な抽出から意味的な拡張へと進む場合、完全で復元可能なメタデータ基盤が構築される。一方、同じプログラムを知識の枯渇後に実施した場合、データの構造については正しくても、その意味については何も示さない、不完全ではあるものの正確な技術的メタデータ基盤が構築される。
メタデータは地図だ。数十年にわたるシステムがそれを埋もれさせてしまった。
現代のシステムにおけるデータガバナンスは、最新かつアクセス可能で、少なくとも部分的に文書化されたメタデータから始まります。一方、数十年にわたるシステムにおけるデータガバナンスは、数千ものソースコードファイルに分散し、インターネット以前の仕様書に部分的に文書化され、定年退職間近の開発者の記憶に部分的にしか残されていないメタデータから始まります。
埋もれた情報から管理可能な情報へと至る道筋は、抽出、再構築、そして拡充という順序で進みます。ソースコードから抽出された技術メタデータは、初期インベントリを提供します。プログラムの依存関係から再構築された運用履歴は、来歴マップを提供します。ドメイン専門知識によって検証された意味的拡充は、技術メタデータを分析、AI、ガバナンスに活用できるビジネス上の意味を与えます。
最新のデータカタログプラットフォームは、このメタデータの出発点ではなく、最終的な保存先です。Collibraがメタデータを管理し、Alationがカタログ化し、データサイエンティストがそれを信頼できるようになるには、数十年にわたるシステムに含まれるメタデータを、まずFDエントリ、コピーブック、88レベルの条件名、そして40年分のPROCEDURE DIVISIONロジックにエンコードされたビジネスルールの中から見つけ出す必要があります。
地図は存在する。あとはそれを読み取るだけだ。
