» 【119号】フェデレーション・アーキテクチャ

株式会社データ総研 データ総研のオンサイト教育
製品案内 DMBOK ITコンサルティングサービス ITコンサルティング事例 紹介セミナー 教育コース 技術情報 DRIブログ 会社概要
技術情報
【119号】フェデレーション・アーキテクチャ

今月は118号に続いて、114号の「リレーショナルモデルの問題点」の、
「③DBのスコープの設定について言及がない」の対策を考えました。フェデレー
ション・アーキテクチャの提案です。

■当該対象システムのDBだけ考えた
DBのスコープの設定について言及がないとき、DBのスコープはどのようにし
て決められたのでしょうか。ユーザ部門の強い要望に基づいて、企画が取り上
げ、システム化が決まり、これをサポートすべくDBの大きさが決まっていく。
これが今までのDBのスコープ決定の、最も一般的スタイルではなかったでしょ
うか。
担当者は当該システム/DBだけが念頭にあり、これを如何に成功裏に開発す
るかを考えます。これが他システムとどのような関係にあるべきかについては、
多少気になるとしても、作り上げてから考えよう。それは今自分に課せられた
課題ではない。こうして現在の多くの孤島システムができてきたのではないで
しょうか。特に受託専門のSIerは、受託案件のQCDに注力して、他シス
テムとの関連については目をつぶらざるを得ません。
■天動説から地動説へ
したがって、当該システムの位置づけを考えるのはユーザ企業の企画担当者以
外にはありません。しかし人間は誰しも、はじめは「当該対象は何か、その内
容」までは考えても「当該対象の位置づけ」までは考えにくいもののように思
われます。赤ん坊は自分を認識し、次に母親や家族を認識しますが、自分の位
置づけまではできません。自分中心の世界観、天動説的世界観からスタートし
ます。成長とともに自分を相対化し、地動説的世界観を持つようになります。
地球は火星とともに太陽の周りを回る仲間なのだと。すなわち当該開発対象シ
ステム/DBの位置づけ、他システム/DBとのあるべき関係を考えるには、
それなりの経験を必要とするものかと思われます。
しかし、この地動説への転換は、実は2回目だともいえます。自分の作るプロ
グラム中心の考え方から、これを相対化しDB中心のシステムへ転換した、P
OAからDOAへの転換がすでにあったからです。DBという通信場を共有す
ることによって、プログラム間のデータ流通が自由になりました。同じメカニ
ズムを、1ランク上の粒度の、プログラムの集合からなるシステム間に応用す
れば孤島システムは解消するはずです。その意味ではDOAの本質は、自己中
心の天動説を脱却して地動説に転換することだともいえます。このときのシス
テム間のコミュニケーション問題を解消するDB通信場を、筆者はEDW
(Enterprise DWH)とかRDW(Realtime DWH )とか呼んでいます。
■フェデレーション・アーキテクチャ
この考え方のベースには、実は全社にはn個のアプリDBが存在し、その上に
これを統括するインフラDBがあるというフェデレーション・アーキテクチャ
−個別アプリDBをロウレベルDB、インフラDBをハイレベルDBと呼ぶ−
が前提になっています。すなわち、「個々のDBの大きさ/スコープは有限で
ある、適度の大きさをもつ、だからこれを統括する上位のDBが必要である」
という前提です。初期のDOAやERPにはあったかに見えますが、「データ
の流通範囲に応じて、1個のDBのスコープをどんどん拡大すればよい」とは
考えていません。「DBはデータ標準化の単位、文化圏として管理しなければ
ならない、したがって大きさは有限になる」と考えるからです。
統括する上位のインフラDB(ハイレベルDB)には3種類、すなわち
 ・リポジトリ(メタDB):システムの構造を規定する(注1)
 ・リソースDB     :各アプリで使用するコード値の標準を規定する
 ・EDW(RDW)   :システム間の通信場を設定する(注2)
があると考えます。したがって、これにアプリDBを考慮するとDBは4種類
あるということができます。
(注1)
これがさらに、業務構造を規定する概念リポジトリ、ソフト構造を規定するソフトウエア
リポジトリ、プラットフォーム構造を規定するプラットフォームリポジトリの3種に分かれる。
(注2)
従来の各種分析のためのDWHはEDWの内容を時系列的に蓄積した参照専用
のものとしてEDWの類と考える。
リポジトリ、およびリソースDBは、システム間のコミュニケーションの基盤
です。筆者の25年を超えるコンサル経験を振り返ってみても、この基盤確立
に成功した会社は、その後の再構築やERP導入においての失敗事例を聞きま
せん。またシステム間の通信場を用意するEDWは、これからの課題ですが、
BPM、SOAを成功裏に支える不可欠の基盤となるはずです。
最近話題のEA(Enterprise Architecture)ではこれを次の4階層
 ・BA(Business Architecture)
 ・DA(Data Architecture)
 ・AA(Application Architecture)
 ・TA(technology Architecture)
に分けて論じられることが多いのですが、上述のDBのスコープはこのDAの
中核を構成するものと考えられます。企業の業務仕様の基礎をDAが規定し、
この上に建物に相当する業務プロセスBAが構築されると見ることができるか
らです。
このようにRDM提案時に言及されなかったDBのスコープは、「通信場を処
理に優先させるDOA」のコンセプトから必然的に導かれるもののはずですが、
これまで多くの孤島システムができてしまったのは大変残念なことでした。一
番大きな原因は、業務仕様を全社的スコープから考える立場の人−CIOやC
EO−の理解や指導が得られなかったことかと思われます。システムの問題は
システム部長に任せておけば済む、といった時代ではなくなっています。なぜ
ならば、それはシェアードサービス、アウトソーシングを含めて、業務の構造
をどうするかにかかわっているからだと思われるからです。話題の”IT
doesn’t matter.” とは「技術でなくマネジメントの問題として考えよ」とい
うことかと思われます。