» DRI通信151~160号

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

創業者、椿正明の過去の発信のアーカイブです

【160号】「PLAN―DBの出自」

2010/02/03

■DOA40年
2000年に社長を、2006年に会長をやめ、フェローの肩書きで勤めていまし
たが、この2月でDB研と中断中のK2Wを締めくくって、社員も辞めることにい
たしました。そこで、DOA40年にわたるPLAN-DBの出自と今後の展望を
つづってみることにしました。

■千代田化工での化工設計
私は1959年工学部化学工学を卒業して、化学プラントの最上流の設計「化工設
計」に携わりたいと、千代田化工建設に入社しました。石油化学はなやかなりし頃
で、反応・分離・加熱・冷却などの単位操作(処理工程)を組合わせて、所定の物
質を作るプロセスを設計する仕事です。設計結果はプロセスフローシートと呼ばれ
る図面に表現されます。図面の書き方は、ほぼ標準化されていて、設計者によって
若干の違いはあるものの、読む人にとって気になるほどのものではありません。図
面言語としては完成度の高いものが確立していたと言えるでしょう。

設計の中心は、顧客の要求する製品を作り出すための物質・熱収支計算です。これ
は機器と機器のインターフェース「ストリーム」の整合性を保証するものとなって
います。これを実現するための機器の形状・寸法・材質・強度などの設計は、物質
・熱収支計算の後で行います。すなわち実装独立の整合性を保障し、その結果をも
とに実装設計を行う手順となっています。

入社当時はまだコンピュータはなく、気液平衡の試行錯誤計算も、計算尺や手回し
の計算機を使ってやっていました。入社5年後くらいにIBM360が導入され、
技術計算はFORTRANで、事務計算はCOBOLで機械計算ができるようにな
り、手計算は機械計算に移行していきました。

化工計算では機器に出入りするストリームは、エタン、プロパンなどの各分子のモ
ル流量を表すベクトル(アレイ)で表現されますので、これを処理する機器の働き
は変換マトリクスで表現することができます。このベクトルとマトリクスによる、
リニアモデルと呼ばれる表現が、所期の製品を作るための最も単純化されたプロセ
スの表現となります。私はこれをベースにプロセスシミュレータを作るべく、かな
り早い段階に化工エンジニアから足を洗うことになりました。と同時にこのいわば
GOA(Goal Oriented Approach)は、「整合性のとれた実装独立設計先行」とと
もに、私の体にしみ付いて、以後の活動に影響を与えて行ったように思われます。
実装独立すなわち「概念」と「論理」の区別の曖昧なシステム屋を見かけますが、
この真の理解にはユーザ部門での原体験が必要なのかもしれません。

当時はまだ、インプットはカードパンチ、アウトプットは紙です。事務計算のアウ
トプットは、早めに順次ファイルに移行していきましたが、プログラマーの関心事
は処理をいかに機械化するかでした。千代田化工の仕事は、最上流の化工計算から、
反応器・蒸留塔・熱交換器・ポンプなどの機器や配管の形状・寸法・材質決定・強
度設計、これら機器・配管の調達、工事計画、工事管理と続きます。この各作業で
コンピュータが使われるわけですが、このままいくと「人間はコンピュータのアウ
トプットを見て次のインプットを作る係りになるな」と思いました。

■Information Algebraをベースに
そこで早晩、各作業を連携するために各アプリケーションがどのようなデータを受
け渡ししているかを解明しなければならないと考えました。データをどう表現すべ
きかを考えているときに遭遇したのが、CODASYLのInformation Algebraという文献
でした。そこでは、V=A(E)すなわち
 Value=Attribute ( Entity )
が紹介されていました。「われわれの眼にする値は、あるエンティティの属性であ
る」とのこと。したがって縦軸にエンティティ(インスタンス)を、横軸に属性を
並べ、その交点に値を書きこれを適宜並べ替えると、エンティティタイプおよび共
通の属性が見えてくるはずです。これを基にTH(椿・穂鷹)モデルの原型を作り、
種々の下流工程の帳票を分析して行きました。1970年頃、40年前のことです。
「これによって、上流から下流に至る各アプリケーションを連携できると」いう確
信を得ることができました。そこで個別業務の機械化と同時に、これらを統合する
CHEIS(CHiyoda Engineering Information System)の開発が必要であると、
その構想を提案しました。

■ミドルウエアDPLSの開発
当時はまだデータベースという言葉はありませんでした。化工関係のアメリカの学
会で、プロジェクトファイルというアイデアが発表されました。プロジェクトの上
流から下流をコンピュータ上で繋ごうという、似たアイデアです。CHEIS実現
のためには、「OSの機能だけでは難しい、ミドルウエアが必要である」と考えま
した。IBMにPLANというソフトがあることが分かりました。必要なサブプロ
グムを事前にリンクしておかなくても、実行時にリンクするダイナミックリンクの
機能があります。今のStored ProcedureないしWeb Servicesに近い機能です。顧客
ごとに異なった機器構成からなるプロセスを扱うには非常に好都合です。またコマ
ンド言語があり、これによりユーザは処理とそのためのパラメータを、アプリによ
らず統一的な形式で定義できます。まだGUIはなく、CUI(Command User
Interface)の時代ですが、今のXMLに似た形式の言語です。当時プログラマーが
思い思いのユーザインターフェースを設計し、ユーザはその対応にまごついていた
わけですが、これが解消できます。そこでこのPLANにDBMS機能を付加し、
DPLS(Database Programbase Languagebase Support)というミドルウエアを開
発することになりました。

DBMS機能はISM(Information Structure Model)、DSM(Data
Structure Model)、SSM(Storage Structure Model)の3階層からなる、今で
言う概念、論理、物理を分離したモデルでした。また今でいうリソースDB、また
プロジェクトごとに用意すべき複数個のイベントDBなどn個のDBから成る環境
を管理するために、DD/D-今で言うリポジトリ-を内蔵するものとしました。
当時SIerの部長だった穂鷹さんと共同で、THデータモデルをほぼ完成させま
したが、彼は「DPLSは自己記述型の先進的DBMS」と評し、大手メーカーへ
の説明会をアレンジしてくれました。私は1975年ボストンの第1回VLDB
(Very Large Data Base)学会で発表しましたが、それはP. P. ChenのERモデル
と同時でした。

社内で、説明のためデモシステムを作りましたが、高い生産性を確認することがで
きました。私は35年後の今でも非常によくできたエンジニアリングDBMSだっ
たと思います。うまく活用できれば、最も難しいエンジニアリング企業のミドルウ
エアとして大きな貢献ができたのではないかと残念に思います。しかし、会社はD
PLSでなく、当時ようやく登場したIMSを使うと決めました。「DPLSを使
うには広汎なデータの洗い出しと整理が必要だ。IMSならその必要がない」と言
われました。技術でなく、人間との戦いは人生の浪費になると思って千代田化工を
辞めることにしました。

■方法論PRIDEとの出会い
そこで入ったのが、日本システミックスというシステムコンサルティングの会社で
す。アメリカのMBA社からシステム開発方法論PRIDEを輸入販売していました。
「情報システムはInformation Resource から構成すべき、だからInformation
Resourceの管理が鍵だ」という、組立加工製造業的な方法論です。その思想に問題
は無いのですが、データモデルの面で不十分な点があったので、THデータモデル
でこれを補うこととしました。

「PRIDE+THデータモデル」による先進企業に対するコンサルは、非常に高
い成功率だったと思います。THモデルに加えて、これを補強する業務フローを記
述するIPF(Information Process Flow)チャート、SPF(Schema Process
Flow)チャートも実プロジェクトに適用し有効であることを確認することができま
した。PRIDE技法では、「サブシステム」という処理粒度の基準、またIOか
らDBを決めるべきとする考え方が参考になりました。

