データメッシュ内のアーキテクチャと機能

Last reviewed 2024-09-03 UTC

データメッシュは、データをプロダクト(このドキュメントではデータ プロダクトと呼びます)として扱うアーキテクチャおよび組織フレームワークです。このフレームワークでは、データを完全に理解し、組織全体の一連のデータ ガバナンス基準に従うチームによって、データ プロダクトが開発されます。データ プロダクトがデータメッシュにデプロイされると、組織内の分散チームは、ニーズに関連するデータを迅速かつ効率的に検出してアクセスできます。このようなデータメッシュを適切に機能させるには、まずこのドキュメントで説明するアーキテクチャ コンポーネントと組織のロールの概要を理解する必要があります。

このドキュメントは、Google Cloud でデータメッシュを実装する方法を説明するシリーズの一部です。ここでは、Google Cloud での最新の分散型データメッシュの構築で説明されているコンセプトを理解していることを前提としています。

このシリーズは、次のパートから構成されています。

このシリーズでは、説明するデータメッシュは組織内部にあります。データ メッシュ アーキテクチャを拡張してデータ プロダクトをサードパーティに提供することは可能ですが、そのような拡張的な手法についてはこのドキュメントでは説明しません。データメッシュを拡張する場合は、組織内での使用だけでなく、その他の考慮事項も考慮する必要があります。

アーキテクチャ

このシリーズで説明するアーキテクチャ コンポーネントを定義する際は、次の重要な用語を使用します。

  • データ プロダクト: データ プロダクトは、1 つ以上の関連データリソースの論理コンテナまたはグループです。
  • データリソース: データリソースは、構造化データを保持するストレージ システム内の物理アセット、または構造化データを生成するクエリを保存する物理アセットです。
  • データ属性: データ属性は、データリソースのフィールドまたは要素です。

次の図は、Google Cloud に実装されたデータメッシュの主なアーキテクチャ コンポーネントの概要を示しています。

データメッシュのアーキテクチャ コンポーネント。

上の図は、次のことを示しています。

  • セントラル サービスを使用すると、データメッシュ参加者に影響を与える組織のポリシー、(Identity and Access Management グループによる)アクセス制御、インフラストラクチャ固有のアーティファクトなどのデータ プロダクトの作成と管理が可能になります。このようなコミットメントと予約、データメッシュの機能を容易にするインフラストラクチャについては、プラットフォーム コンポーネントとソリューションを作成するをご覧ください。
  • セントラル サービスは主に、データメッシュ内のすべてのデータ プロダクトに Data Catalog を提供し、これらのプロダクトのユーザーに対して検出メカニズムを提供します。
  • データドメインは明確に定義されたデータ消費インターフェースを通じて、データのサブセットをデータ プロダクトとして公開します。これらのデータ プロダクトにはテーブル、ビュー、構造化ファイル、トピック、ストリームなどがあります。BigQuery ではデータセット、Cloud Storage ではフォルダまたはバケットになります。データ プロダクトとして公開できるさまざま種類のインターフェースが存在します。インターフェースの例として、BigQuery テーブルの BigQuery ビューがあります。分析目的で最も一般的に使用されるインターフェースの種類については、データメッシュでデータ プロダクトを構築するをご覧ください。

データメッシュのリファレンス実装

このアーキテクチャのリファレンス実装は、data-mesh-demo リポジトリにあります。リファレンス実装で使用されている Terraform スクリプトは、データメッシュのコンセプトを示していますが、本番環境での使用は想定していません。これらのスクリプトを実行すると、次のことができるようになります。

  • プロダクトの定義と基礎となるデータを分離する。
  • プロダクトのインターフェースを記述するための Data Catalog テンプレートを作成する。
  • これらのテンプレートを使って、プロダクトのインターフェースにタグ付けする。
  • プロダクトの消費者に権限を付与する。

プロダクトのインターフェースについては、リファレンス実装では、次のインターフェース タイプを作成して使用します。

  • BigQuery テーブルの承認済みビュー。
  • Pub/Sub トピックに基づくデータ ストリーム。

詳細については、リポジトリの README ファイルをご覧ください。

データメッシュの機能

データメッシュを適切に動作させるには、データメッシュ内でタスクを実行するユーザーに明確なロールを定義する必要があります。所有権はチームのアーキタイプまたは関数に割り当てられます。これらの機能は、データメッシュで作業するユーザーのコアユーザー ジャーニーを保持します。ユーザー ジャーニーを明確に説明するために、ユーザーロールに割り当てられています。これらのユーザーロールは各企業の状況に応じて分割または結合できます。組織内の従業員やチームに直接ロールをマッピングする必要はありません。

