許多企業架構（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從業者有責任了解行業的業務驅動力，確保在新計劃執行期間開發的架構設計符合業務發起人的期望並且能夠支持組織的業務目標。
提示: 繼續執行步驟1中啟動的業務原則、目標和驅動程式範本, 方法是完成磁區驅動程式部分, 或在該節中添加基於業務PEST分析的圖表或Porter的5力量模型。重要的是要注意的是, 這個想法不是成為一個商業戰略家, 而是收集, 理解和反思的戰略, 企業決定和司機影響組織。原則、目標和驅動程式檔必須作為一種機制, 將 EA 從業者對環境的理解傳達給贊助商和其他利益相關者。
第三步：明確架構開發的職責
“協作”、“介紹”、“討論”、“推動”以及“交互”等都可以用來描述參與某個架構計劃的EA專業人員的部分職責。EA專業人員必須與組織中的各級僱員進行互動，包括從高管到行政人員，還要與廠商、供應商以及監管機構進行溝通。 架構團隊要了解組織的期望和為其設定日程的執行發起人。如果不能清楚地了解所有利益相關者（包括EA團隊自身）對團隊的職責和要求，架構項目交付可能會遇到來自組織策略的挑戰。企業架構，顧名思義，是一項跨組織的活動。對一個團隊來說，即使是規模較小的組織有時也會因為過於復雜而難以管理整個架構，因此必須對工作進行分割。在具有若干EA團隊的大型組織中，對每個團隊的職責有一個清醒的認識尤為重要。
第四步：識別架構原則並將其與組織價值和驅動力聯繫起來
處於同一行業、具有同等規模、在同一國家經營並同處於其細分市場頂端的不同組織可能具有截然相反的組織文化、結構和對待風險的態度。所以，這些組織會各自具有驅動其架構決策的差異巨大的架構實踐和原則。
例如，在零售行業可能存在兩家相互競爭的食品零售商，他們遵循完全不同的戰略。一家零售商可能採用特許經營模式，所有的零售網點均獨立經營；另一家零售商可能會自己經營所有門店。第一家零售商選擇的架構原則可能會圍繞通用詞彙和數據定義（如TOGAF的第14條原則）展開，以確保能夠最低限度地建立互操作性標準，實現交易數據與總部和供應鏈合作夥伴的集成。而第二家零售商可能會採用類似的原則–數據託管（如TOGAF的第13條原則，該原則要求所有數據有一個管理員，負責批准和執行跨組織的特定數據元素共享。
架構原則是組織價值和業務原則的一個子集。通過奠定架構治理的基礎，架構原則要驅動組織中各架構團隊的行為。因此，在啟動各架構項目之前，建立一整套明確定義且獲得認可的原則非常重要。
提示: 確定業務原則 (即業務價值/支柱/信念) 並更新業務原則、目標和驅動程式文檔 (最初在步驟1中開始)。使用思維圖或實體關聯圖將體系結構原則與業務原則和驅動程式相關聯。在體系結構計畫的範圍內使用映射作為輸入, 以説明構建體系結構專案的業務案例。使用 TOGAF 9 章 23: 體系結構原則
第五步：了解架構治理融入組織治理框架的方式
架構治理是指將模型存儲庫轉換成企業所需的真實價值的過程。架構開發週期中交付的架構文件必須受治理結構控制。如果組織初次嘗試EA實踐，則必須對當前的組織治理結構進行更新以便適應新的架構流程。
例如，架構治理委員可能會批准一項旨在定義針對整個組織的標準集成層的計劃。與此同時，某個業務單元可能決定為其環境實施一個不同的集成協議。如果IT採購部門和項目管理辦公室（Business Project Office，BPO）依照不同的治理結構辦事，則尋求某個適當解決方案的業務請求很可能會獲得批准，而試圖為企業範圍集成設定標準的架構計劃則會流產。
第六步：集成架構開發流程與其他管理框架
TOGAF9中的架構開發方法（Architecture Development Method，ADM）是EA從業者在執行某個架構項目時遵循的步進式指南。ADM可以作為一種獨立方法使用，也可以集成到其他架構框架或行業特定的管理框架之中。第五步已經指出，架構治理框架必須與組織的治理框架保持一致。同時，還需強調的一點是，流程步驟必須與其他管理框架的步驟保持一致，這樣就可以避免重複勞動和輸出重複的交付物。
實施TOGAF9時要解決的第一個可能發生的重疊是項目管理交付物和流程步驟。如果組織已經實施了某個架構管理框架（如Prince2），則TOGAF的某些關鍵交付物（如SOW、溝通計劃、實施與遷移計劃）就會與之發生重疊。如果允許這些框架獨立運作，架構項目經理會創建類似但實則不同的交付物，並將它們提交給不同的決策機構。這將在組織中造成混亂。在第三步中，我們會創建一份利益相關者地圖。可以利用該地圖標出各方面的利益相關者，包括項目管理（如Prince2）、開發（如SCRUM）、操作管理（如ITIL）、IT 管理（如COBIT）以及採購等等。同時，要確保架構團隊有權訪問已經在組織中部署的所有業務與IT管理框架和流程。
提示: 將 COBIT 4.1 框架作為集成框架、域 PO (計畫)、AI (生成或採購)、DS (運行) 和我 (監視器) 的起點。首席建築師被定義為 COBIT 4.1 責任矩陣 (每個 COBIT 過程的1個矩陣) 中的一個角色。COBIT 4.1 能力矩陣為每個角色指派一個 RACI (負責、負責、諮詢或通知) 指示器, 並使用問責制矩陣可以識別出首席建築師所涉及的過程。
第七步：進行架構成熟度評估
可以利用能力成熟度模型（Capability Maturity Mode，CMM）來判定企業打算採用EA方法來管理變更和復雜性的準備度。架構成熟度的度量是主觀的，其結果將反映那些完成評估指標的參與者的意見。要想獲得真實結果，重要的是識別那些要度量的關鍵特徵，並從某個成熟的且可以根據組織需要加以調整的成熟度評估開始。TOGAF9提供了一些NASIO架構成熟度模型、CMMI以及DOC架構CMM的例子，可以作為定義組織架構成熟度指標的起點。
提示: 如果配置和完成一個正式的 CMM 評估是不可行的, 但你仍然需要一個指示, 在什麼級別的組織可以受益于以下或改善他們的架構環境, 遵循的階段, 建築學成熟和作為戰略的企業架構中的管理實踐可能是一個很好的選擇。在 EA 專案可以嘗試之前, 管理實踐是必要的: 有一個專案方法論到位, 並有業務案例的所有倡議。
第八步：將架構職能納入組織
組織中任何可持續的架構計劃都需要規範化的架構職能。我們知道，很多組織以項目群或項目的方式實施了它們的架構計劃，但卻沒有為扮演組織中與架構有關的各種角色的專業人員提供組織職業發展通道。
架構職能的結構受前面列舉的很多因素的影響。基於行業、組織成熟度、人力資源戰略、預算約束以及治理結構等因素，必須制定組織結構圖，列出團隊結構、各種角色及其職責。將人力資源構件規範化將使管理團隊能夠啟動後續規劃、技能開發、資源分配以及績效管理。
許多EA項目由於組織人員流動（辭職）、過度使用外包或臨時員工等原因導致失敗或不能實現其最初目標。根據組織戰略，使用外包或臨時員工是可以接受的，但是必須要清楚這樣做存在的風險和對項目的影響，使管理團隊能夠靈活決策。
提示: 使用 TOGAF 9 範本: 企業架構的組織模型, 以整合與成熟度評估、角色和責任、約束、預算要求和治理和支援相關的所有資訊
第九步：定制TOGAF
TOGAF 9是一個不斷演進的框架，用於解決各行各業的問題，包括公共部門和非盈利組織。在第五和第六步，我們已經討論過TOGAF 9需要和其他的管理框架保持一致，以確保各交付物納入組織治理流程和結構之中。這一步是為了推動EA從業者正式編寫定制化的TOGAF流程以及組織要求的任何交付物。 如果有新人加入架構團隊，或者架構流程必須進行規範化和突破（如達到CMMI二級），又或者架構職能在組織中獲得了擴展，則本文極具價值。
提示: 使用您的體系結構存儲庫對內部體系結構環境進行建模, 包括體系結構開發過程。即成為您自己的建築客戶。
第十步：實施之前應考慮的架構存儲庫構件 要想在TOGAF9的基礎上建立可持續的EA實踐，需要一個卓越的架構存儲庫。存儲庫必須提供用以支持TOGAF9成功部署的構件如下：
- 架構存儲庫必須具有一個易於定制化的模型存儲構件（架構景觀），使眾多項目和用戶可以在同一服務器存儲具有製品級安全的內容。
- 元模型必須開放，易於定制。
- 一個提供參考材料（如ITIL、APQC PCF、COBIT、TRM等）的獨立參考庫構件，以及允許將內部組織特定的架構加入各參考庫構件的能力。
- 一個治理日誌構件，可以存儲治理內容（如架構項目文件和決策等）並與某個外部項目管理存儲庫共享這些內容。
- 一個文件庫或內容管理構件，所有非製品架構相關的內容存儲在一個版本受控環境中（包括架構能力文件、項目文件以及差距分析報告）。
- 一個視點庫，具有能夠在組織中重用的一整套預定義視點，並且能夠為組織中的其他製品添加預定義視點。
- 一個分析引擎（使架構師能夠進行假定分析、差距分析、動態視圖創建等）。
提示: 下載下一篇白皮書, 標題為 "TOGAF 9 存儲庫中所需的前10個功能", 以瞭解在選擇體系結構存儲庫工具時需要考慮哪些因素。
結論
EA從業者通常專注於項目交付，極少考慮在EA實踐之前定義項目環境和進行規劃。本文基於TOGAF9標準著重強調的10個步驟是所有架構師在啟動一項新計劃或項目之前必須完成的工作。
EA從業者要想獲得更好的資金支持或提高當前架構項目成功率，唯一途徑就是回歸根本。必須確保有一位理解項目價值的執行發起人、一個理解其作用和組織定位的內部架構師團隊以及對通過自動工具發布並符合需求的一整套視點認可的各種利益相關者。
閱讀清單
- 什麼是TOGAF？
- TOGAF ADM教程
- TOGAF 9.1框架 - 綜合指南
- TOGAF企業架構軟件
- 最好的TOGAF軟件
- 什麼是ArchiMate？
- 完整的ArchiMate觀點指南
- ArchiMate 3更新
- ArchiMate 3有什麼新功能？
- 使用帶TOGAF ADM的ArchiMate工具