運用TOGAF ADM 的準備階段

準備階段的目標

1. 決定適合組織的架構能力(Architecture Capability)
2. 建立企業的架構能力

以雲端運算來說，需要評估組織的現有組織架構、流程、人員技能等關於組織上的事項是否能成功建立雲端運算的能力。

準備階段的輸入資料

1. 架構框架(Architecture Framewroks): TOGAF 文件庫、或其他的參考框架，如AWS的Well-Architectured或 Azure Well-Architected Framewroks
2. 治理和法律框架(Governance and Legal Frameworks): 包含架構治理策略(Architecture Governance strategy)
3. 其他框架: 有一些組織所處的產業需要遵守的框架
4. 組織特有的規範文件: 像是董事會的策略，業務原則、目的與驅動因素
5. 已存在的架構儲存庫(Architecture Repository)事項: 框架，企業架構的組織模型

準備階段的步驟

步驟1: 受影響的企業組織範圍

• 誰會受到影響?誰會從這項架構專案獲得最多的價值?( 稱為Core Units)
• 誰會看到這個架構專案實施之後的變動，並且是會跟主要單位(也就是獲得最多價值的)一起作業但不會受到該項專案的影響(稱為Soft Units)
• 這個架構專案實施之後在企業之外誰(可能是客戶或合作夥伴)會受到影響?(稱為Extended enterprise)
• 誰是那些將受到影響的利害關係人(稱為Communities)
• 治理結構(Governance structure)是甚麼(包含了法規法令框架)?例如上雲端之後遵守GDPR可能會變得需要仔細監控。

步驟2: 確認企業所需要的治理框架與支援框架

"治理(Governance)"是該階段最重要也是最主要的產出。如果組織已有任何現有的治理模型，它們是否需要隨著 TOGAF 的導入而改變?而治理是為了確保"變革"以"安全且有序"的方式發生。完成這一個步驟代表架構的初始概念與其可能的風險都已被相關的利害關係人理解與認同。

步驟3: 建立企業架構團隊/組織

• 組織現有的架構能力甚麼?(如果有的話)
• 組織已經準備好有一個正式架構能力了嗎?(這是指架構/業務變革成熟度評估)
• 辨識差距(gap)
• 為企業架構能力(Architecture Capability)管理和治理分配主要角色和職責
• 判斷是否有任何的制約因素(各項資源限制-人/錢/時間/技術)
• 與架構專案發起人(通常是CIO)和架構委員會達成協議
• 確認資金/資源已經到位

步驟4: 定義與建立架構原則(Architecture Principle)

原則是告知組織內的人員完成其企業使命的方式的一般規則和指南。例如確定Cloud First是組織的原則。並且原則應該是持久的，其意圖是讓原則會持續一段時間。

• 有一套指導原則可以更容易地決定解決問題的方法
• 一群原則相互關聯並作為一個集合來使用
• 有時需要進行權衡與取捨

通常以下因素會影響著組織的架構原則:

1. 企業的使命與規劃
2. 企業的戰略舉措(企業自己的S.W.O.T)及其當前的企業戰術意圖（例如流程改進和質量管理）
3. 外部的制約因素，如市場因素、法律因素等
4. 現行存在於企業內的系統與技術。
5. IT技術的趨勢。關於IT技術的使用、可用性和成本的預測，這些預測大都來自目前正在使用的相關最佳實踐。

哪我們如何運用架構原則呢?所謂架構原則就是企業如何使用與部署IT資源與資產的一個基本事實。原則有以下不同方式來呈現:

• 有一個框架，這個框架可以讓我們做出一個經過思考的企業架構決策。該決策可以讓我們達到目標架構
• 原則可以指導我們產生相關的評估規則，規則可以幫助我們在之後的ADM階段中選擇產品與解決方案並且符合我們的企業架構合規標準
• 作為評估現有實施和未來策略組合的輸入，以符合已定義的架構； 這些評估將為實施架構所需的過渡作業提供有價值的見解，以支援業務目標和優先事項
• 作為定義架構功能需求的驅動力量
• TOGAF 原則模板中的理由陳述(Rationale statement)突顯了架構對企業的價值，因此為架構作業的合理性提供了基礎
• TOGAF 原則模板中的影響陳述(Implications statement)概述了企業遵循該原則的主要工作、資源和潛在成本

原則是相互關聯的，需要作為一個集合來應用;例如雲端運算的"可存取性"與”安全性”原則。每項原則都必須在“所有其他條件相同”的背景下加以考量。 有時需要決定在特定問題上哪個原則優先。 此類決策的理由應始終記錄在案。 一項原則看似不言而喻的事實並不意味著該原則實際上在組織中得到遵守或接受，即使存在對該原則的口頭承認。 雖然原則宣言中沒有規定具體懲罰，但違反原則通常會導致運營問題並抑制組織履行其使命的能力。

