企业架构研究总结（38）——TOGAF架构能力框架之架构能力建设和架构治理

      为了确保架构功能在企业中能够被成功地运用，企业需要通过建立适当的组织结构、流程、角色、责任和技能来实现其自身的企业架构能力，而这也正是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.1 架构愿景阶段

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

• 建立项目：此步骤应该关注于定义与此架构实践有关的各个干系人。这些干系人包括了参与到架构实践活动中的角色和组织单元，以及那些会从架构实践所产生的交付物中获益的干系人。
• 明确干系人和其关注点、业务需求和架构愿景：此步骤将会针对此架构实践从业务信息系统和技术的角度产生第一个关于基线和目标环境的高度概括定义。
• 明确业务差距和业务驱动力：对业务目标和驱动力的了解对于促成此架构实践和业务之间的协调是非常重要的。
• 定义范围：针对此架构实践范围的定义将会产生一份高度概括的项目规划，用以概括在接下来的一个时间区间内需要被解决的问题。
• 定义约束：此步骤的关注点在于企业范围内会对所有架构项目产生影响的各种约束。
• 审查架构原则（包括业务原则）：此步骤的意图在于定义用于治理和指导这一架构实践运行的各种原则。与通常的架构原则用来治理架构交付物所不同，架构实践原则将被用来明确架构实践的组织、内容、工具和相关流程。
• 开发架构工作说明书和安全认证。
• 另外一个需要在此阶段被考虑进来的步骤是进行架构成熟度评估（请参阅2.4.4.6架构成熟度模型部分的描述）。

1.2 业务架构阶段

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

• 架构本体论（Architecture Ontology）：定义了各种架构的术语和定义，用于在组织中建立起关于这些内容的共识。
• 架构流程（Architecture Process）：以架构开发方法为基础并按照组织的需要和架构实践的愿景来对架构开发方法所进行的定制，并且所需的架构治理流程也应该被包含到整个架构流程之中。
• 架构视角和视图（Architecture Viewpoints and Views）：列举出所有架构实践所涉及到的视角和视图，而针对这些内容的定义工作应由此前被识别出来的架构实践干系人来进行指导。
• 架构框架（Architecture Framework）：描述了将会由架构实践所产生的各种架构交付物以及他们之间的交互、依赖关系，此外还包括了种种用于管理这些交付物的设计的规则和指南。那些在之前被定义的架构视角和视图也应该被用来指导架构框架的定义
• 架构问责矩阵（Architecture Accountability Matrix）：定义了架构实践所涉及到的各种角色，以及为这些角色所分配的关于架构交付物和流程的责任。
• 架构性能指标（Architecture Performance Metrics）：明确和描述了用于与架构实践愿景和目标进行比对和监督的各项架构实践性能指标。
• 架构治理框架（Architecture Governance Framework）：是一个与之前定义的架构流程和架构责任矩阵相关的特定视图。

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

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

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

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

1.5 技术架构阶段

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

1.6 机会与解决方案阶段

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

1.7 迁移规划阶段

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

1.8 实施治理阶段

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

1.9 架构变更管理阶段

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

1.10 需求管理

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

2. 架构治理

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

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

• 公司治理（Corporate governance）
• 技术治理（Technology governance）
• IT治理（IT governance）
• 架构治理（Architecture governance）

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

2.1 治理的共性

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

• 关注于各种干系人的权力、角色以及针对他们的公平处置。
• 信息披露、透明度和委员会的责任。
• 确保组织中良好的战略指南。
• 确保委员会进行有效管理监督。
• 确保委员会对于公司与相关干系人之间的问责。
• 委员会的责任包括：
• 审查和指导战略。
• 设置并监督管理绩效目标的进展。

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

• 纪律性（Discipline）：所有牵涉的团体需要承诺遵循由组织建立的各种程序、流程和权利结构。
• 透明性（Transparency）：被授权的组织和各供应商应该可以对所有实施行动和他们的决策支持进行检查。
• 独立性（Independence）：所有流程、决策制定以及所采用机制的建立应最小化或避免潜在的利益冲突。
• 问责性（Accountability）：所有在组织中被确定的团队需要被授权，并且需要为他们的行为负责。
• 责任性（Responsibility）：每个签订契约的团体需要对组织以及他们的干系人采取负责任的行为。
• 公平性（Fairness）：所有的决策、使用的流程以及针对他们的实现不应对任何团体产生不公平的利益。

