クラウドネイティブなデータガバナンスソリューションを設計する方法

1. 背景

データ ガバナンス プロジェクトには、多くの場合、規制上の圧力、高コスト、投資収益の不明確さが伴います。重要なデータを識別し、メタデータを管理し、データ品質を制御し、データの出所を決定するプロセスは、多くの場合、時間がかかり、コストがかかります。たとえば、銀行業界における関連年間コストは、年間 1,000 万人民元を簡単に超え、場合によっては 1 億人民元を超えることもあります。このプロセスは、過去数十年にわたって作成された数百のシステムとアプリケーションにわたる数千のデータ要素を手動で識別する必要があるため、実装が困難で時間がかかります。

おそらく、これらの中で最もわかりにくいのは、データの系統です。一部のベンダーは、システムをスキャンしてメタデータを収集できるツールを作成することに成功していますが、一般的に、ほとんどの既存のシステム環境に接続することはできません。データ フローは企業全体で構造化されておらず、一貫して文書化されていないことが多いため、主にベンダーの知識と手動のマッピング作業に依存してコンパイルされます。サプライヤーが撤退し、この知識が会社から失われると、状況はさらに悪化します。

さらに、ビジネス メタデータと技術メタデータが調整された修復計画の一環として記録されている場合でも、メタデータのキャプチャと記録が自動化されていないため、ほとんどのメタデータはすぐに古くなります。最新の状態に保つには、継続的な手作業が必要です。

最後に、組織はデータ ガバナンス自体を超えたビジネス目的を達成するために、このメタデータを企業全体のビジネス ユニットと共有します。多くの大規模組織では、データ管理基盤がデータ サイエンスなどのビジネス目的もサポートする必要があることを何らかの形で明記したデータ戦略を持っていますが、これを実際に実装することに成功している組織はほとんどありません。

クラウドベースのテクノロジーの登場により、スケーラビリティ、弾力性、コストの削減、迅速な導入、データ テクノロジーの互換性の向上が期待できます。過去数年にわたり、さまざまな組織のクラウド移行およびデータ最新化の取り組みに協力してきた中で、データが設計された瞬間からデータをインテリジェントに管理する方法に関するパターンが浮かび上がってきました。

たとえば、API の相互運用性標準を定義して、将来のデータ系統の視覚化におけるログ記録とガバナンスを自動化できます。データ品質管理は、一貫したデータ モデルに基づいて作成し、新しいインフラストラクチャに直接組み込むことができます。データ要素とその起源に関する重要な情報はデータ カタログに簡単に記録されるため、変換中に既存の知識が失われたり劣化したりすることはありません。

以下では、データ ガバナンス設計の概念についてさらに詳しく説明し、データ アセット、データ管理センター、API 駆動型アーキテクチャ (データ ファブリックと呼ばれるデータ レイヤー経由) などの機能を通じてデータ ガバナンスがどのように実現されるかを説明します。

2. フレームワーク

サービスベースのアーキテクチャでは、マイクロサービスが組織のビジネスプロセスを接続します。このようなアーキテクチャでは、4 つの基本コンポーネントが連携して、データ管理とデータ ガバナンスの設計を実装できます。次に例を示します。5 つの部門 (リスクとコンプライアンス、財務、マーケティング、アカウント管理、製品開発) を持つ組織について説明します。各部門は複数のデータ製品を作成および管理しており、その一部は他の部門の消費者も使用するため「データ資産」として分類されます。さまざまな API がさまざまな部門間でデータと情報を交換します。これらはすべてデータ インフラストラクチャに基づいて慎重に計画され、データ管理センターによってスキャンされて、データ管理とサービスが提供されます。これらのコンポーネントを簡単に見てみましょう。

データ資産– 通常、各ドメインまたは部門は、他のドメインで使用されるデータまたは情報を生成します。たとえば、顧客管理ドメインでは、オンボーディングおよび顧客関係管理プロセスを通じて顧客データを収集し、顧客情報を含む中央データベースを生成および維持する場合があります。マーケティング チームはデータベースを使用して販売活動を実行し、リスク部門はデータベースを使用してデータ プライバシー規制への準拠を確認できます。このようなデータ製品には、データ製品、データ資産、信頼できるソース、権威あるデータソース、記録システムなど、さまざまなラベルが付けられています。

