» 【126号】DOAの本質は自己相対化の世界観

株式会社データ総研 データ総研のオンサイト教育
製品案内 DMBOK ITコンサルティングサービス ITコンサルティング事例 紹介セミナー 教育コース 技術情報 DRIブログ 会社概要
技術情報
【126号】DOAの本質は自己相対化の世界観

■世界観は自己中心からスタート
われわれは、宇宙→銀河系→太陽系→地球→日本→自分と言った位置づけを
知っていますが、コロンブス前の人々は自分の周辺からしか自分を位置づけること
ができませんでした。

赤ん坊は自分→母親→家族→周辺の人々と、自分中心で世界観を広げていき
ますが、これは極めて自然な発達といえます。子供も小学校に行くようになって
ようやく自分を相対化する世界観を持つことができるようになりますが、世界観の
拡大がその条件となっているものと思われます。ガリレオの地動説が否定された
のも、大衆の世界観が未熟だったためと思われますが、この転換には「コペルニ
クス的転換」という言葉があるように、かなりのショックを必要とするもののように
思われます。
■情報システムはプログラム中心からスタート
情報システムの世界では、まずコンピュータを使って処理を機械化するため、
プログラム作成が最初の課題となります。プログラムによってコンピュータは、
手作業ではとてもできないと思われていた処理を魔法のようにやってくれます
から、プログラムはプログラマにとって自分のかわいい手下/分身のような存
在になります。プログラマは自分のプログラムにクレームがつくとわが子がい
じめられたように傷つきます。システム開発はこうして、まずプログラマの分
身である担当プログラム中心の世界観で作られて、スタートします。
■データ中心への移行は必然
プログラマは何人かのプログラマを抱えるSEに昇格していくわけですが、こ
のようなSEが他にもいて、相互にデータのやりとりが必要になってきます。
初めは上流のプログラムや大きいプログラムの都合に、下流や小さいプログラ
ムは合わせます。上流のプログラムに変更が発生すると下流はその影響を受け
修正しなければなりませんが、それがどこまで及ぶか簡単にはわかりません。
結局そのようなプログラムがたくさんになって、収拾が付かなくなります。一
般にはかなりの「すったもんだ」の末、結局個々のプログラムの世界観を捨て、
個々のデータニーズを「調整」して作られるデータ独自の構造を反映したデー
タ中心の−しかも実装独立の−世界観に移行することになります。これは当該
プログラムを中心にした天動説からデータベースを中心にした地動説に転換し
たことになるわけですが、それまで欠落していたそのプログラムの外部設計を
行って、これを相対化した結果と解釈することもできます。処理に心を奪われ
るとどうしてもその位置づけ、外部設計が甘くなる傾向があるようで要注意で
す。
■データ独立性による民主的アーキテクチャ
「調整」とは標準化、約束事を作ることです。これによって、データベース通
信場ができ、個々のプログラムはこの約束事さえ守れば自由に設計・変更でき
るようになります。E. F. Coddの「データ独立性」、J. Martinの「サブジェ
クトデータベース」は、これを実現する条件として提案されたものです。独裁
者が群雄割拠する社会に、法律ができて民主社会ができたようなものです。こ
の意味ではPOA(Process Oriented Approach)は幼児の自己中心的世界観
の反映、DOA(Data Oriented Approach)はプログラムを相対化する大人の
民主社会中心的世界観を反映するアーキテクチャと言えるのではないでしょう
か。自己中心を克服する必要があるため、多くの人にとってなかなかのハード
ルとなることも理解できます。
■データベースの大きさは有限
このデータベース通信場は、大きいと関係者が多くなり、調整に時間がかかり
ます。また大きいとニーズの変更も多発しますので、寿命が短くなります。そ
して大きすぎると調整時間が寿命を超えてしまいますから、データベース通信
場は、ある有限の大きさに収めなければなりません。販売、生産、経理、人事
などのデータベース、したがってこれを中心とするアプリケーションが別々に
作られてきたのも、このような合理的配慮の反映だと思われます。
■ハイレベルのデータベース通信場
こうして作られるアプリケーション間にもデータのやり取りが必要ですから、
プログラム間−これをP2P(Program to Program)と呼ぼう−でと同様に、
始めは下流が上流の形式にあわせて変換していたとしても、最終的にはアプリ
ケーション間−これをA2A(Application to Application)と呼ぼう−にお
けるデータベース通信場が必要になります。個々のアプリケーションの世界観
を捨てて、これらの調整によって作られる一回り上のデータ中心の世界観に移
行するわけです。こうしてプログラムの場合と同様に、個々のアプリケーショ
ンはこの約束事さえ守れば自由に設計・変更できるようになります。すなわち、
アプリケーションが相対化され、このハイレベル(全社レベル)でのデータ独
立性、民主社会中心的アーキテクチャが実現されることになります。
ただし一般に、このテーマはDOA的にかなり高度の技術を必要とするため、
ユーザ企業には今十分な人材がそろえられない、一方SIerは個別アプリケー
ション開発を受託する体質からこの問題への接点がもてない、といった責任者
不在の問題を抱えています。またP2PレベルでのDB通信場は理解できるが、
A2Aレベルでの通信場までは理解できない、という人も少なくありません。
調整事は技術問題というより政治問題になりますから、適切なマネジメントの
対応が待たれるところです。
アプリケーション間(A2A)でやりとりされるデータは、アプリケーション
内(P2P)でやり取りされるデータに比べると量的に少なく、かつ質的にも
−発注、入庫、生産指図、生産完成、受注、出荷、請求など品物やお金の在庫
(先日付を含む)にかかわる−かなり限定されたものになるようです。筆者は
アプリケーションの大きさを適切に決めることによって、業種ごとの雛形さえ
用意することができるのではないかと考えています。
■リポジトリとリソースデータベース
P2Pでの通信場を実現するためには、従来型のOLTP型DBMSを使うこ
とができます。約束事はレコード形式とコード値となりますが、前者はリポジ
トリ/ディレクトリ、後者はマスターデータ(THモデルではリソースデータ
という)としてストアされるのが一般的でした。A2Aでは、OLTPの必要
はないためDWH型のDBMSで十分と思われます。そして約束事として、レ
コード形式はリポジトリ、またコード値は全社レベルの高い共用ニーズに応え
るために、独立のリソースデータベースを使用する必要があると考えます。
■フェデレーション・アーキテクチャ
このように通信場をP2PとA2Aの2階層用意するアーキテクチャを、われ
われはフェデレーション・アーキテクチャと呼んでいますが、メインフレーム、
C/S、WEBを含み、レガシー、パッケージ、手作りなど多様なアプリケー
ションから成る、しかもM&Aなどが急遽発生する、全社システムをスムーズ
に運用・保守するには、この2階層アーキテクチャ(図参照)が不可欠なもの
に違いないと考えます。
A2A: R&R0(全社レベルのリポジトリ&リソースDB)
通信場  DB0―――――――――――――――――――――
           |←―(ときにレベル間変換要)―→|
