エグゼクティブ サマリ

Michael Platt
Microsoft Corporation

July 2002
日本語版最終更新日 2002 年 12 月 3 日

目次

エンタープライズ アーキテクチャ
アプリケーションおよびテクノロジ アーキテクチャ
概念的、論理的、および物理的ビュー
アプリケーション アーキテクチャ
アプリケーション パターン
テクノロジ アーキテクチャ
テクノロジ パターン

このドキュメントは、Microsoft のエンタープライズ、アプリケーション、およびテクノロジ アーキテクチャに対するアプローチを理解したいと考えているビジネス、ソフトウェア、およびインフラストラクチャ アーキテクトを対象としています。アーキテクチャの用語、パターン、および概念と、一連のビューまたはレベルとしてのアーキテクチャの定義を示しています。

エンタープライズ アーキテクチャ

ANSI/IEEE 規格 1471-2000 では、アーキテクチャを次のように定義しています。「システムのコンポーネント、コンポーネント同士と環境との間の関係、およびその設計と進化を支配する原理に体現された、システムの基本的な構造」。

エンタープライズ アーキテクチャ (EA) は、組織が自らの構造とその動作を理解するのを手助けする概念的なツールです。企業のマップを提供し、ビジネスとテクノロジ上の変化のためのルート プランナーの役割を果たします。

通常、エンタープライズ アーキテクチャは、企業の構造と機能を記述する、ひとまとまりのモデルの包括的なセットの形を取ります。重要な用途としては、体系的な IT プランニングとアーキテクチャの作成、および高度な意思決定があります。

EA 内の個々のモデルは論理的な形に配置されており、以下に示すように、企業の情報を徐々に細分化して提供します。

• その目的と目標
• そのプロセスと構造
• そのシステムとデータ
• 使用されるテクノロジ

Microsoft のアーキテクチャの視点

エンタープライズ アーキテクチャの中の情報は、さまざまな視点から見ることができ、さまざまなニーズに応えることができます。アーキテクチャのユーザーには、ビジネス マネージャとアナリスト、システム アーキテクトとデザイナ、ワークフローおよびプロシージャ アナリスト、ロジスティクス専門家、組織アナリストなどが含まれます。これらの人々は、高レベルの集計情報、詳細データ、そしてこの 2 つの間のあらゆるレベルの情報を必要とします。このニーズは、概念的ビュー、論理的分析、および物理的インプリメンテーションの作成を通して満たされます。

Microsoft は、4 つの一般的な視点を重要と見なし、広く使用しています。これらは、ビジネス、アプリケーション、情報、およびテクノロジの視点です。

ビジネスの視点

ビジネスの視点は、企業がどのように動いているのかを記述します。これには広範囲のビジネス戦略と、組織を現在の状態から未来の想定された状態へと移行させるための計画が含まれます。一般には以下のものが含まれることになります。

• 企業の高レベルの目的と目標
• 企業全体、またはその大部分が実行するビジネス プロセス
• 実行されるビジネス機能
• 主な組織構造
• これらの要素間の関係

アプリケーションの視点

アプリケーションの視点は、企業のアプリケーション ポートフォリオを記述するもので、アプリケーション中心型となります。このビューには、一般に以下のものが含まれます。

• ビジネス プロセスをサポートする自動化されたサービスの記述
• 組織のアプリケーション システムの相互作用と依存関係 (インターフェイス) の記述
• 企業の目的、目標、および進化を続けるテクノロジ プラットフォームに基づいて、新しいアプリケーションを開発し、古いアプリケーションを修正するための計画

アプリケーションの視点は、共通のビジネス目標を達成するために異なるスキルと業務のユーザーをリンクする、組織の境界を越えるサービス、情報、および機能を捉えることができます。

情報の視点

情報の視点は、組織がビジネス プロセスと業務を実行するために知っておかなくてはならない事柄を記述します。これには以下のものが含まれます。

• 標準データ モデル
• データ管理ポリシー
• 組織における情報の生産および消費パターンの記述

