TOGAF是在过去二十年间出现的企业架构框架，其目标是成为 EA 开发的标准。TOGAF 是由 Open Group consortium 成员创建的， TOGAF 不是一开始就体现整体的 EA 焦点。最初，TOGAF 只包括技术架构(版本 1 到 7)，然而，最近该框架中加入了业务架构领域(版本 9，Enterprise Edition)，这快速地将 TOGAF 推向当今 EA 框架选择的第一把交椅。

到添加了业务架构领域为止，TOGAF 已经利用应用、数据和技术架构领域构建了坚固的技术基础。业务架构领域的加入进一步推动了 TOGAF 不断增长的名望，而其他从技术架构开始的框架在它周围度过困难的时期。举例来说，EUP 不得不利用 RUP 的方法、技术和标记符(UML)，而 Zachman、Spewak，和一些其他的框架有意地使它们的指导在高抽象层上，这负面地影响了人们对它们的接受，因为它们没有赢得技术团队的支持。

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

图 1：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)。