説明
リファレンスアーキテクチャを定義する前に, それは、ソフトウェアアーキテクチャについていくつかのアイデアを持っている方が良いです. ソフトウェアアーキテクチャは、異なる供給源から誘導される種々の定義を有する. それは設計の範囲, creating and maintaining all the code of large computer systems to incorporating all the functioning of the physical and logical components of enterprise systems as well. It is a combination and interaction of all the components (software and hardware) to make a complete system specific to different business needs.
リファレンスアーキテクチャとフィット/ギャップ分析は、現在のプロジェクトのアーキテクチャの基礎として使用するリファレンスアーキテクチャを明記し、この決定の根拠を含む文書が不足している. これは、リファレンス·アーキテクチャとその実装を理解するために、分析プロセスである.
リファレンスアーキテクチャは、特定のビジネスと技術の文脈で使用するために設計された事前定義されたアーキテクチャパターンです.
組織内のリファレンスアーキテクチャのソースは、以前のプロジェクトで使用される任意の実績のあるフレームワークとアセットできる. 作業成果物は、一般的であり、他のソースからのリファレンスアーキテクチャの選択にも同様に適用.
リファレンスアーキテクチャの最も重要な部分は、解析中に見つかったフィットネスとのギャップを理解することです.
リファレンスアーキテクチャフィット/ギャップ分析は、リファレンス·アーキテクチャを選択することに関与する重要な要因を集計:
- ビジネスシナリオ
- ビジネスドライバ
- アーキテクチャ特性
Asset selection involves tradeoffs. Reference Architecture Fit/Gap Analysis documents the differences between the desired project architecture and the reference architecture in a statement-of-fit and identifies modifications required for the project.
目的
今私たちはリファレンスアーキテクチャモデルで目的フィット/ギャップ分析を確認してみましょう. リファレンスアーキテクチャフィット/ギャップ分析は、以下のために使用され
- 提案されたソリューション開発プロジェクトの範囲を決定を支援するために
- As an input to other architecture work products. Depending on the size of the gaps, 選択されたリファレンス·アーキテクチャおよび関連するフィット/ギャップ分析は、全体アーキテクチャの基礎を形成することができる.
- To highlight any gaps where the Reference Architecture does not fit project requirements. These indicate areas of risk or substantial architectural work required in the project. また、提案されたプロジェクトのための参照アーキテクチャを選択するのに役立ちます.
リファレンスアーキテクチャを持っていないの影響
リファレンスアーキテクチャを選択すると、実績のある再利用することでリスクを軽減, best-practice solutions. Not applying a standard Reference Architecture increases project effort and cost, そしてプロジェクトの失敗のリスクを増大させる.
The best way to use architectural assets is to start by selecting a Reference Architecture. This will form the context for a more detailed selection of assets and guidance.
リファレンス·アーキテクチャを使用しない理由
資産ベースのプロジェクトで, この製品は、常に生成されるべきである.
If appropriate Reference Architectures are not available to a project or a project decides not to use a Reference Architecture, then at most the Executive Summary, including reasons why a Reference Architecture was not selected, should be completed. Often even this is unnecessary. A note can be added to the documentation of the choice of work products.
How Fit/Gap analysis is documented
A Reference Architecture Fit/Gap Analysis is basically textual document, with tables assessing the requirements characteristic profile and subject area coverage. The tabular form describes all the required points to get a clear picture of the referred architecture and its fitness in the proposed project.
Executive Summary: Brief statement of selected Reference Architecture and any major issues/risks.
はじめに: Introductory comments about the reference architecture.
Key Drivers: A brief statement of the business objectives or constraints.
Architecture Requirements Checklist: 文書では、建築の要件に関する質問および潜在回答の標準セットで構成されています, which allows a systematic collection of the architectural requirements for the project. This set is used as a checklist to prompt for customer architectural requirements and associated issues, 表に記載されている, 以下のように. これは、サンプルテーブルであり、それは、組織の標準に従って異なるフォーマットとすることができる.
| 要件 | リファレンスアーキテクチャの特徴 | プロジェクトのために必要な値 | 調査するためにリスク/問題/コメントポイント |
| 要件名 | このアーキテクチャの値の該当範囲 | 顧客への適用範囲 | 任意のギャップ, リスク, おそらく今後の課題, その後の分析のためのトピック |
Subject Area Checklist:各リファレンス·アーキテクチャは、複数のサブジェクト·エリアを包含 (時々 "ドメイン"と呼ぶ). Subject areas are specific areas of concern, 例えば, Webベースの配信チャネルは、Webブラウザから成る対象エリアです, ドメインネームサーバ, 等. A simple and clear way of examining the “fit” of a Reference Architecture to customer requirements is to compare it to the subject area coverage. 以下に詳細を捕捉するためのテーブルである.
主題領域 |
アーキテクチャでは、本? | お客様が必要とする? | 問題/リスク/メモ |
| 対象領域の名前 | Yes/No | Yes/No |
Statement of Fit:A summary of the extent of “fit” between the Reference Architecture and customer requirements. Each Reference Architecture is described at several levels of abstraction, and guidance is provided at each level on the characteristics supported. For each area where the Reference Architecture does not meet requirements, describe briefly:
- The unmet requirement. This is very important for selecting the reference architecture.
- The type and extent of delta that would be requisite for the Reference Architecture to meet the requirement. Also mention if it needs to be extended, modified, or receive a new subject area?
- An estimate of the cost and risk of the delta
Development Approach
The following steps should be taken in generating this work product:
- Identify the most likely Reference Architecture candidate. As there are a small number of Reference Architectures, each with a well-defined focus, it should be simple to identify one or two as relevant to the customer’s project goals and future business model.
- Review the description of the asset context, which is provided in both textual and illustration form, with the customer to assess fit. The illustrations, in particular, are a powerful way of checking customer understanding of the proposed approach. During this process, 顧客が彼の前に述べた要件を変更することを決定することができる, 例えば, リファレンスアーキテクチャが提供するアーキテクチャパターンは、彼が以前に想定していた1よりも優れているという認識を通じ.
- ビジネス·ドライバを使用して、, IT原則と顧客の要件を特徴づける要件リストは標準的な特性でカバーされていない他の重要な要件があるかどうかで顧客に確認してください.
- 抽象化のさまざまなレベルでリファレンスアーキテクチャが提供する特性を持つ要件の適合を調べる.
- 資産ベースから, identify the subject areas covered by the Reference Architecture. Compare these with the subject areas required by the customer.
- Analyze the fit between the Reference Architecture and the customer requirements. Document all gaps, and make initial assessments with the customer on how these shortcomings will be resolved. This may involve:
- アーキテクチャの拡張 (e.g., 追加の対象領域へのリンク)
- リファレンスアーキテクチャの変更 (すなわち, その内部構造や動作を変更する)
- 仮定の観点から、これらの決定のそれぞれの根拠を文書化, ビジネス上の正当な理由, リスク, 等.
- この時点で入手可能な情報に基づいて生存率およびリスクの総合的な評価を行う.
検証と確認
以下のチェックを行う:
- 顧客はリファレンスアーキテクチャを比較し、選択するための基準を承認したことを確認します.
- 顧客のすべての主要な要件領域が考慮されていることを確認します.
- ターゲット環境でのアーキテクチャの重要な依存関係を満たすことができることを確認します.
- 以下の基準で顧客と資産プロバイダで作られているいずれかのトレードオフを検証.
- アーキテクチャは、予想される変化に弾力的であることを確認.
