TOGAF 组件

TOGAF 的一个关键组件是架构开发方法（Architecture Development Method，ADM），是用于具体到组织的企业架构实现和裁减的过程。除了 ADM，TOGAF 包括一个通称为“Enterprise Continuum”的参考资产集合。TOGAF 预想，Enterprise Continuum 成为一组可复用的构建块（模式）集合，向企业架构团队提供可以像乐高玩具那样使用的参考架构、模型和过程。

TOGAF ADM

TOGAF 架构开发方法为实现和执行组织的企业架构提供完整的指导。该过程包括闭合循环中的多个，连续的阶段（参见图 10）。

图 10：TOGAF 架构开发方法（Architecture Development Method，ADM）

初期的目标是确定实现过程涉众，并且让它们面对企业架构工作的内容。该阶段交付基于组织业务法则的架构指导方针（Architecture Guiding Principles），并且描述用于监控 EA 实现进展的过程和标准。

过程的阶段 A 用于明确 EA 远景。架构远景（Architecture Vision ）工件利用业务推动者明确企业架构工作的目的，并且创建基线和目标环境的粗略描述。如果业务目标不清楚，那么该阶段中的一部分工作是来帮助业务人员确定其关键的目标和相应的过程，这些企业架构都必须支持。同样是该阶段中生成的架构工作描述（Statement of Architectural Work），勾勒出 EA 的范围及约束，并且表示出架构工作的计划。

阶段 B 用于详述关于业务领域架构的工作。架构远景（Architecture Vision） 中概括的基线和目标架构在此被详细说明，从而使它们作为技术分析的有用输入。业务过程建模、业务目标建模和用例建模是用于生成业务架构的一些技术，这又包含了所期望状态的间隙分析。

阶段 C 涉及应用和数据（信息）架构的交付。该阶段利用基线和阶段 A（Architecture Vision）中开始的目标架构，以及业务间隙分析（业务架构的一部分）的结果，在范围内，并根据架构工作描述（Statement of Architectural Work ）中所概括的计划，为目前和展望的环境交付应用及数据架构。

阶段 D 利用技术架构的交付完成了 TOGAF ADM 循环的详细架构工作。如前面的阶段里，间隙分析和草案架构用作基线，由于初期对架构指导原则达成一致。建模标记，例如 UML，在此阶段中被积极地使用，从而生成各种观点。

阶段 E 的目的是阐明目标架构所表现出的机会，并概述可能的解决方案。此阶段中的工作围绕着实现方案的可行性和实用性。此处生成的工件包括实现与移植策略（Implementation and Migration Strategy）、高层次实现计划（High-level Implementation Plan），以及项目列表（Project List），还有作为实现项目所使用的蓝图的已更新的应用架构。

阶段 F 将所提议的实现项目划分优先级，并且执行移植过程的详细计划和间隙分析。该工作包括评估项目之间的依赖性，并且最小化它们对企业运作的整个影响。在此阶段中，更新了项目列表（Project List），详述了实现计划（Implementation Plan)，并且将蓝图传递给了实现团队。

随着项目列表的稳定，重点就移动到为每个实现项目明确更具体的目标和推荐。在阶段 G 中，建立起了治理架构（TOGAF）和开发组织之间的关系（例如，可能由 RUP 和项目管理知识体系（（Project Management Body of Knowledge，PMBOK) 的组合，或其他项目管理方法所规定），并且在正式的架构治理下实现所选的项目。阶段的交付内容是开发组织所接受的架构契约（Architecture Contracts）。阶段 G 最终的输出是符合架构的解决方案。

阶段 H 中的重点转移到实现的解决方案的交付所达到的架构基线的变更管理。该阶段可能会生成为企业架构工作的后继循环设置目标的 架构工作请求（Request for Architecture Work）。

TOGAF Enterprise Continuum

Enterprise Continuum 是资源库，例如，模型、解决方案模式，和其他可以在企业架构实现和裁减过程中用作构建块的资产。实质上，Enterprise Continuum 类似于 EA 专业人员和涉众的资料库。

除了 ADM 和 Enterprise Continuum，TOGAF 还提供关于用于计划并实现企业架构的技术、方法和解决方案的附加资料和参考。
TOGAF 是迭代的吗？

如图 10 所示，TOGAF 是迭代的过程。TOGAF 迭代（常称为循环）通常比 RUP 迭代要长，并且跨越企业架构实现及维护的多个阶段。这并不奇怪，因为 EA 的范围比单个的 RUP 项目大得多。

需求管理和 TOGAF

如图 10 所示，TOGAF —— 照字面意义 —— 是以需求为中心的过程。ADM 需求管理处理所有类型的需求，包括显著的业务推动者、关系，及新的功能和变更请求。最后但并非不重要的是，由于架构需求从属于持续的变更，所以需求管理在整个 EA 实现生命周期中都会发生。

TOGAF 和其他方法

在现代组织中，TOGAF 必须与其他方法、过程和框架共存。它们中的一些，像 RUP，不共享公共的范围，而其他的，像 EUP 和 Zachman 框架，在 EA 生命周期上有一部分重叠。

TOGAF 与 RUP 的交汇点

TOGAF 有时候看上去像 RUP 的替代，但其实不是。虽然两个框架之间有许多共同的模型和主题，但是它们有不同的推动者和目的。

TOGAF 和 RUP 之间的原则差别是 RUP 是技术架构驱动的，然而，TOGAF 是业务架构驱动的。在 RUP 中，收集业务需求，来设计并交付基于软件的系统，而在 TOGAF 中技术被视为实现业务远景的方法。

作为软件开发生命周期（Software Development Life Cycle，SDLC）方法的 RUP 的目的是支持及时且有效的应用程序交付。对比 TOGAF 的目的，TOGAF 支持企业架构实现和维护。图 11 展示了 RUP 和 TOGAF 生命周期重叠的程度。

图 11：RUP 和 TOGAF 的生命周期

在 TOGAF 实现过程中有一个与 RUP 交叉的明确定义的点。交集的起始点在阶段 F 的开始处，此时，架构蓝图（应用程序模型）、业务架构、和高层实现移交给了实现团队。当两边都同意实现的范围时，移交视为完成。与此同时，签署了详述小组职责及架构实现治理原则的架构契约（Architecture Contracts）。图 12 中提供了关于 TOGAF 和 RUP 之间工件流的细节。

图 12：TOGAF 与 RUP 之间的工件流