また、情報の視点は、データがワーク フローにどのように結び付けられているかも記述します。これには、データベースなどの構造化データ ストアと、組織全体に分散しているドキュメント、スプレッドシート、およびプレゼンテーションなどの非構造化データ ストアが含まれます。

テクノロジの視点

テクノロジの視点は、組織をサポートしているハードウェアとソフトウェアを記述します。これには以下のものが含まれます (これらに限定されません)。

• デスクトップおよびサーバー ハードウェア
• オペレーティング システム
• ネットワーク接続部品
• プリンタ
• モデム

テクノロジの視点は、アプリケーションの視点と情報の視点をサポートするために必要なインフラストラクチャとシステム コンポーネントの、論理的な、特定のベンダに依存しない記述を提供します。ビジネス ミッションを遂行するために必要なテクノロジ標準とサービスのセットを定義します。

視点は数多く存在しますが、これらの視点から見ることになるエンタープライズ アーキテクチャは 1 つしか存在しません。エンタープライズ アーキテクチャの価値は、個々の視点にあるのではなく、これらの視点間の関係、相互作用、および依存関係にあります。

すべての視点がエンタープライズ アーキテクチャの重要な要素となりますが、このドキュメントではアプリケーションとテクノロジの視点に焦点を当てることにします。

アプリケーションおよびテクノロジ アーキテクチャ

ソフトウェア システムの機能要件は、そのソフトウェアが提供するビジネス上の価値を記述します。たとえば天候情報サービスの機能要件は、「適切な形式のメッセージ A を入力として与えられたとき、サービスはメッセージ A で表現された時間枠と地理的位置に応じたメッセージ B を返す」というようなものになります。

アプリケーション アーキテクチャは、このような機能要件をサポートし、インプリメントする任意の自動化されたサービスのアーキテクチャです。これには、ビジネスおよびその他のアプリケーションへのインターフェイスが含まれます。これはアプリケーションの構造と、その構造が組織の機能要件をどのようにインプリメントするかといった事柄を記述します。理想的には、1 つの組織には 1 つのアプリケーション アーキテクチャが存在するべきですが、現実には多数のアプリケーション アーキテクチャが存在しています。

ソフトウェア システムの運用要件は、ソフトウェアの信頼性、管理可能性、パフォーマンス、セキュリティ、および相互運用性などの要件を定義します。例としては、サービスは認可されたサブスクライバのみが利用でき、99.999% の時間は正常に動作していなくてはならないというような要件が考えられます。

テクノロジ アーキテクチャは、組織をサポートするハードウェアおよびソフトウェア インフラストラクチャのアーキテクチャであり、運用 (すなわち非機能) 要件、特に組織のアプリケーションおよび情報アーキテクチャをインプリメントします。使用されているテクノロジの構造と相互関係、およびこれらのテクノロジが組織の運用要件をどのようにサポートするかを記述します。

優れたテクノロジ アーキテクチャはセキュリティ、可用性、および信頼性を提供することができ、その他のさまざまな運用要件をサポートすることができますが、アプリケーションがテクノロジ アーキテクチャの特性を活かすように設計されていなければ、不十分なパフォーマンスしか出せなかったり、配置と運用が難しくなったりします。同じように、ビジネス プロセス要件に正確に対応し、最新のテクノロジを使った再利用可能なソフトウェア コンポーネントから作られた、適切に設計されたアプリケーション構造であっても、サーバーがアプリケーション コンポーネントを適切にサポートできるように構成されていなかったり、ネットワーク ハードウェアが情報のフローをサポートできるように設定されていなければ、現実のテクノロジ構成は不十分なものになりかねません。これらの例は、アプリケーション アーキテクチャとテクノロジ アーキテクチャには関連性があることを示しています。優れたテクノロジ アーキテクチャは、組織にとって重要な特定のアプリケーションをサポートするように構築されます。優れたアプリケーション アーキテクチャは、テクノロジ アーキテクチャを活かして、すべての運用要件について一貫性のあるパフォーマンスを実現します。

