如何使TOGAF標準服務於企業架構

摘要： 本文要點 TOGAF取代了逐步發展企業架構實踐的需要。熟悉這個標準可以取代重新創造EA流程、實踐、結構和原則的需要。 為了對TOGAF有一個全面的瞭解，包括流程、內容、指南、角色、結構，學習該標準的七個基本部分。 利用TOGAF技術，把它...

要記錄大型企業系統的所有複雜性是一個巨大的工程，而且都很難知道從哪裡開始。此外，開發滿足企業戰略的企業架構，並保證良好的架構質量，是一項有挑戰性的工作。TOGAF中的指南和結構可以提供幫助。這是一個分層的、經過測試的框架，為企業架構的許多方面提供指南。這裡，我將分享TOGAF的好處，如何入手以及如何把它與其他方法結合起來。

不久前，出於各種原因，我著手完成TOGAF 9認證。在經過大量的學習和準備之後，我通過了兩部分考試。但是，在完成考試後，我變得特別推崇整個TOGAF標準的全面性，遠遠超出預期。

為了說明TOGAF的價值，我將首先概括地介紹下這個標準。然後，我將大概介紹下它對於企業架構的貢獻，並提供在組織中運用這項標準的指南，說明如何調整標準以適應其他的技術。因為該標準由七個精心設計的部分組成，我將選擇幾項對你有幫助的重點介紹下。為了更好的理解這個標準，我建議查閱ofollow,noindex" target="_blank">完整的標準 。這篇概述是為了鼓勵你採用一種成熟而深入的標準，而不是逐步發展自己的。

先說下我的背景。我有17年的技術生涯，在過去的八年裡，我更多地關注軟體、系統和解決方案結構。到目前為止，我已經完成了36個架構設計，領域涉及應用程式、整合、雲、UI、移動和CI管道。在這些架構中，有25個實現了，目前還在使用或在生產環境中。雖然我仍在設計各種型別的技術架構，但是，我的工作已經逐步地向企業架構轉移。

目前，我大部分的工作都是在一家大型服裝公司的供應鏈中，圍繞設計、監督和管理一系列基於運輸物流的線上零售應用程式而開展。在這個組織中，作為董事會成員，我還積極參與到架構評審委員會裡。該委員會負責架構評審、技術標準化、制定藍圖、設計指導，以及加強安全措施，保證工件格式和質量的一致性。

在這個組織裡，架構評審委員會的結構和活動都是自行設計的，在委員會成立後經過了短暫的發展。隨著我越來越多地參與到企業架構的流程、活動和相關問題中，我希望藉助行業認可的企業架構標準來形式化我的經驗。我通過TOGAF認證的目的是學習一種全面而又備受推崇的企業架構方法。我希望以我在這個領域的經驗為基礎，學習一門新學科。再者，我現在希望能勸說組織建立並實行一種全面的企業架構實踐。

企業架構的價值

那麼，為什麼說TOGAF標準很重要？或者更進一步，為什麼說企業架構（EA）很重要？企業需要發展變化，提供新產品和新服務來營利並保持地位。但是，在企業的整個生命週期中，新系統被建立，企業兼併需要系統整合或整合，為了保持競爭優勢，新技術被採用，更多的系統需要通過整合來共享資訊。為了應對、處理和管理這些技術和計算複雜性，在組織層面，一個恰當定義、管理的企業架構實踐就尤其重要。如果沒有EA實踐，系統之間就會缺乏連線，解決方案就會不一致，產品團隊和工程團隊就會缺少交流，工程工作重複，組織架構和解決方案質量受損。

讓我們舉一個產品初創公司的例子。該初創公司會經歷快速增長，迅速從新生進入初期發展階段。業務和技術都會經歷頻繁的變化。如果沒有EA實踐，或者至少是某個層面的架構指南，那麼該初創公司可能很快就會發現其系統不一致，無法共享資訊。公司發展越快，威脅就越是迫在眉睫。

另外一個可以說明EA必要性的典型例子是併購。當兩家公司合到一起，多出來的系統需要共享資訊，或許需要合併。例如，可能有多個面向員工的HR系統需要整合或整合成一個。不恰當的整合會導致員工資料無法共享、軟體缺陷、傳輸錯誤、過度傳輸以及為了與其他的系統實現恰當的業務連續性而額外進行的手工過程。此外，你可能需要合併或者把EA框架轉換到一個模型下，如TOGAF。

總之，使用一個成熟的企業架構標準，如TOGAF，可以提供更有效且更高效的IT運營。它可以提高投資回報，降低未來冗餘投資風險，加速採購，降低採購成本。所有這些好處都支援更高效的業務運營。

TOGAF概述

開放組架構框架，簡稱為TOGAF ，這是一個由The Open Group 組織建立的企業架構框架標準。該標準是一個方法論，包括一套流程、原則、指南、最佳實踐、技術、角色和工件。它用於開發和治理企業架構，妥善處理業務需求。認證學習指南 中有一個恰當的定義：