データドメインはビジネス ユニット(BU)または企業内の機能と連携します。ビジネス ドメインの一般的な例としては、銀行の住宅ローン部門や企業の顧客部門、流通部門、財務部門、人事部門などがあります。概念的には、データ メッシュにはデータ プロデューサー チームとデータ コンシューマ チームの 2 つのドメイン関連の機能があります。1 つのデータドメインが同時に両方の機能を処理する可能性が高いことを理解することが重要です。データドメイン チームは、自身が所有するデータからデータ プロダクトを生成します。また、チームはデータ プロダクトを利用してビジネスに関する分析情報を入手し、他のドメインで使用するため派生データ プロダクトを生成します。

データメッシュには、ドメインベースの機能に加えて、組織内の一元管理されたチームによって実行される一連の機能もあります。これらの一元管理されたチームは、クロスドメインの監視、サービス、ガバナンスを提供することで、データメッシュの運用を可能にします。これによりデータ プロダクトの作成と消費におけるデータドメインの運用の負担が軽減され、データメッシュの運用に必要なクロスドメイン関係が容易になります。

このドキュメントでは、データメッシュ固有のロールを持つ機能についてのみ説明します。プラットフォームに採用されているアーキテクチャに関係なく、企業で必要なロールは他にもいくつかあります。ただし、これらの他の役割についてはこのドキュメントでは説明しません。

データメッシュの主な 4 つの機能は次のとおりです。

  • データ ドメインベースのプロデューサー チーム: ライフサイクル全体でデータ プロダクトを作成し、維持します。これらのチームは多くの場合、データ プロデューサーと呼ばれます。
  • データドメイン ベースのコンシューマー チーム: データ プロダクトを検出し、さまざまな分析アプリケーションで使用します。これらのチームは、データ プロダクトを使用して新しいデータ プロダクトを作成できます。これらのチームは多くの場合に、データ コンシューマーと呼ばれます。
  • 一元管理されたデータ ガバナンス チーム: データ プロデューサー間でデータ ガバナンス ポリシーを定義して適用し、コンシューマーに対してデータ品質とデータの信頼性を確保します。このチームは多くの場合に、「データ ガバナンス チーム」と呼ばれます。
  • 一元管理されたセルフサービス インフラストラクチャ プラットフォーム チーム: データ プロデューサーにセルフサービス データ プラットフォームを提供します。このチームは、データ コンシューマーとデータ プロデューサーの両方が使用する、一元的なデータ検出とデータ プロダクトのオブザーバビリティのためのツールも提供しています。このチームは多くの場合に「データ プラットフォーム チーム」と呼ばれます。

考慮する必要があるその他の任意の機能は、データメッシュのセンター オブ エクセレンス(COE)の機能です。COE の目的はデータメッシュを管理することです。COE は、他の機能によって発生した競合を解決するための指定された仲裁チームでもあります。この機能は、他の 4 つの機能を接続する場合に活用できます。

データ ドメインベースのプロデューサー チーム

通常、データ プロダクトはデータの物理リポジトリ(単一または複数のデータ ウェアハウス、レイク、ストリーム)の上に構築されます。従来のデータ リポジトリを作成して維持するには、組織に従来のデータ プラットフォームのロールが必要です。ただし、従来のデータ プラットフォームのロールは通常、データ プロダクトを作成するユーザーではありません。

これらの物理リポジトリからデータ プロダクトを作成するには、データ エンジニアやデータ アーキテクトなど、さまざまなデータ実務者が必要です。次の表に、データ プロデューサー チームに必要なドメイン固有のユーザーロールを示します。


ロール

業務内容

必要なスキル

求めている結果

データ プロダクト オーナー
  • データ プロダクトの主要なビジネス上の連絡先として機能します。
  • プロダクトとして公開されるデータの定義、ポリシー、ビジネス上の決定、ビジネスルールの適用に責任を負います。
  • ビジネス上の質問に関する連絡窓口としての枠割を果たします。そのためオーナーは、データ コンシューマ チームまたは一元的なチーム(データ ガバナンスとデータ インフラストラクチャ プラットフォーム)とミーティングを行うときに、データドメインを代表します。

データ分析

