企業架構研究總結（38）——TOGAF架構能力框架之架構能力建設和架構治理

      爲了確保架構功能在企業中可以被成功地運用，企業須要經過創建適當的組織結構、流程、角色、責任和技能來實現其自身的企業架構能力，而這也正是TOGAF的架構能力框架（Architecture Capability Framework）的關注點所在。架構能力框架爲企業如何創建這樣一種架構能力提供了一系列參考材料，從而爲各企業架構能力的建立提供了幫助，不過TOGAF的架構能力框架在當前還不是一套全面的關於如何運用架構能力的模板，它只是爲企業架構能力建設和運用過程當中的各項關鍵活動提供了一系列導則和指南。

      如圖所示，企業的架構能力必定是運行在某一成熟度水平之上，而且在此背景之下，治理組織（Governance Bodies）將對企業中各架構功能的運做進行監管、評測和指導。圖中間部分所表述的就是架構功能得以被成功運用所需的各類元素，包括了：

• 用於管理架構功能的實現和維護所必需的各類角色、責任以及其所需技能的技能資源池（Skilled Resource Pool）。
• 架構功能的實現和維護最終須要落實到一個個的實施項目（Project/Portfolios）之上，而這些項目在其整個生命週期內都須要處在必定的架構治理（Project/Portfolios Governance）之下，從而使其可以與架構的定義始終保持一致，而爲了在明確和標準化的前提下達成這一目標，這些實施項目與相應的項目治理之間須要經過合同（Contract）來進行溝通和約束。

      技能資源池爲各實施項目以及項目治理設定了相應的參與角色和責任，並對可以勝任這些角色和責任的專業人員其所需的各類技能進行了定義和組織，同時經過培訓的建設來創建或提升專業人員所需的各類技能。對於處於架構能力框架主導地位的治理組織來講，它除了對技能資源池的建設提供指導以外，還須要爲各實施項目的治理設定優先級和關注點，並對項目治理的成效進行評測。因爲企業的內部以及其所處的外部環境是不斷變化的，於是企業自己也須要適應這些內外的變化，而企業平常的業務運營（Business Operation）情況對於架構來講正是這種內外變化的最佳反映，它爲針對各架構實現項目所進行的治理的優先級排序以及關注點的設定提供了參照，同時各架構實現項目也爲企業的業務運營提供了合適的解決方案。

      在以前的各部分中已經提到過，企業架構的各項內容最終要存放到架構資源庫（Architecture Repository）之中，於是在架構能力框架中也將這一元素包括了進來，用於對在各項目中所產生的架構工做產品進行保存和維護，並經過引入企業連續體（Enterprise Continuum）來對這些工做產品進行分類概括。

      綜上所述，架構能力框架爲企業中架構能力的建設提供了指南。這裏所說的架構能力簡單來講就是企業可以成功建設和運用架構的能力，而其實現方式是在企業中創建相應的組織結構和流程，並對所需的角色、責任和技能進行定義和分配，從而爲企業中的各架構的交付和治理提供環境和資源。TOGAF針對上面這些內容從以下方面分別給出了導則和指南：

• 架構能力建設：用於指導企業如何經過架構開發方法的引入來對架構能力進行建設。
• 架構治理（Architecture Governance）：架構能力的目標就是經過對企業中各個架構的合理治理來保障整個企業架構建設和運做的順利，而且此部分對於架構治理以及與此過程相關的組織結構的創建、架構合同（Architecture Contracts）和架構合規性（Architecture Compliance）都進行了較爲詳盡的描述。
• 架構成熟度模型（Architecture Maturity Models）：不論企業清楚與否，其企業架構的建設和運做必定處於某種成熟度水平之上，而爲了讓企業可以瞭解本身企業架構的成熟度水平，並藉此針對薄弱環節進行識別和改善，都須要成熟度模型的引入。
• 架構技能框架（Architecture Skills Framework）：架構能力的實現須要爲參與架構實現項目和架構治理的各類角色、其所需的技能和技能掌握水平進行定義，從而明確企業架構過程當中相關角色的職責和要求，並藉此遴選合適的專業人員。TOGAF的架構技能框架便爲這一目標的實現提供了參考和指南。

 

