TOGAF 的主干是一个包括业务、信息、应用，和技术架构的四维模型：

　　业务架构：定义业务战略、业务驱动因素、治理 (governance)、组织结构、角色定义，和重要的业务流程

　　信息/数据架构：描述一个组织的逻辑数据模型、物理结构，和数据管理资源，包括数据的规类、与业务应用的关系、数据的使用和管理策略等

　　应用架构：对要部署的应用系统，提供一个蓝图，应用间的相互关系，和他们与核心业务流程之间的关系

　　技术架构：描述用来支持业务、数据、应用服务部署的基础设施能力，包括中间件、网络、通信等软硬件，及相关的平台和技术标准等

　　TOGAF 提供一套详细的方法过程(称作 ADM; Architecture Development Method)，依据业务需求，来指导企业架构的开发。ADM 和 Zachman、FEA

　　等框架间没有冲突或矛盾，而是为所有的框架，提供一个从收集、记录现况，然后制定未来蓝图愿景，再分析鸿沟，并制定如何填满鸿沟的计划;一个自上而下的规划过程。

　　看到这里，可能有人会问：EA 工作如果做得好，规划出来的项目都能一一落实，是不是就不需要 SOA 了?换一个角度问，SOA 是否给传统 EA 领域，带来什么新的理念和方法?

　　前面一开始提到，多年下来，许多企业的 EA 组织，在一般 IT 同事的心目中，往往是一群定标准规范、做 PPT、画蓝图，定架构发展路线图的理论家。换句话说，EA 规划和项目的执行成效，落实与否之间，往往有一个断层。在许多企业中，EA 的角色，最后往往流于只是在制定软硬件采购标准这类的工作。但制定标准规范这件事本身，并不能使业务更加敏捷灵活(应该说只有比较间接的帮助)，而这样的贡献，更是很难订出指标来衡量其绩效;在这样的恶性循环之下，EA 的 ROI 很难得到充分的支撑。

　　有人批评 SOA 的 “S”，认为到底什么是“服务”，已经说不清楚了;而这两年市场上关于 SOA 的炒作和杂音，似乎只让问题更为加剧。这是个非常有趣的话题，因为 SOA 给 EA 带来的关键价值，我认为其实正在于此 -- 表面上看，“服务” 的确是个模糊的概念，从业务人员、架构师，到程序员，各自对“服务”的解读，都不相同;但这恰好是 SOA 给 EA 、传统面向应用的需求管理，和项目交付方式，所带来的最大价值。“服务”概念的出现，其最大意义，在于提供了我们一个能贯穿从业务需求、架构规划、项目交付，一路到上线后的运营监控的统一概念 -- 一个具有很长的生命周期、能够全程管理的单元。业务功能能通过“服务”来沟通，并且针对个别服务，制定契约来规范它的功能，以及效能指标、安全要求等非功能性需求。用扎克曼层次化的概念来看，尽管“服务”在各个层次所着重的内容不同，但最终是个统一贯穿的概念;更重要的，是它跨越了传统 EA 和项目交付两大迭代，让 EA 所规划出来的模型和规范，能真正贯彻、落实到项目的执行，甚至于上线后的生产运营，和监控管理(第三个迭代)，将绩效反馈给业务的 stakeholder，形成一个能不断迭代精炼的闭环。这是 SOA 概念及方法论给 EA 和传统面向应用的需求、项目管理方式，所带来最大价值。