今回は“インターオペラビリティ(相互接続性)”について書いてみたい。前回ブログの“グループ経営とITアーキテクチャ“や、”2014.8.27グローバル対応モデル“など過去のブログに度々登場している「異なるモデル間の変換」について掘り下げてみる。
世の中の開発方法論(特にウォーターフォール)には、開発工程の前半で“スコープ(システム化の対象範囲)を決めなさい“と書かれている。ご存じの通りこのスコーピング作業は後々の開発の成否を決する重要なポイントとなる。では、スコープから除外された部分はどうなるのだろうか? 世の中のシステムは、(宇宙がそうであるように)どこまで行ってもスコープの外側が存在する。例えば、単体⇔グループ、自社⇔他社、自国⇔他国などである。外部システムとの間には、人間系も含めてインターフェース・システムが介在する。そして、最近のシステムのデータ品質問題の多くはこのインターフェースに起因する。理由は近年のシステム拡大で、コンテキスト(文脈、前提)の異なる2つのシステム連携が頻発しているからである。(図1)
20世紀の企業システムは、可能な限りスコープを広く設定しその中でデータ一貫性を保証したシステムにすることが良しとされた(ERPによる密結合型が最たる物)。しかし今世紀に入り、そのスコープが1法人を越えグループ経営やM&Aに対応せざるを得なくなる。また、社内システム自体も複雑化、巨大化し、もはやビッグバンによる全面再構築が不可能となる等、ここへきてモノコック(一体成型)構造では立ち行かなくなってきた。
前置きが長くなったが、このような背景により企業システムのスコープ拡大への対応には、“統一”の名のもとに何年もかけて同一のシステムにすることよりも、異なるシステムの素早い相互接続を可能にする“インターオペラビリティ”が今日重要視される。膨大なコストと時間をかける“統一”がどれだけROIに貢献したのかという経営者の疑問に答えられないからだ。
では異なるシステム間のインターフェースを肯定的に捉えるならば、それはどのように設計され、どのように管理されるのが良いのだろうか。ITアーキテクチャ主導に考えてみたい。まずはDA(データ・アーキテクチャ)の観点から、意味が同様でコード形式の異なる2つのエンティティの間には関連エンティティ(変換テーブル)を見出すことが出来る。1:1の単純変換ができないケースでも何らかの導出ロジックで両者のデータモデルを繋ぐ変換プロセスを設計する。そしてAA(アプリケーション・アーキテクチャ)の観点からは、上記の変換プロセスを共通コンポーネントとして一元管理することを考えたい。変換プロセスはいたる所に散在させず、1か所に配置し“変換プロセス”の品質をとことん保証する。また、これらのデータ・プロセスに関する定義情報は、メタデータとして“REPOSITORY”に格納し“定義の再利用”を図ることが好ましい。
より具体的には、この“変換プロセス”はバックナンバー“2014.2.26 適材適所(その2)”のエンタープライズHUB内の、データベースを挟んだインバウンドかアウトバウンドに配置して一貫性を保証すべきである。このことは“データ中心”のセオリーに合致する。今後のエンタープライズシステムに関するソフトウエア市場では、このように異なるシステム同志をモデル変換&連携するための実装ツールが、かつてのEAIやETLツールの発展型として、より脚光を浴びてくると思われる。 さらに、データHUBの変換機能を持ってすれば、スコープが異なる複数のシステム群同志が、このデータHUBを介して相互接続が実現可能となり、自律分散かつ拡張性に富んだ巨大なネットワーク型システムを形成することも可能である。(図2) インターオペラビリティに富んだシステムは、モノコックなシステムより堅牢性は甘いかもしれないが、拡張性・柔軟性には長けている。堅牢性と柔軟性を上手く組み合わせたハイブリッドなシステムアーキテクチャがアジャイル経営を必要とする今日、求められている。