図 1. アーキテクチャ間の関係

概念的、論理的、および物理的ビュー

アーキテクチャのすべての視点で、そのアーキテクチャについてのさまざまなビューが存在し、これらは一般に概念的、論理的、および物理的ビューに分類されます。 概念的ビューは最も抽象的なもので、システムの (IT プロフェッショナルでない) ユーザーが最も慣れ親しんでいる用語を使って記述される傾向があります。概念的ビューは、機能要件と、アプリケーションのビジネス ユーザーがビジネス モデルを生成するために使用するビューを定義するために使用されます。 論理的ビューは、主な機能コンポーネントと、それらのシステム内での関係を、機能の技術的なインプリメント方法とは独立に示します。アーキテクトは、ビジネス目標と要件を満たす方法を考える中で、ビジネス モデルの論理的ビューであるアプリケーション モデルを作成します。アプリケーション モデルは、アプリケーションのアーキテクチャの論理的ビューを表現します。 物理的ビューは最も抽象度が低く、具体的なインプリメンテーション コンポーネントとそれらの間の関係を示します。物理的ビューの中の個々の要素は、通常は設計および開発プロセスによって、ソフトウェアまたはハードウェア システムとしてインプリメントされます。このインプリメンテーション ビューは、通常は組織内の開発または運用組織がオーナーとなるので、このドキュメントの対象外となります。

図 2. アーキテクチャのビュー

個々のアーキテクチャ レベルには複数のビューが存在しえます (また通常は実際に存在します)。たとえば、通常は 1 つのアプリケーションにつき 1 つの論理的アプリケーション アーキテクチャ ビューが存在します。

これらのビューは要件のセットによってドライブされ、設計、開発、セットアップ、および運用プロセスとシステムへのインプットを生成します。

図 3. アーキテクチャのビューとパターン

本ガイドの残りの部分では、アプリケーションおよびテクノロジ アーキテクチャと、Web サービスという新しいテクノロジを利用したサービス ベースのアプリケーションを構築する際に使用される概念と主なパターンに焦点を当てます。設計、開発、セットアップ、配置、および管理を含むインプリメンテーションの領域は、全体的なシステム生成における重要な話題ですが、このドキュメントの対象外となります。

アプリケーション アーキテクチャ

すでに述べたように、アプリケーション アーキテクチャは概念的、論理的、および物理的の 3 つのビューを持っています。これらのビューは、アーキテクトによって、ビジネス要件をサポートし、それらを満たす組織内のモデルを生成するために使用されます。理想的には 1 つのビューにつき 1 つのモデルが存在するべきですが、現実には 1 つのビューに複数のモデルが存在することがあります。これは、組織とテクノロジの成長と変化の結果です。ただし、これらのモデルを最小限の数に抑えることが、効率的で柔軟性のある編成を実現する上での鍵となります。

概念的ビュー

概念的ビューは、ビジネス要件と、アプリケーションのビジネス ユーザーがビジネス モデルを生成するために使用するビューを定義するために使用されます。ケース分析、アクティビティ ダイアグラム、プロセス デザイン、およびビジネス エンティティ モデリングなどの概念的モデリング テクニックは、主要なビジネス プロセスとそれらが使用するデータを、ビジネス目標と要件を強調し、インプリメンテーション テクノロジから独立した形で記述するのに役立ちます。

論理的ビュー

アーキテクトは、ビジネス目標と要件を満たす方法を決定するなかで、ビジネス モデルの論理的ビューであるアプリケーション モデルを作成します。アプリケーション モデルはアプリケーションのアーキテクチャの論理的ビューを表現します。

この際に、アーキテクトはアプリケーションの全体的構造に関心を持ちます。データ管理とプロセス ステップのマッピングを決定し、モデルの各部分の相互作用を論理的なメッセージとシーケンスの観点から設計し、モデルがどのようなデータと状態を保持するべきかを決定します。