データ アーキテクチャ

プロダクト管理
  • データ プロダクトはコンシューマーの価値を高めています。データ プロダクトのライフサイクルをしっかり管理でき、プロダクトを廃止するタイミングや新しいバージョンをリリースするタイミングなども決定します。
  • ユニバーサル データ要素は他のデータドメインと調整される。

データ プロダクト テクニカル リード
  • プロダクトの主な技術関連の連絡先として機能します。
  • プロダクトのインターフェースの実装と公開について責任を負います。
  • 技術的な質問に関する連絡窓口としての枠割を果たします。そのためリードは、データ コンシューマ チームまたは一元的なチーム(データ ガバナンスとデータ インフラストラクチャ プラットフォーム)とミーティングを行うときに、データドメインを代表します。
  • データ ガバナンス チームと連携して、組織内のデータメッシュ標準を定義して実装します。
  • データ プラットフォーム チームと連携して、本番環境と消費環境で発生する技術的なニーズに合わせたプラットフォームの開発を支援します。

データ エンジニアリング

データ アーキテクチャ

ソフトウェア エンジニアリング
  • データ プロダクトがビジネス要件とデータメッシュの技術基準を満たす。
  • データ コンシューマ チームがデータ プロダクトを使用し、データ プロダクトの検出エクスペリエンスによって生成された結果に表示される。
  • データ プロダクトの使用状況(1 日あたりのクエリ数など)を分析できます。


データ プロダクトのサポート
  • 本番環境サポートの問い合わせ先として機能します。
  • プロダクトのサービスレベル契約(SLA)を維持する責任があります。

ソフトウェア エンジニアリング

サイト信頼性エンジニアリング(SRE)
  • データ プロダクトは所定の SLA を満たす。
  • データ プロダクトの使用に関するデータ コンシューマの質問に対応し、解決する。

データドメイン対象分野の専門家(SME)
  • 他のデータドメインの SME とミーティングを行い、組織全体に共通のデータ要素の定義と境界を設定する際のデータドメインを代表します。
  • ドメイン内の新しいデータ プロデューサーが商品スコープを定義する際に支援します。

データ分析

データ アーキテクチャ
  • さまざまなデータドメインの他の SME と協力して、組織内のデータと、データで使用されるデータモデルを包括的に理解し、維持する。
  • 組織全体のデータモデルに一致する相互運用可能なデータ プロダクトの作成を容易にする。
  • データ プロダクトの作成とライフサイクル管理には明確な基準がある。
  • データドメインからのデータ プロダクトにはビジネス価値がある。

データオーナー
  • コンテンツ領域に関する責任があります。
  • データの品質と精度に関する責任があります。
  • アクセス リクエストを承認します。
  • データ プロダクトのドキュメント作成に貢献します。
  • あらゆるスキル。ただし業務に関する十分な知識が必要です。
  • あらゆるスキル。ただしデータの意味と、データに関するビジネスルールを完全に理解している必要があります。
  • あらゆるスキル。ただしデータ品質の問題に対して可能な限り最適な解決策を特定できる必要があります。
  • 各部門で使用するデータが正確であること。
  • ステークホルダーがデータを理解している。
  • データの使用は利用ポリシーに従って行われる。

データ ドメインベースのコンシューマ チーム

データメッシュでは、データ プロダクトを使用するユーザーは通常、データ プロダクト ドメイン外のデータユーザーです。これらのデータ コンシューマは、中央のデータカタログを使用して、ニーズに関連するデータ プロダクトを見つけます。ニーズは複数のデータ プロダクトで満たされることもあるため、データ コンシューマは最終的に複数のデータ プロダクトにサブスクライブする可能性があります。

データ コンシューマがユースケースに必要なデータ プロダクトを見つけられない場合は、データメッシュ COE に直接相談する必要があります。データ コンシューマは相談時にデータニーズについて提起し、1 つ以上のドメインでそのニーズを満たす方法についてアドバイスを求めることができます。

データ コンシューマはデータ プロダクトを探す際、永続的な分析ダッシュボードやレポート、個々のパフォーマンス レポート、その他のビジネス パフォーマンス指標など、さまざまなユースケースを実現できるデータを求めます。また、データ コンシューマは人工知能(AI)や機械学習(ML)のユースケースで使用できるデータ プロダクトを探している場合もあります。このようなさまざまなユースケースを実現するには、データ コンシューマは次のようなデータ実務者ペルソナを組み合わせる必要があります。


