描述
之前定義的參考架構, 最好是有一些想法，關於軟件架構. 軟件架構有不同的定義，從不同的來源. 它的範圍從設計, 創建和維護大型計算機系統的所有代碼將所有的職能，以及企業系統的物理和邏輯組件. 它是所有組件的組合和相互作用 (軟硬件) 做一個完整的系統，具體到不同的業務需求.
參考架構和FIT /差距分析是一個簡短的文件說明被用來作為當前項目的架構的基礎和參考架構，包括作出這一決定的理由. 這也是一個分析過程，了解參考架構及其實施.
參考架構是一個預定義的建築格局，設計用於在特定的業務和技術背景.
在一個組織內源參考架構可以是任何成熟的框架和資產在早期項目中使用. 工作產品是通用的，也同樣適用於其他來源的選擇的參考架構的.
參考架構中最重要的部分是理解健身和差距分析過程中發現，.
A參考架構的FIT / GAP分析列表選擇參考架構所涉及的關鍵因素:
- 業務場景
- 業務驅動
- 結構特徵
資產選擇包括權衡. 參考架構飛度/差距分析文件中的報表-的配合所需的項目架構和參考體系結構之間的差異，並確定項目所需的修改.
目的
現在，讓我們檢查的目的FIT /差距分析的參考架構模型. 參考架構FIT / GAP分析用於以下
- 為了協助確定建議的解決方案開發項目的範圍
- 作為輸入到其他架構的工作產品. 取決於間隙的大小, 所選擇的參考體系結構和相關聯的適合/縫隙分析可能形成整個體系結構的基礎.
- 為了突出存在的差距，其中的參考體系結構不符合項目要求. 這表明風險或主要建築工作，在項目所需領域. 它還有助於擬建項目選擇的參考架構.
不具有參考架構的影響
選擇參考架構降低風險重用證明, 最佳實踐的解決方案. 不應用標準參考體系結構增加項目工作量和成本, 並增加了項目失敗的風險.
使用建築資產的最好方法是通過選擇一個參考架構. 這將形成的上下文進行更詳細的選擇資產和指導的.
理由不使用參考架構
基於資產項目, 這款產品應該總是產生.
如果適當的參考架構是項目或項目決定不使用參考架構, 然後在執行摘要, 包括參考架構為什麼沒有被選中的原因, 應完成. 通常，即使這是不必要的. 的說明可以添加到工作產品的選擇的文件.
如何記錄FIT /差距分析
A參考架構的FIT / GAP分析基本上是文本文件, 評估表的要求特性曲線和學科領域覆蓋. 表格的形式描述了所有所需的積分，獲得清晰的畫面擬建項目的參考架構和健身.
執行摘要: 選定的參考架構，並簡要說明任何重大問題/風險.
介紹: 介紹性評論的參考架構.
關鍵驅動因素: 業務目標或約束的一個簡短的聲明.
架構需求清單: 該文件由一組標準的問題和潛在的答案，有關建築要求, 它允許項目的建築要求一個系統地收集. 這組被用作一個清單來提示客戶建築要求和相關問題, 都記錄在一個表, 如下圖所示. 這是一個示例表，它可以是不同的格式，根據該組織的標準.
| 需求 | 參考架構特性 | 項目所需的值 | 風險/問題/評論點調查 |
| 要求名稱 | 這種架構的值的相關範圍 | 範圍適用於客戶 | 任何空白, 風險, 未來可能的問題, 主題以供後續分析 |
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, 和指導提供在每個級別上支持的特性. 對於每個地方不符合要求的參考架構, 簡要描述:
- 未滿足要求. 這是非常重要的，選擇的參考架構.
- 三角洲的類型和程度，這將是必要的參考架構，以滿足要求. 還提到，如果是需要被擴展, 改性, 或收到一個新的學科領域?
- 增量的成本和風險的估計
Development Approach
產生這種工作產品，應採取以下步驟:
- Identify the most likely Reference Architecture candidate. As there are a small number of Reference Architectures, 每一個明確的重點, 它應該是簡單的識別相關的一個或兩個客戶的項目目標和未來的業務模式.
- 查看資產上下文的描述, 文字和插圖的形式，其設置在, with the customer to assess fit. The illustrations, 特別是, are a powerful way of checking customer understanding of the proposed approach. During this process, the customer may decide to modify his previously stated requirements, 例如, through recognition that the architectural pattern provided by the Reference Architecture is superior to the one he had previously envisaged.
- Use Business Drivers, 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., 鏈接到一個額外的主題領域)
- 修改的參考架構 (即, 改變其內部的結構或行為)
- 記錄假設這些決定的理由, 業務理由, 風險, 等等.
- Make an overall assessment of viability and risk based on the information available at this point.
Validation and Verification
Perform the following checks:
- Verify that the customer has approved the criteria used to compare and choose the Reference Architectures.
- Verify that all major requirement areas of the customer have been considered.
- Verify that critical dependencies of the architecture in the target environment can be met.
- 驗證任何與客戶和資產提供用以下標準的權衡.
- 驗證的架構是有彈性的預期變化.
