» 【第93号】ハイレベルDOA

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

DRI通信93号「ハイレベルDOA」       2004.6.1
ゴールデンウイークに山で痛めた脚が治ったら、もうアジサイが咲いてホトトギスが鳴く6月です。皆様、今期の出足はいかがですか。
5月28日に行われたDOA+第2分科会はウルシステムズさんから、UMLautの紹介がありました。生産性を挙げるべくJ2EEを補強したソフトウエアフレームワークを基に、SQLを含むJAVAプログラムを自動生成する点はOOなのでしょうが、オブジェクトの再利用はねらいでなく、RDBベースなので分析設計はDOA、そしてORならぬROマッピングというきわめてDOA的なものでした。
また、最近NECの桧垣さんからうかがった言葉、「建築工学の卒業生はアーキテクチャを学んでくる。しかし情報工学の卒業生はプログラミング言語を学んでくるだけで、アーキテクチャを知らない。鉋の使い方、釘の打ち方を習得してくるようなものだ」は印象的でした。情報工学の先生方、何とかしてください。
■DOAの分割
データ中心アプローチ、DOAといっても、いろいろな流儀があります。これを整理することを考えていたときに、ひとつのアプリケーションの中で考えるDOAと、異質なアプリケーション横断(注1)で考える、いわば2階建てのDOAとがあり、これを意識すべきことに気づきました。前者をロウレベルDOA(lDOA)、後者をハイレベルDOA(hDOA)と呼ぶことにします。DOAとしてのねらいも、両者で若干異なります。
(注1)横断対象となるアプリケーションには、何らかの壁があるものとします。ユーザの職種の違い、顧客の業界の違いなどにより、用語/文化がちがったりします。過去のシステム化の歴史の違いや、ハードやソフトの環境の違いも多くみられます。これらが壁をつくるものと思われます。


