为确保架构功能在企业中能够被成功运用，企业需要通过建立适当的组织结构、流程、角色、责任和技能来实现其自身的企业架构能力。这正是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的架构技能框架提供了参考和指南。

1、架构能力的建设

企业可以通过应用企业架构开发方法（ADM）来为建设各种业务能力。如果把视界放开一点，我们会发现企业架构开发方法可以应用到任何能力建设方面，这当然也包括架构能力。在架构能力的建设中，对于架构开发方法的成功运用可以使企业获得一个可持续的并以客户为中心的增值型架构实践，从而帮助企业达成其各项业务目标、最大化投资价值，并能够明确各种获得业务利益和管理风险的机会。架构实践的建设是一种持续性的实践过程，可为组织中其他架构的交付提供环境和资源。

在TOGAF的眼中，任何一种企业能力的建设都需要对如下四种领域进行设计，当然也包括针对这一可持续性架构实践建设：

▪ 业务架构：突出了架构治理、架构流程、架构组织结构、架构信息需求以及架构产品等方面。

▪ 数据架构：定义了组织中架构连续体和架构资源库的结构。

▪ 应用架构：描述了用于支持此可持续架构实践的功能和/或应用服务。

▪ 技术架构：描述了架构实践中用于支持各架构应用和企业连续体的基础设施需求和部署方式。

TOGAF对于这一可持续性架构实践的建设有着更加详尽的指南，在本节的后续部分中我们将以架构开发方法各阶段为基础来对企业架构能力的建设进行进一步探讨。

1）架构愿景阶段

此阶段的目的在于定义或审查这一架构实践的愿景、干系人和原则。具体步骤如下：

▪ 建立项目：此步骤关注与此架构实践有关的各个干系人。这些干系人包括了参与到架构实践活动中的角色和组织单元，及那些会从架构实践所产生的交付物中获益的干系人。

▪ 明确干系人和其关注点、业务需求和架构愿景：此步骤将会针对此架构实践从业务信息系统和技术的角度产生第一个关于基线和目标环境的高度概括定义。

▪ 明确业务差距和业务驱动力：对业务目标和驱动力的了解对于促成此架构实践和业务之间的协调是非常重要的。

▪ 定义范围：针对此架构实践范围的定义将会产生一份高度概括的项目规划，用以概括在接下来的一个时间区间内需要被解决的问题。

▪ 定义约束：此步骤的关注点在于企业范围内会对所有架构项目产生影响的各种约束。

▪ 审查架构原则（包括业务原则）：此步骤的意图在于定义用于治理和指导这一架构实践运行的各种原则。与通常的架构原则用来治理架构交付物所不同，架构实践原则将被用来明确架构实践的组织、内容、工具和相关流程。

▪ 开发架构工作说明书和安全认证。

▪ 另外一个需要在此阶段被考虑进来的步骤是进行架构成熟度评估。

2）业务架构阶段

此阶段的目标在于建立或提炼架构实践的业务架构，需要关注如下几个关键领域：

▪ 架构本体论（Architecture Ontology）：定义了各种架构的术语和定义，用于在组织中建立起关于这些内容的共识。

▪ 架构流程（Architecture Process）：以架构开发方法为基础并按照组织的需要和架构实践的愿景来对架构开发方法所进行的定制，并且所需的架构治理流程也应该被包含到整个架构流程之中。

▪ 架构视角和视图（Architecture Viewpoints and Views）：列举出所有架构实践所涉及到的视角和视图，而针对这些内容的定义工作应由此前被识别出来的架构实践干系人来进行指导。

▪ 架构框架（Architecture Framework）：描述了将会由架构实践所产生的各种架构交付物以及他们之间的交互、依赖关系，此外还包括了种种用于管理这些交付物的设计的规则和指南。那些在之前被定义的架构视角和视图也应该被用来指导架构框架的定义

▪ 架构问责矩阵（Architecture Accountability Matrix）：定义了架构实践所涉及到的各种角色，以及为这些角色所分配的关于架构交付物和流程的责任。

▪ 架构性能指标（Architecture Performance Metrics）：明确和描述了用于与架构实践愿景和目标进行比对和监督的各项架构实践性能指标。

▪ 架构治理框架（Architecture Governance Framework）：是一个与之前定义的架构流程和架构责任矩阵相关的特定视图。

3）信息系统架构阶段（数据）

架构实践的数据架构对组织的企业连续体和架构资源库进行了描述和治理。数据架构的定义应该基于组织所选择的架构框架，并且有时也被引用为架构实践的元模型。

4）信息系统架构阶段（应用）

架构实践的应用架构定义了用于产生、维护、发布、分发以及治理架构交付物的各种功能，而这其中一个关键点在于用来建模的各种建模工具组。

5）技术架构阶段

架构实践的技术架构应该对用于支持架构实践的技术基础设施进行定义。

6）机会与解决方案阶段

在这样一个与架构实践建设规划相关的阶段中，企业需要审慎考虑的重要一点是所需的组织变更，以及达成这一变更的方法。

7）迁移规划阶段

此阶段的关注点不仅要放到信息系统架构组件之上，还需要将业务架构包括在内，而对于架构流程和框架的采用将会对组织中架构实践的整体建设产生主要的影响。

8）实施治理阶段

针对架构实践的业务架构的实现应该是此阶段的关注重点。将组织中的实践活动改变为一种更加结构化和有纪律的方法非常具有挑战性，因而需要通过适当的组织变更技术来达成。

9）架构变更管理阶段

此阶段需要对架构实践中各种架构的变更进行管理，而这些变更通常是在各个架构项目的执行过程中被触发的。一个典型的变更往往会成为对于新架构交付物的需求，并会对架构实践中的所有架构领域产生影响。

10）需求管理

了解和管理架构实践的需求是非常关键的，并且这些需求需要被清晰地描述出来，并与架构实践愿景相一致。

2、架构治理

简单来讲，企业架构能力是指企业各种架构的建设能力，而这里所说的建设能力不仅指的是企业中各架构的实现，而且需要保证架构的实现是在一个透明且受控的环境之中。架构能力中有关这种保障架构建设和交付的内容就是架构治理（Architecture Governance），而这也是架构能力中最为核心的部分。

无论何种企业总有其需要进行管理的地方，即便是没有涉及到任何架构的企业也总会有着针对其他方面的治理体系。这也注定了架构治理必定不会独立地存在，而应该存在于一个层次化的治理结构之中。按照所处领域的不同，TOGAF将这一层次化的治理结构划分为如下四种，其中的每一种都具有其各自的规则和流程，并且可以存在于多个地理区域层次之上（包括全球、地区和本地这三种地理区域种类）：

▪ 公司治理（Corporate governance）

▪ 技术治理（Technology governance）

▪ IT治理（IT governance）

▪ 架构治理（Architecture governance）

以上这几种治理体系不是绝对隔离的，不同的治理体系所包含的活动和行为多少都会有交叠，但由于其所面对的领域不相，其管理的范畴以及所具备的规则、流程和活动具有很大的差异性。由于公司治理、技术治理和IT治理的内容范畴超过了一个企业架构框架理论内容范围，TOGAF中相关部分的描述重点还是放在了架构治理这一方面，不过它对治理的共性以及技术治理和IT治理还是做出了简要的描述。

1）治理的共性

在进一步介绍架构治理之前，我们需要对“治理”这一概念有一个清晰的认识。这里所说的治理并不像其字面上那样，仅仅代表显式的管控和对于规则的严格遵守，而是更加倾向于为有效且公平的使用各种资源提供指南，从而确保组织的战略目标的可持续发展。根据所处领域不同，在前面提到过治理可以被细分为若干治理层次，但无论其种类为何，“治理”的最终目标在于确保业务得以顺利进行，并且在这些种类不同的治理都遵循着相同的原则。经合组织（OECD：Organization for Economic Co-operation and Development）曾经针对这些基础共通原则做出了如下概括：

▪ 关注于各种干系人的权力、角色以及针对他们的公平处置。

▪ 信息披露、透明度和委员会的责任。

▪ 确保组织中良好的战略指南。

▪ 确保委员会进行有效管理监督。

▪ 确保委员会对于公司与相关干系人之间的问责。

▪ 委员会的责任包括：

  √ 审查和指导战略。

  √ 设置并监督管理绩效目标的进展。

除了这些共同原则之外，TOGAF还概括出了治理的各种共同特性，用以突显治理作为一个被组织在其内以及与其他有关团体之间所采用的方法的价值和必要性：

▪ 纪律性（Discipline）：所有牵涉的团体需要承诺遵循由组织建立的各种程序、流程和权利结构。

▪ 透明性（Transparency）：被授权的组织和各供应商应该可以对所有实施行动和他们的决策支持进行检查。

▪ 独立性（Independence）：所有流程、决策制定以及所采用机制的建立应最小化或避免潜在的利益冲突。

▪ 问责性（Accountability）：所有在组织中被确定的团队需要被授权，并且需要为他们的行为负责。

▪ 责任性（Responsibility）：每个签订契约的团体需要对组织以及他们的干系人采取负责任的行为。