1. 架構能力的建設

      在前面的敘述中咱們應該已經瞭解到，企業能夠經過應用企業架構開發方法（ADM）來爲其建設各類業務能力，而若是把視界放開一點，咱們會發現企業架構開發方法能夠應用到企業中任何能力的建設方面，這固然也包括架構能力。在架構能力的建設中，對於架構開發方法的成功運用可使企業得到一個可持續並以客戶爲中心的增值型架構實踐，從而幫助企業達成其各項業務目標、最大化投資價值，並可以明確各類得到業務利益和管理風險的機會。不過這一架構實踐的建設並非一個一次性的項目，而應該是一種持續性的實踐過程，從而爲組織中其餘架構的交付提供環境和資源。

      在TOGAF的眼中，任何一種企業能力的建設都須要對以下四種領域進行設計，這固然也包括針對這一可持續性架構實踐建設：

• 業務架構：此領域中的內容突出了架構治理、架構流程、架構組織結構、架構信息需求以及架構產品等方面。
• 數據架構：此領域中的內容定義了組織中架構連續體和架構資源庫的結構。
• 應用架構：此領域中的內容描述了用於支持此可持續架構實踐的功能和/或應用服務。
• 技術架構：此領域中的內容描述了此架構實踐中用於支持各架構應用和企業連續體的基礎設施需求和部署方式。

      TOGAF對於這一可持續性架構實踐的建設有着更加詳盡的指南，在本節的後續部分中咱們將以架構開發方法各階段爲基礎來對企業架構能力的建設進行進一步探討。

1.1 架構願景階段

      此階段的目的在於定義或審查這一架構實踐的願景、干係人和原則。TOGAF對於此過程的具體步驟作了以下建議：

• 創建項目：此步驟應該關注於定義與此架構實踐有關的各個干係人。這些干係人包括了參與到架構實踐活動中的角色和組織單元，以及那些會從架構實踐所產生的交付物中獲益的干係人。
• 明確干係人和其關注點、業務需求和架構願景：此步驟將會針對此架構實踐從業務信息系統和技術的角度產生第一個關於基線和目標環境的高度歸納定義。
• 明確業務差距和業務驅動力：對業務目標和驅動力的瞭解對於促成此架構實踐和業務之間的協調是很是重要的。
• 定義範圍：針對此架構實踐範圍的定義將會產生一份高度歸納的項目規劃，用以歸納在接下來的一個時間區間內須要被解決的問題。
• 定義約束：此步驟的關注點在於企業範圍內會對全部架構項目產生影響的各類約束。
• 審查架構原則（包括業務原則）：此步驟的意圖在於定義用於治理和指導這一架構實踐運行的各類原則。與一般的架構原則用來治理架構交付物所不一樣，架構實踐原則將被用來明確架構實踐的組織、內容、工具和相關流程。
• 開發架構工做說明書和安全認證。
• 另一個須要在此階段被考慮進來的步驟是進行架構成熟度評估（請參閱2.4.4.6架構成熟度模型部分的描述）。

1.2 業務架構階段

      此階段的目標在於創建或提煉架構實踐的業務架構，而這須要關注以下幾個關鍵領域：

• 架構本體論（Architecture Ontology）：定義了各類架構的術語和定義，用於在組織中創建起關於這些內容的共識。
• 架構流程（Architecture Process）：以架構開發方法爲基礎並按照組織的須要和架構實踐的願景來對架構開發方法所進行的定製，而且所需的架構治理流程也應該被包含到整個架構流程之中。
• 架構視角和視圖（Architecture Viewpoints and Views）：列舉出全部架構實踐所涉及到的視角和視圖，而針對這些內容的定義工做應由此前被識別出來的架構實踐干係人來進行指導。
• 架構框架（Architecture Framework）：描述了將會由架構實踐所產生的各類架構交付物以及他們之間的交互、依賴關係，此外還包括了種種用於管理這些交付物的設計的規則和指南。那些在以前被定義的架構視角和視圖也應該被用來指導架構框架的定義
• 架構問責矩陣（Architecture Accountability Matrix）：定義了架構實踐所涉及到的各類角色，以及爲這些角色所分配的關於架構交付物和流程的責任。
• 架構性能指標（Architecture Performance Metrics）：明確和描述了用於與架構實踐願景和目標進行比對和監督的各項架構實踐性能指標。
• 架構治理框架（Architecture Governance Framework）：是一個與以前定義的架構流程和架構責任矩陣相關的特定視圖。

