引言
本系列共有三个部分，讨论 SOA 和 EA 的相似点与不同处，并基于实际客户合作项目说明如何处理由于二者的重叠部分造成的潜在问题。在此合作项目中，IBM® 提供了各种业务转换和 IT 外包服务，并负责管理客户的所有 IT 操作——大型机、中型机、台式机、帮助台、语音与数据网络、应用程序开发与维护。该项目要求并行开发 SOA 和 EA。
本系列的第 1 部分提供了 SOA 和 EA 的定义和范围，从而形成框架，以便在二者之间进行有意义的对比和比较。另外，还说明了 SOA 和 EA 不仅仅是体系结构，而且都包括体系结构、治理和路线图。我们在其中详细介绍了二者每个不同的领域和治理框架。
第 2 部分（即本文）将重点讨论 SOA 和 EA 的相似点与不同处，将对二者中的体系结构进行讨论，标识各自对应的领域中的重叠部分。另外还将特别讨论在企业开发 EA 之后（或正在开发时）开始建立 SOA 时可能出现的问题。然后，我们将重点讨论 EA 和 SOA 的治理方面，并进行分析（与我们在开展与公用事业行业的《财富》500 强企业的大型合作项目时对体系结构进行的分析工作类似）。
即将推出的第 3 部分将基于作者在与客户合作而面临类似挑战时获得的经验，提供有关如何处理这些问题的指南。
SOA 与 EA 中的 A
为了确定 SOA 和 EA 的不同领域间的重叠情况，请让我们看看图 1 和图 2。这两张图分别描述了 EA 和 SOA 的对应领域。我们将使用这些图表作为映射的基础。
图 1. EA 体系结构领域
图 2. SOA 解决方案堆栈
下表提供了 SOA 和 EA 的体系结构领域间的映射关系。这个映射关系清楚地说明了 SOA 领域和 EA 领域之间存在大量重叠。
表 1. 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 必须处理的系统管理的一个子集。
体系结构领域：相似点与不同处
下面对考虑 SOA 和 EA 中的体系结构概念时的相似点与不同处进行了总结：
相似点
SOA 和 EA 领域有很多相似点。例如：
- 二者都处理类似的体系结构领域。
- 二者都意在将 IT 与业务紧密相关。
- 二者都使用基于业务目标的输入。
- 二者都需要类似的战略和规划活动。
不同处
EA 体系结构领域的重点在宏观级别，而 SOA 体系结构重点在微观级别。具体如下：
- EA 关注业务组件的定义，而 SOA 关注业务服务。
- EA 处理应用程序框架和企业应用程序，而 SOA 的范围仅限于服务建模。
- EA 处理企业级基础设施和集成方法（服务器、数据库、文件传输、应用程序集成等），而 SOA 仅关注企业服务总线。
- EA 处理所有级别的企业安全性（如应用程序安全性和数据安全性）。SOA 安全性重点讨论与服务相关的问题（例如，SOA 安全性策略供应和联合身份验证）。不过，SOA 安全性必须依赖和利用其他安全性机制（通常为一组企业级安全机制）来处理常规安全问题，如 LDAP/Active Directory、标识管理系统和防火墙等。
潜在问题
由于 EA 和 SOA 体系结构领域存在重叠，当分开进行二者的开发时，可能会出现以下潜在问题：
- 如果企业仅仅将重点放在 SOA，则可能会忽略 EA 的其他方面。例如，可能会忽略 SOA 所支持的集成方法和标准之外的合法要求（例如，点对点接口）或未在企业级加以处理。另外，如果没有 EA，组织可能会出现采用“万能锤子”反模式的情况（如果锤子是唯一的工具，则所有问题看起来都像钉子），会尝试为所有解决方案使用 SOA，甚至对于不会从此体系结构获益的解决方案也是如此。
- 对于 SOA 和 EA 并行开发的情况，可能会由于重复工作和缺少利用现有体系结构构件的机会而出现效率低下的情况。可以想象，开发 SOA 和 EA 的两个团队可能会花费很多不必要的工作精力和资源来实现重复的项目，有时候还可能产生相互矛盾的信息模型、基础设施、系统管理策略、战略和工具等。
- 在没有仔细考虑 EA 和 SOA 具体考虑的内容的情况下，企业可能无法标识 SOA 特定的需求并将其作为 EA 的一部分包含进来（如 XML 和 BPEL 等 SOA 特定的标准）。
治理
根据要治理的领域不同，治理的定义也有所不同，例如 IT 治理、体系结构治理和现在的 SOA 治理。不过，这些不同的治理之间存在联系，我们将在此部分对此进行讨论。
治理的定义依赖于要治理的领域。以下是摘选的不同领域的治理定义：
IT 治理
“由关系和流程组成的结构，用于指导和控制企业，通过平衡风险与 IT 及其流程的回报来实现增值，从而实现企业的目标。”— The IT Governance Institute
体系结构治理
“企业体系结构和其他体系结构的实践和方向在企业级加以管理和控制。这些通常并不会独立操作，而在治理结构的层次结构中进行，特别在较大的企业中更是如此，可能包括企业治理、技术治理、信息技术（Information Technology，IT）治理和体系结构治理。”— The Open Group
SOA 治理
“随着企业提高其在面向服务方面的级别，SOA 治理将扩展 IT 治理。SOA 同时还是跨功能的活动，涉及业务和 IT，共同实现企业战略和目标。因此，SOA 治理必须弥合企业和 IT 治理间的任何差距。”— Kerrie Holley，IBM 科学家
以下的比较重点是治理的组织模型，而不是治理流程或被治理的流程。
治理组织模型
为了支持治理流程，必须建立治理组织，以定义、执行和维护这些流程。本部分将对 SOA 和 EA 的治理组织进行比较。
体系结构治理模型
图 3 描述了 IBM 所述的典型体系结构治理组织模型。
图 3. 典型体系结构治理组织
在此体系结构治理组织中，底层的治理机构处理各个项目，而在中间层次的治理机构建立程序级别的治理（通常监督多个项目的执行）。上层的团队在高于程序级别的级别操作，提供指向外部实体和涉众的必要链接（如果有必要）。对于本文而言，中间层中的体系结构审核委员会（Architecture Review Board，ARB）和体系结构指导组（Architecture Steering Group，ASG）都非常重要。
ARB 具有 EA 的所有权，并负责对其进行维护。在很多情况下，如果没有设计权威，则由 ARB 在开发项目体系结构时向项目团队提供指导。ARB 还负责强制要求各个项目遵循 EA 并在恰当的情况下允许存在例外。
另一方面，ASG 负责建立体系结构策略和解决 ARB 所升级上报的问题。务必注意，ARB 和 ASG 具有明确的不同职责，并与其他两个层次中的治理机构进行严格的交互。
SOA 治理模型
图 4 给出了经过简化的 SOA 治理组织模型。此治理模型中描述的主要团队有：
- SOA 执行指导委员会 (SOA Executive Steering Committee)，负责确定企业中的 SOA 方向。
- SOA 审核委员会 (SOA Review Board)，负责确保 SOA 标准和策略在所有 SOA 相关项目中得以实现。
- SOA 业务委员会 (SOA Business Council)，充当到业务部门（Line Of Business，LOB）组织的连接纽带，以标识要开发且对业务非常重要的服务和确定其优先顺序。
- SOA 卓越中心（Center of Excellence，CoE），负责持续指导和为所有项目的 SOA 开发提供指南。
图 4. 经过简化的 SOA 治理组织
EA 和 SOA 治理：相似点与不同处
此处您会发现，审核委员会和指导委员会同时出现在 SOA 和 EA 治理组织模型中。不过，SOA 治理组织模型可以通过引入 SOA CoE 和 SOA 业务委员会（EA 中没有相应的组织）扩展传统 EA 治理得到。
根据各自的职责，以下列表列出了 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 CoE 负责人和企业架构师的职责之间可能存在重叠。这个职责的重叠可能会导致两个负责人之间存在混淆和分歧，并最终对 SOA 和 EA 的成功造成影响。
- SOA 和 EA 对相同业务资源的竞争。在大多数企业中，业务主题专家的实践和可用性是稀缺资源。因此，要求他们参与 SOA 和 EA 的重复活动及类似的活动和治理组织可能会导致其不能有效地参与和考虑相关问题。这可能会导致这些专家对 SOA 和/或 EA 的活动贡献减少。
- 可能会导致做出影响整个企业的矛盾体系结构决策。虽然 SOA 和 EA 的工作都在同时独立地进行，其中某一边做出的决策仍然可能会导致在依赖于其结果来指导决策的人员中造成进一步的混淆。
总结
在本文中，我们从体系结构和治理的角度了解了 SOA 和 EA 的相似点与不同处。另外，还讨论了企业未对 EA 和 SOA 活动进行协调的情况下可能会遇到的潜在问题。本系列的下一部分（第 3 部分）将基于我们从实际合作项目获得的经验提供有关可以如何处理这些问题的指导信息。
致谢
特别感谢 Ian Charters，他负责 IBM 技术研究院关于 EA 的研究项目，本文中的很多图表都源自此项目。另外，我们还要感谢以下人员在这方面的帮助以及在撰写本文的早期所提供的宝贵意见和建议：Paul Bate、Luba Cherbakov、Claudio Cozzi、Ray Harishankar、Kerrie Holley、Don Hutcheson、David Janson、Steven Barnes、Satish Kalyani 和 Sharon Fortune。