TOGAF 和 Zachman Framework

虽然 TOGAF 和 Zachman Framework (ZF) 属于一类“企业框架”，但是它们在方法、组成，和工作范围上都有差别。

ZF 是结构化的（静态的）框架，当用作方法及框架的工件和元分析的分析和分类的模型时最有效，而 TOGAF 是过程（动态）框架，还包括使用它们的参考过程模型指导。尽管有这些基本的差别，我们还是有很大可能一起应用这两种框架：

• 利用 ZF 作为工件的字典和交付结构，将 TOGAF 用作工件交付过程

• 用 ZF 设置转换 TOGAF 和其他解决方案方法之间的工件，例如，RUP 和/或 IT Infrastructure Library (ITIL) ，的结构

• 在实现 TOGAF 过程中或之前，利用 ZF 进行现有企业过程和业务模型的间隙分析

• 利用 ZF 进行 TOGAF 的元分析，这可能导致对其弱点的确定，以及与其他方法的可能接口。

• 将 ZF 用作设计 TOGAF企业架构模型的助手（TOGAF 阶段 B-D）

TOGAF 和 EUP

虽然 EUP 和 TOGAF 都工作于组织层面上，但是它们的范围不同。EUP，将 RUP 扩展到企业级，引入了七个新的规程 —— 企业架构是其中一个 —— 并对它们的应用提供指导。虽然大多数 EUP 规程工作于组织层，并且作为企业架构过程的输入，但是 EUP 本质上不是企业架构开发框架。（尽管 EUP 可能在 RUP 的未来实现方面进行变更。）

对比 EUP，TOGAF 只关注企业架构规程。从一开始就期望，并将其创建为企业架构实现的框架。

尽管 EUP 和 TOGAF 在视角上有差别，但是 EUP 所引入的规程对企业架构实现非常重要。举例来说，企业业务建模（Enterprise Business Modeling）对于对现有业务过程的“构架”变更来说是有帮助的，而投资组合管理（Portfolio Management）是企业架构师分析潜能，并监控（或 EA 术语中的治理）正在进行的实现的“必用”工具。

可能出现的 TOGAF 实现障碍

TOGAF ADM 不是端到端的过程，它是框架，且同样需要具体到组织的裁减。裁减采用强大的方法，及丰富的商业模型知识 —— 不容易找到的质量。情况因 TOGAF v 8.0，Enterprise Edition 是相对新的过程，拥有有限的上路经验这一事实而变得复杂了。

它可能很难让涉众使用 TOGAF。通常要利用有影响的雇员让高级管理层和职员相信，TOGAF 过程和模型应该弥补并替代那些他们熟悉的内容。

尽管 TOGAF 最近有了一些增强，它仍不像其他方法那样详细，特别是在其业务和技术联络的核心领域。例如，TOGAF 不包含像 Rational Method Composer 或 MyRUP 的东西，它也没有全面的周期库可用。

成熟的组织，特别是那些常规地使用项目管理和软件生命周期方法的，例如 PMBOK、RUP、Scrum，和 ITIL，在企业架构的实现上更加容易成功。我推荐组织在引入 TOGAF 之前先适应几个技术、标记，和 SDLC 方法，如图 13 所例举。

图 13：TOGAF 实现路线图

对成功的 EA 实现的其他潜在威胁包括缺乏用于获取并管理 EA 工件的标准工具，并且缺乏标准标记符。

TOGAF 或非 TOGAF？

组织要做出的最初选择是是否实现企业架构，而 TOGAF 是演进中的下一个逻辑阶段。通常，成功且一贯使用解决方案生命周期方法，如 RUP 的组织将 EA 的实现视为演进的下一个里程碑。

很关键的是，在组织中不用强迫实行企业架构。对企业架构实践的需求应该是人们了解了业务过程和结构的管理与支持技术基础框架的结合的不断发展的复杂性的结果。 9
如果您不确定 TOGAF 是否适合您，那么在您的组织中试用一下是个好主意。试验可能要包含一组热情且值得信任的解决方案及业务架构师。重要的是要加入业务和技术角色，以确保利益均衡。还要注意，要想成功，EA 实现必须保障组织中的支持。要确保支持，可以加入一名执行团队的成员，作为 EA 团队的代理，或者让企业架构师进入组织的领导委员会。