【正文】 文檔的形式充分地記錄每一個元素的信息 對照業(yè)務(wù)目標(biāo)，對總體架構(gòu)進(jìn)行最終的復(fù)核；以文檔的形式記錄架構(gòu)文檔中元素決策的全部依據(jù)編寫最終的需求跟蹤報告最終確定所有的應(yīng)用架構(gòu)工作產(chǎn)品本階段輸出物包括：《應(yīng)用架構(gòu)詳稿》　 用架構(gòu)階段輸出匯總應(yīng)用架構(gòu)定義文檔，包括有： 當(dāng)前應(yīng)用架構(gòu)，（詳細(xì)的） 目標(biāo)應(yīng)用架構(gòu)，（詳細(xì)的），包括： 流程系統(tǒng)模型 位置系統(tǒng)模型 時間系統(tǒng)模型 人員系統(tǒng)模型架構(gòu)需求規(guī)格草案，包括以下業(yè)務(wù)架構(gòu)需求： 差距分析結(jié)果 應(yīng)用的互操作性需求 對即將設(shè)計的技術(shù)架構(gòu)的約束 更新的業(yè)務(wù)需求（如果合適的話） 更新的數(shù)據(jù)需求（如果合適的話）充分必要條件評估及完善要求　 技術(shù)架構(gòu)設(shè)計　 技術(shù)架構(gòu)的目的技術(shù)架構(gòu)階段的目的是，將應(yīng)用架構(gòu)階段所定義的應(yīng)用構(gòu)件映射到一系列技術(shù)構(gòu)件上去。這些技術(shù)構(gòu)件包括軟件構(gòu)件和硬件構(gòu)件，它們可以來自于市場或者在組織中裝配到技術(shù)平臺之上。由于技術(shù)架構(gòu)定義的是架構(gòu)解決方案的物理實現(xiàn)，因而它同具體實現(xiàn)與遷移規(guī)劃有著緊密的聯(lián)系。同時，技術(shù)架構(gòu)還定義了技術(shù)組合的當(dāng)前視圖（例如，當(dāng)前的視圖）與目標(biāo)視圖，詳細(xì)描述了通往目標(biāo)架構(gòu)的路線圖，并在路線圖中標(biāo)識出關(guān)鍵的工作包。可以說，技術(shù)架構(gòu)完善了整個架構(gòu)的信息集合，因此它支持對特定遷移場景的成本評估。　 選取參考模型，視點以及工具首先，應(yīng)該評審和驗證一系列技術(shù)原則，這些原則通常會成為一套總體的架構(gòu)原則的組成部分。然后，根據(jù)業(yè)務(wù)驅(qū)動力、利益相關(guān)者以及利益相關(guān)者的關(guān)注點，從架構(gòu)儲藏庫中選取相關(guān)的技術(shù)架構(gòu)資源（參考模型、模式，等等）接著，選取相關(guān)的技術(shù)架構(gòu)視點，使得架構(gòu)師能夠通過這些視點展現(xiàn)利益相關(guān)者所關(guān)注的問題是如何在技術(shù)架構(gòu)中得以妥善解決的。進(jìn)而，結(jié)合所選視點，確認(rèn)出適于記錄、建模和分析的工具和技術(shù)。需要補(bǔ)充的是，根據(jù)所需復(fù)雜程度等級的不同，這些工具可以僅僅是簡單的文檔與電子數(shù)據(jù)表，也可以包含較為復(fù)雜的建模工具與技術(shù)。 　 確定總體建模流程首先，對于每一個視點，都應(yīng)使用所選取的工具與方法，選擇相應(yīng)的模型以支持所需的特定視圖。同時，必須確保這些模型覆蓋了所有利益相關(guān)者的關(guān)注點。如果沒有完全覆蓋的話，就需要創(chuàng)建新的模型，或者是擴(kuò)大現(xiàn)有的模型（見上文）來處理它們。開發(fā)技術(shù)架構(gòu)的流程包含以下步驟：l 定義一套平臺服務(wù)與邏輯技術(shù)構(gòu)件（包括標(biāo)準(zhǔn)）的分類法l 確認(rèn)技術(shù)部署的相關(guān)位置l 編寫一份物理清單，詳列所部署的技術(shù)，并將其抽象上升到分類法中。l 審查應(yīng)用與業(yè)務(wù)對技術(shù)的需求l 判斷這些技術(shù)是否能恰當(dāng)?shù)貪M足新的需求（例如，它是否能滿足功能性需求與非功能性需求）l 精化分類法l 產(chǎn)品選取（包括獨立的產(chǎn)品）l 確定所選技術(shù)的配置l 確定影響：l 影響的范圍和成本l 能力規(guī)劃l 安裝/治理/遷移的影響在規(guī)劃的早期階段，某些圍繞服務(wù)粒度與服務(wù)邊界的決策已暗含了對技術(shù)構(gòu)件與服務(wù)平臺的要求。一般來說，受到這些決策影響的技術(shù)架構(gòu)領(lǐng)域包括以下方面：l 性能: 服務(wù)的粒度會影響平臺服務(wù)的需求。粗粒度的服務(wù)包含了數(shù)項功能性需求與可能不斷變化的非功能性需求，因此，應(yīng)該考慮到平臺的性能。另外，有時粗粒度的服務(wù)所包含的信息，要比提出服務(wù)請求的系統(tǒng)所要求的多。l 可維護(hù)性: 如果服務(wù)的粒度過粗，那么對該服務(wù)引入變更將會變得十分困難，并且會影響到對服務(wù)的維護(hù)以及對提供服務(wù)的服務(wù)平臺的維護(hù)l 位置與延遲: 服務(wù)之間可能需要通過遠(yuǎn)程連接進(jìn)行交互，加之服務(wù)間通信存在固有的延遲。因此，在劃定服務(wù)邊界以及確定服務(wù)粒度時，應(yīng)該充分考慮平臺/位置對這些服務(wù)間通信的影響。l 可用性: 服務(wù)調(diào)用常常會遭遇網(wǎng)絡(luò)故障或服務(wù)實效的情況。因此，在分解服務(wù)與定義服務(wù)粒度時，需要重點考慮通信的高可用性。在技術(shù)架構(gòu)階段中，當(dāng)我們需要重用現(xiàn)有的產(chǎn)品，添加能力增量或者將產(chǎn)品選擇決策作為項目啟動過程中一項約束條件時，產(chǎn)品選擇流程就應(yīng)運而生了。如果產(chǎn)品選擇活動偏離了現(xiàn)有的標(biāo)準(zhǔn)，包含有重要的產(chǎn)出或者產(chǎn)生了廣泛的影響，那么這一活動就應(yīng)該被標(biāo)識為一項機(jī)會，留到“機(jī)會與解決方案”階段來處理?！?確認(rèn)所需的目錄在技術(shù)架構(gòu)階段中，應(yīng)該依照如下步驟創(chuàng)建技術(shù)目錄：基于現(xiàn)有的技術(shù)目錄以及在應(yīng)用架構(gòu)階段中對應(yīng)用的分析，收集當(dāng)前使用中的產(chǎn)品信息，并編制成產(chǎn)品列表。如果現(xiàn)有的產(chǎn)品不能滿足應(yīng)用架構(gòu)中所確認(rèn)的需求，就應(yīng)該使用市場上那些能夠滿足其功能需求與規(guī)定標(biāo)準(zhǔn)的可用產(chǎn)品來擴(kuò)展產(chǎn)品列表如果技術(shù)標(biāo)準(zhǔn)當(dāng)前可用，就應(yīng)該將其應(yīng)用于技術(shù)構(gòu)件目錄，以獲得關(guān)于技術(shù)標(biāo)準(zhǔn)一致性的當(dāng)前視圖在技術(shù)架構(gòu)中，應(yīng)該考慮開發(fā)以下目錄：l 技術(shù)標(biāo)準(zhǔn)l 技術(shù)組合　 確認(rèn)所需的矩陣在一項技術(shù)架構(gòu)中，應(yīng)該考慮開發(fā)以下矩陣：l 系統(tǒng)/技術(shù)矩陣　 確認(rèn)所需的圖在技術(shù)架構(gòu)中，應(yīng)該考慮開發(fā)以下的圖：l 環(huán)境與位置圖l 平臺分解圖l 處理圖l 網(wǎng)絡(luò)計算/硬件圖l 通信工程圖　 確認(rèn)需要收集的需求類型當(dāng)技術(shù)架構(gòu)目錄、矩陣、圖都已開發(fā)完成時，為完成架構(gòu)建模，我們還需要使以數(shù)據(jù)為中心（datafocused）的需求正式化，這些需求將最終用于實現(xiàn)目標(biāo)架構(gòu)。在本步驟中，架構(gòu)約定應(yīng)該確定各種需求的類型，這些類型的需求都應(yīng)該在架構(gòu)實現(xiàn)中達(dá)成。需求的類型包括有：l 功能需求l 非功能需求l 假定l 約束l 領(lǐng)域特定的技術(shù)架構(gòu)原則l 政策l 標(biāo)準(zhǔn)l 指引l 規(guī)格說明書　 開發(fā)當(dāng)前技術(shù)架構(gòu)的描述開發(fā)現(xiàn)有技術(shù)架構(gòu)的當(dāng)前描述，以更好地支持目標(biāo)技術(shù)架構(gòu)?！?開發(fā)對目標(biāo)技術(shù)架構(gòu)的描述開發(fā)技術(shù)架構(gòu)的目標(biāo)描述，使之能夠充分地支持架構(gòu)愿景、目標(biāo)業(yè)務(wù)架構(gòu)與目標(biāo)信息系統(tǒng)架構(gòu)。目標(biāo)架構(gòu)描述所定義的范圍與細(xì)節(jié)等級，是由實現(xiàn)目標(biāo)架構(gòu)的技術(shù)元素的相關(guān)性以及架構(gòu)描述是否存在的情況決定的?！?執(zhí)行差距分析首先，驗證架構(gòu)模型，確保其內(nèi)部的一致性與精確性。接著，記錄對視點的有關(guān)變更并寫入文檔。最后，確認(rèn)當(dāng)前與目標(biāo)之間的差距：l 創(chuàng)建差距矩陣l 確認(rèn)延用的構(gòu)建塊，將其分為改變的與未改變的兩類l 確認(rèn)移除的構(gòu)建塊l 確認(rèn)新的構(gòu)建塊l 確認(rèn)差距并將其分為需要開發(fā)的與需要采購的兩類　 分析對架構(gòu)景觀產(chǎn)生的影響技術(shù)架構(gòu)一旦得到最終確定，架構(gòu)團(tuán)隊就應(yīng)該著手去理解這一架構(gòu)所產(chǎn)生的廣泛影響或可能的結(jié)果。具體來說，在本階段，就應(yīng)該檢查架構(gòu)景觀中其他架構(gòu)制品，確認(rèn)出：l 本技術(shù)架構(gòu)對預(yù)先存在的架構(gòu)產(chǎn)生了影響嗎？l 最近是否進(jìn)行過影響技術(shù)架構(gòu)的變更呢？l 組織中其他領(lǐng)域有沒有可能綜合利用本技術(shù)架構(gòu)的產(chǎn)品呢？l 本技術(shù)架構(gòu)會影響其他項目嗎（包括規(guī)劃中的項目以及當(dāng)前進(jìn)展中的項目）？l 本技術(shù)架構(gòu)會被其他項目所影響嗎（包括規(guī)劃中的項目以及當(dāng)前進(jìn)展中的項目）？　 進(jìn)行正式的利益相關(guān)者評審對照提議的技術(shù)架構(gòu)，檢查架構(gòu)項目與架構(gòu)工作聲明的動機(jī)，查看它是否符合支持其他架構(gòu)域中后續(xù)工作的目的。在需要的情況下，可以對提議的技術(shù)架構(gòu)進(jìn)行精化?！?最終確定技術(shù)架構(gòu)l l為每一個構(gòu)建塊選定標(biāo)準(zhǔn)，盡量地重用那些來自架構(gòu)儲藏庫中參考模型的構(gòu)建塊l l用文檔的形式充分地記錄每一個構(gòu)建塊的信息l 對照業(yè)務(wù)目標(biāo)，對總體架構(gòu)進(jìn)行最終的復(fù)核；以文檔的形式記錄架構(gòu)文檔中構(gòu)建塊決策的全部依據(jù)l 編寫最終的需求跟蹤報告l 編寫架構(gòu)儲藏庫中最終的架構(gòu)映射文檔；從所選構(gòu)建塊中，確認(rèn)出那些也許需要重用的塊，然后通過架構(gòu)儲藏庫發(fā)布它們。l 最終確定所有的工作產(chǎn)品，如差距分析報告?！? 輸出本階段的輸出有：l 架構(gòu)愿景階段交付物的精化與更新版本，包括有： ——架構(gòu)工作聲明（需要時進(jìn)行更新） ——已驗證的技術(shù)原則，或新的技術(shù)原則（如果是這一階段產(chǎn)生的）l 架構(gòu)定義文檔草案，包括： ——目標(biāo)技術(shù)架構(gòu)，（詳細(xì)的），包括： ——技術(shù)構(gòu)件以及它們與信息系統(tǒng)的聯(lián)系 ——技術(shù)平臺以及它們的分解，展現(xiàn)了用以實現(xiàn)特定技術(shù)“?！钡募夹g(shù)組合。 ——環(huán)境和位置——將所需技術(shù)分到不同計算環(huán)境中的歸類 ——技術(shù)構(gòu)件的預(yù)期處理負(fù)載與負(fù)載分布 ——物理（網(wǎng)絡(luò)）通信 ——硬件及網(wǎng)絡(luò)規(guī)范 ——當(dāng)前技術(shù)架構(gòu)，（詳細(xì)的）（如果合適的話） ——對應(yīng)于所選視點的視圖，這些視點用于解決關(guān)鍵利益相關(guān)者的關(guān)注點l 架構(gòu)需求規(guī)范草案，包含如下技術(shù)架構(gòu)需求： ——差距分析結(jié)果 ——自B階段到C階段的需求輸出 ——更新的技術(shù)需求l 架構(gòu)路線圖的技術(shù)架構(gòu)構(gòu)件　 實施計劃　 明確總體實施戰(zhàn)略　 評審并合并自業(yè)務(wù)分析階段至技術(shù)規(guī)劃階段的差距分析結(jié)果合并及整合業(yè)務(wù)、信息系統(tǒng)與技術(shù)架構(gòu)（自業(yè)務(wù)分析階段至技術(shù)規(guī)劃階段創(chuàng)建的）的差距分析結(jié)果，并根據(jù)潛在的解決方案/機(jī)會與相互依賴關(guān)系來評估它們包含的內(nèi)容。評審來自每一個架構(gòu)階段的差距分析結(jié)果，并把這些結(jié)果合并成一份長清單，這份清單將會作為工作分解結(jié)構(gòu)（WBS）的基礎(chǔ)。　 闡明高層次的實施與遷移策略創(chuàng)建一個整體的解決方案策略來指導(dǎo)目標(biāo)架構(gòu)的實施并構(gòu)建過渡架構(gòu)。第一項活動是確定整體的策略方法以實施解決方案與/或開拓機(jī)會。往新架構(gòu)范式的遷移行動將需要一種不同的策略來升級現(xiàn)有的IT基礎(chǔ)設(shè)施。應(yīng)該根據(jù)對先前識別的風(fēng)險所做的分析來闡明一種適當(dāng)?shù)牟呗苑椒?。下一步，確定一種方法來實施上面所選擇的整體策略指導(dǎo)，從而解決并減輕在合并的差距、解決方案、依賴性整合矩陣中識別的風(fēng)險。在任何情況下，由于方法的含義相當(dāng)重要，因此需要高層級的業(yè)務(wù)與技術(shù)保持一致。例如，一種戰(zhàn)略性的投資就長期而言是會帶來很高的利潤的，而在短期看來卻會對股票的價格造成非常不利的影響，這就需要進(jìn)行適當(dāng)?shù)臏贤?。?輸出本階段的輸出是：l 能力評估，它包括：——企業(yè)架構(gòu)成熟度概要——轉(zhuǎn)換就緒狀態(tài)報告l 過渡架構(gòu)，它包括：——合并的差距，解決方案與依賴的評估——風(fēng)險記錄，——影響分析—項目清單——依賴分析報告——實施因素評估與推導(dǎo)矩陣l 實施與遷移計劃，包括高層級的實施與遷移戰(zhàn)略　 制定詳細(xì)的項目階段計劃本階段的目的是完成詳細(xì)的實施與遷移計劃；確切地說包括：l 確保實施與遷移計劃能有效地配合企業(yè)中正在使用的各種不同的管理框架l 通過賦予商業(yè)價值，并進(jìn)行成本/業(yè)務(wù)分析，從而區(qū)分所有工作包、項目和構(gòu)建塊的優(yōu)先次序l 按照已達(dá)成一致的實施方法，完成架構(gòu)愿景與架構(gòu)定義文檔 l 與相關(guān)的利益相關(guān)者共同確認(rèn)E階段中所定義的過渡架構(gòu)l 創(chuàng)建、發(fā)展與監(jiān)控詳細(xì)的實施和遷移計劃，使其為實現(xiàn)E階段所定義的過渡架構(gòu)提供必需的資源。　 估算資源需求，項目時限及可用性/交付載體為每一項目及項目增量確定所需的資源與時間，并為項目提供初步的成本估算。成本應(yīng)該拆分為資金（用以創(chuàng)建能力）、運營與維護(hù)（用以經(jīng)營和維持能力）。注意到，當(dāng)?shù)谝粋€增量交付到運營管理組織時，就必須著手進(jìn)行運營與維護(hù)投資，因此，必須從一開始就弄清，這兩種類型的投資來源（是否負(fù)擔(dān)得起）。這種問題的典型例子就是軟件維護(hù)的成本以及與更新相關(guān)的成本（包括所做的某些專門定制的軟件修改）。成本應(yīng)該包括所有的能力開支，如業(yè)務(wù)過程開發(fā)、互操作性需求、培訓(xùn)、新員工、設(shè)備等等。需要牢記的是，創(chuàng)建項目時應(yīng)該精化實際成本的估算。通過依賴關(guān)系，確認(rèn)機(jī)會——與交付新的或更好的能力相關(guān)的成本能否被將淘汰的現(xiàn)有系統(tǒng)的維護(hù)費用所抵消，因為這種維護(hù)可能消耗掉數(shù)量與之不相稱的資源。這一點應(yīng)該明確注釋。將所需資源分配給每一活動，并在項目增量與項目級別上進(jìn)行總計。　 生成架構(gòu)實施路線圖（按時間順序）及遷移計劃本步驟生成實施與遷移計劃的順序與細(xì)節(jié)。分層架構(gòu)的一項主要創(chuàng)新在于它專注于增量的業(yè)務(wù)價值的持續(xù)交付，并允許通過創(chuàng)建適時的過渡架構(gòu)而適機(jī)地利用新技術(shù)。這一敏捷性與靈活性的代價是需要緊密地協(xié)調(diào)重要的并發(fā)活動。通常情況下，會有三到四個過渡架構(gòu)接受著并行的管理，即交付、構(gòu)建、設(shè)計與規(guī)劃。沒有任何一個企業(yè)架構(gòu)或支持計劃擁有無數(shù)的細(xì)節(jié)，因為無論是從業(yè)務(wù)事件還是從技術(shù)演化的角度看，這些細(xì)節(jié)的大部分都經(jīng)不住時間的考驗。確切地說，它將隨著時間朝著目標(biāo)狀態(tài)演化，并受到一系列不斷趨同的架構(gòu)狀態(tài)的指引。這些狀態(tài)適機(jī)地向戰(zhàn)略上所定義的目標(biāo)架構(gòu)不斷推進(jìn)。同時，隨著企業(yè)的自文檔化進(jìn)程，增強(qiáng)的內(nèi)容、可重用的資源、不斷增加的細(xì)節(jié)，使得企業(yè)架構(gòu)與架構(gòu)儲藏庫的內(nèi)容變得日漸豐富起來。架構(gòu)規(guī)劃的主要特點在于，存在有大量的活動并發(fā)進(jìn)行，因而實施與遷移計劃就成為了將這些制品粘在一起的“膠水”。計劃中的多數(shù)細(xì)節(jié)都已收集完成，因而本步驟中需要做的就是使用已批準(zhǔn)的組合/項目規(guī)劃與管理技巧，將這些細(xì)節(jié)整合到一起?！?輸出本階段的輸出有：l 實施與遷移計劃，l 最終的架構(gòu)定義文檔l 最終的架構(gòu)需求規(guī)格說明書l 最終的架構(gòu)路線圖l 最終的過渡架構(gòu)l 可重用的架構(gòu)構(gòu)建塊l 項目實施中架構(gòu)方面的架構(gòu)工作要求（如果有的話）l 項目實施的架構(gòu)契約（標(biāo)準(zhǔn)）l 實施治理模型l 由所吸取的教訓(xùn)產(chǎn)生的變更請求　 IT治理　 實施治理本階段的目的是：l 闡明每一實施項目的理由l 治理與管理涵蓋總體實施過程與部署過程的架構(gòu)契約l 在實施與部署解決方案期間，履行適當(dāng)?shù)闹卫砺毮躭 確保實施項目與其他項目依從于所定義的架構(gòu)l 確保解決方案計劃依照所定的工作計劃成功地部署，l 確保所部署的解決方案依從于目標(biāo)架構(gòu)l 動員支持工作以延長所部署的解決方案的未來工作壽命。　 執(zhí)行企業(yè)架構(gòu)一致性評審l 評審正在進(jìn)行的實施治理以及每一構(gòu)建塊的架構(gòu)一致性l 進(jìn)行開發(fā)后的評審l 關(guān)閉部署項目中的開發(fā)部分　 執(zhí)行實施后期評審并關(guān)閉實施l 進(jìn)行實施后評審l 發(fā)布評審報告并關(guān)閉項目l 當(dāng)解決方案都完全地