» 【149号】 情報システムの進化

株式会社データ総研 データ総研のオンサイト教育
製品案内 DMBOK ITコンサルティングサービス ITコンサルティング事例 紹介セミナー 教育コース 技術情報 DRIブログ 会社概要
技術情報
【149号】 情報システムの進化

■POAから第1世代DOAへ
私が会社に入ったときは、コンピュータはありませんでした。石油のある溜分
が、ある温度・圧力でどのように気体・液体に分かれるかを算盤や計算尺でト
ライアル計算する時代でした。処理結果は紙に書かれ、人がこれを手渡す業務
プロセスでした。1965年ころコンピュータが入ったわけですが、コンピュー
タの役割は機械処理であって、処理結果はそれまでどおり、紙に出力され人が
手渡していました。

テープやディスクが登場して、処理結果を電子的にやり取りすることができる
ようになりましたが、人による手渡しを電子化するものでした。構造型DBM
Sが登場して、親子関係や部品展開などが表現できるようになっても、「人→
コンピュータプログラム、紙→DB」と変化しただけで、アーキテクチャは以
前と同じでした。プログラムが主役であり、DBは記憶を担当する脇役のPO
Aアーキテクチャでした。アーキテクチャとは変えにくいもの、いまだに「プ
ログラム=俺」中心の発想から脱皮できない人が見られます。
1972年ころからでしょうか、データモデルが研究され、RDBMSが登場
して、「DBは便利な記憶係というだけではない、ビジネス実態を表現するも
のだ」という認識が生まれました。顧客、商品、在庫などだけでなく、受発注
や生産など処理中の案件/イベントの状態も、DBを検索すれば容易に分かる。
したがって処理結果を誰に渡すかなど考えずに、ともかくDBに反映すればよ
い。DBはデータのストレージというより、関係者が情報を共有し、コミュニ
ケーションする通信場として認識されるようになって行きました。
こうして、「ビジネス実態を表現するDBが主役、プログラムはDBに仕える
脇役」と主客転倒、DOAアーキテクチャへの大変革が起きることになりまし
た。いわば天動説から地動説へのコペルニクス的転回です。プログラムAとプ
ログラムBはDBに対して、同等の位置づけにあり、どちらが主、どちらが従
と言う関係はありませんので、いわゆるデータ独立性が実現でき、保守が容易
になりました。
しかし、DB通信場を共有するプログラムの種類/範囲に制限?多くは個別ア
プリ単位?があり、DBMSも実装独立を実現できるものではありませんでし
た。このため作られたアプリケーションのほとんどは、後にSILOと呼ばれ
る部門システムであり、顧客や商品などのリソースデータ(マスターデータ)
は、それぞれが定義・保守するものとなっていました。
また、データの処理はすべてアプリケーションの担当であり、SQLを発行し
て必要なデータを取り込み、処理をしてこれをDBに返すものと考えられたた
め、たとえば5個出荷したとき在庫が5個減る処理もアプリケーションの担当
と考えられました。これは本来、在庫数と出荷数の間の整合性制約?筆者は加
工データ制約と呼んでいる?に基づいてDBMSが行うべき処理であり、デー
タモデル図上でトレースすべき課題だと考えられますが、その機能を提供する
DBMSがないため一般化していません。これを第1世代のDOAと呼ぶこと
ができるでしょう。
この環境のもとで、プログラム自動生成をねらうCASEツール、C/Sプラ
ットフォーム、アプリケーションパッケージの登場があり、さらに部門アプリ
を統合するERP、さらにはWebが登場することになります。
■第2世代DOAに向かって
情報システムの歴史は、アプリケーションの統合・拡大とIT進化の歴史だっ
たと言えますが、これはビジネス世界におけるデータが切れ目なく連携してお
り、情報システムはこれをマッピングすべき宿命をもっているからかと思われ
ます。
これに対し、かつてはScrap & Build などが行われたわけですが、種々のIT
を活用して構築され、連携によって大規模化したシステムに対して、SCM、
CRM、M&A、グローバル化、エネルギー高騰、サブプライムローンなど、
大きなビジネスニーズの変化がつぎつぎと押し寄せ、また進化したITの取り
込みなど、その対応に苦慮しているのが、大方の企業の実態かと思われます。
コスト削減やIT高度化の対策として、アウトソーシングやパッケージ採用に
走り、ITと同時に、ビジネスモデルを把握する人材の枯渇を招いた企業も少
なくないかに見えます。ビジネスをアウトソースしない限り、自社要員による
ビジネスモデルの把握は必須のはずです。かつての優秀な担当者は、部門シス
テムならば、よく全体を把握していたわけですが、今日の部門横断や企業横断
のスケールにおいて、「ITはビジネスを支えるべき」という要請に応えてい
くとき、今までのアプローチでは対処できなくなっているかに見えます。
したがって、この対策としてはかなり抜本的なもの、たとえば
(1)ビジネス全体の要所のみを可視化する
(2)計画は全体を抑えつつも、実装は部分を対象に逐次行う
(3)パッケージやレガシーを活用する
などが必要になると考えます。
(1)における「ビジネス全体の要所」とは、「アプリケーション間のインター
フェース」になると考えます。すなわち、フェデレーション・アーキテクチャ
を採用し、アプリケーション内の問題とアプリケーション間の問題に分けて、
後者の可視化に注力するわけです。前者はすでにパッケージベンダーやレガシー
設計者によってほぼ解決されているので、原則として可視化の対象からは外し
ます。
インターフェースとは、アプリケーション間のメッセージ(トランザクション)
となりますが、これは最近話題のサービスに一致し、一般的にはユーザインター
フェース、すなわちIOに含まれており、この中から抽出することができると
思われます。ITの違いは本質的ではありませんから、インターフェースは実
装独立とします。
可視化とは、KPIなどのようなグラフ化ではありません。設計図と部品表、
すなわちデータモデル図やプロセスモデル図と属性定義書などによる可視化で
す。設計図は、適切な作図規則を持ち個人差の発生を防止し、正確な情報共有
を可能にするものでなくてはなりません。
(2)は対象システムがすでに巨大化しているため当然かと思われます。従来は
全体はあいまいのまま部分を設計してきたため、SILO化を招いたわけです
が、(1)によりその弊が防止されるので、安心して部分に注力できることにな
ります。
(3)もすべてを一挙にToBe化することができませんから、接続のための若
干の手入れはしても、極力使えるAsIsのパッケージやレガシーは活用しよ
うというわけです。
この(1)、(2)、(3)の対策の要は、アプリケーション間にDB通信場(ハイレ
ベル)を用意するものです。第1世代DOAはアプリケーション内のプログラ
ム間にDB通信場(ロウレベル)を設けてプログラム間の独立を実現するもの
でしたから、これはアプリケーション間の独立を実現する第2世代DOAと呼
ぶことができるでしょう。
ハイレベルで扱うメッセージは、一般にロウレベルにストアされていますので、
ストレージとしてはこれを活用して、ハイレベルを仮想化することができます。
全メッセージを仮想化した場合、これはESBによる実装に「ほぼ」一致する
ものと思われます。ここで「ほぼ」と修飾したのは、ESBでは「ハイレベル
で扱う全メッセージを対象にして、標準化し通信場を作る」という条件が明記
されていませんし、このために「メッセージを素材にデータモデル図を作る」
というコメントも見たことがないからです。実際そのためでしょう、社内にE
SBがいくつも乱立し混乱するケースがあると報告(IBM SOAアーキテ
クトサミット2008 豊村明彦氏)されています。
■フェデレーション・アーキテクチャ
フェデレーション・アーキテクチャのメリットは
・パッケージやレガシーを活用できる
・個別アプリは同じ分野/文化圏に属するので担当者間の効率的コミュニケー
ションが可能
・種々の変更もこの中で解決できるものが多いはずなので、速く安く対応できる
・アプリ間、たとえば購買、生産、販売、物流、会計などの間のメッセージは、
業種対応には異なっても、もともと数が限られていると同時に、時代とともに
変化することが少なく、テンプレート化も可能と思われるなどと考えられます。
大規模システムを扱うときには、Monolithic「一枚板」でなく、やはり古代ロー
マ人の知恵、Divide and Conquer 「分割して統治せよ」を採用するのが良い
のではないでしょうか。