ロール

業務内容

必要なスキル

求めている結果

データ アナリスト

単一ドメインまたはクロスドメインのデータ プロダクトを検索、識別、評価、サブスクライブして、ビジネス インテリジェンス フレームワークの運用の基盤を構築します。

アナリティクス エンジニアリング

ビジネス分析
  • データ可視化スペシャリストが使用できる、クリーンでキュレートされ、集約されたデータセットを提供する。
  • データ プロダクトの使用方法に関するベスト プラクティスを作成する。
  • ドメインの分析ニーズに合わせて、クロスドメイン データセットを集約してキュレートする。

アプリケーション デベロッパー

ドメイン内外の 1 つ以上のデータ プロダクトでデータを使用するためのアプリケーション フレームワークを開発します。

アプリケーション開発

データ エンジニアリング
  • 1 つ以上のデータ プロダクトからデータを使用するアプリケーションを作成、提供、管理する。
  • エンドユーザーが使用するデータ アプリケーションを作成する。

データ可視化スペシャリスト
  • データ エンジニアリングとデータ分析の専門用語を、ビジネス関係者が理解できる情報に変換します。
  • データ プロダクトからビジネス レポートを生成するプロセスを定義します。
  • 戦略的なビジネス目標を説明するレポートを作成してモニタリングします。
  • 組織内のエンジニアと協力して、データ プロダクトから集約したデータセットを設計します。
  • レポート ソリューションを実装します。
  • 高レベルなビジネス要件を技術要件に変換します。

要件分析

データの可視化
  • 有効で正確なデータセットとレポートをエンドユーザーに提供する。
  • 開発されたダッシュボードとレポートによってビジネス要件が満たされる。

データ サイエンティスト
  • データ サイエンスのユースケース用のデータ プロダクトを検索、識別、評価、サブスクライブします。
  • 複数のデータドメインからデータ プロダクトとメタデータを抽出します。
  • 予測モデルをトレーニングしてデプロイし、ドメインのビジネス プロセスを最適化します。
  • 複数のデータドメインに対して可能なデータ キュレーションとデータ アノテーションの手法に関するフィードバックを提供します。

ML エンジニアリング

アナリティクス エンジニアリング
  • ビジネス プロセスを最適化する予測モデルと規範的モデルを作成する。
  • モデルのトレーニングとデプロイが適時に行われる。

中央データ ガバナンス チーム

データ ガバナンス チームによって、データ プロデューサーとコンシューマは、組織にコンプライアンス リスクをもたらすことなく、セルフサービス方式でデータを安全に共有、集約、計算できます。

組織のコンプライアンス要件を満たすために、データ ガバナンス チームは次のようなデータ実務担当者で構成されます。


ロール

業務内容

必要なスキル

求めている結果

データ ガバナンス スペシャリスト
  • コンプライアンスを一元的に管理および調整します。
  • データの収集、保護、データの保持に関するメッシュ全体のプライバシー ポリシーを推奨します。
  • データ スチュワードがポリシーについて把握し、ポリシーにアクセスできるようにします。
  • 必要に応じて最新のデータ プライバシー規制について通知し、コンサルトします。
  • 必要に応じてセキュリティに関する質問を通知し、コンサルトします。
  • 内部監査を実施し、リスク計画と制御計画に関する定期的なレポートを共有します。

法務 SME

セキュリティ SME

データ プライバシー SME
  • ポリシーのプライバシー規制が最新に保たれている。
  • データ プロデューサーにポリシーの変更がタイムリーに通知される。
  • 公開されているすべてのデータ プロダクトについて、ポリシーの遵守状況に関するタイムリーなレポートを経営陣が定期的に受け取る。

データ スチュワード(各ドメイン内)
  • データ ガバナンスのスペシャリストによって作成されたポリシーをコード化します。
  • 組織がデータ プロダクト、データリソース、データ属性に検出やプライバシー関連のメタデータのアノテーションを付けるために使用する分類を定義して更新します。
  • それぞれのドメイン内外のさまざまなステークホルダーと連携します。
  • ドメイン内のデータ プロダクトが組織のメタデータ標準とプライバシー ポリシーを遵守していることを確認します。
  • データ プラットフォーム機能の設計と優先順位付けの方法について、データ ガバナンス エンジニアにガイダンスを提供します。

データ アーキテクチャ