物理的ビュー

アプリケーション モデル内の個々の要素は、現実のテクノロジの要素へのマッピングを必要とします。これにより、アプリケーション モデルはインプリメンテーション モデルとして現実化されることになります。このタスクの一部は、プログラマが詳細なビジネス ロジックをコードとして作成する通常の開発作業のなかで行われますが、インプリメンテーション活動の多くの部分はフレームワーク コンプリーションという概念に分類することができます。これは、分散型のアプリケーションとデータ管理のインフラストラクチャの多くの部分を、カスタム アプリケーション ロジックと宣言型制御構造によって拡張された高度なフレームワークを使って処理する開発テクニックの 1 つです。フレームワーク コンプリーションにより、開発者から非同期的メッセージ処理などの細かい部分が隠蔽され、平均的なスキルを持った開発者でもプロジェクトに効果的に貢献できるようになります。

組織のためのこれらのモデルをあらゆるレベルで設計し、構築する作業は、明らかに多大な労力を要します。さらに、これらのモデルが正しく定義されることは、組織にとってきわめて重要です。アーキテクチャ モデルが不適切だと、ほぼ確実にスケーラビリティや信頼性の点で深刻な設計または運用上の問題が発生し、最悪のケースではプロジェクトが途中で挫折し、ビジネスに悪影響が及びます。アーキテクトは、これらのモデルの作成とインプリメンテーションを支援し、不適切なモデルの使用に付随するリスクを最小限に抑えることができるフレームワークとロードマップを求めています。

アーキテクトがモデルの生成に要する期間を短縮し、リスクを最小限に抑えるために利用できるアーキテクチャ上のガイダンスとアシスタンスには、主に 2 つのタイプがあります。

第 1 のものは、以下のものを提供するアーキテクチャ概念のセットです。

• 共通の理解とコミュニケーション
• 特定の概念をいつどのように使用すべきかというガイダンスと、それらの属性についての情報
• これらの概念が、ガイダンスまたは現実のテクノロジの形でいつ実現され、利用可能になるか

第 2 のものは、これらの基本概念から構成された多数の成功した分散型アプリケーションにおける現実の経験に基づくパターンのセットです。これらのパターンは、分散型アプリケーション設計の重要なベスト プラクティスをカプセル化したものであり、既知の優れたテスト済みのアーキテクチャ モデルを提供することで、プロジェクトが失敗するリスクを最小限に抑えます。

図 4. アプリケーション アーキテクチャのビュー

この 2 つのガイダンスのセット、すなわち概念とパターンは、概念的レベル (ビジネス モデルの概念とパターン)、論理的レベル (アプリケーションの概念とパターン)、およびテクノロジのレベルに関わってきます。これらの概念とパターンが提供されることは、システムの迅速かつ低コストでのインプリメンテーションの成功と、組織によるテクノロジの採用にとっての鍵となります。

アプリケーション アーキテクチャ: 概念的ビュー

過去において、アプリケーションはファイル システムやデバイス ドライバなどのローカルなシステム サービスを統合することによって構築されてきました。このモデルは、多様な開発リソースのセットを提供し、アプリケーションの動作を細かく制御できるという点できわめて柔軟性の高いものでした。しかし、誤りが生じやすく、コストと時間のかかるものでもありました。

今日では、複雑な分散型アプリケーションは、ネットワーク上の既存のアプリケーションとサービスを統合し、ビジネス エンティティ、データ エンティティ、およびファサードなどの要素を使ってそれに独自の価値を付加するという方法で構築されるようになっています。これにより、開発者は独自のビジネス バリューの提供に専念できるようになります。その結果として、開発期間が短縮され、開発者の生産性が向上し、究極的にはソフトウェアの品質が高まることになります。これは長年にわたって強力なアーキテクチャ モデルとして使用されてきましたが、アーキテクチャの再利用に大きな問題をもたらす「アプリケーション ストーブパイプ」や「情報の島」を作り出してもいました。