なお、同社に在籍したとき、n個のDBから成る環境を前提としたミドルウエアD
BCMS(DB Complex Management System)に関する調査レポートを作り、IPA
に納入しました。私の今の3階層DHアーキテクチャはこの延長上にあると言えま
す。

■PLAN-DBコンサルテーション
しかし1985年、「THデータモデルによるDOAは、PRIDEユーザ以外に
も普及すべき」との思いからDRIを創立することにいたしました。当時はシステ
ム部門主導で、メインフレーム上に基幹系システムのRDB構築を行っていた時代、
THモデルを中核にした、弊社の方法論PLAN-DBは好評でした。「リソース
DBは全社に1個、個別アプリと切り離すべき」という主張はほとんどの顧客で受
け入れられ、1980年代に今で言うMDM(Master Data Management)が実現で
き、その企業では後の混乱を避けることができました。それから20年以上経過す
るわけですが、「保守や開発の合理化は1%台ではなく10%以上と考えられるの
で、顧客には大変なROI-大きいところでは5千万円が100億円になる-を提
供できたはず」とは、私の皮算用です。

1990年代に入ると、C/Sによるダウンサイズが流行し、システム部門による
統制が効かなくなりMDMが劣化していきました。バブルがはじけ、パッケージ導
入が多くなり、Y2Kに忙殺され、システム部門のビジネス理解力がダウンしてい
きました。

私は
「情報システム=ビジネスシステム+ソフトウエアシステム」
だと考えますが、「情報システム=ソフトウエアシステム」との誤解があるので
しょうか、パッケージやSIerに丸投げする企業も少なくありません。ユーザ企
業の情報システム部門は、ビジネスシステムを全社横断で可視化し経営をサポート
する役割があるはずです。可視化には分かりやすい正しい図面言語が必須のはずで
す。

これまで統制不十分のままシステム化を進めてきたため、「アプリが1000個以
上ある、データ項目は40000以上ある、パッケージも入れた、さらにグローバ
ル化、M&Aが進められる、これに迅速に対応すべし」など誰の手にも負えないよ
うな状況になりつつある企業も少なくないと思われます。これらの整理は機械では
できません。人手になりますので如何に巧妙に進めるかが問われます。進め方その
ものを試行錯誤により決めていかなければなりません。

私は初めが肝心、分かりやすい主なアプリを選択し、このアプリ間のデータ(先の
DRI通信159号の3階層DHアーキテクチャにおけるE2データ)を手掛かり
にE2(アプリ間のイベントデータハブ)の構造の可視化から進めるのが得策と考
えています。したがって個別アプリ内のE1(アプリ内のイベントデータハブ)の
データは当面眼をつぶります。E2に登場するリソースは共用性の高い重要なデー
タですから、標準化不全ならばこれから手をつけなければなりません。この作業-
2,3ヶ月を想定しています-の中から、その企業に合った効率的な進め方、整理す
べきアプリなどが発見できると考えます。

■今後の課題
これまで40年かけて、DOAの方法論を追求し、コンサルティングを通じて人材
育成を図ってきたわけですが、1990年まではよいとして、その後はなかなか苦
戦だったように思われます。方法論もツールも進化していますので、「規模が拡大
し、体制がとりにくくなった顧客における環境変化」が主な原因かと思われます。
しかし策はあります。MDMは必須条件として、「スパゲッティフリーを実現する
3階層DHアーキテクチャとプログラミングレスを実現するリポジトリツール」が
鍵ではないかと考えています。

以上の記述にあたり、昔を省みたわけですが、実装独立先行、そこでの整合性保障,
GOA、マルチDBなど化工設計やプラントエンジニアリングから習得したものが
多いのに気づきました。その意味では私にとっての化工設計の10年弱は、その後
のDOA開発方法論開発のための準備期間だったのかもしれません。確かに情報シ
ステムと最もよく似たハードのシステムは化学プラントだと思います。都度一品物
を設計して建設します。図面をベースに成果物を共有しなければなりません。この
ため設計方法論も似てくるようです。ただ、ハードシステムは重力が働くため、図
において特に約束を設けなくても個人差は出ませんが、情報の場合は重力の規制が
ないため、各人思いのままに図を書きます。私はエンティティの粒度によって、粗
いものが上、細かいものが下と、配置規則を決めましたが、成功だったようです。
またリソース系は標準部品の定義ですから、これを「システム広辞苑だ」として、
成果物のイベント系データ構造図から分離するものとしました。

私は、Information Algebra以外、参考にしたい文献を発見できませんでした。
1971年頃、E. F. CoddのRDMの論文を読みましたが、意味論が抜けているし、
n個のDBを扱っていないのでツールはできても、企業モデルにはなりえないと考え
ました。また、P. P. ChenのERモデルは意味論的アプローチでしたが、属性よりも
エンティティタイプを優先するので、整合性-特に加工・加工元データの整合性-が
取りきれず、品質が上がりにくい、またサブジェクトエリアの概念ではn個のDBが
構成する全社モデルが裁ききれないと考えました。結局、コンサルで取り組んだ200
近いアプリケーション、特にその画面・帳票と格闘しながら、方法論を作っていきま
した。困ったときは「プラントの場合はどうしているか」を考えました。概念モデル
に限定してですが、3階層DHアーキテクチャによって、スパゲッティフリーが実現
できると考えたので、プログラミングレスを実現できる、私なりのメタデータの決定
版を確定し本にしよう、これを2010年の課題としたい、と考えています。
注文などありましたらお寄せいただきたいと思います。


【159号】「3階層通信場をサポートするリポジトリ」

2010/01/04

■概念ミドルウエア
先の158号において、スパゲッティフリーを実現する2つのミドルウエア
 ・ACMGR-iDBMS(Access Manager-intelligent DBMS)
 ・WFMGR(Work Flow Manager)
を紹介しました。その後のセミナーにおいて、「アーキテクチャと言うからには、
データ通信場だけでなく、それらを連携するミドルウエアを明示すべきではないか。
EA、SOAの議論が分かりにくく、かみ合わないのはそのためではないか」と提
言したところ、「実装独立のアーキテクチャになぜソフトウエアが登場するのか」
というご質問をいただきました。「ミドルウエア=ソフトウエア」の誤解を招いた
ようでした。「概念ミドルウエア」とでも言うべきだったのかもしれません。

実装独立のインプットから、実装独立のアウトプットを生成する処理は、実装独立
の処理と言えるでしょう。これがアプリレベルでなく、より汎用的レベルだったた
め、ミドルウエアと呼んだまで。別にメインフレームかクラウドか、COBOLか
JAVAか、などが絡む話ではありません。上記2つのミドルウエアは、リポジト
リを参照することによって、エンティティレコードやメッセージレコードの、汎用
的な通信処理を行います。したがって、このとき参照するリポジトリの構造が課題
となります。

■3種のリポジトリ
ディレクトリ、DD/D、リポジトリなどと、メタデータをストアするDBは、機
能の向上-当初はDB構造記述、データ定義、CASEツールサポート、後に業務
フロー記述、アプリ間通信など-とともに名前を変えてきたわけですが、その最終
的な姿はまだ見えていないと言えるでしょう。最大の問題はITが変化/進化する
ため、プラットフォームが変化し、これによってソフトウエアが変化するためです。
したがって、筆者はリポジトリを考えるにあたっては、IT変化の受け方に応じて、
まず
 ・業務モデル・リポジトリ(ビジネス世界のデータ、プロセス等を記述)
 ・ソフトウエア・リポジトリ(プログラムや電子化ファイル等を記述)
 ・プラットフォーム・リポジトリ(PC、サーバー、ディスク、NW等を記述)
