企業架構研究總結（36）——TOGAF企業連續體和工具之企業連續體構成及架構劃分

       又回頭看了以前文章的評論，本人也一樣感慨這些文章的確像政治課本般的虛無縹緲，因此對費力看完卻以爲無從下手的看官致以誠摯的歉意和理解，由於這個問題也一樣困擾着筆者本人，而我能作的也只能是紙上談兵。以前也接觸過國家某大型公司的企業架構建設項目，採用的也是TOGAF標準，可是要將其做爲例子羅列出來，實在是件偉大的工程，並且本人也真沒接觸這麼多項目內容，沒法列舉示例還請見諒。就筆者本人的理解，是否符合TOGAF的斷定標準主要是企業架構的建設過程是否遵循企業架構開發方法（ADM），至於後面的內容框架（架構製品、交付物和構建塊等）並非決定是否遵循TOGAF的絕對斷定標準，其內容也是綜合了衆多組織經驗的抽象之談，因此過於理論化無可避免。本系列的本意仍是還原標準文本，盡力進行普及，雖翻譯、理解能力有限，亦但願能糾當前衆多中文資料中不負責任的謬誤（見開篇的幾篇文章就可瞭解我寫本系列的用意）。至於如何掌握這門技術，須要各看官有機遇參與相關項目，於實踐中融會貫通，到時這些枯燥的理論應該會助各位一臂之力。無論怎麼說，企業架構真的很複雜枯燥，甚至是否應該建設或者其建設到底有多大用處目前尚未誰能有個確定且量化的回答，筆者讀了幾年資料並參與了一個相關項目，也能是紙上談兵，不過做爲一個將來方向（筆者自認），能對其有點了解也是好的，畢竟不是具體的軟件技術，能夠在短期學以至用，而且也有大把機會能夠去實踐鍛鍊。原本打算終止寫做TOGAF方面的內容，提前開始寫企業架構建模和分析方面的內容，由於這個方面內容例子多了不少，看起來也輕鬆不少，不過終不想半途而廢，還請諸看官耐心一點，並但願有經驗的看客對筆者給予指正。

      從字面上看企業架構好像是一個獨立且一應俱全的架構，可是這種看似能解決全部問題的單一架構卻每每只能存在於理想之中。在實踐中，一個企業架構應該是由若干具備不一樣目標的架構所組成的。這些架構具備着各不相同的背景，並由於不一樣的目標而被建立出來，而且經過這些架構之間的關聯關係而造成了一個能夠解決各干係人需求的有機總體，亦即企業架構。既然企業架構是由這麼多個子架構所組成，那麼一個關係混亂且相互冗餘的架構構成狀況是不能被稱之爲良好的企業架構的，於是如何界定這些架構的範圍對於企業架構的成功與否有着重要意義。在這個方面TOGAF提出了企業連續體（Enterprise Continuum）的概念，用以對企業內外存在的各類架構製品進行分類，併爲企業內以及企業與外部的客戶和廠商進行架構方面的溝通提供了基點。除此此外，TOGAF還提出了一系列架構劃分的原則和方法，從而使得針對企業架構的建立和維護工做的複雜度得以被有效地控制（由於企業架構是爲了達成不一樣干係人的需求而制定的，且干係人及其需求之間的差別性也很是大，因此企業架構所面對的問題域必將是很是複雜的）。在本章的後半部分，咱們還將對用於儲藏和管理各個架構的架構資源庫的組織方式進行闡述，並對用於生成和維護企業架構的自動化工具的選擇標準進行了描述。

