为了确保架构功能在企业中能够被成功地运用，企业需要通过建立适当的组织结构、流程、角色、责任和技能来实现其自身的企业架构能力，而这也正是TOGAF的架构能力框架（Architecture Capability Framework）的关注点所在。架构能力框架为企业如何建立这样一种架构能力提供了一系列参考材料，从而为各企业架构能力的创建提供了帮助，不过TOGAF的架构能力框架在当前还不是一套全面的关于如何运用架构能力的模板，它只是为企业架构能力建设和运用过程中的各项关键活动提供了一系列导则和指南。
如图所示，企业的架构能力一定是运行在某一成熟度水平之上，并且在此背景之下，治理组织（Governance Bodies）将对企业中各架构功能的运作进行监管、评测和指导。图中间部分所表述的就是架构功能得以被成功运用所需的各种元素，包括了：
用于管理架构功能的实现和维护所必需的各种角色、责任以及其所需技能的技能资源池（Skilled Resource Pool）。
架构功能的实现和维护最终需要落实到一个个的实施项目（Project/Portfolios）之上，而这些项目在其整个生命周期内都需要处在一定的架构治理（Project/Portfolios Governance）之下，从而使其能够与架构的定义始终保持一致，而为了在明确和标准化的前提下达成这一目标，这些实施项目与相应的项目治理之间需要通过合同（Contract）来进行沟通和约束。
技能资源池为各实施项目以及项目治理设定了相应的参与角色和责任，并对能够胜任这些角色和责任的专业人员其所需的各种技能进行了定义和组织，同时通过培训的建设来建立或提高专业人员所需的各种技能。对于处于架构能力框架主导地位的治理组织来说，它除了对技能资源池的建设提供指导之外，还需要为各实施项目的治理设定优先级和关注点，并对项目治理的成效进行评测。由于企业的内部以及其所处的外部环境是不断变化的，因而企业本身也需要适应这些内外的变化，而企业日常的业务运营（Business Operation）状况对于架构来说正是这种内外变化的最佳反映，它为针对各架构实现项目所进行的治理的优先级排序以及关注点的设定提供了参照，同时各架构实现项目也为企业的业务运营提供了合适的解决方案。
在之前的各部分中已经提到过，企业架构的各项内容最终要存放到架构资源库（Architecture Repository）之中，因而在架构能力框架中也将这一元素包括了进来，用于对在各项目中所产生的架构工作产品进行保存和维护，并通过引入企业连续体（Enterprise Continuum）来对这些工作产品进行分类归纳。
综上所述，架构能力框架为企业中架构能力的建设提供了指南。这里所说的架构能力简单来说就是企业能够成功建设和运用架构的能力，而其实现方式是在企业中建立相应的组织结构和流程，并对所需的角色、责任和技能进行定义和分配，从而为企业中的各架构的交付和治理提供环境和资源。TOGAF针对上面这些内容从如下方面分别给出了导则和指南：
架构能力建设：用于指导企业如何通过架构开发方法的引入来对架构能力进行建设。
架构治理（Architecture Governance）：架构能力的目标就是通过对企业中各个架构的合理治理来保障整个企业架构建设和运作的顺利，并且此部分对于架构治理以及与此过程相关的组织结构的建立、架构合同（Architecture Contracts）和架构合规性（Architecture Compliance）都进行了较为详尽的描述。
架构成熟度模型（Architecture Maturity Models）：不论企业清楚与否，其企业架构的建设和运作一定处于某种成熟度水平之上，而为了让企业能够了解自己企业架构的成熟度水平，并借此针对薄弱环节进行识别和改善，都需要成熟度模型的引入。
架构技能框架（Architecture Skills Framework）：架构能力的实现需要为参与架构实现项目和架构治理的各种角色、其所需的技能和技能掌握水平进行定义，从而明确企业架构过程中相关角色的职责和要求，并借此遴选合适的专业人员。TOGAF的架构技能框架便为这一目标的实现提供了参考和指南
在前面的叙述中我们应该已经了解到，企业可以通过应用企业架构开发方法（ADM）来为其建设各种业务能力，而如果把视界放开一点，我们会发现企业架构开发方法可以应用到企业中任何能力的建设方面，这当然也包括架构能力。在架构能力的建设中，对于架构开发方法的成功运用可以使企业获得一个可持续并以客户为中心的增值型架构实践，从而帮助企业达成其各项业务目标、最大化投资价值，并能够明确各种获得业务利益和管理风险的机会。不过这一架构实践的建设并不是一个一次性的项目，而应该是一种持续性的实践过程，从而为组织中其他架构的交付提供环境和资源。
在TOGAF的眼中，任何一种企业能力的建设都需要对如下四种领域进行设计，这当然也包括针对这一可持续性架构实践建设：
业务架构：此领域中的内容突出了架构治理、架构流程、架构组织结构、架构信息需求以及架构产品等方面。
数据架构：此领域中的内容定义了组织中架构连续体和架构资源库的结构。
应用架构：此领域中的内容描述了用于支持此可持续架构实践的功能和/或应用服务。
技术架构：此领域中的内容描述了此架构实践中用于支持各架构应用和企业连续体的基础设施需求和部署方式。
TOGAF对于这一可持续性架构实践的建设有着更加详尽的指南，在本节的后续部分中我们将以架构开发方法各阶段为基础来对企业架构能力的建设进行进一步探讨。
此阶段的目的在于定义或审查这一架构实践的愿景、干系人和原则。TOGAF对于此过程的具体步骤做了如下建议：
明确业务差距和业务驱动力：对业务目标和驱动力的了解对于促成此架构实践和业务之间的协调是非常重要的。
审查架构原则（包括业务原则）：此步骤的意图在于定义用于治理和指导这一架构实践运行的各种原则。与通常的架构原则用来治理架构交付物所不同，架构实践原则将被用来明确架构实践的组织、内容、工具和相关流程。
开发架构工作说明书和安全认证。
另外一个需要在此阶段被考虑进来的步骤是进行架构成熟度评估（请参阅2.4.4.6架构成熟度模型部分的描述）。
架构本体论（Architecture Ontology）：定义了各种架构的术语和定义，用于在组织中建立起关于这些内容的共识。
架构流程（Architecture Process）：以架构开发方法为基础并按照组织的需要和架构实践的愿景来对架构开发方法所进行的定制，并且所需的架构治理流程也应该被包含到整个架构流程之中。
架构视角和视图（Architecture Viewpoints and Views）：列举出所有架构实践所涉及到的视角和视图，而针对这些内容的定义工作应由此前被识别出来的架构实践干系人来进行指导。
架构框架（Architecture Framework）：描述了将会由架构实践所产生的各种架构交付物以及他们之间的交互、依赖关系，此外还包括了种种用于管理这些交付物的设计的规则和指南。那些在之前被定义的架构视角和视图也应该被用来指导架构框架的定义
架构问责矩阵（Architecture Accountability Matrix）：定义了架构实践所涉及到的各种角色，以及为这些角色所分配的关于架构交付物和流程的责任。
架构性能指标（Architecture Performance Metrics）：明确和描述了用于与架构实践愿景和目标进行比对和监督的各项架构实践性能指标。
架构实践的数据架构对组织的企业连续体和架构资源库进行了描述和治理。数据架构的定义应该基于组织所选择的架构框架，并且有时也被引用为架构实践的元模型。
架构实践的应用架构定义了用于产生、维护、发布、分发以及治理架构交付物的各种功能，而这其中一个关键点在于用来建模的各种建模工具组。
架构实践的技术架构应该对用于支持架构实践的技术基础设施进行定义。
此阶段需要对架构实践中各种架构的变更进行管理，而这些变更通常是在各个架构项目的执行过程中被触发的。一个典型的变更往往会成为对于新架构交付物的需求，并会对架构实践中的所有架构领域产生影响。
了解和管理架构实践的需求是非常关键的，并且这些需求需要被清晰地描述出来，并与架构实践愿景相一致。
简单来讲，企业架构能力是指企业对于其内各种架构的建设能力，而这里所说的建设能力不仅指的是企业中各架构的实现，而且还需要保证架构的实现是处在一个透明且受控的环境之中，从而使架构的建设得以正确进行。架构能力中有关这种保障架构建设和交付的内容就是架构治理（Architecture Governance），而这也是架构能力中最为核心的部分。
无论何种企业总有其需要进行管理的地方，因而即便是没有涉及到任何架构的企业也总会有着针对其他方面的治理体系，这也注定了架构治理必定不会独立并隔绝地存在着，而应该存在于一个层次化的治理结构之中，这对于大型企业来讲尤其重要。按照所处领域的不同，TOGAF将这一层次化的治理结构划分为如下四种，其中的每一种都具有其各自的规则和流程，并且可以存在于多个地理区域层次之上（包括全球、地区和本地这三种地理区域种类）：
公司治理（Corporate governance）
技术治理（Technology governance）
IT治理（IT governance）
架构治理（Architecture governance）
以上这几种治理体系之间并不是绝对隔离的，不同的治理体系所包含的活动和行为多少都会有所交叠，但由于其所面对的领域各不相同，其管理的范畴以及所具备的规则、流程和活动具有很大的差异性。由于公司治理、技术治理和IT治理的内容范畴超过了一个企业架构框架理论内容范围，TOGAF中相关部分的描述重点还是放在了架构治理这一方面，不过它对治理的共性以及技术治理和IT治理还是做出了简要的描述。
在进一步介绍架构治理之前，我们需要对“治理”这一概念有一个清晰的认识。这里所说的治理并不像其字面上那样，仅仅代表显式的管控和对于规则的严格遵守，而是更加倾向于为有效且公平的使用各种资源提供指南，从而确保组织的战略目标的可持续发展。根据所处领域不同，在前面提到过治理可以被细分为若干治理层次，但无论其种类为何，“治理”的最终目标在于确保业务得以顺利进行，并且在这些种类不同的治理都遵循着相同的原则。经合组织（OECD：Organization for Economic Co-operation and Development）曾经针对这些基础共通原则做出了如下概括：
信息披露、透明度和委员会的责任。
确保组织中良好的战略指南。
确保委员会进行有效管理监督。
委员会的责任包括：
审查和指导战略。
设置并监督管理绩效目标的进展。
除了这些共同原则之外，TOGAF还概括出了治理的各种共同特性，用以突显治理作为一个被组织在其内以及与其他有关团体之间所采用的方法的价值和必要性：
纪律性（Discipline）：所有牵涉的团体需要承诺遵循由组织建立的各种程序、流程和权利结构。
独立性（Independence）：所有流程、决策制定以及所采用机制的建立应最小化或避免潜在的利益冲突。
责任性（Responsibility）：每个签订契约的团体需要对组织以及他们的干系人采取负责任的行为。
公平性（Fairness）：所有的决策、使用的流程以及针对他们的实现不应对任何团体产生不公平的利益。
在前面提到过的四种领域中的治理除了具备上一节所述的共同原则和特性之外还分别具备各自的特点。由于公司治理的内容范畴超过了一个企业架构框架所应覆盖的范围，所以在这里并不会进行专门的描述，而接下来我们将针对其余的三种治理体系，亦即技术治理、IT治理和架构治理，分别进行描述。
技术治理控制了一个组织如何将技术应用于针对其产品和服务的研究、开发和生产之中。技术治理与IT治理关系非常紧密，而且技术治理往往会涵盖IT治理中的各种活动，但技术治理的内容范畴则更为广阔。在现代企业中，越来越多的组织将注意力的重心逐渐放到无形资产之上，而不是仅仅关注于有形资产管理。由于大部分无形资产是信息化或数据资产，这正说明现代企业的业务与IT之间的关系也越来越紧密，因而针对IT的治理（亦即IT治理）也成为技术治理的一个重要组成部分。这一针对无形资产逐渐重视的趋势同时也突显了企业的业务不仅仅依赖于信息本身，还依赖于用于产生、交付和使用这些信息的各种流程、系统和结构。此外，随着无形资产价值比重在各个行业中的不断攀升，风险管理也需要作为一个重点而加以考虑，从而使得新的挑战、威胁和机会能够得以被理解和缓和。
需要注意的是，不仅仅是组织的运营和盈利越来越依赖于IT，组织的声誉、品牌以及最终他们的价值也都依赖于这些信息和支持技术。
IT治理为IT资源和信息与企业目标和战略之间的联系提供了框架和结构，并且IT治理为规划、采购、实现和监督IT绩效指定了各种最佳实践，从而确保企业的IT资产对其业务目标的支持。
架构治理是为了在全企业范围内对企业架构以及其他各种架构进行管理和控制而需要借助的各种实践和方向，它具有如下几个方面的特性：
实现一个系统来控制所有架构组件和活动的创建，并对它们进行监督，从而确保在组织内有效地引入、实现各种架构，并保障这些架构的顺利演进。
实现一个系统用于确保各种架构对于企业内外的标准和法律法规的遵守。
建立各种流程，用于在已达成共识的各因素的约束之下，对上述流程的有效管理进行支持
开发各种实践，用于在组织内外确保对于一个经过清晰定义的干系人团体的问责性。
在前面有关企业架构开发方法的介绍中，我们已经在“实施治理”阶段见过了“治理”一词。这个阶段所关注的是通过各个变更项目来对架构进行实现，因而此阶段的治理仅仅是关于架构实现这一方面，不过对于架构治理来说，这一实施治理只是一个非常重要的方面，架构治理的范畴要更为广阔，它涵盖了针对企业架构以及其他各种架构在其开发和演进过程中所有方面的管理和控制。作为一个企业架构框架，TOGAF为支持架构治理的实现提供了一个架构治理框架（Architecture Goverance Framework），用于帮助企业明确各种有效的治理流程，从而使得与架构治理相关联的各种业务职责得以被鉴别出来，并能够对其进行有效地管理和沟通。
架构治理框架的概念结构包含了架构治理中的种种概念，这其中最为重要的是对一个有效的架构治理所应具有的各种流程以及与它们相关的内容所进行的定义。这一架构治理的概念结构采用了一种内容无关的方式，将流程、流程所涉及的内容以及背景元素进行了分离，从而使得新的治理材料的引入不会过度地影响到各个治理流程，同时也保证了这一治理框架的灵活性。
上图展示了架构治理框架的概念结构，其中涵盖了这一框架中的各种概念，而这其中最关键的是与治理流程有关的各种概念。治理流程被用来识别、管理、审计和传播所有与架构管理、合同和实现相关的信息，从而确保对所有架构制品、合同、原则以及运营级别协议（operational-level agreements）进行持续地监督，并且所做的各项决策也具有了清晰的可审计性。这些治理流程相关的概念总结如下：
策略管理与内容引入（Policy Management and Take-On）：为了注册、验证、批准、管理和发布新的或经过更新的内容，所有针对架构修订、合同和支持性信息的引入都需要处在一个正规流程的治理之下。这些流程将确保与现存治理内容的有序整合，从而使得所有相关的团体、文档、合同和支持信息得以被管理和审计。
合规（Compliance）：针对服务水平协议（SLAs：Service Level Agreements）、运营水平协议（OLAs：Operational Level Agreements）、现行各项标准和法规需求的合规性评估需要在一个持续的基础上进行，从而确保针对稳定性、一致性和性能的监督。这些评估的进行需要以在治理框架中所定义的各项标准为准绳。
豁免（Dispensation）：当主题域（设计、运营、服务水平或技术）的内容在合规性评估中被判为不合规时，该部分内容将可能会被否定，而此时将会存在如下几种处理方式：
对这些不合规内容进行调整，从而使其满足合规性需求。
申请一份豁免。当合规评估未能通过时，豁免就成为了一条用来达成临时性一致的备选路线。豁免只会存在于一段时间区间内，并在其整个生命周期内被强制设置明确的服务和运行条件。豁免并不会永久有效，它只是被用来作为一种在确保服务水平和运营水平得以满足的同时附加一定水平的灵活性的机制。豁免的时限性特征确保了它们是合规性评估循环的一个主要触发因素。
监督和汇报（Monitoring and Reporting）：性能管理被用来确保运营和服务元素的管理是基于一系列经过协定的标准之上，这包括了监督服务水平和运营水平协议、对于调整的反馈以及针对这些结果的汇报。
环境管理（Environment Management）：明确了各种服务，这些服务确保了以资源存储库为基础的环境对治理框架进行支持是有效且高效。这包括了针对所有用户的物理和逻辑资源存储库的管理、访问、沟通、培训和评审。为了形成一个受管的服务和流程环境，治理环境中将会定义一些管理流程，这些流程包括了用户管理、内部服务水平协议（为了控制这些管理流程本身而定义）以及针对管理信息的汇报
在架构治理框架的概念结构中，TOGAF以一种内容无关的方式明确了一个有效的治理所涉及的各种概念，并借此概括了各种架构治理流程以及与这些流程相关联的各种内容，但如果要确保一个架构治理的顺利进行，还需要在企业中设立专门负责治理举措施行的组织结构。在实践中凭空创建这些用于架构治理的组织结构其实是不现实的，企业应该组合现有的各种IT治理流程、组织结构和能力来对其进行创建。通常来讲，企业中的治理组织结构可被分为如下几个层次：
全局治理委员会
本地治理委员会
设计部门
工作组
TOGAF提出了如下图所示的治理组织结构，各个企业可以按照各自的需求以此图所示的组织结构为基础而进行改造：
如图所示，架构治理框架的组织结构可以被分为三个重点区域，他们分别是：开发（Develop）、实现（Implement）和部署（Deploy），它们中的每一个都代表了在架构生命周期的每一个阶段中各个相关小组所应尽的责任。尤其是对于开发区域来讲，这里的开发责任、流程和组织结构都与架构开发方法过程有着紧密的关联，而对于实现区域来讲，其所包含的实施责任、流程和组织结构与架构开发方法的实施治理阶段也是密不可分的：
在开发区域中，架构委员会（Architecture Board）对主架构师进行任命，并且通过两者的合作来对企业架构的设计和落实进行指导，并最终将企业架构细化成为各个面向具体问题的领域架构。
在部署区域中，由于各个架构实现项目的实现和部署改变了企业当前的运营状态，因而受管理办公室委派的服务管理组织（Service Management Organisation）需要对企业的各运营系统进行监督，从而发现新的问题和需求，并借此启动新的一轮架构开发循环。
除了以上这三个核心区域之外，我们还应注意到企业连续体的再次出现。企业连续体之所以会在这里出现是因为它是架构治理的一个不可或缺的部分，因为它不仅承载了与架构相关的各种内容，也同时存储了与架构治理过程相关的种种材料。
在实践中，为了实现一个成功的架构治理方法，并对架构合同进行有效的管理，企业需要考虑如下几个关键因素：
用于支持架构治理的流程以及达成汇报需求的组织结构及其责任。
对各种工具和流程进行整合，从而便于在程序上和文化上执行各个流程。
除了上面几项对于架构治理成功因素的描述，TOGAF还指出了一个在企业中获得接受和成功的架构所应具备的三个主要的架构治理战略元素：
需要在最高管理层的支持下建立一个跨组织的架构委员会（Architecture Board，见2.4.4.3架构委员会）来对IT治理策略的实现提供监督。
需要建立一套全面的架构原则，从而对组织如何通过使用信息技术来完成自身的任务而进行指导和支持。
需要采用一种架构合规性策略（见2.4.4.4架构合规性），从而通过具体的措施来保证架构的合规性，这包括了项目影响评估、正式的架构合规性审查流程，同时也可能包括在产品采购过程中架构团体所进行参与。
正如前面所说，一个用来对架构治理策略的实现进行监督的跨组织的架构委员会是架构治理策略成功的主要要素之一。架构委员会应该能够代表所有主要干系人的需求，并且通常还需要对整个架构的审查及维护活动负有高级行政职责。通常来讲，架构委员会需要对如下目标的达成进行负责：
子架构之间的一致性。
确定可重用组件。
保证企业架构的灵活性：
满足不断变化的业务需求。
尽可能的利用不断出现的新技术。
严格确保架构合规性。
改善组织中架构规程的成熟度水平。
确保采用以架构为基础的开发规程。
为所有关于架构变更的决策提供基础。
为超出范围的决策提供升级的能力。
如果从执行的角度来看，架构委员会还需要承担如下责任：
有关架构合同的监督和控制的所有方面。
定期举行会议。
确保针对架构进行有效并且一致地管理和实现。
解析不清楚的地方，并对各种问题以及已经升级了的冲突进行解决。
提供各种建议、指导以及信息。
确保各种架构的合规性，并在确保与技术战略及目标一致的基础上授予豁免。
当相似的豁免被申请并被通过时，架构委员会需要考虑进行策略变更。
对汇报的服务水平、成本节约等方面进行验证。
如果从治理的角度来看，架构委员会还需要承担如下责任：
产生各种可用的治理材料和活动。
为确保架构的有效实现而提供一个基本控制机制。
在架构的实现、包含在企业架构中的架构战略和目标，以及业务的战略目标之间建立关联，并对其进行维护。
为了通过豁免或策略更新来进行调整，架构委员会需要明确架构与计划开展的活动之间的差异。
一个架构委员会的建立往往受如下事件的触发：
新CIO的任命。
兼并或收购。
考虑采用一个新的计算形式。
认识到IT与业务的契合度很差。
渴望通过技术来达成竞争优势。
一个企业架构方案的创建。
重大的业务变更或业务的快速发展。
需要复杂且跨越诸多功能的解决方案。
在很多公司中，最初的领导级架构赞助者通常都是CIO，然而为了在企业中获得广阔的支持，一个赞助组织的影响力往往超过某个个人，这样一个赞助组织在这里被称为一个架构委员会。架构委员会是一个高级领导层组织，用来为战略架构及其子架构的审查和维护进行负责。虽然架构委员会是企业中架构的赞助者，企业架构委员会自己本身也需要获得企业高层的赞助和支持，并且这一支持需要贯彻整个规划过程，延伸到针对架构项目的维护之中。
架构委员会的常驻人员规模不宜过大，按照TOGAF的建议，一个架构委员会的常驻人员规模应包含四至五人，或不超过十人。为了使架构委员会随着事件的推移而一直保持合理的规模，并同时确保其在企业范围内的代表性，架构委员会的成员需要采用轮换制，从而给予各个高级经理决策权和相关责任。除此之外，由于现实中的各种原因这一轮换机制还有其存在的必要性，例如当有些架构委员会成员受时间所限而不能长期承担其职责时。虽然采用了轮换制，但为了确保架构委员会的决策不会变化无常，企业需要主动的采用某种机制来确保其核心理念的稳定，例如为成员设置任期，并将不同成员的离退时间交错开来。
架构委员会的运行的核心以及在形式上的表现就是按照清晰的日程安排所进行的架构委员会会议，并且这些日程安排需要具有明确的目标、所涵盖的内容和经过定义的行为。架构委员会会议需要为如下几个方面提供指导：
对高质量的治理材料和活动的产生进行支持。
为确保有效的架构实现提供一个基本控制机制。
在架构的实现、包含在企业架构中的架构战略和目标以及业务的战略目标之间建立关联，并对其进行维护。
为通过豁免或策略更新来与合同进行重新校准而对合同和规划活动之间的差异进行明确。
每个会议的参与者在开会前会收到一份日程描述和相关支持文档，他们需要在开会前对这些内容进行熟悉，并且被分配进行某项活动的与会人员还需要报告其执行进度。此外，每个与会人员还必须确认其是否参加架构委员会会议。
由此可见，会议的日程描述是有关整个会议内容的核心，TOGAF对于其内容项目做了如下建议：
前期会议纪要：以前的架构委员会会议的详细纪要。
变更请求：此条目之下的内容通常包含了针对架构、原则等内容进行修订的变更请求，此外也可以包含对于架构合同的业务控制（例如，确保针对某一付费号码的语音流量（例如天气预报）被禁止，以及对于某一特定网站进行访问的数据流量需要被控制）。任何一个变更请求的设置需要在制定者的授权范围之内，并采用在架构合同中已经定义好的参数。
合规性评估：合规性的评估是针对服务水平协议、运营水平协议、成本目标等方面而进行的。根据在架构治理框架中定义的条件标准，通过审查后，这些评估结果或者被接受亦或者被拒绝，并且架构合规性评估报告还应包含所描述的各个细节。
争议解决：经过架构合规性审查和豁免过程而依然未被解决的争议需要在这里被明确，从而为下一步的行动提供目标，并且这些内容需要被记录到架构合规性评估和豁免文档之中。
架构战略和方向文档：这里所描述的内容仅被全局架构委员会所制定，它包含了架构的战略、方向及其优先级顺序。
行动分配：这是一个关于前期架构委员会会议所分配行动情况的报告。在此报告中，一个行动跟踪记录被用来记录和保持所有在架构委员会会议中被分配的行动的状态，其内容至少应该包含如下几个方面：
参考材料
优先级
行动概述
行动所属者
行动详细描述
开始日
到期日
状态
类型
决议通过之日
合同文档管理：这是为架构文档的后续发布而对其进行的有关更新和改变的正式认可。
其他事项（AOB：Any Other Business）：关于上述内容所没有覆盖的问题的描述。这些内容也许不会被描述在会议日程之中，但应该在会议开始时被提出。
针对架构合规性的审查是架构治理战略的核心环节，也是决定其能否成功的重要因素。架构合规性审查是针对各个具体项目与已经建立的架构标准、精神以及业务目标的相符合情况所进行的审议，而一个关于这些审议的正规流程正是企业的架构合规性策略的核心内容。通过架构合规性审查，企业可以达成如下几点（或部分）目标：
首先且最重要的目标是企业得以尽早在项目架构中发现错误，从而减少在整个生命周期的后期进行更改的风险和成本，而这也意味着整体的项目时间得以缩减，并且各项业务也能够尽早地获得架构所带来的底线收益（bottom-line benefit）。
确保将各种最佳实践应用到架构工作当中。
提供一份关于架构与强制性企业标准的符合度的概略。
明确标准本身需要进行修改的地方。
明确能够作为企业基础设施的组成部分，却在当前只为特定应用提供支持的各个服务。
将关于团队合作、资源共享以及其他能够跨越多个架构团队的协同增效方面的战略进行文档化。
充分利用技术所带来的先进性。
对项目的技术准备状态进行沟通。
确定采购活动的关键标准。
明确重大的架构性差距，并就此与产品和服务供应商进行沟通。
除了上面这些与质量保证有关的目标之外，架构合规性审查的进行还在特定情况下具有着倾向于以政治为导向的动机：
由于具有决策能力的人通常会参与到审查当中，并能够从对业务最优的角度进行决策指导，而不仅仅注重技术的优劣，这使得架构合规性审查成为了一种在各种架构选择之间进行选择的好方法。
架构合规性审查的输出是为数不多的用来汇报给CIO，并辅助其决策制定的可测性交付物之一。
架构审查可以作为一条架构组织借以参与到开发项目之中的途径，否则各个开发项目的进行将会与企业的架构功能相脱节。
架构审查可以为企业业务团体给出快速且正面的支持：
企业架构以及架构合规性可以帮助确保各IT项目与业务目标的符合度。
架构师有时可以被视为深入到技术基础设施之中而远离核心业务之外。
由于架构合规性审查倾向于将主要注意力放到一个系统的关键风险区域内，所以此审查经常可以为系统所有者凸显各种主要的风险。
架构合规性审查并不是一个一次性的活动，它应该在适当的项目里程碑或项目生命周期的各个检查点进行，并且其具体的审查要点应包括：
架构开发自身的合规性，亦即对于架构开发方法的符合度。
架构实现的合规性，亦即各个实施项目与架构的符合度。
针对架构项目审查的时点应包括：
项目启动
初步设计
主要设计变更时
其它特定时刻
就架构合规性审查的进行、治理以及参与的人员来说，TOGAF针对此审查的进行总结出了如下三种情景：
对于小规模的项目，这一审查流程可以只是由项目架构师或项目组长制定一系列问题（可以通过对后面将要列出的问题清单进行定制而获得），再将答案收录到某种形式的报告中，并对其进行管理。进行这样一个流程的需求通常要被包含在整个企业范围的IT治理策略中。
如果处于审查之下的项目并没有一个全职的架构师的参与（例如，一个应用级的项目），那么就需要借助于企业中具有架构功能的组织的专业性架构能力了。这种情况下，企业架构功能组织将负责对这一审查进行组织、领导和执行，并保证各业务领域专家的参与。需要注意的是，这样的审查并不是要取代架构师对于项目的参与，而是对架构师参与的一个有效的补充。此外，在这种情景下也许还需要引入一套数据库系统，从而对在大型系统或系统组的分析中所产生的大量数据进行管理。
对于大多数情况来说，尤其是对于大型项目来说，组织中具有架构功能的组织可能已经深入地参与到（或领导）处于合规性审查之下的开发项目之中。在这种情况下，这一审查应该由主架构师来进行协调。主架构师需要组织一个包含业务和技术领域专家的团队，并将合规性审查中各个问题的答案编织成某种形式的报告。合规性审查中各个问题的制定需要由各个业务和技术领域专家一起来执行。除了由主架构师领导之外，架构合规性审查也可以由架构委员会的代表或其他在全企业范围内具有相似能力的组织来领导。
在上面这些情景中，架构合规性审查的进行都需要高级管理层的支持，并通常被作为企业架构治理策略的一个重要部分来加以强制。一般来讲，企业的CIO或企业架构委员会将对所有主要项目进行强制性审查，并在之后形成年度审查的惯例。
TOGAF对于架构合规性审查的流程做了如下图所示的总结：
角色
职责
备注
架构委员会
确保IT架构的一致性，并能对所有业务目标进行支持
赞助并监督架构活动
项目组长
（或项目委员会）
为这个项目负责
架构审查协调人
管理整个架构的开发和审查流程
更倾向于面向业务，而不是技术
首席企业架构师
确保架构在技术上的连贯，并且是面向未来的
一个IT架构专家
架构师
首席企业架构师的技术助理之一
客户
确保业务需求被清晰地描述和理解
管理组织的一部分，该部分依赖于在架构中所描述的信息技术的成功实现和运用
业务领域专家
确保用于满足业务需求的流程是合理并能够被理解的
了解业务领域的运作。可以通过客户来担当这一角色
项目负责人
确保架构师对于客户部门流程有着足够详细的理解，并能够为业务领域专家或架构师提供各种所需的输入
能够为架构所要满足的业务需求提供输入的客户组织中的成员
架构合规性审查是针对各个项目与架构的符合度而进行的审议活动，而这一活动的具体实施需要围绕着一份问题清单来进行的。为了帮助这一份问题清单的制定，TOGAF根据架构的各个方面提出了一系列备选问题，而负责问题清单开发的领域专家可以根据所审查架构的特性在这些备选问题中进行选择和定制。需要注意的是，这里所列出的问题并不适用于针对业务领域架构或跨越多个项目的架构的审查。针对这些架构的审查的流程虽然相似，但是其所使用的问题清单的类别和内容将会有所不同。（有些问题并不是以提问的形式出现，而是通过简短的描述来对引发问题的缘由，以及答案中所应包含的内容方向进行了阐述，从而使得相关人员可以按照各自情况编制出合适的问题）
项目生命周期方法是什么？
项目目前处在生命周期的哪个阶段？
已经被明确的或被用作分析的，在项目中用来对网络、服务器以及终端设备的硬件和操作系统进行评估的关键问题是什么？
将要参与到大量和/或高频率数据传输中去的系统能力是什么？
系统设计是如何影响或涉及到终端用户设备的？
所进行的使用、数据存储和处理的数量及分布（地区性和全局性）是什么？
通过对比数据、应用服务等方面的相似性，应用与项目的关联有哪些？并且数据与项目的关联程度为何？
在系统关键元素的功能性设计之前就已经做出的关于硬件和操作系统的选择是什么？
是否关于硬件和操作系统的决策制定超出了项目的控制？
项目对于那些决策的理由有什么样的认识？
当系统设计成型时，项目是如何影响那些决策的？
是否选择了非标准化的内容？
不使用公司标准的关键业务和技术需求是什么？
是否被业务案例所支持？
在业务案例中的假设是否已被审查？
用于评估硬件和操作系统的全生命周期成本的流程是什么？
公司财务管理是如何被引入到生命周期成本评估中去的？
是否进行了供应商的财务分析？
是否对供应商提出了承诺？
是否坚信需求仅被一个供应商所满足？
描述错误条件是如何在应用组件之间被定义、产生和传播的。
描述在各个应用模块中关于方法定义和排列的通用模式。
描述在各个应用模块中关于方法参数定义和排列的通用模式。
描述用来最小化服务器和客户端之间调用次数的方法，这对于在进程间进行具有复杂数据结构的调用尤其重要。
描述在主要系统组件之间进行传递的主要数据结构。
描述在主要系统组件之间进行通信所采用的协议。
描述在不同系统组件之间所使用的编组（marshaling）技术，并针对所使用的特定编组安排进行描述。
描述系统在多大程度上设计有状态（stateful）和无状态（stateless）组件？
针对有状态和无状态组件来描述如何以及何时进行状态保存。
相比于对象池中对象的重用，描述在什么范围内对对象进行创建、使用和销毁。
描述系统依赖于线程或临界区代码的程度。
描述在系统内部用来记录方法、方法参数和方法功能的方式和内部文档。
描述代码审查流程。
描述用来测试系统组件的单元测试。
描述包含在各种系统模块中的前置和后置条件测试。
描述包含在系统中的断言测试。
各个组件是否具备了它需要支持的所有接口？亦或某些关于何种类型组件采用语言绑定或其它形式的编组（marshaling）方式来调用其它组件的假设是否被制定？
描述在何种程度上对跨平台的大字节或小字节数据格式问题进行了处理。
描述在不同平台上是否对数字和字符串的处理采用不同的方式。
描述是否软件需要对浮点舍入误差进行检查。
描述何种工具和流程被用来就内存泄漏、可达性（reachability）或一般鲁棒性（general robustness）来对系统进行测试的。
描述系统服务软件的分层情况。描述主要系统组件之间的连接的一般数量。是否系统大量采用点对点方式进行联系，还是主要通过消息路由的方式？
描述系统组件松耦合或紧耦合的程度。
就共享库、通信协议支持、负载平衡、事务处理、系统监控、命名服务或其它基础服务来讲，系统对于底层基础设施的需求是什么？
描述系统和系统组件是如何通过设计来达成重构性的？
描述相对于采用点对点的通信结构，系统或系统组件是如何依赖于通用消息基础设施的？
基础设施应用
是否需要一些企业标准基础设施应用产品并没有提供的能力？例如：
团队协作方面：
应用共享
视频会议
日程安排
电子邮件
工作流管理
出版/文字处理应用
HTML
SGML和XML
可移植的文档格式
文档处理（专有格式）
桌面发布系统（Desktop publishing）
电子表格应用
展示应用
业务展示
图片
动画
视频
音响
基于计算机的培训系统（CBT：Computer-Based Trainning）
Web浏览器
数据管理应用
数据库接口
文档管理
产品数据管理
数据仓库/集市
项目管理应用
项目管理
项目可见度（Program visibility）管理
描述标准产品所不能满足的对于企业基础设施应用能力的业务需求。
业务应用
是否用于支持一条或多条业务线应用的标准产品提供了所需要的能力？例如：
业务采购应用：
销售和市场
工程应用
计算机辅助设计
计算机辅助工程
数学和统计分析
供应管理应用
供应链管理
客户关系管理
生产应用
企业资源规划（ERP）应用
制造执行系统
制造质量
制造工艺工程
机器和自适应控制
客户支持应用
航空物流支持
维护工程
财务应用
人员应用
设施应用
信息系统应用
系统工程
软件工程
Web开发工具
集成式开发环境
生命周期类别
功能类别
专业类别
计算机辅助生产
电子商务支持
业务流程工程
统计质量控制
描述标准产品所不能满足的对于业务应用能力的流程需求。
应用集成方法
架构的目标集成点（业务流程/活动、应用、数据、计算环境）是什么？
所采用的应用集成技术是什么（通用数据对象、标准数据定义（STEP、XML等）、通用用户界面展示）？
数据价值方面
用于对数据的管理和使用进行标准化的流程是什么？
用于支持数据录入和验证的业务流程是什么？数据的用处为何？
业务用户对于数据质量的需求是什么？
当前用于支持数据引用完整性和/或规范化的流程是什么？
数据定义方面
所购买的应用的数据模型、数据定义、结构以及主机选项（hosting options）都是什么？
用于定义和维护数据需求规则以及对信息系统中所有组件所进行的设计是什么？
何种共享资源库被用来保存数据模型内容和数据的支持性信息？
用于设计数据库的物理数据模型定义是什么？
所选择的软件开发和数据管理工具是什么？
已明确的对如下事项进行负责的数据拥有者都有哪些？：
通用数据定义
计划外冗余的消除
稳定可靠性的提供
信息的及时性和准确性
防止数据被滥用和破坏
安全/保护方面
采用何种机制来控制企业内部临时驻留性外部资源对于数据的访问？
托管、数据类型和共享方面
已经明确的用于储存高级或中级重要度的运行数据的层级数据服务器为何？
已经明确的用于储存C类型运行数据的层级数据服务器为何？
已经明确的用于储存包含在一个数据仓库中的决策支持数据的层级数据服务器为何？
所实现的数据库管理系统为何？
通用服务
标准化的分布式数据管理服务（例如，数据验证、一致性检查、数据编辑、加密以及事务管理）为何？这些服务存在于何处？
访问方法
对于标准文件、消息和数据管理的数据访问需求为何？
对于决策支持数据的访问需求为何？
数据存储库和应用逻辑位置为何？
采用何种查询语言？
安全意识：
是否已确保正在使用的公司安全策略和导则是最新的版本？
是否已经阅读了最新版本的公司安全策略和导则？
识别/认证：对于一个用户是如何被应用所识别，以及此应用是如何验证该用户确为其所声称那个人的过程流进行图形表述。对这一图形表述提供支持性文档，从而对用户界面和应用/数据库服务器之间的交互流程进行解释。是否符合公司关于账户、密码等方面的策略？
申请是如何被适当的数据拥有者所批准？
用户是如何被归入到适当的访问级别分类设定档中的？
用户账号、密码和访问是如何建立的，并如何提供给用户的？
如何通知用户对于应用的使用责任？
如何变更密码？
应向谁请求帮助？
其他。
访问控制：记录用户的账户、密码和访问配置是如何被增加、更改、删除和记录的？这一文档还应该包括对这些流程进行负责的人员。
敏感信息保护：提供确定了需要额外保护的敏感数据的文档。明确对这些数据进行负责的数据拥有者，以及用来保护数据存储、传输、打印和分发的流程。这包括：
如何对密码文件或字段进行保护？
如何防止用户查看他人的敏感信息？
与外部团体之间是否具有着信息保护的协议？如果是，具体责任和义务为何？
审计跟踪和审计日志：
明确并记录被多个用户或应用支持所需要的组账户。
明确并记录个人账户和/或具有超级用户权限的角色。
这些权限为何？
何人可以访问这些账户？
如何对这些账户的访问进行控制和跟踪，以及如何对其进行日志记录？
如何处理密码的变更和分发？
明确审计日志：
何人可以读取审计日志？
何人可以修改审计日志？
何人可以删除审计日志？
如何保护和存储审计日志？
用户账户在审计日志中是否记录不清？
外部访问注意事项：
是否应用只是内部使用？
如果不是内部使用，那么是否符合公司的外部访问需求？
必须被分发出去的软件更新的频率为何？
采用何种工具进行软件分发？
是否在产品中允许使用多个软件和/或数据版本？
如何对用户的账户进行创建和管理？
需要采用何种通用系统管理工具？
需要采用何种特定的服务管理工具？
如何接受和发送服务调用？
描述如何卸载系统。
描述用于检查系统是否被正确安装的流程或工具。
描述用于监督系统健康状况和性能的工具或仪器。
描述用来确定系统被安装在何处的工具或流程。
描述用于捕捉系统历史（特别是在一次意外发生之后）的审计日志的格式。
描述系统将其错误消息发送给服务人员的能力。
一般性问题
需要整合进来的其他应用和/或系统为何？
描述集成度水平和战略。
用户群的地理分布为何？
系统对于其他企业内外用户团体的战略重要性为何？
需要什么样的计算资源来为企业内的用户、处于企业外并使用企业计算资产的用户，以及处于企业外并使用他们自有资产的用户提供系统服务？
处于本地交付环境之外的用户如何访问企业的应用和数据？
当前应用的平均寿命为何？
用户群的规模以及他们的期望性能水平为何？
采用何种性能和压力测试技术？
软件和数据组件的整体组织方式为何？
整体的服务和系统配置为何？
软件与数据是如何被配置和映射到服务及系统配置之上的？
此系统需要何种专门的软硬件技术？
描述当前的用户群，以及在之后的三到五年中对其变化的预期。
描述当前的用户群地理分布，以及在之后的三到五年中对其变化的预期。
描述在当前或未来需要通过移动或离线方式来对应用进行使用的用户数量。
描述应用的通常行为、其主要组件以及主要的数据流。
描述包含在应用中并用于监督其健康和性能状况的仪器。
描述系统的业务缘由。
从初始开发成本对比长期维护成本的角度出发，描述选择系统开发语言的理由。
描述用于产生系统架构及其产品选择阶段的系统分析流程。
除了原来的客户之外还有谁会通过对此系统的使用而获益？
通过浏览模式和更新模式来使用此系统的用户比例为何？
事务性的申请数量通常为多少？
是否需要严格保障的数据传输或更新？系统是否容错？
描述系统架构符合或不符合标准的地方。
描述运用在项目中的项目规划和分析方法。
处理器/服务器/客户端方面
描述客户/服务器应用架构。
通过标注图示来阐述执行应用功能的地方。
客户端方面
除了展示之外用户设备是否还具有其他功能？
描绘数据和流程所提供的帮助功能。
描述“从屏到屏”的导航技术。
描述用户如何在此应用与其他应用之间进行导航。
如何从用户设备上对此应用以及其他应用进行启动？
是否具有应用之间的数据和流程共享能力？如果是，描绘所共享的内容，以及采用何种技术来实现共享。
描述传输到客户端上的数据量。
对于支持应用的本地缓存数据的额外需求是什么？
对于支持应用的本地软件存储/内存的额外需求是什么？
是否存在由其他应用需求或会对用户产生影响的情况而导致的软硬件冲突或容量限制？
描述当前应用与其他现存应用之间展示层的感观效果的对比情况。
描述客户端在多大程度上支持异步和/或同步通信。
描述系统的展示层是如何与其他计算或数据传输层相分离的。
应用服务器方面
展示层和应用层是否可以运行在不同的处理器之上？
应用层和数据访问层是否可以运行在不同的处理器之上？
是否此应用可以被放置到一个应用服务器之上，并独立于其他所有应用？如不可以，则需要解释这些应用之间的依赖关系。
是否可以比较容易地添加额外的平行应用服务器？如果可以，负载平衡机制为何？
是否应用的资源需求被测量过了，且其值为何？如果已被测量，那么是否规划的服务器容量已在应用和总体级别上被确认了？
数据服务器方面
是否存在其他应用必须与当前应用共享数据服务器？如果是，则需要对这些应用进行明确，并描述其数据和数据访问需求。
是否应用的资源需求被测量过了，且其值为何？如果已被测量，那么是否规划的服务器容量已在应用和总体级别上被确认了？
商用现成品（COTS）方面
厂商是否稳定？
当厂商消亡时企业是否会收到产品源代码？
是否软件按照企业的用途而进行了配置？
是否存在特有的架构和设计方面的数据或流程，从而阻碍了针对软件的使用？
是否此软件在当前是可得的？
是否厂商使用或阐明的规模/可用性/服务水平与企业的需求相类似？
描述厂商过往的财务和市场份额历史。
是否具有对当前业务操作方法的评定指标？
系统拥有者是否已经创建了用于指导当前项目的评估标准？如果有，则对如何使用这些评估标准进行描述。
是否对于现存架构的研究已经完成，从而使得当前的工作成果能够得以被充分利用？描述在这一研究中所使用的发现和认识方法。是否现存的这些架构需要被整合？如果是，解释将会采用的方法。
描述将会应用到项目中的方法：
用于定义业务战略的方法。
用于定义需要改善的领域的方法。
用于定义基线和目标业务流程的方法。
用于定义过渡流程的方法。
用于管理项目的方法。
用于团队沟通的方法。
用于知识管理、变更管理和配置管理的方法。
用于软件开发的方法。
用于引用标准和方向说明的方法。
用于交付物的质量保证的方法。
用于设计审查和交付验收的方法。
用于达成指标的方法。
是否各个方法已被记录，并被分发给了每个团队成员？
团队成员在多大程度上熟悉这些方法？
采用何种流程来确保方法执行的符合性？
描绘当前所采用的用于支持方法使用的基础设施。
如何提供咨询和故障排除？
如何协调安排培训？
如何合并和关联各种变更和改进？
如何获取经验教训，并对其进行沟通？
关于项目所采用的工具为何？（指定版本和平台）。团队成员对这些工具的熟悉度为何？
描绘当前所采用的用于支持此工具使用的基础设施。
如何提供咨询和故障排除？
如何协调安排培训？
如何合并和关联各种变更和改进？
如何获取经验教训，并对其进行沟通？
描述项目如何促进对其交付物及所交付内容的重用。
在项目实现后此架构设计是否还会存续？描述用来将变更合并入此架构设计的方法。
当前流程是否被定义？
是否各种问题已经被记录和评定，并与当前流程关联起来？如果没有，那又如何得知已经出现问题的地方正在被修正？
是否现存或规划的流程改善活动已被明确，并与当前流程关联起来？如果没有，那又如何知道此活动与其他工作说明书中的内容不会发生冲突或相互冗余？
当前是否存在各种评估指标？当前是否存在预测指标？如果没有，那又如何得知获得了改善？
采用何种流程来收集、评估和汇报各种指标？
新的设计对于现存业务流程、组织结构和信息系统有什么样的影响？是否这些影响已经被记录到文档之中，并与其他干系人进行共享？
高风险区域。
预期的（突发的）差异。
对于清单中的每条问题，需要理解：
问题本身的含义。
问题背后的原则。
在回应中需要寻找什么样的内容。
寻求领域专家的意见。
根据自身需要对清单中的问题进行修补。
时刻牢记需要架构委员会的反馈。
理解审查的目标，并始终保持在正确的轨道之上对提出的问题提供适合的交付物。例如，人们通常希望了解正在架构的系统的对错之处，而不是希望了解诸如所采用的开发方法是否正确、管理组织结构是否合理等这些方面，因而在审查中就会经常偏离主题。
随着审查讨论的进行，其他一些需要被解决的问题将会逐渐显现，而且这些问题还常常会超出当前审查的范围。在这种情况下，我们需要在此次审查会后对其进行处理，并依照这些问题的重要性来制定一份用于解决这些问题的计划。
保持科学的态度。与其说“我们期望看到大型数据库放置在ABC之上而不放在XYZ”，我们更应该说“XYZ数据库环境之下的停机时间远远超过在ABC数据库环境之中的状况。因此我们不推荐将M和N系统放置到XYZ环境中”。
询问开放性问题。
在审查的征询过程中经常会存在隐藏的日程或有争议的问题，而这些内容在前期是无法预知的，因而采用一个非个性化的方法来进行讨论将会弥合这些差距而不是加剧他们。
尊重面谈的对象。他们可能不会采用合适的方法来构建系统，但是他们可能在其所处的环境中已经尽了最大的努力。
在练习中增长经验。
审查应该包括针对架构的详细评估活动，并确保其结果被存储到企业连续体之中。
架构合同是在开发团体和赞助者之间关于架构的交付物、质量以及适用目标的联合协议，并且通过有效的架构治理将会促使这些协议的成功施行。通过对合同的管理施行一个治理方法，如下几点将会得到保障：
明确存在于架构的开发、实现和运营中的各种风险。
一系列流程和实践得以被制定，从而保障针对所有架构制品的开发和使用的问责性、责任和规章。
对于为合同进行负责的治理组织、其权威等级以及它所负责的架构范围产生一个正式的理解。
在企业架构开发方法的各阶段中经常会见到架构合同的身影，例如架构愿景阶段中的架构工作说明书等。但无论是何种架构协议，我们都要牢记企业架构开发的终极目标是创建一个动态的企业架构，亦即该架构可以适应外界技术和业务环境的变化而灵活地演进，而架构合同对于促成这一动态企业架构的实现，以及针对此实现的治理是非常重要的。
此合同是一份为设计和开发企业架构而签署的意向说明，亦或是其中一个重要部分。此合同所涉及到的团队组织包括系统集成者、应用提供者和服务提供者。随着合作分工的逐渐细化，针对一个或多个架构领域（业务、数据、应用和技术）的开发已经越来越多的被外包出去，而企业架构组织则主要负责在整体上进行监督和协调，并且在有些情况下，这一监督性角色的任务也被外包到企业之外。但无论怎样安排这些外包任务，这些安排都需要在架构合同的治理之下来进行。这些架构合同定义了所开发架构的交付物、质量、适用目标以及架构开发团队之间进行合作的各种流程。通常来讲，这些架构的内容包括如下几点：
背景介绍
协议性质
架构范围
架构和战略的原则和需求
一致性需求
目标架构评测
针对交付物所定义的各个阶段
按照优先级排序的联合工作计划
架构交付和业务指标
当企业架构被实现之后，在架构功能组织（或整合了架构功能的IT治理组织）和业务用户（他们将会在所设计的架构环境中创建和部署各个应用系统）之间就需要达成一份架构合同（此合同还可以被用来在架构变更阶段中对企业架构变更进行管理），而这份业务用户架构合同（Business Users’ Architecture Contract）的内容通常包括如下几点：
背景介绍
协议性质
范围
战略需求
用于满足业务需求的架构交付物
一致性需求
架构采用者
架构业务指标
服务架构（包括SLA，即服务水平协议）
在企业架构开发方法过程的实施治理阶段中所产生的各种架构合同文档主要处于架构治理领域之中。在架构治理的背景之下，这些架构合同经常被用来作为驱动架构变更的一种手段。为了确保这些架构合同的效能，如下几个治理框架的方面需要被引入到实施治理阶段之中：
精简的流程
强有力的沟通
及时的反馈，以及有效的上报流程
专门用作支持的组织结构
针对架构实现进行状态跟踪
由于各个组织所处的环境并不是一成不变的，因而能够对这些变化进行快速反应并与之相适应的组织将会比那些缺乏应变能力的组织获得更大的优势。随着IT技术的日益发展以及与组织业务联系的日趋紧密，每个组织都知道为了管理所有可能出现的变化需要不断地改其与IT相关的开发流程，但对于很多组织来说，在哪些方面进行改进以及如何改进的确是个让人头疼的问题。所以在实践过程中，有的组织要么由于不知如何下手而投入过少，要么进行漫无目标的投入而导致投资回报率过低。那么各个组织如何才能解决这一问题，从而使得其所做的改进努力更加有目的性，并得到足够好的回报呢？其实这一问题的答案就是在组织中建立和运用能力成熟度模型（CMMs：Capability Maturity Models）。通过使用这些模型，组织可以得到如下效益：
这些模型描述了各种经过总结的实践，借此组织可以改进其流程。
这些模型提供了一系列衡量尺度，借此组织可以对其能力状态进行周期性评测。
这些模型提供了一个经过验证的框架，借此组织可以对其所付出的改进努力进行有效管理。
能力成熟度模型并不是专为企业架构而生，其实它最初目标是为了改善软件和系统工程的过程，只是随着企业架构理论的发展以及业界针对这一领域的关注逐渐加强，人们才开始考虑将这一模型应用到企业架构的领域之中，从而为评测和改进企业架构的过程提供导向。在TOGAF 9中并没有为企业架构专门设计一套成熟度模型，它只是通过例举两种成熟度模型来介绍当前企业架构是如何与能力成熟度模型相结合的，以供读者借鉴。
在前面已经提到过，美国政府可以说是施行企业架构的先行者之一，因而所有的美国联邦政府部门都被要求提供成熟度模型以及相应的打分机制来作为他们的IT投资管理和审计需求的一部分。以美国商务部（US Department of Commerce（DoC））为例，他就已经开发出了一套企业架构能力成熟度模型（ACMM：Architecture Capability Maturity Model）来帮助其内部的企业架构成熟度评测。这一成熟度模型在2007年12月时发布了1.2版本。ACMM提供了一套框架，其中包含了一个富有成效的企业架构过程所应具备的各种关键组件，其目标在于通过明确企业架构的薄弱环节并提供一条定义良好的演进改善路线来提升企业架构的成功几率。ACMM包含如下三部分内容：
企业架构成熟度模型
各个运行单元的流程在不同成熟度水平上的企业架构特性。
企业架构能力成熟度模型记分卡。
在上述三个部分的内容中，前两部份描述了架构能力成熟度水平、相应的企业架构元素，以及用在成熟度评测中的每个成熟度水平的特性；最后一个部分被用来获取用于向商务部首席信息官（CIO）进行汇报的架构能力成熟度水平。
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）
ACMM将每个企业架构成熟度评估元素的成熟度水平分为如下五个档次：
无（None）
初步（Initial）
在开发（Under development）
已定义（Defined）
受管理的（Managed）
可计量的（Measured）
截至到目前，成熟度模型已经在很多行业中得到了接受和施行，而且每个行业几乎都具有符合其自身特点的成熟度模型，但是正是由于这种广泛的接受性导致了成熟度模型过于繁杂。为了管理这一由于过多成熟度模型所带来复杂性，SEI（Software Engineering Institute）开发了一个名为能力成熟度模型集成（CMMI：Capability Maturity Model Integration）的框架。该框架综合了各领域成熟度模型的最佳实践，它使得组织可以：
将管理和工程活动与业务目标更加明显地联系在一起。
扩展产品生命周期和工程活动的范围和可见度，从而确保产品或服务满足用户的期望。
纳入从其他领域的最佳实践中汲取的经验教训。
实现更加坚固的高成熟度实践。
实现对产品和服务来说非常重要的额外的组织功能。
由于CMMI并不是隶属于某个特定行业的综合性成熟度模型，因而在企业架构的成熟度方面也可以对其进行借鉴，而这其中最为重要的就是标准过程改进评估方法（SCAMPI ：Standard CMMI Appraisal Method for Process Improvement）。此方法是与CMMI相关连的评估方法，被用来与CMMI参考模型进行比对，从而对目标的优势、弱点进行明确，并通过分数评定的方式进行清晰的表述。
企业架构过程是个非常繁杂的过程，它的顺利进行离不开众多具有不同角色的人员的通力协作，而如何保证这些相互合作的人员在各自岗位上能够胜任就变成一切活动的根本问题。为了应对这一问题，TOGAF提出了架构技能框架（Architecture Skills Framework），它为进行企业架构建设的组织提供了一份关于企业架构工作中各种角色及其能力的视图，从而为担负企业架构工作任务的团队的建立提供了导则。简单来讲，架构技能框架的内容包含如下三个方面：
定义了架构工作各领域所涉及到的角色。
定义了每个角色所应具备的技能。
定义了每个角色为了顺利承担其责任而对各种技能所应掌握的水平。
在实践中，每个企业对于项目人员的选择应该都有着自己的一套方法和流程，基本上来讲，都是通过项目本身的特质来制定所需人员的技能标准，并通过简单的面试来从组织内外的候选者中选择合适之人，但这对于企业架构的建设来讲却过于简单了。虽然企业架构的建设从本质上来讲也是一个项目，但是由于其本身的复杂度之高、牵涉性之广，如果把它当作一个普通实现项目来对待的话，组织往往会面临如下风险：
由于牵涉太广，从而缺乏统一术语、沟通和表述方式，所以招募组织、资讯团体和雇佣部门之间的沟通会非常困难。
由于没有明确的标准，招募宣传中的要求往往会由于被误解而使那些具有足够能力的人员被忽视。
雇佣不合适人员的风险将会加大，而这又会导致：
由于可能会出现人员的再次招募或重新分配，因而会导致人员成本的增加。
为了尽量避免这些风险，各个组织应该采用更为正式的认证机制来对企业架构工作人员进行定义和选择，而这一机制的目的应该在于如下两点：
作为建立和维护一个专业架构组织的任务的一部分，对架构人员所需的技能进行正式认可。
确保人员的技能和经验与其所担当的任务相匹配。
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）
其他角色...
架构技能框架将架构团队所需要技能归纳为如下几类：
通用技能（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）：通常包括数据保护法、合同法等。
架构委员会成员
架构赞助者
架构经理
架构师
（技术）
架构师
（数据）
架构师
（应用）
架构师
（业务）
方案/项目经理
IT设计师
通用技能
领导力
团队合作
人际交往
口才
写作
逻辑分析
干系人管理
风险管理
业务技能和方法
业务案例
业务情景
组织结构
业务流程
战略规划
预算管理
战略愿景
业务指标
业务文化
遗留的投资
业务功能
企业架构技能
业务建模
业务流程设计
角色设计
组织结构设计
数据设计
应用设计
系统集成
IT行业标准
服务设计
架构原则设计
架构视图和视角设计
构建块设计
解决方案建模
效益分析
业务交互
系统行为
项目管理
方案或项目管理技能
方案管理
项目管理
管理业务变更
变更管理
价值管理
通用IT知识技能
IT应用开发方法和工具
编程语言
代理应用
信息消费应用
信息提供应用
存储管理
网络
基于Web的服务
信息技术基础设施
资产管理
服务等级协议
系统
商用现成品
企业连续体
迁移规划
管理工具
基础设施
IT技术技能
软件工程
安全
系统和网络管理
事务处理
位置和目录
用户界面
国际化操作
数据管理
图形与图像
操作系统服务
网络服务
通信基础设施
法律环境
合同法
数据保护法
采购法
诈骗
商业法
7.5 企业架构师角色详解
在前面提到过的各种角色之中，最经常被提到的恐怕要数“企业架构师”这一角色了，而这也正是因为这一角色是整个企业架构建设的核心。虽然非常重要且常被挂在嘴角，但其在各行业中正式的定义却鲜有所闻，而仅仅被当作一个跨越多个架构领域具有广泛实践经验和技能的角色。TOGAF对于企业架构师的工作描述总结为如下几点：
负责保证架构的完整性，即所有种类不同的视图关联在一起，圆满调和不同干系人之间的冲突点，并展示出此种调和所带来的利益权衡。
架构师的职责范围贯穿了企业架构的整个生命周期，它开始于与客户一起理解其真正的需求，并在其后的过程中负责将这些需求转化为能够对其进行实现的各项能力。此外，架构师还需要通过不同模型的展示来与客户就其需求是如何被满足的进行沟通。由此可见，架构师与负责建设的团队是不同的，他的主要目标在于理解如何才能满足客户的需要，并就此为负责建设的应用开发团队或产品实现团队提供设计决策文档。与建设者相比，架构师需要保持一定水平的抽象性，并且通常其所使用的技能应该是归纳性的，而建设者则更加注重于实现方面，其所采用的技能也往往是推断性的。综上所述，架构师的角色职能可以总结如下：
理解并解释需求：探索信息、倾听信息、影响他人、促进共识、将各种观点综合转换为可行的需求、并将这些观点解释给他人。此外，还包括明确用途或目标、约束以及风险等因素。架构师将参与到针对各种客户业务情景的发掘之中，并对其进行文档记录。架构师还负责针对需求进行理解，并将这些理解融入到架构说明规范之中。
创建有用的模型：根据需求来开发各种经过精心定制的模型，并在必要的情况下对这些模型进行充实，使其能够适应所有的环境。架构师还将以这些模型为基础来展示出各种视图，从而提升与干系人之间所进行沟通的有效性。架构师为整体架构的完整性进行负责，并负责从架构的视角来对所提供的愿景进行维护。此外，架构师还要确保对各种明确的机会进行利用、采用各种构建块，并充当各个功能组织之间的联络员。为了理解开发工作的各个领域，并对组织内外所应采取的行为进行指导，架构师需要以框架的方式对这些模型进行提供和维护，此外架构师还必须通过对所有必须的业务组件的理解来表现架构的组织视图。
验证、修缮并扩展模型：对各种假设进行验证，并将其输入给主题专家。为了改善模型并对其进行进一步的定义，架构师需要为模型加入必须的新观点，从而使得模型更加灵活，并能够与当前及期望的需求联系得更加紧密。除此之外，架构师还应该对产生于现场工作用于对解决方案进行增强的开发的价值进行评估，并将这些内容适当地融入到架构模型之中。
管理架构：对模型进行持续监督，并在必要时对其进行更新，从而展示出了各种变化、新增和调整。在项目的开发和决策点对各种架构和问题进行表现。在整个开发周期中，架构师需要持续地促进组织间对于客户、架构和技术信息的共享。
在前面有关企业连续体的部分中我们已经了解到，对于构建块的实现可能会受其复杂性所限而需要对其解决方案的实施进行进一步划分，而在这种情况下就需要多种架构师的通力协作。从企业连续体的角度来说，架构师这一角色可以分为如下几种，并且其中的每一种都具备着各自的关注点：
企业架构师（Enterprise Architect）：从全景和技术参考模型的层次来为架构设计和文档进行负责。企业架构师通常领导一组与某一给定方案相关的片段架构师和/或解决方案架构师，并且其关注点在于所需要的企业级业务功能。
片段架构师（Segment Architect）：负责特定业务问题或组织领域内的架构设计和文档。一个片段架构师将会对其他架构师的输出进行重用，并将详细的技术解决方案加入到整体架构全景之中。片段架构师的关注点在于一个给定领域（例如财务、人力资源以及销售等）中的企业级业务解决方案。
解决方案架构师（Solution Architect）：在系统或子系统级别对架构设计和文档进行负责。一个解决方案架构师可以为企业或片段架构师屏蔽不必要的系统、产品和/或技术方面的细节，并且其关注点在于系统技术解决方案方面，例如诸如企业数据仓库之类的解决方案组件。
在本节的最后一部分，我们来探讨一下TOGAF对于企业架构师各方面特质的归纳总结：
熟悉创建设计的技能和经验：企业架构师必须熟练掌握创建复杂系统设计的各项技术，这包括需求发现和分析、解决方案上下文的制定、对各种可能的解决方案进行识别和评定、技术选型以及设计配置。
具备宽泛的技术广度，并在一个或几个领域中具备一定技术深度：企业架构师应该对IT行业有着宽泛的技术广度，并且这一广度应该涵盖应用开发和部署，以及针对用于支持复杂应用环境的基础设施的创建和维护方面。当前的IT环境包罗万象，而为了应对各种情况，有经验的企业架构师将具备跨越多个平台的技能，这包括了分布式系统以及传统的大型机环境。此外，企业架构师还应至少在一个领域中具备专家级的水平。
以方法驱动（Method-Driven）的方式来进行工作：企业架构师应该使用已被确认的方法（例如TOGAF）来进行工作。企业架构师应会使用一种以上的设计方法，并会根据工作状态自如地选择合适的方法或方法的一部分，亦即架构师应该了解在某给定情况下何种方法或方法部分可以被采用，而何种则不可以。
具备全项目范围的经验：当企业架构师对用于实现的项目的设计和执行进行负责时，他们对项目所有的方面具备经验是非常重要的。这些项目方面包括了开发、测试、实现和生产。企业架构师所掌握的项目经验的范围有助于其立于“适合目标（fitness-for-purpose）”以及系统实现的现实性的基础之上，而且全项目范围经验所带来的影响将会引导企业架构师制定出更好的设计决策，并在这些决策之间获得更好的平衡。
具备领导力：沟通和团队协作对于企业架构师这一角色的成功实现来讲是关键，并且良好的技术技能和领导能力的结合对其来讲也是至关重要的。企业架构师应被IT组织、其所服务的客户以及管理层看作企业中的一个领导者。
具备人际关系和专业方面的技能：由于企业架构师的主要任务之一就是与所有干系人（包括没有技术背景的干系人）就复杂的技术信息进行沟通，所以企业架构师必须具备很强的沟通和人际关系技能。此外，企业架构师还需要具备很强的谈判及解决问题的能力，因为企业架构师还必须与项目管理团队一起工作来及时地制定决策，从而保证项目运行在正确轨道之上。
具备一个或多个行业中的技能和经验：行业技能和经验将会使得收集需求及关于优先级的决策任务更加简单和有效。企业架构师必须理解企业的业务流程，以及这些流程是如何与行业中的其他企业协同工作的。企业架构师还应能发现主要的趋势，并对有缺陷的流程进行修正，从而给予IT组织对企业进行引导的能力，而不仅仅是对需求进行回应而已。企业架构师的任务是进行战略技术领导。