▪ 公平性（Fairness）：所有的决策、使用的流程以及针对他们的实现不应对任何团体产生不公平的利益。

2）不同治理领域的特性

在前面提到过的四种领域中的治理除了具备上一节所述的共同原则和特性之外还分别具备各自的特点。接下来将针对技术治理、IT治理和架构治理分别进行描述。

▪ 技术治理

技术治理控制了一个组织如何将技术应用于针对其产品和服务的研究、开发和生产之中。技术治理与IT治理关系非常紧密，而且技术治理往往会涵盖IT治理中的各种活动，但技术治理的内容范畴则更为广阔。在现代企业中，越来越多的组织将注意力的重心逐渐放到无形资产之上，而不是仅仅关注于有形资产管理。由于大部分无形资产是信息化或数据资产，这正说明现代企业的业务与IT之间的关系也越来越紧密，因而针对IT的治理（亦即IT治理）也成为技术治理的一个重要组成部分。这一针对无形资产逐渐重视的趋势同时也突显了企业的业务不仅仅依赖于信息本身，还依赖于用于产生、交付和使用这些信息的各种流程、系统和结构。此外，随着无形资产价值比重在各个行业中的不断攀升，风险管理也需要作为一个重点而加以考虑，从而使得新的挑战、威胁和机会能够得以被理解和缓和。

需要注意的是，不仅仅是组织的运营和盈利越来越依赖于IT，组织的声誉、品牌以及最终他们的价值也都依赖于这些信息和支持技术。

▪ IT治理

IT治理为IT资源和信息与企业目标和战略之间的联系提供了框架和结构，并且IT治理为规划、采购、实现和监督IT绩效指定了各种最佳实践，从而确保企业的IT资产对其业务目标的支持。

▪ 架构治理

架构治理是为了在全企业范围内对企业架构以及其他各种架构进行管理和控制而需要借助的各种实践和方向，它具有如下几个方面的特性：

▪ 实现一个系统来控制所有架构组件和活动的创建，并对它们进行监督，从而确保在组织内有效地引入、实现各种架构，并保障这些架构的顺利演进。

▪ 实现一个系统用于确保各种架构对于企业内外的标准和法律法规的遵守。

▪ 建立各种流程，用于在已达成共识的各因素的约束之下，对上述流程的有效管理进行支持

▪ 开发各种实践，用于在组织内外确保对于一个经过清晰定义的干系人团体的问责性。

在前面有关企业架构开发方法的介绍中，我们已经在“实施治理”阶段见过了“治理”一词。这个阶段所关注的是通过各个变更项目来对架构进行实现，因而此阶段的治理仅仅是关于架构实现这一方面。不过对于架构治理来说，这一实施治理只是一个非常重要的方面，架构治理的范畴要更为广阔，它涵盖了针对企业架构以及其他各种架构在其开发和演进过程中所有方面的管理和控制。作为一个企业架构框架，TOGAF为支持架构治理的实现提供了一个架构治理框架（Architecture Goverance Framework），用于帮助企业明确各种有效的治理流程，从而使得与架构治理相关联的各种业务职责得以被鉴别出来，并能够对其进行有效地管理和沟通。

3）架构治理框架

架构治理框架包括两个部分的内容，其一是用来概括架构治理各流程以及相关内容的概念结构，另外一个是TOGAF对于架构治理所建议的组织结构。

①概念结构

架构治理框架的概念结构包含了架构治理中的种种概念，其中最为重要的是对一个有效的架构治理所应具有的各种流程以及与它们相关的内容所进行的定义。这一架构治理的概念结构采用了一种内容无关的方式，将流程、流程所涉及的内容以及背景元素进行了分离，从而使得新的治理材料的引入不会过度地影响到各个治理流程，同时也保证了这一治理框架的灵活性。

上图展示了架构治理框架的概念结构，其中涵盖了这一框架中的各种概念，这其中最关键的是与治理流程有关的各种概念。治理流程被用来识别、管理、审计和传播所有与架构管理、合同和实现相关的信息，从而确保对所有架构制品、合同、原则以及运营级别协议（operational-level agreements）进行持续地监督，并且所做的各项决策也具有了清晰的可审计性。这些治理流程相关的概念总结如下：

▪ 策略管理与内容引入（Policy Management and Take-On）：为了注册、验证、批准、管理和发布新的或经过更新的内容，所有针对架构修订、合同和支持性信息的引入都需要处在一个正规流程的治理之下。这些流程将确保与现存治理内容的有序整合，从而使得所有相关的团体、文档、合同和支持信息得以被管理和审计。

▪ 合规（Compliance）：针对服务水平协议（SLAs：Service Level Agreements）、运营水平协议（OLAs：Operational Level Agreements）、现行各项标准和法规需求的合规性评估需要在一个持续的基础上进行，从而确保针对稳定性、一致性和性能的监督。这些评估的进行需要以在治理框架中所定义的各项标准为准绳。

▪ 豁免（Dispensation）：当主题域（设计、运营、服务水平或技术）的内容在合规性评估中被判为不合规时，该部分内容将可能会被否定，而此时将会存在如下几种处理方式：  

√ 对这些不合规内容进行调整，从而使其满足合规性需求。

√ 申请一份豁免。当合规评估未能通过时，豁免就成为了一条用来达成临时性一致的备选路线。豁免只会存在于一段时间区间内，并在其整个生命周期内被强制设置明确的服务和运行条件。豁免并不会永久有效，它只是被用来作为一种在确保服务水平和运营水平得以满足的同时附加一定水平的灵活性的机制。豁免的时限性特征确保了它们是合规性评估循环的一个主要触发因素。

▪ 监督和汇报（Monitoring and Reporting）：性能管理被用来确保运营和服务元素的管理是基于一系列经过协定的标准之上，这包括了监督服务水平和运营水平协议、对于调整的反馈以及针对这些结果的汇报。

▪ 业务控制（Business Control）：业务控制与各个流程相关，这些流程的引发被用来确保与组织的业务策略相符合。

▪ 环境管理（Environment Management）：明确了各种服务，这些服务确保了以资源存储库为基础的环境对治理框架进行支持是有效且高效。这包括了针对所有用户的物理和逻辑资源存储库的管理、访问、沟通、培训和评审。为了形成一个受管的服务和流程环境，治理环境中将会定义一些管理流程，这些流程包括了用户管理、内部服务水平协议（为了控制这些管理流程本身而定义）以及针对管理信息的汇报。

②组织结构

在架构治理框架的概念结构中，TOGAF以一种内容无关的方式明确了一个有效的治理所涉及的各种概念，并借此概括了各种架构治理流程以及与这些流程相关联的各种内容，但如果要确保一个架构治理的顺利进行，还需要在企业中设立专门负责治理举措施行的组织结构。在实践中凭空创建这些用于架构治理的组织结构其实是不现实的，企业应该组合现有的各种IT治理流程、组织结构和能力来对其进行创建。通常来讲，企业中的治理组织结构可被分为如下几个层次：

▪ 全局治理委员会

▪ 本地治理委员会

▪ 设计部门

▪ 工作组

TOGAF提出了如下图所示的治理组织结构，各个企业可以按照各自的需求以此图所示的组织结构为基础而进行改造：

如上图所示，架构治理框架的组织结构可以被分为三个重点区域，他们分别是：开发（Develop）、实现（Implement）和部署（Deploy），它们中的每一个都代表了在架构生命周期的每一个阶段中各个相关小组所应尽的责任。尤其是对于开发区域来讲，这里的开发责任、流程和组织结构都与架构开发方法过程有着紧密的关联，而对于实现区域来讲，其所包含的实施责任、流程和组织结构与架构开发方法的实施治理阶段也是密不可分的：

▪ 在开发区域中，架构委员会（Architecture Board）对主架构师进行任命，并且通过两者的合作来对企业架构的设计和落实进行指导，并最终将企业架构细化成为各个面向具体问题的领域架构。

▪ 在实现区域中，受架构委员会授权和委派的项目管理办公室（Program Management Office）对用于实现各个领域架构的实施项目进行管控，从而保障其顺利施行。

▪ 在部署区域中，由于各个架构实现项目的实现和部署改变了企业当前的运营状态，因而受管理办公室委派的服务管理组织（Service Management Organisation）需要对企业的各运营系统进行监督，从而发现新的问题和需求，并借此启动新的一轮架构开发循环。

除了以上这三个核心区域之外，我们还应注意到企业连续体的再次出现。企业连续体之所以会在这里出现是因为它是架构治理的一个不可或缺的部分，因为它不仅承载了与架构相关的各种内容，也同时存储了与架构治理过程相关的种种材料。

4）架构治理实践导则

在实践中，为了实现一个成功的架构治理方法，并对架构合同进行有效的管理，企业需要考虑如下几个关键因素：

▪ 与架构策略、程序、角色、技能、组织结构和支持服务的提交、采用、重用、回报和废止相关的各种最佳实践。

▪ 用于支持架构治理的流程以及达成汇报需求的组织结构及其责任。

▪ 对各种工具和流程进行整合，从而便于在程序上和文化上执行各个流程。

▪ 与架构治理流程、豁免、合规性审查、SLAs和OLAs的控制相关的各种指标。