1 . 企業連續體的構成

      如前所述，企業架構並非一個單一的架構，而是由多個具備各自背景且面向不一樣目標的子架構所組成的，這些子架構或存在於企業之中亦或來源於企業以外，它們包括了架構描述、模型、構建塊、模式、視角以及其餘的架構製品。舉例來說，對於存在於企業內部的架構製品來講，包括了在以前的架構工做中所產出的各類交付物，而對於外部的製品來講，則包括了各行業中的各類參考模型和架構模式等，例如在TOGAF中定義的具備高度普遍性的技術參考模型（TRM：Technical Reference Model）、IT領域中某一具體方面的架構（例如Web服務架構）、與特定信息處理類型相關的製品（例如，電子商務、供應鏈管理等），以及與特定行業相關的製品（例如電信業的TMF、零售業的ARTS以及石化行業的Energistics）。面對如此紛繁複雜的架構以及更爲繁複的架構間關係，企業必須經過一種合理的分類方法來對他們進行組織和界定，從而使他們成爲一個協調的有機總體，而這正是企業連續體的用武之地。簡單的講，企業連續體能夠看做是用來對全部架構資產進行存儲的資源庫（架構資源庫，其詳細介紹請參閱後面的部分）的一個視圖，其目標便是對企業內外的各類架構和解決方案製品進行分類。

      雖然企業連續體是一個有關架構分類的方法，可是咱們不能把它簡單地看做是一個靜態的分類法。不管是從字面上，仍是從企業架構自己的動態特性來看，企業連續體也是一個針對各個架構製品的動態分類方法，它展現了架構製品是如何從通用的「基礎架構」分類層次演進到「組織特定架構」這一分類層次。雖然這看起來像是一個由抽象到具體的架構演進過程，可是咱們不能過度強調其動態性而忽略了其分類法的本質，一個架構並非必定要經歷這一演進過程，其自己的特性仍是決定其所處分類層次的決定因素。除此以外，咱們還要注意的是這個分類法的動態特性不是單向的，一個架構能夠由較爲通用的分類層次出發經由整合和定製來達到符合各組織特色且更爲具體的特化分類層次，同時一個通過長時間考驗並在較大範圍內獲得認同的架構則能夠被提高到一個更爲通用的分類層次之中，而這也正是TOGAF因此一直強調的「重用」精神的體現。此外，正是因爲這個分類法對架構和解決方案製品所進行的分類和規整，企業連續體爲在企業內外進行關於架構的理解和溝通提供了基準點，使得企業在內部以及與外部客戶和合做團隊進行架構交流時，可以明確目標架構所處的分類層次和相應的特性，從而避免南轅北轍式地探討。因而可知，企業連續體同時也是一個針對架構進行理解和溝通的有力工具。

      做爲TOGAF中的一個重要內容，與其餘關鍵部分同樣，企業連續體與TOGAF的核心內容，亦即企業架構開發方法，有着緊密關係。企業架構開發方法所描述的是一個開發組織特定的架構，以及與此架構相關的解決方案的過程，而且這一過程的實現一般是要藉助於針對通用架構和解決方案的採用和定製，而這樣一個由「通用」到「特有」的過程與企業連續體的精神是一致的。此外，企業架構開發方法不只提倡針對可重用構建塊的利用，它同時還指導着新的可重用資源的發掘，而在企業連續體中那些被證實是通用的架構也是能夠被劃入到通用性更高的層次之中。因而可知，企業架構開發方法爲架構的開發和維護提供了手段，而企業連續體則爲其結果提供了組織機制。除此以外，企業連續體各分類層次中的資源對架構開發方法的各個階段具備重要的幫助做用，例如在技術架構的開發中，TOGAF的技術參考模型即具備着指導意義，而在業務架構的開發中，一個關於電子商務的參考模型也可能具備一樣的幫助做用，這同時也與企業架構的資源重用精神是相符合的。

      企業連續體是由三個界限清晰的模塊所構成的，即「企業連續體（Enterprise Continuum，此部分名稱雖與其總體名稱相同，但在這裏指的是一個獨立的子部件）」、「架構連續體（Architecture Continuum）」和「解決方案連續體（Solutions Continuum）」，他們之間的關係，以及企業連續體與企業資源庫之間的關係展現以下：

      如圖所示，外部存在的各類架構驅動因素被企業連續體子模塊所歸整，並造成各架構的開發背景和需求。接下來，這些背景元素及需求推進了相應架構的造成，而在此過程當中，架構連續體子模塊可被用來爲企業資源庫所包含的各個相關架構資產提供組織結構和分類方法。當架構被定義並組織好以後，位於架構連續體中的各個架構被用來指導和支持相關解決方案的建立，而在此過程當中，解決方案連續體子模塊被用來對存儲於企業資源庫中的各解決方案資源進行分類和組織。最後，各解決方案被部署到企業的運營環境之中，併成爲新的企業架構背景的組成部分。因而可知，企業連續體的三個子模塊被完美地契合入整個企業架構生命週期中（自外部驅動因素的識別開始到最終解決方案的部署），並從架構和解決方案兩個主要層面對企業資源庫中的資源進行歸類和組織。企業連續體的三個子模塊的定義以下，而且在後面的部分中咱們將對他們的內容進行更加詳盡地闡述：

