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

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

■情報システムがビジネスの足を引っ張る
SCMやWeb2.0のロングテールなど、かつてないIT活用によるビジネス展開が
見られる一方、金がかかる、重大トラブル発生、3K職場、対応が遅いなど、情報
社会の進展にともなう問題が山積しています。

社会が成熟しM&Aが図られますが、時間のかかるシステム統合がビジネスの足
を引っ張るケースも少なくありません。かつてはシステムの全貌が優秀なSEの頭
の中に把握されていましが、今やシステム規模が一回り大きくなり、いかに優秀な
人の頭にも収めきれなくなってしまいました。ITベースの経営が課題とされています
が、次世代の経営者を育てる組織やキャリアパスはどのように用意されているので
しょうか。
■3つの原因
このような問題が発生した原因は何でしょうか。私は、主なものとして次の3
つが挙げられるかと思います。
・個別アプリを機械化して積み上げていけば全社システムができるとの楽観論。
ソフトだから後で調整して連携すればよい。ともかく目先のシステム化を
急ごう。この場合、特にリソース系データ(製品、組織、取引先など)を
個別アプリ担当者に任せた場合が悲惨になります。
・システムは建物のような構造物。一度作ればあとは多少のメンテナンスで
運用できる、といった無機構造物の認識。しかし人間の作るビジネス世界
は変化が激しく、これについていけないと競争に負ける。システムはアマゾン
のジャングルのような有機構造物として把握すべきもののようだ。
・ITの変化が思ったより激しい。今ベストのプラットフォームを選んでソフト
を作っても、思ったより速く陳腐化する。
こうして変更・メンテナンスが頻発し、ドキュメントが実体から離れ、
システムは限られた担当者以外からは暗黙知となってしまいます。
■一番困るのは
この場合一番困るのは変更がアプリケーション内にとどまらず、他のシステム
に飛び火することです。多くは関係者を集め、会議を開いて確認するなどが行
われます。どのようなシステムがあるか、その一覧表はあっても、その間にや
り取りされるデータに関するドキュメントが多くの場合ありません。個別シス
テムの責任者ははっきりしているのですが、アプリ横断のデータに関して責任
者がはっきりしている会社は多くありません。
それはちょうど都市計画無しにできた都市のようです。3車線の道路が急に1
車線になったり、袋小路があったりします。環状線がないため一旦都心に出な
ければならないこともあるでしょう。ローカルな道路の方が先にでき、後から
幹線道路が企画されるような状況です。道路は目に見えるので改善案の合理性
が分かります。しかしシステムの場合は、目に見えないので、“立ち退き”の
折衝も簡単ではありません。
SIerは作れといわれたシステムを作りました。ユーザは自分の使うシステ
ムの仕様を考えました。システム担当は予算を持っているユーザの企画を引き
受けました。情報企画部門はハードやソフトのインフラを整備しました。何が
いけなかったのでしょうか。防衛大臣ではありませんが、「しょうがなかった」
のでしょうか。
■Scrap & Buildはなし
対策を考えなければなりませんが、前提として「もはやScrap & Buildはなし」
といたしましょう。個別アプリケーションがスコープではないからです。
現在動いていてまだ数年は持ちこたえるべきレガシーがあります。
購入したパッケージもあります。新規に開発すべきシステムもあるでしょう。
これらを活用しながら、企業のビジネスニーズに応えていこうという姿勢です。
■通信場先行の設計
ここで思い出すのは、1980年ころからのDBの普及です。アプリケーショ
ンプログラムのコミュニケーションはDB通信場に切り替えられて行きました。
これによってCoddの言うプログラムのデータ独立性が実現され、大規模システ
ムが作りやすくなりました。この場合まずDB通信場を設計し、プログラムは
これに合わせて設計しました。通信場先行の設計です。この考えを一回り大き
いアプリケーションシステムに適用するのです。従来の個別アプリケーション
のためのDB通信場の上に、アプリケーション間の通信場を持つフェデレーシ
ョン・アーキテクチャを前提とし、このハイレベル通信場をアプリケーション
に先行して設計します。まずアプリケーションをつくり動かしてから、それら
の繋ぎを考えるというプロセス先行の従来路線を捨てる必要があります。
データモデリングにより可視化することになりますが、個別アプリケーション
のデータ全部が対象になるわけではありません。アプリケーション横断の限ら
れたメッセージデータ/トランザクションデータを素材に通信場を設計します。
このハイレベルメッセージデータが精度良く収集できれば、データモデリング
作業そのものは難しくありません。
アプリケーション間をつなぐためとしてSOAが騒がれていますが、通信場を
前提としたものになっているのでしょうか。そうでなければn(要素の数)の
自乗のインターフェースが発生しメンテを難しくします。通信場を作るために
標準化が必要になりますが、これによってインターフェースはnの1乗に抑え
られます。私は今、このアプリケーション間の通信場の普及に注力しています
が、残念なことはこれをほしいと思っているお客様が非常に少ないことです。
「お客様のいない商品を作っても仕方がないではないか」といわれますが、
「システム間の問題を自分の問題」と気づいておられる方が、今のところ
少ないだけ、「私の仕事は顧客を創造すること」と考えています。
■ROIはどう考えるべきか
またここで、ROIが障害になるかとも思われます。しかしこれについてはひ
とつの成功事例を思い出します。1986年ころ、ある顧客でリソースデータ
の全社一元化をやらせていただきました。5ヶ月くらい掛けたかと思います。
2、3年間で考えれば小さなROIだったかと思われますが、安定したリソー
スデータをベースにした開発・保守が20年以上続いています。私の皮算用に
すぎませんが、費用の5%を合理化したと考えても、20年間では100倍以
上のROIになったと考えられます。
その顧客から最近PLAN−DBの教育とOJTの仕事を頂きましたが、メン
バーの方から「リソースデータがアプリごとに作られている会社がまだあるの
ですか?」と聞かれました。また実装独立のアプローチが定着していて、「シ
ステム担当の方の議論がITでなくビジネスの核心に迫っていく様子は、他の
顧客では経験しなかったもの」と弊社担当コンサルタントは舌を巻いています。
DOA文化定着の20年の重みを感じた次第でした。
ROIを考える時、期間は一体どう設定すべきなのでしょうか。課題によって
適正な値があるのでしょうが、それはどのようにして決めるべきなのでしょう
か。