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

株式会社データ総研 データ総研のオンサイト教育
製品案内 DMBOK ITコンサルティングサービス ITコンサルティング事例 紹介セミナー 教育コース 技術情報 DRIブログ 会社概要
技術情報
【159号】「3階層通信場をサポートするリポジトリ」

■概念ミドルウエア
先の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でのスムーズな連携が可能になると考えました。

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