• 企業連續體（Enterprise Continuum）：此種類型的連續體用來對與整個企業架構背景相關的資產進行分類和概括。這些背景性質的資產通常並不直接用在架構開發過程之中，但他們對於架構卻具備着很是大的影響，例如政策、標準、戰略舉措、組織架構以及企業級別的能力等。
• 架構連續體（Architecture Continuum）：架構連續體對於認識和定義通用規則、表現方式以及架構間的關係（這些關係包括可追溯性和派生關係，例如一個組織特定架構與其所基於的某個行業或通用標準之間的關係）提供了一種一致性的方法，而且它爲各類可重用的架構構建塊（ABBs）在其整個演進生命週期內提供了組織結構，同時架構連續體在架構的通用型發掘和冗餘消除方面也是一個很是有用的工具。
• 解決方案連續體（Solutions Continuum）：此種連續體爲認識和描述在架構連續體中定義的各類架構資產的實現提供了一種一致性方法，而且它爲各類解決方案構建塊（SBBs）提供了組織結構。解決方案能夠說是客戶和業務夥伴之間協議的產物，它實現了定義在架構領域中的各類規則和關係，同時解決方案連續體在處理產品、系統和系統服務之間的共性和差別方面也是一個有力的工具。

 

1.1 企業連續體子模塊

      如前所述，企業連續體子模塊被用來對背景性資產進行歸整。這些資產可能來源於企業範圍以內，也可能位於企業的外部環境之中，例如外界的產品、研究、市場因素、商業因素、業務策略以及法律法規等。雖然TOGAF是一個用於指導企業架構開發的框架，可是在企業連續體中所包含的各類資產卻每每超出TOGAF的考慮範疇，而且一個架構的造成又常常被架構實踐以外的各類因素所決定，因此如何準確反映外部背景因素是很是重要的。儘管具體的外部背景因素在不一樣的架構之間會有很大的差別性，可是一般能夠分爲以下幾類：

• 外部影響因素，例如法規的變化、技術的進步以及競爭者的活動等。
• 業務策略和背景，包括合併、採購以及其餘業務轉型需求。
• 反映當前已部署的架構和解決方案所構成的業務運營狀況。

1.2 架構連續體子模塊

      架構連續體描述了各個架構是如何從基礎架構（Foundation Architecture）開始，歷經通用系統架構（Common Systems Architectures）和行業架構（Industry Architectures），並最終演進爲企業自身的組織特定架構（Organization-Specific Architectures）的過程。除了以上這四種分類層次以外，他們之間的雙向關係連線也有着很是重要的含義。如圖所示，企業和業務的需求以一種詳細度漸進的方式從左至右逐級獲得知足，而對於架構組建和構建塊的重用，企業則須要在架構連續體中自右向左地尋找。若是最終沒有尋找到所指望的架構元素，那麼對於此缺失的架構元素的需求則以自右向左的方向尋找合適的分類層次。

 

1.2.1 基礎架構（Foundation Architecture）

      基礎架構是一個包含了一系列構建塊和相關標準的架構，這些元素被用來支持通用系統架構以及完備的企業運營環境。The Open Group提供了一個技術參考模型（TRM），它自己就是一個基礎架構的良好體現，它描述了一個基本架構，並在此基礎之上使得更爲具體的架構得以被建立。

