DX(デジタルトランスフォーメーション)推進コンサルティング 株式会社アイ・ティ・イノベーション

今回からエンタープライズレベルでのデータ（統合）アーキテクチャをテーマに数回に渡って連載したい。理由は、近年EAにおけるデータアーキテクチャの悩みの１つに、いわゆるデータモデリング問題だけでなく、システムの規模拡大とともに物理DBの配置とデータ連携のデザインをどうしたものか？があるからだ。具体的には、これからの時代に備えて大規模かつ疎結合*を実現する”HUBアーキテクチヤ”を取り上げてみたい。連載の初回は、本アーキテクチヤの持つ本来的メリットと、その基本構造についてお話したい。

まず図1を見ていただきたい。図の例はアプリA～アプリFまでの6つのシステム間で何らかのデータのやりとりが発生するものとする。インターフェース（以下I/Fと略）のルート数は、左側のHUBを介さない場合には組み合わせ合計15通り存在し得る。一方で右側のHUB経由の場合にはルート数はアプリの数分の6通りということになる。ピアtoピアはHUB経由の2.5倍のルート管理が理論上発生する。アプリの数が8個になれば28:8（3.5倍）、10個になれば45:10（4.5倍）とその比率も増えて行く。言わずもがなHUBを経由しないピアtoピアのままの連携はいわゆるスパゲッティ化の元凶となる。

そして、このHUB経由が成り立つためには、図2にあるようにHUB上のI/Fレコードはアプリ非依存で中立な標準形式であることが条件となる。そしてこの標準形式に歩み寄る為に、HUBの両側に変換機能が存在する。変換機能にはコード変換やフォーマット変換等があり、それらは他の類似したI/Fにおいても再利用可能である。システムのいたる所に同類の変換プロセスを作成し、いたずらにコード量を増やすことはエンタープライズ全体でのメンテナビリティの悪化をもたらす。

次にこのHUB内のI/Fレコードの種類であるが、レコードの汎化度合いがポイントとなる。通常はマスタレコードのケースはエンティティ（“取引先“と“品目”など）毎に個別となるが、トランザクションレコードは実績系においてはバックナンバー2014.3.25「トランザクションHUB」にあるようにかなりの汎化が可能である。SCMでの“受払“、会計での”仕訳“、人事での”異動“などがこれに該当する。また、トランザクションにおいても指図（メッセージ）系のレコードは汎化が難しく個別のものとなる。
さらにこのHUB内のI/Fの連携形態には大きく２種類存在する。１つは実DBを介した最も疎結合なI/Fであり、DBへの書き込みとDBからの読み出しを非同期にするデータベースHUBである。本ブログに度々登場するマスタHUBやトランザクションHUBがこれに該当する。もう1つはDBが実体を持たない”仮想DB”のケースであり実DBへの読み書きがない分だけ即時性が高い疎結合I/Fである。

以上がHUBアーキテクチャのメリットとその基本的メカニズムである。どうであろうか、物理的には目に見えないITアーキテクチャであるが、このように図表現してみるとHUBアーキテクチャのメリットがいかなるものか一目瞭然である。ＩＴアーキテクチャはシンプルかつシンメトリーで美しいほうが良い。逆に図やモデルに現そうとしても条件分岐や例外が多い歪（いびつ）な形になってしまう場合はダメなアーキテクチャという事になる。次回は、このHUBアーキテクチャの進化形についてお話したい。

※疎結合とは・・・情報システムにおいて、二つのシステムが緩やかに結びついた状態。システムどうしが標準的なインターフェースに基づいて接続されているため，一方が他方を容易に取り替えられる状態をいう。⇔ （反）密結合