企业架构研究总结（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教程
- • 互联网系统应用架构基础分析 - 红包项目实战
- • 算法总结-广度优先算法
- • 算法总结-深度优先算法
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. Appium入门
- 2. Spring WebFlux 源码分析(2)-Netty 服务器启动服务流程 --TBD
- 3. wxpython入门第六步（高级组件）
- 4. CentOS7.5安装SVN和可视化管理工具iF.SVNAdmin
- 5. jedis 3.0.1中JedisPoolConfig对象缺少setMaxIdle、setMaxWaitMillis等方法，问题记录
- 6. 一步一图一代码，一定要让你真正彻底明白红黑树
- 7. 2018-04-12—（重点）源码角度分析Handler运行原理
- 8. Spring AOP源码详细解析
- 9. Spring Cloud（1）
- 10. python简单爬去油价信息发送到公众号