許多企業架構（Enterprise Architecture，EA）項目無法達成所有目標或實現架構團隊最初定義的各種收益。雖然團隊在執行項目時使用了良好的架構框架和方法作為指引，但最終還是不可避免地出現了這樣的結果。

為了幫助EA團隊成功交付The Open Group架構框架（The Open Group Architecture Framework，TOGAF）9項目，本文著力強調架構團隊應遵循的10個關鍵步驟。這些步驟是從TOGAF 9中摘錄出來的。TOGAF9是世界各地的組織和從業者采用的行業標準框架，全球已有超過16,000名架構師獲得了TOGAF認證。

有了TOGAF，EA從業者就可以充分利用全球各地的組織和自由架構師的經驗和知識。

第一步：定義對組織的理解

EA從業者諳熟組織的內部運營，包括熟悉組織內部部署的各種流程、系統和技術。但是，我們發現，極少從業者真正理解部署這些流程、系統和技術的原因。

對問題“我們為什么開展這項業務”的回答能讓架構團隊洞察組織的業務目標，并讓他們更清楚地識別那些對組織具有實際影響的計劃。在批準新計劃時，多數業務主管，包括管理層主要關心如何降低成本、管理風險和增加價值。架構團隊必須能夠證明他們如何增進計劃的價值。如果他們不理解業務目標，就無法清晰解釋架構工作將如何支持這些計劃。

第二步：識別影響組織的關鍵因素

組織經營并非虛無縹緲。多數發達國家的金融機構仍在設法從幾年前的次貸危機中艱難恢復，而且至今全球依然能夠感受到次貸危機的影響。次貸危機迫使金融機構改變銀行以前的做法（特別是抵押資產證券化），而新的政府監管規定也在影響著銀行業的跨國經營。例如，行業的業務驅動力影響著組織的戰略和目標，新的環境立法影響著許多國家的自然資源行業（尤其是礦業及石油開采）和對電信業的管制力度，而技術創新和互聯網寬帶普及迫使零售商們參與國際競爭，也使中小型企業加入了與現有專業服務組織的競爭行列。

這些驅動力影響著特定行業中組織的業務目標和戰略，而新的業務目標則需要新的或改進的業務能力，使組織能夠應付這些變化。EA從業者有責任了解行業的業務驅動力，確保在新計劃執行期間開發的架構設計符合業務發起人的期望并且能夠支持組織的業務目標。

第三步：明確架構開發的職責

“協作”、“介紹”、“討論”、“推動”以及“交互”等都可以用來描述參與某個架構計劃的EA專業人員的部分職責。EA專業人員必須與組織中的各級雇員進行互動，包括從高管到行政人員，還要與廠商、供應商以及監管機構進行溝通。

架構團隊要了解組織的期望和為其設定日程的執行發起人。如果不能清楚地了解所有利益相關者（包括EA團隊自身）對團隊的職責和要求，架構項目交付可能會遇到來自組織策略的挑戰。企業架構，顧名思義，是一項跨組織的活動。對一個團隊來說，即使是規模較小的組織有時也會因為過于復雜而難以管理整個架構，因此必須對工作進行分割。在具有若干EA團隊的大型組織中，對每個團隊的職責有一個清醒的認識尤為重要。

第四步：識別架構原則并將其與組織價值和驅動力聯系起來

處于同一行業、具有同等規模、在同一國家經營并同處于其細分市場頂端的不同組織可能具有截然相反的組織文化、結構和對待風險的態度。所以，這些組織會各自具有驅動其架構決策的差異巨大的架構實踐和原則。

例如，在零售行業可能存在兩家相互競爭的食品零售商，他們遵循完全不同的戰略。一家零售商可能采用特許經營模式，所有的零售網點均獨立經營；另一家零售商可能會自己經營所有門店。第一家零售商選擇的架構原則可能會圍繞通用詞匯和數據定義（如TOGAF的第14條原則）展開，以確保能夠最低限度地建立互操作性標準，實現交易數據與總部和供應鏈合作伙伴的集成。而第二家零售商可能會采用類似的原則--數據托管（如TOGAF的第13條原則，該原則要求所有數據有一個管理員，負責批準和執行跨組織的特定數據元素共享。

架構原則是組織價值和業務原則的一個子集。通過奠定架構治理的基礎，架構原則要驅動組織中各架構團隊的行為。因此，在啟動各架構項目之前，建立一整套明確定義且獲得認可的原則非常重要。

第五步：了解架構治理融入組織治理框架的方式

架構治理是指將模型存儲庫轉換成企業所需的真實價值的過程。架構開發周期中交付的架構文件必須受治理結構控制。如果組織初次嘗試EA實踐，則必須對當前的組織治理結構進行更新以便適應新的架構流程。

例如，架構治理委員可能會批準一項旨在定義針對整個組織的標準集成層的計劃。與此同時，某個業務單元可能決定為其環境實施一個不同的集成協議。如果IT采購部門和項目管理辦公室（Business Project Office，BPO）依照不同的治理結構辦事，則尋求某個適當解決方案的業務請求很可能會獲得批準，而試圖為企業范圍集成設定標準的架構計劃則會流產。