企業架構的目的是把企業範圍內那些碎片化的流程（手工的和自動的）優化成為一個整合的環境，可以響應變化，支援業務策略的交付。

為了實現這個高階目標，該標準建議建立幾個底層的策略元素為此提供支援。這些元素包括——指導原則、一個全面的架構開發方法（ADM）、一個活的架構統一體、一個活的工件庫、一個治理結構、一個能力框架和一個參考模型庫。你可能已經看到，其中有些方面是結構，如統一體和庫。但其他方面是流程，如可迭代的ADM架構開發方法。

為了更好的理解該框架的元件，下面將介紹該標準的結構。

♦ 第一部分：簡介

• 定義常用術語，在TOGAF標準的語境下。例子包括定義一個企業、企業架構和架構框架。
• 提供核心概念概述。例子包括ADM、輸出型別、統一體、庫、能力以及把TOGAF與其他架構框架搭配使用。

♦ 第二部分：架構開發方法（ADM）

• ADM是一個可迭代的架構開發方法，由9個階段構成，為架構師和組織開發、交付架構提供指導。

（1） 5.2.2小節 TOGAF 9.1標準

• 階段包括定義的活動/流程、預期的輸入和輸出。
• 可以對階段進行調整以滿足組織需求。它們可以作為一個完整的週期進行迭代，根據需要，相鄰的迭代或內部迭代。

♦ 第三部分：ADM指南和技術

• 指南提供備選方法，用於調整ADM流程，處理變化的使用場景。一個例子是如何把迭代選項運用到ADM。
• 技術是支撐ADM迴圈任務的具體手段。例子包括確定和應用架構原則、利用架構模式、定義業務場景、執行差距分析。

♦ 第四部分：架構內容框架

• 定義一個元模型，把架構工作的輸出分類。例子包括交付物、工件和構建塊。
• 區分交付物、工件和構建塊。為每一個提供具體的內容示例。

♦ 第五部分：企業統一體和工具

• 提供一種架構和解決方案資產分類方法，提供一致性，促進重用。企業統一體有兩個內部統一體構成：架構統一體和解決方案統一體。
• 內部的架構統一體根據角色、架構設計、表示、關係對輸出（交付物、工件、構建塊）進行分類。這種分析可能更多是抽象的，或者與解決方案需要支援的原則有關。架構統一體是解決方案統一體的指南。
• 內部的解決方案統一體提供具體的方法，利用技術和框架，實現架構統一體中的資產。它支援架構統一體。
• 這兩個統一體架構類別都是水平排列的——從左（更一般或抽象）到右（更具體）。每個都包含基礎、通用系統、行業和特定組織四類。

[點選檢視大圖]

（1） 39.3小節，TOGAF 9.1標準

♦ 第六部分：參考模型

• 提供滿足常見業務目標的非常一般化或抽象的架構&技術參考模型。
• 例子包括技術參考模型（TRM）架構，提供一般化服務和函式，作為更具體架構的基礎。

♦ 第七部分：企業能力模型

• 提供組織結構、流程、角色、職業和技能，以便在組織裡建立和運營企業架構實踐。
• 在架構委員會、合規審查、契約、治理、成熟度模型和員工技能框架的支援下建立架構能力。

標準的應用

在大概介紹了企業架構和TOGAF的好處後，讓我們討論下如何把它運用到組織中。雖然上面介紹的7個部分可能看上去非常複雜或是“重量級流程”，但總的來說，它們非常全面。可以把它們看成是住宅或商業大廈的藍圖。

在TOGAF中，該標準的這些部分介紹了架構分類、引入迭代方法交付架構、支援的組織結構、指南和技術、治理、促動原則、參考模型、資產庫等等。你沒必要自己重新創造這些東西。

但是，你並不是需要標準中的所有東西才能成功。你必須知道它提供了什麼以及如何有效地運用它。

當引入TOGAF（或任何EA實踐）時，一項建議是從小處著手。例如，在開展實現工作時，開始時把ADM階段和組織的專案方法聯絡起來。對於每個可運用的階段，識別出所需的輸入和理想的輸出。執行ADM階段的流程和活動，提供輸出和預期的結果。例如，在建立新的目標架構時，運用ADM階段B、C、D（業務、資訊系統和技術架構階段）建立一個基線架構，然後執行差距分析識別出隱患。另外一個實現EA的例子是，著手在一個企業統一體中彙集現有和全新的架構資產。建立一個架構內容框架，開始對工件、交付物和構建塊進行分類。

在整個工作過程中，使技術、專案和利益干係人團隊參加集體學習，熟悉相關概念和術語。列出TOGAF標準已經幫助交付的成果。接下來，在適當的時候，你可以引入一個更正式的流程。介紹需要在組織方面正式確認的東西，如架構委員會和治理實踐。至於完整的活動和注意事項列表，請查閱TOGAF標準46小節 （9.1版本）。

