IBM®
跳转到主要内容
    中国 [选择]    使用条款
 
 
Select a scope:Search for:    
    首页    产品    服务与解决方案     支持与下载    个性化服务    
跳转到主要内容

developerWorks 中国  >  SOA and Web services | Architecture  >

面向服务的体系结构与企业体系结构,第 3 部分: 它们如何协同工作

从真实的客户项目中总结的经验教训

developerWorks
文档选项

未显示需要 JavaScript 的文档选项

讨论


级别: 中级

Dr. Mamdouh Ibrahim (mibrahim@us.ibm.com), 高级认证执行 IT 架构师兼 STSM, IBM 
Gil Long (gillong@us.ibm.com), 杰出工程师, IBM

2007 年 10 月 22 日

如果您正在采用面向服务的体系结构(SOA),并且同时正在开发企业体系结构 (EA),或者正计划这么做,那么您将从本文中受益。本系列文章中的前两部分对 SOA 和 EA 进行了和对照,并介绍了在企业内部因为不协调的 EA 和 SOA 活动可能导致的问题。在开展价值 16 亿美元的客户业务时(其中涉及到 SOA 和 EA 的开发),本文的作者们开始面对这些问题。在本系列文章的最后这个部分中,我们借鉴他们的经验,并在此基础上提供指导,以帮助您解决这些问题,希望您能够避免重大的失误。

简介和概述

在各种概念、活动、过程、SOA 的结果、EA 以及它们的相应治理方面,存在着大量重叠的地方。例如,SOA 和 EA 两者都需要基于业务目标的输入,并产生依赖于这些目标和对这些目标进行度量的结果。它们的目标都着眼于解决各种企业级的问题(战略和规划、参考体系结构等等)。并且它们的治理模型非常相似。如果您的企业在开发 EA(及其相关的治理)的时候采用 SOA,但却没能认识和考虑到 EA 与 SOA 之间的相似以及重叠之处的话,那么您可能会碰到一些问题。

相关内容:

本系列的 第 1 部分 提供了 SOA 和 EA 的定义和范围,从而形成框架,以便在二者之间进行有意义的对比和比较。它还说明了 SOA 和 EA 不仅仅只是体系结构,确切的说,它们都包括体系结构、治理和路线图。我们在其中详细介绍了二者每个不同的领域和治理框架。

第 2 部分 重点介绍 SOA 和 EA 的相似点与不同处,对二者中的体系结构进行了讨论,说明了它们对应的领域中的重叠部分。另外还特别讨论了在企业开发 EA 之后(或正在开发时)开始建立 SOA 时可能出现的问题。然后,我们将重点讨论 EA 和 SOA 的治理方面,并进行分析(与我们在开展与公用事业行业的《财富》500 强企业的大型合作项目时对体系结构进行的分析工作类似)。

第 3 部分,即本系列文章中的最后一个部分,针对我们并发地开发 EA 和 SOA 的情况,以我们的经验为基础,提供了一个案例研究。我们提供了相应的指导,以解决潜在的问题,并总结了一些经验教训。





回页首


合作项目

有一家《财富》500 强的企业与 IBM® 签订了一份为期 10 年的业务和 IT 外包服务的合同。在此合作项目中,IBM 提供了各种业务转换和 IT 外包服务,并负责管理客户的所有 IT 操作——大型机、中型机、台式机、帮助台、语音与数据网络、应用程序开发与维护。

其中,重要的 IT 转换活动包括下面的内容:

  • SOA 框架和卓越中心(CoE)的建立
  • 在开发和维护应用程序方面,达到 3 级软件工程协会(Software Engineering Institute,SEI)过程成熟度
  • 应用程序组合管理
  • 若干个新的转换项目的开发,以及数据中心和服务器整合项目




回页首


相关的事实和挑战

首先,让我们对所碰到的某些特定的 SOA-EA 挑战进行分解,以帮助我们为有关发生这些问题时的环境提供一些说明:

企业体系结构

  • 我们过去曾认为对于 EA 的需求是出现在销售周期中财务评估阶段的后期。因此,除了企业架构师之外,没有为开发 EA 分配任何预算或者人员。
  • 通过从正在开发的项目中对相关的原则、决策和模型进行抽象,我们决定以增量方式开发 EA,包括整合的财务和会计系统,以及客户服务通用桌面系统。
  • 在这个合作项目启动后不久,为了系统地阐述和证明 SOA 及其治理还仍然处于开发过程中,我们建立了一种称为“稻草人”的 EA 治理结构。

SOA

  • 之所以能够赢得这份合同的某些原因,以及 IBM 及其对手之间的区别在于,IBM 建议 SOA,并在它的开发中展示了领先的地位。
  • 该合同包括 SOA 启动活动的资金和计划,这也为以后的工作创造了一个很好的开始。
  • 只有一个转换项目明显地与 SOA 相关联,而对于其他转换项目在组织和投资方面并没有明确地包含 SOA。这使得在合同签署之后,向这些项目中引入 SOA 可能会导致各种问题。




