第1章 企業架構開發方法（ADM）概述
1.1 認識 TOGAF
TOGAF（The Open Group Architecture Framework）起源於美國國防部的信息管理技術架構框架（TAFIM，Technical Architecture Framework for Information Management），在獲得美國國防部的允許之後，藉助美國政府大筆資金投入，並經過多年的探索後，最終於 1995 年發佈了 TOGAF 1。發展至今 TOGAF 已經發布到了第九個版本，即 TOGAF 9（目前最新的版本是 2011 年發佈的 TOGAF 9.1）。
TOGAF 是眾多企業架構框架理論中的一種，它為一個企業或組織對於企業架構的接受、
創建、使用和維護提供了一系列輔助方法和工具。同時，TOGAF 還是一個基於迭代過程模型的企業架構框架理論，支持該過程模型的重要基礎是全球最佳實踐，以及一系列可重用的現有企業資產。總的來說，TOGAF 的內容涵蓋了企業架構生命週期中的方方面面，尤其是通過在 2009 年發佈的第九版中引入了內容框架，在有關架構內容描述和指導方面填補了以往的空白。在 TOGAF 9 中，The Open Group 將 TOGAF 的各部分內容以及他們之間的關係通過如下的示意圖進行了表述：
圖表 TOGAF 內容結構圖
TOGAF 所包含的各種企業架構相關方法與工具在企業的業務願景、驅動力和業務能力之間建立起了一座溝通的橋樑，促進企業業務能力的實現和發展，而且經過長期的運營，企業的業務能力又為企業的業務願景反饋了新的需求和發展推動力。
TOGAF 內容分為：
1、 TOGAF 能力框架（TOGAF Capability Framework）：為了在一個企業中有效地操作企業架構並使其發揮最大的效能，需要定義一系列適當的組織結構、流程、技能、角色和責任，並將它們進行結合。TOGAF 的能力框架為如何組織好組織結構、流程、技能、角色和責任提供了指南。
2、 TOGAF 架構開發方法和內容框架（TOGAF ADM（Architecture Development Method）
& Content Framework）：是 TOGAF 的核心部分，它包含了兩個方面的內容。其一，架構開發方法是 TOGAF 針對企業架構建設方法的論述，它以一個循環迭代模型為基礎將企業架構的建設過程劃分為前後銜接的若干步驟，並對每個步驟的輸入、輸出以及所採用方法都進行了詳盡的闡述；其二，作為的內容框架部分，它針對企業架構中所包含的各種工作產品以及他們之間的關係作出了詳細的描述。
3、 TOGAF 企業連續序列和工具（TOGAF Enterprise Continuum and Tools）：企業連續序列是企業架構資源庫的一張視圖，它為企業中的各種架構和解決方案製品提供了一種分類和組織的方法。企業架構過程是一個動態的過程，因而這一針對工作制品進行組織分類的方式也不僅僅是一個靜態方法，還是一種能夠隨著企業架構演進而變化其分類方式的動態方法。在此方法的視角中，隨著企業架構的演進發展，其內容也從通用走向特化，其詳細程度也由簡略轉為詳細，而隨著實踐的積累，原來特化的架構或解決方案製品也可能成為在更廣泛範圍內通用製品。除此之外，該部分內容還提供了幾個用於幫助企業架構建設的參考模型以及其他的一些輔助工具。
上述三個部分的內容相對比較獨立，其中能力框架方面的內容著重於幫助企業更好地使用企業架構，架構開發方法和內容框架著重於幫助企業提高其企業架構建設和維護過程的標準化水平和執行效率，而企業連續序列以及各種方法工具則更關注於為企業在企業架構的開發、使用和維護過程中提供參考和最佳實踐。雖然這三個部分相對獨立，但是一個優良的企業架構的創建、使用和維護是他們三者緊密配合、相互作用的結果。不過作為一個開放且靈活的企業架構框架標準，TOGAF 並不要求所有引入它的企業都必須一個不漏的照搬這三個部分的內容，而是可以根據各自的需要選擇相應的部分進行採用，即便是已經建立了企業架構的組織（哪怕他採用別的框架理論來創建其企業架構）也可以將 TOGAF 中的內容與當前企業架構進行融合。
1.1.1 現有的企業架構框架
1.1.1.1 Zachman 框架
Zachman 框架起源於 John Zachman 先生在 1987 年完成的那篇著名的信息系統架構論文
（《A framework for information systems architecture》 ），並一直髮展至今。在這篇論文中 Zachman 先生以修建房屋為例從兩個維度將與信息系統架構設計相關的各種元素歸納到如下表格之中：
表格中的每一行代表了在信息系統構造過程中所涉及到的不同的干係人在描述信息系統時所採用的視角，具體表述：
1、 範圍/規劃師（Planner）：包括整個信息系統描述所處的環境上下文、產生於內部與來源於外部的各種約束，以及其他視角下對信息系統的描述所需要考慮的相關構成部分的列表。
2、 業務模型/擁有者（Owner）：有關最終產品的概念視圖，反映了最終產品的使用特性，即用戶準備如何對最終產品加以使用。具有此視角的干係人包括最終產品的客戶或用戶。
3、 系統模型/設計師（Designer）：有關最終產品的邏輯視圖，反映了最終產品的本質規律以及邏輯約束。具有此視角的干係人包括工程師、架構師以及能夠將期望所得與現有的物理、技術上的實現聯繫起來的各種中間人。
4、 技術模型/建造者（Builder）：反映了在產品構建過程中現有技術的物理約束。具有此視角的干係人包括製造工程師、總承包商以及具有生產最終產品所需的技術能力的組織或人員。
5、詳細表述/分包者（Sub-Contractor）：關於為了達到生產目的而對複雜對象進
行分解的詳細描述，這些內容在從設計媒介到最終產品媒介的轉換中起著非常重要的作用。例如，用於將技術模型中所闡述的技術約束與供應商為所提供的產品聯繫在一起的產品規格說明。
6、產品/運行中的企業（Functioning Enterprise）：在 1987 年的論文（《A framework for information systems architecture》）中並沒有這一行的內容，實際上此行的內容也並不在架構描述的範疇的之內，不過為了使得架構 Zachman 框架對於架構的表述更加完備，這一行最終還是被加了進去。這一行的內容代表了最終產品，是架構在客觀現實中的實例體現。例如，對信息系統架構來說，此行的內容就是最終產出的信息系統，同理，對於企業架構來說，這一行所代表的就是運行中的企業本身。簡而言之，前面五行的內容是對於客觀對象的描述，而這最後一行的內容就是客觀對象本身了。
表格中的每一列代表了用於描述信息系統的某一個方面。在 Zachman 先生看來，對於任何一個事物只要在幾個基本方面對其進行清晰的解釋就足將其描述清楚，而且幾千年來人類自然語言的特性也證明了這一結論。這些方面包括：
1、 數據（What，即什麼內容）：用於表示客觀對象的材料組成，即材料清單。對於企業來說，此部分內容就是組成事物模型（Thing Model，之所以將其稱為組成事物模型而不是數據模型是因為由於不同的行代表了不同的視角，而僅在設計師所處的第三行才會關注真正信息化意義上的"數據模型"，因而在此才使用"組成事物"來對所有視角在此列中的描述對象進行指代）。
2、 功能（How，即如何工作）：用於表示功能和轉換行為。對於企業來說，這部分內容就是流程或功能模型等。
3、 網絡（Where，即何處）：用於表示各組成部件的坐落位置以及相互之間的聯通關係。對於企業來說，這部分內容就是物流或網絡模型等。
4、 人（Who，即何人負責）：用於描述了何人應該做何事，例如用戶手冊和操作說明等。對於企業來說，這部分內容就是人力模型或工作流模型等。
5、 時間（When，即什麼時間）：用於描述事物發生的時間以及不同事物之間的相對時間關係，例如生命週期和時序圖等。對於企業來說，這部分內容就是時間或動態模型等。
6、 原因（Why，即為什麼做）：用於表示最終結果和意義。對於企業來說，這部分內容就是動機模型等。
1.1.2 TOGAF 發展
1.2 架構開發方法（ADM）
架構開發方法（ADM，Architecture Development Method）為開發企業架構所要執行各個步驟以及他們之間的關係進行詳細的定義，同時它也是 TOGAF 規範中最為核心的內容。一個組織中企業架構的發展過程可以看成是其企業連續序列從基礎架構開始，歷經通用基礎架構和行業架構階段而最終達到組織特定架構的演進過程，而在此過程中用於對組織開發行為進行指導的正是架構開發方法。由此可見，架構開發方法是企業連續序列得以順利演進的保障，而作為企業連續序列在現實中的實現形式或信息載體，企業架構資源庫也與架構開發方法有著千絲萬縷的聯繫。企業架構資源庫為架構開發方法的執行過程提供了各種可重用的信息資源和參考資料，而企業架構開發方法中各步驟所產生的交付物和製品也會不停地填充和刷新企業架構資源庫中的內容，因此在剛開始執行企業架構開發方法時，各個企業或組織常常會因為企業架構資源庫中內容的缺乏和簡略而舉步維艱，但隨著一個又一個架構開發循環的持續進行，企業架構資源庫中的內容將日趨豐富和成熟，從而企業架構的開發也會越發明快。
架構開發方法（ADM）建立在一個循環迭代的模型基礎之上，並且 TOGAF 還通過定義一系列按指定順序排列的階段和步驟來對這一迭代過程進行了更加詳盡和標準的描述。不過需要注意的是，這一迭代過程中所包含的各個階段以及每個階段所包含的各個實施步驟並不是絕對不變的；鑑於 TOGAF 本身的開放性和靈活性，針對架構開發方法中各步驟的執行也具備著很高的靈活性，而這一靈活性通常表現為：
1、 TOGAF 並不排斥組織中對其他企業架構框架理論的引入和使用，因而在多個企業架構框架同時並存的情況下，企業架構開發方法各階段的輸入和輸出可以不完全按照 TOGAF企業架構開發方法（ADM）的定義，換可以採用適合組織自身情況的其他框架中所定義的相關內容。
2、 企業架構開發方法中各階段之間的先後順序也並不是絕對的，各組織可以按照自己的實際情況進行適當的修改。
3、 由於各組織的規模和特性千差萬別，因而他們對企業架構開發方法的適應程度也各不相同。對於一箇中小型企業來講，如果嚴格按照上述架構開發方法的階段定義來執行，其繁瑣程度可能會將人們的熱情迅速冷卻，因而針對企業架構開發方法進行適當的裁剪並使其符合組織自身情況對於各個組織來講是非常必要的。
4、 架構開發是一個循環迭代的過程，但是並不意味著每次循環都要走完圖中所有的步驟，而且如果必要的話，在任何一個步驟的執行過程中都可以根據遇到的情況而開展一個新的循環過程。
企業架構開發方法為組織中企業架構的開發制定了一個循環迭代的流程，並且隨著每個架構開發循環過程的完成，組織中企業架構的範圍以及交付物的深度和廣度都得以演進，但對於企業架構範圍的決定卻應獨立於這一企業架構開發方法的執行過程。在每一次架構開發方法迭代過程開始之前，組織都需要針對如下幾點進行考慮：
1、 組織將要在什麼範圍內進行架構定義和建設？
2、 需要採用何種詳細度進行架構描述？
3、 需要建設的企業架構的目標時間區間是什麼？
4、 所能夠使用的架構資產（包括上次迭代過程中產生的各種架構資產以及存在於組織外的行業通用資產）都有哪些？
以上四個要點制約著企業架構以及相關架構活動的範圍。理論上來將，為整個組織的方方面面進行全面的建模是企業架構的終極目標，而在現實生活中如此理想的目標往往會成為不可能的任務，而更加理性的做法應該是立足於當前的狀況對每次架構工作的範圍進行約定，並通過一次次的工作迭代逐步豐富企業架構內容的深度和廣度，從而逐漸接近於理想狀態。這種方式對於結構複雜的大型組織來說尤為重要，這種組織往往是由若干業務單元通過聯邦的方式組合而成，而在這種情況下一個有效的企業架構過程應該是對架構的範圍和活動進行明晰的劃分，並在最後進行有效的整合的過程（美國聯邦政府的FEA 就是一個很好的例子，雖然具有著獨特的架構建設和維護方法，但是在如何應對繁雜組織的複雜度方面，其與 TOGAF 有著相通的見解）。總的來說，TOGAF 的企業架構開發方法的基礎是對企業架構的範圍進行適當限定和定義，而這些限定和定義的方面包括：
1、 企業範圍或著眼點：用於表述企業的整體範圍，以及架構活動所涵蓋的範圍。
2、 架構領域：一個完備的架構描述需要涵蓋四個架構領域中的內容，即業務、數據、應用和技術，而這也正是限定架構內容範圍的維度之一。
3、 詳細度：用於表述架構內容的詳細程度，即何種程度的架構描述才是足夠的。
4、 時間段：用於表述架構願景所描述的是在未來哪個時間段的目標，以及此目標是否可以在指定的詳細度上被描述清楚，如果不能則需要對中間過渡狀態進行制定，並且對每個過渡狀態的描述所採用的詳細度應符合指定的需要。
一般來講，企業架構範圍的定義和限定首先需要明確企業範圍或著眼點、詳細度和時間段這三個方面。在這三個方面被確定之後，組織需要根據所面對的問題開展針對各種架構領域的選擇和組合，從而實現針對企業架構範圍的最終確定。需要注意的是，之所以架構範圍需要被限定，是因為現實中的資源不是無限的，這些限制一般包括如下方面：
1、 架構開發團隊的權力有一定限制。
2、 企業中不同角度的干係人的關注點千差萬別。
3、 人力、資金等資源的限制。
綜上所述，企業架構開發方法是一種非常靈活的架構開發指導方法，任何組織不論其身處何種行業或是具備什麼樣的規模都可以將其作為指導自身企業架構建設的方法。需要注意的是，企業架構開發雖然能夠指導企業架構的建設，但是企業架構的範圍則需要組織自身根據實際情況來進行定義和限定，也只有這樣才能讓企業架構開發方法的進行得以處在一個現實可行的環境當中。那企業架構方法具體如何進行呢？為了解答這個問題，本節隨後的內容將會對企業架構開發方法的各階段和步驟進行詳細描述。
第2章 預備階段
2.1 目標
1、 對進行企業架構活動的組織的背景和環境進行審查。
2、 明確企業架構的贊助人，以及其他將被創建企業架構這項業務指令所影響的主要干係人，並確定他們的需求和優先級、他們與組織的關係，以及他們之間所需的工作行為。
3、 確保所有將要被涉及到的或受益的人員致力於架構過程的成功。
4、 促使架構贊助者為將要受到影響的業務領域的工作制定需求。
5、 明確受此業務指令影響的各個企業組織元素，並對其範圍進行界定。此外，還需要為這些元素定義各種約束和假設。
6、 定義組織的"架構足跡"，包括負責執行架構工作的人員、他們的位置以及職責。
7、 定義用於進行企業架構建設的框架和詳細方法。
8、 確定一個治理和支持框架，用來在整個 ADM 過程中為架構治理提供業務流程和資源方面的支持。此種框架將會確保目標架構的適用性（fitness-for-purpose），並對其在進行過程中的效能進行評測。
9、 選擇和落實用於支持架構活動的各種工具和基礎設施。
10、 定義架構原則，而這些原則將會成為約束架構工作的一個部分。
2.2 方法
預備階段在於為企業或組織定義在哪裡、為什麼、誰負責、如何創建架構，以及架構的大體內容是什麼，具體包括如下幾個主要方面：
1、 確定企業的範圍，並藉此明確將要從企業架構中獲益的各個干係人。
2、 為了在某個企業中為採用何種框架做出一個有效且明智的決定（包括如何對框架進行裁剪，從而適合組織的需要），明確組織背景和環境是必需的，這包括針對如下幾個方面的考慮：
①．企業架構的商業模型和企業架構活動的預算計劃。
②．企業中與架構相關的干係人以及他們的關注點。
③．組織的意向和文化。
④．當前用於支持變更執行和 IT運營的各個流程。
⑤．基線架構景觀，包括企業當前的狀態以及其景觀如何通過文檔的形式來表現。
⑥．將要使用架構框架的組織的技能和能力。
3、 架構工作需求：處在架構工作背後的業務需求驅動了針對架構工作的需求和性能指標的制定。這些需求應該足夠清晰，從而使得業務輸出和資源需求得以被界定，同時簡要的企業業務信息需求以及與之相關的企業架構工作策略也將被定義出來。
4、 制定原則：在此階段制定的架構原則將會成為日後用於約束架構工作的各種內容的重要組成部分。
5、 明確組織的管理框架：企業架構開發方法是一種通用的方法，它既可以適用於各種行業，亦可以與企業中已經存在的各種管理框架相融合。一般來講，能夠與 TOGAF相互協調的管理框架包括業務能力管理、組合/項目管理方法、運營管理方法和解決方案開發方法。這些框架並不是相互隔絕的，而是相互交疊並組合在一起來為組織提供價值，因而TOGAF 也不能僅僅著眼於 IT 實現，而應該擴展視野，將關注點放到其對整個組織的影響之上。這種與組織中其他框架的融合也為組織在引入 TOGAF 時提出了要求，即組織應根據自身特點對其進行適當的改造。
6、 將各種管理框架進行關聯：由於組織中存在著各種作用不同的管理框架和方法，因而他們與企業架構之間的合作關係應該得到明確的定義。在 TOGAF規範中列出瞭如下圖所示的一張管理框架關係圖：
7、 組織中管理框架之間的關係與交互為企業架構/業務變更的成熟度評估進行規劃：能力成熟度模型（CMM，Capability Maturity Model）是一個根據各種選定因素而進行評估的有效方法，在企業架構的建設中亦是如此。成熟度的實際水平為組織的變更能力提供了一個戰略上的評測以及一系列用於改善組織能力的步驟。一個好的企業架構成熟度模型應該在很大程度上涵蓋了企業的各項特性，這既包括業務方面，也包括技術方面。每個組織都可以根據自身情況制定各項評測因素，並據此建立起適合於自己的成熟度模型，不過 TOGAF建議組織應以某現存並且開放的成熟度模型（例如NASICO、美國聯邦企業架構成熟度模型等）為基礎來定製符合自身需要的成熟度模型，而不要憑空創建。
2.3 輸入輸出
2.4 步驟
1、 界定將要受到影響的企業組織的範圍。
①．識別出將會受到架構工作最大影響的核心單位。
②．識別出工作組將會發生變化、但不會直接被影響的單位。
③．識別出不在被界定的範圍的企業內的擴展單位，這些單位會被他們自身的企業架構所影響。
④．識別出涉及到的各個群體-那些利益相關者會受到影響，那些人屬於一個群體。 ⑤．識別涉及到的治理方法。
2、 確定治理和支持框架。
①．這一步驟的主要輸出是一個作為機構治理的框架。
②．現有的組織治理和支持模型可能需要改變。
③．目前的治理和支持模型需要評估，以瞭解其內容。
④．有關的潛在影響，將需要諮詢贊助者和利益相關者。
3、 定義並建立企業架構團隊和組織結構。
①．確定現有企業和業務能力
②．進行架構/業務變更成熟度評估
③．識別在現有的工作領域的差距
④．為企業架構能力的管理和治理分配關鍵的角色和職責
⑤．撰寫對現有項目的變更需求
⑥．新企業架構工作的範圍
⑦．確定對企業架構工作的約束
⑧．與贊助者及其委員會一起評審並達成一致意見
⑨．評估預算需求
4、 明確並制定架構原則。
①．定義架構原則
②．TOGAF架構原則的模板
③．業務原則 ④．數據原則 ⑤．應用原則 ⑥．技術原則
⑦．範例-首要性原則、自助服務、面向服務
⑧．架構原則的五個質量性質
⑨．原則和元模型
5、 選擇架構框架，並對其進行定製。
①．術語定製：最好用整個企業都理解的術語。
②．流程控制：ADM是一種通用的流程。定製流程允許我們去掉一些在其他地方完成的任務，增加一些組織特定的任務，並將 ADM 流程與外部流程框架保持一致。
③．內容定製：使用 TOGAF架構內容框架作為基礎，也可採用第三方的內容框架
並定製該框架，以支持組織的特定需求。
6、 落實相關架構工具。
①②③④⑤⑥⑦⑧⑨⑩
第3章 階段 A：架構願景
3.1 目標
1、 確保架構開發循環的進展被企業管理層認知和支持，並取得必要的管理線的支持和承認。
2、 在預備階段中明確的架構框架的整體背景之下定義和組織架構開發循環。
3、 驗證業務原則、業務目標、組織的戰略業務驅動力，以及企業架構的主要性能指標
（KPIs）.
4、 定義基線架構的範圍，明確其所包含的組件以及組件的優先級。
5、 定義相關干係人以及他們的關注點和目標。
6、 定義架構工作所要解決的關鍵業務需求，以及必須應對的各項約束。
7、 闡明架構願景，並定製價值主張。這些價值主張被用來闡述對於那些需求和約束的回應。 8、創建一個綜合性計劃，用來表明規劃進度、資源、財務、溝通、風險、約束、假設和依賴關係，並應與企業中的項目管理框架相適合（PRINCE2 或 PMBOK 等）。
9、 確保正式批准得以執行。
10、 理解與其他並行的企業架構開發循環之間的相互影響
3.2 方法
架構願景階段是從架構組織收到來自於架構贊助組織的架構工作要求書時開始的。在這個階段中，組織需要基於針對當前資源及其可用性所做的評估來界定架構工作的範圍，以及需要應對的種種約束。這些約束通常來源於在準備階段中制定的各項業務原則和架構原則，而在架構願景階段中，組織需要確定這些原則是存在並清晰的，如果不是這樣，則需在此階段對這些原則進行明確的定義。除此之外，在此階段所涉及到的方法還包括：
3.2.1 創建架構願景
架構願景是架構贊助者向各干係人以及決策者推廣其所提出的能力的絕佳工具，它描述了新的能力如何滿足組織的戰略和業務目標，以及當這些能力實現時，相關干係人所關注的問題又是如何獲得解決的。因而針對架構願景的創建實際上就是對架構的目標進行明確，並對如何通過架構開發來達成這些目標進行闡明。架構願景在一個很高的層面上為基線和目標架構做了有關第一印象的描述，並且這一描述應該涵蓋業務、數據、應用和技術這四個層面
（這只是概要性描述，這些層面的具體內容將在後續的相應階段被逐步細化）。
一旦架構願景被定義並被記錄到架構工作說明書中，接下來在各個干係人中對這份架構願景形成共識將會成為重中之重，因為如果沒有這份共識，那麼最終的架構是否能夠被組織所接受就無從談起了。這份共識的獲得是通過贊助組織簽署架構工作說明書來實現的。
3.2.2 業務情景業務情景方法用於識別和闡明隱含的架構需求和隱藏在新業務能力（用於滿足關鍵業務驅動力的需求）中的業務需求。此技術通過一種循環迭代的方式進行，並針對業務架構的各層次化分解部件採用不同等級的詳細度進行描述。
3.3 輸入輸出
3.4 步驟
1、 建立架構項目；①②③④⑤⑥⑦⑧⑨⑩
①．引導企業-特定程序已獲得：
A．企業-廣泛的認可。
B．公司管理者背書。
C．部門管理者的支持和承諾。
②．參考其他管理框架：
A．解釋此項目如何關聯到那些框架。
2、 識別干係人、關注點和業務需求；
①．在這裡我們必須識別：
A．候選願景構件和需求。
B．候選範圍邊界。
C．利益相關者關注、議題、和文化因素。
D．項目相關的關注和視點。
E．項目涉及的利益相關者。
F．項目內的關鍵角色和責任。
②．另一個關鍵的任務將是考慮哪一個架構視圖和視點需要制定，以滿足各種利益
相關者的需求。
3、 確認並闡述業務目標、驅動力和約束；
4、 評估業務能力；
5、 評估業務轉型準備情況；
6、 定義範圍；
7、 確認並闡述架構原則，包括業務原則；
8、 開發架構願景；
9、 定義目標架構價值主張和主要性能指標；
10、 明確業務轉型風險和緩解措施；
11、 開發企業架構計劃和架構工作說明書，並確保被批准。
最後大家最關心架構精要資料的獲取！
領取方法：
1.評論文章，沒字數限制，一個字都行！然後轉發出去！
2.關注小編，成為小編的粉絲！
3.私信小編：“精要”即可！
謝謝大家，祝大家學習愉快！