在具有聯合架構的大型企業中，較高等級架構的要求通常在較低等級的架構中呈現為“原則”。 這通常採取原則的形式，聲明較低等級的架構必須遵守較高等級架構的原則。 另一個例子可能是組織內的技術原則，比如“所有的應用程式都必須支援容器化”。

原則引領我們開發架構。 它們不應相互損害牴觸，也不應成為其他原則的障礙。 雖然我們不太可能始終實現這些原則 — — 但我們應該盡力實現這些原則。以下是一個經過架構委員會核可的原則宣言:

業務原則:

1. 原則至上
2. 為企業帶來最大利益
3. 遵守法律
4. 系統與服務隨時隨地可用
5. 業務連續性(Business Continuity)
6. 公民權
7. 管理者的職務
8. 去客製化
9. 無痛的用戶體驗
10. 自助服務

架構原則:

1. 去技能化
2. 一個來源
3. 內容管理

而所謂原則至上是指我們在企業架構的整體脈絡考量中，在做決策時原則都應該被納入考量。而在原則聲明中(Name/Statement/Rationale/Implication)，理由(Rationale)告訴我們我們這個原則的"效益"是甚麼，而影響(Implications)則告訴我們要達到這樣的原則需要有甚麼"要求"。

步驟5:量身訂做組織的TOGAF框架與其他現有既存框架

TOGAF 9 標準主要在對每一個個別企業能量身訂做(也可稱客製)，所以能夠適應我們自己的企業需求和文化。在這個過程中，任何TOGAF框架中與我們組織無關的都可以去除。並且量身訂做後的TOGAF標準可以整合到企業現有在使用的框架或業務流程，這個整合的程度視乎組織的架構能力(Architecture Capability)。量身訂做的意義在於我們可以對利害關係人與專案有適切的可交付成果與工件。

以下為客製化框架時會考量到的因素:

• 術語客製：使用的術語應該是整個企業都能理解的術語。客製應該為架構內容的描述生成一個通用(就是大家都懂)的術語集。 如果可以的話，應該有一個術語名詞解釋表。
• 流程客製：ADM 是一個通用流程。流程客製允許刪除已在企業其他地方執行的工作，加上組織特定工作，以及使 ADM 流程與外部流程框架保持一致。
• 內容客製：使用架構內容框架(Architecture Content Framework)和企業連續體(Enterprise Continuum)作為基礎，內容結構和分類方法的客製允許使用第三方內容框架，還可以客製框架以支援組織特定的要求

步驟6: 為工具與技術制定策略與實施計畫

在這個步驟中我們需要確定這個架構專案/作業該怎麼樣管理，是自行開發或是購買現有的商用解決方案? 例如，架構儲存庫(Architecture Repository)是需要一個良好的目錄架構，可以被稽核，有版本控制與權限管控。像是可以使用Microsoft Sharepoint當作架構儲存庫。

準備階段的產出

1. 架構原則
2. 企業架構的組織模型。一個響亮的名稱，這個組織模型也是該階段重要的產出。定義企業受影響的範圍，成熟度評估，差距(gaps)，R&R(role and responsibility)，制約因素，預算需求與治理策略。同時也要定義不同企業架構團隊內的成員，他們個別的工作範圍。並且有一個能夠治理這些不同工作範圍之間關係的方法。
3. 量身訂做的TOAGF框架。在TOGAF框架中那些是組織會用得到的還有用哪種工具來管理架構作業
4. 架構儲存庫。這基本上是一個CMS(Content management system)，來管理所有架構作業後的產出並且保存每一個版本。草稿/最終版與工件(artifacts)，包含不同的利害關係人的看待架構的不同視圖(views)
5. 業務原則，目的與驅動因素的再聲明(這會是之後好幾個階段的產出)
6. 架構治理框架(Architecture Governance Framework)。重要的是治理模型(governance model)
7. 架構作業要求(Request for Architecture Work)。這是組織與架構團隊之間的"合約"，也是整個ADM週期的正式要求。發起人、使命宣言、業務目標、戰略計劃、時間限制、業務環境的變化、合約、預算、現行業務系統描述、現行架構系統描述、組織描述、可用資源描述。

準備階段的總結

在這一階段最重要的是將組織相關的文件都整理在一起，以開始我們的架構準備階段。在這一階段都是高階作業，沒有任何的實際執行動作。因為這一階段我們需要針對建立架構團隊、架構治理、架構方法與架構原則。也要確保參與的每一個人對架構的目的與範圍都是一樣的認知(on the same page)。