記事

データメッシュとそれをつなぎ合わせる糸

エンタープライズ・データ・アーキテクチャへのアプローチとして、データメッシュが注目を集めています。素晴らしいアイデアを体現している一方で、実際に適用する際に失われがちな原則がいつくかあります。

Kevin Lewis
Kevin Lewis
2021年4月10日 10 分で読める
データメッシュとデータアーキテクチャ
エンタープライズ・データ・アーキテクチャのアプローチとしてデータメッシュは着実に注目を集めています。素晴らしいアイディアを体現している一方で、実際に適用しようとすると、いくつかの重要な原則を見失う可能性があります。

データメッシュの基本的な考え方は、企業のデータ・アーキテクチャをビジネス指向の論理的なドメインで構成し、各ドメインの「所有者」に責任を分散させることで実現するというものです。これは、技術的なアーキテクチャ内の層(取り込み、データ管理、アクセスなど)ごとにチームを編成し、基本的に、中央集中的に管理される従来のアプローチとは対照的です。

企業やそのデータ資産、またプロセスがますます複雑化する中、その複雑さを管理する方法を確立することは非常に理にかなっています。そして、各ドメイン (ビジネスプロセス、データ対象など) に最も精通している人にできるだけ多くの責任を負わせることが、そのドメインに関連するソリューション要件に適切な専門知識と経験を一致させるための最良の方法です。

ここまでは良しとしましょう。

しかし、データメッシュの問題点、というよりも、データメッシュが複数の組織で最初に導入された方法の問題点は、複雑さを軽減し、責任を分散させようとする善意の努力の中で、集中化の良い面の多くが失われてしまうことです。高度に調整され部門間を超えたクロスファンクショナルな能力が、過度の集中化と管理不能な複雑さに流されてしまうのです。

このような事態を避けるためには、データのリーダーは、データメッシュの理念を実践する際に、今もなお有効で、注意を要する、いくつかの重要な原則を忘れないようにしなければなりません。

成功の鍵を握るのは、今も昔も、資金力のあるビジネスの取り組みに合わせることです私は今までに、次のような場面に何度も遭遇してきました。それは、データメッシュのアプローチを採用しようとして、データガバナンスの中心となる組織がデータランドスケープをドメインと名付けて分割し、各ドメインにデータ所有者を割り当てて、そのドメインの計画と実装をリードするよう、「さあ、頑張れ!」と言っているような状況です。その結果は、お察しの通りです。

取り組みを正当化するためのビジネス推進要因、ドメイン間の作業範囲、実装要素の優先順位を適切に調整することなく、各データ所有者は「重要」と考えるデータに基づいて、思いつきのようにランダムな方法で実装の優先順位を決めました。各ドメイン内のどのデータ要素ももれなく対象範囲内で、発生したデータの問題はすべて詳細な分析と解決の対象となりました。先を見越した積極的で綿密な調整が行われなければ、誰も納得できるような合理的なスケジュールで、各ドメインが部門間のビジネスの取り組みをサポートできるようにすることはできませんでした。その結果、プロジェクトは長期化し、コストもかさみ、導入したデータの活用も限られたものになってしまいました。また、多くのアプリケーションプロジェクトに携わる人々が、必要なデータの収集と管理を自分たちで行わなければならないことに不満を感じていました。

アーキテクチャへのアプローチは、ビジネスの取り組みから始めなければなりません。特に、企業にとって重要であると認識されていて、資金が提供されている、部門間のビジネスの取り組みから始めなければなりません。ここで言う「データイニシアチブ」とは、「データマーケットプレイス」や「真実の単一バージョン」といった名称のものではありません(これらの概念はビジネスの取り組みをサポートする上で有用です)。その代わりに、オムニチャネルのカスタマーエクスペリエンス、サプライチェーンの最適化、製造の自動化などの取り組みを推進力とすべきです。実際のビジネスの取り組みを推進力とすることで、各データ所有者は、近い将来のビジネスニーズをサポートするために、自分のドメイン内のデータを提供することに合意することができます。このアプローチでは、段階的に提供されるデータの焦点が大幅に絞り込まれ、ドメイン間の明確なスコープメカニズムが提供されます。提供されるすべての要素は、戦略的価値を持つと同時に、一貫性のあるデータにつながります。

大量のデータ、複雑なデータ、頻繁に結合されるデータ、頻繁に再利用されるデータは、同じデータベースに保存する必要があります。データウェアハウスの概念は、少なくとも部分的には技術的な制限への対応であることを認識しましょう。もし、すべての現在および過去のデータをトランザクションシステム(POSシステムや購買システムなど)に保持し、これらのシステムの上に「仮想化層」を構築することが可能であれば、エンドユーザーやアプリケーションは、これらのシステム内およびシステム間でデータに簡単かつシームレスにアクセスでき、トランザクションおよび分析ワークロードの両方で優れたパフォーマンスを得ることができます。その場合は、データウェアハウスは存在しません。しかし、データウェアハウス自体は存在しており、その数は増え続けています。実際、専用のデータウェアハウス技術はこれまで以上に広く導入されています。それはなぜでしょうか。それは、複数のデータ領域にリンクされた、複雑で、頻繁に結合され、頻繁に再利用されるデータ (これらのデータは、少なくとも技術的な能力と同じくらいの速さで増加しています) を、物理的にデータベースに格納することなく、良好なパフォーマンスを得る方法がまだ他にないからです。

分散された粒度の細かいドメイン間でデータをオンザフライでリアルタイムに仮想的にリンクすることは、一部のアプリケーションでは有効かもしれませんが、データウェアハウスのワークロードでは効果的なパフォーマンスとスケーラビリティを実現することはできません。