▪ 组织内外对于所有架构治理相关信息、服务和流程在有效性、效率、保密性、完整性、可得性、合规性和可靠性这些方面的需求。

除了上面几项对于架构治理成功因素的描述，TOGAF还指出了一个在企业中获得接受和成功的架构所应具备的三个主要的架构治理战略元素：

▪ 需要在最高管理层的支持下建立一个跨组织的架构委员会（Architecture Board）来对IT治理策略的实现提供监督。

▪ 需要建立一套全面的架构原则，从而对组织如何通过使用信息技术来完成自身的任务而进行指导和支持。

▪ 需要采用一种架构合规性策略，从而通过具体的措施来保证架构的合规性，这包括了项目影响评估、正式的架构合规性审查流程，同时也可能包括在产品采购过程中架构团体所进行参与。

3、架构委员会

正如前面所说，一个用来对架构治理策略的实现进行监督的跨组织的架构委员会是架构治理策略成功的主要要素之一。架构委员会应该能够代表所有主要干系人的需求，并且通常还需要对整个架构的审查及维护活动负有高级行政职责。通常来讲，架构委员会需要对如下目标的达成进行负责：

▪ 子架构之间的一致性。

▪ 确定可重用组件。

▪ 保证企业架构的灵活性：

  √ 满足不断变化的业务需求。

  √ 尽可能的利用不断出现的新技术。

▪ 严格确保架构合规性。

▪ 改善组织中架构规程的成熟度水平。

▪ 确保采用以架构为基础的开发规程。

▪ 为所有关于架构变更的决策提供基础。

▪ 为超出范围的决策提供升级的能力。

如果从执行的角度来看，架构委员会还需要承担如下责任：

▪ 有关架构合同的监督和控制的所有方面。

▪ 定期举行会议。

▪ 确保针对架构进行有效并且一致地管理和实现。

▪ 解析不清楚的地方，并对各种问题以及已经升级了的冲突进行解决。

▪ 提供各种建议、指导以及信息。

▪ 确保各种架构的合规性，并在确保与技术战略及目标一致的基础上授予豁免。

▪ 当相似的豁免被申请并被通过时，架构委员会需要考虑进行策略变更。

▪ 确保所有与架构合同的实现相关的信息在可控的条件下被发布，并可被经过授权的团体所获得。

▪ 对汇报的服务水平、成本节约等方面进行验证。

如果从治理的角度来看，架构委员会还需要承担如下责任：

▪ 产生各种可用的治理材料和活动。

▪ 通过共识和被授权的发布来为架构的正式接受和批准提供一种机制。

▪ 为确保架构的有效实现而提供一个基本控制机制。

▪ 在架构的实现、包含在企业架构中的架构战略和目标，以及业务的战略目标之间建立关联，并对其进行维护。

▪ 为了通过豁免或策略更新来进行调整，架构委员会需要明确架构与计划开展的活动之间的差异。

1）架构委员会的建立

一个架构委员会的建立往往受如下事件的触发：

▪ 新CIO的任命。

▪ 兼并或收购。

▪ 考虑采用一个新的计算形式。

▪ 认识到IT与业务的契合度很差。

▪ 渴望通过技术来达成竞争优势。

▪ 一个企业架构方案的创建。

▪ 重大的业务变更或业务的快速发展。

▪ 需要复杂且跨越诸多功能的解决方案。

在很多公司中，最初的领导级架构赞助者通常都是CIO，然而为了在企业中获得广阔的支持，一个赞助组织的影响力往往超过某个个人，这样一个赞助组织在这里被称为一个架构委员会。架构委员会是一个高级领导层组织，用来为战略架构及其子架构的审查和维护进行负责。虽然架构委员会是企业中架构的赞助者，企业架构委员会自己本身也需要获得企业高层的赞助和支持，并且这一支持需要贯彻整个规划过程，延伸到针对架构项目的维护之中。

架构委员会的常驻人员规模不宜过大，按照TOGAF的建议，一个架构委员会的常驻人员规模应包含四至五人，或不超过十人。为了使架构委员会随着事件的推移而一直保持合理的规模，并同时确保其在企业范围内的代表性，架构委员会的成员需要采用轮换制，从而给予各个高级经理决策权和相关责任。除此之外，由于现实中的各种原因这一轮换机制还有其存在的必要性，例如当有些架构委员会成员受时间所限而不能长期承担其职责时。虽然采用了轮换制，但为了确保架构委员会的决策不会变化无常，企业需要主动的采用某种机制来确保其核心理念的稳定，例如为成员设置任期，并将不同成员的离退时间交错开来。

2）架构委员会的运行

架构委员会的运行的核心以及在形式上的表现就是按照清晰的日程安排所进行的架构委员会会议，并且这些日程安排需要具有明确的目标、所涵盖的内容和经过定义的行为。架构委员会会议需要为如下几个方面提供指导：

▪ 对高质量的治理材料和活动的产生进行支持。

▪ 通过共识和被授权的发布来为架构的正式接受提供一个机制。

▪ 为确保有效的架构实现提供一个基本控制机制。

▪ 在架构的实现、包含在企业架构中的架构战略和目标以及业务的战略目标之间建立关联，并对其进行维护。

▪ 为通过豁免或策略更新来与合同进行重新校准而对合同和规划活动之间的差异进行明确。

每个会议的参与者在开会前会收到一份日程描述和相关支持文档，他们需要在开会前对这些内容进行熟悉，并且被分配进行某项活动的与会人员还需要报告其执行进度。此外，每个与会人员还必须确认其是否参加架构委员会会议。

由此可见，会议的日程描述是有关整个会议内容的核心，TOGAF对于其内容项目做了如下建议：

▪ 前期会议纪要：以前的架构委员会会议的详细纪要。

▪ 变更请求：此条目之下的内容通常包含了针对架构、原则等内容进行修订的变更请求，此外也可以包含对于架构合同的业务控制（例如，确保针对某一付费号码的语音流量（例如天气预报）被禁止，以及对于某一特定网站进行访问的数据流量需要被控制）。任何一个变更请求的设置需要在制定者的授权范围之内，并采用在架构合同中已经定义好的参数。

▪ 豁免：豁免被用来作为一个对现存架构、合同和原则等方面内容进行更改的申请。豁免只会在一定的时间区间中以及定义明确的在整个豁免期间需要被贯彻的服务和运营条件下被认可。

▪ 合规性评估：合规性的评估是针对服务水平协议、运营水平协议、成本目标等方面而进行的。根据在架构治理框架中定义的条件标准，通过审查后，这些评估结果或者被接受亦或者被拒绝，并且架构合规性评估报告还应包含所描述的各个细节。

▪ 争议解决：经过架构合规性审查和豁免过程而依然未被解决的争议需要在这里被明确，从而为下一步的行动提供目标，并且这些内容需要被记录到架构合规性评估和豁免文档之中。

▪ 架构战略和方向文档：这里所描述的内容仅被全局架构委员会所制定，它包含了架构的战略、方向及其优先级顺序。

▪ 行动分配：这是一个关于前期架构委员会会议所分配行动情况的报告。在此报告中，一个行动跟踪记录被用来记录和保持所有在架构委员会会议中被分配的行动的状态，其内容至少应该包含如下几个方面：

  √ 参考材料

  √ 优先级

  √ 行动概述

  √ 行动所属者

  √ 行动详细描述

  √ 开始日

  √ 到期日

  √ 状态

  √ 类型

  √ 决议通过之日

▪ 合同文档管理：这是为架构文档的后续发布而对其进行的有关更新和改变的正式认可。

▪ 其他事项（AOB：Any Other Business）：关于上述内容所没有覆盖的问题的描述。这些内容也许不会被描述在会议日程之中，但应该在会议开始时被提出。

▪ 会议安排：所有会议的时间和内容安排应被详细描述，并公之于众。

4、架构合规性

针对架构合规性的审查是架构治理战略的核心环节，也是决定其能否成功的重要因素。架构合规性审查是针对各个具体项目与已经建立的架构标准、精神以及业务目标的相符合情况所进行的审议，而一个关于这些审议的正规流程正是企业的架构合规性策略的核心内容。通过架构合规性审查，企业可以达成如下几点（或部分）目标：

▪ 首先且最重要的目标是企业得以尽早在项目架构中发现错误，从而减少在整个生命周期的后期进行更改的风险和成本，而这也意味着整体的项目时间得以缩减，并且各项业务也能够尽早地获得架构所带来的底线收益（bottom-line benefit）。

▪ 确保将各种最佳实践应用到架构工作当中。

▪ 提供一份关于架构与强制性企业标准的符合度的概略。

▪ 明确标准本身需要进行修改的地方。

▪ 明确能够作为企业基础设施的组成部分，却在当前只为特定应用提供支持的各个服务。

▪ 将关于团队合作、资源共享以及其他能够跨越多个架构团队的协同增效方面的战略进行文档化。

▪ 充分利用技术所带来的先进性。

▪ 对项目的技术准备状态进行沟通。

▪ 确定采购活动的关键标准。

▪ 明确重大的架构性差距，并就此与产品和服务供应商进行沟通。

