今回のブログは、今後の企業情報システムがSoRとSoEをどのように両立させてゆくかについて、エンタープライズアーキテクチャの面から迫ってみたい。バックナンバー2016.12.04 では、SoE領域を特別扱いするあまり、SoR領域とのデータ連携が途切れて、さらなるサイロを生み出す危惧について言及した。それでは、この2つの領域を繋ぐデータはどのように連携するのが良いのだろうか。
この課題の解決策でも、従来型システムの時と同様、”Copy&PasteからDB-Shareへのアーキ転換”の考え方は活きてくる。無作為に必要なデータをエンドtoエンドでCopy連携すると従来システムで言うところのスパゲッティ化は免れない。即ち共有マスター、共有トランザクション及び、それらのメタデータを定義したリポジトリーを抱えたエンタープライズ・データHUBを介して、SoRとSoEの異なる領域間を疎結合するのだ。
図1を参照していただきたい。この図は、私が所属するNPO“要求開発アライアンス”の6月例会にて、河野理事が発表した「SoRからSoEへの潮流、そして要求開発の変化」の中の1スライドを引用し手を加えたものであるが、近年私が主張してきたエンタープライズ・データHUBによる疎結合アーキテクチャモデルとその骨子は同様である。河野理事がここに行きついた背景には、やはり一筋縄ではいかない巨大なSoRの再構築の難しさがあったと言う。
私が今回このテーマを取り上げた理由も、基幹系システム(SoR領域)の再構築をひと通り終えないと、その他の領域(情報系を含むSoE領域)に着手してはいけないと思い込んでいるユーザ企業がいることである。確かに全ての基幹系システムの再構築が完了した後に、鮮度、精度の高い全てのデータセットを元に、SoEや情報系を構築するのはいかにもスッキリする。しかしROI(投資対効果)の観点では、SoRの老朽化対応よりもビジネス上の価値をもたらすSoE領域の1システムの方が遥かに急がれるケースも少なくない。
このような局面を打開する仕組みがエンタープライズ・データHUBである。基幹系システムの新旧に関らず、真っ先に企業にとって理想とする“共有データモデル”に従ってHUB上にエンティティを生成し、これをSoR、SoEの各システム間で共有する仕掛けを構築するのだ。まずは現行のレガシーのSoRから取得できる共通データでかなりの再利用は可能である。また、仮に現行SoRからでは捕捉できずに共通DB内のその部分がNull値となっていても、近い将来エントリーシステムが改善されて、そこにデータが埋まった時点で他システムで情報系のSoEでの再利用が可能となる。逆に、エントリー系SoEで新たに取得された(将来共有すべき)データは、ひとまずHUB上の共通DBに連携され、SoRシステムにこれを読み込む機能が備わった時点で、一気通貫する。
図1の全社ベースでのアプリケーション・アーキテクチャは、SoR、SoEの個別アプリケーションの利便性の良否を問わず、共通DBのデータがクリーンになりさえすれば、その直後からアプリ間でのデータ共有ができる。よって、HUBに疎結合された複数システムの同時開発が可能となるわけだ。図上部の吹き出しに、その構築順を記述した。①最初にデータHUB上の共通DBありきである。そして、②SoE領域や情報系へも積極的に取り組みを開始する。この際に、現状の共通DBで足りない部分は個別システム側で補完しても構わない。さらに③基幹系システムの再構築は老朽化のタイムリミット迄に順次再構築すればよい。というシナリオを描くことができる。ちなみに、②③は同時並行で進行しても構わない。
繰り返しになるが、SoRの重たい再構築が、魅力的なSoE領域のアプリケーション開発の足をひっぱることは非常に残念なことである。画期的なパラダイムチェンジをもたらす新たなIT-SEEDSは積極的に享受できるに越したことはない。その為にはSoR領域の完璧を期する必要はなく、早くSoE領域に着手することである。着手すれば、新たな気づきも色々と生ずるに違いない。例えて言うなれば、「教科書のあるページに書かれた内容の1つでも腑に落ちない箇所があると次のページをめくらないといった生真面目さ」は、進化の速いITの世界では、邪魔物以外の何物でもない。可能なかぎり、コンカレントに、アジャイルに何事にもチャレンジすることにつきる。そして、それらが可能なエンタープライズ・アーキテクチャを指向することが得策である。データセントリックなアーキテクチャはプロセスに先んじてデータベースが存在するのだ。