企業架構研究總結（37）——TOGAF企業連續體和工具之架構資源庫及架構工具的選擇

 

3. 架構資源庫

      在一個企業，尤爲是在一個大型企業中，建設一個成熟的架構每每會產生大量的工做產品。爲了很好地管理和利用這些工做產品，企業須要制定一個正式的針對不一樣類型架構資產的分類方法，而且還須要專門的流程和工做來輔助這些內容的存儲和管理，而這正是架構資源庫所關心的。在TOGAF中架構資源庫所包含的內容包括了以下幾個方面的信息：

• 架構元模型（Architecture Metamodel）：描述了組織爲自身量身定製的架構框架，包括架構開發方法和架構內容的元模型。
• 架構能力（Architecture Capability）：定義了用於支持架構資源庫治理的各個因素、結構和流程。
• 架構情景（Architecture Landscape）：展現了由組織當前正在使用的構件塊所組成的一幅架構視圖。爲了適用於不一樣的架構目標，架構情景一般會存在於多個粒度層次中。
• 標準信息庫（Standards Information Base）：此信息庫儲存了新架構所必須遵循的各個標準，包括行業標準、從供應商處所選擇的產品和服務，或者是已經部署在組織中的共享服務。
• 參考庫（Reference Library）：提供了用來加速企業中新架構建立的導則、模板、模式以及其餘形式的參考資料。
• 治理日誌（Governance Log）：用於對整個企業中的治理活動進行記錄。

      上圖對以上這些架構資源庫中的信息進行了展現，而且他們之間的關係以及他們與外界環境之間的關係也在這張圖中進行了描述。由圖可見，位於中間部分的架構情景庫包含了各個反應了企業當前情況的構建塊，而這些構建塊的產生和組織結構是由架構元模型而定的，而且在這些構建塊的產生過程當中，企業還須要借鑑參考庫和標準信息庫中的各類參考資料和標準，從而提升其建立的效率和質量。架構情景庫、參考庫和標準信息庫之間並不只僅是單向的借鑑關係，隨着企業架構過程的進行，架構情景庫中的構建塊將會日趨成熟，於是有些構建塊能夠被驗證爲在企業或行業甚至更爲廣闊範圍內的最佳實踐，從而能夠將他們引入到參考庫或標準信息庫之中，造成新的參考資料或標準，以供後期活動借鑑使用。爲了確保企業架構可以被正確地建立、運行和維護，企業架構過程須要一個治理過程來保駕護航。在治理過程當中，架構情景庫中的各個構建塊都是治理的目標所在，而且標準信息庫中的各項標準也是標準合規性檢查的重要輸入。須要注意的是，標準信息庫中各項標準的參考實現也能夠被保存到參考庫之中。

      既然架構資源庫是爲了方便外界針對架構資產的存儲和管理而存在的，那麼架構資源庫與外界環境之間也有着自然的聯繫：

• 企業能夠採用位於企業範圍以外的各類參考模型，並將其放入到參考庫之中。
• 企業能夠採用位於企業範圍以外的各類標準，並將其放入到標準信息庫之中。
• 架構委員會能夠檢視治理日誌庫中存儲的各項治理活動記錄，並將新的架構治理活動狀況錄入其中。
• 企業架構的最終目標是塑造企業的各項能力（組織結構、工做流程等），並使其知足企業的戰略目標，而反過來說，這些能力也保障和促進了企業架構的開發和運用。與這些能力相關的產品被存儲於架構能力庫之中，而架構委員會能夠經過其中的內容對各項能力進行管理。

      TOGAF針對架構情景庫、參考庫、標準信息庫和治理日誌庫中的內容進行了詳盡的描述，在接下來的各節中筆者將分別針對這些內容進行描述。

3.1 架構情景庫

      架構情景庫包含了用於描述企業當前狀態的各類架構塊。因爲整個企業中存在着形形色色的干係人，而且他們的需求也各不相同，於是架構情景庫中的內容包含了以下三個粒度層次：