除了上面这些与质量保证有关的目标之外，架构合规性审查的进行还在特定情况下具有着倾向于以政治为导向的动机：

▪ 由于具有决策能力的人通常会参与到审查当中，并能够从对业务最优的角度进行决策指导，而不仅仅注重技术的优劣，这使得架构合规性审查成为了一种在各种架构选择之间进行选择的好方法。

▪ 架构合规性审查的输出是为数不多的用来汇报给CIO，并辅助其决策制定的可测性交付物之一。

▪ 架构审查可以作为一条架构组织借以参与到开发项目之中的途径，否则各个开发项目的进行将会与企业的架构功能相脱节。

▪ 架构审查可以为企业业务团体给出快速且正面的支持：

  √ 企业架构以及架构合规性可以帮助确保各IT项目与业务目标的符合度。

  √ 架构师有时可以被视为深入到技术基础设施之中而远离核心业务之外。

  √ 由于架构合规性审查倾向于将主要注意力放到一个系统的关键风险区域内，所以此审查经常可以为系统所有者凸显各种主要的风险。

1）架构合规性审查发生时点

架构合规性审查并不是一个一次性的活动，它应该在适当的项目里程碑或项目生命周期的各个检查点进行，并且其具体的审查要点应包括：

▪ 架构开发自身的合规性，亦即对于架构开发方法的符合度。

▪ 架构实现的合规性，亦即各个实施项目与架构的符合度。

针对架构项目审查的时点应包括：

▪ 项目启动

▪ 初步设计

▪ 主要设计变更时

▪ 其它特定时刻

2）架构合规性审查进行的情景概括

就架构合规性审查的进行、治理以及参与的人员来说，TOGAF针对此审查的进行总结出了如下三种情景：

▪ 对于小规模的项目，这一审查流程可以只是由项目架构师或项目组长制定一系列问题（可以通过对后面将要列出的问题清单进行定制而获得），再将答案收录到某种形式的报告中，并对其进行管理。进行这样一个流程的需求通常要被包含在整个企业范围的IT治理策略中。

▪ 如果处于审查之下的项目并没有一个全职的架构师的参与（例如，一个应用级的项目），那么就需要借助于企业中具有架构功能的组织的专业性架构能力了。这种情况下，企业架构功能组织将负责对这一审查进行组织、领导和执行，并保证各业务领域专家的参与。需要注意的是，这样的审查并不是要取代架构师对于项目的参与，而是对架构师参与的一个有效的补充。此外，在这种情景下也许还需要引入一套数据库系统，从而对在大型系统或系统组的分析中所产生的大量数据进行管理。

▪ 对于大多数情况来说，尤其是对于大型项目来说，组织中具有架构功能的组织可能已经深入地参与到（或领导）处于合规性审查之下的开发项目之中。在这种情况下，这一审查应该由主架构师来进行协调。主架构师需要组织一个包含业务和技术领域专家的团队，并将合规性审查中各个问题的答案编织成某种形式的报告。合规性审查中各个问题的制定需要由各个业务和技术领域专家一起来执行。除了由主架构师领导之外，架构合规性审查也可以由架构委员会的代表或其他在全企业范围内具有相似能力的组织来领导。

在上面这些情景中，架构合规性审查的进行都需要高级管理层的支持，并通常被作为企业架构治理策略的一个重要部分来加以强制。一般来讲，企业的CIO或企业架构委员会将对所有主要项目进行强制性审查，并在之后形成年度审查的惯例。

3）架构合规性审查流程

①流程

TOGAF对于架构合规性审查的流程做了如下图所示的总结：

②参与流程的各角色及职责

4）架构合规性审查问题参考列表

架构合规性审查是针对各个项目与架构的符合度而进行的审议活动，而这一活动的具体实施需要围绕着一份问题清单来进行的。为了帮助这一份问题清单的制定，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）方面

     √ 厂商是否稳定？

     √ 当厂商消亡时企业是否会收到产品源代码？

     √ 是否软件按照企业的用途而进行了配置？

     √ 是否存在特有的架构和设计方面的数据或流程，从而阻碍了针对软件的使用？

        ▶ 是否此软件在当前是可得的？

     √ 是否厂商使用或阐明的规模/可用性/服务水平与企业的需求相类似

        ▶ 描述厂商过往的财务和市场份额历史。

⑧系统工程/方法与工具问题清单

    ▪ 是否具有对当前业务操作方法的评定指标？

    ▪ 系统拥有者是否已经创建了用于指导当前项目的评估标准？如果有，则对如何使用这些评估标准进行描述。

    ▪ 是否对于现存架构的研究已经完成，从而使得当前的工作成果能够得以被充分利用？描述在这一研究中所使用的发现和认识方法。是否现存的这些架构需要被整合？如果是，解释将会采用的方法。

    ▪ 描述将会应用到项目中的方法：

     √ 用于定义业务战略的方法。

     √ 用于定义需要改善的领域的方法。

     √ 用于定义基线和目标业务流程的方法。

     √ 用于定义过渡流程的方法。

     √ 用于管理项目的方法。

     √ 用于团队沟通的方法。

     √ 用于知识管理、变更管理和配置管理的方法。

     √ 用于软件开发的方法。

     √ 用于引用标准和方向说明的方法。

     √ 用于交付物的质量保证的方法。

     √ 用于设计审查和交付验收的方法。

     √ 用于达成指标的方法。

    ▪ 是否各个方法已被记录，并被分发给了每个团队成员？

    ▪ 团队成员在多大程度上熟悉这些方法？

    ▪ 采用何种流程来确保方法执行的符合性？

    ▪ 描绘当前所采用的用于支持方法使用的基础设施。

     √ 如何提供咨询和故障排除？

     √ 如何协调安排培训？

     √ 如何合并和关联各种变更和改进？

     √ 如何获取经验教训，并对其进行沟通？

    ▪ 关于项目所采用的工具为何？（指定版本和平台）。团队成员对这些工具的熟悉度为何？

    ▪ 描绘当前所采用的用于支持此工具使用的基础设施。

     √ 如何提供咨询和故障排除？

     √ 如何协调安排培训？

     √ 如何合并和关联各种变更和改进？

     √ 如何获取经验教训，并对其进行沟通？

    ▪ 描述项目如何促进对其交付物及所交付内容的重用。

    ▪ 在项目实现后此架构设计是否还会存续？描述用来将变更合并入此架构设计的方法。

    ▪ 当前流程是否被定义？

    ▪ 是否各种问题已经被记录和评定，并与当前流程关联起来？如果没有，那又如何得知已经出现问题的地方正在被修正？

    ▪ 是否现存或规划的流程改善活动已被明确，并与当前流程关联起来？如果没有，那又如何知道此活动与其他工作说明书中的内容不会发生冲突或相互冗余？

    ▪ 当前是否存在各种评估指标？当前是否存在预测指标？如果没有，那又如何得知获得了改善？

    ▪ 采用何种流程来收集、评估和汇报各种指标？

    ▪ 新的设计对于现存业务流程、组织结构和信息系统有什么样的影响？是否这些影响已经被记录到文档之中，并与其他干系人进行共享？

5）架构合规性审查实践导则

①裁剪和定制问题清单导则

    ▪ 关注于：

     √ 高风险区域。

     √ 预期的（突发的）差异。

    ▪ 对于清单中的每条问题，需要理解：

     √ 问题本身的含义。

     √ 问题背后的原则。

     √ 在回应中需要寻找什么样的内容。

    ▪ 寻求领域专家的意见。

    ▪ 根据自身需要对清单中的问题进行修补。

    ▪ 时刻牢记需要架构委员会的反馈。

②架构合规性审查执行导则

    ▪ 理解审查的目标，并始终保持在正确的轨道之上对提出的问题提供适合的交付物。例如，人们通常希望了解正在架构的系统的对错之处，而不是希望了解诸如所采用的开发方法是否正确、管理组织结构是否合理等这些方面，因而在审查中就会经常偏离主题。

    ▪ 随着审查讨论的进行，其他一些需要被解决的问题将会逐渐显现，而且这些问题还常常会超出当前审查的范围。在这种情况下，我们需要在此次审查会后对其进行处理，并依照这些问题的重要性来制定一份用于解决这些问题的计划。

    ▪ 保持科学的态度。与其说“我们期望看到大型数据库放置在ABC之上而不放在XYZ”，我们更应该说“XYZ数据库环境之下的停机时间远远超过在ABC数据库环境之中的状况。因此我们不推荐将M和N系统放置到XYZ环境中”。

    ▪ 询问开放性问题。

    ▪ 在审查的征询过程中经常会存在隐藏的日程或有争议的问题，而这些内容在前期是无法预知的，因而采用一个非个性化的方法来进行讨论将会弥合这些差距而不是加剧他们。

    ▪ 尊重面谈的对象。他们可能不会采用合适的方法来构建系统，但是他们可能在其所处的环境中已经尽了最大的努力。

    ▪ 在练习中增长经验。

    ▪ 审查应该包括针对架构的详细评估活动，并确保其结果被存储到企业连续体之中。

（以上内容摘自微信公众平台架构师修炼之道，如有侵权请联系删除）