1.3 信息系統架構階段（數據）

      架構實踐的數據架構對組織的企業連續體和架構資源庫進行了描述和治理。數據架構的定義應該基於組織所選擇的架構框架，而且有時也被引用爲架構實踐的元模型。

1.4 信息系統架構階段（應用）

      架構實踐的應用架構定義了用於產生、維護、發佈、分發以及治理架構交付物的各類功能，而這其中一個關鍵點在於用來建模的各類建模工具組。

1.5 技術架構階段

      架構實踐的技術架構應該對用於支持架構實踐的技術基礎設施進行定義。

1.6 機會與解決方案階段

      在這樣一個與架構實踐建設規劃相關的階段中，組織須要審慎考慮的重要一點是所需的組織變動，以及達成這一變動的方法。

1.7 遷移規劃階段

      此階段的關注點不只要放到信息系統架構組件之上，還須要將業務架構包括在內，而對於架構流程和框架的採用將會對組織中架構實踐的總體建設產生主要的影響。

1.8 實施治理階段

      針對架構實踐的業務架構的實現應該是此階段的關注重點。將組織中的實踐活動改變爲一種更加結構化和有紀律的方法很是具備挑戰性，於是須要經過適當的組織變動技術來達成。

1.9 架構變動管理階段

      此階段須要對架構實踐中各類架構的變動進行管理，而這些變動一般是在各個架構項目的執行過程當中被觸發的。一個典型的變動每每會成爲對於新架構交付物的需求，並會對架構實踐中的全部架構領域產生影響。

1.10 需求管理

      瞭解和管理架構實踐的需求是很是關鍵的，而且這些需求須要被清晰地描述出來，並與架構實踐願景相一致。

2. 架構治理

      簡單來說，企業架構能力是指企業對於其內各類架構的建設能力，而這裏所說的建設能力不只指的是企業中各架構的實現，並且還須要保證架構的實現是處在一個透明且受控的環境之中，從而使架構的建設得以正確進行。架構能力中有關這種保障架構建設和交付的內容就是架構治理（Architecture Governance），而這也是架構能力中最爲核心的部分。

      不管何種企業總有其須要進行管理的地方，於是即使是沒有涉及到任何架構的企業也總會有着針對其餘方面的治理體系，這也註定了架構治理一定不會獨立並隔絕地存在着，而應該存在於一個層次化的治理結構之中，這對於大型企業來說尤爲重要。按照所處領域的不一樣，TOGAF將這一層次化的治理結構劃分爲以下四種，其中的每一種都具備其各自的規則和流程，而且能夠存在於多個地理區域層次之上（包括全球、地區和本地這三種地理區域種類）：

• 公司治理（Corporate governance）
• 技術治理（Technology governance）
• IT治理（IT governance）
• 架構治理（Architecture governance）

      以上這幾種治理體系之間並非絕對隔離的，不一樣的治理體系所包含的活動和行爲多少都會有所交疊，但因爲其所面對的領域各不相同，其管理的範疇以及所具有的規則、流程和活動具備很大的差別性。因爲公司治理、技術治理和IT治理的內容範疇超過了一個企業架構框架理論內容範圍，TOGAF中相關部分的描述重點仍是放在了架構治理這一方面，不過它對治理的共性以及技術治理和IT治理仍是作出了簡要的描述。