に分けて考えるべきだ、と主張しています。しかしこれは、リポジトリ製品をビジ
ネスとして扱う、ソフトウエアベンダーにとっては、あまり興味を引く課題ではあ
りません。今のニーズに応えて、市場を確立し、たくさん売ることが課題だからで
す。こうして多くのリポジトリ製品が発表されましたが、ITの変化がより激しかった
ためか、この分離を無視した多くの製品が、予想以上に速く姿を消していきました。

■リポジトリの最終形
筆者は、ソフトウエア・リポジトリやプラットフォーム・リポジトリはプロジェク
トが具体化し、環境が確定してから検討すべき課題と考えるため、まずは業務モデ
ル・リポジトリに限って考察しているわけですが、業務モデルに限っても「これが
最終的な姿だ」と立証することは、非常に難しい課題だと考えています。標準化団
体に属する有識者が、多数決で「これをリポジトリ構造の標準にしよう」と決めれ
ばそれで決まるといった性質の問題ではないと考えるからです。世の中には、サイ
エンスが対象とする「決まっている問題」と、人間が相談して「決めればよい」問
題があるわけですが、リポジトリ構造には前者が種々含まれており、提案されたリ
ポジトリ構造の姿から、これを判定することは神ならぬ有識者にも難しいと考える
からです。

それではどうするか。筆者は多くの業務アプリケーションでのモデル化の経験、
すなわち、
 ①DB構造は、素材となる画面・帳票に立脚する
 ②PLAN-DB技法によって、個人差なく同じ概念DB構造が得られた
 ③DBのスコープは素材となる画面・帳票によって決まるから、その画面・帳
票は適切に選択しなければならない
を通じて、「リポジトリ=メタデータDB」においても、リポジトリ構造の決定の
ために、①業務アプリケーションを表現する画面・帳票-業務フロー図、概念DB
構造図、システムアーキテクチャ図、WBS、データ定義書など-の形式がいかに
あるべきか、②この画面・帳票から個人差なく概念DB構造を導く技法、③適切な
スコープの設定による素材の選択、が必須条件になるのではないかと考えます。

すなわち、少なくとも①、②、③の議論が収束してはじめて、概念リポジトリ構造
の標準化の議論が進められるのではないか、と考えます。最大の問題は、①の
システムドキュメントに関してで、現在、業務フロー図としてDFD、BPMN、
IPFチャートなど、また概念DB構造図において、リソースデータを分離する/しない、
加工データを明示する/しない、などまちまちなものが使われており、標準化
には程遠い状況かと思われるからです。やはり、「製品=システムドキュメント」
を決めなければ、「部品=リポジトリ属性」は決められないのではないでしょうか。
これらシステムドキュメントは、発注画面、生産指図書などの業務アプリケーショ
ンのドキュメントに比較して、システム開発という抽象的な業務を支援するために、
収束が難しいわけですが、リポジトリ構造はこれに依存するために、一層収束が
難しいのだと思われます。

②に関しては、たとえばTH図やIPFチャートなど、図特有の分析の難しさは
ありますが、システムドキュメントにおいても、PLAN-DB技法(f)により、
DB=f(IOs)
すなわち、「主要なn個のIOを決めればほぼ客観的にDB構造が決まる」が受け
入れられ、あまり問題は発生しないのでは、と予想します。

③に関しては、従来DBMSやCASEツールなどは、個別アプリの世界に終始し、
標準の異なるアプリの連携や、B2Bでの連携は対象外としており、逆にESB等
通信ツールは個別アプリの業務モデルの記述を除外するなど、メタデータの世界を
適宜「つまみ食い」する形式でカバーしてきたため、スコープの全貌がはっきりし
ませんでした。しかし、先の158号に述べた「3階層通信場アーキテクチャ」で
は、2つのミドルウエア「ACMGRおよびWFMGR」が、アプリケーション/
データハブの追加、すなわちスコープの拡大に、スパゲッティを発生させることな
く対応しますので、従来の業務データや業務プロセスを記述する部分とあわせて、
リポジトリのカバーすべき全体が、すでに抑えられている-いや「こんなメタデー
タが抜けているではないか」というご指摘があれば是非お寄せください、大歓迎で
す-と考えました。したがって、「A2Aとして扱うべきか、B2Bとして扱うべきか
議論の発生する、グローバルな協力会社の扱い」など運用上の問題は残りますが、
リポジトリ構造の収束は③に関しては解決可能と考えます。

■試作リポジトリにおいて
DRI通信誌上で、リポジトリ構造を議論するのは、あまりにこみいっていて、適当
でないと思われますので、別の機会に譲りますが、弊社システムドキュメントを
前提に試作いたしましたところ、リポジトリは大きく次の4つのパート
 BP.業務プロセス(WBSやIPFチャート、画面・帳票など)
 DH.データハブ・アーキテクチャ(データハブ間の関係など)
 AT.属性(概念DB構造図や加工データ仕様など)
 CV.標準変換(レガシーやパッケージなどとの変換)
から構成することができました。

この場合、ACMGRはDH、CV、およびATの一部(主に属性がどのデータハブ
に属するか)、iDBMSはATの一部(加工データ仕様)、またWFMGRは
DHおよびCVをアクセスすればよい、という結果になりました。このリポジトリ
を構成する一部のメタメタ属性は、これまでの文献等では見かけなかったもの
のように思いました。

もし以上の設計が正しいとすれば、各企業は、勿論コンテンツは違うわけですが、
全く同じリ汎用ポジトリ構造(注)により、その業務モデルを記述でき、A2Aは
当然として、B2Bでのスムーズな連携が可能になると考えました。

(注)ここではリポジトリの概念構造のみを述べています。これをどう分散し実装
 実装するかなどリポジトリの実装は別途設計すべきものとしております。
 したがってテーブルやプログラムなどのソフトウエア部品は対象外です。念の為。


【158号】3階層通信場アーキテクチャにおけるSOA

2009/12/01

■サービスはE2/E3通信場にある
POAでは、当該スコープのプロセスの設計を先行させ、他のプロセスとの連携/
通信はこの後で考えるため、その通信は必然的にスパゲッティ構造を作ります。
DOAはこれを避けるべく、まずプロセス間で通信されるべきデータを抽出し、これ
を標準化して通信場(DH:Data Hub)を設計し、これを前提にプロセスを設計し
ます。実装独立の通信場ですから、その素材は現状ビジネスでやり取りされている
帳票等から入手できます。通信場を規定する標準そのものは、値についてはリソー
スDB、形式についてはリポジトリDBに規定されるべきと考えます。

3階層通信場アーキテクチャでは、このDHを個別アプリ内(E1)、アプリ間
(E2)、企業間(E3)に用意し、プロセスは直接的でなく、必ずDHを介して
通信するものとします。SOAはSILO化したレガシーやパッケージを活用して、
安く速く連携しようというもので、当該DB/E1のデータは対象外ですから、S
OAを考えるときは、E2およびE3だけが対象になります。この場合、ユーザ/
AP(アプリケーションプログラム)の要求するサービスは、E2、E3設計時に
識別され、すでに存在していることになります(注1)。

(注1)リソースDBへの検索-顧客住所の検索、部品の電気特性検索など-や
   リポジトリDBへの検索-顧客番号の形式の検索、部品属性の一覧表作成
   など-は、ここではサービスから除いて考えます。

■E2/E3のデータの形式
E2、E3内のデータの形式は、次の2つと考えられます。
 ・エンティティレコード:正規形、形式はリポジトリに記述、宛先なし
 ・メッセージレコード :非正規形、形式、宛先はレコード内に記述