われわれは、コンピューティングの次のフェーズに入りつつあります。すなわち、インターネットと、誰もがどこでも使用できる強力なアプリケーションの作成を可能にする Web サービスの概念の組み合わせによって実現されるフェーズです。これにより、アプリケーションのリーチが拡大し、ソフトウェアの継続的な提供が可能となります。このコンテキストでは、ソフトウェアはサービスとなります。つまり、通信ネットワークを通してサービスにサブスクライブし、使用するというモデルです。

.NET は、n 層コンピューティングの持つ密結合の生産性の高い側面を、Web の疎結合のメッセージ指向の概念と組み合わせることで、このアイデアをサポートしています。このスタイルのコンピューティングは XML Web サービスと呼ばれます。これはアプリケーション開発の次の進化形態を体現しており、概念的アプリケーション アーキテクチャの基盤となります。

Web サービスは、ネットワーク経由でのアクセスに適したメッセージ ベースのインターフェイスを公開する、独立したアプリケーション ロジックの単位です。一般にサービスは、それが解決しようとしている問題に関連するビジネス ロジックと状態管理の両方を提供します。サービスを設計する際には、実世界のプロセスに関連付けられているロジックとデータを効果的にカプセル化し、何を含め、何を独立したサービスとしてインプリメントするかという点でインテリジェントな選択を行うことが目標となります。

状態操作はビジネス ルールによって決定されます。ビジネス ルールは、品目リストの金額を合計して請求書を作るというような比較的安定したアルゴリズムであり、通常はアプリケーション ロジックとしてインプリメントされます。

サービスはポリシーによって決定されます。ポリシーはビジネス ルールほど安定しておらず、地域やカスタマごとに異なることがあります。ポリシーは一般に、実行時にルックアップ テーブルをもとに決定されます。

したがって、サービスのより詳しい定義は、次のようになるでしょう。「サービスとは、ロジックをインプリメントし、状態を管理し、メッセージを介して通信し、ポリシーによって決定される、ネットワーク対応のソフトウェア単位である」。

このアプリケーションの概念的ビューについては、「アプリケーション アーキテクチャ: 概念的ビュー」でさらに詳しく説明しています。

アプリケーション パターン

パターンとは、コンテキストの中での問題の解決方法のことです。パターンは、特定の問題領域における経験から得られた具体的な知識をコード化します。アプリケーション パターンは、具体的なアプリケーション環境でのアーキテクチャ設計におけるベスト プラクティスを定義する、アーキテクチャ レベルのパターンです。

パターンのタイプと分類法にはさまざまな種類がありますが、これらは個々のパターンの定義や解説と同様に、このドキュメントの対象外です。Web サービス ベースのアーキテクチャでは、現行のアーキテクチャ パターンの多くを使用することができますが、Web サービスに含まれる新しいコンストラクトを使って作られる新しいパターンもいくつか存在します。

テクノロジ アーキテクチャ

アプリケーション アーキテクチャと同様に、テクノロジ アーキテクチャは、概念的、論理的、および物理的ビューの 3 つのビューを提供します。これらのビューは、アーキテクトが運用要件をサポートし、満たす目的で、組織内のモデルを生成するために使用します。アプリケーションの場合と同様に、テクノロジ アーキテクチャは 1 つだけ存在しているべきですが、現実にはほぼつねに、組織とテクノロジの成長と変化のせいで、複数のテクノロジ アーキテクチャが存在します。組織にとっての重要な要件は、これらの異なるテクノロジ アーキテクチャを 1 つの包括的なアーキテクチャへと統合することによって、現存のアプリケーションを再利用できるようにし、これらのテクノロジ アーキテクチャの数を最小限に抑えることです。この共通の単一アーキテクチャを提供することは、効率的で効果的かつ柔軟性のある組織を作るためにはきわめて重要です。

概念的ビュー