为确保架构功能在企业中能够被成功运用，企业需要通过建立适当的组织结构、流程、角色、责任和技能来实现其自身的企业架构能力。这正是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的架构技能框架提供了参考和指南。

1、架构能力的建设

企业可以通过应用企业架构开发方法（ADM）来为建设各种业务能力。如果把视界放开一点，我们会发现企业架构开发方法可以应用到任何能力建设方面，这当然也包括架构能力。在架构能力的建设中，对于架构开发方法的成功运用可以使企业获得一个可持续的并以客户为中心的增值型架构实践，从而帮助企业达成其各项业务目标、最大化投资价值，并能够明确各种获得业务利益和管理风险的机会。架构实践的建设是一种持续性的实践过程，可为组织中其他架构的交付提供环境和资源。

在TOGAF的眼中，任何一种企业能力的建设都需要对如下四种领域进行设计，当然也包括针对这一可持续性架构实践建设：

▪ 业务架构：突出了架构治理、架构流程、架构组织结构、架构信息需求以及架构产品等方面。

▪ 数据架构：定义了组织中架构连续体和架构资源库的结构。

▪ 应用架构：描述了用于支持此可持续架构实践的功能和/或应用服务。

▪ 技术架构：描述了架构实践中用于支持各架构应用和企业连续体的基础设施需求和部署方式。

TOGAF对于这一可持续性架构实践的建设有着更加详尽的指南，在本节的后续部分中我们将以架构开发方法各阶段为基础来对企业架构能力的建设进行进一步探讨。

1）架构愿景阶段

此阶段的目的在于定义或审查这一架构实践的愿景、干系人和原则。具体步骤如下：

▪ 建立项目：此步骤关注与此架构实践有关的各个干系人。这些干系人包括了参与到架构实践活动中的角色和组织单元，及那些会从架构实践所产生的交付物中获益的干系人。

▪ 明确干系人和其关注点、业务需求和架构愿景：此步骤将会针对此架构实践从业务信息系统和技术的角度产生第一个关于基线和目标环境的高度概括定义。

▪ 明确业务差距和业务驱动力：对业务目标和驱动力的了解对于促成此架构实践和业务之间的协调是非常重要的。

▪ 定义范围：针对此架构实践范围的定义将会产生一份高度概括的项目规划，用以概括在接下来的一个时间区间内需要被解决的问题。

▪ 定义约束：此步骤的关注点在于企业范围内会对所有架构项目产生影响的各种约束。

▪ 审查架构原则（包括业务原则）：此步骤的意图在于定义用于治理和指导这一架构实践运行的各种原则。与通常的架构原则用来治理架构交付物所不同，架构实践原则将被用来明确架构实践的组织、内容、工具和相关流程。

▪ 开发架构工作说明书和安全认证。

▪ 另外一个需要在此阶段被考虑进来的步骤是进行架构成熟度评估。

2）业务架构阶段

此阶段的目标在于建立或提炼架构实践的业务架构，需要关注如下几个关键领域：

▪ 架构本体论（Architecture Ontology）：定义了各种架构的术语和定义，用于在组织中建立起关于这些内容的共识。

▪ 架构流程（Architecture Process）：以架构开发方法为基础并按照组织的需要和架构实践的愿景来对架构开发方法所进行的定制，并且所需的架构治理流程也应该被包含到整个架构流程之中。

▪ 架构视角和视图（Architecture Viewpoints and Views）：列举出所有架构实践所涉及到的视角和视图，而针对这些内容的定义工作应由此前被识别出来的架构实践干系人来进行指导。

▪ 架构框架（Architecture Framework）：描述了将会由架构实践所产生的各种架构交付物以及他们之间的交互、依赖关系，此外还包括了种种用于管理这些交付物的设计的规则和指南。那些在之前被定义的架构视角和视图也应该被用来指导架构框架的定义

▪ 架构问责矩阵（Architecture Accountability Matrix）：定义了架构实践所涉及到的各种角色，以及为这些角色所分配的关于架构交付物和流程的责任。

▪ 架构性能指标（Architecture Performance Metrics）：明确和描述了用于与架构实践愿景和目标进行比对和监督的各项架构实践性能指标。

▪ 架构治理框架（Architecture Governance Framework）：是一个与之前定义的架构流程和架构责任矩阵相关的特定视图。

3）信息系统架构阶段（数据）

架构实践的数据架构对组织的企业连续体和架构资源库进行了描述和治理。数据架构的定义应该基于组织所选择的架构框架，并且有时也被引用为架构实践的元模型。

4）信息系统架构阶段（应用）

架构实践的应用架构定义了用于产生、维护、发布、分发以及治理架构交付物的各种功能，而这其中一个关键点在于用来建模的各种建模工具组。

5）技术架构阶段

架构实践的技术架构应该对用于支持架构实践的技术基础设施进行定义。

6）机会与解决方案阶段

在这样一个与架构实践建设规划相关的阶段中，企业需要审慎考虑的重要一点是所需的组织变更，以及达成这一变更的方法。

7）迁移规划阶段

此阶段的关注点不仅要放到信息系统架构组件之上，还需要将业务架构包括在内，而对于架构流程和框架的采用将会对组织中架构实践的整体建设产生主要的影响。

8）实施治理阶段

针对架构实践的业务架构的实现应该是此阶段的关注重点。将组织中的实践活动改变为一种更加结构化和有纪律的方法非常具有挑战性，因而需要通过适当的组织变更技术来达成。

9）架构变更管理阶段

此阶段需要对架构实践中各种架构的变更进行管理，而这些变更通常是在各个架构项目的执行过程中被触发的。一个典型的变更往往会成为对于新架构交付物的需求，并会对架构实践中的所有架构领域产生影响。

10）需求管理

了解和管理架构实践的需求是非常关键的，并且这些需求需要被清晰地描述出来，并与架构实践愿景相一致。

2、架构治理

简单来讲，企业架构能力是指企业各种架构的建设能力，而这里所说的建设能力不仅指的是企业中各架构的实现，而且需要保证架构的实现是在一个透明且受控的环境之中。架构能力中有关这种保障架构建设和交付的内容就是架构治理（Architecture Governance），而这也是架构能力中最为核心的部分。

无论何种企业总有其需要进行管理的地方，即便是没有涉及到任何架构的企业也总会有着针对其他方面的治理体系。这也注定了架构治理必定不会独立地存在，而应该存在于一个层次化的治理结构之中。按照所处领域的不同，TOGAF将这一层次化的治理结构划分为如下四种，其中的每一种都具有其各自的规则和流程，并且可以存在于多个地理区域层次之上（包括全球、地区和本地这三种地理区域种类）：

▪ 公司治理（Corporate governance）

▪ 技术治理（Technology governance）

▪ IT治理（IT governance）

▪ 架构治理（Architecture governance）

以上这几种治理体系不是绝对隔离的，不同的治理体系所包含的活动和行为多少都会有交叠，但由于其所面对的领域不相，其管理的范畴以及所具备的规则、流程和活动具有很大的差异性。由于公司治理、技术治理和IT治理的内容范畴超过了一个企业架构框架理论内容范围，TOGAF中相关部分的描述重点还是放在了架构治理这一方面，不过它对治理的共性以及技术治理和IT治理还是做出了简要的描述。

1）治理的共性

在进一步介绍架构治理之前，我们需要对“治理”这一概念有一个清晰的认识。这里所说的治理并不像其字面上那样，仅仅代表显式的管控和对于规则的严格遵守，而是更加倾向于为有效且公平的使用各种资源提供指南，从而确保组织的战略目标的可持续发展。根据所处领域不同，在前面提到过治理可以被细分为若干治理层次，但无论其种类为何，“治理”的最终目标在于确保业务得以顺利进行，并且在这些种类不同的治理都遵循着相同的原则。经合组织（OECD：Organization for Economic Co-operation and Development）曾经针对这些基础共通原则做出了如下概括：

▪ 关注于各种干系人的权力、角色以及针对他们的公平处置。

▪ 信息披露、透明度和委员会的责任。

▪ 确保组织中良好的战略指南。

▪ 确保委员会进行有效管理监督。

▪ 确保委员会对于公司与相关干系人之间的问责。

▪ 委员会的责任包括：

  √ 审查和指导战略。

  √ 设置并监督管理绩效目标的进展。

除了这些共同原则之外，TOGAF还概括出了治理的各种共同特性，用以突显治理作为一个被组织在其内以及与其他有关团体之间所采用的方法的价值和必要性：

▪ 纪律性（Discipline）：所有牵涉的团体需要承诺遵循由组织建立的各种程序、流程和权利结构。

▪ 透明性（Transparency）：被授权的组织和各供应商应该可以对所有实施行动和他们的决策支持进行检查。

▪ 独立性（Independence）：所有流程、决策制定以及所采用机制的建立应最小化或避免潜在的利益冲突。

▪ 问责性（Accountability）：所有在组织中被确定的团队需要被授权，并且需要为他们的行为负责。

▪ 责任性（Responsibility）：每个签订契约的团体需要对组织以及他们的干系人采取负责任的行为。