2.1 治理的共性

      在進一步介紹架構治理以前，咱們須要對「治理」這一律念有一個清晰的認識。這裏所說的治理並不像其字面上那樣，僅僅表明顯式的管控和對於規則的嚴格遵照，而是更加傾向於爲有效且公平的使用各類資源提供指南，從而確保組織的戰略目標的可持續發展。根據所處領域不一樣，在前面提到過治理能夠被細分爲若干治理層次，但不管其種類爲什麼，「治理」的最終目標在於確保業務得以順利進行，而且在這些種類不一樣的治理都遵循着相同的原則。經合組織（OECD：Organization for Economic Co-operation and Development）曾經針對這些基礎共通原則作出了以下歸納：

• 關注於各類干係人的權力、角色以及針對他們的公平處置。
• 信息披露、透明度和委員會的責任。
• 確保組織中良好的戰略指南。
• 確保委員會進行有效管理監督。
• 確保委員會對於公司與相關干係人之間的問責。
• 委員會的責任包括：
• 審查和指導戰略。
• 設置並監督管理績效目標的進展。

      除了這些共同原則以外，TOGAF還歸納出了治理的各類共同特性，用以突顯治理做爲一個被組織在其內以及與其餘有關團體之間所採用的方法的價值和必要性：

• 紀律性（Discipline）：全部牽涉的團體須要承諾遵循由組織創建的各類程序、流程和權利結構。
• 透明性（Transparency）：被受權的組織和各供應商應該能夠對全部實施行動和他們的決策支持進行檢查。
• 獨立性（Independence）：全部流程、決策制定以及所採用機制的創建應最小化或避免潛在的利益衝突。
• 問責性（Accountability）：全部在組織中被肯定的團隊須要被受權，而且須要爲他們的行爲負責。
• 責任性（Responsibility）：每一個簽定契約的團體須要對組織以及他們的干係人採起負責任的行爲。
• 公平性（Fairness）：全部的決策、使用的流程以及針對他們的實現不該對任何團體產生不公平的利益。

2.2 不一樣治理領域的特性

      在前面提到過的四種領域中的治理除了具有上一節所述的共同原則和特性以外還分別具有各自的特色。因爲公司治理的內容範疇超過了一個企業架構框架所應覆蓋的範圍，因此在這裏並不會進行專門的描述，而接下來咱們將針對其他的三種治理體系，亦即技術治理、IT治理和架構治理，分別進行描述。

2.2.1 技術治理

      技術治理控制了一個組織如何將技術應用於針對其產品和服務的研究、開發和生產之中。技術治理與IT治理關係很是緊密，並且技術治理每每會涵蓋IT治理中的各類活動，但技術治理的內容範疇則更爲廣闊。在現代企業中，愈來愈多的組織將注意力的重心逐漸放到無形資產之上，而不是僅僅關注於有形資產管理。因爲大部分無形資產是信息化或數據資產，這正說明現代企業的業務與IT之間的關係也愈來愈緊密，於是針對IT的治理（亦即IT治理）也成爲技術治理的一個重要組成部分。這一針對無形資產逐漸重視的趨勢同時也突顯了企業的業務不只僅依賴於信息自己，還依賴於用於產生、交付和使用這些信息的各類流程、系統和結構。此外，隨着無形資產價值比重在各個行業中的不斷攀升，風險管理也須要做爲一個重點而加以考慮，從而使得新的挑戰、威脅和機會可以得以被理解和緩和。

     須要注意的是，不只僅是組織的運營和盈利愈來愈依賴於IT，組織的聲譽、品牌以及最終他們的價值也都依賴於這些信息和支持技術。

2.2.2 IT治理

      IT治理爲IT資源和信息與企業目標和戰略之間的聯繫提供了框架和結構，而且IT治理爲規劃、採購、實現和監督IT績效指定了各類最佳實踐，從而確保企業的IT資產對其業務目標的支持。

2.2.3 架構治理

      架構治理是爲了在全企業範圍內對企業架構以及其餘各類架構進行管理和控制而須要藉助的各類實踐和方向，它具備以下幾個方面的特性：