適應其他框架和方法

最後，TOGAF認可偶爾需要把標準與其他業務、專案或運營管理方法整合。每一種管理方法的動機都是它自身關注的問題。TOGAF關注滿足業務策略的高質量架構。可能需要對它進行調整以使用其他架構框架，如Zachman框架。請查閱該標準的2.10小節 （9.1版本）瞭解把TOGAF與其他框架混合的指南。提到的方法包括識別架構活動的可交付輸出，然後識別輸出應該在哪個活動或階段產生。讓我們看兩個例子。

示例1：調整TOGAF以適應敏捷方法

敏捷開發方法被廣泛應用於以迭代方式開發和交付基於技術的專案。敏捷關注開發和專案，是為了確保交付的產品滿足利益干係人的關切。

相比之下，TOGAF ADM更多的是關注架構，是為了確保目標架構將支援利益干係人的關切，並且支援長期的業務策略。當需要交付目標架構時，應該採用ADM。不是所有的敏捷專案都需要交付一個新的架構（例如小版本和史詩），因此，就不需要引入ADM迴圈。但是話說回來，ADM也是一個迭代過程。它很靈活——你可以圍繞所有八個階段進行迭代，或者在單個階段內部迭代。它是提供健壯目標架構的最佳選項。記住，開發團隊依賴你提供一個高質量的架構產品。

如何與敏捷開發團隊一起把ADM作為企業架構引入？讓我們看一個例子。

首先，時間就是一切。從初始階段到階段D的大部分介紹性工作需要在開發團隊接受它並用於解決方案和實現之前完成。這包括以下階段：初始階段、架構願景、業務/資訊系統/技術架構設計。在理想情況下，企業架構師致力於分析、設計和交付，而敏捷團隊致力於完成前一個版本。理想時機是在階段D、開發團隊開始解決方案和實現、進入下一個敏捷版本之前交付最後的企業架構輸出。接下來，在解決方案階段，企業架構師應該自始至終進行監督，確定是否需要過渡架構。架構師應該在後臺跟蹤遷移計劃任務（階段F）和實現治理任務（階段G），而敏捷團隊開發解決方案。敏捷團隊交付應該由ADM階段H架構變更管理任務支援。

示例2：調整TOGAF以適應Zachman框架

雖然一個組織不可能同時引入多個企業架構框架，但有一種可能的情況是正在進行併購。例如，兩個合併後的組織可能會使用不同的框架——TOGAF標準和Zachman框架。長期來看，可能會縮減為一個框架，但是，在併購過程中，這兩種方法可能需要共存。

澄清一下，Zachman框架 不是一種方法論，它是一種本體論，描述適用於架構的企業結構。TOGAF是一種方法論，有ADM作為交付企業架構的流程，還提供了其他多項能力。不過，調整TOGAF以適應Zachman證明了TOGAF的靈活性。此外，這還可以為組織從Zachman轉變到TOGAF提供一條可行之路，因為與Zachman相比，TOGAF提供了一種更為全面的解決方案。

首先，評估Zachman表模型的維數。雖然經過了多年的發展，但總結起來就是下面這些內容。表的列從左向右是使用疑問詞什麼、怎樣、何時、誰、哪裡、為何 提出的問題。你可以把這些列理解為需要採取什麼行動或交付什麼東西的線索或提示。表的行從上往下是背景、概念、邏輯、物理和細節 等階段概念。你可以把這些行理解為需要不同輸出的不同視角。本質上講，這個框架涉及專案的所有參與者，詳細說明了他們應該提供什麼輸出，構建一個令人滿意的目標解決方案。有人可能會爭論說，Zachman框架不屬於架構框架範疇，它更多的是一個專案框架。

在概要介紹了Zachman框架之後，我們現在可以調整它以適應TOGAF標準了。我們看個例子。

首先，你可以把Zachman表的行概念（背景、概念、邏輯、物理和細節）理解為專案的階段，而不僅僅是視角。Zachman的背景行可以對應到ADM初始階段和階段A——架構願景。下一個Zachman行，概念，與ADM架構願景（階段A）和業務架構（階段B）存在一些重疊。以此類推，偶爾可能會有輕微的偏差需要解釋。

小結

希望你現在已經瞭解了TOGAF的價值以及它如何服務於企業架構。實際上，它是一種深入、全面、適用性強的方法，運用企業架構服務於業務需求。歡迎在評論區反饋及介紹經驗。

關於作者

是一名技術架構師兼顧問， 他有多年行業經驗，涉及多種架構，包括軟體工程、雲、UI、移動。他獲得了計算機軟體安全理學碩士學位、電腦科學理學學士學位。他獲得了多項行業認證，提供獨立諮詢，並且已經獨立推出了兩款自制產品Valloc.com 和SocialIntuition.co 。

檢視英文原文：How the TOGAF Standard Serves Enterprise Architecture