エンティティレコードとしては、製品在庫、売掛残高、今期実績利益(E2)や予
約座席(E3)などがあるわけですが、メッセージレコードとしては次のような-
近年XMLなどでの実装が話題となっている-ものが含まれます。
E2:①営業→生産、生産依頼
   ②生産→営業、納期回答
   ③生産→営業、出荷案内
E3:④バイヤー→サプライヤー、発注
   ⑤サプライヤー→バイヤー、納期回答
   ⑥サプライヤー→バイヤー、出荷案内

受取側にとってはこれがサービスになりますから、生産にとっての①、営業にとっ
ての②、③、またサプライヤーにとっての④、バイヤーにとっての⑤、⑥がサービ
スになります。

サービスとしては、エンティティレコードについては必要な結合処理を行う必要が
ありますが、メッセージレコードについては、そのままでサービスとして提供でき
ると考えます。

ただしSOAミドルウエアとしては、そのE1の形式や値に関する標準が、レガ
シーやパッケージなどで、E2やE3と異なっている場合の変換を行い、またメッ
セージレコードについては、そのユーザ/APへの送信を行うことになります。こ
の変換を行うミドルウエアをサポートするために、リポジトリとして属性対応テー
ブル、またリソースDBとしてコード変換テーブルを用意する必要があります。

■アプリ間データには何があるか
SOAの主題は企業内アプリ横断の通信ですから、3階層データ通信場アーキテク
チャにおいてはE2が主役となります。E2として扱うべきデータの種類はかなり
限定され、かつ安定しているのではないか。たとえば経営、購買、生産、販売、経
理、などを連携するデータが10年経ってもさほど変わるわけがない。したがって
これを可視化することによって、CIOの戦略立案が合理化できるはず、と考えま
した。

そこでE2のデータとして何があるかを考えました。考察だけなので仮説に過ぎま
せんが、筆者の仮説「3種類のアプリ間データ」
 ①計画・追跡データ
 ②在庫・引当データ
 ③要求・回答データ
について、以下述べることにします。

①は月、期、年などで立てた計画を、タイミングに応じて追跡するデータです。た
とえば年間利益計画(E2)について、「6ヶ月経ったが、半分行っているか」を
見る、などです。追跡には多くのアプリ(E1)のデータの反映が必要となります。
またプロジェクト業務の場合は、月、期、年でなく、構成作業単位ごと、進捗ステ
イタスごとにコスト計画(E2)を立てますので、これをアプリ(E1)のデータ
で追跡する、などとなります。

②は、在庫管理です。部品在庫は購買がプラスし、生産がマイナスします。製品在
庫は生産がプラスし、営業がマイナスします。売掛残は営業がプラスし、経理がマ
イナスします。このように、見込生産・販売などに多く見られるアプリ横断の在庫
データは-各E1アプリが重複して持つのでなく-E2で一元管理すべきと筆者は
主張します。

③は、要求・回答データをE2所属とするものです。特注品などは在庫しませんの
で、営業が生産に生産依頼し、生産が回答するような形式となります。宛先が決
まっているのだから、E2経由にするメリットがないようにも見えます-事実従来
は直接通信がほとんどです-が、リポジトリの内容だけで、1個のロジックにより
すべてを制御でき、またアプリ間の通信はすべてE2経由ということで、SOAが
分かりやすくなり、変更・管理がやさしくなると考えます。いま話題のESBは、
③からストレージ機能を除き即時配信としたものに一致する-したがって③はES
Bを包含する-ものと思われます。

「E2データとして、以上の①、②、③のほかに何があるか」は筆者の課題として
いますが、あってもさほど多くはない、したがって管理すべきメタデータも多くな
く、その追加・変更だけで、以後のアプリケーション連携の追加・変更に、いわば
「スパゲッティフリー」に対応できます。筆者は、保守の2大強敵は「個別リソー
ス」と「スパゲッティ通信」であり、前者はMDMによって、後者は3階層データ
通信場によって解決できるのではないか、「スコープの拡大には、スパゲッティは
必然」と考える従来のPOAに比べて、格段に保守が容易になるはず、と考えます。

■3階層データ通信場アーキテクチャのイメージ
さてこの3階層データ通信場アーキテクチャにおいて、どのようなミドルウエアが
位置づけられるべきかを考えます。紙面の制約から、リソース系DBとしてR3、
R2、・・、また3階層イベント系DHとしてE3、E2のほか、自社アプリ購買、
生産、営業などに対応するE1(n個)、また他社アプリとしてA、Bなどがある
ものとして考えます。ミドルウエアとして2種類、すなわち①自社アプリの生成し
たレコードを裁くACMGR-iDBMS(iDBMSを従えたAccess Manager)
および、②E2/E3にストアされたレコードを配信するWFMGR(Work Flow
Manager)を導入したイメージを図示します。

ACMGRはアプリケーションの生成したメッセージレコードおよびiDBMSの
生成したエンティティレコード(DRI通信154号参照)を受け取り、必要な変
換を行い、所定のDH、E1/E2/E3にストアするもの、またWFMGRはE
2/E3のデータに必要な変換を行い、所定のエントリーポイントに、所定のタイ
ミングで送信するミドルウエアです。リポジトリはこれらミドルウエアをサポート
し、変換、送信先識別、送信タイミング、iDBMSによる整合性データ生成など
に使われます。

図はもちろん検証されたものではありません。3階層データ通信場のイメージアッ
プのための議論のスタートが切れれば良いとして示しました。

 ┌――[WFMGR]←―――――――――REPO
 |    ↑   ↑                  |
 |┌-→E3 E2  E1 E1 E1・・・     |  R3 R2 ・・・
 ||   ↑   ↑   ↑  ↑  ↑       |   | |
 ||   ↓   ↓   ↓  ↓  ↓       ↓  ↓  ↓ 
 || [*******ACMGR-iDBMS*******]
 ||          ↑   ↑  ↑    ↑
 ||          ↓   ↓  ↓    ↓
 ||        購買  生産  営業 ・・・・・・自社アプリ(注2)
 ||          ↑    ↑   ↑   ↑
 └――┬――┬―┴――┴――┴――┴
  |  ↓    ↓
  |  A     B ・・・他社アプリ
  └―┴――┴―――
図-3階層データ通信場アーキテクチャへのミドルウエアの導入イメージ

(注2)入力チェックのために、各アプリもデータタイプ、桁数などメタデータを
利用しますが、コンパイル時(Compile 方式)なら直接、また実行時
(Interpreting方式)ならばACMGR経由入手するものとします。
アプリ機能は、加工データ整 合性をiDBMSに委託できるため、
ユーザからの入力を整えるだけと単純化 でき、自動生成/プログラム
レスが容易になっていると考えます。

■メタデータの全貌
リポジトリにストアされるメタデータの応用は、当初はエンティティタイプ、属性、
RDBテーブル、カラム、モジュールなどから始まったわけですが、その応用は従
来になく広がっています。ミドルウエアはメタデータの活用が前提です。仮説の域
を出ませんが、次号以降に、報告できればと考えます。先の仮説「3種類のアプリ
間データ」に対するコメントを含めて皆様の声を寄せていただければありがたいと
思います。


【157号】アーキテクチャを考える

2009/11/02

■アーキテクチャへのニーズ
EAとかSOAとか、業務横断、さらには企業横断の広域アーキテクチャが問題に
なっています。「なぜ今」、また「これにどう対処すべきか」について考えてみま
す。

アーキテクチャとはもともと建築の様式の意味でした。構造や設計法、工法に関わ
るとのことですが、芸術性はさておき、その建築物に課せられた機能を最大限に発
揮する構造を追及するものだったのではないでしょうか。機能の欠落や重複は論外、
適正な機能の配置、空間、調和が必須かと思われます。