1.2.2 通用系統架構（Common Systems Architectures）

      通用系統架構對於從基礎架構中選擇和整合特定的服務提供了指導，從而爲建立跨越多個相關領域的通用解決方案創建了架構。從系統的總體功能角度來看，通用系統架構並不完備，它所包含的架構應該是面對某一個特定領域內的問題，於是實現了其中架構的解決方案爲企業功能完備的運營狀態的創建提供了可重用的構建塊。TOGAF中定義了一個名爲集成信息基礎設施參考模型（III-RM：Integrated Information Infrastructure Reference Model）做爲關注於與無邊界信息流（Boundaryless Information Flow）相關的需求、構建塊和標準的通用系統架構。除此以外，通用系統架構的特定還包括：

• 反映了針對某個通用問題域的需求。
• 針對某個特定問題域定義構建塊。
• 爲構建塊的實現定義業務、數據、應用或技術標準。
• 提供各類構建塊從而方便重用和下降成本。

1.2.3 行業架構（Industry Architectures）

      行業架構對從通用系統組件到特定的行業組件的集成提供了指導，併爲在特定行業中爲解決目標用戶問題而創建解決方案提供了指南。行業架構的其餘特性還包括：

• 反映了針對具體行業的需求和標準。
• 爲具體行業定義構建塊。
• 包含了行業特定的邏輯數據和流程模型。
• 包含了行業特定的應用、流程模型以及業務規則。
• 爲系統集合的測試提供指南。
• 提高在整個行業中的互操做水平。

1.2.4 組織特定架構（Organization-Specific Architectures）

      組織特定架構描述並指導了在一個具體企業或相互聯繫的企業網中針對解決方案組件的最終部署。組織特定架構的其餘特性還包括：

• 在全部的四個架構領域中，爲對業務運營進行溝通和管理提供方法。
• 反映了對特定企業的具體需求。
• 爲一個特定企業定義具體構建塊。
• 包含了組織特定的業務模型、數據、應用和技術。
• 爲促進適當的解決方案的實現提供了方法，從而知足業務須要。
• 爲評測和選擇適當的產品、解決方案和服務提供了判別標準。
• 提供一條演進路線來支持業務需求的發展或新的業務需求

1.3 解決方案連續體子模塊

      解決方案連續體表明瞭針對各架構連續體層次中架構的詳盡描述和構成。解決方案連續體的每一個分類層次充滿了針對相應架構的解決方案構建塊，從而表達了在每一個層次用於知足企業業務需求的解決方案。一個基於解決方案連續體並被相關構建塊所填充的資源庫能夠被看做爲一個解決方案倉庫，它爲管理和實施針對企業的改善提供了巨大的價值。與架構連續體相相似，解決方案連續體中除了如圖的四種分類層次外，這些分類層次之間的雙向關係也一樣值得注意：

• 自左向右，解決方案連續體關注於解決方案價值的提供，亦即基礎解決方案爲建立通用系統解決方案提供價值，系統解決方案被用來爲行業解決方案提供價值，而行業解決方案則爲組織特定解決方案的創建提供價值。
• 自右向左，解決方案連續體關注於知足企業的需求。

 

1.3.1 基礎解決方案（Foundation Solutions）

      基礎解決方案包含了高度通用的概念、工具、產品、服務和解決方案組件，這些內容同時也成爲了企業能力的根本提供者。舉例來說，基礎解決方案包括了編程語言、運營系統、基本數據結構、組織結構的通用方法、組織IT運做的基本結構等。

1.3.2 通用系統解決方案（Common Systems Solutions）

      通用系統解決方案是一個針對通用系統架構的實現，它包含了一系列的產品和服務，並表明了在通用系統解決方案所支持的行片斷中的一個或多個解決方案的最高級別共性。通用系統解決方案所針對的並非某個特定客戶或行業，而是表明了關於通用需求和能力的集合，併爲具體業務和信息需求的運行環境提供了組織方式。舉例來說，通用系統解決方案能夠包括一個企業管理系統產品或一個安全系統產品。

1.3.3 行業解決方案（Industry Solutions）

      行業解決方案是針對行業架構的一個實現，它提供了針對一個特定行業的通用組件和服務的可重用封包。處在基礎解決方案中的組件被通用系統解決方案和/或基礎解決方案所提供出來，並在行業解決方案中被擴展爲行業特定的組件。須要注意的是，在有些狀況下，行業解決方案不只包含針對行業架構的實現，還包括了其餘解決方案元素，例如特定產品、服務和與行業相適宜的系統解決方案。

