データ メッシュでのマスター データの管理
多くの場合、データ メッシュ アーキテクチャを使用する企業には多数のドメインがあり、それぞれに固有のシステムとデータが含まれています。
このような設定では、同じデータの複数のバージョンが存在する可能性があるため、この広範なデータの分散によって複雑さが増します。 所有者が、複数のドメインから同じデータのすべての異なる部分を統合して調和させる必要があるため、統合にはより多くの労力が必要です。 これらの異なるドメイン間のコンテキストでは、データに整合性がない可能性があります。 データの品質も異なる場合があります。 これらの課題に対処するには、マスター データ管理 (MDM) を適用します。
ドメイン指向のマスター データ管理
マスター ID 番号は、MDM の重要な側面です。 マスター ID 番号は、マスター データとドメインのデータをリンクします。 これらの番号は、どのデータがマスター化され、どのデータが一緒に属しているかを追跡するために重要です。 一意のデータのみを識別し、システム内でローカルにではなく、中央でマスター ID 番号を割り当てることができます。 さまざまなシステムのマスター データは、MDM ソリューション内で一緒にする必要があります。
ドメイン指向アーキテクチャではそれらの分散の性質により、MDM の動作が異なります。 ドメイン内の MDM に依存しているため、一貫性の実現は困難です。
一貫性を実現できる 1 つの方法は、データ製品を配布するときに、一元管理されたマスター データに準拠するようにドメインに依頼することです。 マスター データの一覧は、マスター データ ストアまたは中央リポジトリで公開できます。 ドメインは、他のドメインにデータ製品を配布するときに、エンタープライズ参照データからのエンタープライズ参照識別子を使用してデータを分類できます。 これにより、他のドメインは、それらのデータ製品内のマスター データをすばやく認識できます。
また、MDM アクティビティをグループ化するときに、マスター データ ストアを一元化されたリポジトリとして使用して、新しい MDM ドメインを作成することもできます。 それぞれの新しい MDM ドメインには、マスター データの識別と制御に重点を置く特定のデータ主体が含まれている必要があります。 このデータのよく知られている例には、顧客、製品、従業員、地理的な場所、財務およびリスク情報などがあります。 これらの MDM ドメインのマスター データは、他のドメインに戻る方法を見つける必要があります。 このデータの配布は、データ製品の配布に似ています。
マスター データ管理の範囲を指定し、さまざまな方法でデータ製品の配布を許可できます。 特定のスコープの境界内では、データ製品はエンタープライズ マスター データに準拠する必要はありませんが、スコープの境界を超えた場合は、データ製品はそれに準拠する必要があります。 また、このパターンを逆に適用することもできます。この場合、マスター データへの準拠は特定のスコープ内でのみ必要となり、その外部では必要なくなります。 これらの設定では、マスター データは MDM ソリューション内で一元的に管理されます。 ドメインは、中央のマスター データにマップするローカル データを認識できるように、マスター データを交換する必要があります。 これらのリレーションシップを特定して維持することで、どのデータがマスター化され、どのデータを迅速にリンクできるかを把握できます。 運用システムのローカル ドメイン キーが変更された場合、すべてをバインドする要素はマスター識別子だけです。
マスター識別子を配布するときは、MDM マスター識別子をすべてのソース システムに当てはめないでください。 そのようにすると、一貫性の問題が発生する可能性があります。 MDM ハブからマスター識別子を取得する必要があるのは、MDM の対象となるアプリケーションまたはシステムだけです。 MDM の対象ではないシステムでは、独自のローカル (ドメイン) 整合性を使用する必要があります。
ドメイン レベルのマスター データ管理
重複するデータを探すと、さまざまな程度の重複が検出される可能性があります。 一部のデータは汎用であり、多くのドメインにまたがっています。 その他のデータは重複が限定的であり、一部のドメインのみにまたがっています。 MDM をドメイン レベルの MDM に拡張することで、重複するデータの量とその重要性を区別します。 これを行うには、特定のスコープ内にマスター データの部分的なビューを作成します。 これは、データが、すべてのドメインではなく一部のドメイン間で共有されている場合に便利です。
重複するドメインがデータを管理し、中央への依存関係を持たないことが重要です。 MDM ソリューションは、これを実現するのに役立ちます。 インフラストラクチャを抽象化し、MDM をサービスとしてドメインに提供することで、使用を大幅に簡素化できます。 中央のソリューションを使用する場合は、個々のドメインまたはスコープに分離されたビューを適用します。
再利用可能なコンポーネントとの整合性を実現する
コードの共有は、マスター データのコラボレーションと再利用性を確保するもう一つの方法です。 マスター データを共有する代わりに、基になるコード (スニペットとスクリプト) を共有して出力を生成し、効果的な再利用を促進します。 バージョン管理を使用して、この基になるコードを中央のオープンなリポジトリに格納します。 チームは全員、このリポジトリに存在するコードに貢献し、改善することができます。
このモデルでは、ドメイン内でのみビジネス ロジックを適用します。 チームは、適切だと思われる限り、ロジックを変更、改善し、または少し最適化されたバージョンのロジックを使用できます。 コミュニティの機能強化が中央コード リポジトリに追加されたときに、出力を再生成できます。
チームがコードを変更できるようにすると、さまざまなチーム間の結果の比較が困難になり、一貫性に影響を与える可能性があることに注意してください。
マスター データの管理のまとめ
ユーザーは、使用するデータに一貫性があり、正しい場合にのみ、正しい意思決定を行うことができます。 MDM を使用すると、エンタープライズ レベルでデータの一貫性と品質を確保できます。
組織は MDM の適切なバランスを見つける必要があります。 マスター データまたは参照値の領域が多すぎると、ドメインをまたいだ配置が非常に多くなります。 エンタープライズ データがまったくない場合、結果を比較できなくなります。 バランスの取れた方法で MDM の使用を開始するための実用的な方法は、リポジトリを実装することです。 これは、組織のマスター データを管理するための最もシンプルな方法です。 リポジトリを使用すると、低品質のデータや調整する必要があるデータを確認するためにドメイン システムを調整する必要がなくなります。 リポジトリは情報を取得するために役立つので、より迅速に価値を提供できます。
リポジトリを実装した後に、明確なスコープの概要を定義する必要があります。 すべてのデータを選択するとエンタープライズ データの統一の罠に陥いることがあります。 最も重要なフィールドのマスター データのみを選択します。 最初に、顧客、契約、製品、組織単位など、最も価値を高めるサブジェクトを選択します。 属性の数は、数百または数千ではなく、数十単位にする必要があります。
ドメインについての合意が成立したら、プロセスとガバナンスを調整します。 すべてのドメインに対して明白なタイムラインとレビューについて合意します。 また、メタデータについての作業も確認してください。 マスター データをカタログ化します。 ソース システムの候補となるデータ要素と、それらの要素がデータ パイプラインを通過する方法をドメインで認識していることを確認します。
最後のステップと最終的な目標は、共存を達成することです。 改善点は、直接ドメインにも適用される必要があります。 これは、多くのアーキテクチャ変更を必要とするため、プロセスの最も困難な部分です。 ドメインは、一元管理された MDM ソリューションから送信された修正と機能強化を処理できる必要があります。