次なるデータプラットフォームの構築：今後の選択肢

私は、次のような図を顧客企業の会議室で何度も見たことがあります。

片側には、使えそうなデータソースがいくつも描いてあります。アプリケーション、データ、形式、所有者はさまざまです。

反対側には、こういったデータの多くを興味深い方法で活用したい重要なビジネスプロセスがあります。

そして、担当チームがそれらを繋ぐ真ん中の部分をどうしようかと思案しています。しかし、これはなかなか困難です。

シンプルな例

ある銀行が富裕層向け「プレミアムカスタマーエクスペリエンス」を提供したいと考えました。ある時点で、当該顧客に関するあらゆる情報を（その形式を問わず）関連付けることで、このサービスを改善できることに気付きました。これはいわゆる「カスタマー360」です。

しかしこれは実現が困難です。というのも、この銀行はフルサービスの金融機関でありポートフォリオが多様だからです。また他組織との協業において、外部のシステムも利用しています。関連付けて有効活用するには、情報があまりにも多種多様なのです。

あるいは医療において、多様なポートフォリオに関する新しい治療法を探しているとします。すべての研究者に、役に立ちそうな関連情報（いろいろな入手先からの）を提供したいのですが、入手先は極めて多岐にわたっています。

また、多数のアプリケーションやシステムに関わる複雑なトランザクションにおいて、不正を発見しなければならないこともあります。

いずれの場合でも、本来関連付けが想定されていなかったデータを関連付けることが強く求められます。

ここでこれらを実現するための方法を探す必要があります。探しはじめるとすぐに、「パターン」および「アンチパターン」（「うまくいくやり方」と「失敗するやり方」）が見えてくるでしょう。

ここで起こりうること

当然のことながら、生データから価値を生み出すには、何らかの作業が必要です。ここで「誰がこの作業をするのか」という最初の疑問が出てきます。関連データの入手先が少なければ（そしてデータの所有者が協力的であれば）、なんとかなるかもしれません。

しかしデータの入手先が多い場合、作業分担を皆にお願いすることは困難です。またそこで構築したアーキテクチャが、新しい環境に素早く対応できない、極めて複雑かつ柔軟性がないものとなる可能性もあります。

こうなると、入手した多様なデータをそのまま全部読み込み、さまざまな方法でこれに価値を加え、利用者が求める形でデータを提供できた方が望ましいと思うでしょう。

ここでデータマート、データウェアハウス、データラボなどが登場するのです。これらの中核には、何らかのデータ管理プラットフォームがあります。

こういった作業は、表データ（列と行）や、きちんと整理された「非構造化」データ（XMLやJSON）に対して行うだけでも十分大変です。

しかし、ちょっと試しに、もっと難しい状況を想定してみましょう。

例えば極めてリッチなデータとして、現実世界で使われているドキュメント、メールと添付ファイル、地理情報がタグ付けされたデータ、研究ノート（構造化データ）、ログやトラッキング、まだ何だかよくわからないけれども面白そうなもの、などを扱わなければならないとします。

重要な分岐点

この時点において、経営陣はアーキテクチャに関していくつかの重要な決定を下さなければなりません。どのようにプラットフォームを構築するのか（特にこれまでよりもリッチなデータを扱う場合）について判断しなければならないのです。

選択肢の1つとしては、絶対に避けられない状況にならない限り、扱いが難しいデータタイプは無視する、というものがあります。これは魅力的です。「難しいものは後回しにしておく」ということです。こういった決断は、当たり前のようによく見られます。

しかしここで、構築側とビジネス側の優先事項が一致しない可能性があります。扱いが困難なデータも重要である（あるいは扱いが困難なデータの方が重要である）ことがよくあるからです。

この場合、将来リッチ/複雑なデータを扱わなければならなくなったら、さまざまなデータ管理コンポーネントを繋ぎ合わせることになります。しかし、そもそもここで想定していたのは「1つのソースだけではなく、複数ソースからの情報を結び付ける」ことでした。

他の経路からこれと同様の状況にたどり着く人もいます。彼らはまず、道具として使えそうな用途特化型のデータベース（通常はオープンソース）を探します。これらは、何らかの結合作業が必要なものです。

これは、「各用途ごとにベストなデータ管理ツールを複数選ぶメリット」の方が、「それらを結合する際のコスト、複雑さ、技術的リスクというデメリット」よりも大きいと判断したということです。このやり方が適切な場合も確かにあるでしょう。

しかし通常は、1つのマルチモデルデータベースで、あらゆるタイプのデータに対してさまざまな価値を付加していく方が、魅力的でしょう。長い時間をかけて完璧な対応策を生み出すことよりも、スピードやアジリティの方が重要だということです。

しかし、重要な考慮事項がもう1つあります。

新しい真実を生み出しているのか

ここで、私がいくつかの業界で目にした大変うまくいっているパターンをご紹介します。

この新しいデータファクトリーが成功した場合、これが新しい「システムオブレコード」（一元化された真実）となり、価値の高い新しいビジネスプロセスをすべて扱えるようになります。

このように成功するためには、拡張性、可用性、復元性、高度なセキュリティなどを備えた、完全な本番稼働プラットフォームを提供しなければならないのです。

ここにおいても、「特化型」と「ユニバーサル（普遍的）」プラットフォームのどちらを選択するのかの判断が重要です。

MarkLogic の登場

このような問題を理解しはじめると、私が MarkLogic サーバー (およびそのエコシステム) に惹かれている理由もわかっていただけるでしょう。

MarkLogic は興味深い問題を極めてユニークな方法で解決します。現時点でも驚くほど多くの場所で採用されていますが、今後その利用実績はさらに拡大していくことでしょう。

みなさまもぜひ使ってみませんか。