このためには機能の列挙、整理、標準化が必要になるかと考えます。コンサート
ホールにはコンサートホールの、単身者マンションには単身者マンションのアーキ
テクチャが求められます。しかし建築には、何千年もの経験の蓄積があり、目に見
えるため、十分なフィードバックが行われてきました。

ところが情報システムの世界はどうでしょう。歴史が浅い、目に見えない、ITの
変化が激しい。さらにビジネスニーズの変化-単なる変化というより、当初想定し
なかった他のシステムとの連携によるスコープの拡大など-も激しい。したがって、
機能の欠落、重複は累々。その列挙、整理、標準化が追いつきません。本来必要な
はずの10倍の-作成タイミング、作成者の異なる-プログラムが稼動していて、
10倍の保守コストと時間を要求し、ときどきちぐはぐな答えを出力し担当者をあ
わてさせます。そこから、アーキテクチャ、アーキテクトが叫ばれてきたものと思
われます。今、アーキテクトによる青写真が求められているのでしょう。

青写真無しに都市を作るとどうなるでしょう。勝手に建物を建てます。道路はその
隙間をぬって、後から作ります。どうしても邪魔な建物は壊して別のところに建て
直さなければなりません。情報システム部門は、これまでこんなことを繰り返して
きたのではないでしょうか。都市計画は、日本でも奈良時代から行われてきたわけ
ですが、多くの企業の情報システム計画は、まだ奈良時代以前の状況のように思
われます。

■必要な取り組み
では情報システムアーキテクチャを構築するための取り組みはどうあるべきなので
しょうか。まだ試案レベルですが、私は次の7項目を提案したいと考えます。

 ①データの整理から入る
 ②実装独立に進める
 ③外部設計に留意する
 ④抽象化思考に慣れる
 ⑤データの関係を見る
 ⑥機能の共通化を図る
 ⑦機能分割に際しインターフェースの識別を重視する

①は、私がDOA屋だからではありません。データに欠落・重複・矛盾があれば、
必ず機能にこれが反映されるからです。結局、正しいデータモデリングが必要に
なるはずです。経験者は、スピードアップのために、トップダウンに行うことを主張
する傾向がありますが、原則はボトムアップに、属性、エンティティタイプ、DB
タイプと積み上げるべきと考えます。トップダウンは往々にして、ミドルダウンと
なってスコープが狭すぎたり、思い込み優先で、顧客と仕入先を取引先として統一
するチャンスを失ったりするからです。

②はSE思考の方が、特に留意すべきことです。RDBのテーブルを作ることでは
ありません。ITの違いや変化に影響を受けず、ビジネスユーザと正しくコミュニ
ケーションをするためです。

③は他システムとの連携が後追い設計にならないためです(注1)。多くの設計は
スコープを決めると、その中だけに注力し、外部との連携は後追いで対応するため、
スパゲッティ構造を招き、保守に問題を残し、寿命を縮めます。外部設計をどこま
で行うかの難しい問題はありますが、当該システムをどう位置づけるかは重要な課
題です。SIerには難しい課題であり、ユーザ企業のシステム企画者への期待が
大の課題です。

(注1)外部設計には、システムアーキテクト向けの「他システムとの連携」の意
味と、SE向けの「単なるユーザインターフェース」の意味と2つあるようです。
ここでは前者の意味で使っています。

④はモデル化といっても良いでしょう。物事の、とくにデータの共通点や相違点の
判定に不可欠のものです。たとえば、品番、顧客番号、受注番号には共通点と相違
点があります。すべてKEY(識別子)であり、特に品番、顧客番号はリソースの
KEYですが、受注番号はイベントのKEYです。これが発番や整合性管理のロ
ジックに影響を与え、正しく把握できないとき、冗長コーディングを発生させます。
在庫数量と売掛残高の共通点と相違点についても同様のことが言えます。
われわれはエンティティタイプを、リソース、イベント、在庫型、要約、断面に5大分類し、
また加工データを13種類に分類しています-ここまで抽象化を要求するデータモ
デル手法は世界中でほかにないようです-が、これによって処理ロジックの共通化
ができ、冗長性が除かれると考えるからです。また個別対応が減り、処理ロジック
の事前準備ができますので、信頼性の向上が期待できると考えます。

⑤は、データがそれ自身の性質と同時に、他のデータとの関係が非常に重要だから
です。特にEI(Entity Integrity)、RI(Referential Integrity)、DI(Derivation Integrity)
が、整合性管理のため重要と考えます。EIは必要な属性が定義されていること、逆に
不要な属性が定義されてないことを要求するものです。顧客に与信限度額が未定義、
工事に終盤になっても実行予算金額が未定義は困るといった制約です。RIは参照
KEYに対応するKEY値が定義されていること。受注エンティティの顧客#は正しく
定義されていなければなりません。DIは加工データが加工元データと正しく対応
定義されているべきと要求するものです。5個出荷したならば、残高は5個減るべき
ですし、売掛残はその分増えなければなりません。この値が月次売上金額といつ整合
すべきか、またサブタイプ対応に処理が異なる場合など、そのルールをはっきり把握し
メタデータとして定義しなければなりません。こうして実装独立段階に整合性を取りきり、
この負担をプログラム設計者から開放するのが、DOAの本来の進め方と考えます。

⑥はデータの整理だけでなく、これに基づいて機能の共通化まで見届けるべきと考
えるものです。EAの提案には、整理の結果ミドルウエアがどう用意されるかが読
み取れず、この点から未完成と感じます。逆に「ESBを使えばSOA」にも、
「ESB機能の共通化だけでは」と感じざるを得ません。

⑦は機能分割に際しての留意点です。大きな機能はそのままでは扱いに限度があり
ますので、より小さなサブ機能に分割するわけですが、このときサブ機能を識別し、
機能を説明するだけで終わらせてしまうケースを良く見ます。サブ機能間のインター
フェースが明示されていないと、そこにスパゲッティ構造が残ります。インター
フェースを集め、整理・標準化を行うことによって、ハブ&スポーク構造が作られ、
きれいなアーキテクチャができて行きます。国を決め、首都や代表者を決めても、
国境が決まってないと、トラブルが続出するのと同様です。インターフェース明示
の重要性を指摘したいと思います。

さきの3階層通信場アーキテクチャは、通信場を個別アプリ内、アプリ横断、企業
横断に分け機能の共通化をすすめ、スリムで高信頼性のミドルウエアを用意したい
というものでした。次号以降にこれを述べたいと思います。


【156号】 3階層通信場アーキテクチャの考察

2009/10/01

■3階層通信場
先の155号でDOA的SOAの前提として、3階層通信場を提案しました。スパ
ゲッティ化を避けるとき、プロセス間の直接的通信はなくなり、n個のプロセスが
やり取りするメッセージを集め、データの標準化を行い、その結果できる通信場を
共用するDOAの通信形式になります。これを
 L1:個別アプリ内
 L2:個別アプリ間(全社、注1)
 L3:企業間
のように分類したわけです。L1では生産、販売、経理など個性的なデータを扱う。
L2では品物やお金の残高など、経営リソースの有効活用の鍵を握るデータを扱う。
L3には企業の利害に係るネゴマターが含まれる。このため4階層、5階層などい
ろいろな考え方があるとしても、3階層がやはり最も本質的なものである、と考え
たのです。

注1:大手エンジニアリング会社の場合は、ここは全社でなく1プロジェクト全体
となる。

またメッセージの中で用語の役割を果たすリソースデータ(取引先や製商品など)
は、「システム広辞苑」とも言うべき通信の要であり、原則としてL2ないしL3
とすべきものと考えました。ここでL3のリソースとは、業界標準の商品や組織な
どの情報であり、将来的にはサプライヤーが公開し、ユーザは仮想的にこれにアク
セスできるため、自社DBに取り込む必要がなくなると予想されるものです。一方、
いわゆるアプリケーションパッケージにはL1のリソースデータが含まれますが、
これは他との通信において変換を必要とする、今MDMとして課題になっている
データです。