データ スチュワードシップ
  • ドメイン内のすべてのデータ プロダクトに必要なメタデータが作成されており、ドメイン内のデータ プロダクトが正確に記述されている。
  • セルフサービスのデータ インフラストラクチャ プラットフォーム チームが、データ プロダクトのメタデータ アノテーション、ポリシーの作成、検証を自動化する適切なツールを構築する。

データ ガバナンス エンジニア
  • すべてのデータドメインで使用できるデータ アノテーションを自動生成するツールを開発し、それらのアノテーションをポリシーの適用に使用します。
  • 問題が見つかった場合にアノテーションとアラートの整合性を確認するモニタリングを実装します。
  • アラート、レポート、ダッシュボードを実装して、組織内の従業員にデータ プロダクトのステータスを確実に通知します。

ソフトウェア工学
  • データ ガバナンスのアノテーションが自動的に検証される。
  • データ プロダクトはデータ ガバナンス ポリシーを遵守しています。
  • データ プロダクトの違反がタイムリーに検出される。

一元的なセルフサービス データ インフラストラクチャのプラットフォーム チーム

セルフサービスのデータ インフラストラクチャ プラットフォーム チームまたは単にデータ プラットフォーム チームは、一連のデータ インフラストラクチャ コンポーネントの作成を担当します。分散データドメイン チームは、これらのコンポーネントを使用してデータ プロダクトを構築し、デプロイします。またデータ プラットフォーム チームは、ベスト プラクティスを推進し、新しいテクノロジーを導入する際に分散しているチームの認知負荷の軽減に役立つツールと手法を紹介します。

プラットフォーム インフラストラクチャはグローバルなオブザーバビリティ、計測、コンプライアンスの自動化のための運用ツールと簡単に統合できる必要があります。また分散型チームを成功に導くために、そのような統合を容易にできるようにする必要があります。

データ プラットフォーム チームには、分散ドメインチームと基盤となるインフラストラクチャ チームと共有する責任モデルがあります。このモデルは、プラットフォームの利用者に期待される責任と、データ プラットフォーム チームがサポートするプラットフォーム コンポーネントを示します。

データ プラットフォーム自体が内部プロダクトであるため、すべてのユースケースがサポートされているわけではありません。データ プラットフォーム チームは代わりに、優先順位の高いロードマップに従って新しいサービスと機能を継続的にリリースします。

データ プラットフォーム チームは、開発中の標準のコンポーネント セットを用意している場合があります。ただしデータ プラットフォームが提供するニーズがチームのニーズと一致しない場合、データドメイン チームは別の固有のコンポーネント セットを使用する可能性があります。データドメイン チームが別のアプローチを選択する場合は、チームが構築して維持するプラットフォーム インフラストラクチャが、セキュリティとデータ ガバナンスに関する組織全体のポリシーとガードレールを遵守していることを確認する必要があります。中央データ プラットフォーム チームの外部で開発されたデータ プラットフォーム インフラストラクチャの場合、データ プラットフォーム チームは、共同投資するか、独自のエンジニアをドメインチームに組み込みます。データ プラットフォーム チームがエンジニアの共同投資を選択するか、エンジニアを組み込むかは、組織にとってのデータドメイン プラットフォーム インフラストラクチャの戦略的重要性によって決まります。組織はデータドメイン チームによるインフラストラクチャの開発に常に関与することで、将来の再利用に向けて開発中の新しいプラットフォーム インフラストラクチャ コンポーネントを再パッケージ化するために必要な調整と技術的な専門知識を提供できます。

データ メッシュのスケールアップについて関係者からの承認を得ることを主な目的としている場合は、データメッシュの作成の初期段階で自律性を制限することが必要な場合があります。ただし自律性を制限すると、中央データ プラットフォーム チームにボトルネックが発生するリスクがあります。このボトルネックがデータメッシュのスケーリングを妨げる可能性があります。そのため、一元化に関する決定は慎重に行う必要があります。データ プロデューサーにとって、限られた利用可能なオプション セットから技術的な選択を行うほうが、自分で無制限のオプション リストを評価して選択するよりも望ましい場合があります。データ プロデューサーの自律性を促進することは、管理されていないテクノロジー環境を構築することではありません。選択の自由と標準化の適切なバランスを取り、コンプライアンスとプラットフォームの導入を促進することが目標になります。