1.3.4 組織特定解決方案（Organization-Specific Solutions）

      組織特定解決方案是針對提供了所需業務功能的組織特定架構的一個實現。因爲在這裏的解決方案是爲具體的業務運營而設計的，於是一般它們包含了最大量的獨特內容，從而知足各具體組織中形色各異的人員和流程的須要。爲了支持各個具體的服務水平協議（SLAs：Service Level Agreements），從而確保在指望的服務水平對運行系統進行支持，組織特定解決方案須要經過一種結構化的方式進行組織。例如，一個第三方應用託管提供商就可能在不一樣水平上對運行系統提供支持。另一個定義在企業特定解決方案中的重要元素是關鍵運行參數和質量指標，這些參數和指標可被用來對企業的運行環境進行管理和監督。

2. 架構劃分

      企業連續體對企業中的各個架構和解決方案進行了清晰地概括和組織，但在實踐過程當中，基於以下的緣由咱們須要對單個架構和解決方案（或一組相互聯繫的架構或解決方案）進行進一步的劃分，由於：

• 用單一架構來解決全部問題每每比較複雜。
• 不一樣的架構之間會產生衝突。例如，因爲企業的狀態會隨時間的推移而發生變化，於是此時此刻還合做良好的兩個架構可能會在將來某個時間點發生矛盾。
• 不一樣的人員每每在相同的時間點對架構的不一樣組成元素進行開發和維護，於是針對架構的劃分可使各我的員明確其所負責的架構部分。
• 一個有效的架構重用方式要求模塊化的架構分段形式，這些架構片斷能夠被合併爲更大的架構和解決方案。

      在實踐中，因爲架構的多樣性，企業更傾向於選擇可以反映其經營模式的架構劃分方法（回想一下咱們在前面部分提到過的聯邦企業架構中片斷架構的概念就是一個架構劃分的具體實例），於是創建一個通用的架構劃分模型是很是困難的，但TOGAF仍是爲架構或解決方案的劃分提供了一套分類標準：

• 首先明確架構和解決方案的特性。
• 以某一個特性爲基準將其拓展爲一個維度（就像畫一條以此特性爲標尺的座標軸同樣），並將架構在此維度之中進行排列。例如，若是咱們把「時間」這個特性做爲一個判別維度，那麼某一架構按此維度的排列就造成了此架構的一張路線圖。由此咱們也能夠看出，架構劃分是以架構或解決方案的特性爲基礎的，並不只是有關構成方面的劃分。
• 根據開發或維護目標的不一樣，將若干個特性結合起來對架構進行多維度劃分。

2.1 解決方案的分類特性

      TOGAF列出了以下幾個用於對解決方案進行分類的特性：

• 主題：用於描述一個解決方案的最顯而易見的方法就是檢視其內容、結構和功能。此外，也可經過檢視一個解決方案的邊界和與此邊界發生交互的全部外部因素來進行描述，例如前置條件、後置條件、使用者、提供者、擁有權、運行以及影響因素等。
• 時間：全部的解決方案都會存在必定的時間，而其主題和所處的環境也可能會隨着時間的推移而發生變化，因此明確解決方案的時間屬性是一個關鍵的考慮要素。此外，當描述將來的解決方案時，這一時間屬性表明了一個目標實現日期，並被用來對和組織相關變動活動進行規劃。
• 成熟度/波動性：用於描述解決方案的主題和其所處環境隨着時間推移而發生變化的幅度。這一屬性之因此關鍵是由於針對不成熟或不穩定的解決方案的管理與針對穩定或成熟解決方案的一般是很是不同的，例如易於變化的環境更適合靈活的解決方案的採用。

2.2 架構的分類特性

      從前面的內容中咱們能夠了解到架構實際上就是解決方案的一種表現方式，它定義瞭解決方案的需求，於是在前一部分中對解決方案所定義的特性一樣也適用於架構。TOGAF列出了以下幾個用於對架構進行分類的特性：