• 實現一個系統來控制全部架構組件和活動的建立，並對它們進行監督，從而確保在組織內有效地引入、實現各類架構，並保障這些架構的順利演進。
• 實現一個系統用於確保各類架構對於企業內外的標準和法律法規的遵照。
• 創建各類流程，用於在已達成共識的各因素的約束之下，對上述流程的有效管理進行支持
• 開發各類實踐，用於在組織內外確保對於一個通過清晰定義的干係人團體的問責性。

      在前面有關企業架構開發方法的介紹中，咱們已經在「實施治理」階段見過了「治理」一詞。這個階段所關注的是經過各個變動項目來對架構進行實現，於是此階段的治理僅僅是關於架構實現這一方面，不過對於架構治理來講，這一實施治理只是一個很是重要的方面，架構治理的範疇要更爲廣闊，它涵蓋了針對企業架構以及其餘各類架構在其開發和演進過程當中全部方面的管理和控制。做爲一個企業架構框架，TOGAF爲支持架構治理的實現提供了一個架構治理框架（Architecture Goverance Framework），用於幫助企業明確各類有效的治理流程，從而使得與架構治理相關聯的各類業務職責得以被鑑別出來，並可以對其進行有效地管理和溝通。

2.3 架構治理框架

      架構治理框架包括兩個部分的內容，其一是用來歸納架構治理各流程以及相關內容的概念結構，另一個是TOGAF對於架構治理所建議的組織結構。在接下來的內容中咱們將分別對這兩個方面進行探討。

2.3.1 概念結構

      架構治理框架的概念結構包含了架構治理中的種種概念，這其中最爲重要的是對一個有效的架構治理所應具備的各類流程以及與它們相關的內容所進行的定義。這一架構治理的概念結構採用了一種內容無關的方式，將流程、流程所涉及的內容以及背景元素進行了分離，從而使得新的治理材料的引入不會過分地影響到各個治理流程，同時也保證了這一治理框架的靈活性。

      上圖展現了架構治理框架的概念結構，其中涵蓋了這一框架中的各類概念，而這其中最關鍵的是與治理流程有關的各類概念。治理流程被用來識別、管理、審計和傳播全部與架構管理、合同和實現相關的信息，從而確保對全部架構製品、合同、原則以及運營級別協議（operational-level agreements）進行持續地監督，而且所作的各項決策也具備了清晰的可審計性。這些治理流程相關的概念總結以下：

• 策略管理與內容引入（Policy Management and Take-On）：爲了註冊、驗證、批准、管理和發佈新的或通過更新的內容，全部針對架構修訂、合同和支持性信息的引入都須要處在一個正規流程的治理之下。這些流程將確保與現存治理內容的有序整合，從而使得全部相關的團體、文檔、合同和支持信息得以被管理和審計。
• 合規（Compliance）：針對服務水平協議（SLAs：Service Level Agreements）、運營水平協議（OLAs：Operational Level Agreements）、現行各項標準和法規需求的合規性評估須要在一個持續的基礎上進行，從而確保針對穩定性、一致性和性能的監督。這些評估的進行須要以在治理框架中所定義的各項標準爲準繩。
• 豁免（Dispensation）：當主題域（設計、運營、服務水平或技術）的內容在合規性評估中被判爲不合規時，該部份內容將可能會被否認，而此時將會存在以下幾種處理方式：
• 對這些不合規內容進行調整，從而使其知足合規性需求。
• 申請一份豁免。當合規評估未能經過時，豁免就成爲了一條用來達成臨時性一致的備選路線。豁免只會存在於一段時間區間內，並在其整個生命週期內被強制設置明確的服務和運行條件。豁免並不會永久有效，它只是被用來做爲一種在確保服務水平和運營水平得以知足的同時附加必定水平的靈活性的機制。豁免的時限性特徵確保了它們是合規性評估循環的一個主要觸發因素。
• 監督和彙報（Monitoring and Reporting）：性能管理被用來確保運營和服務元素的管理是基於一系列通過協定的標準之上，這包括了監督服務水平和運營水平協議、對於調整的反饋以及針對這些結果的彙報。
• 業務控制（Business Control）：業務控制與各個流程相關，這些流程的引起被用來確保與組織的業務策略相符合。
• 環境管理（Environment Management）：明確了各類服務，這些服務確保了以資源存儲庫爲基礎的環境對治理框架進行支持是有效且高效。這包括了針對全部用戶的物理和邏輯資源存儲庫的管理、訪問、溝通、培訓和評審。爲了造成一個受管的服務和流程環境，治理環境中將會定義一些管理流程，這些流程包括了用戶管理、內部服務水平協議（爲了控制這些管理流程自己而定義）以及針對管理信息的彙報。

 