API 駆動型アーキテクチャ- さまざまなチームが、データ統合の優先方法または唯一の方法として API を介して接続します。 API ファーストの考え方を維持することで、重要なデータが組織内外の消費者に利用可能になります。

データ管理センター- 個別に構成されたスペースまたは環境でデータ管理機能のセットを提供します。これらの機能には、メタデータ管理、マスターおよび参照データ管理、データ品質が含まれます。これらの機能を組織のあらゆる領域に組み込むのではなく、中央データ管理から展開できます。

データ ファブリック— すべてのシステムとアプリケーション間の接続を提供するスレッドは、データ ファブリックと呼ばれます。これは、どこからともなくインスタンス化できる魔法のレイヤーではありません。むしろ、一連のサポート機能と慎重に検討されたガバナンス プロトコルで構成されており、これらを組み合わせることで、企業全体のデータを検出、カタログ化、分類、タグ付け、品質管理し、共通の相互運用性標準とチャネルを通じてアクセスできるようにします。

データ資産管理哲学の採用

データ資産とは何ですか?

データ資産とは、準備されたデータのセット（通常は生データではない）であり、より幅広い消費者が利用できるようになります。管理され、ラベル付けされ、品質管理され、簡単にアクセスできます。企業全体の消費者にセルフサービスを可能にするために、検出と説明が可能です。データ資産は通常、企業全体で再利用され、特定のデータまたはビジネス ドメイン内で所有されます。

なぜそれが非常に懸念されるのか

データ資産は多数の消費者によって使用されるため、これはデータ品質とガバナンス制御を実装する非常に論理的な場所です。この管理対象資産では、コンテンツにタグが付けられ、データ品質が厳密に管理されているため、企業全体でこのデータを識別して測定する必要がなく、多くの場合「真実のバージョン」に一貫性がなくなるのではなく、特定のデータ セットに対して信頼できる 1 つの配布ポイントが存在します。たとえば、米国のトップ 10 銀行はすでに、これらの重要なデータ ソースを特定して管理する取り組みを開始しています。通常、約 20 ～ 100 のデータ資産があれば、組織はすべての重要なデータを制御できるようになります。これは、1,000 個の個別のシステムでデータ品質を定義するよりもはるかに効果的です。

データ資産の採用

データ資産を作成して定義するだけでは不十分です。必要かつ同様に重要なステップは、その使用を管理することです。なぜなら、消費者がそれらを使用しないと、集中管理されたデータの品質の恩恵を受けることができないからです。その結果、多くの組織がさまざまなバージョンのデータ資産導入イニシアチブを立ち上げました。通常、これには、一方では共有と流通、データ資産とその使用の利点に関する認識の強化、他方では、データがデータ資産からのみ使用され、他の場所では使用されないようにすることを要求するコンプライアンス標準とメカニズムが含まれます。

ビジネスユーザーと影響

データ組織にとって、測定が難しい価値（規制上の罰金の回避など）を超えて、ビジネスに付加する価値を明確に表現することは、歴史的な苦労でした。データ資産はここでゲームチェンジャーとなります。データ ソースは、重要な下流の消費者が存在する場合にのみデータ資産となるため、これらの消費者とその使用例を文書化することをお勧めします。

データ資産とそれに依存するユースケースの簡単な概要を作成することで、これらの資産が及ぼす影響を明確に示すことができます。データの下流要件を収集し、信頼できる配布ポイント内でデータをどのように制御および強化できるかを評価することで、影響評価をより効果的に実行することもできます。たとえば、ある大手保険会社は、顧客データの強化によって販売キャンペーンをより簡単に実行し、その効果を高めることができたかどうかを比較的正確に測定することができました。

データ資産を識別して積極的に管理しないと、重複や不整合を伴う、理解しがたい「蜘蛛の巣」のようなデータ フローになってしまうことがよくあります。データ資産を戦略的に使用することで、独自の再利用可能なユースケースに使用される、厳選されたデータ ソースのグループを識別できます。

3. データ資産ガバナンス

データ資産をデータ ファブリックに組み込んで「不良」データによって圧倒されないようにするためのガバナンス モデルが必要であり、「データ メッシュ」は、このガバナンスを組織に組み込むための主要な方法です。

データグリッド

