构建成功的 SOA 项目

发布: 2007-11-20 18:34 | 作者: Tina Abdollah | 来源: IBM | 查看: 56次 | 进入软件测试论坛讨论

从架构师的角度了解面向服务的体系结构 (SOA) 开发过程的主要阶段。了解实现成功的 SOA 项目方面的经验教训和最佳实践，包括组织准备情况、用户的角色、对流程进行转换、基于资产的支持和工具要求。

Saugatuck Technology、Gartner 及其他公司所做的行业调查表明，无论各自的基础技术如何，很多大型企业都采用了或要将面向服务的体系结构（Service-Oriented Architecture，SOA）作为其战略方向加以采用。

在最近的一项调查中，Saugatuck Technology 发现“SOA 正逐渐在大中型企业中缓慢但稳定地推广开”。¹（请参见soa/index.html?ca=drs-cn#resources">参考资料。）在此项调查中，他们与在大中型企业工作的高级 IT 管理人员（用户）和应用程序架构师进行了 40 次深入的访谈，注意到“所采访的 37% 的高级 IT 管理人员都表示其公司目前正处于 SOA 部署的有限或完全生产阶段”¹。

虽然注意到 Gartner 预测在接下来两年中所有新应用程序中将有 80% 将基于 SOA，但 Saugatuck 的调查表明用户的期望非常乐观，指出“到 2008 年，将有接近 67% 的用户将使用有限或完全的 SOA 生产环境”。¹其他 Saugatuck 研究数据表明，到 2008 年，会有不到 45% 的大中型企业会采用有限或完全的 SOA 生产环境。在任何情况下，下一年大中型企业中有 45% 到 80% 采用 SOA 都是非常显著的变化了。

随着将 SOA 应用于更为复杂的任务，将会出现更多复杂情况。复杂任务涉及到各种类型的集成模板，用于处理不同的业务挑战和需求，如遗留集成与转换、应用程序、打包应用程序集成、组合业务服务和自定义开发。

作为架构师，您经常在将业务需求和 IT 需求应用到 SOA 项目中扮演着领头雁的角色。本文讨论在从传统开发向 SOA 的过渡中的一些主要成功因素和经验教训。

回页首

评估组织准备情况

架构师必须处理 SOA 项目中的很多错误和挑战。一个主要的挑战就是组织准备情况。但是在处理此挑战前，务必确定 SOA 能够给组织带来什么样的价值，并指定恰当的转换计划。

很多 SOA 项目的启动都是仅仅因为客户在长期战略中需要 SOA，不过并没有实际确定 SOA 可能带来的好处有多少，或者确定哪些业务区域可以得到改进。这样将得到定义槽糕的交付计划和范围，而随后会因为没有达到客户的预期而导致客户满意度下降。如果在早期销售周期中参与者没有足够的 SOA 知识来确定工作范围或在签署合同前向客户传递相关知识，则可能会导致预期不当。显然，同样重要的是，交付团队和客户都要全面了解 SOA。

有关 SOA 的观点通常可归为两类：SOA 是最好，或者 SOA 一钱不值。这是两个极端，而 SOA 实际上位于两者之间的位置。不幸的是，作为架构师，您可能需要面对支持这两种观点中的一种的客户和开发团队成员，因此要么过度积极，要么过度消极。克服这些极端思想，需要在 SOA 开发过程中进行大量的理念传递和培训。

“SOA 并不是什么新东西——全是假想，没有实质。”: 要克服有负面影响的谬论和驳斥不相信 SOA 的人，您可以指出 SOA 在 20 世纪 90 年代早期就出现了，已经取得了长足的发展。还要务必记住，与其他技术（如 CORBA）相比，今天的 Web 服务标准已经得到了更广泛的行业和用户的接受，而这也对 SOA 的推广起到了促进作用。
“SOA 是革命性的范式变迁，是万能药。”: 对于过分乐观的观点，您需要指出，SOA 更多是发展的结果，而不是革命性剧变的结果。在进行类似的事情方面比以前有所改进，只是更好了。这不是范式变迁，不过这是一个重要的转变。SOA 对企业处理分布式计算的方法进行了发展，对其实现进行了改进，但 SOA 并不代表着可以视为革命性的突破性变更。

SOA 在经常受到业务环境的频繁更改影响的异类环境中尤为有用。您需要首先向客户确认其 IT 环境是否是同类环境。如果是，则 SOA 可能并不适合该客户的情况。高性能是否比松散耦合更为重要？客户是否希望对 IT 功能进行严密的控制，以尽可能提高性能？如果是，则 SOA 也不适合他们使用。即使是能够从 SOA 获益的公司，也不要假定他们所需要的唯一体系结构就是 SOA。毕竟，SOA 能很好地与其他体系结构并存，而 SOA 本身并不能解决信息和语义集成挑战。公司需要其他技术方法来解决这些更具挑战性的问题。

在启动 SOA 项目前，应回答以下问题：

SOA 带来了对业务什么样的实际承诺？
为什么要在 SOA 投入资金来提高组织的收益？
SOA 将为业务带来什么样的好处，组织应该如何做来确保投资在将来有回报？

可以用于帮助派生出长期和短期战略、热图和 KPI 值的一项技术是组件业务建模（Component Business Modeling，CBM）。我们知道 SOA 的承诺是构建足够灵活的 IT 基础设施，以响应业务的需求。由于具有这么广泛和战略意义的价值主张，因此很容易看到 SOA 是无法回避的趋势。但是，每个组织都需要做到以下几点，仔细地计划从传统开发组织过渡到服务组织的工作：

始终保持开放态度
不受制于内部或外部派系利益
注重“全局”

通常这些都是项目所面临的最严峻的挑战。

将组织向服务过渡的过程需要时间、人力、流程、方法和工具支持。这是一项长期的体系结构战略，目的是为了满足业务目标，需要采取渐进的方式才能获得其承诺的好处。在开始项目前，务必了解组织所处的位置和准备情况。要确定项目的范围和所需的工作，应该在做出任何建议前确定组织的准备情况。SOA 路线图能够帮助保持增量计划的战略性。不幸的是，并非所有 SOA 项目都考虑了全局。

回页首

获得涉众支持

组织中的不同人员各有自己不同的考虑，而这在 SOA 转换过程中有着非常大的影响。“业务优势”对不同的人员有不同的含义。无论是 SOA 还是非 SOA 项目，架构师在整个开发过程中都经常必须面对各种类型的人。

我们都知道涉众的支持对任何项目的成功都非常重要，但对 SOA 项目尤为重要。SOA 活动应该由业务人员在考虑业务目标的情况推动开展，因此与传统开发项目相比，此类项目需要更多的业务涉众参与。不幸的是，技术人员所支持的 SOA 项目的有些业务优势根本与业务不相关，而是只有 IT 部门能够感受到其影响的技术优势。