如何使 TOGAF 标准服务于企业架构

本文要点

• TOGAF 取代了逐步发展企业架构实践的需要。熟悉这个标准可以取代重新创造 EA 流程、实践、结构和原则的需要。
• 为了对 TOGAF 有一个全面的了解，包括流程、内容、指南、角色、结构，学习该标准的七个基本部分。
• 利用 TOGAF 技术，把它运用到你的组织中。如果需要，则可以利用调整技术，使它和其他框架共存。
• 通过评估已交付目标架构的完成情况追踪成效。
• 和其他人分享采用标准化 EA 框架（如 TOGAF 标准）的好处。如果发现组织在创建自定义 EA 实践，则劝说组织不重复造轮子。

要记录大型企业系统的所有复杂性是一个巨大的工程，而且都很难知道从哪里开始。此外，开发满足企业战略的企业架构，并保证良好的架构质量，是一项有挑战性的工作。TOGAF 中的指南和结构可以提供帮助。这是一个分层的、经过测试的框架，为企业架构的许多方面提供指南。这里，我将分享 TOGAF 的好处，如何入手以及如何把它与其他方法结合起来。

不久前，出于各种原因，我着手完成 TOGAF 9 认证。在经过大量的学习和准备之后，我通过了两部分考试。但是，在完成考试后，我变得特别推崇整个 TOGAF 标准的全面性，远远超出预期。

为了说明 TOGAF 的价值，我将首先概括地介绍下这个标准。然后，我将大概介绍下它对于企业架构的贡献，并提供在组织中运用这项标准的指南，说明如何调整标准以适应其他的技术。因为该标准由七个精心设计的部分组成，我将选择几项对你有帮助的重点介绍下。为了更好的理解这个标准，我建议查阅完整的标准。这篇概述是为了鼓励你采用一种成熟而深入的标准，而不是逐步发展自己的。

先说下我的背景。我有 17 年的技术生涯，在过去的八年里，我更多地关注软件、系统和解决方案结构。到目前为止，我已经完成了 36 个架构设计，领域涉及应用程序、集成、云、UI、移动和 CI 管道。在这些架构中，有 25 个实现了，目前还在使用或在生产环境中。虽然我仍在设计各种类型的技术架构，但是，我的工作已经逐步地向企业架构转移。

目前，我大部分的工作都是在一家大型服装公司的供应链中，围绕设计、监督和管理一系列基于运输物流的在线零售应用程序而开展。在这个组织中，作为董事会成员，我还积极参与到架构评审委员会里。该委员会负责架构评审、技术标准化、制定蓝图、设计指导，以及加强安全措施，保证工件格式和质量的一致性。

在这个组织里，架构评审委员会的结构和活动都是自行设计的，在委员会成立后经过了短暂的发展。随着我越来越多地参与到企业架构的流程、活动和相关问题中，我希望借助行业认可的企业架构标准来形式化我的经验。我通过 TOGAF 认证的目的是学习一种全面而又备受推崇的企业架构方法。我希望以我在这个领域的经验为基础，学习一门新学科。再者，我现在希望能劝说组织建立并实行一种全面的企业架构实践。

企业架构的价值

那么，为什么说 TOGAF 标准很重要？或者更进一步，为什么说企业架构（EA）很重要？企业需要发展变化，提供新产品和新服务来营利并保持地位。但是，在企业的整个生命周期中，新系统被创建，企业兼并需要系统集成或整合，为了保持竞争优势，新技术被采用，更多的系统需要通过集成来共享信息。为了应对、处理和管理这些技术和计算复杂性，在组织层面，一个恰当定义、管理的企业架构实践就尤其重要。如果没有 EA 实践，系统之间就会缺乏连接，解决方案就会不一致，产品团队和工程团队就会缺少交流，工程工作重复，组织架构和解决方案质量受损。

让我们举一个产品初创公司的例子。该初创公司会经历快速增长，迅速从新生进入初期发展阶段。业务和技术都会经历频繁的变化。如果没有 EA 实践，或者至少是某个层面的架构指南，那么该初创公司可能很快就会发现其系统不一致，无法共享信息。公司发展越快，威胁就越是迫在眉睫。

另外一个可以说明 EA 必要性的典型例子是并购。当两家公司合到一起，多出来的系统需要共享信息，或许需要合并。例如，可能有多个面向员工的 HR 系统需要集成或整合成一个。不恰当的集成会导致员工数据无法共享、软件缺陷、传输错误、过度传输以及为了与其他的系统实现恰当的业务连续性而额外进行的手工过程。此外，你可能需要合并或者把 EA 框架转换到一个模型下，如 TOGAF。

总之，使用一个成熟的企业架构标准，如 TOGAF，可以提供更有效且更高效的 IT 运营。它可以提高投资回报，降低未来冗余投资风险，加速采购，降低采购成本。所有这些好处都支持更高效的业务运营。

TOGAF 概述

