企業架構研究總結（40）——TOGAF架構能力框架之架構合同、成熟度模型和架構技能框架
5. 架構合同
架構合同是在開發團體和贊助者之間關於架構的交付物、質量以及適用目標的聯合協議，而且經過有效的架構治理將會促使這些協議的成功施行。經過對合同的管理施行一個治理方法，以下幾點將會獲得保障：面試
- 一個連續監測系統，用於檢查完整性、變動、決策，並對組織內全部架構相關活動進行審計。
- 與現存的或正在開發中的架構相關的原則、標準和需求得以被堅持。
- 明確存在於架構的開發、實現和運營中的各類風險。
- 一系列流程和實踐得以被制定，從而保障針對全部架構製品的開發和使用的問責性、責任和規章。
- 對於爲合同進行負責的治理組織、其權威等級以及它所負責的架構範圍產生一個正式的理解。
在企業架構開發方法的各階段中常常會見到架構合同的身影，例如架構願景階段中的架構工做說明書等。但不管是何種架構協議，咱們都要牢記企業架構開發的終極目標是建立一個動態的企業架構，亦即該架構能夠適應外界技術和業務環境的變化而靈活地演進，而架構合同對於促成這一動態企業架構的實現，以及針對此實現的治理是很是重要的。編程
5.1 各架構合同內容
5.1.1 架構工做說明書
架構工做說明書產生於架構開發方法的架構願景階段，它是架構組織和企業架構贊助者之間的所簽定的協議，其具體內容請參見以前架構內容框架中的相關內容。安全
5.1.2 架構設計和開發團隊之間的合同
此合同是一份爲設計和開發企業架構而簽署的意向說明，亦或是其中一個重要部分。此合同所涉及到的團隊組織包括系統集成者、應用提供者和服務提供者。隨着合做分工的逐漸細化，針對一個或多個架構領域（業務、數據、應用和技術）的開發已經愈來愈多的被外包出去，而企業架構組織則主要負責在總體上進行監督和協調，而且在有些狀況下，這一監督性角色的任務也被外包到企業以外。但不管怎樣安排這些外包任務，這些安排都須要在架構合同的治理之下來進行。這些架構合同定義了所開發架構的交付物、質量、適用目標以及架構開發團隊之間進行合做的各類流程。一般來說，這些架構的內容包括以下幾點：網絡
- 背景介紹
- 協議性質
- 架構範圍
- 架構和戰略的原則和需求
- 一致性需求
- 架構開發和管理流程及相關角色
- 目標架構評測
- 針對交付物所定義的各個階段
- 按照優先級排序的聯合工做計劃
- 時間窗口
- 架構交付和業務指標
5.1.3 架構功能組織和業務用戶之間的合同
當企業架構被實現以後，在架構功能組織（或整合了架構功能的IT治理組織）和業務用戶（他們將會在所設計的架構環境中建立和部署各個應用系統）之間就須要達成一份架構合同（此合同還能夠被用來在架構變動階段中對企業架構變動進行管理），而這份業務用戶架構合同（Business Users’ Architecture Contract）的內容一般包括以下幾點：架構
- 背景介紹
- 協議性質
- 範圍
- 戰略需求
- 用於知足業務需求的架構交付物
- 一致性需求
- 架構採用者
- 時間窗口
- 架構業務指標
- 服務架構（包括SLA，即服務水平協議）
5.2 架構合同與架構治理
在企業架構開發方法過程的實施治理階段中所產生的各類架構合同文檔主要處於架構治理領域之中。在架構治理的背景之下，這些架構合同常常被用來做爲驅動架構變動的一種手段。爲了確保這些架構合同的效能，以下幾個治理框架的方面須要被引入到實施治理階段之中：app
- 精簡的流程
- 以人爲本的受權方式
- 強有力的溝通
- 及時的反饋，以及有效的上報流程
- 專門用做支持的組織結構
- 針對架構實現進行狀態跟蹤
6. 架構成熟度模型
因爲各個組織所處的環境並非一成不變的，於是可以對這些變化進行快速反應並與之相適應的組織將會比那些缺少應變能力的組織得到更大的優點。隨着IT技術的日益發展以及與組織業務聯繫的日趨緊密，每一個組織都知道爲了管理全部可能出現的變化須要不斷地改其與IT相關的開發流程，但對於不少組織來講，在哪些方面進行改進以及如何改進的確是個讓人頭疼的問題。因此在實踐過程當中，有的組織要麼因爲不知如何下手而投入過少，要麼進行漫無目標的投入而致使投資回報率太低。那麼各個組織如何才能解決這一問題，從而使得其所作的改進努力更加有目的性，並獲得足夠好的回報呢？其實這一問題的答案就是在組織中創建和運用能力成熟度模型（CMMs：Capability Maturity Models）。經過使用這些模型，組織能夠獲得以下效益：框架
- 這些模型描述了各類通過總結的實踐，藉此組織能夠改進其流程。
- 這些模型提供了一系列衡量尺度，藉此組織能夠對其能力狀態進行週期性評測。
- 這些模型提供了一個通過驗證的框架，藉此組織能夠對其所付出的改進努力進行有效管理。
能力成熟度模型並非專爲企業架構而生，其實它最初目標是爲了改善軟件和系統工程的過程，只是隨着企業架構理論的發展以及業界針對這一領域的關注逐漸增強，人們纔開始考慮將這一模型應用到企業架構的領域之中，從而爲評測和改進企業架構的過程提供導向。在TOGAF 9中並無爲企業架構專門設計一套成熟度模型，它只是經過例舉兩種成熟度模型來介紹當前企業架構是如何與能力成熟度模型相結合的，以供讀者借鑑。編程語言
6.1 美國商務部架構能力成熟度模型（US DoC ACMM）
在前面已經提到過，美國政府能夠說是施行企業架構的先行者之一，於是全部的美國聯邦政府部門都被要求提供成熟度模型以及相應的打分機制來做爲他們的IT投資管理和審計需求的一部分。以美國商務部（US Department of Commerce（DoC））爲例，他就已經開發出了一套企業架構能力成熟度模型（ACMM：Architecture Capability Maturity Model）來幫助其內部的企業架構成熟度評測。這一成熟度模型在2007年12月時發佈了1.2版本。ACMM提供了一套框架，其中包含了一個富有成效的企業架構過程所應具有的各類關鍵組件，其目標在於經過明確企業架構的薄弱環節並提供一條定義良好的演進改善路線來提高企業架構的成功概率。ACMM包含以下三部份內容：分佈式
- 企業架構成熟度模型
- 各個運行單元的流程在不一樣成熟度水平上的企業架構特性。
- 企業架構能力成熟度模型記分卡。
在上述三個部分的內容中，前兩部份描述了架構能力成熟度水平、相應的企業架構元素，以及用在成熟度評測中的每一個成熟度水平的特性；最後一個部分被用來獲取用於向商務部首席信息官（CIO）進行彙報的架構能力成熟度水平。ide
6.1.1 ACMM企業架構評定元素
ACMM從以下九個方面對企業架構的成熟度水平進行評定：
- 架構流程（Architecture process）
- 架構開發（Architecture development）
- 業務聯繫（Business linkage）
- 高層管理的參與（Senior management involvement）
- 運行單元的參與（Operating unit participation）
- 架構溝通（Architecture communication）
- IT安全性（IT security）
- 架構治理（Architecture governance）
- IT投資和併購戰略（IT investment and acquisition strategy）
6.1.2 ACMM成熟度水平
ACMM將每一個企業架構成熟度評估元素的成熟度水平分爲以下五個檔次：
- 無（None）
- 初步（Initial）
- 在開發（Under development）
- 已定義（Defined）
- 受管理的（Managed）
- 可計量的（Measured）
6.2 能力成熟度模型集成（CMMI）
截至到目前，成熟度模型已經在不少行業中獲得了接受和施行，並且每一個行業幾乎都具備符合其自身特色的成熟度模型，可是正是因爲這種普遍的接受性致使了成熟度模型過於繁雜。爲了管理這一因爲過多成熟度模型所帶來複雜性，SEI（Software Engineering Institute）開發了一個名爲能力成熟度模型集成（CMMI：Capability Maturity Model Integration）的框架。該框架綜合了各領域成熟度模型的最佳實踐，它使得組織能夠：
- 將管理和工程活動與業務目標更加明顯地聯繫在一塊兒。
- 擴展產品生命週期和工程活動的範圍和可見度，從而確保產品或服務知足用戶的指望。
- 歸入從其餘領域的最佳實踐中汲取的經驗教訓。
- 實現更加堅固的高成熟度實踐。
- 實現對產品和服務來講很是重要的額外的組織功能。
- 更加充分的遵循相關ISO標準。
因爲CMMI並非隸屬於某個特定行業的綜合性成熟度模型，於是在企業架構的成熟度方面也能夠對其進行借鑑，而這其中最爲重要的就是標準過程改進評估方法（SCAMPI ：Standard CMMI Appraisal Method for Process Improvement）。此方法是與CMMI相關連的評估方法，被用來與CMMI參考模型進行比對，從而對目標的優點、弱點進行明確，並經過分數評定的方式進行清晰的表述。
7. 架構技能框架
企業架構過程是個很是繁雜的過程，它的順利進行離不開衆多具備不一樣角色的人員的通力協做，而如何保證這些相互合做的人員在各自崗位上可以勝任就變成一切活動的根本問題。爲了應對這一問題，TOGAF提出了架構技能框架（Architecture Skills Framework），它爲進行企業架構建設的組織提供了一份關於企業架構工做中各類角色及其能力的視圖，從而爲擔負企業架構工做任務的團隊的創建提供了導則。簡單來說，架構技能框架的內容包含以下三個方面：
- 定義了架構工做各領域所涉及到的角色。
- 定義了每一個角色所應具有的技能。
- 定義了每一個角色爲了順利承擔其責任而對各類技能所應掌握的水平。
在實踐中，每一個企業對於項目人員的選擇應該都有着本身的一套方法和流程，基本上來說，都是經過項目自己的特質來制定所需人員的技能標準，並經過簡單的面試來從組織內外的候選者中選擇合適之人，但這對於企業架構的建設來說卻過於簡單了。雖然企業架構的建設從本質上來說也是一個項目，可是因爲其自己的複雜度之高、牽涉性之廣，若是把它看成一個普通實現項目來對待的話，組織每每會面臨以下風險：
- 因爲牽涉太廣，從而缺少統一術語、溝通和表述方式，因此招募組織、資訊團體和僱傭部門之間的溝通會很是困難。
- 候選者每每具備很好的意向，但卻可能缺少組織所須要的必要技能和經驗，而這每每會致使時間的浪費。
- 因爲沒有明確的標準，招募宣傳中的要求每每會因爲被誤解而使那些具備足夠能力的人員被忽視。
- 僱傭不合適人員的風險將會加大，而這又會致使：
- 因爲可能會出現人員的再次招募或從新分配，於是會致使人員成本的增長。
- 對運營的IT系統以及對其進行交付的項目的時間、成本和質量將產生巨大影響。
爲了儘可能避免這些風險，各個組織應該採用更爲正式的認證機制來對企業架構工做人員進行定義和選擇，而這一機制的目的應該在於以下兩點：
- 做爲創建和維護一個專業架構組織的任務的一部分，對架構人員所需的技能進行正式承認。
- 確保人員的技能和經驗與其所擔當的任務相匹配。
7.1 角色分類
TOGAF將一般用來承擔企業架構開發工做的架構團隊中的角色分爲以下幾類：
- 架構委員會成員（Architecture Board Members）
- 架構贊助者（Architecture Sponsor）
- 架構經理（Architecture Manager）
- 架構師（Architects）。包括以下幾個領域中的架構師：
- 企業架構（Enterprise Architecture）：此種類型的架構能夠看做是下面幾個領域（業務、數據、應用和技術）中的架構的超集。
- 業務架構（Business Architecture）
- 數據架構（Data Architecture）
- 應用架構（Application Architecture）
- 技術架構（Technology Architecture）
- 方案和/或項目經理（Program and/or Project Managers）
- IT設計師（IT Designer）
- 其餘角色...
7.2 技能分類
架構技能框架將架構團隊所須要技能概括爲以下幾類：
- 通用技能（Generic Skills）：一般包括領導力、團隊協做能力和人際交流技能等。
- 業務技能和方法（Business Skills & Methods）：一般包括業務案例、業務流程和戰略規劃等。
- 企業架構技能（Enterprise Architecture Skills）：一般包括建模、構建塊設計、應用和角色設計、系統集成等。
- 方案或項目管理技能（Program or Project Management Skills）：一般包括管理業務變動、項目管理方法和工具等。
- 通用IT知識技能（IT General Knowledge Skills）：一般包括代理應用（brokering applications）、資產管理、遷移規劃以及SLAs等。
- IT技術技能（Technical IT Skills）：一般包括軟件工程、安全、數據交換以及數據管理等。
- 法律環境（Legal Environment）：一般包括數據保護法、合同法等。
7.3 熟練度水平定義
7.4 各角色及其技能熟練度水平
| 架構委員會成員 |
架構贊助者 |
架構經理 |
架構師 （技術） |
架構師 （數據） |
架構師 （應用） |
架構師 （業務） |
方案/項目經理 |
IT設計師 |
|
| 通用技能 |
|||||||||
| 領導力 （Leadership） |
4 |
4 |
4 |
3 |
3 |
3 |
3 |
4 |
1 |
| 團隊合做 （Teamwork） |
3 |
3 |
4 |
4 |
4 |
4 |
4 |
4 |
2 |
| 人際交往 （Inter-personal） |
4 |
4 |
4 |
4 |
4 |
4 |
4 |
4 |
2 |
| 口才 （Oral Communications） |
3 |
3 |
4 |
4 |
4 |
4 |
4 |
4 |
2 |
| 寫做 （Written Communications） |
3 |
3 |
4 |
4 |
4 |
4 |
4 |
3 |
3 |
| 邏輯分析 （Logical Analysis） |
2 |
2 |
4 |
4 |
4 |
4 |
4 |
3 |
3 |
| 干係人管理 （Stakeholder Management） |
4 |
3 |
4 |
3 |
3 |
3 |
3 |
4 |
2 |
| 風險管理 （Risk Management） |
3 |
3 |
4 |
3 |
3 |
3 |
3 |
4 |
1 |
| 業務技能和方法 |
|||||||||
| 業務案例 （Business Case） |
3 |
4 |
4 |
4 |
4 |
4 |
4 |
4 |
2 |
| 業務情景 （Business Scenario） |
2 |
3 |
4 |
4 |
4 |
4 |
4 |
3 |
2 |
| 組織結構 （Organization） |
3 |
3 |
4 |
3 |
3 |
3 |
4 |
3 |
2 |
| 業務流程 （Business Process） |
3 |
3 |
4 |
4 |
4 |
4 |
4 |
3 |
2 |
| 戰略規劃 （Strategic Planning） |
2 |
3 |
3 |
3 |
3 |
3 |
4 |
3 |
1 |
| 預算管理 （Budget Management） |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
4 |
3 |
| 戰略願景 （Visioning） |
3 |
3 |
4 |
3 |
3 |
3 |
4 |
3 |
2 |
| 業務指標 （Business Metrics） |
3 |
4 |
4 |
4 |
4 |
4 |
4 |
4 |
3 |
| 業務文化 （Business Culture） |
4 |
4 |
4 |
3 |
3 |
3 |
3 |
3 |
1 |
| 遺留的投資 （Legacy Investments） |
4 |
4 |
3 |
2 |
2 |
2 |
2 |
3 |
2 |
| 業務功能 （Business Functions） |
3 |
3 |
3 |
3 |
4 |
4 |
4 |
3 |
2 |
| 企業架構技能 |
|||||||||
| 業務建模 （Business Modeling） |
2 |
2 |
4 |
3 |
3 |
4 |
4 |
2 |
2 |
| 業務流程設計 （Business Process Design） |
1 |
1 |
4 |
3 |
3 |
4 |
4 |
2 |
2 |
| 角色設計 （Role Design） |
2 |
2 |
4 |
3 |
3 |
4 |
4 |
2 |
2 |
| 組織結構設計 （Organization Design） |
2 |
2 |
4 |
3 |
3 |
4 |
4 |
2 |
2 |
| 數據設計 （Data Design） |
1 |
1 |
3 |
3 |
4 |
3 |
3 |
2 |
3 |
| 應用設計 （Application Design） |
1 |
1 |
3 |
3 |
4 |
3 |
3 |
2 |
3 |
| 系統集成 （Systems Integration） |
1 |
1 |
4 |
4 |
3 |
3 |
3 |
2 |
2 |
| IT行業標準 （IT Industry Standards） |
1 |
1 |
4 |
4 |
4 |
4 |
3 |
2 |
3 |
| 服務設計 （Services Design） |
2 |
2 |
4 |
4 |
3 |
4 |
3 |
2 |
2 |
| 架構原則設計 （Architecture Principles Design） |
2 |
2 |
4 |
4 |
4 |
4 |
4 |
2 |
2 |
| 架構視圖和視角設計 （Architecture Views & Viewpoints Design） |
2 |
2 |
4 |
4 |
4 |
4 |
4 |
2 |
2 |
| 構建塊設計 （Building Block Design） |
1 |
1 |
4 |
4 |
4 |
4 |
4 |
2 |
3 |
| 解決方案建模 （Solutions Modeling） |
1 |
1 |
4 |
4 |
4 |
4 |
4 |
2 |
3 |
| 效益分析 （Benefits Analysis） |
2 |
2 |
4 |
4 |
4 |
4 |
4 |
4 |
2 |
| 業務交互 （Business Interworking） |
3 |
3 |
4 |
3 |
3 |
4 |
4 |
3 |
1 |
| 系統行爲 （Systems Behavior） |
1 |
1 |
4 |
4 |
4 |
4 |
3 |
3 |
2 |
| 項目管理 （Project Management） |
1 |
1 |
3 |
3 |
3 |
3 |
3 |
4 |
2 |
| 方案或項目管理技能 |
|||||||||
| 方案管理 （Program Management） |
1 |
2 |
3 |
3 |
3 |
3 |
3 |
4 |
2 |
| 項目管理 （Project Management） |
1 |
2 |
3 |
3 |
3 |
3 |
3 |
4 |
2 |
| 管理業務變動 （Managing Business Change） |
3 |
3 |
4 |
3 |
3 |
3 |
4 |
4 |
2 |
| 變動管理 （Change Management） |
3 |
3 |
4 |
3 |
3 |
3 |
4 |
3 |
2 |
| 價值管理 （Value Management） |
4 |
4 |
4 |
3 |
3 |
3 |
4 |
3 |
2 |
| 通用IT知識技能 |
|||||||||
| IT應用開發方法和工具 （IT Application Development Methodologies & Tools） |
2 |
2 |
3 |
4 |
4 |
4 |
2 |
3 |
3 |
| 編程語言 （Programming Languages） |
1 |
1 |
3 |
4 |
4 |
4 |
3 |
2 |
3 |
| 代理應用 （Brokering Applications） |
1 |
1 |
3 |
3 |
4 |
4 |
3 |
2 |
3 |
| 信息消費應用 （Information Consumer Applications） |
1 |
1 |
3 |
3 |
4 |
4 |
3 |
2 |
3 |
| 信息提供應用 （Information Provider Applications） |
1 |
1 |
3 |
3 |
4 |
4 |
3 |
2 |
3 |
| 存儲管理 （Storage Management） |
1 |
1 |
3 |
4 |
4 |
2 |
2 |
2 |
3 |
| 網絡 （Networks） |
1 |
1 |
3 |
4 |
3 |
2 |
2 |
2 |
3 |
| 基於Web的服務 （Web-based Services） |
1 |
1 |
3 |
3 |
4 |
4 |
2 |
2 |
3 |
| 信息技術基礎設施 （IT Infrastructure） |
1 |
1 |
3 |
4 |
3 |
2 |
2 |
2 |
3 |
| 資產管理 （Asset Management） |
1 |
1 |
4 |
4 |
3 |
3 |
3 |
2 |
3 |
| 服務等級協議 （Service Level Agreements） |
1 |
1 |
4 |
4 |
3 |
4 |
3 |
2 |
3 |
| 系統 （Systems） |
1 |
1 |
3 |
4 |
3 |
3 |
2 |
2 |
3 |
| 商用現成品 （COTS） |
1 |
1 |
3 |
4 |
3 |
4 |
2 |
2 |
3 |
| 企業連續體 （Enterprise Continuums） |
1 |
1 |
4 |
4 |
4 |
4 |
4 |
2 |
3 |
| 遷移規劃 （Migration Planning） |
1 |
1 |
4 |
3 |
4 |
3 |
3 |
2 |
3 |
| 管理工具 （Management Utilities） |
1 |
1 |
3 |
2 |
4 |
4 |
2 |
2 |
3 |
| 基礎設施 （Infrastructure） |
1 |
1 |
3 |
4 |
3 |
4 |
2 |
2 |
3 |
| IT技術技能 |
|||||||||
| 軟件工程 （Software Engineering） |
1 |
1 |
3 |
3 |
4 |
4 |
3 |
2 |
3 |
| 安全 （Security） |
1 |
1 |
3 |
4 |
3 |
4 |
3 |
2 |
3 |
| 系統和網絡管理 （Systems & Network Management） |
1 |
1 |
3 |
4 |
3 |
3 |
3 |
2 |
3 |
| 事務處理 （Transaction Processing） |
1 |
1 |
3 |
4 |
3 |
4 |
3 |
2 |
3 |
| 位置和目錄 （Location & Directory） |
1 |
1 |
3 |
4 |
4 |
3 |
3 |
2 |
3 |
| 用戶界面 （User Interface） |
1 |
1 |
3 |
4 |
4 |
4 |
3 |
2 |
3 |
| 國際化操做 （International Operations） |
1 |
1 |
3 |
4 |
3 |
3 |
2 |
2 |
2 |
| 數據交換 （Data Interchange） |
1 |
1 |
3 |
4 |
4 |
3 |
2 |
2 |
3 |
| 數據管理 （Data Management） |
1 |
1 |
3 |
4 |
4 |
3 |
2 |
2 |
3 |
| 圖形與圖像 （Graphics & Image） |
1 |
1 |
3 |
4 |
3 |
3 |
2 |
2 |
3 |
| 操做系統服務 （Operating System Services） |
1 |
1 |
3 |
4 |
3 |
3 |
2 |
2 |
3 |
| 網絡服務 （Network Services） |
1 |
1 |
3 |
4 |
3 |
3 |
2 |
2 |
3 |
| 通訊基礎設施 （Communications Infrastructure） |
1 |
1 |
3 |
4 |
3 |
3 |
2 |
2 |
3 |
| 法律環境 |
|||||||||
| 合同法 （Contract Law） |
2 |
2 |
2 |
2 |
2 |
2 |
2 |
3 |
1 |
| 數據保護法 （Data Protection Law） |
3 |
3 |
4 |
3 |
3 |
3 |
3 |
2 |
2 |
| 採購法 （Procurement Law） |
3 |
2 |
2 |
2 |
2 |
2 |
2 |
4 |
1 |
| 詐騙 （Fraud） |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
1 |
| 商業法 （Commercial Law） |
3 |
3 |
2 |
2 |
2 |
2 |
3 |
3 |
1 |
7.5 企業架構師角色詳解
在前面提到過的各類角色之中，最常常被提到的恐怕要數「企業架構師」這一角色了，而這也正是由於這一角色是整個企業架構建設的核心。雖然很是重要且常被掛在嘴角，但其在各行業中正式的定義卻鮮有所聞，而僅僅被看成一個跨越多個架構領域具備普遍實踐經驗和技能的角色。TOGAF對於企業架構師的工做描述總結爲以下幾點：
- 負責保證架構的全面性，即架構應照顧到全部相關干係人的關注點。
- 負責保證架構的完整性，即全部種類不一樣的視圖關聯在一塊兒，圓滿調和不一樣干係人之間的衝突點，並展現出此種調和所帶來的利益權衡。
- 企業架構師所要作的重要決策之一就是針對各類干係人關注點來選擇開發特定的視圖。這一選擇須要注意其可實踐性，並要在符合適用目標（fitness-for-purpose）的原則下進行。
架構師的職責範圍貫穿了企業架構的整個生命週期，它開始於與客戶一塊兒理解其真正的需求，並在其後的過程當中負責將這些需求轉化爲可以對其進行實現的各項能力。此外，架構師還須要經過不一樣模型的展現來與客戶就其需求是如何被知足的進行溝通。因而可知，架構師與負責建設的團隊是不一樣的，他的主要目標在於理解如何才能知足客戶的須要，並就此爲負責建設的應用開發團隊或產品實現團隊提供設計決策文檔。與建設者相比，架構師須要保持必定水平的抽象性，而且一般其所使用的技能應該是概括性的，而建設者則更加註重於實現方面，其所採用的技能也每每是推斷性的。綜上所述，架構師的角色職能能夠總結以下：
- 理解並解釋需求：探索信息、傾聽信息、影響他人、促進共識、將各類觀點綜合轉換爲可行的需求、並將這些觀點解釋給他人。此外，還包括明確用途或目標、約束以及風險等因素。架構師將參與到針對各類客戶業務情景的發掘之中，並對其進行文檔記錄。架構師還負責針對需求進行理解，並將這些理解融入到架構說明規範之中。
- 建立有用的模型：根據需求來開發各類通過精心定製的模型，並在必要的狀況下對這些模型進行充實，使其可以適應全部的環境。架構師還將以這些模型爲基礎來展現出各類視圖，從而提高與干係人之間所進行溝通的有效性。架構師爲總體架構的完整性進行負責，並負責從架構的視角來對所提供的願景進行維護。此外，架構師還要確保對各類明確的機會進行利用、採用各類構建塊，並充當各個功能組織之間的聯絡員。爲了理解開發工做的各個領域，並對組織內外所應採起的行爲進行指導，架構師須要以框架的方式對這些模型進行提供和維護，此外架構師還必須經過對全部必須的業務組件的理解來表現架構的組織視圖。
- 驗證、修繕並擴展模型：對各類假設進行驗證，並將其輸入給主題專家。爲了改善模型並對其進行進一步的定義，架構師須要爲模型加入必須的新觀點，從而使得模型更加靈活，並可以與當前及指望的需求聯繫得更加緊密。除此以外，架構師還應該對產生於現場工做用於對解決方案進行加強的開發的價值進行評估，並將這些內容適當地融入到架構模型之中。
- 管理架構：對模型進行持續監督，並在必要時對其進行更新，從而展現出了各類變化、新增和調整。在項目的開發和決策點對各類架構和問題進行表現。在整個開發週期中，架構師須要持續地促進組織間對於客戶、架構和技術信息的共享。
在前面有關企業連續體的部分中咱們已經瞭解到，對於構建塊的實現可能會受其複雜性所限而須要對其解決方案的實施進行進一步劃分，而在這種狀況下就須要多種架構師的通力協做。從企業連續體的角度來講，架構師這一角色能夠分爲以下幾種，而且其中的每一種都具有着各自的關注點：
- 企業架構師（Enterprise Architect）：從全景和技術參考模型的層次來爲架構設計和文檔進行負責。企業架構師一般領導一組與某一給定方案相關的片斷架構師和/或解決方案架構師，而且其關注點在於所須要的企業級業務功能。
- 片斷架構師（Segment Architect）：負責特定業務問題或組織領域內的架構設計和文檔。一個片斷架構師將會對其餘架構師的輸出進行重用，並將詳細的技術解決方案加入到總體架構全景之中。片斷架構師的關注點在於一個給定領域（例如財務、人力資源以及銷售等）中的企業級業務解決方案。
- 解決方案架構師（Solution Architect）：在系統或子系統級別對架構設計和文檔進行負責。一個解決方案架構師能夠爲企業或片斷架構師屏蔽沒必要要的系統、產品和/或技術方面的細節，而且其關注點在於系統技術解決方案方面，例如諸如企業數據倉庫之類的解決方案組件。
在本節的最後一部分，咱們來探討一下TOGAF對於企業架構師各方面特質的概括總結：
- 熟悉建立設計的技能和經驗：企業架構師必須熟練掌握建立複雜系統設計的各項技術，這包括需求發現和分析、解決方案上下文的制定、對各類可能的解決方案進行識別和評定、技術選型以及設計配置。
- 具有寬泛的技術廣度，並在一個或幾個領域中具有必定技術深度：企業架構師應該對IT行業有着寬泛的技術廣度，而且這一廣度應該涵蓋應用開發和部署，以及針對用於支持複雜應用環境的基礎設施的建立和維護方面。當前的IT環境一應俱全，而爲了應對各類狀況，有經驗的企業架構師將具有跨越多個平臺的技能，這包括了分佈式系統以及傳統的大型機環境。此外，企業架構師還應至少在一個領域中具有專家級的水平。
- 以方法驅動（Method-Driven）的方式來進行工做：企業架構師應該使用已被確認的方法（例如TOGAF）來進行工做。企業架構師應會使用一種以上的設計方法，並會根據工做狀態自如地選擇合適的方法或方法的一部分，亦即架構師應該瞭解在某給定狀況下何種方法或方法部分能夠被採用，而何種則不能夠。
- 具有全項目範圍的經驗：當企業架構師對用於實現的項目的設計和執行進行負責時，他們對項目全部的方面具有經驗是很是重要的。這些項目方面包括了開發、測試、實現和生產。企業架構師所掌握的項目經驗的範圍有助於其立於「適合目標（fitness-for-purpose）」以及系統實現的現實性的基礎之上，並且全項目範圍經驗所帶來的影響將會引導企業架構師制定出更好的設計決策，並在這些決策之間得到更好的平衡。
- 具有領導力：溝通和團隊協做對於企業架構師這一角色的成功實現來說是關鍵，而且良好的技術技能和領導能力的結合對其來說也是相當重要的。企業架構師應被IT組織、其所服務的客戶以及管理層看做企業中的一個領導者。
- 具有人際關係和專業方面的技能：因爲企業架構師的主要任務之一就是與全部干係人（包括沒有技術背景的干係人）就複雜的技術信息進行溝通，因此企業架構師必須具有很強的溝通和人際關係技能。此外，企業架構師還須要具有很強的談判及解決問題的能力，由於企業架構師還必須與項目管理團隊一塊兒工做來及時地制定決策，從而保證項目運行在正確軌道之上。
- 具有一個或多個行業中的技能和經驗：行業技能和經驗將會使得收集需求及關於優先級的決策任務更加簡單和有效。企業架構師必須理解企業的業務流程，以及這些流程是如何與行業中的其餘企業協同工做的。企業架構師還應能發現主要的趨勢，並對有缺陷的流程進行修正，從而給予IT組織對企業進行引導的能力，而不只僅是對需求進行迴應而已。企業架構師的任務是進行戰略技術領導。
- 1. 企業架構研究總結（38）——TOGAF架構能力框架之架構能力建設和架構治理
- 2. togaf架構內容框架_敏捷地使用企業架構框架（TOGAF）
- 3. 企業架構研究總結（30）——TOGAF架構內容框架之內容元模型（上）
- 4. 企業架構研究總結（5）——Zachman框架
- 5. 《TOGAF 9.1IT企業架構》2.2企業IT架構的工作結構組成
- 6. 框架&架構
- 7. 架構、框架
- 8. 怎麼理解框架、架構和企業架構？
- 9. 【架構框架】IoC框架
- 10. 企業架構（TOGAF）學習
- 更多相關文章...
- • Docker 架構 - Docker教程
- • 互聯網系統應用架構基礎分析 - 紅包項目實戰
- • 算法總結-廣度優先算法
- • 算法總結-深度優先算法
-
每一个你不满意的现在，都有一个你没有努力的曾经。