» 【第88号】情報システムのアーキテクチャの進化

株式会社データ総研 データ総研のオンサイト教育
製品案内 DMBOK ITコンサルティングサービス ITコンサルティング事例 紹介セミナー 教育コース 技術情報 DRIブログ 会社概要
技術情報
【第88号】情報システムのアーキテクチャの進化

DRI通信88号「情報システムのアーキテクチャの進化」  2004.1.5
あけましておめでとうございます。おだやかな年明けでした。皆様お元気ですか。昨年末DOA+コンソーシアムを立ち上げました。今年こそDOA氷河期を終わらせたいと期待しています。データの図面を共有して、環境変化に柔軟に対応できる全体最適化の条件を整備したいものです。どうぞよろしくお願いします。
■ アーキテクチャへの関心
EA(Enterprise Architecture)が話題となり、ITアーキテクトといった肩書きの名刺を頂いたりするこのごろ、情報システムにおけるアーキテクチャへの関心が高まりつつあるかに見えます。アーキテクチャはシステムの寿命に関わります。10億円かけて開発して、5年で陳腐化するか、15年持つかは大違いですが、従来あまり問題にされてこなかったようです。うすうすこれを感じて問題にし始めたということでしょうか。
ハードの世界では、90年代ホスト(主人)がサーバー(僕、しもべ)にリプレースされ、さらに今これがWebの海に浮かぶというアーキテクチャの変革が進みつつあるわけですが、最近のアーキテクチャは主に90年代、短期ソリューションを目指して出来上がったバラバラシステムを、統合連携させようという、ソフトや業務モデル寄りのものに見えます。


ソフトの2大要素といえば、プログラムとDBであり、言語と正規化を勉強すればなんとかなる、といった感覚かと思われますが、アーキテクチャ問題をこなしていくための武器、その基本コンセプトは何でしょうか。経験に基づく単なる属人的知恵でもなさそうです。
■ システムアーキテクチャの進化
そこでシステムアーキテクチャはどのように進化していくものかを考えてみました。目下次ぎの5段階で整理できそうに思われます。
L1:バケツリレー
L2:アプリケーションDB
L3:リソースDBの独立・共用
L4:リポジトリによるメタデータ一元管理
L5:リアルタイムDWHの独立・共用
■ プログラム中心からデータ中心へ
L1は順次ファイルによりプログラムからプログラムへデータを受け渡しする最も古いアーキテクチャです。電話や手紙のように通信の相手が固定されていて、実行の順序が固定されています。SEというよりプログラマーが、当該プログラム中心の発想でプログラミングをしていた時代です。DBMSが登場してきても、はじめは階層や網構造が表現できることを利用するだけで、プログラム中心の世界観から抜け出すまでには時間がかかりました。当該プログラムはプログラマーの自我の反映といった面があり、天動説的な世界観を作りやすい。天動説の地球人と天動説の火星人が話し合ってどうも話が合わない、そして模索して太陽中心の地動説にたどり着く。このように私は、これは処理中心のアプローチに常に伴う、人間の性にもとづく問題で、そこからの脱却にはかなりの時間が必要らしい、と考えて来ましたがいかがでしょうか。
DBMSはデータ構造を表現できる高級なファイル機能を持つものですが、いくつものプログラムが通信する場としての意味の方が大きいと私は考えます。それまでの固定化されたプログラム間の通信が、伝言板/Broadcast & Subscribe方式となり、DBを介して、各プログラムは独立に実行できるようになりました。正規化により原則として冗長性を排除し、One Fact in One Placeの原則が実現できました。プログラムはDBのデータの仕様だけを考慮すればよい、L2のアプリケーションDBによる、いわゆるデータ独立性の実現です。
■ リソースデータの共用
しかし、L2のアプリケーションDBでは、アプリケーション横断的に見ると、製商品・原材料や、社内外人・組織など、リソースデータが重複してストア・維持管理されています。リソースデータとは販売や生産などのイベント(トランザクション)データに関わるリソース(コード)を定義するもの、いわば新聞記事に対する用語辞書/広辞苑のようなものです。これが方言のようにいろいろあっては維持コストがかかるだけでなく、データのやり取りに支障をきたす。これを一元化・共用するためにリソースDBを独立させたい。これがL3のリソースDB独立のアーキテクチャになり、リソースデータに関するOne Fact in One Placeが実現されます。ERPにもこのリソースの準備が必要です。よくERP失敗談を聞きますが、L3レベルの会社での失敗はほとんど聞きません。
■ メタデータ管理
よほどのレガシーシステムでない限り、どこの会社でもレコードフォーマットは管理しています。横長の物理レコード形式を記述した紙から、WORDやEXCEL、さらにDD/Dやリポジトリと、その管理媒体は進化してきたわけですが、データ項目を中心とするメタデータ管理には、いまだ多くの課題が残されています。業務やITに関わるメタデータの構造に関するコンセンサスが未熟ですし、本格的アプローチは標準化レベルの高いL3をクリアした会社が、長期的ROIを設定してはじめて取り組める課題だからです。短期的ROIですと、かなり限定されたメタデータにしか取り組めませんので、効果も中途半端になり、挫折する危険性が高くなります。しかし競争激化の中、速く安く高品質の情報サービスを提供するには不可欠の方向であり、各企業環境に合ったL4へ向けての粘り強い接近が必要とされています。L4の段階では、メタデータに関するOne Fact in One Placeが実現されることになります。
■ リアルタイムDWH
システムは、業務の種類や目的対応に構築されますが、他システムへの可及的速やかな、依頼や回答、また他システムの状況の把握などが必要になります。これらにもぐらたたき的に対応していては、システム間にスパゲッティ的コミュニケーション経路が発生し、後の混乱の原因を作ります。そこでシステム間でやり取りされるべき、「ハイレベルメッセージ」のみを、イベント発生の都度、疎結合形式でリアルタイムDWHにストアするアーキテクチャを、L5として提案しました。経営トップの要求するダッシュボードは、これをベースに容易に作ることができると考えます。このリアルタイムDWHは原則として、1企業1個ですから、データの仕様は企業標準に則ったものでなければなりません。
したがって個別業務アプリケーションとして、レガシーシステムや、パッケージを使うときは、形式や値の変換を必要とします。リアルタイムDWHによってシステム間のコミュニケーション問題が解決されますが、これはERPの狙いを別の形で実現しますので、レガシーやパッケージを、独立性の高い形で運用したい場合の有効な選択肢となると考えます。
L5においては、システム間でやり取りされる「ハイレベルメッセージ」のOne Fact in One Placeが実現されることになります。こうして共用される3つの参照専用のDB−リポジトリ・リソース・リアルタイムDWH−を、データインフラと定義したいと思います。こうしてDBには、この3種のインフラと各業務のためのイベント系のDBを加えた4種類があると考えました。
■ One Fact in One Placeが推進力
結局この5段階のアーキテクチャの進化の柱は、One Fact in One Placeになるように思われます。この進化の過程をSAMM(System Architecture Maturity Model)と呼びたいと思っていますがいかがでしょうか。
なおDB設計における正規化もOne Fact in One Placeの実現です。したがって逆にこれらをすべて広義の正規化ということもできるかと思います。そしてもっと砕けて言えば、中学で習った「因数分解の情報への応用」とも言えそうです。