2.2 不同治理领域的特性

      在前面提到过的四种领域中的治理除了具备上一节所述的共同原则和特性之外还分别具备各自的特点。由于公司治理的内容范畴超过了一个企业架构框架所应覆盖的范围，所以在这里并不会进行专门的描述，而接下来我们将针对其余的三种治理体系，亦即技术治理、IT治理和架构治理，分别进行描述。

2.2.1 技术治理

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

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

2.2.2 IT治理

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

2.2.3 架构治理

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

• 实现一个系统来控制所有架构组件和活动的创建，并对它们进行监督，从而确保在组织内有效地引入、实现各种架构，并保障这些架构的顺利演进。
• 实现一个系统用于确保各种架构对于企业内外的标准和法律法规的遵守。
• 建立各种流程，用于在已达成共识的各因素的约束之下，对上述流程的有效管理进行支持
• 开发各种实践，用于在组织内外确保对于一个经过清晰定义的干系人团体的问责性。

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

2.3 架构治理框架

      架构治理框架包括两个部分的内容，其一是用来概括架构治理各流程以及相关内容的概念结构，另外一个是TOGAF对于架构治理所建议的组织结构。在接下来的内容中我们将分别对这两个方面进行探讨。

2.3.1 概念结构

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

      上图展示了架构治理框架的概念结构，其中涵盖了这一框架中的各种概念，而这其中最关键的是与治理流程有关的各种概念。治理流程被用来识别、管理、审计和传播所有与架构管理、合同和实现相关的信息，从而确保对所有架构制品、合同、原则以及运营级别协议（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）：明确了各种服务，这些服务确保了以资源存储库为基础的环境对治理框架进行支持是有效且高效。这包括了针对所有用户的物理和逻辑资源存储库的管理、访问、沟通、培训和评审。为了形成一个受管的服务和流程环境，治理环境中将会定义一些管理流程，这些流程包括了用户管理、内部服务水平协议（为了控制这些管理流程本身而定义）以及针对管理信息的汇报。

 

2.3.2 组织结构

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

• 全局治理委员会
• 本地治理委员会
• 设计部门
• 工作组

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

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

• 在开发区域中，架构委员会（Architecture Board）对主架构师进行任命，并且通过两者的合作来对企业架构的设计和落实进行指导，并最终将企业架构细化成为各个面向具体问题的领域架构。
• 在实现区域中，受架构委员会授权和委派的项目管理办公室（Program Management Office）对用于实现各个领域架构的实施项目进行管控，从而保障其顺利施行。
• 在部署区域中，由于各个架构实现项目的实现和部署改变了企业当前的运营状态，因而受管理办公室委派的服务管理组织（Service Management Organisation）需要对企业的各运营系统进行监督，从而发现新的问题和需求，并借此启动新的一轮架构开发循环。

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

 

2.4 架构治理实践导则

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

• 与架构策略、程序、角色、技能、组织结构和支持服务的提交、采用、重用、回报和废止相关的各种最佳实践。
• 用于支持架构治理的流程以及达成汇报需求的组织结构及其责任。
• 对各种工具和流程进行整合，从而便于在程序上和文化上执行各个流程。
• 与架构治理流程、豁免、合规性审查、SLAs和OLAs的控制相关的各种指标。
• 组织内外对于所有架构治理相关信息、服务和流程在有效性、效率、保密性、完整性、可得性、合规性和可靠性这些方面的需求。

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

• 需要在最高管理层的支持下建立一个跨组织的架构委员会（Architecture Board，见2.4.4.3架构委员会）来对IT治理策略的实现提供监督。
• 需要建立一套全面的架构原则，从而对组织如何通过使用信息技术来完成自身的任务而进行指导和支持。
• 需要采用一种架构合规性策略（见2.4.4.4架构合规性），从而通过具体的措施来保证架构的合规性，这包括了项目影响评估、正式的架构合规性审查流程，同时也可能包括在产品采购过程中架构团体所进行参与。