▪ 公平性（Fairness）：所有的决策、使用的流程以及针对他们的实现不应对任何团体产生不公平的利益。

2）不同治理领域的特性

在前面提到过的四种领域中的治理除了具备上一节所述的共同原则和特性之外还分别具备各自的特点。接下来将针对技术治理、IT治理和架构治理分别进行描述。

▪ 技术治理

技术治理控制了一个组织如何将技术应用于针对其产品和服务的研究、开发和生产之中。技术治理与IT治理关系非常紧密，而且技术治理往往会涵盖IT治理中的各种活动，但技术治理的内容范畴则更为广阔。在现代企业中，越来越多的组织将注意力的重心逐渐放到无形资产之上，而不是仅仅关注于有形资产管理。由于大部分无形资产是信息化或数据资产，这正说明现代企业的业务与IT之间的关系也越来越紧密，因而针对IT的治理（亦即IT治理）也成为技术治理的一个重要组成部分。这一针对无形资产逐渐重视的趋势同时也突显了企业的业务不仅仅依赖于信息本身，还依赖于用于产生、交付和使用这些信息的各种流程、系统和结构。此外，随着无形资产价值比重在各个行业中的不断攀升，风险管理也需要作为一个重点而加以考虑，从而使得新的挑战、威胁和机会能够得以被理解和缓和。

需要注意的是，不仅仅是组织的运营和盈利越来越依赖于IT，组织的声誉、品牌以及最终他们的价值也都依赖于这些信息和支持技术。

▪ IT治理

IT治理为IT资源和信息与企业目标和战略之间的联系提供了框架和结构，并且IT治理为规划、采购、实现和监督IT绩效指定了各种最佳实践，从而确保企业的IT资产对其业务目标的支持。

▪ 架构治理

架构治理是为了在全企业范围内对企业架构以及其他各种架构进行管理和控制而需要借助的各种实践和方向，它具有如下几个方面的特性：

▪ 实现一个系统来控制所有架构组件和活动的创建，并对它们进行监督，从而确保在组织内有效地引入、实现各种架构，并保障这些架构的顺利演进。

▪ 实现一个系统用于确保各种架构对于企业内外的标准和法律法规的遵守。

▪ 建立各种流程，用于在已达成共识的各因素的约束之下，对上述流程的有效管理进行支持

▪ 开发各种实践，用于在组织内外确保对于一个经过清晰定义的干系人团体的问责性。

在前面有关企业架构开发方法的介绍中，我们已经在“实施治理”阶段见过了“治理”一词。这个阶段所关注的是通过各个变更项目来对架构进行实现，因而此阶段的治理仅仅是关于架构实现这一方面。不过对于架构治理来说，这一实施治理只是一个非常重要的方面，架构治理的范畴要更为广阔，它涵盖了针对企业架构以及其他各种架构在其开发和演进过程中所有方面的管理和控制。作为一个企业架构框架，TOGAF为支持架构治理的实现提供了一个架构治理框架（Architecture Goverance Framework），用于帮助企业明确各种有效的治理流程，从而使得与架构治理相关联的各种业务职责得以被鉴别出来，并能够对其进行有效地管理和沟通。

3）架构治理框架

架构治理框架包括两个部分的内容，其一是用来概括架构治理各流程以及相关内容的概念结构，另外一个是TOGAF对于架构治理所建议的组织结构。

①概念结构

架构治理框架的概念结构包含了架构治理中的种种概念，其中最为重要的是对一个有效的架构治理所应具有的各种流程以及与它们相关的内容所进行的定义。这一架构治理的概念结构采用了一种内容无关的方式，将流程、流程所涉及的内容以及背景元素进行了分离，从而使得新的治理材料的引入不会过度地影响到各个治理流程，同时也保证了这一治理框架的灵活性。

上图展示了架构治理框架的概念结构，其中涵盖了这一框架中的各种概念，这其中最关键的是与治理流程有关的各种概念。治理流程被用来识别、管理、审计和传播所有与架构管理、合同和实现相关的信息，从而确保对所有架构制品、合同、原则以及运营级别协议（operational-level agreements）进行持续地监督，并且所做的各项决策也具有了清晰的可审计性。这些治理流程相关的概念总结如下：

▪ 策略管理与内容引入（Policy Management and Take-On）：为了注册、验证、批准、管理和发布新的或经过更新的内容，所有针对架构修订、合同和支持性信息的引入都需要处在一个正规流程的治理之下。这些流程将确保与现存治理内容的有序整合，从而使得所有相关的团体、文档、合同和支持信息得以被管理和审计。

▪ 合规（Compliance）：针对服务水平协议（SLAs：Service Level Agreements）、运营水平协议（OLAs：Operational Level Agreements）、现行各项标准和法规需求的合规性评估需要在一个持续的基础上进行，从而确保针对稳定性、一致性和性能的监督。这些评估的进行需要以在治理框架中所定义的各项标准为准绳。

▪ 豁免（Dispensation）：当主题域（设计、运营、服务水平或技术）的内容在合规性评估中被判为不合规时，该部分内容将可能会被否定，而此时将会存在如下几种处理方式：  

√ 对这些不合规内容进行调整，从而使其满足合规性需求。

√ 申请一份豁免。当合规评估未能通过时，豁免就成为了一条用来达成临时性一致的备选路线。豁免只会存在于一段时间区间内，并在其整个生命周期内被强制设置明确的服务和运行条件。豁免并不会永久有效，它只是被用来作为一种在确保服务水平和运营水平得以满足的同时附加一定水平的灵活性的机制。豁免的时限性特征确保了它们是合规性评估循环的一个主要触发因素。

▪ 监督和汇报（Monitoring and Reporting）：性能管理被用来确保运营和服务元素的管理是基于一系列经过协定的标准之上，这包括了监督服务水平和运营水平协议、对于调整的反馈以及针对这些结果的汇报。

▪ 业务控制（Business Control）：业务控制与各个流程相关，这些流程的引发被用来确保与组织的业务策略相符合。

▪ 环境管理（Environment Management）：明确了各种服务，这些服务确保了以资源存储库为基础的环境对治理框架进行支持是有效且高效。这包括了针对所有用户的物理和逻辑资源存储库的管理、访问、沟通、培训和评审。为了形成一个受管的服务和流程环境，治理环境中将会定义一些管理流程，这些流程包括了用户管理、内部服务水平协议（为了控制这些管理流程本身而定义）以及针对管理信息的汇报。

②组织结构

在架构治理框架的概念结构中，TOGAF以一种内容无关的方式明确了一个有效的治理所涉及的各种概念，并借此概括了各种架构治理流程以及与这些流程相关联的各种内容，但如果要确保一个架构治理的顺利进行，还需要在企业中设立专门负责治理举措施行的组织结构。在实践中凭空创建这些用于架构治理的组织结构其实是不现实的，企业应该组合现有的各种IT治理流程、组织结构和能力来对其进行创建。通常来讲，企业中的治理组织结构可被分为如下几个层次：

▪ 全局治理委员会

▪ 本地治理委员会

▪ 设计部门

▪ 工作组

TOGAF提出了如下图所示的治理组织结构，各个企业可以按照各自的需求以此图所示的组织结构为基础而进行改造：

如上图所示，架构治理框架的组织结构可以被分为三个重点区域，他们分别是：开发（Develop）、实现（Implement）和部署（Deploy），它们中的每一个都代表了在架构生命周期的每一个阶段中各个相关小组所应尽的责任。尤其是对于开发区域来讲，这里的开发责任、流程和组织结构都与架构开发方法过程有着紧密的关联，而对于实现区域来讲，其所包含的实施责任、流程和组织结构与架构开发方法的实施治理阶段也是密不可分的：

▪ 在开发区域中，架构委员会（Architecture Board）对主架构师进行任命，并且通过两者的合作来对企业架构的设计和落实进行指导，并最终将企业架构细化成为各个面向具体问题的领域架构。

▪ 在实现区域中，受架构委员会授权和委派的项目管理办公室（Program Management Office）对用于实现各个领域架构的实施项目进行管控，从而保障其顺利施行。

▪ 在部署区域中，由于各个架构实现项目的实现和部署改变了企业当前的运营状态，因而受管理办公室委派的服务管理组织（Service Management Organisation）需要对企业的各运营系统进行监督，从而发现新的问题和需求，并借此启动新的一轮架构开发循环。

除了以上这三个核心区域之外，我们还应注意到企业连续体的再次出现。企业连续体之所以会在这里出现是因为它是架构治理的一个不可或缺的部分，因为它不仅承载了与架构相关的各种内容，也同时存储了与架构治理过程相关的种种材料。

4）架构治理实践导则

在实践中，为了实现一个成功的架构治理方法，并对架构合同进行有效的管理，企业需要考虑如下几个关键因素：

▪ 与架构策略、程序、角色、技能、组织结构和支持服务的提交、采用、重用、回报和废止相关的各种最佳实践。

▪ 用于支持架构治理的流程以及达成汇报需求的组织结构及其责任。

▪ 对各种工具和流程进行整合，从而便于在程序上和文化上执行各个流程。

▪ 与架构治理流程、豁免、合规性审查、SLAs和OLAs的控制相关的各种指标。