だからといって、企業の中核となるすべてのデータを1 つの巨大なデータウェアハウスに保存しなければならない訳ではありません。たとえば、複数の独立した部署を持つ企業では、各部署が独自のデータウェアハウスを持ち、必要なときだけ特定のユースケースのためにデータウェアハウス間でデータをリンクしたり結合したりする方が適している場合があります。大規模で現代的な企業が必要とするデータウェアハウスの数は、複数の場合がありますが、ゼロであることはないでしょう。

組織内のデータウェアハウスの役割は、組織の性質や、サポートすべき部門間でのビジネスの取り組みの数や種類に基づいて、十分に検討する必要があります。

データは、ドメイン間でセマンティックにリンクされていなければなりません。中核となるエンタープライズデータを統合することは、ビジネスの取り組みのニーズを満たし、取り組みにおけるデータ共有を可能にするために、コアなデータの統合が常に不可欠です。また、最近のビジネスの取り組みでは、これまで以上にドメイン間の統合の必要性が高まっています。現代のビジネスで必要とされるデータの一貫性と部門間での共有を提供するためには、データを技術的にリンクさせるだけでなく、セマンティックにリンクさせるという大変な作業が必要です。

統合はテクノロジーによって可能になる部分もありますが、技術的な複雑さを各ドメイン内に隠し、ドメイン間でのインターフェイスでのコミュニケーションを簡単にするだけでは、データ自体のドメイン間での一貫性を確保することはできません。たとえば、オムニチャネルを実現するためには、当然のことながら、タッチポイントや販売チャネルを通して個々の顧客に関する情報をリンクさせる必要があります。また、サプライチェーンを可視性するためには、サプライチェーン上のさまざまなポイントをつなぐ一貫した製品データが必要です。このようなドメイン間の一貫性は、積極的で高度に調整された、ビジネス主導のデータガバナンス・プロセスがなければ不可能です。エンタープライズ・データ管理の経験を持つ人なら誰でも知っているように、同じデータドメインが複数のシステムに存在し、異なる構造、異なるデータ値、異なる定義、異なる階層やその他のグループ化などが存在します。データ所有者がドメイン間でコミュニケーションを取るためのフォーラムを備えたデータカタログといつくかのガイドラインだけでは十分ではありません。

データ管理ツールをうまく活用し、ドメインをまたいだデータガバナンスを効果的に実施するには、専門的な知識が必要です。データ管理ツールが非常に使いやすくなり、人工知能によって効果的にサポートされるようになれば、専門家でなくても、生のデータセットにツールを向けるだけで、意味を推測し、構造を定義し、データ変換や統合のためのワークフローを開発できるようになる日が来るかもしれません。しかし、その日はまだ来ていません。また、たとえそのような日が来たとしても、どんなツールであっても、企業にとってより大きな利益になる場合でも、同じデータを様々な目的で使用するツールに企業が完全に納得することはないでしょう。データ管理のエキスパートは、データガバナンスやスチュワードシップと協力して、導入時時に発生する技術的および非技術的な問題の解決を支援しなければなりません。

各ドメインチームにガイダンスやツールを提供するだけでは十分ではありません。有能な専門家は、各ドメインの舞台裏で、データ品質プロセス、データ構造設計、データ照合、アーキテクチャのその他の要素の開発を支援しなければなりません。それは、目先のアプリケーションや分析のユースケースに対応するだけでなく、スケーラビリティと拡張性を備えており、新たなデータニーズに対応して基盤を強化しても、大幅な手直しや再設計をすることなく、新たな要件に対応することができる方法で行う必要があります。これを実現するには、専門的なトレーニングと豊富な経験を必要とします。

結論
これらの原則と、データメッシュが推進することと推進していないことを比較するのではなく、分散化を重視するあまりこれらのコンセプトを放棄してしまう可能性が高いことを指摘しておきます。データメッシュは、実際には、高度に調整されたドメイン間を超えたガバナンスプログラムを提唱していますが、様々な理由で見過ごされがちです。得に、多くの企業がこれをクロスドメインの調整という困難な作業を回避する機会と捉えていることが挙げられます。それはまるで、アジャイル手法がしばしば誤解され、誤って使用されて、本来であれば時代を超えた不朽なプログラムやプロジェクト管理原則であるのに、それを放棄してしまったのと同じことです。

もしあなたが、データメッシュに興味を持っている多くの企業データの専門家の一人であるならば、あるいはデータメッシュのアイディアを組織に適用し始めている場合は、メッシュをつなぎ合わせるために必要な縫い目を適用し、ドメイン間での活動を調整するために必要なプロ意識を失わないようにしてください。
Tags

Kevin Lewis について

Kevin M Lewis is a Director of Data and Architecture Strategy with Teradata Corporation. Kevin shares best practices across all major industries, helping clients transform and modernize data and analytics programs including organization, process, and architecture. The practice advocates strategies that deliver value quickly while simultaneously contributing to a coherent ecosystem with every project.
  Kevin Lewisの投稿一覧はこちら

知っている人に滞在

Teradataのブログを購読して、毎週あなたに配信されるインサイトを入手する



テラデータはソリューションやセミナーに関する最新情報をメールにてご案内する場合があります。 なお、お送りするメールにあるリンクからいつでも配信停止できます。 以上をご理解・ご同意いただける場合には「はい」を選択ください。

テラデータはお客様の個人情報を、Teradata Global Privacy Statementに従って適切に管理します。