前回は，アーキテクチャという言葉に多様な意味があり，事前の定義なしに議論を進めることは危険であると述べた。この連載では，特に断らない限り，アーキテクチャという言葉を「テクノロジ・アーキテクチャ（プラットフォームの標準）」ではなく，「アプリケーション・アーキテクチャ」，つまり，標準化されたアプリケーション設計仕様という意味で使用していくことにしよう。

◆アーキテクチャのスコープ

　アプリケーション・アーキテクチャを考える場合に，多くの企業が見落としている重要なポイントにアーキテクチャのスコープ（適用範囲）がある。アーキテクチャのスコープは大きく以下の3種類に分けられる。アーキテクチャ構築プロジェクトを失敗させない最大のポイントが，このスコープの概念の理解にあると言っても過言ではないだろう。

1．アプリケーション内のアーキテクチャ（建築図面型アーキテクチャ）：

　このアーキテクチャは，従来からある「プログラムの基本設計」という言葉と大きく変わることはない。要するに，UML（Universal Modeling Language）[用語解説] ，DFD（Data Flow Diagram）[用語解説] ，ER（Entity-Relationship）図[用語解説] などの手法を使って作成されるアプリケーションの厳密な仕様である。例えて言えば，建築物の設計図面に相当するだろう。

　相当にひどい開発プロジェクトでない限り，このアーキテクチャなしにアプリケーションを構築することはないだろう。相当の欠陥住宅でもない限り，設計図面なしに家を建てることはないのと同様である（ただし，現実にはアプリケーション構築中に要求仕様の変化により，元となるアーキテクチャがどんどん変わってしまう場合も多い。これは，重要な課題ではあるが，どちらかというとアーキテクチャとしての議論よりも，プロジェクト・マネジメントやITガバナンスの課題として考えるべきだろう）。

2．アプリケーション・システム間のアーキテクチャ（都市計画型アーキテクチャ）：

　このアーキテクチャは，企業内に存在する多数のアプリケーションをどのように連係させていくかべきかを定めるアーキテクチャである。このアーキテクチャは都市計画に例えることができる。都市計画では，さまざまな建物やインフラ施設を限られた土地にどのように配置すれば，最も住みやすい都市ができるかを考えるのと同様に，このアーキテクチャでは建物に相当するアプリケーション群を企業内でどのように配置し，連係させていくがが主眼となる。

　今，特に，この種のアーキテクチャに注目が集まっており，アーキテクチャ＝都市計画という認識が広まっている点（関連記事）は納得できる。「建築図面としてのアーキテクチャ」の利用は昔から自明であったが，最近まで「都市計画としてのアーキテクチャ」はあまり注目されておらず，個々の建物は立派だが都市としては決して住みやすくないと言う状況に近い情報システムが多かったからである。要するに部分最適化はできているが，全体最適化ができていないという状況である。

3．企業間連携のアーキテクチャ（国際条約型アーキテクチャ）：

　アーキテクチャは企業内だけでなく，関連する企業間のB2Bのやり取りにも適用することができる。ちょっと例えが苦しいかもしれないが，国家間の取り決めを定めた条約のようなアーキテクチャと言えるだろうか。

◆スコープが拡大するにつれ柔軟性が重要になる

　ここで，スコープが変わることで，求められるアーキテクチャの特性も変わってくる点に十分な注意が必要だ。明らかに建築図面型アーキテクチャでは，厳密な仕様の規定が必要である。そうでなければ，まともなアプリケーションを構築することはできない。1つのアプリケーション内でデータ設計，プロセス設計，オブジェクト設計，コンポーネント設計などが標準化されているのは当たり前のことである。

　しかし，都市計画型，国際条約型とアーキテクチャのスコープが広がるにつれて，厳密性の要件よりも柔軟性の要件の方が重要になってくる。例えば，複数のアプリケーションにまたがって同じデータ設計やコンポーネント設計を適用することは不可能，ないし，可能であっても望ましくない場合も多い。この場合には，疎結合型のアプリケーション連係を前提としたアーキテクチャが必要となってくるわけである。

　少々概念的な話になってしまったかもしれない。次回は，上記のポイントを実例を交えつつ，もう少し突っ込んで考えてみることとしたい。