5. 架构合同
架构合同是在开发团体和赞助者之间关于架构的交付物、质量以及适用目标的联合协议，并且通过有效的架构治理将会促使这些协议的成功施行。通过对合同的管理施行一个治理方法，如下几点将会得到保障：
- 一个连续监测系统，用于检查完整性、变更、决策，并对组织内所有架构相关活动进行审计。
- 与现存的或正在开发中的架构相关的原则、标准和需求得以被坚持。
- 明确存在于架构的开发、实现和运营中的各种风险。
- 一系列流程和实践得以被制定，从而保障针对所有架构制品的开发和使用的问责性、责任和规章。
- 对于为合同进行负责的治理组织、其权威等级以及它所负责的架构范围产生一个正式的理解。
在企业架构开发方法的各阶段中经常会见到架构合同的身影，例如架构愿景阶段中的架构工作说明书等。但无论是何种架构协议，我们都要牢记企业架构开发的终极目标是创建一个动态的企业架构，亦即该架构可以适应外界技术和业务环境的变化而灵活地演进，而架构合同对于促成这一动态企业架构的实现，以及针对此实现的治理是非常重要的。
5.1 各架构合同内容
5.1.1 架构工作说明书
架构工作说明书产生于架构开发方法的架构愿景阶段，它是架构组织和企业架构赞助者之间的所签订的协议，其具体内容请参见之前架构内容框架中的相关内容。
5.1.2 架构设计和开发团队之间的合同
此合同是一份为设计和开发企业架构而签署的意向说明，亦或是其中一个重要部分。此合同所涉及到的团队组织包括系统集成者、应用提供者和服务提供者。随着合作分工的逐渐细化，针对一个或多个架构领域（业务、数据、应用和技术）的开发已经越来越多的被外包出去，而企业架构组织则主要负责在整体上进行监督和协调，并且在有些情况下，这一监督性角色的任务也被外包到企业之外。但无论怎样安排这些外包任务，这些安排都需要在架构合同的治理之下来进行。这些架构合同定义了所开发架构的交付物、质量、适用目标以及架构开发团队之间进行合作的各种流程。通常来讲，这些架构的内容包括如下几点：
- 背景介绍
- 协议性质
- 架构范围
- 架构和战略的原则和需求
- 一致性需求
- 架构开发和管理流程及相关角色
- 目标架构评测
- 针对交付物所定义的各个阶段
- 按照优先级排序的联合工作计划
- 时间窗口
- 架构交付和业务指标
5.1.3 架构功能组织和业务用户之间的合同
当企业架构被实现之后，在架构功能组织（或整合了架构功能的IT治理组织）和业务用户（他们将会在所设计的架构环境中创建和部署各个应用系统）之间就需要达成一份架构合同（此合同还可以被用来在架构变更阶段中对企业架构变更进行管理），而这份业务用户架构合同（Business Users’ Architecture Contract）的内容通常包括如下几点：
- 背景介绍
- 协议性质
- 范围
- 战略需求
- 用于满足业务需求的架构交付物
- 一致性需求
- 架构采用者
- 时间窗口
- 架构业务指标
- 服务架构（包括SLA，即服务水平协议）
5.2 架构合同与架构治理
在企业架构开发方法过程的实施治理阶段中所产生的各种架构合同文档主要处于架构治理领域之中。在架构治理的背景之下，这些架构合同经常被用来作为驱动架构变更的一种手段。为了确保这些架构合同的效能，如下几个治理框架的方面需要被引入到实施治理阶段之中：
- 精简的流程
- 以人为本的授权方式
- 强有力的沟通
- 及时的反馈，以及有效的上报流程
- 专门用作支持的组织结构
- 针对架构实现进行状态跟踪
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）进行汇报的架构能力成熟度水平。
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组织对企业进行引导的能力，而不仅仅是对需求进行回应而已。企业架构师的任务是进行战略技术领导。