前回の記事でデータ連携を行うときの課題と、クラウド型データ連携基盤を使った解決方法を紹介してきました。

今回は「データ連携ハブ」についてハブ空港を例に説明します。

「データ連携ハブ」は、企業の標準データを一時的に蓄積し、複数のシステム間インターフェースを、一カ所で管理するシステムのことです。

「データ連携ハブ」は、欲しいシステムのデータから、欲しいタイミングで取り出すために、企業の標準データを非同期で連携する機能や、コードやフォーマットの変換機能を持ちます。

企業には保有しているデータをビジネスに活用したいニーズがあり、一昔前には企業に散財するデータの活用のために、『セントラルデータベース』という手法が用いられていました。

システムによって使われている、アプリケーションの種類やデータの保存形式、名称、情報の内容はバラバラです。

そのため、『セントラルデータベース』でさまざまなデータを一括して管理するためには、それらの差異を統一化する必要がありました。

このような問題を解決するために、データの統合によってデータ上の項目名の統一を図ったり、重複している項目を削除して整合性を取っています。

蓄積したデータは、原則として永久的にデータを保持するため、データは肥大化し、

また『セントラルデータベース』にアクセスが集中するため、非常に高性能なデータベースが必要となってしまいます。

ですので、最近は『セントラルデータベース』ではなく、企業内にバラバラに存在しているシステムを相互に連携させて、

全体としてビジネスの効率を高めるための『Hub and Spoke型』でデータ連携を解決することに注目が集まっています。

従来のように個々のシステムを1対1で接続するのではなく、システムの中心にハブと呼ばれるデータ連携基盤を置き、

ここに各システムを『ハブ空港』のように繋げることで相互の連携を実現することができます。

また新しいシステムが増えた場合でもハブに繋げるだけで、他のシステムとの連携が可能になります。

『Hub and Spoke型』では疎結合が大きなポイントとなります。

システム間連携を疎結合化することで、対応範囲も極小化でき障害時の対応も迅速化できます。

相手のシステムも知らないとできない蜜連携が、ハブを採用することで、エンジニアの疎結合も出来たりします。

また、単にデータハブのシステムを作れば良いという事ではなく、全社視点で統合されたデータ設計に基づくフォーマットを用意して、周辺システムへ整合の取れたデータを、提供する仕組みにする必要があります。

データハブには、大きく３つの機能が必要となります。

一時的に標準化されたデータを格納する領域を「トピック」と呼ぶ。

トピックに格納されたデータをどのシステム、どのデータを配信したかを管理したりする機能。

トピックに格納されたデータは、任意の取り方で取得でき、全件取得・差分取得など、データの取得方法も選ぶことが可能。

対象すべてのシステムへの配信完了後、データを削除する機能も必要。

ETLと呼ばれる機能。連携元システムからデータを抽出、加工する。

　

下記の図は、データハブをハブ空港としてのイメージでまとめています。

① 各システムから荷物というデータを届けます。全ての荷物が整ってからでもいいですし、定刻になったらデータをハブに届けます。

② 受け取り側のシステムはデータを受け取ります。
荷物が到着次第でも、定刻になったらでも、配送準備が整った順でも任意の形でデータを受け取ることができます。

③ 各システムの受け取り方法は任意に選択できます。
データベース更新やFTPなど選択することができ、この例では飛行機や船など任意の配送方法を選べます。

④ 一定期間、何処のシステムにも届けられない荷物は返却や破棄することができます。

⑤ 荷物が何処にあり、どのシステムに荷物を届けたのかハブを起点として把握することが可能になります。

先ほどご紹介した通り、ハブには3つのハブを管理する仕組みが必要でした。

もちろん通常のETLでもハブを管理する機能を、お客様自身で実装することもできますが、今後増えていくインターフェースに対しスクラッチでハブ機能を実施することは、多くの工数・時間・費用がかかってしまいます。

このようなことから、ハブ機能を保有するデータ連携基盤 製品を採用するのが一番の近道となります。

ここまでご紹介してきましたHub and Spoke機能は、Informaticaのクラウド インテグレーション ハブにて実現できます。

スクラッチで実装するには多くのスキル、手順が必要となりますが、ハブ機能については、GUIのウィザード画面の設定で、誰でも簡単に実装できます。

　

アプリケーションインターフェイスを共通化・標準化するような基盤を採用し、障害時の影響を極小化、エンジニアも疎結合化すること

連携元が連携先の仕様を把握して、相手が受け取りやすい形にする、おもてなしのデータ連携は不要な基盤としていくこと

全社のデータ連携基盤もクラウド化し、24時間365日のサービスを提供することでグローバル展開も視野に入れた基盤としていく必要がある