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

情報システムにおいて、アプリケーションアーキテクチャまたはアプリケーションアーキテクチャは、エンタープライズアーキテクチャ（EA）の柱を形成するいくつかのアーキテクチャドメインの1つです。^{[1] [2]}

アプリケーション アーキテクチャは、ビジネスで使用されるアプリケーションの動作を、アプリケーション同士およびユーザーとのやり取りに焦点を当てて記述します。アプリケーションの内部構造ではなく、アプリケーションによって消費および生成されるデータに焦点を当てています。

たとえば、アプリケーション ポートフォリオ管理では、提供される価値を評価するために、アプリケーションはビジネス機能とプロセス、コスト、機能品質、技術品質にマッピングされます。

アプリケーション アーキテクチャは、ビジネス要件と機能要件に基づいて指定されます。これには、機能範囲の観点からアプリケーション パッケージ、データベース、ミドルウェア システム間の相互作用を定義することが含まれます。これにより、統合の問題や機能範囲のギャップを特定できます。

その後、ソフトウェア ライフサイクルの終了時にあるシステムや、技術的な障害の結果としてビジネスに混乱をもたらす可能性のある 固有の技術的リスクがあるシステムに対して、移行計画を作成できます。

アプリケーション アーキテクチャは、複合アーキテクチャを作成するために組織が使用するアプリケーション スイートが、スケーラブル、信頼性、可用性、管理性に優れていることを保証することを目的としています。

アプリケーション アーキテクチャは、複数のアプリケーションがどのように連携して動作するかを定義します。これは、システムの構築方法に関する技術設計を扱うソフトウェア アーキテクチャとは異なります。 ^{[引用が必要]}

複合アーキテクチャが実装している機能のダイナミクスを理解して管理するだけでなく、展開戦略の策定を支援し、組織の成長や運営を危険にさらす可能性のある技術的リスクに注意を払う必要があります。^{[引用が必要]}

アプリケーション アーキテクチャ戦略には、アプリケーションと統合が組織の成長戦略と一致するようにすることが含まれます。

組織が買収を通じて急速な成長を計画している製造組織である場合、アプリケーション アーキテクチャは、継承されたレガシー システムだけでなく、他の大規模な競合システムも網羅できるほど機敏である必要があります。

アプリケーションは、従う アプリケーションアーキテクチャ パターンに応じてさまざまなタイプに分類できます。

「パターン」は次のように定義されています。

「ある実用的な状況で役に立ったアイデアは、おそらく他の状況でも役に立つだろう」。

パターンを作成するには、ビルディング ブロックが必要です。ビルディング ブロックはソフトウェアのコンポーネントであり、ほとんどが再利用可能で、特定の機能を作成するために利用できます。パターンは、ビルディング ブロックをコンテキストに配置する方法であり、ビルディング ブロックを使用して 1 つまたは複数のアーキテクチャ上の問題に対処する方法を説明します。

アプリケーションはさまざまな機能の集合体であり、通常はすべて同じパターンに従います。このパターンによってアプリケーションのパターンが定義されます。

アプリケーション パターンは、構造的 (デプロイメント/配布関連) または動作的 (プロセス フローまたは相互作用/統合関連) な特性を記述でき、アプリケーション アーキテクチャは 1 つまたは複数のパターンを活用できます。

パターンの考え方は、コンピュータ サイエンスの始まりの頃から存在していましたが、最も有名になったのは「Gang of Four」(GoF) によるものです。ただし、彼らのパターンの多くは、「アプリケーション アーキテクチャ」パターンではなく、「ソフトウェア アーキテクチャ」パターンです。

GoF に加えて、Thomas Erlはさまざまな種類のパターンの著名な作成者であり、Microsoftなどの大手ソフトウェア ツール ベンダーのほとんどが広範なパターン ライブラリを公開しています。

公開されているパターンは数多くありますが、「業界標準」と考えられるパターンは比較的少数です。その中で最もよく知られているものは次のとおりです。