P2P:      R&R1                  R&R2
通信場      DB1――――――――       DB2――――――――
               |     |             |     |
             PG11  PG12           PG21  PG22
図 フェデレーション・アーキテクチャ
これからの保守は安定部品と取替部品を区分し、取替部品を随時取替ながら行
うべきですが、長期的にはスクラップ&ビルトもなくすわけには行かないでしょ
う。この場合しかし、全社スクラップ&ビルト−初期のERPはこれに挑戦し
ました−は、これからはありえず、個別アプリケーションごとに、計画的に行
うことになると思われます。したがって、P2Pのローレベルには約束事の違
うレガシーやパッケージが常に混在するわけで、A2Aのハイレベルの全社標
準でこれらがコミュニケーションするためにはレベル間での変換が必要になり
ます。したがって約束事を記述するリポジトリやリソースDBは、P2Pおよ
びA2Aのそれぞれに用意する、2レベルのアーキテクチャとしなければなら
ないはずです。
最近話題のSOAでのサービスは、本来ここで述べるA2Aレベルのメッセー
ジデータ(トランザクションレコード)に相当する(メッセージデータを作る
処理はDOAではメッセージの裏に隠蔽するので敢えて言及しない)ものと思
われます。SOAでは、まだA2A通信場に言及するものは少ないようですが、
これも応用初期のためで、SOAの普及とともに個別アプリケーションを相対
化する世界観が定着し、今後大きな話題になってくるものと筆者は考えます。
このとき、そのデータは本来フェデレーション・アーキテクチャのどこにある
べきかが重要な設計課題となります。これを考慮しない、ただ現在ストアされ
ているデータを連携するSOA−これがいま誌上をにぎわしている−は、将来
に禍根を残すバンドエイド型のSOAになる危険性が高いものと心配です。
(注1)社内外組織、商品/部品など共用性の高いリソースデータはA2Aレ
ベルで設定し、これをP2Pレベルでも使います。このため弊社では個別アプ
リケーションを対象とする場合でも、リソースデータをイベントデータから切
り離して扱います。これによって、多くのプロジェクトにおいて孤島システム
の発生を未然に防止してくることができました。
(注2)説明が難しくならないため、B2B(Business to Business)のコミ
ュニケーション問題はA2Aの応用問題として解決できるものとしてここでは
省略しました。また「A2AやB2Bの通信場がWEB主体となり、XMLが
使用されるであろう」などは、実装よりの話題なので敢えて言及を避けました。
(注3)DOAの本質を明らかにするためにPOAと対立させて書きましたが、
プロセスが不要というものではありません。ただしOS、DBMSをはじめと
するミドルウエアはPOAによって作られますが、画面・帳票など出力形式の
規定されるアプリケーションは原理的にはすべてDOAによってプログラムレ
スで作ることができるはずと考えます。