回页首


建议的治理组织模型

因为该合同明确地要求开发和实现一个体系结构治理模型,所以其中隐含将开发 SOA 治理模型假定为 SOA 启动活动中的一部分。本文接下来的几个部分将对建议的体系结构治理和 SOA 治理模型进行描述。

体系结构治理组织模型

为了建立一种体系结构治理,我们提出了一种由两层组织结构构成的模型(请参见图 1),该模型对 IBM Enterprise Architecture Consulting Method 中描述的治理模型进行了改进。在这种模型中,将两个治理主体称为体系结构管理委员会(Architecture Management Council,AMC)和交付体系结构审核委员会(Delivery Architecture Review Board,DARB)。


图 1. 建议的 EA 治理组织模型
建议的 EA 治理组织模型

AMC 的职责包括:

  • 为客户确定整体的体系结构策略,同时考虑客户的业务策略、技术扫描(包含各种可用技术的赞助研究)以及行业知识。
  • 处理和解决升级的问题。
  • 赞助并实现 EA。

DARB 的职责可以分为以下两类:

  1. EA 的增量式开发和维护:
    • 收集现有的体系结构策略,并对它们进行研究,以确定客户的 EA 适合采用哪些策略
    • 提升与合并单独的项目体系结构决策(那些适合于使企业成为 EA 中的一个完整部分的决策)
  2. 体系结构治理
    • 指导项目体系结构的开发。
    • 通过客户的 EA 监控项目体系结构的遵从性。
    • 在进行硬件和软件的采购,以及开始详细设计与开发之前,作为先决条件,对项目体系结构进行审批。
    • 酌情批准一些例外的情况。

SOA 治理组织模型

在开发和建立 EA 治理模型的时候,建议 SOA 团队使用下面的 SOA 治理组织模型,如图 2 中所描述的。


图 2. 建议的 SOA 治理组织模型
建议的 SOA 治理组织模型

在这种模型中,通过建立三个委员会来管理 SOA:执行指导委员会(图表的顶部)、SOA 业务委员会(右部)和 SOA 审核委员会(左部)。SOA CoE 和建议的集中式 SOA 交付团队共同作为核心 SOA 团队。图 2 还显示了这些管理团体中所包含的各个成员。





回页首


应对挑战

这个部分概述了我们如何解决并发地开发SOA 和 EA 时可能出现的潜在问题。我们将这些问题分为两类(体系结构和治理),并映射到在本系列文章的第 2 部分中所描述的问题。

体系结构相关的问题


潜在的问题我们的解决方案
由于我们对 SOA 的重点关注,而忽略了其他的 EA 方面
  • 我们使得 SOA CoE 和 DARB 分离开来。
  • DARB 重点关注于 EA,而 CoE 重点关注于 SOA。
  • SOA 的领导和企业架构师相互地参与到 DARB 和 SOA CoE 中。
由于重复的工作和错失利用现有体系结构构件的机会,而导致效率低下
  • 我们利用 DARB 审核 SOA 的设计和基础结构。
  • 我们使用企业服务总线(ESB)作为企业集成基础结构。
  • 我们为 SOA 基础结构利用(扩充)现有的系统管理和监控工具。
未能识别并将特定的 SOA 需求合并到 EA 中
  • 与其他的非 SOA 项目一样,DARB 审核相关的 SOA 项目。
  • 我们对 SOA 的定位是,将其作为 EA 功能体系结构域的基础。

与治理相关的问题


潜在的问题我们的解决方案
SOA CoE 领导和企业架构师之间在职责上的重叠
  • EA 是 SOA CoE 的成员,并且 SOA 领导是 DARB 的核心成员,这导致必须共同制定相关决策。
SOA 和 EA 之间对于相同业务资源的竞争
  • 为 SOA 和 EA 共享相同的治理委员会,这样做允许同时解决 SOA 和 EA 的业务资源需求。
可能会制定出影响整个企业的、矛盾的体系结构决策
  • 除了特定的 SOA 相关问题之外,所有其他的体系结构决策都由 DARB 批准。

图 3 显示了我们如何利用 EA 治理组织模型来实现 SOA 治理结构。(请参见图 3 中的大图。)


图 3. 映射体系结构和 SOA 治理组织模型
映射体系结构和 SOA 治理组织模型





回页首


总结的经验教训

通过对这个客户合作项目期间所碰到的问题进行处理,我们总结了关于采用 SOA 和同时开发 EA 的一些很有价值的经验教训。下面的列表突出显示了我们所总结的经验教训,并希望能够帮助您避免碰到这些类似的问题。