■lDOA
当該アプリケーション1個を対象にするlDOAが目下メジャーなようです。SIへの発注の大部分がアプリケーション単位になるため、アプリケーション横断のニーズなどあまり取り組んだことがなかった、という人が多いためかとも思われます。OOの方々の話題にするDOAも、異質なアプリケーションの壁への取り組みは見られず、結局等質なlDOAを念頭においたものがほとんどのように思われます。
はじめは構造型DBMSを、そして今ではリレーショナル型DBMSを使って、n個のアプリケーションプログラムがデータを共用するシステムを、データ中心/データ先行で設計・構築するものです。定期的なバッチ処理は別にして、更新や検索のプログラムは非同期に自由に実行することができます。順ファイルをバケツリレーしながら走らせる、かつてのCOBOL時代のプログラムと比較して大きな自由度が獲得されました。DBはデータのストレージであると同時にn個のアプリケーションの通信する場となったわけです。そのみそは、データ定義をプログラムの支配下から、ディレクトリとしてDBの支配下に移し標準化したことにあります。
しかし、ほとんどの場合、DBは1個、J.マーチンの言うアプリケーションDBを作るものでした。ポイントは、使いやすい個別システムを、いかに速く安く作るかだといえるでしょう。人・組織・モノなどのリソースデータはイベントデータと混在・同居することになりました。したがってそのリソースデータは、そのアプリケーションの「偏見」を持つものとなりました。アプリケーション横断のDWHやERPの用途には、使うことができません。
■hDOA
hDOAは、アプリケーション横断のDOAです。データ総研のDOAは、はじめからこれを指向したものでした。人・組織・モノなどのリソースデータはアプリケーション横断に共用されますから、各業務DBから分離し、集中します。DB構造図もリソース系用に1枚独立したものを作ります。アプリケーションごとの「偏見」は、この上で自然調整されることになります。販売、生産、経理、人事などのDBは、それぞれ独自の目的を持つものとして管理されますから、これらは主としてイベント系ファイルから構成されたものとして残されます。
したがってhDOAでは、たまたま最初のプロジェクトで1個のアプリケーションしか対象にしないときでも、リソース系DB1個とイベント系DB1個を、別々に作ることになります。リソース系DBはその後、追加アプリケーションのニーズを調整・吸収しながら拡大されていくわけです。またあるアプリケーションについては、パッケージやレガシーの改造で間に合わせることもありえます。このときはリソースデータに「偏見」がのこされますから、いわば方言と標準語の変換機構を取り付けて対応することになります。
■オペレーショナルDWH
hDOAでは、もう一つ共用の器が必要になります。各アプリケーションはそれだけでは閉じていない、すなわち他のアプリケーションの状況を参照しなければならないことがあるからです。たとえば営業アプリケーションとしては、品物Aが100個いつ完成するかを知りたい、また生産では品物Aの売上が増加基調なのかどうか知りたいなど。とくにCRMのコールセンターなどでは販売、生産、購買、物流、アフターケアなど各種アプリケーションの状況を、事業部をまたがって参照する必要がありえます。このようなアプリケーション横断に参照される業務状況を示すイベントデータ(これをハイレベルメッセージと呼ぶことにします)をストアするための器です。
このハイレベルメッセージのための器に対する関心の高まりは、ごく最近のことのようです。私はオペレーショナルDWHと呼んでいましたが、エンタープライズDWHとかリアルタイムDWHと呼ぶ記事が目立ってきました。DWHと言うとバッチで集計するアナリティカルDWHを想定しがちですが、オペレーショナルDWHは共用されるべきイベントデータを発生時そのまま非同期にコピーして作るものです。共用メッセージDBということもできます。戦略用途でなく戦術用途ですが、参照専用という意味ではDWHとして分類できるでしょう。これがアプリケーション間のメッセージ通信場を用意するわけです。ワークフロー機能を用いて、ユーザにこれをPushすることもできますが、基本はユーザが必要の都度Pullして参照することになります。
このような他のアプリケーションの状況の参照ニーズは従来もあったわけですが、電話や紙で間に合わせたり、緊急度が高い場合だけ他DBを参照するインターフェースを場当たり的に作りこむなどの対策が講じられていたようです。これはしかし昔のバケツリレーの発想と変わりません。たとえWeb サービス技術を使っても、スパゲッティインターフェース地獄にはまる危険性が多々残されています。やはりアプリケーション間においてもDBによる通信場通信を考慮しなければならないと思われます。そしてこれはERPのアプリケーション統合の機能を代替することができます(アプリのロジックは別です)。
■アプリケーションの単位
hDOAでは、在庫更新にちょっとした配慮が必要ですが、対象はメッセージだけですから、lDOAにおけるようなユーザインターフェース設計や加工データの整合性に伴う面倒はいりません。リポジトリとしてもメッセージ(IOのサブタイプ)とこれに関係するエンティティおよびアトリビュートだけが対象になります。
したがって、アプリケーション1単位をいかに設定すべきかが、一番の課題かと思われます。アプリケーションの設定が大きすぎると管理が難しくなります。独立に扱えるものである限り、小さい単位が良い。しかし小さすぎるとオペレーションでの同期が必要になり、独立性が失われてしまいます。一般には「加工データと加工元データが2つのアプリケーション(注)に分かれない」といった条件があるかと思われます。
(注2)加工元データがリソース系にあるのはかまわない
■3種のインフラ系DB
しかし、リソース系データがアプリケーションごとに散在することを除けば、現状のアプリケーション単位の設定でも問題のあるケースは少ないようです。これが妥当ならば(注3)、各アプリケーションの運用に必要な他のアプリケーションのメッセージを洗い出し、これを集めてオペレーショナルDWHとして共用に付すことができます。こうして、
・ リソース系DB(共用のための参照専用のコードデータ)
・ オペレーショナルDWH(共用のための参照専用のイベントデータ)
・ メタデータ系DB(統制のための参照専用のメタデータ)
の3種のインフラ系DBが構成され、このもとに各業務系DBが運用される、かなりすっきりしたアーキテクチャが用意できると考えられます。
(注3)アプリケーションの単位が大きすぎると、ハイレベルメッセージが少なくなり、逆に小さすぎると多くなります。客観的基準は難しいので、識者のセンスにたよることになりますが、稼動後に追加・削除する負荷はさほど大きくないと思われますので、はじめから完全をねらわず試行錯誤を行うのが現実的と思われます。
■フェデレーション・アーキテクチャ
hDOAにおいては、アプリケーション内部でのみ、やり取りされるメッセージは、隠蔽し触らないでおくことができます。SOA(Service Oriented Approach)方式による、フェデレーション・アーキテクチャといえるでしょう。たとえば生産システムと営業システムとの間では、日程生産計画、生産指図、投入実績、生産実績、受注、納期回答、出荷実績などはハイレベルメッセージとして公開されますが、棚入れ、棚間移動、出荷指図、ピッキングなどはロウレベルメッセージとして、システム内に隠蔽されます。
いまやシステムは巨大です。一挙に全社システムを再構築、などできるはずもありません。「まだまだ使えるレガシーシステム」は後回しにしなければなりません。購入パッケージを活用する必要もあるでしょう。そしてこれら異質のアプリケーション間でのシームレスなデータ流通による、スピーディな全体最適が要求されています。そのような場合、このフェデレーション・アーキテクチャが、活用できるものと考えます。
なおこの2階建てDOAについては、日経BPのEA大全およびソリューションITにも寄稿しておりますので、お知らせします。