▪ 组织内外对于所有架构治理相关信息、服务和流程在有效性、效率、保密性、完整性、可得性、合规性和可靠性这些方面的需求。

除了上面几项对于架构治理成功因素的描述，TOGAF还指出了一个在企业中获得接受和成功的架构所应具备的三个主要的架构治理战略元素：

▪ 需要在最高管理层的支持下建立一个跨组织的架构委员会（Architecture Board）来对IT治理策略的实现提供监督。

▪ 需要建立一套全面的架构原则，从而对组织如何通过使用信息技术来完成自身的任务而进行指导和支持。

▪ 需要采用一种架构合规性策略，从而通过具体的措施来保证架构的合规性，这包括了项目影响评估、正式的架构合规性审查流程，同时也可能包括在产品采购过程中架构团体所进行参与。

3、架构委员会

正如前面所说，一个用来对架构治理策略的实现进行监督的跨组织的架构委员会是架构治理策略成功的主要要素之一。架构委员会应该能够代表所有主要干系人的需求，并且通常还需要对整个架构的审查及维护活动负有高级行政职责。通常来讲，架构委员会需要对如下目标的达成进行负责：

▪ 子架构之间的一致性。

▪ 确定可重用组件。

▪ 保证企业架构的灵活性：

  √ 满足不断变化的业务需求。

  √ 尽可能的利用不断出现的新技术。

▪ 严格确保架构合规性。

▪ 改善组织中架构规程的成熟度水平。

▪ 确保采用以架构为基础的开发规程。

▪ 为所有关于架构变更的决策提供基础。

▪ 为超出范围的决策提供升级的能力。

如果从执行的角度来看，架构委员会还需要承担如下责任：

▪ 有关架构合同的监督和控制的所有方面。

▪ 定期举行会议。

▪ 确保针对架构进行有效并且一致地管理和实现。

▪ 解析不清楚的地方，并对各种问题以及已经升级了的冲突进行解决。

▪ 提供各种建议、指导以及信息。

▪ 确保各种架构的合规性，并在确保与技术战略及目标一致的基础上授予豁免。

▪ 当相似的豁免被申请并被通过时，架构委员会需要考虑进行策略变更。

▪ 确保所有与架构合同的实现相关的信息在可控的条件下被发布，并可被经过授权的团体所获得。

▪ 对汇报的服务水平、成本节约等方面进行验证。

如果从治理的角度来看，架构委员会还需要承担如下责任：

▪ 产生各种可用的治理材料和活动。

▪ 通过共识和被授权的发布来为架构的正式接受和批准提供一种机制。

▪ 为确保架构的有效实现而提供一个基本控制机制。

▪ 在架构的实现、包含在企业架构中的架构战略和目标，以及业务的战略目标之间建立关联，并对其进行维护。

▪ 为了通过豁免或策略更新来进行调整，架构委员会需要明确架构与计划开展的活动之间的差异。

1）架构委员会的建立

一个架构委员会的建立往往受如下事件的触发：

▪ 新CIO的任命。

▪ 兼并或收购。

▪ 考虑采用一个新的计算形式。

▪ 认识到IT与业务的契合度很差。

▪ 渴望通过技术来达成竞争优势。

▪ 一个企业架构方案的创建。

▪ 重大的业务变更或业务的快速发展。

▪ 需要复杂且跨越诸多功能的解决方案。

在很多公司中，最初的领导级架构赞助者通常都是CIO，然而为了在企业中获得广阔的支持，一个赞助组织的影响力往往超过某个个人，这样一个赞助组织在这里被称为一个架构委员会。架构委员会是一个高级领导层组织，用来为战略架构及其子架构的审查和维护进行负责。虽然架构委员会是企业中架构的赞助者，企业架构委员会自己本身也需要获得企业高层的赞助和支持，并且这一支持需要贯彻整个规划过程，延伸到针对架构项目的维护之中。

架构委员会的常驻人员规模不宜过大，按照TOGAF的建议，一个架构委员会的常驻人员规模应包含四至五人，或不超过十人。为了使架构委员会随着事件的推移而一直保持合理的规模，并同时确保其在企业范围内的代表性，架构委员会的成员需要采用轮换制，从而给予各个高级经理决策权和相关责任。除此之外，由于现实中的各种原因这一轮换机制还有其存在的必要性，例如当有些架构委员会成员受时间所限而不能长期承担其职责时。虽然采用了轮换制，但为了确保架构委员会的决策不会变化无常，企业需要主动的采用某种机制来确保其核心理念的稳定，例如为成员设置任期，并将不同成员的离退时间交错开来。

2）架构委员会的运行

架构委员会的运行的核心以及在形式上的表现就是按照清晰的日程安排所进行的架构委员会会议，并且这些日程安排需要具有明确的目标、所涵盖的内容和经过定义的行为。架构委员会会议需要为如下几个方面提供指导：

▪ 对高质量的治理材料和活动的产生进行支持。

▪ 通过共识和被授权的发布来为架构的正式接受提供一个机制。

▪ 为确保有效的架构实现提供一个基本控制机制。

▪ 在架构的实现、包含在企业架构中的架构战略和目标以及业务的战略目标之间建立关联，并对其进行维护。

▪ 为通过豁免或策略更新来与合同进行重新校准而对合同和规划活动之间的差异进行明确。

每个会议的参与者在开会前会收到一份日程描述和相关支持文档，他们需要在开会前对这些内容进行熟悉，并且被分配进行某项活动的与会人员还需要报告其执行进度。此外，每个与会人员还必须确认其是否参加架构委员会会议。

由此可见，会议的日程描述是有关整个会议内容的核心，TOGAF对于其内容项目做了如下建议：

▪ 前期会议纪要：以前的架构委员会会议的详细纪要。

▪ 变更请求：此条目之下的内容通常包含了针对架构、原则等内容进行修订的变更请求，此外也可以包含对于架构合同的业务控制（例如，确保针对某一付费号码的语音流量（例如天气预报）被禁止，以及对于某一特定网站进行访问的数据流量需要被控制）。任何一个变更请求的设置需要在制定者的授权范围之内，并采用在架构合同中已经定义好的参数。

▪ 豁免：豁免被用来作为一个对现存架构、合同和原则等方面内容进行更改的申请。豁免只会在一定的时间区间中以及定义明确的在整个豁免期间需要被贯彻的服务和运营条件下被认可。

▪ 合规性评估：合规性的评估是针对服务水平协议、运营水平协议、成本目标等方面而进行的。根据在架构治理框架中定义的条件标准，通过审查后，这些评估结果或者被接受亦或者被拒绝，并且架构合规性评估报告还应包含所描述的各个细节。

▪ 争议解决：经过架构合规性审查和豁免过程而依然未被解决的争议需要在这里被明确，从而为下一步的行动提供目标，并且这些内容需要被记录到架构合规性评估和豁免文档之中。

▪ 架构战略和方向文档：这里所描述的内容仅被全局架构委员会所制定，它包含了架构的战略、方向及其优先级顺序。

▪ 行动分配：这是一个关于前期架构委员会会议所分配行动情况的报告。在此报告中，一个行动跟踪记录被用来记录和保持所有在架构委员会会议中被分配的行动的状态，其内容至少应该包含如下几个方面：

  √ 参考材料

  √ 优先级

  √ 行动概述

  √ 行动所属者

  √ 行动详细描述

  √ 开始日

  √ 到期日

  √ 状态

  √ 类型

  √ 决议通过之日

▪ 合同文档管理：这是为架构文档的后续发布而对其进行的有关更新和改变的正式认可。

▪ 其他事项（AOB：Any Other Business）：关于上述内容所没有覆盖的问题的描述。这些内容也许不会被描述在会议日程之中，但应该在会议开始时被提出。

▪ 会议安排：所有会议的时间和内容安排应被详细描述，并公之于众。

4、架构合规性

针对架构合规性的审查是架构治理战略的核心环节，也是决定其能否成功的重要因素。架构合规性审查是针对各个具体项目与已经建立的架构标准、精神以及业务目标的相符合情况所进行的审议，而一个关于这些审议的正规流程正是企业的架构合规性策略的核心内容。通过架构合规性审查，企业可以达成如下几点（或部分）目标：

▪ 首先且最重要的目标是企业得以尽早在项目架构中发现错误，从而减少在整个生命周期的后期进行更改的风险和成本，而这也意味着整体的项目时间得以缩减，并且各项业务也能够尽早地获得架构所带来的底线收益（bottom-line benefit）。

▪ 确保将各种最佳实践应用到架构工作当中。

▪ 提供一份关于架构与强制性企业标准的符合度的概略。

▪ 明确标准本身需要进行修改的地方。

▪ 明确能够作为企业基础设施的组成部分，却在当前只为特定应用提供支持的各个服务。

▪ 将关于团队合作、资源共享以及其他能够跨越多个架构团队的协同增效方面的战略进行文档化。

▪ 充分利用技术所带来的先进性。

▪ 对项目的技术准备状态进行沟通。

▪ 确定采购活动的关键标准。

▪ 明确重大的架构性差距，并就此与产品和服务供应商进行沟通。