最後に、優れたデータ プラットフォーム チームは、社内の他のメンバーに教育やベスト プラクティスを提供する中心的な情報源となります。中央データ プラットフォーム チームに推奨される、特に影響の大きいアクティビティは次のとおりです。

  • 新しい機能プロジェクトの定期的なアーキテクチャ設計のレビューを促進し、開発チーム全体に共通の開発方法を提案する。
  • 知識と経験を共有し、共同でベスト プラクティスとアーキテクチャ ガイドラインを定義する。
  • エンジニアが適切なツールを導入して、コードの問題やバグ、パフォーマンスの低下などの一般的な落とし穴を検証、チェックできるようにする。
  • 開発チームが内部ツールのニーズに対する要件を明確にできるように、内部のハッカソンを開催する。

中央データ プラットフォーム チームの役割と責任の例を次に示します。

役割 責務
必要なスキル
求めている結果

データ プラットフォーム プロダクト オーナー
  • データ インフラストラクチャとソリューションのエコシステムを構築し、分散したチームがデータ プロダクトの構築を支援します。導入への技術的な障壁を低減し、ガバナンスを組み込み、データ インフラストラクチャの技術的負債を最小限に抑えます。
  • リーダー、データドメイン オーナー、データ ガバナンス チーム、テクノロジー プラットフォームのオーナーと連携して、データ プラットフォームの戦略とロードマップを策定します。

データ戦略と運用

プロダクト管理

関係者の管理
  • 適切に動作するデータ プロダクトのエコシステムを確立します。
  • 本番環境には膨大な数のデータ プロダクトが存在します。
  • データ プロダクトのリリースにより、最小実装製品化までの時間と本番環境用製品化までの時間が短縮されます。
  • データ プロデューサーとデータ コンシューマの最も一般的なニーズに対応できるように、一般化されたインフラストラクチャとコンポーネントのポートフォリオが用意される。
  • データ プロデューサーとデータ コンシューマの満足度スコアが高い。

データ プラットフォーム エンジニア
  • テンプレート、デプロイ可能なアーキテクチャ ブループリント、デベロッパー ガイド、その他のドキュメントを使用して、データの取り込み、保存、処理、消費のための再利用可能なセルフサービス データ インフラストラクチャとソリューションを作成します。また Terraform テンプレート、データ パイプライン テンプレート、コンテナ テンプレート、オーケストレーション ツールも作成します。
  • データ共有、パイプラインのオーケストレーション、ロギングとモニタリング、データ ガバナンス、ガードレールを組み込んだ継続的インテグレーションと継続的デプロイメント(CI / CD)、セキュリティとコンプライアンスのレポート、FinOps のレポートなど、部門横断的な懸念事項に対するプロセスを標準化するための中央データサービスとフレームワークを開発し、維持する。

データ エンジニアリング

ソフトウェア エンジニアリング
  • データ プロデューサーがデータの取り込み、保存、処理、キュレーション、共有を行うための標準化された再利用可能なインフラストラクチャ コンポーネントとソリューション、そして必要なドキュメントが用意されている。
  • コンポーネント、ソリューション、エンドユーザー ドキュメントのリリースはロードマップに沿って行われる。
  • ユーザーから高い顧客満足度が寄せられる。
  • データメッシュ内のすべての関数に対して堅牢な共有サービスがある。
  • 共有サービスの稼働時間が長い。
  • サポート応答時間が短い。

プラットフォームとセキュリティ エンジニア(ネットワーキングやセキュリティなど、一元管理された IT チームの代表者。データ プラットフォーム チームに組み込まれています)
  • データ プラットフォームの抽象化が、企業全体のテクノロジー フレームワークと意思決定に沿ったものになるようにします。
  • データ プラットフォーム配信に必要なテクノロジー ソリューションとサービスをコアチームで構築することで、エンジニアリング活動をサポートします。

インフラストラクチャ エンジニアリング

ソフトウェア エンジニアリング
  • プラットフォーム インフラストラクチャ コンポーネントは、データ プラットフォーム用に開発されています。
  • コンポーネント、ソリューション、エンドユーザー ドキュメントのリリースはロードマップに沿って行われる。
  • 中央データ プラットフォーム エンジニアから高い顧客満足度が寄せられる。
  • データ プラットフォームで使用されるコンポーネント(ロギングなど)のインフラストラクチャ プラットフォームの健全性が改善される。
  • 基盤となるテクノロジー コンポーネントの稼働時間が長い。
  • データ プラットフォーム エンジニアに問題があった場合のサポートの応答時間が短くなる。