• 戰略架構：提供了一份關於整個企業的長期歸納性視圖，併爲運行和變動活動提供了一個組織框架，從而使得企業能夠在領導層進行方向設定。
• 片斷架構：爲企業中的各個領域提供了更加詳盡的運營模型。片斷架構能夠被應用在方案或項目組合層面，從而用來對更加詳盡的變動活動進行組織和運行調整。
• 能力架構：採用一種更加詳盡的方式來展現企業是如何支持各個能力單元的。能力架構能夠被用來提供一個關於當前能力、目標能力以及能力增量的概覽，並使得各個工做包和項目得以被組合到受管理的項目組合和方案之中。

3.2 參考庫

      參考庫中包含了在企業的架構建設過程當中所用到的各類最佳實踐或模板材料。這些參考性資料能夠從各個方向而來，包括：

• 標準組織
• 產品和服務廠商
• 行業協會或論壇
• 由公司團體定義的模板
• 從項目實施中總結而出的最佳實踐

      爲了整合這些來源於各個地方的參考資料，參考庫能夠採用架構連續體來做爲它們的分類方法。

3.3 標準信息庫

      標準信息庫爲架構所必須遵照的各類規範說明提供了存儲區域，而且標準信息庫的創建爲架構治理也提供了一個清晰的基礎。標準的類型一般分爲以下幾類：

• 法律和法規義務：這些標準被法律所強制約束，於是企業必須遵照這些內容並面對可能產生的各類嚴重後果。
• 行業標準：這些標準由行業組織所創建，並被企業選擇採納。行業標準爲企業間的互操做和共享提供了潛力。因爲針對此種類型標準的控制處於企業以外，因此企業應該對此種類型標準的情況進行監督。
• 組織標準：這些標準在組織內部確立，並基於組織的業務指望。企業須要創建各類流程來保證這些標準的豁免狀況和演進。

      標準並非亙古不變的，每一個標準都要其生命週期，通常來說標準的生命週期包括以下幾個階段：

• 試行
• 有效
• 過期
• 廢棄

      全部的標準都應該按照必定的週期進行檢查，從而確保它們處於正確的生命週期階段。做爲標準生命週期管理的一部分，標準生命週期狀態的變動影響須要被明確，從而瞭解標準變動對於企業當前狀態的影響，併爲適當的處理活動進行規劃。

      針對存儲在標準信息庫中的各項標準的劃分與TOGAF內容元模型中所定義的各構建塊是相關的。在內容元模型中定義的各個實體都具備與其相關的標準。從最高劃分層次來說，標準的分類劃分是以TOGAF的各架構領域爲基礎而進行的：

• 業務標準：
• 標準的共享業務功能
• 標準的角色和執行者定義
• 與業務活動相關的安全和治理標準
• 數據標準：
• 標準編碼和數據值
• 數據的標準結構和格式
• 數據源和數據歸屬標準
• 複製和訪問限制
• 應用標準：
• 支持具體業務功能的標準或共享應用
• 應用通訊和互操做標準
• 訪問、表現和風格標準
• 技術標準：
• 標準硬件產品
• 標準軟件產品
• 軟件開發標準

3.4 治理日誌庫

      治理日誌庫爲正在進行的與項目治理活動相關的各項信息提供了一個儲存區域。針對治理信息的維護是很是重要的，由於：

• 對在項目進行過程當中所作的決策進行保留是很是重要的。例如，若是一個系統須要被替換，那麼對當初與其實現相關的關鍵架構決策有所瞭解是頗有價值的，由於它能夠對各類約束和限制進行標明，以避免這些信息被遺漏。
• 許多幹系人對於項目治理的結果是很是關心的，例如項目的客戶、架構委員會、其餘項目等。

      治理日誌庫的內容應包含以下各方面：