• シングル ティア/シック クライアント/デスクトップ アプリケーション(構造パターン): 1 台のコンピューター (通常はデスクトップ) にのみ存在するアプリケーション。もちろん、同じデスクトップ アプリケーションを複数のコンピューターにインストールすることはできますが、それらのコンピューターは相互にやり取りしません (まれな例外を除く)。
• クライアント サーバー/ 2 層 (構造パターン):ビジネス ロジック、ワークフロー、統合、およびデータ サービスを提供するバックエンド(サーバー)と通信するリッチ クライアントとして実行されるフロントエンド(ユーザー向け) レイヤーで構成されるアプリケーション。デスクトップ アプリケーション (シングル ユーザー) とは対照的に、クライアント サーバー アプリケーションはほとんどの場合、マルチ ユーザー アプリケーションです。
• n 層(構造パターン): クライアント サーバー パターンの拡張であり、サーバー機能が複数の層に分割され、ローカル エリア ネットワーク(LAN) 上の異なるコンピューターに分散されます。
• 分散型(構造パターン): n 層パターンの拡張で、サーバー機能が広域ネットワーク(WAN) またはクラウド全体に分散されます。このパターンには、動作パターンの属性もいくつか含まれています。これは、WAN およびクラウドの展開シナリオで発生する可能性のある重大な遅延に対処するために、サーバー機能をより自律的に設計し、他の機能と非同期で対話して機能する必要があるためです。
• 水平スケーラビリティ(構造パターン): 複数のコンピューターでサーバー機能の複数のコピーを実行するパターン。これにより、処理負荷の増加を、より大規模で強力なコンピューターに機能を再展開するのではなく、機能のインスタンス数の増加に分散できます。クラウド ネイティブ アプリケーションは、基本的に水平スケーラビリティに基づいています。
• イベント駆動型アーキテクチャ(動作パターン): データ イベント (最初はデバイス、アプリケーション、ユーザー、データ ストア、またはクロックから発生した可能性があります) と、条件に応じてイベントを破棄したり、イベント関連のプロセスを開始したり、ユーザーまたはデバイス マネージャーに警告したり、データ ストアを更新したりするイベント検出ロジック。イベント駆動型パターンは、分散アーキテクチャパターンに必要な非同期処理の基礎となります。
• ETL (動作パターン): 元のソースからデータを抽出し、そのデータをビジネス ルールに従って変換し、そのデータを宛先にロードするアプリケーション プロセス パターン。ETL パターンのバリエーションには、ELT と ETLT があります。
• 要求応答(動作パターン): アプリケーションが別のアプリケーションにデータを要求し、要求されたデータを含む応答を待機する、データ交換のためのアプリケーション統合パターン。これは、前のパターンの説明で言及した非同期処理とは対照的に、同期パターンの最も顕著な例です。

適切なアプリケーション パターンは、組織の業界とコンポーネント アプリケーションの使用状況によって異なります。

組織が有機的な成長と買収による成長の両方を経験した場合、複数のパターンが混在する可能性があります。

TOGAF は、アプリケーション アーキテクトのスキルと役割期待の両方を説明しています。これらのスキルには、アプリケーションのモジュール化/配布、統合、高可用性、スケーラビリティのパターン、テクノロジー、トレンドの理解が含まれます。アプリケーション コンテナー、サーバーレス コンピューティング、ストレージ、データと分析、その他のクラウド関連のテクノロジーとサービスに関する理解が、アプリケーション アーキテクトのスキルとしてますます求められています。ソフトウェアのバックグラウンドはアプリケーション アーキテクトにとって優れた基礎ですが、プログラミングとソフトウェア設計はアプリケーション アーキテクトに必要なスキルではありません (これらは実際には、コンピューター プログラミングチームのリーダーであるソフトウェア アーキテクトに必要なスキルです)。

アプリケーションモデリング

新しいアプリケーションや拡張アプリケーションの展開と統合のフレームワークとしてモデリングを採用し、モデリングを使用して問題を見つけ、リスクを軽減し、予測可能性を向上させ、コストと市場投入までの時間を削減し、さまざまな製品シナリオをテストして、クライアントの非機能的なニーズ/要件を組み込み、必要に応じて開発プロセスにテスト設計の決定を追加し、製品設計の問題を評価します。

競争情報、ビジネスモデリング、戦略分析

