ソースマッピングに関するガイダンス
DEUNA が Athia に、商社とプロバイダーのデータを公開せずに連携させる方法を理解する。
Athia は、商業、決済、金融、リスク、および運用関連のソース間でビジネス概念を連携させる。 特定の環境におけるマッピングは、有効化時に個別に合意される。 このページは、公開スキーマまたは必須フィールドのリストではなく、アプローチを説明している。
概念情報ドメイン#
これらのドメインは意図的に広範である。 1つの機能は、ドメインの一部のみを使用し、権威のあるシステムは、商社、プロバイダー、市場、およびライフサイクルの段階によって異なる可能性がある。
ソースのマッピングの仕組み#
01 · define
目的を合意する
ビジネス上の質問、決定、KPI、および許可されたアクションを定義する。
02 · inventory
承認されたソースを特定する
必要な各概念を権威を持って観察するシステムを特定する。
03 · map
ビジネスの意味を一致させる
意味、粒度、関係、タイミング、所有権、および許可された変換について合意する。
04 · validate
カバレッジと品質を測定する
完全性、一貫性、鮮度、線形性、および安全な取り扱いをテストする。
05 · operate
マッピングを監視する
ソースのドリフト、遅延した配信、定義の変更、およびカバレッジの喪失を検出する。
1つの商社の概念は、プロセッサレポート、倉庫モデル、API、またはファイルで異なる方法で表現される可能性がある。 DEUNA は、これらのソースが公開された標準的な名前を採用することを必要としない。 承認されたマッピングは、各ソースがどのようにデプロイメントに貢献し、どのシステムが権威を持つかを記録する。
マッピングの原則#
| 原則 | 実装に関するガイダンス |
|---|---|
| 名前の前に意味 | 例に似たソースの列名を変更するのではなく、ビジネスの定義を一致させる。 |
| 粒度を保持する | 注文レベル、試行レベル、イベントレベル、ケースレベル、および財務的な証拠を明確に区別する。 |
| 権限を維持する | どのソースが観察値を所有し、どの値が派生しているかを記録する。 |
| 関係性を安定させる | ライフサイクル全体で、重要な、機密性のないリンクを保持し、結果の説明を可能にする。 |
| 時間を明確にする | 観察、処理、および財務的な利用可能性の境界を、異なる場合に保持する。 |
| 機密データを最小限に抑える | 有効な目的に必要な承認されたコンテキストのみを共有し、テキストまたはメタデータに資格情報を含めない。 |
| 変更をバージョン管理する | ソースまたはビジネス定義が本番環境に投入される前に、マッピングの変更を確認してください。 |
準備段階#
マッピングが本番環境でのインサイトや意思決定をサポートする前に、商社とDEUNAは以下の項目について合意する必要があります。
- ユースケース、商社の範囲、対象市場、環境、および評価期間;
- 各ビジネスコンセプトに対する承認されたソースと権限。
- 期待される粒度、ライフサイクル関係、およびタイミング境界;
- 品質、鮮度、整合性、およびドリフトの閾値;
- アクセス、保持、最小化、削除、および監査要件;
- 承認されたソースが不完全、遅延、または利用できない場合に備えるための代替動作。
生成されるマッピングは、DEUNAチームによって管理される、デプロイメント固有の設定です。このドキュメントからは推測することはできません。
APIと顧客アクションのライフサイクルを実装するために、 Athia Data Guidance, Athiaとの統合, および Payments Intelligenceのためのデータガバナンス.