• 決策日誌：一個關於組織中全部重要架構決策的日誌，一般其內容包括：
• 產品選擇
• 項目主要架構特性的原因
• 標準誤差
• 標準生命週期變動
• 變動請求評估和審批
• 可重用性評估
• 合規評估：在項目過程的重要里程碑之中須要對架構進行一次正式地審查，用於評測項目與定義的標準之間的符合度。對於每一個項目來講，此日誌內容應包括：
• 項目概述
• 過程審查（時間表、狀態、問題、風險以及依賴關係等）
• 完整的架構清單
• 標準合規評測
• 建議的行爲
• 能力評估：根據項目目標的不一樣，某些項目須要進行業務、IT或架構能力方面的評估。這些評估須要週期性進行，並具有可追溯性，從而確保進程的順利。此日誌內容應該包括：
• 用於進行能力評估的模板和參考模型
• 業務能力評估
• IT能力、成熟度和影響評估
• 架構成熟度評估
• 行事曆：展現了一份關於還未落地的項目和對於這些項目進行正式審查的日程規劃。
• 項目組合：包含了關於全部還未處在架構治理之中的項目的摘要信息，包括：
• 項目名稱和描述
• 項目的架構範圍
• 與項目相關的架構角色和責任
• 性能評測：基於架構功能的章程，企業須要定義一系列性能指標。性能評測日誌應該包含與項目治理相關的指標，以及與架構章程相關的性能指標，從而使得架構的性能能夠在一個進行的狀態中得以被評測出來。

4. 架構工具的選擇

      從前面的內容中咱們能夠了解到，在企業架構的建設過程當中會產生出許許多多架構製品。雖然企業能夠經過創建架構資源庫的方式對這些製品進行儲存，可是對於它們的管理和訪問，以及對資源庫自身的維護來講，單靠手工來作那幾乎就是一個不可能完成的任務。從架構製品的使用角度來講，存儲在架構資源庫中的內容只是一些基礎素材，而要知足不一樣干係人在不一樣層面的不一樣需求，企業須要將這些元素進行組合，從而產生基於各類視角的視圖，而這一工做也是不可能單靠手工就能夠完成的。因而可知，在架構的開發、維護和使用過程當中自動化工具的介入和幫助是很是必要的。

      對於企業架構自動化工具來說，其最核心的問題就是如何創建一個統一的工具標準。這個方法從表面看是很是合理的，由於若是真的存在這樣一套遵循統一標準的萬能工具，那麼企業將會所以而得到培訓開支縮減、軟件受權共享、批量折扣，以及維護和信息交換方面的便利。這的確是一幅美好的畫卷，可是在實踐過程當中這種狀態卻很是難以達到。客觀的講，單一工具會減小工具之間的競爭，從而妨礙其演進，而且企業架構工具的選擇應該與企業的架構成熟度水平緊密關聯，而一個可以涵蓋全部架構成熟度水平的萬能工具是幾乎不可能存在的。

      雖然當前存在着不少由不一樣廠商開發的企業架構自動化工具，可是TOGAF做爲一個開放性標準，它對於這些自動化工具並無顯式的推薦，而是爲企業列舉出了一系列用於判斷架構工具是否符合自身要求的參考標準。在現實生活中，企業能夠參考這些標準，並按照自身狀況對其進行定製（例如，爲不一樣的標準設置不一樣的權重），從而在衆多工具之中選擇出適合於本身的自動化企業架構工具。須要注意的是，不管採用何種方式對工具進行選擇，咱們都須要注意以下幾個原則：

• 工具的價值依賴於組織的架構成熟度水平。
• 工具的選擇須要與組織的能力相匹配。
• 企業對於工具的選擇須要在戰略層面（組織總體標準和方向等）和戰術層面（人員能力和熟練度等）取得良好的平衡。
• 團隊對於工具的成功有着重要的影響，這些影響既多是正面的也多是負面的。

4.1 功能性考量

4.1.1 關鍵功能