除了上面这些与质量保证有关的目标之外，架构合规性审查的进行还在特定情况下具有着倾向于以政治为导向的动机：

▪ 由于具有决策能力的人通常会参与到审查当中，并能够从对业务最优的角度进行决策指导，而不仅仅注重技术的优劣，这使得架构合规性审查成为了一种在各种架构选择之间进行选择的好方法。

▪ 架构合规性审查的输出是为数不多的用来汇报给CIO，并辅助其决策制定的可测性交付物之一。

▪ 架构审查可以作为一条架构组织借以参与到开发项目之中的途径，否则各个开发项目的进行将会与企业的架构功能相脱节。

▪ 架构审查可以为企业业务团体给出快速且正面的支持：

  √ 企业架构以及架构合规性可以帮助确保各IT项目与业务目标的符合度。

  √ 架构师有时可以被视为深入到技术基础设施之中而远离核心业务之外。

  √ 由于架构合规性审查倾向于将主要注意力放到一个系统的关键风险区域内，所以此审查经常可以为系统所有者凸显各种主要的风险。

1）架构合规性审查发生时点

架构合规性审查并不是一个一次性的活动，它应该在适当的项目里程碑或项目生命周期的各个检查点进行，并且其具体的审查要点应包括：

▪ 架构开发自身的合规性，亦即对于架构开发方法的符合度。

▪ 架构实现的合规性，亦即各个实施项目与架构的符合度。

针对架构项目审查的时点应包括：

▪ 项目启动

▪ 初步设计

▪ 主要设计变更时

▪ 其它特定时刻

2）架构合规性审查进行的情景概括

就架构合规性审查的进行、治理以及参与的人员来说，TOGAF针对此审查的进行总结出了如下三种情景：

▪ 对于小规模的项目，这一审查流程可以只是由项目架构师或项目组长制定一系列问题（可以通过对后面将要列出的问题清单进行定制而获得），再将答案收录到某种形式的报告中，并对其进行管理。进行这样一个流程的需求通常要被包含在整个企业范围的IT治理策略中。

▪ 如果处于审查之下的项目并没有一个全职的架构师的参与（例如，一个应用级的项目），那么就需要借助于企业中具有架构功能的组织的专业性架构能力了。这种情况下，企业架构功能组织将负责对这一审查进行组织、领导和执行，并保证各业务领域专家的参与。需要注意的是，这样的审查并不是要取代架构师对于项目的参与，而是对架构师参与的一个有效的补充。此外，在这种情景下也许还需要引入一套数据库系统，从而对在大型系统或系统组的分析中所产生的大量数据进行管理。

▪ 对于大多数情况来说，尤其是对于大型项目来说，组织中具有架构功能的组织可能已经深入地参与到（或领导）处于合规性审查之下的开发项目之中。在这种情况下，这一审查应该由主架构师来进行协调。主架构师需要组织一个包含业务和技术领域专家的团队，并将合规性审查中各个问题的答案编织成某种形式的报告。合规性审查中各个问题的制定需要由各个业务和技术领域专家一起来执行。除了由主架构师领导之外，架构合规性审查也可以由架构委员会的代表或其他在全企业范围内具有相似能力的组织来领导。

在上面这些情景中，架构合规性审查的进行都需要高级管理层的支持，并通常被作为企业架构治理策略的一个重要部分来加以强制。一般来讲，企业的CIO或企业架构委员会将对所有主要项目进行强制性审查，并在之后形成年度审查的惯例。

3）架构合规性审查流程

①流程

TOGAF对于架构合规性审查的流程做了如下图所示的总结：

②参与流程的各角色及职责

4）架构合规性审查问题参考列表

架构合规性审查是针对各个项目与架构的符合度而进行的审议活动，而这一活动的具体实施需要围绕着一份问题清单来进行的。为了帮助这一份问题清单的制定，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）方面

     √ 厂商是否稳定？

     √ 当厂商消亡时企业是否会收到产品源代码？

     √ 是否软件按照企业的用途而进行了配置？

     √ 是否存在特有的架构和设计方面的数据或流程，从而阻碍了针对软件的使用？

        ▶ 是否此软件在当前是可得的？

     √ 是否厂商使用或阐明的规模/可用性/服务水平与企业的需求相类似

        ▶ 描述厂商过往的财务和市场份额历史。

⑧系统工程/方法与工具问题清单

    ▪ 是否具有对当前业务操作方法的评定指标？

    ▪ 系统拥有者是否已经创建了用于指导当前项目的评估标准？如果有，则对如何使用这些评估标准进行描述。

    ▪ 是否对于现存架构的研究已经完成，从而使得当前的工作成果能够得以被充分利用？描述在这一研究中所使用的发现和认识方法。是否现存的这些架构需要被整合？如果是，解释将会采用的方法。

    ▪ 描述将会应用到项目中的方法：

     √ 用于定义业务战略的方法。

     √ 用于定义需要改善的领域的方法。

     √ 用于定义基线和目标业务流程的方法。

     √ 用于定义过渡流程的方法。

     √ 用于管理项目的方法。

     √ 用于团队沟通的方法。

     √ 用于知识管理、变更管理和配置管理的方法。

     √ 用于软件开发的方法。

     √ 用于引用标准和方向说明的方法。

     √ 用于交付物的质量保证的方法。

     √ 用于设计审查和交付验收的方法。

     √ 用于达成指标的方法。

    ▪ 是否各个方法已被记录，并被分发给了每个团队成员？

    ▪ 团队成员在多大程度上熟悉这些方法？

    ▪ 采用何种流程来确保方法执行的符合性？

    ▪ 描绘当前所采用的用于支持方法使用的基础设施。

     √ 如何提供咨询和故障排除？

     √ 如何协调安排培训？

     √ 如何合并和关联各种变更和改进？

     √ 如何获取经验教训，并对其进行沟通？

    ▪ 关于项目所采用的工具为何？（指定版本和平台）。团队成员对这些工具的熟悉度为何？

    ▪ 描绘当前所采用的用于支持此工具使用的基础设施。

     √ 如何提供咨询和故障排除？

     √ 如何协调安排培训？

     √ 如何合并和关联各种变更和改进？

     √ 如何获取经验教训，并对其进行沟通？

    ▪ 描述项目如何促进对其交付物及所交付内容的重用。

    ▪ 在项目实现后此架构设计是否还会存续？描述用来将变更合并入此架构设计的方法。

    ▪ 当前流程是否被定义？

    ▪ 是否各种问题已经被记录和评定，并与当前流程关联起来？如果没有，那又如何得知已经出现问题的地方正在被修正？

    ▪ 是否现存或规划的流程改善活动已被明确，并与当前流程关联起来？如果没有，那又如何知道此活动与其他工作说明书中的内容不会发生冲突或相互冗余？

    ▪ 当前是否存在各种评估指标？当前是否存在预测指标？如果没有，那又如何得知获得了改善？

    ▪ 采用何种流程来收集、评估和汇报各种指标？

    ▪ 新的设计对于现存业务流程、组织结构和信息系统有什么样的影响？是否这些影响已经被记录到文档之中，并与其他干系人进行共享？

5）架构合规性审查实践导则

①裁剪和定制问题清单导则

    ▪ 关注于：

     √ 高风险区域。

     √ 预期的（突发的）差异。

    ▪ 对于清单中的每条问题，需要理解：

     √ 问题本身的含义。

     √ 问题背后的原则。

     √ 在回应中需要寻找什么样的内容。

    ▪ 寻求领域专家的意见。

    ▪ 根据自身需要对清单中的问题进行修补。

    ▪ 时刻牢记需要架构委员会的反馈。

②架构合规性审查执行导则

    ▪ 理解审查的目标，并始终保持在正确的轨道之上对提出的问题提供适合的交付物。例如，人们通常希望了解正在架构的系统的对错之处，而不是希望了解诸如所采用的开发方法是否正确、管理组织结构是否合理等这些方面，因而在审查中就会经常偏离主题。

    ▪ 随着审查讨论的进行，其他一些需要被解决的问题将会逐渐显现，而且这些问题还常常会超出当前审查的范围。在这种情况下，我们需要在此次审查会后对其进行处理，并依照这些问题的重要性来制定一份用于解决这些问题的计划。

    ▪ 保持科学的态度。与其说“我们期望看到大型数据库放置在ABC之上而不放在XYZ”，我们更应该说“XYZ数据库环境之下的停机时间远远超过在ABC数据库环境之中的状况。因此我们不推荐将M和N系统放置到XYZ环境中”。

    ▪ 询问开放性问题。

    ▪ 在审查的征询过程中经常会存在隐藏的日程或有争议的问题，而这些内容在前期是无法预知的，因而采用一个非个性化的方法来进行讨论将会弥合这些差距而不是加剧他们。

    ▪ 尊重面谈的对象。他们可能不会采用合适的方法来构建系统，但是他们可能在其所处的环境中已经尽了最大的努力。

    ▪ 在练习中增长经验。

    ▪ 审查应该包括针对架构的详细评估活动，并确保其结果被存储到企业连续体之中。

（以上内容摘自微信公众平台架构师修炼之道，如有侵权请联系删除）