比較的新しい用語に「データ グリッド」があります。これは、中央のセルフサービス データ インフラストラクチャによってサポートされ、ビジネス領域が重要なデータをキャプチャおよび維持する時点で管理できるようにするアプローチです。これは、組織が重要なデータをデータ レイクやデータ ウェアハウスに集中させようとした過去の取り組みとはまったく対照的です。このような集中化の取り組みでは、データを理解するためのビジネス固有のコンテキストを持たない中央データ チームに過度の期待が寄せられ、消費者が求めるペースに追いつけないという問題がよく発生します。 「汚れた」データレイクはよくある症状です。

ガバナンスモデル

一部のビジネス領域または機能領域では、重要なデータ資産をすぐに管理する準備ができている場合がありますが、他の領域ではそうでない場合があります。銀行業界を例にとると、規制データガバナンスガイドラインに準拠する長年の経験があるため、一般的に比較的成熟している分野にはリスクと財務が含まれます。

ドメイン所有者が他のユーザーが使用できるようにデータ資産を生成できるようにするには、いくつかの要件があります。まず、サポート部門には、データ管理とエンジニアリングに関する最低限必要なスキルと経験が必要です。次に、ドメイン所有者は、チームの内部または外部に必要なリソース、または責任の一部を委任するための予算を持っている必要があります。データ資産の維持管理は通常、フルタイムの仕事ではありませんが、大きな責任を伴います。

これらの考慮事項に基づいて、企業は適切なガバナンス モデルを選択できますが、それぞれのガバナンス モデルには長所と短所があります。組織は、最初は 1 つのモデルを選択しても、時間の経過とともに別のモデルに進化する場合があります。

ガバナンスに関する推奨事項

次の推奨事項に従うと、パターンを標準化し、実装のリスクを軽減できます。

• データ資産の概念を企業変革アプローチに組み込む
• データ資産のガバナンスを含む一連の設計原則を開発し、それに従う
• データ資産は、確認済みの信頼できるソースから直接取得する必要があるという設計原則を遵守します。
• 明確に記述されたドメインを持つ信頼できるエンタープライズデータモデルを定義する
• データ資産の中央カタログを維持する
• 分類やその他のセキュリティ関連のメタデータを含む、ロールベースのアクセスを可能にするために必要なメタデータの最小限のセットに準拠する
• 発見可能性と相互運用性の標準を定義し、実施する

4. API駆動型アーキテクチャと相互運用性標準

明確に定義された相互運用性標準を備えた API ファーストの考え方を採用することは、将来のデータフローのガバナンスと制御を確保し、データ系統の自動キャプチャを推進して、将来的に大幅な手動マッピング作業を回避するための鍵となります。

API 駆動型アーキテクチャ

API ファースト インフラストラクチャでは、データ統合の最初または唯一の方法として、さまざまなチームが API を介して接続します。 API ファーストの考え方を維持することで、重要なデータが組織内外の消費者に利用可能になります。正しく実行されれば、オープン バンキング標準などのグローバル標準への準拠も促進され、戦略的パートナーとのコラボレーションの機会も提供されるはずです。

相互運用性標準

相互運用性標準は、さまざまなシステムやアプリケーション間の相互作用とデータ交換を促進する一連のルールとプロトコルで構成されています。電気を例えにすると、冷蔵庫から照明、携帯電話の充電器まで、あらゆる種類の電化製品を購入し、通常はそれを自宅のコンセントに接続できると期待できます。データについても同様です。家の中のさまざまな部屋にアクセスできる人なら誰でも利用できる標準ソケットを通じて、合意された品質と量のデータが利用できるようにする必要があります。企業にとって、これにはインターフェースの種類と、インターフェースにデータが提供されるチャネルに関する合意が必要です。

相互運用性標準の 1 セットがすべての組織に適しているわけではありませんが、重要な側面やコンポーネントがいくつかあります。

• データモデルを遵守することで、少なくとも最低限の重要なデータについては、データの一貫した使用と解釈が保証されます。
• 標準メッセージングとペイロード形式
• 最小限のビジネスおよび技術メタデータが識別され、維持され、システムおよびアプリケーションとともに標準化された形式で利用可能になります。
• 特定された互換性のある技術のセット

相互運用性ツールセット

一貫した相互運用性標準のセットがあれば、準拠しているあらゆる種類のテクノロジーがインフラストラクチャとデータを交換できるようになります。導入の目的で、データ エンジニアがそれぞれの目的で使用できる API テクノロジーを少なくとも 1 つ、可能であれば複数特定することをお勧めします。

