» 【第44号】3種類の通信モデル

株式会社データ総研 データ総研のオンサイト教育
製品案内 DMBOK ITコンサルティングサービス ITコンサルティング事例 紹介セミナー 教育コース 技術情報 DRIブログ 会社概要
技術情報
【第44号】3種類の通信モデル

DRI通信44号「3種類の通信モデル」 2000.5.1
花祭りに桜は満開になり、スケジュールどおり新緑の季節となりました。Y2
Kが過ぎ、昨年よりは活気があるように感じますが、実質は掛け声ほどでなく、
安心はできません。皆様はいかがでしょうか。
先月は標準化について私見をのべましたが、特に反論もなく、標準化をからめて
1件の講演を依頼された状況でした。
今月は専門外なので、若干不安ですが、通信のモデルについて素人考えを述べて
見たいと思います。通信に関して次の3種のモデルがあるように見えるというこ
とです。
■3種の通信モデル
(1) 個体間通信モデル
CSV形式トランザクション
[組織1]――――――――――――――――――→[組織2]
DB1:ローカルリソースデータ プッシュ型通信 :各種イベントデータ
(2) DB通信場モデル
公開DB: (メタデータ)
:(リソースデータ)
:(イベント1)&(イベント2)&(イベント3)&…・
↑ |
| ↓ プル型通信
[組織1][組織2]
(3) EAIモデル (メタデータ)


(EAIメタ)
[EAIツール]
↑ |
| ↓ プッシュ型通信
「組織1」 「組織2」


■特徴
すなわち(1)は従来の伝統的通信で、昔の紙に変わってトランザクションが
プッシュで届けられるものです。組織1に昔は人と紙があったのですが、いま
はプログラムとDB1(ローカルリソースデータと各種イベントデータから成
る)があります。トランザクションには、組織1と組織2で協定したCSV形
式などが用いられます。2種類のデータ、DBとトランザクションを持つのが
特徴です。組織が少ないうちは良いのですが、n個になるとn*(n−1)種
類のCSV形式が発生するP2P(Point to Point)の欠陥を持ちます。
(2)はDBを公開し、各組織とも自前のDBは持ちません。発生したデータ
は公開DBに書き込み、他は必要に応じてプル型で参照します。DBの構造を
示すメタデータと共用すべきリソースデータ(マスターデータなどと呼ぶ企業
が多い)は、各組識で協定し共用します。各組織はデータを持たず、公開DB
1種類しかデータが存在しないのがこのモデルの特徴です。組織がn個あって
も、DBがハブ型の通信場を提供しますので、複雑化せず柔軟性・拡張性が落
ちません。これをP2H(Point to Hub)によるイントラ統合と呼んで良いで
しょうか。ホームページやナレッジマネージメントの進んだ会社のオフィスを
連想させます。
(3)はEAIツールという通信を一手に引き受けて裁くエイジェントが介在
するモデルです。n*(n−1)種類のメッセージが発生し、トランザクション
をプッシュで届けるという意味では(1)に似たモデルになります。実装独立の
データの意味を記述するメタデータと、EAIツールが利用する実装従属のデー
タの仕様を記述するEAIメタデータとは、特別に配慮しない限り別管理になり
ます。
■大組織の場合
組織が大きくなっても、(1)のモデルは変わりません。大組織間でCSV形式の
トランザクションが授受されるだけです。しかし(2)では、ある大きさを超え
ると全データの公開が難しくなります。それはM&Aの場合やレガシーとERP
の場合の通信を考えると直ぐ分かります。既存の資産がある場合、これをを活か
したいからです。このときは大組織間で通信するデータに限った2階層目のハブを
用意して、言わばインター統合を実現することになります。(3)は元々大規模組
織間の通信を解決するためのモデルですから考慮する必要がないでしょう。
■個体間通信モデルはプレ通信場モデル
歴史的に考えると(2)はDBとネットワーク、とくにインターネットが可能・
有効になった通信場を活用する人工的なモデル、(1)は昔からの組織をコンピ
ュータ化した常識的で自然なモデルと言えます。(2)では通信場ありきで考え
ますが、(1)では通信場という考えがありません。プレ通信場モデルと言っても
良いでしょう。(2)はDOAの、(1)はPOAのアーキテクチャと言えます。
オブジェクト指向にはいろいろあって、どれが家元か分からないので一律に論ず
ることができませんが、元来オブジェクト指向には通信場という概念が希薄で、
P2Pの個体間通信を前提にしているように見えます。実世界を自然に写像し
ようとすると、仲間内での小さな閉じた世界では問題がないのですが、ボーダー
レスに拡大を迫られるビジネスアプリケーションに対応できなくなる心配があり
ます。天動説は自然かつ常識的で日常生活において何の支障もないわけですが、
実はどこかで行き詰まる、というのと似ているように思われます。一般にローカ
ルな見方は、自然で分かりやすく一般受けしますが、全体を調整する能力に欠け
る場合が多いようです。
■DB通信場モデルは抽象的かつ人工的
通信場という考え方は、ある種の抽象化を要求するので、人によっては不自然
に感じられるのかと思われます。これを作るためには、個々の組織のローカル
な見方−これを敢えて「偏見」と表現したい−を調整しなければなりません。
データモデリングにおいての難題は、DB統合と称するこの「偏見」の調整で
す。企業合併ですと、同様だが微妙に意味の違うデータが沢山出てまいります。
コンサルタント(われわれは最近ビジネスモデルコンサルタントと称しています)
は、これを概念DB構造図上にマッピングして、その違いを判定し、同じとす
べきところについては適切な落とし所を作って調整していくことになります。な
お「偏見」と表現しましたが、低次元に撲滅してはなりません。大切な偏見はそ
れとして残さなければなりません。
結果はデータ辞書(最近はリポジトリと呼ばれることが多くなりました)に記
述されます。これによってn個の組織のコミュニケーションが保証されます。
われわれは、この人間に分かりやすい図表現として概念DB構造図などを用い
ています。このようなコミュニケーションの規範を作って、「データベースの
原理−One fact to all users」による情報民主主義や文鎮型組織を実現しよう
としているわけです。
■最後は人間の能力
キリスト教、というよりはその前身の旧約聖書には神と個人の関係を正しくす
れば、個人間の問題は解決されるという思想があります。個人間の問題解決の
場、規範として神を位置づけているわけですが、データベースのように客観的
素材がなくまた可視化することができないために、正しい共通の認識が難しい。
悲しいかな人間には思い込みがあり、これを隠れみのに悪用する奴がでてくる。
こうして歴史上たくさんの悲惨な結果も残されました。「所詮人間の能力は有限
である。運用にはこの認識が肝要」ということになろうかと思われます。
DB通信場モデルが今後の方向と思われますが、その規模や有効性は「偏見」
の調整をリードするデータ管理者の能力と、「偏見」を提供するビジネスユー
ザの協力が決め手になります。データ管理者に要求されるのは、IT技術とい
うよりはビジネスに関する広い知識、分野の異なる種々のユーザの「偏見」
を正しく理解し、調整する能力です。データモデリング能力はOJTなどによ
り身につけた実践的なものでなければなりません。年齢は30台前半が最適か
と思われます。弊社の関わったDOA成功企業を見ると、そこには必ず優れた
データ管理者が育ち、情報システムの文化が近代化され、最新の情報技術を
次々と消化して決して失敗しない、健全さが育成されているかのように思われます。