SOA和EA的关系

　　最近SOA炒得火热，作为一种面向服务的体系结构，颇受各大厂商推崇。EA领域经过20多年的发展，在IT系统日益复杂、投资回报较低的今天，也再次引起人们的关注。SOA 和EA作为架构有什么异同呢？

　　简单总结了一下IBM的网站上一篇文章《面向服务的体系结构与企业体系结构》，SOA和EA异同如下：

１、体系结构方面

SOA 和 EA 体系结构领域之间的映射
体系结构领域 SOA 解决方案堆栈 EA 框架 业务 业务流程 业务体系结构 应用程序 服务与组件 应用程序体系结构 集成与中间件 集成体系结构/ESB 技术体系结构 数据 数据体系结构 信息体系结构 操作 QoS、安全性、监视和基础设施 技术体系结构

不过，很显然 SOA 领域是 EA 领域的子集。例如，SOA 不仅考虑业务体系结构开发。而且会使用业务流程的输出和其他业务体系结构构件（如组件业务建模（Component Business Modeling，CBM））作为输入来标识业务服务。相反，EA 考虑业务体系结构的开发，包括业务流程和 CBM 等。类似地，从应用程序体系结构的角度而言，SOA 考虑的是服务及实现服务的组件的建模和开发，而 EA 体系结构不仅处理特定于 SOA 的构件，而且还要处理整个企业的其他组件、包和系统。

分析技术体系结构时，SOA ESB 只是 EA 可能需要处理的众多集成机制中的一个而已。另请注意，SOA 并不处理内容管理体系结构 (Content Management Architecture)，而 EA 会处理此问题。

另一个重叠区域是安全性和服务管理。事实上，SOA 安全性是必须指定的总体安全性的一个特例，SOA 服务管理和监视是 EA 必须处理的系统管理的一个子集。

EA 体系结构领域的重点在宏观级别，而 SOA 体系结构重点在微观级别。

２、治理方面

SOA 与 EA 治理组织的可能映射方式：

• SOA 执行战略委员会 (SOA Executive Strategy Committee) 映射到体系结构指导委员会
• SOA 审核委员会映射到体系结构审核委员会
• SOA CoE 可以映射到设计权威（Design Authority）（这是在英国、欧洲、中东和非洲非常流行的概念，但在美国不常用）；不过，即使存在设计权威，企业仍然可能会选择建立 SOA CoE 来确保实现采用 SOA 所能带来的好处。
• 在 EA 环境中通常不存在 SOA 业务委员会。

总的说来，SOA 和 EA 治理有很多相似点与不同处：

相似点：

• 都需要执行委员会进行监督。
• 都需要审核委员会。
• 都处理企业级的问题。
• 都努力确保业务和 IT 涉众得到完全的考虑。

不同处：

• SOA 需要通过与业务单位进行紧密交互的 SOA 业务委员会的形式了解业务方面的更多策略信息。
• SOA 可能需要特定的方法来保证实现的资金投入，而传统 EA 治理模型对此并不会加以考虑。
• SOA CoE 是一个独立的实体，在 EA 组织中没有直接的对等项。
• 虽然 EA 治理从总体领导和资助的角度（战略）看待治理，而 SOA 治理将其视为策略领域的东西，使用工具进行治理（这实际上更多是管理，而不是治理）。

 

另外劳虎顾问有一篇《乐见 SOA 和 EA 融合之势  》文章，谈到了SOA和EA领域的协作和融和，SOA给EA带来了新的价值。王仰富先生的《SOA与企业IT架构规划》也谈到了SOA和架构规划的一些关系。

总体讲，正如劳虎顾问文章标题所述，融和是个必然的趋势。