开放组架构框架，简称为 TOGAF ，这是一个由 The Open Group 组织创建的企业架构框架标准。该标准是一个方法论，包括一套流程、原则、指南、最佳实践、技术、角色和工件。它用于开发和治理企业架构，妥善处理业务需求。认证学习指南中有一个恰当的定义：

企业架构的目的是把企业范围内那些碎片化的流程（手工的和自动的）优化成为一个集成的环境，可以响应变化，支持业务策略的交付。

为了实现这个高阶目标，该标准建议创建几个底层的策略元素为此提供支持。这些元素包括——指导原则、一个全面的架构开发方法（ADM）、一个活的架构统一体、一个活的工件库、一个治理结构、一个能力框架和一个参考模型库。你可能已经看到，其中有些方面是结构，如统一体和库。但其他方面是流程，如可迭代的 ADM 架构开发方法。

为了更好的理解该框架的组件，下面将介绍该标准的结构。

♦ 第一部分：简介

• 定义常用术语，在 TOGAF 标准的语境下。例子包括定义一个企业、企业架构和架构框架。
• 提供核心概念概述。例子包括 ADM、输出类型、统一体、库、能力以及把 TOGAF 与其他架构框架搭配使用。

♦ 第二部分：架构开发方法（ADM）

• ADM 是一个可迭代的架构开发方法，由 9 个阶段构成，为架构师和组织开发、交付架构提供指导。

（1） 5.2.2 小节 TOGAF 9.1 标准

• 阶段包括定义的活动 / 流程、预期的输入和输出。
• 可以对阶段进行调整以满足组织需求。它们可以作为一个完整的周期进行迭代，根据需要，相邻的迭代或内部迭代。

♦ 第三部分：ADM 指南和技术

• 指南提供备选方法，用于调整 ADM 流程，处理变化的使用场景。一个例子是如何把迭代选项运用到 ADM。
• 技术是支撑 ADM 循环任务的具体手段。例子包括确定和应用架构原则、利用架构模式、定义业务场景、执行差距分析。

♦ 第四部分：架构内容框架

• 定义一个元模型，把架构工作的输出分类。例子包括交付物、工件和构建块。
• 区分交付物、工件和构建块。为每一个提供具体的内容示例。

♦ 第五部分：企业统一体和工具

• 提供一种架构和解决方案资产分类方法，提供一致性，促进重用。企业统一体有两个内部统一体构成：架构统一体和解决方案统一体。
• 内部的架构统一体根据角色、架构设计、表示、关系对输出（交付物、工件、构建块）进行分类。这种分析可能更多是抽象的，或者与解决方案需要支持的原则有关。架构统一体是解决方案统一体的指南。
• 内部的解决方案统一体提供具体的方法，利用技术和框架，实现架构统一体中的资产。它支持架构统一体。
• 这两个统一体架构类别都是水平排列的——从左（更一般或抽象）到右（更具体）。每个都包含基础、通用系统、行业和特定组织四类。

[点击查看大图]



（1） 39.3 小节，TOGAF 9.1 标准

♦ 第六部分：参考模型

• 提供满足常见业务目标的非常一般化或抽象的架构 & 技术参考模型。
• 例子包括技术参考模型（TRM）架构，提供一般化服务和函数，作为更具体架构的基础。

♦ 第七部分：企业能力模型

• 提供组织结构、流程、角色、职业和技能，以便在组织里建立和运营企业架构实践。
• 在架构委员会、合规审查、契约、治理、成熟度模型和员工技能框架的支持下建立架构能力。

标准的应用

在大概介绍了企业架构和 TOGAF 的好处后，让我们讨论下如何把它运用到组织中。虽然上面介绍的 7 个部分可能看上去非常复杂或是“重量级流程”，但总的来说，它们非常全面。可以把它们看成是住宅或商业大厦的蓝图。

在 TOGAF 中，该标准的这些部分介绍了架构分类、引入迭代方法交付架构、支持的组织结构、指南和技术、治理、促动原则、参考模型、资产库等等。你没必要自己重新创造这些东西。

但是，你并不是需要标准中的所有东西才能成功。你必须知道它提供了什么以及如何有效地运用它。

当引入 TOGAF（或任何 EA 实践）时，一项建议是从小处着手。例如，在开展实现工作时，开始时把 ADM 阶段和组织的项目方法联系起来。对于每个可运用的阶段，识别出所需的输入和理想的输出。执行 ADM 阶段的流程和活动，提供输出和预期的结果。例如，在创建新的目标架构时，运用 ADM 阶段 B、C、D（业务、信息系统和技术架构阶段）建立一个基线架构，然后执行差距分析识别出隐患。另外一个实现 EA 的例子是，着手在一个企业统一体中汇集现有和全新的架构资产。创建一个架构内容框架，开始对工件、交付物和构建块进行分类。

在整个工作过程中，使技术、项目和利益干系人团队参加集体学习，熟悉相关概念和术语。列出 TOGAF 标准已经帮助交付的成果。接下来，在适当的时候，你可以引入一个更正式的流程。介绍需要在组织方面正式确认的东西，如架构委员会和治理实践。至于完整的活动和注意事项列表，请查阅 TOGAF 标准 46 小节（9.1 版本）。