選択するテクノロジーは、組織、目標とするビジネス成果、既存のテクノロジー スタックと専門知識によって異なります。たとえば、ある地域の小売組織は、デジタル組織を構築するための API プラットフォームとして MuleSoft を採用することを決定し、一方で大手のメーカーは、独自に内部構築した API 機能を作成することを選択しました。

API によるデータ系統の産業化

組織にとって、API ファーストの考え方を採用することで、将来のインフラストラクチャの設計にデータ管理を組み込む大きなチャンスが生まれます。

1. データと情報フローの将来の需要を満たすために API パターンを定義できます。パターンの例には、非同期、同期、オーケストレーションとデータ処理、イベント駆動型パターンなどがあります。
2. 各モードで、API で提供されるメタデータ スクリプトまたはファイルを調整します。これらのスクリプトは標準化されている必要があり、ソース、送信先、フィード頻度、含まれる主要なデータ要素、さまざまなインジケーター (分類、PII インジケーターなど) などのビジネスおよび技術メタデータの最小限のセットが含まれている必要があります。 API が更新されるたびに、これらのメタデータ ファイルが更新され (可能な場合は自動的に)、API ディレクトリに保持されることがベスト プラクティスです。
3. 必ず API メタデータ ファイルをメタデータ管理にプッシュまたはプルしてください。家系図グラフを作成できるように、特にデータ カタログなどのツールが用意されています。

システム間でデータを交換するための主な手段として API を推進し、最低限の標準を主張することで、「設計によるデータ系統」が推進されます。

注意:メタデータ ファイルを複雑にしすぎないでください。ビジネス価値が不明瞭な網羅的なセットよりも、主要なメタデータのセットを少なくする方が効果的です。例外はありますが、詳細なデータ要素レベルのソースおよび変換ロジックをデフォルトで含める必要はありません。

5. データ管理センター

集中的に構成されながらローカルで採用されるデータ管理機能により、実装後に手動で実行されるガバナンス活動よりも低コストで、データの一貫した定義、ガバナンス、保護が強化されます。

データ管理センターの重要性

設計によるデータ管理を推進するには、最低限必要なデータ機能を備えた単一の構成済み管理センターを作成して提供することが重要です。管理センターにはデータ管理が含まれており、将来のクラウドネイティブ ビジネスまたは機能プロセス構築の一部として参照および組み込まれる必要があります。各変革イニシアチブやビジネス機能領域で、マスター データの適切な使用、メタデータの管理、データ品質の監視方法に関する機能と標準を再発明するのではなく、データからこれらの機能をセルフサービスで利用できるようにする必要があります。

データ管理には設計が必要

歴史的に、従来のデータ管理投資の大部分は「事後」（つまり実装後）に費やされてきました。ビジネス プロセスの検出、データ要素の識別、ビジネス要件の推測、既存のインフラストラクチャ実装に対するデータ品質の測定には、多大な手作業と継続的な規律が必要です。

ここで紹介するアプローチでは、これらのデータ管理の考慮事項が、設計および実装フェーズの前と最中に組み込まれています。さらに、後で手動で実行されるガバナンス手順は、機能要件、非機能要件、および技術要件として設計の一部として統合されます。ソリューションが実装されると、データ管理は「設計によって」構築されます。

設計機能の例

データ カタログ - API について上で概説したとおりですが、より広義では、アプリケーションとそれらの間のデータ フローの体系的かつ包括的な検出、ドキュメント化、視覚化を自動化できます。

データ品質- データの品質と整合性を監視し、確保するためのコントロールは、主に 2 つの方法で組み込むことができます。まず、データの作成、取得、および送信時に特定の制御と制限を適用できます。例としては、受け入れられる値や有効な値に対する制限や、データ フロー内の調整チェックなどが挙げられます。 2 番目に、データ資産などの戦略的な場所では、静的データに対して品質管理を実装して、完全性、正確性、適時性を測定できます。

マスター データと参照データ– データ資産の非常に具体的な例であるマスター データと参照データは、トランザクション レベルで再利用されるデータの一貫した使用を促進できる非常に強力な手段です。たとえば、MDM は、企業全体のオンボーディング、トランザクション、顧客との連絡、マーケティング、関係管理などのプロセスで正しい顧客データ要素が使用されるようにします。同様に、郵便番号標準などの簡単にアクセスできる参照データを提供することで、その採用が促進されます。