■通信場の5分類
したがって、3階層の通信場(DH:Data Hub)をリソース系とイベント系に分け、
これらをR、Eとして示すと(R1DHは除かれるので)、
 R2DH、R3DH、E1DH、E2DH、E3DH
ように5つに分類でき、E1DHについてはさらに生産、販売、経理などと、個別
アプリごとに分類されると考えられます。全社標準化を進めることによって、企業
内は将来R2DHとE2DHに統一できるとしても、当面はレガシーの継続活用、
パッケージの導入などにより、各種標準間の変換を行いながら運用せざるを得ない
ものと考えます。

通信場通信においては、プロセスのオペレーションは参照も更新も、DHに対して
行われます。参照の場合はメッセージ種別を指定する定型、また個別に属性を指定
する不定型、いずれの場合も、正しく該当する標準を選択することのほか、特別の
配慮は不要なので、以下更新の場合について考察するものとします。

■事例研究
更新の事例として、購買システムにおける「発注」を考えましょう。そのメッセー
ジは次のような形をしているものとします(スペース節約のため省略記号を使いま
す)。

発注:[発#]-(仕入先#、品#、 @、数量、¥、  納期、  届先#、・・・)
     123    S15   P01  5  10  50  9日15時  F4

このデータが購買DB(E1DH)にストアされるわけですが、同時に整合性保障
のため、次のようなデータを生成し、先日付在庫および仕入先に対する買掛残を更
新すべきとします。

先日付在庫:[品#. 倉庫#. 締時]-(初残、末残、安全残、残チェック)
          P01. F4. 9日18時   30  40   20  0(正常)

買掛残  :[仕入先#. 締時]-(初残、末残、残チェック)
         S15. 9日24時  100  150  0(正常)

そしてこれらは、他の生産や経理システムからも更新されるデータですから、E2
DHにストアされるべきと考えます。これらはE2DHの言わば全社標準のデータ
ですから、購買システムが独自の標準を採用している場合は、形式についてはメタ
データの、また値についてはリソースの、変換テーブルに基づく変換を行ってから
更新をかけることになります。

また、発注データは仕入先に届けるべく、E3DHにストアされます。E3DHは
種々のイベントデータの行き交う企業間通信場ですから、次のようにメッセージの
KEYに宛先、イベント種別(E種)、発番箇所を補う必要があります。

発注MSG:[宛先.E種.発番箇所.発#]-(仕入先#、品#、・・・)
        S15 発注 TB02  123    S15   P01

この発注MSGは、宛先が適時E3DHをスキャンして入手するか、ワークフロー
機能に委託して入手し処理することになります。いずれにしても、E3DHの標準
によるデータですから、形式や値に関して、自らの標準に変換する必要があります。
この発注MSGは仕入先によって処理され、回答の形でE3DHに戻ってきます。
これを入手した購買アプリは先日付在庫や買掛残を予定から確定に変えてE2DH
にストアすることになります(以下省略)。

■統一的なミドルウエアで裁く
このように3階層通信場アーキテクチャでは、アプリ間のメッセージは所定の通信
場に属するものとすることによって、整合性管理、標準変換、配信などの処理を統
一的なミドルウエアで裁き、簡素化と高信頼性を実現するものと考えます。これに
よって従来、「製品在庫を販売システムと生産システムの両方で抱え、厄介なオペ
レーションを行っていた」などの問題は未然に防げるのではないでしょうか。また、
大手企業の力によるEDI通信場が、このようなE3DHに容易にシフトするとは
考えられませんが、通信場先行のDOA的アーキテクチャの特徴を理解しておくこ
との重要性が、今後増大してくると考えます。

3階層通信場アーキテクチャのイメージ理解のために、製造業の基幹システムが経
営・経理・購買・生産・販売からなるものとし、これらの間、およびサプライ
チェーン先A、B、C、・・・との間にどのような通信場が形成されるかを描いて
みます。

      経営  経理
       |  |
       E2DH(社内アプリ間通信場)
      /  | \
     購買 生産 販売
       \   /
        E3DH(企業間通信場)
         /||\
       A B C ・・・

理解しやすくするために、単純化していますが、3階層通信場アーキテクチャの本
質は表現できているように思われます。通信場アーキテクチャがいかにあるべきか
は、まだ今後の検討を要する課題ですが、これに言及しないで済ませる問題ではな
いと考えます。EAやSOAの成果を実りあるものにするための前提として提案し
たいと考えました。

追伸:
発注を事例としたため、E2DHでは在庫引当型通信、E3DHでは要求回答型通
信が登場しました。しかし、E2DHでも販売が特殊仕様の製品を生産に依頼する
場合は、要求回答型通信が、またE3DHでも座席予約のような場合は在庫引当型
通信が登場すると考えられます。このほかE2DHには、月次販売・生産・購買計
画数量のような多部門にまたがる経営計画を追跡するデータが所属します。個別ア
プリのインターフェースとなるE2DHのデータおよびこの加工元データは、多く
の企業においてまだ可視化されていないように見えますが、経営の役割と部門の役
割の関係を明快に示すための、今後の課題かと思われます。


【155号】 DB通信場再考

2009/09/01

■DB通信場
いま広域統合のためのSOA(Service Oriented Architecture)が話題になって
います。しかしサービスと言う言葉の持つ意味の広さや、各人の立場・背景からく
る、この言葉についての意味づけの違いから噛み合った議論が難しくなっています。
筆者もその一人に過ぎませんが、DOAの延長線上に位置づけたSOAを考えて
います。そのアーキテクチャを構成する主役は3階層の通信場-P2P(Program
to Program)、A2A(Application to Application)、B2B(Business to
Business)-です。「通信場」といっても、この生硬な用語の意味は、十分共有
できない心配があります。そこでまず、P2PにおけるDB通信場を手がかりにその
意味を再考したいと考えました。

DBおよびこれを制御するDBMSは1970年代に登場しました。それまではア
プリケーションプログラムはQSAMやBSAMと呼ばれるファイルに書き出し、
これを読むことによって通信を行っていました。いわゆるバケツリレーです。一般
に下流のプログラムは、上流のプログラムの決めたファイル形式にしたがってこれ
を読むことになりましたから、上流のプログラムがファイル形式を変更したときは、
下流プログラムはこれに合せた変更をしなければなりません。下流プログラムの
都合を取り入れたとしても、インターフェースについての約束事は2者間のローカ
ルマターに過ぎません。プログラムがn個あるとすると、そのインターフェースの
数は理論的には、n(n-1)/2になりますので、Peer to Peerのいわゆるスパ
ゲッティ構造となり、メンテが難しくなります。DBMSが登場しても当初は、
ヘッダー・ディテール構造や部品展開が表現でき、また論理インターフェースを活
用し、項目追加の容易な便利なアクセスメソッドとして使われるだけで、スパゲッ
ティ構造はそのまま残されました。

しかし実装独立のデータモデル論が登場し、RDBMSが実用化されて、「DBは
実務の世界の写像である」とする実装独立のDB通信場の考え方が普及してい
きました。リレーショナルモデルの提唱者E. F. Coddは「プログラムは、他のプログラ
ムとは独立に、DBにアクセスすべきだ」というデータ独立性の主張をしました。
こうしてDBを、一種の伝言板、ハブ通信場とする、Hub & Spokeのアーキテクチャ
ができていきました。実際筆者は、「DBとはストレージ機能より通信場機能が本質」
ではないかと考えます。

DBがハブ通信場として機能する条件は、構成するデータ―属性の形式と値-
の標準化です。このためには原則として関わる全メッセージを素材に、データモデ
リングを行い、標準化・整合化を行います。その結果はリポジトリ(メタデータDB)
およびリソースDBに記述されます。またプログラムは、実務の世界の変化-受注
や生産完成など-を可及的速やかに把握しこれを反映する更新系と、実務の
世界を参照し適切なアクション-発注や生産指図など-につなげるための、意思
決定元データを参照する参照系との2種類に分かれます。こうしてDB通信場が
介在するために、留守電やインターネットメールのように、プログラムPiとプログラムPj
が直接交信することがなくなりますが、同時にPiの記述した内容は、Pkも参照
できることになります。

このようにデータが通信場に「鎮座」し、これにアクセスすることによって通信が
実現すると考えるのがDOAの発想であり、逆にプロセスは「鎮座」し、データが
流れることによって通信が実現すると考えるのがPOAの発想と言えます。データ
は標準化によって1個のハブにまとめられますが、プロセスはn個のままですから、
POAでは脱スパゲッティができません。「通信においてはデータが流れる」と考
えるのは、POAや実装従属の発想から脱しきれないとろから来るもののように
思われます。

■孤島システム/SILOの出現
DBによるハブ通信場にはしかし、守備範囲が存在します。生産関係のメッセージ
から作れば生産DBが、また販売関係のメッセージから作れば販売DBが作られま
す。「これでは困る」と両者のメッセージを集めれば生産&販売DBができますが、
生産技術者と営業マンは異なった文化を持っており、お互いの用語を理解し標準
化を進めるデータ管理者は容易には見当たらず、時間も掛かります。開発の動機や
スポンサーが異なるという理由もあるわけですが、分野統合のDB構築は必ずしも
得策でないことから、これまで一部の例外を除き行われてきませんでした。その例
外はERPです。パッケージにして沢山売ればコストと時間が回収できるという計算
から行われたわけです。

こうして多くの企業で、個別アプリケーションDBが作られてきたわけですが、アプ
リケーション間のコミュニケーション不全の、いわゆる孤島システム/SILOと呼
ばれる、次の二つの大きな問題、

①アプリごとに社内外組織や製商品・部品などのリソースデータの定義が異なる
②アプリ間でやり取りするデータの所在はどこにすべきか基準がないが残されました。

生産指図、完成、受注、出荷などのイベントを文章表現したとき、担当者、顧客、
商品などのリソースデータは用語に相当します。①はこの用語がアプリケーションごと
に異なると言うことです。また、たとえ用語が異ならなくても2重管理になりコストの
点でマイナスですし、他のアプリケーションのリソースを参照することになれば、RPC
(Remote Procedure Call)やWebサービスを多用したスパゲッティ構造を招くことに
なります。いま話題になっているMDM(Master Data Management)の問題となる
わけですが、根本は本来全社的に管理すべきものを個別アプリケーションに任せた
結果と言えます。

②は、たとえば製品残高のようなデータの問題です。これは生産システムの生産
完成でプラスされ、販売・物流システムの出荷でマイナスされるアプリ横断のデータ
ですが、どこに所在すべきかはっきりした基準を持たないため、2箇所にストアしたりし
ている企業も少なくないように見受けられます。これも全社レベルで管理すべきもの
を個別アプリケーションに任せた結果であり、スパゲッティ構造を招き、メンテを難しく
します。また、証券業務における約定残高なども、フロントとバックで共用されますが、
よく似た問題を抱えています。

■3階層ハブアーキテクチャ
そこで、EDIなどの社外への拡張をも配慮して、データに次のようなレベル付け
L1:個別アプリケーション内でだけ使われるP2Pデータ
L2:アプリケーション横断/全社レベルで使われるA2Aデータ
L3:企業横断で使われるB2Bデータ
をします。すると上述は、筆者の提案する3階層ハブアーキテクチャの原則
・独自の文化を持つ個別アプリは、迅速対応・コストなどの観点からL1のDBを
中心に作る(注1)。
・アプリ横断のデータはL2のハブ所属として管理する。
・企業横断のデータはL3のハブ所属として管理する。
のように、まとめられると考えます。

(注1)L1とL2、L3の記述が違いますが、L1の場合はハブをさらにDBと
限定しても問題がないと考えたためで、すべてハブ通信場であることに変わりはあ
りません。

この場合リソースデータは、L1は特にローカルなものに限られるので、ほとんどL2
として管理すべきと考えます。実際われわれは1980年以降のプロジェクトでは「リ
ソースは全社にひとつ」を原則としてコンサルを行ってきましたが、これを採用いただ
いた会社では、以後スムーズなシステム開発が展開でき大成功だったと考えます。
また実例はこれからかと思われますが、使用頻度の低い部品仕様などは、L3-
実データは部品メーカにストアされているが仮想化してL3で公開する-として参照
できるのが理想的だと考えます。この方式のポイントは、物理記憶ではなく、部品
仕様の形式と値の標準をL3で規定することです。

イベントデータの多くはL1となりますが、アプリ横断の在庫データ-先の製品在庫や
買掛・売掛残高など-はL2、また企業横断の在庫データ-ホテルや飛行機の座席
など-はL3として位置づけられると思います。在庫データはアプリAがプラスし、
アプリBがマイナスするわけですが、これは需要が予測できる場合のアプリ間に見られる
「在庫引当型コミュニケーション」の形式だと考えられます。需要が予測できない場合は、
発注に対して、回答、納入、検収が続くような、「要求・回答型コミュニケーション」
が行われますが、これもL2、L3レベルに見ることができます。

またイベント系の一種に、L2データとして、多部門に関わる全社計画・実績データが
あります。たとえば月次販売計画数量・金額ですと、月次製品生産計画、月次資材
購入計画との整合関係が存在するため、これは購買、生産、販売、経理に関わる部門
横断のデータとして扱われ、L2の管轄となります。

■ハイリターンの期待されるL2・L3通信場の可視化
L1を構成するデータの属性は、アプリの個性を反映して、多様かつ変化も激しいので
すが、L2やL3を構成するデータの属性は、たとえば生産アプリと販売アプリ間でやり
取りされるメッセージを考えても分かると思いますが、数も限られかつ安定しています。
現在は多くの企業や企業間において、個別アプリの観点から設計されたL1のデータ
モデルはあるとしても、L2、L3におけるデータモデリングは未着手と思われます。
このためアプリ間インターフェースはちぐはぐであり、ある変更が当該システム内で収まる
か、他に波及するかの判定にすら、多大のコストと時間を投入せざるを得なかったりします。

L1の各アプリの範囲を如何に設定すべきかは、決め事であり難題ですが、これを
決めればL2、L3のデータモデリングは、アプリ間のメッセージを収集すれば可能
であり、技術的に難しい問題はありません。L2、L3のプロセスモデル図およびデータ
モデル図は、経営とITが会話するための必須のドキュメントとなるのでないかと筆者は
予測します。これらは、日本の交通問題を、高速道路と新幹線が解決したのと同様
の役割を果たすことができるのではないかと期待されます。

以上ハブ通信場を3階層に分けるフェデレーション・アーキテクチャにより、孤島/S
ILO問題を解決する提案をいたしました。L2、L3の通信場を構成するメッセージ
は、サービスと呼べるものかと思われますので、以上はDOAの拡張「DOA的SOA」
と呼ぶことができるかと思われます。


【154号】 iDBMSの勧め

2009/08/03

■DI対策
先々号で「現行DBMSの欠陥」を述べましたが、今回はその
「③DI(Derivation Integrity:加工データ整合性)の抜け」に対する対策を
考察します。

分かりやすさのため、部品入庫により部品残高および買掛残高が増える事例を考えます。
すなわち、いま

[入庫#]-(品、倉、入庫数、入庫金額、取引先、区分)
  5      P W  5    ¥50    S   買

のレコードが発生したとします。これによって次のように、部品残高および掛残高は
s1からs2に変化します。

[品.倉]-(部品残高)   [取引先.区分]―(掛残高)
s1: P W    100         S   買     ¥200
s2: P W    105        S   買     ¥250

この場合、従来法ではDBMSに向けて、アプリケーションプログラム(AP)から、
次のように3つの更新トランザクション(TRX)が発行されるものと思われます。

 ┌-(入庫TRX)――┐ 
AP―(品残更新TRX)+→DBMS-DB
 └―(掛残更新TRX)┘

すなわち、実世界では1件のイベントが発生し、ユーザは1件の入力をしただけですが、
APは整合性を保障するために、3件のTRXを発生させ、これをDBMSに依頼して
いるわけです。これではDBMSは、ただ指定された場所にデータを入れているだけで、
「DBを管理するシステム」とは言えないのではないでしょうか。

■iDBMSの登場
そこでiDBMS(intelligent DBMS)が登場するわけです。すなわち、次のようにDI
の整合性管理をiDBMSが引受けます。
 
                   ┌-(入庫TRX)――┐ 
AP―(入庫TRX)→iDBMS―+―(品残更新TRX)+→DBMS-DB
                   └―(掛残更新TRX)┘

こうして、iDBMS+DBMSが本来のDBMSの役割を果たすと考えるわけです。
このために、iDBMSは次のようなリポジトリ情報を活用し、

[加工データ.加工元データ]-(参照KEY)
  部品残高 入庫数      品.倉
  掛残高  入庫金額     取引先.区分

「入庫数、入庫金額が加工元データであり、対応する加工データが[品.倉]エンティ
ティの部品残高、および[取引先.区分]の入庫金額であること」を突き止め、加工
データ対応に記述された加工ロジック(ここでは省略)を参照して、部品残高=100+5、
および入庫金額=200+50を計算し、DBMSに更新依頼することになります(注1)。

(注1)部品残高および掛残高は、生産システムや経理システムからもアクセスされる
ため、アプリ横断のDB中にストアされるべきとも考えられますが、これはリポジトリ
情報から判断できますので、iDBMSによる対応は可能と考えます。

入力データの値や形式の制約チェックも、iDBMSに任せることができますから、AP
の仕事は、実世界に発生した情報を素直にコンピュータの世界で扱えるデータに変換して、
iDBMSに渡すだけになります。整合性にかかわる配慮は不要になりますので、APは
ユーザ・サービスに徹することができます。

従来は、AP開発担当者とDB設計担当者が分業していても、AP担当者もDIの絡む
データ間の複雑な関係-特にサブタイプが絡むとき複雑で抜けも発生しやすい-を認識しな
ければならず、両者の認識が違っていたり、抜けが発生して、トラブルの発生する危険性が
高かったのですが、きれいに分業ができ(注2)、ドキュメントが単純化されます。データ
の設計は、DIを含めて、データモデラーが実装独立に、先行して完結することができます
ので、実装工程からのやり直し依頼はなくなり、開発・保守ともに大幅に合理化されると期
待されます。

(注2)最近、DBの整合性を保障すべく、DBMSは各種ストアードプロセジャー機能を
充実させてきていますが、「データモデラーが実装独立段階に設計すべし」という設計思想
ではなく、プログラマを支援するもののように思われます。

DIにおいては、①加工元データを加工データの所属するエンティティに集め、②これを演
算するわけですが、②の非定型処理ステートメント以外にはプログラム言語による記述は
(iDBMSが肩代わりするため)不要なので、AP側以外にはプログラミングは不要にな
ると期待されます。すなわち、オブジェクト指向言語なしで、その狙いをカバーするものに
なるのではないかと思われるのですがいかがでしょう。またAP側も、一覧表型、ヘッダー
ディテール型、マトリックス型、個票型、など画面・帳票のパターンを用意することによって、
大幅にプログラミング工数を削減することができると考えます。

■課題
この場合心配は、次のようなものかと思われます。
①すべてのDIを受け止めるリポジトリ構造が設計できるか 
②これを活用する、十分な効率を持つ、iDBMSが設計できるか
③データモデラーが、リポジトリに登録すべき高品質のデータを効率よく作れるか

もちろん、世の中のすべての加工データについて検証したわけではありませんが、筆者は①は、
ほぼ完成に近いものが設計できている、ただし、②における機械効率のための工夫がリポジトリ
構造にも必要と考えますので、この課題が若干残されているかと考えます。DIはビジネスルール
/業務知識の中核であり、これは「プログラムで書くもの」との先入観を持っておられる方もある
ようですが、私はメタデータとしてリポジトリに記述すべきもの、これによって実装独立段階の
仕事にできる、と考えています。

②は、これから実証すべきテーマですが、1個のプログラムが対象であり、多少の試行錯誤はある
でしょうが、必ず解決できる課題と考えます(注3)。

③は、これまでSEをやっていた、多くの新参データモデラーにとって未経験の部分を含んでい
ますので、設計手順や教育など、まだ課題が残されているかと思われます。しかし、プログラミ
ングのような個人差が発生しませんので、さほど難題ではないと思われます。

また、当面iDBMSが用意できなくても、APのロジックからiDBMS部分を分割し、この
設計をデータモデラーの担当とすることによって、大幅な合理化が達成できると考えます。

(注3)方式としては、事前にプログラムを自動生成しこれをiDBMSから呼び出すプログラム
ジェネレータ方式(コンパイル方式とも呼ぶ)と、実行時リポジトリを解析して動くインタープリ
ーター方式があるかと思われます。技術的には前者が易しいと思われます。

なお、科学技術計算などの加工データ-たとえば流体の流量対応のパイプ径、地震に耐える鉄骨寸法、
流体の温度・圧力での蒸気圧など-は、自動生成でなく従来どおりのプログラミングを行い、
iDBMSから加工ロジックとして呼び出すのが適切かと思われます。


【153号】 IPFチャートの設計条件

2009/07/01

■IPFチャートの成り立ち
IPF(Information Process Flow)チャートは、弊社が標準としている業務フ
ローチャートです。古くはDFD、UMLのアクティビティ図、最近話題のBP
MNとほぼ同じ粒度の業務プロセスを記述する図といえます。
『【153号】 IPFチャートの設計条件』の続きを読む・・・


【152号】 現行DBMSの欠陥

2009/06/01

■現行DBMSの欠陥
現行DBMSとは、ほとんどRDBMSかと思われます。RDBMSは構造型D
BMSのポインター操作からプログラマーを開放し、オプティマイザーを始め多
くの改良を施し、E. F. Coddの提案する12のルールを消化して、多くの情報シ
ステムの不可欠の基盤となっています。しかし一方、いま多くの情報システム部
門の抱えている問題のうち、現行RDBMSに起因すると考えられるものも少な
くないので、これについて私見を述べたいと思います。

『【152号】 現行DBMSの欠陥』の続きを読む・・・


【151号】 ユーザ企業の役割、SIerの役割

2009/05/01

■情報システムアーキテクチャの進化
情報システムアーキテクチャは、相互に通信すべきメッセージデータ(=トラン
ザクションデータ、イベントデータ)の通信の方式によって、
 G1:ロウレベルPOA(個別プログラムが適宜データを通信する)
 G2:ロウレベルDOA(プログラムはアプリDBを介してデータを通信する)
 G3:ハイレベルPOA(アプリ同士適宜データを通信する)
 G4:ハイレベルDOA(アプリはアプリ間通信場DBを介してデータを通信
する)
のように、進化するかに見えます。
『【151号】 ユーザ企業の役割、SIerの役割』の続きを読む・・・