适应其他框架和方法

最后，TOGAF 认可偶尔需要把标准与其他业务、项目或运营管理方法集成。每一种管理方法的动机都是它自身关注的问题。TOGAF 关注满足业务策略的高质量架构。可能需要对它进行调整以使用其他架构框架，如 Zachman 框架。请查阅该标准的 2.10 小节（9.1 版本）了解把 TOGAF 与其他框架混合的指南。提到的方法包括识别架构活动的可交付输出，然后识别输出应该在哪个活动或阶段产生。让我们看两个例子。

示例 1：调整 TOGAF 以适应敏捷方法

敏捷开发方法被广泛应用于以迭代方式开发和交付基于技术的项目。敏捷关注开发和项目，是为了确保交付的产品满足利益干系人的关切。

相比之下，TOGAF ADM 更多的是关注架构，是为了确保目标架构将支持利益干系人的关切，并且支持长期的业务策略。当需要交付目标架构时，应该采用 ADM。不是所有的敏捷项目都需要交付一个新的架构（例如小版本和史诗），因此，就不需要引入 ADM 循环。但是话说回来，ADM 也是一个迭代过程。它很灵活——你可以围绕所有八个阶段进行迭代，或者在单个阶段内部迭代。它是提供健壮目标架构的最佳选项。记住，开发团队依赖你提供一个高质量的架构产品。

如何与敏捷开发团队一起把 ADM 作为企业架构引入？让我们看一个例子。

[点击查看大图]

首先，时间就是一切。从初始阶段到阶段 D 的大部分介绍性工作需要在开发团队接受它并用于解决方案和实现之前完成。这包括以下阶段：初始阶段、架构愿景、业务 / 信息系统 / 技术架构设计。在理想情况下，企业架构师致力于分析、设计和交付，而敏捷团队致力于完成前一个版本。理想时机是在阶段 D、开发团队开始解决方案和实现、进入下一个敏捷版本之前交付最后的企业架构输出。接下来，在解决方案阶段，企业架构师应该自始至终进行监督，确定是否需要过渡架构。架构师应该在后台跟踪迁移计划任务（阶段 F）和实现治理任务（阶段 G），而敏捷团队开发解决方案。敏捷团队交付应该由 ADM 阶段 H 架构变更管理任务支持。

示例 2：调整 TOGAF 以适应 Zachman 框架

虽然一个组织不可能同时引入多个企业架构框架，但有一种可能的情况是正在进行并购。例如，两个合并后的组织可能会使用不同的框架——TOGAF 标准和 Zachman 框架。长期来看，可能会缩减为一个框架，但是，在并购过程中，这两种方法可能需要共存。

澄清一下， Zachman 框架不是一种方法论，它是一种本体论，描述适用于架构的企业结构。TOGAF 是一种方法论，有 ADM 作为交付企业架构的流程，还提供了其他多项能力。不过，调整 TOGAF 以适应 Zachman 证明了 TOGAF 的灵活性。此外，这还可以为组织从 Zachman 转变到 TOGAF 提供一条可行之路，因为与 Zachman 相比，TOGAF 提供了一种更为全面的解决方案。

首先，评估 Zachman 表模型的维数。虽然经过了多年的发展，但总结起来就是下面这些内容。表的列从左向右是使用疑问词什么、怎样、何时、谁、哪里、为何提出的问题。你可以把这些列理解为需要采取什么行动或交付什么东西的线索或提示。表的行从上往下是背景、概念、逻辑、物理和细节等阶段概念。你可以把这些行理解为需要不同输出的不同视角。本质上讲，这个框架涉及项目的所有参与者，详细说明了他们应该提供什么输出，构建一个令人满意的目标解决方案。有人可能会争论说，Zachman 框架不属于架构框架范畴，它更多的是一个项目框架。

在概要介绍了 Zachman 框架之后，我们现在可以调整它以适应 TOGAF 标准了。我们看个例子。

[点击查看大图]

首先，你可以把 Zachman 表的行概念（背景、概念、逻辑、物理和细节）理解为项目的阶段，而不仅仅是视角。Zachman 的背景行可以对应到 ADM 初始阶段和阶段 A——架构愿景。下一个 Zachman 行，概念，与 ADM 架构愿景（阶段 A）和业务架构（阶段 B）存在一些重叠。以此类推，偶尔可能会有轻微的偏差需要解释。

小结

希望你现在已经了解了 TOGAF 的价值以及它如何服务于企业架构。实际上，它是一种深入、全面、适用性强的方法，运用企业架构服务于业务需求。欢迎在评论区反馈及介绍经验。

关于作者

Will Stevens 是一名技术架构师兼顾问， 他有多年行业经验，涉及多种架构，包括软件工程、云、UI、移动。他获得了计算机软件安全理学硕士学位、计算机科学理学学士学位。他获得了多项行业认证，提供独立咨询，并且已经独立推出了两款自制产品 Valloc.com 和 SocialIntuition.co 。

查看英文原文： How the TOGAF Standard Serves Enterprise Architecture