2.3.2 組織結構

      在架構治理框架的概念結構中，TOGAF以一種內容無關的方式明確了一個有效的治理所涉及的各類概念，並藉此歸納了各類架構治理流程以及與這些流程相關聯的各類內容，但若是要確保一個架構治理的順利進行，還須要在企業中設立專門負責治理舉措施行的組織結構。在實踐中憑空建立這些用於架構治理的組織結構實際上是不現實的，企業應該組合現有的各類IT治理流程、組織結構和能力來對其進行建立。一般來說，企業中的治理組織結構可被分爲以下幾個層次：

• 全局治理委員會
• 本地治理委員會
• 設計部門
• 工做組

      TOGAF提出了以下圖所示的治理組織結構，各個企業能夠按照各自的需求以此圖所示的組織結構爲基礎而進行改造：

      如圖所示，架構治理框架的組織結構能夠被分爲三個重點區域，他們分別是：開發（Develop）、實現（Implement）和部署（Deploy），它們中的每個都表明了在架構生命週期的每個階段中各個相關小組所應盡的責任。尤爲是對於開發區域來說，這裏的開發責任、流程和組織結構都與架構開發方法過程有着緊密的關聯，而對於實現區域來說，其所包含的實施責任、流程和組織結構與架構開發方法的實施治理階段也是密不可分的：

• 在開發區域中，架構委員會（Architecture Board）對主架構師進行任命，而且經過二者的合做來對企業架構的設計和落實進行指導，並最終將企業架構細化成爲各個面向具體問題的領域架構。
• 在實現區域中，受架構委員會受權和委派的項目管理辦公室（Program Management Office）對用於實現各個領域架構的實施項目進行管控，從而保障其順利施行。
• 在部署區域中，因爲各個架構實現項目的實現和部署改變了企業當前的運營狀態，於是受管理辦公室委派的服務管理組織（Service Management Organisation）須要對企業的各運營系統進行監督，從而發現新的問題和需求，並藉此啓動新的一輪架構開發循環。

      除了以上這三個核心區域以外，咱們還應注意到企業連續體的再次出現。企業連續體之因此會在這裏出現是由於它是架構治理的一個不可或缺的部分，由於它不只承載了與架構相關的各類內容，也同時存儲了與架構治理過程相關的種種材料。

 

2.4 架構治理實踐導則

      在實踐中，爲了實現一個成功的架構治理方法，並對架構合同進行有效的管理，企業須要考慮以下幾個關鍵因素：

• 與架構策略、程序、角色、技能、組織結構和支持服務的提交、採用、重用、回報和廢止相關的各類最佳實踐。
• 用於支持架構治理的流程以及達成彙報需求的組織結構及其責任。
• 對各類工具和流程進行整合，從而便於在程序上和文化上執行各個流程。
• 與架構治理流程、豁免、合規性審查、SLAs和OLAs的控制相關的各類指標。
• 組織內外對於全部架構治理相關信息、服務和流程在有效性、效率、保密性、完整性、可得性、合規性和可靠性這些方面的需求。

      除了上面幾項對於架構治理成功因素的描述，TOGAF還指出了一個在企業中得到接受和成功的架構所應具有的三個主要的架構治理戰略元素：

• 須要在最高管理層的支持下創建一個跨組織的架構委員會（Architecture Board，見2.4.4.3架構委員會）來對IT治理策略的實現提供監督。
• 須要創建一套全面的架構原則，從而對組織如何經過使用信息技術來完成自身的任務而進行指導和支持。
• 須要採用一種架構合規性策略（見2.4.4.4架構合規性），從而經過具體的措施來保證架構的合規性，這包括了項目影響評估、正式的架構合規性審查流程，同時也可能包括在產品採購過程當中架構團體所進行參與。