• 主題：架構針對具體的解決方案進行了描述，它自己也繼承了其所描述的解決方案的各個客觀特性，例如主題、時間和波動性等。
• 視角：架構的領域和所產生的各具體制品在干係人需求的基礎上能夠展現解決方案的某一個側面，而這就是就是架構的視角。視角能夠是通常性的，也能夠針對某一特定的架構領域（業務、數據、應用和技術），亦或是有關其餘方面的考慮（例如，安全、運行管理、繼承以及施工等）。
• 詳細度：一般來說，詳細的架構在針對解決方案的支持和指導中會更加有效，而較爲簡略的架構則在有關解決方案的總體性溝通中更加適合。
• 抽象水平：用於描述架構對其解決方案的描述所採用的抽象層次。例如，某些架構爲其相關解決方案提供了直接的描述，而其餘的架構則可能描述了一個能夠跨越多個解決方案的方法或模式。
• 準確度：因爲架構是一個關於現實的表述，於是它也沒必要一絲不差地描述目標解決方案。一般來說，在架構建立中所投入資源的水平和質量將會決定架構的準確度。

2.3 結合多個分類特性進行架構劃分

      在前面部分中所列出的各個特性爲描述、劃分架構和解決方案提供了一系列指標維度，而且一旦這些特性被肯定，它們就能夠被用來對企業連續體中的內容進行劃分和組織，從而造成一系列相互關聯的架構和解決方案。通過如此方式的劃分，每個架構和解決方案的複雜性將會處於可控範圍以內；架構和解決方案的分組得以被定義，而且它們的層次結構和瀏覽結構也會被定義出來；每一個分組相應的流程、角色和責任也獲得了適當的分配。除了做爲獨立的維度而進行劃分以外，在實踐過程當中，這些特性每每還會被按照不一樣的目標而結合在一塊兒，從而對架構和解決方案進行劃分。TOGAF列舉了一系列組合式架構劃分方法，接下來咱們將依次對其進行探討：

 

 

 

 

 

2.3.1 經過架構情景劃分來理解企業狀態

      一般來說架構提供了在特定時間點上架構情景（Architecture Landscape）的摘要視圖。下列特性則常常被用來對繁複的架構情景進行劃分：

• 主題：主題域一般是對架構情景描述進行組織的主要特性，而架構在功能上也會被分解爲由各具體主題域所組成的層次結構。
• 詳細度：對於範圍比較廣闊的主題域來講，較爲簡潔的詳細度被用來確保架構具有可管理的規模和複雜度，而更加具體的主題域一般須要更爲詳細的架構。
• 時間：對於特定的主題和詳細度來講一個企業能夠建立一個基線架構和一系列目標架構。一般來說，範圍廣闊並具有較低詳細度的架構將在較長的時間中有效，併爲企業提供一個將來的願景。
• 視角：對於特定的主題域、詳細度和時間區域來說，架構的干係人將會站在各自的角度針對各自的問題來對架構進行審視。
• 準確度：每一個架構視圖在開發過程當中將會逐步加強其準確度，而若是不經妥善維護這些視圖在被正式批准以後其準確度也會逐步下降。

      以上這些特性能夠被結合在一塊兒來對架構進行劃分，但他們一樣能夠對解決方案連續體中的內容進行劃分。須要注意的是，以下的特性一般不會用在針對架構情景的劃分中：

• 用於描述架構情景的架構一般不是抽象的。
• 解決方案的波動性一般會限制架構對長期的將來進行定義，同時波動性也會隨時間的推移而削減架構的準確度。

 

2.3.2 對參考模型進行劃分來促進優良的實踐和重用

      有些描述解決方案、最佳實踐或模式的架構能夠做爲參考模型在整個企業內部進行共享。下列的特性一般被用來對這些架構參考模型進行劃分：