テクノロジ アーキテクチャの概念的ビューは、テクノロジの各分野を構造とフレームワークにマッピングするために使用されます。これは、テクノロジを使用する IT サプライヤと組織の間で理解を共有し、組織の運用要件または非機能要件をインプリメントするために必要なすべてのテクノロジ分野が定義され、組織で利用できることを保証するために、これらの分野を定義し、名前を付け、位置付けを決めるために使用されます。

論理的ビュー

テクノロジ アーキテクチャの論理的ビューは、エンタープライズ スケールの運用要件をサポートする主な機能要素とそれらの相互関係を提供します。論理的ビューでは、データベース、メール システム、トランザクション サポート、および信頼できるメッセージングなどのエンタープライズ テクノロジ要素が提供されます。このレベルで提供されるテクノロジは、通常はエンタープライズ ソフトウェア ベンダによってサーバーとしてパッケージ化されます。

物理的ビュー

テクノロジ アーキテクチャの個々の要素は、ハードウェアとソフトウェアの両方の、現実のテクノロジの要素へのマッピングを必要とします。これによりテクノロジ アーキテクチャは、ネットワーク、サーバー、オペレーティング システムなどの完全なシステムとして現実化されます。実際の物理的位置、サーバーのプロダクト名、および接続性はこのレベルで示されます。

アーキテクトは、組織の運用要件を満たすシステムを構築し、組織のテクノロジ アーキテクチャに IT ベンダのテクノロジ アーキテクチャとの整合性を持たせられるように、IT ベンダが提供するテクノロジ フレームワークとロードマップを求めています。

テクノロジ アーキテクチャ: 概念的ビュー

テクノロジの概念的アーキテクチャは、組織内でエンタープライズ スケールの Web サービスを実現するためのテクノロジ上の基盤となります。テクノロジの概念的アーキテクチャの高水準のダイアグラムは、Web サービスの生成のためのエンタープライズ ベース サービスを提供する総称的レベルのセットを示しています。これらのレベルは、あらゆる Web サービス アプリケーションまたはシステムに必要な共通要素を含んでいます。

図 5. テクノロジ アーキテクチャの概念的ビュー

ダイアグラムの一番下には、オペレーティング システム、ハードウェア、ストレージ、ネットワーキング、およびシステム全体のための信頼および管理サービスを提供するサービス プラットフォームがあります。

サービス フレームワークは、Web サービス ベースのアプリケーションが必要とするプロセス、ロジック、機能、および状態管理を含んでおり、Web サービス用の具体的なサポートを提供する完全なエンタープライズ アプリケーション サーバーです。

サービス配信は、あらゆるタイプのデバイスのサポートを含めて、プレゼンテーションの問題とテクノロジに焦点を当てたポータルおよびクライアント サービスを含んでいます。

サービス統合は、サービスと現在の運用システム、すなわちレガシー アプリケーション、商用アプリケーション、データベース、および他の Web サービスとの間の統合と相互運用を提供します。これは一般にエンタープライズ アプリケーション統合 (EAI) と呼ばれます。

最後に、サービス作成は、Web サービスの設計、開発、組み立て、管理、配置、およびテストに必要なツール、プロセス、方法論、およびパターンを提供します。

このテクノロジ アーキテクチャの概念的ビューについては、「テクノロジ アーキテクチャ: 概念的ビュー」でさらに詳しく説明しています。

テクノロジ パターン

テクノロジ パターンは、特定のテクノロジ環境のためのベスト プラクティスのアーキテクチャ設計を定義するアーキテクチャ レベルのパターンです。エンタープライズ アーキテクトは、以下の重要な分野において、自分の組織のためのガイダンスとベスト プラクティスを求めています。

• セキュリティ、アイデンティティ、および信頼
• 将来のシステムと現行の運用 (レガシー) システムの両方との統合と相互運用
• 配置、運用、および管理
• スケーラビリティとパフォーマンスを実現する分散テクノロジ アーキテクチャ
• 信頼性と可用性を実現するテクノロジ アーキテクチャ

 ページのトップへ