• 是否支持組織所選擇的框架？
• 是否支持產生組織選擇的框架所要求的各項交付物？
• 若是不支持，那麼是否支持某些現成的企業架構框架，例如TOGAF、Zachman等？
• 術語表：
• 術語表是否能夠被擴展爲一個分類法？
• 當前術語表是否能夠被看成分類法而使用？
• 可以採用某種有意義的方式將架構模型和視圖展現給非技術類型的架構干係人的能力。
• 是否支持元模型？例如，配置和定製模型的能力。
• 是否支持企業級應用？例如，對於多用戶協做的支持。
• 是否支持向下追溯？例如，概念、邏輯和物理等層面的層層深刻。
• 是否提供了一種將需求與用於知足此需求的架構相關聯的機制？亦即需求追溯能力。
• 安全特性：
• 是否具備訪問控制？例如，對於不一樣的角色賦予不一樣的權限。
• 工具的安全設計是否與企業的安全策略相符？
• 是否支持本地報告生成？
• 是否支持通用語言和標註法？

4.1.2 易用性方面

• 是否可以經過一個簡易的流程圖來指導用戶的使用？
• 在線幫助。
• 現成且相關的構件元素，包括業務、數據、應用或技術方面。
• 現成且相關的用於進行架構建設的模板或模式。
• 支持可視化建模。
• 能否被擴展或定製，並是否提供了相關的工具？
• 是否可以對所作的變化進行跟蹤和審計？
• 是否提供了一種方法來爲各個製品進行一致性命名和組織？
• 是否架構製品或組件可以被很容易地查看、使用和重用？
• 是否支持編程語言的使用，而且相關需求都是什麼？

4.1.3 組織相容性方面

• 國際化/本地化能力：
• 是否工具能夠適用於架構工做所發生的各類地理位置和語言區域之中？

4.1.4 工具容量/伸縮性方面

• 是否具備容量限制？
• 數據的規模
• 文件的數量
• 數據記錄數
• 是否具備可配置點，而且這些配置點是如何實現其伸縮性的？
• 是否存在一種升級方式來應對工具的容量限制被超越的狀況？

4.2 工具體系結構考量

• 資源庫是分佈式的仍是集中式的？
• 是否具備動態資源庫？
• 是否支持多行業標準數據庫（例如Oracle，Sybase等）或採用專用存儲庫？
• 是否具備後向兼容性，用以兼容以前發佈的工具？
• 是否容許將數據整合進中央存儲庫？
• 是否具備版本控制？
• 能否經過Web客戶端進行訪問？
• 運行於何種平臺之上（硬件、操做系統、數據庫管理系統以及網絡）？

4.3 架構全生命週期支持考量

• 是否在架構全生命週期中對其進行支持？
• 是否支持各類現成的相關視圖？例如業務流程、數據、應用和技術方面的視圖。
• 是否支持定製化視圖的建立？
• 是否採用與企業架構實踐相關的建模方法和技術？
• 是否支持模擬分析？
• 工具所產生的模型是不是可執行的？

4.4 互操做性考量

• 導入與導出：
• 可否將在工具中建立的製品導出到其它通用工具之中，從而使得這些工具的用戶能夠無缺的使用那些製品。
• 可否導入其它工具所產生的製品，從而使得這些製品能夠在此工具內被無缺地使用。
• 是否能夠與其它工具相集成？
• 是否提供並支持符合行業標準的應用程序接口？
• 是否採用了相關的行業標準？例如，XML、HTML、UML等。

4.5 財務考量

• 採購成本是多少？
• 工具的總擁有成本爲什麼？
• 維護
• 裝置成本
• 支持成本
• 使其保持最新版本所需的資源數量
• 管理責任/時間約束
• 引入此工具所帶來的影響。例如，是否須要架設專門的基礎設施。
• 培訓
• 受權模式

4.6 廠商考量

• 廠商是否還有效？
• 廠商在此領域所存在的時間有多久？
• 是否廠商具備大量的用戶羣？
• 是否廠商具備專業的服務？
• 是否須要第三方支持？
• 是否此工具在組織中具備使用歷史，且其聲譽如何？
• 廠商是否在The Open Group的TOGAF認證程序中被認證？
• 培訓因素：
• 可得到性
• 成本
• 爲得到成效而須要的資金
• 學習風格