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

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

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