第六步：集成架構開發流程與其他管理框架

TOGAF9中的架構開發方法（Architecture Development Method，ADM）是EA從業者在執行某個架構項目時遵循的步進式指南。ADM 可以作為一種獨立方法使用，也可以集成到其他架構框架或行業特定的管理框架之中。第五步已經指出，架構治理框架必須與組織的治理框架保持一致。同時，還需強調的一點是，流程步驟必須與其他管理框架的步驟保持一致，這樣就可以避免重復勞動和輸出重復的交付物。

實施TOGAF9時要解決的第一個可能發生的重疊是項目管理交付物和流程步驟。如果組織已經實施了某個架構管理框架（如Prince2），則TOGAF的某些關鍵交付物（如SOW、溝通計劃、實施與遷移計劃）就會與之發生重疊。如果允許這些框架獨立運作，架構項目經理會創建類似但實則不同的交付物，并將它們提交給不同的決策機構。這將在組織中造成混亂。在第三步中，我們會創建一份利益相關者地圖。可以利用該地圖標出各方面的利益相關者，包括項目管理（如Prince2）、開發（如SCRUM）、操作管理（如ITIL）、IT 管理（如COBIT）以及采購等等。同時，要確保架構團隊有權訪問已經在組織中部署的所有業務與IT管理框架和流程。

第七步：進行架構成熟度評估

可以利用能力成熟度模型（Capability Maturity Mode，CMM）來判定企業打算采用EA方法來管理變更和復雜性的準備度。架構成熟度的度量是主觀的，其結果將反映那些完成評估指標的參與者的意見。要想獲得真實結果，重要的是識別那些要度量的關鍵特征，并從某個成熟的且可以根據組織需要加以調整的成熟度評估開始。TOGAF9提供了一些NASIO架構成熟度模型、CMMI以及DOC架構CMM的例子，可以作為定義組織架構成熟度指標的起點。

第八步：將架構職能納入組織

組織中任何可持續的架構計劃都需要規范化的架構職能。我們知道，很多組織以項目群或項目的方式實施了它們的架構計劃，但卻沒有為扮演組織中與架構有關的各種角色的專業人員提供組織職業發展通道。

架構職能的結構受前面列舉的很多因素的影響。基于行業、組織成熟度、人力資源戰略、預算約束以及治理結構等因素，必須制定組織結構圖，列出團隊結構、各種角色及其職責。將人力資源構件規范化將使管理團隊能夠啟動后續規劃、技能開發、資源分配以及績效管理。

許多EA項目由于組織人員流動（辭職）、過度使用外包或臨時員工等原因導致失敗或不能實現其最初目標。根據組織戰略，使用外包或臨時員工是可以接受的，但是必須要清楚這樣做存在的風險和對項目的影響，使管理團隊能夠靈活決策。

第九步：定制TOGAF

TOGAF 9是一個不斷演進的框架，用于解決各行各業的問題，包括公共部門和非盈利組織。在第五和第六步，我們已經討論過TOGAF 9需要和其他的管理框架保持一致，以確保各交付物納入組織治理流程和結構之中。這一步是為了推動EA從業者正式編寫定制化的TOGAF流程以及組織要求的任何交付物。

如果有新人加入架構團隊，或者架構流程必須進行規范化和突破（如達到CMMI二級），又或者架構職能在組織中獲得了擴展，則本文極具價值。

第十步：實施之前應考慮的架構存儲庫構件

要想在TOGAF9的基礎上建立可持續的EA實踐，需要一個卓越的架構存儲庫。存儲庫必須提供用以支持TOGAF9成功部署的構件如下：

1.架構存儲庫必須具有一個易于定制化的模型存儲構件（架構景觀），使眾多項目和用戶可以在同一服務器存儲具有制品級安全的內容。

2.元模型必須開放，易于定制。

3.一個提供參考材料（如ITIL、APQC PCF、COBIT、TRM等）的獨立參考庫構件，以及允許將內部組織特定的架構加入各參考庫構件的能力。

4.一個治理日志構件，可以存儲治理內容（如架構項目文件和決策等）并與某個外部項目管理存儲庫共享這些內容。

5.一個文件庫或內容管理構件，所有非制品架構相關的內容存儲在一個版本受控環境中（包括架構能力文件、項目文件以及差距分析報告）。

6.一個視點庫，具有能夠在組織中重用的一整套預定義視點，并且能夠為組織中的其他制品添加預定義視點。

7.一個分析引擎（使架構師能夠進行假定分析、差距分析、動態視圖創建等）。

結論

EA從業者通常專注于項目交付，極少考慮在EA實踐之前定義項目環境和進行規劃。本文基于TOGAF9標準著重強調的10個步驟是所有架構師在啟動一項新計劃或項目之前必須完成的工作。

EA從業者要想獲得更好的資金支持或提高當前架構項目成功率，唯一途徑就是回歸根本。必須確保有一位理解項目價值的執行發起人、一個理解其作用和組織定位的內部架構師團隊以及對通過自動工具發布并符合需求的一整套視點認可的各種利益相關者。