エンタープライズ アーキテクト
  • データメッシュとデータ プラットフォームのアーキテクチャを企業全体のテクノロジーおよびデータ戦略と一致させます。
  • データ プラットフォームとデータ プロダクト アーキテクチャの両方について、アドバイス、設計権限、保証を提供し、エンタープライズ レベルの戦略とベスト プラクティスを確実に遵守します。

データ アーキテクチャ

ソリューションのイテレーションと問題解決

コンセンサスの構築
  • 十分な数のデータ プロダクトを含む優れたエコシステムが構築されており、実現可能な最小限のプロダクトの作成と本番環境へのリリースにかかる時間を短縮できる。
  • アーキテクチャ標準は、メタデータ管理とデータ共有アーキテクチャの共通基準の確立など、重要なデータ ジャーニー向けに確立されている。

データメッシュに関するその他の考慮事項

分析データ プラットフォームのアーキテクチャには複数のオプションがあり、オプションごとに前提条件が異なります。各データメッシュ アーキテクチャを有効にするには、このセクションで説明するベスト プラクティスに従うことをおすすめします。

プラットフォームの資金調達

ブログ投稿「If you want to transform start with finance」で説明されているように、プラットフォームは完了していません。常に優先順位の高いロードマップに基づいて動作しています。したがって、プラットフォームは固定エンドポイントを持つプロジェクトではなく、プロダクトとして資金を調達する必要があります。

データメッシュの最初の導入者が費用を負担します。通常、費用はデータメッシュを開始する最初のデータドメインを形成する企業と、一般に中央データ プラットフォーム チームを擁する中央技術チームとで分担されます。

財務チームが中央プラットフォームの資金調達を承認するよう説得するには、一元化されたプラットフォームの価値が徐々に実現されることを示すビジネスケースを作成することをおすすめします。その価値は個々のデリバリー チームに同じコンポーネントを再実装することで得られます。

データメッシュに必要な最小限のプラットフォームを定義する

データメッシュに実用最小限のプラットフォームを定義するために、1 つ以上のビジネスケースで試験運用とイテレーションを行うことをおすすめします。試験運用で必要なユースケースと、結果として得られるデータ プロダクトを採用する準備ができているコンシューマが存在するユースケースを見つけます。ユースケースではデータ プロダクトを開発するための資金がすでにあるはずですが、技術チームからの情報提供が必要になるはずです。

試験運用を実装するチームが、データメッシュの運用モデルを次のように理解していることを確認してください。

  • バックログ、サポート、メンテナンスはビジネス(データ プロデューサー チーム)が行う。
  • 中央チームはセルフサービス パターンを定義し、ビジネスによるデータ プロダクトの構築を支援するが、完了したデータ プロダクトの実行と所有を企業に任せる。
  • 主な目標は事業運営モデル(ドメインによる本番環境、ドメインでの使用)を証明することである。2 つ目の目標は、技術的な運用モデル(中央チームが開発したセルフサービス パターン)を証明することである。
  • プラットフォーム チームのリソースは限られているため、トランクチームとブランチチーム モデルを使用して知識をプールし、専用のプラットフォーム サービスとプロダクトの開発を可能にする。

また、次のことをおすすめします。

  • サービスや機能を有機的に進化させるのではなく、ロードマップを計画する。
  • 取り込み、保存、処理、分析、ML にわたる実用最小限のプラットフォーム機能を定義する。
  • データ ガバナンスを個別のワークストリームとしてではなく、すべてのステップに組み込む。
  • ガバナンス、プラットフォーム、バリュー ストリーム、チェンジ マネジメント全体で最小限の機能を実装する。最小限の機能とはビジネスケースの 80% を満たす機能。

データメッシュと既存のデータ プラットフォームとの共存を計画する

データメッシュを実装する多くの組織には、データレイク、データ ウェアハウス、またはその両方の組み合わせなどの既存のデータ プラットフォームがすでに存在する可能性があります。データメッシュを実装する前に、データメッシュの成長に合わせて既存のデータ プラットフォームを進化させる方法を計画する必要があります。

このような組織は、次のような要因を考慮する必要があります。

  • データメッシュで最も効果的なデータリソース。
  • 既存のデータ プラットフォーム内に留める必要があるアセット。
  • アセットを移動する必要があるかどうか、既存のプラットフォームで維持したままデータメッシュに参加できるかどうか。

次のステップ