• 抽象水平：因爲參考模型的目標就是成爲能夠在多種環境下使用的抽象且可重用的解決方法，於是抽象水平能夠說是一個對參考模型進行組織的良好切入點。
• 主題：在必定的抽象水平之下，相互關聯的模型能夠用來對應某個特定的主題，於是從主題入手的劃分能夠方便針對架構的參考和引用。
• 視角：對於任何一個給定的主題，一系列參考模型能夠從各類相互補足的視角來對主題進行描述，而且相關的視角也能夠被組織起來爲所指望的解決方案方法提供一個更加全面的瞭解。

      一般狀況下，下列特性將不會被用在針對參考模型的劃分中：

• 參考模型一般是針對某一個特定問題的，而且其所採用的詳細度水平也與其描述的解決方法相適合，於是參考模型一般也並不會被分解爲具備更高詳細度的部件。
• 準確度和成熟度。
• 因爲參考模型是抽象的且不會與部署的解決方案有着顯式的綁定關係，於是時間特性與其並不相關。

      藉助於上述特性，參考模型能夠被劃分爲以下四種類別：

• 基礎架構：此種類型的參考模型抽象層次最高，於是能夠適用於全部企業架構或解決方案。
• 通用系統架構：展現了適用於多個企業和行業的通用系統的模式和方法，例如企業資源規劃（ERP）系統。
• 行業架構：提供了能夠適用於一個行業中多個合做夥伴或競爭對手的共享藍圖。
• 組織特定架構：提供了爲一個企業特製的通用參考模型，但這些參考模型也仍是能夠跨越多個業務領域的。

 

2.3.3 經過標準合規來執行企業策略

      各個組織一般經過定義並推行一系列標準來對其所指望的方法進行鼓勵，而下列的特性能夠被用來對架構中的標準進行劃分：

• 視角：因爲標準的意圖在於對整個企業中推行一致性的行爲，因此在一般狀況下，標準會採用一種會涵蓋多個領域的「水平」視角來做爲標準劃分的基礎。業務、數據、應用和技術這幾個架構領域是常常會被用到的標準劃分切入點，固然諸如安全這樣的特定視角也是能夠獨立存在的。
• 主題：在一個特定的視角之下能夠經過標準所涉及的主題來對相關標準進行分組。
• 成熟度/波動性：標準的成熟度能夠被用來決定其在生命週期中的狀態。

      一般狀況下，下列特性將不會被用在針對標準的劃分中：

• 標準的使用關乎於其成熟度，而對於時間區間並無特定的關聯。
• 標準須要被定義得足夠詳細，從而使得對其進行合規性評估成爲可行，因此一般對於標準在詳細度層面進行劃分是沒必要要的。
• 標準一般須要足夠具體才能對其進行合規性評估，於是對於標準在抽象水平層面進行劃分是沒必要要的。
• 標準應該是準確的，於是對於標準在準確度層面進行劃分是沒必要要的。

      藉助於上述特性，架構標準能夠被劃分爲以下四種類別：

• 業務標準：此種類型標準與業務架構領域的實踐相關聯，包括標準的流程、角色、責任和組織模型等。
• 數據標準：此種類型標準與數據架構領域的實踐相關聯，包括標準的數據模型、數據治理模型等。
• 應用標準：此種類型標準與應用架構領域的實踐相關聯，包括標準的應用、應用類型和應用功能等。
• 技術標準：此種類型標準與技術架構領域的實踐相關聯，包括標準的產品、產品類型和與技術的正當使用相關的約束。

 

2.4 架構劃分與架構開發方法

      架構的劃分使得單一架構或解決方案的規模和複雜程度可以處在一個可管理的水平，而且在開發和維護過程當中，具備不一樣職責的人員能夠並行工做，從而提高對最終片斷架構所進行的整合工做的效率。架構開發方法是TOGAF提出的一個關於企業架構開發的指導性流程，而該流程也正是架構劃分的用武之處：

• 預備階段支持對架構的適當劃分進行明確，以及在相關架構分塊間治理關係的確立。
• 在架構願景階段到遷移規劃階段這一過程當中，架構開發方法使得各個架構分塊中的架構內容得以被定義。
• 在實施治理階段和架構變動管理階段中，架構在其實現過程當中得以被有效地治理。這一治理能夠被應用到解決方案的直接實現之上，也能夠處理在其餘架構分塊中開發的架構的治理。