システム間のクラウドネイティブな接着剤としてのデータファブリック

すべてのシステムとアプリケーション間の接続性を提供するスレッドは、データ構造と呼ばれます。これは、どこからともなくインスタンス化できる魔法のレイヤーではありません。むしろ、一連のサポート機能と慎重に検討されたガバナンス プロトコルで構成されており、これらを組み合わせることで、企業全体の情報を共通の相互運用性標準とチャネルを通じて検出、カタログ化、分類、タグ付け、品質管理し、アクセスできるようになります。

この構造は、主に、前述のデータ資産、API、およびデータ管理センター コンポーネントによって実現されます。正しく適切に使用すれば、それらはデータ構造のバックボーンを形成するはずです。ただし、最低限の要件ではないにしても、必須となる補完的なデータ機能がいくつかあります。

データ パイプライン、取り込み、準備、転送、プロビジョニング、およびストレージ– API が機能しない場合は、代替または補完的なデータ配信および統合オプションによって、ビジネスまたは運用に応じてデータが収集、取り込み、変換、管理され、利用可能になることを保証できます。機能リクエスト。データを保存するには構成ストレージが必要です。

データ オーケストレーション- 対象となるユース ケースとビジネス プロセスに応じて、データ オーケストレーションを適用して、さまざまなソースからデータを取得し、そのデータを組み合わせて統合し、データ分析ツールで利用できるようにすることができます。データ オーケストレーションは、IaaS または PaaS レベルで実行することも、Apache Airflow、Prefect、Snowflake などのインフラストラクチャ レベルのアクティビティを抽象化するテクノロジを使用して実行することもできます。

データ セキュリティと保護– 機密データが失われたり、悪用されたり、権限のないユーザーによってアクセスされたりしないように監視および確認し、データ資産を積極的に保護する機能を有効にするプロセス。データの保護方法と共有方法は、ポリシーと標準によって規定される必要があります。アイデンティティおよびアクセス管理 (IAM) はロールベースのアクセスを容易にし、さまざまなネットワークおよび認証保護により不正アクセスや操作からデータを保護できます。

レポート、分析、データ サイエンス– レポートまたは分析のユース ケースを満たすために、1 つ以上のデータ プラットフォームを作成できます。データ資産、API、データ管理を備えています。データ管理センターを導入すると、データが利用可能で、理解しやすく、簡単にアクセスできるため、これは簡単な作業になります。また、クラウドネイティブ環境では、多額の先行投資を必要とせずに、適切なレポート作成ツールやデータ サイエンス ツールをオンデマンドでアクティブ化できます。

7. 成功要因

最後に、成功要因について少し考えてこの記事を締めくくりたいと思います。成功している組織は通常、最初にいくつかの選択された領域に重点を置き、最初からビジネス関係者を関与させ、コンプライアンスとポリシーの利点がビジネス成果と並行して考慮されるようにし、クラウドファーストの設計原則に準拠します。

1. 小規模に開始する -比較的整理されたドメイン内の 1 つまたは 2 つのデータ資産から開始します。通常は、材料、顧客、および製品データが有力な候補になります。小規模で成功し、その集大成である勢いを利用して、他の分野で学んだ教訓を実践に移す方が簡単です。
2. ビジネスの関与 –最初からビジネス代表者を含めます。価値の創造は、データの採用と消費に左右されるため、必要なデータとそのデータへのアクセス方法など、関連する要件がデータ資産とデータ構造に組み込まれていることを確認することが重要です。
3. メリットの統合– 強力な成功事例を持つ組織は、多くの場合、過去のデータ ガバナンスの責任と、より将来を見据えたデータ サイエンス関連のユース ケースを組み合わせて、強力なデータ基盤が企業全体の利害関係者にどのように役立つかを明確に表現できます。データが管理されていれば、投資収益率はより説得力のあるものになります。設計により、規制コンプライアンスとビジネス指向の洞察主導のユースケースを推進します。
4. クラウド ファースト– クラウド ネイティブ設計に準拠することで、ベンダーの障壁を防ぎ、リスクのない失敗のない実験が可能になり、高額な先行投資を回避し、問題発生時に「迅速な修正」で成功を拡大することができます。