经验教训 1:SOA 仅仅解决了 EA 域的一个子集

  • SOA 的范围主要侧重于各种服务及其实现。
  • 大多数的 SOA 活动和决策都属于 EA 功能体系结构域的范畴。
  • SOA 可以利用其他的 EA 域,如信息体系结构、系统管理和为企业建立的任何操作体系结构。

经验教训 2:SOA 治理应该利用 EA 和 IT 治理结构

  • 应该由 SOA CoE 来开发和维护服务模型。
  • 在分析 SOA 治理需求的时候,应该考虑到所建立的体系结构审核委员会和指导委员会。
  • 如果需要,SOA 可能需要一些特殊的委员会,如业务委员会。

经验教训 3:SOA 资金模型在 EA 的范围之外

  • 传统的 EA 模型并不解决资金问题。
  • SOA 资金应该在企业级,而不是项目级。
  • SOA 资金应该利用 IT 资金模型和治理,而不是建立它自己的模型。
  • 应该由 SOA CoE 开发和维护服务模型;然而,应该从 EA 功能域进行引用,而不是复制它。

经验教训 4:SOA 基础结构(ESB)应该是一种企业资产

  • 在处理所有的企业集成需求时,应该考虑 ESB,而不仅仅是正在使用服务的系统。
  • 应该将 ESB 的管理作为企业系统管理体系结构中的一部分进行考虑。
  • ESB 和 SOA 相关的安全应该符合企业安全策略。




回页首


总结

共享本文……

digg 请 Digg 这个故事
del.icio.u 发布到 del.icio.u
Slashdot Slashdot 一下!

在建立了 EA 或者正在并发地开发 EA 的企业中实现 SOA 是很麻烦的。可能会因为它们在影响范围、治理组织、过程和体系结构方面的重叠,导致潜在的体系结构和治理相关的问题。为了在工作过程中减少这些令人头痛的问题,请确保精心地设计体系结构治理和 SOA 治理模型,以及充分地认识到它们应该如何协同工作。充分利用以前总结的经验教训(就像我们在本文中所描述的),以便能够在完成您自己的合作项目期间节省时间和资金。

致谢

我们要感谢以下人员在这方面的帮助以及在撰写本文的早期所提供的宝贵意见:Paul Bate、Ian Charters、Peter De Meo、Luba Cherbakov、Claudio Cozzi、Ray Harishankar、Kerrie Holley、Don Hutcheson、David Janson、Steven Barnes、Satish Kalyani 和 Sharon Fortune。



参考资料

学习

获得产品和技术

讨论


作者简介

Mamdouh Ibrahim's photo

Mamdouh Ibrahim 博士是 Enterprise Architecture and Technology Center of Excellence 的一名高级认证执行 IT 架构师兼高级技术成员(Senior Technical Staff Member,STSM)。他还是 SOA Web Services Center of Excellence 扩展团队的成员。Ibrahim 博士有 30 年的从业和研究经验,曾涉足企业体系结构、SOA、分布式技术和无线技术等领域。他是 IBM IT Architect Certification Board 的成员,也是 IBM Architectural Thinking 课程的教材编写人员和讲师。Ibrahim 博士拥有计算机科学博士学位,计算机科学、固体科学和数学硕士学位以及电气工程和数学学士学位。他是 Central Michigan University 的兼职教师。他曾担任过 OOPSLA 2002 大会主席,目前担任 OOPSLA Steering 委员会主席(到 2008 年卸任)。他是 ACM、IEEE 计算机学会和 AAAI 的成员。


Gil Long's photo

Gil Long 是 IBM 的一名杰出工程师。他目前担任 Worldwide Enterprise Architecture Education 负责人和 SOA Governance 集成负责人,尤其擅长企业级体系结构设计和过渡规划及 SOA 基础设施规划方面的工作。Long 先生在所有 IT 领域都具有丰富的高级管理经验,包括 IT 战略规划、体系结构设计、业务系统设计与实现、系统与网络设计及部署和数据中心运作。他负责直接管理大型 IT 组织设立、人员配备和预算可靠性。他还具有多个行业的相关经验,包括卫生保健、金融服务、教育、零售、保险、公共事务、制造和政府部门等。




对本文的评价

太差! (1)
需提高 (2)
一般;尚可 (3)
好文章 (4)
真棒!(5)

将您的建议发给我们或者通过参加讨论与其他人分享您的想法.




回页首


IBM、IBM 徽标和 WebSphere 是 IBM 在美国和/或其他国家/地区的注册商标。 其他公司、产品或服务的名称可能是其他公司的商标或服务标志。

IBM 公司保留在 developerWorks 网站上发表的内容的著作权。未经IBM公司或原始作者的书面明确许可,请勿转载。如果您希望转载,请通过 提交转载请求表单 联系我们的编辑团队。
    关于 IBM 隐私条约 联系 IBM 使用条款