你的架构应该关注 SOA，还是 BPM？

SOA 在时髦术语标签云里面风光无限的同时，BPM 的名气正变得越来越响。当组织逐渐明白想从 IT 投资中获得收益需要驯服组织间各种各样的流程时，BPM 在 IT 圈内圈外正得到重视，认同和关注。对你的构架来说，哪一个更重要呢？以 BPM 作为 SOA 平台，又或是将 BPM 作为指导实现 SOA 的基本理念，这两个概念之间的联系正变得越来越紧密。

BEA 的 Dain Hansen 最近发表了“ SOA 整合的成功蓝图”，对如何在组织中实施 SOA 给出了详细的指导。在讨论过程中，Hansen 指出了 BPM-SOA 整合的重要性。

我们在谈 IT 和 ERP 系统的整合的时候，也需考虑它们对业务分析师或业务部门（LOB）的影响，因为是他们真正使用这些数据和服务来完成日常业务。这两个往往看似矛盾的元素需要通力协作才能成为一个完整的整合解决方案。当 SOA 和 BPM 都表现良好时，我们才能看到巨大的收益。此时，不仅能使 IT 和业务部门中各角色协调一致，而且还能以两个阵营都能成功管理的最优方式实现流程……一旦在 SOA 整合过程中实现了自动化的业务流程模型，业务分析师就可通过集成的业务活动监控功能获得运行时反馈，触发一个优化过程。这让业务使用者能实时观察到哪些流程需要改进。一旦识别了改进环节，业务分析师就能同时更新模型和业务，此时开发周期又进入了下一个循环。这种迭代式业务——整合循环实现了真正的业务转型与优化。

为了达到这样的收益，SOA 和 BPM 需要以这样的方式来整合：组织里的用户需要有公共统一的工具来共享元数据、治理和管理信息，并最终优化业务流程与流程翻译方法（将它们翻译成后端整合）之间的互操作性。

Quinton Wall，同样来自 BEA，最近谈到了将BPM 和SOA 相结合以最大化业务的机动性。Wall 认为组织可以在SOA 基础上综合利用BPM 工具来达到IT 和业务的一致性：“技巧在于使业务端的改变以一种受管制的方式进行，并削弱它对IT 的依赖性。” 这意味着，BPM 能够让业务部门的执行者充分享用服务和服务组合好处的同时，减少了IT 的介入。BEA 的建议是从“SOA 优先”的立场所作出的，并假设组织已一定程度的面向服务化。其它几位则是以业务流程为中心的角度来考虑BPM 和SOA 的联姻。

Rich Seeley 讲到了特拉华电力公司的 SOA 实施以及 IT 副总裁 Gary Cripps 是如何让它成功的。Cripps 表示，业务流程分解方法在这一过程中发挥了巨大作用。

“我一开始就将所有的流程进行了分解”Cripps 解释到，“我的发现是，参与这样级别的一个 SOA 项目，我们花了百分之五十五的精力在定义流程上。百分之五十五，这令我很吃惊。百分之二十的时间是用于编写代码的。剩下的百分之二十五花在了测试和实施上。”这对那些考虑 SOA 的中小企业来说是个好消息，Cripps 说道。业务流程的界定和建模可以由包括部门涉众在内的核心团队来完成，百分之二十的编码工作则可以外包。

在内部，SOA 团队成员转变了他们思考应用的模式，开始按照业务流程来思考，Cripps 说。“当我们转为面向服务时，就我的团队成员而言，这真正地提升了他们的知识。因为理解一个跨多个部门的特定事务的业务流程和业务规则需要花相当大的努力。”他讲道。

Seeley 同时指出，在转向 SOA 的进程中，业务分析师的角色发生改变了。引用自iTKO 公司首席科学家John Michelsen 的说法，Seeley 写道，在SOA 实施中受影响最大的是业务分析师需求分析的职责，而不是IT 部门开发组件的职责。 > “我认为说编码人员个体受影响最小是公平的。因为他或她所做的不外乎拿到需求，构建组件，测试组件，再将组件插入到更大的系统”他说到，“这和五年前所做的事没任何区别。所以，具有讽刺意味的是，开发人员也许成了受SOA 影响最小的人。”

在这两个例子中，Seeley 都引出了在建设和实施SOA 时业务流程管理和分析的重要性。Dennis Byron 指出 BPM 现已名副其实地属于软件堆栈的顶层。Byron 的观点是，BPM 已经不再是集成层的一部分——这是从 IT 立场出发的定位——而是上升到了整个软件堆栈的顶级。从业务角度来看整个软件堆栈，IT 可以“将 BPM 视为一种建立在面向服务架构（SOA）方法学基础之上的‘新型开发范式’”。

为了找到“BPM 还是 SOA？”这个问题的答案，Neil Macehiter 和 Neil Ward-Dutton 阐述了在现代组织中这两个概念分别扮演了什么样的角色。抛开了“BPM 是自顶向下，业务驱动的创新；SOA 是自底向上，技术驱动的创新”这种传统观念，Macehiter 和 Ward-Dutton 阐述了“‘面向服务同时面向流程；自顶向下同时自底向上’的立场是如何以一种更全面的视角来消除业务与技术架构的分歧。”紧接着这些陈述 Macehiter 和 Ward-Dutton展示了流程和服务的概念是如何通过‘输出（outcome）’统一起来的:

输出（outcome）就是预期到的结果。一个最高层输出（outcome）可以是一个组织的核心价值，财务表现等等这样的东西。在这一层次，输出（outcome）可能和使命宣言直接联系。 再低一点的层次输出（outcome）可以是一些操作结果——比如“产品已经交付”。服务是对达到输出（outcome）的承诺。流程是完成输出（outcome）的手段。

他们俩这样总结了对 BPM/SOA 的观点：“事实是，输出（outcome）是硬道理，服务和流程是达成目标的一体两面。”查看英文原文： Should your architecture focus on SOA or BPM?

译者简介：黄璜，2007 毕业于重庆邮电大学计算机学院。现从事 Java Web 开发，供职于成都 ISSC, 熟悉 Struts,Spring,ibatis，关注语义网，SOA，云计算等领域。个人主页： http://www.chinacomputing.org ， 联系方式 huangh@cn.ibm.com 。参与 InfoQ 中文站内容建设，请邮件至 china-editorial@infoq.com 。