グローバル市場、消費者、業界、競争、およびグローバルビジネスモデル、戦略、財務、運用、構造がどのように相互に関連しているかを理解します。市場、業界、競争、規制環境の現在の傾向を含む競争環境を理解し、ビジネスモデルのコンポーネント（戦略、財務、運用など）がどのように相互に関連して組織が市場で競争力を持つようになるかを理解します。組織のビジネスプロセス、システム、ツール、規制、構造を理解し、それらが顧客、消費者、主要な利害関係者に価値を生み出す製品とサービスを提供するためにどのように相互に関連しているかを理解します。顧客、消費者、主要な利害関係者のために創造される価値が、組織のビジョン、ビジネス、文化、価値提案、ブランドプロミス、戦略的必須事項とどのように一致するかを理解します。競争環境に関連して強み、弱み、機会、リスクを評価するために、組織の過去と現在の成果と欠点を理解します。

テクノロジー

IT 戦略、開発ライフサイクル、アプリケーション/インフラストラクチャのメンテナンスに関する理解。競争上の優位性を促進し、効率性を高め、ビジネスに付加価値をもたらす IT サービスおよびサポート プロセスに関する理解。

技術標準

既存および将来のビジネス要件を効果的にサポートするために必要なインフラストラクチャを形成する主要なテクノロジを完全に理解していることを示し、すべてのハードウェアとソフトウェアがビジネス環境に統合される前にベースライン要件と標準に準拠していることを確認し、新しいテクノロジの使用を容易にするための技術標準と手順を理解して開発することができ、新しいテクノロジを使用および適用するための有用なガイドラインを開発します。

アプリケーション アーキテクトは、組織内のアプリケーション固有のあらゆる事柄に精通しています。アプリケーション アーキテクトは、すべてのアプリケーションを次の観点から理解することで、アプリケーション保守チームに戦略的なガイドラインを提供します。

• 相互運用性機能
• パフォーマンスとスケーラビリティ
• 信頼性と可用性
• アプリケーションライフサイクルステージ
• 技術的リスク
• インスタンス数

上記の分析では、断片化されたアプリケーションの展開戦略の変更から、テクノロジまたは機能のライフサイクルの終了時のアプリケーションの完全な置き換えまで、さまざまな変更を必要とするアプリケーションが指摘されます。

主要なビジネス プロセスのシステム プロセス フローを理解します。これにより、機能マップと、マップ全体にわたるさまざまなアプリケーションのアプリケーション フットプリントが明確に示されます。

多くの組織では、文書化の規律がないため、詳細なビジネス プロセス フローとシステム プロセス フローが不足しています。まずは、それらを整備するための取り組みを開始する必要があるかもしれません。

どの組織にも、複数の部門で単一のインスタンスとして、または部門ごとに異なるインスタンスとして使用されるコア アプリケーション セットがあります。すべてのプロジェクトが実装を設計するための共通の出発点を持つように、すべてのコア アプリケーションのソリューション アーキテクチャ テンプレートを作成します。

アーキテクチャの世界における標準はTOGAFで定義されており、Open Group Architecture FrameworkではEAの4つのコンポーネントをBDAT（ビジネスアーキテクチャ、データアーキテクチャ、アプリケーションアーキテクチャ、テクニカルアーキテクチャ）として説明しています。

組織の複雑さのレベルに応じて、考慮すべき他の標準もあります。

• EA のためのザックマン フレームワーク
• 連邦エンタープライズアーキテクチャ(FEA)
• ガートナー^[3]

• ISO/IEC 42010システムおよびソフトウェア エンジニアリング - アーキテクチャ記述は、システムおよびソフトウェアのアーキテクチャ記述に関する国際標準です。
• IEEE 1471 は、「ソフトウェア集約型システム」のアーキテクチャ (ソフトウェア アーキテクチャとも呼ばれる) を記述するための、廃止された IEEE 標準です。
• IBM システム アプリケーション アーキテクチャー
• エンタープライズアーキテクチャ計画
• 高可用性アプリケーションアーキテクチャ

• 「フェーズ C: 情報システム アーキテクチャ - アプリケーション アーキテクチャ」。TOGAF 9.1。2017年 7 月 26 日閲覧。
• Hunter, Roy、Rasmussen, Brian。「アプリケーション アーキテクチャ」。Oracle。2017年7 月 26 日閲覧。