BPM 和 SOA 的最佳实践和最差实践

Peter Woodhull 在他的新作“BPM 和 SOA 中的最佳实践和最差实践”开篇这样写道：

很多企业继续借助于 BPM 和 SOA 追求业务流程效率和效用的提高，但还是失败了。而促成或破坏一个项目的方法都有好几种。

Peter 讨论了一些 SOA 和 BPM 实施的最佳实践和最差实践。在他看来，以下是一些最差实践：

先买软件。Peter 认为，最坏的错误是一个 BPM/SOA 的项目从评估和购买软件开始。问题是很少有公司能够真正事先知道他们需要那类软件，把解决方案往买软件上靠的做法无异于让别人来掌管你的业务。

……大部分从软件购买开始的项目都是有 IT 部门负责的，并且其最终结果往往是自底向上的支持和实现的策略。这种做法和业务的战略目标脱节，因为它更偏向于以技术为中心而不是以业务流程及业务需求为中心。

不重视组织结构的变化。因为人们总是反对变化的，不论变化是否能够给他们的工作带来便利。

对于即将开发的新流程和系统，如果用户能够以合适的方式参与进来，并且有机会去评审、加注、验证以及做辅助决定，那么，人们将消化这些变化并接受它们。

试图“煮沸整个大海”。将一个 BPM/SOA 的解决方案的实施当作大范围的翻新并铺开的做法是几乎不可取的。

BPM 和 SOA 的工作本身是不断发展的，最好以一种小规模、受控并且频繁发布新能力的方式迭代成长，其能力应该以一种受控的迭代方式展开。流程和服务应该分开管理和实施，从而为其用户群带来即时价值

最佳实践，Peter 也描述了以下几条：

一切始于发现。Peter 认为在没有对问题有清晰了解之前就提出解决方案的做法是很多失败的原因之一。

准确定义将要管理的流程并文档化服务合约（WSDL 文件和数据结构），这是任何实施项目最首要而且最重要的工作。一旦流程规约被准确而清晰地记入文档，并且通过客户以及合作伙伴的验证，签名和批准后，只有在这之后才能由开发团队实施开发和原型设计。

BPM 和 SOA 应是一个复合解决方案。很多人认为 BPM 和 SOA 是两个不相干的事物，经常由不同的部门实施，并且具有不同的优先级。

BPM 和 SOA 实际上是……解决业务上的一些常见且普遍存在的问题的策略和技术。而且……技术平台对它们都有很好的支撑。BPM 套件是非常有效的整合工具，特别是存在将人和计算机系统集成到一个统一的解决方案的需求时，而 Web 服务和 SOA 技术是实现代码重用以及在计算机系统、平台以及组织之间实现互操作的很好的机制。

从关键任务流程开始。和任何新的方法一样，SOA/BPM 也需要通过验证才能赢得管理层的支持。

从某个关键任务的业务流程开始，而且，其价值应该可以明确并且可以量化。理想情况下，应该选择一个正好是客户关心的且没有明确的解决方案的业务流程……这样的结果将是公司的业务部门负责（业务流程的）实施，而不是由 IT 部门负责。

Peter 在文章结束时强调了 SOA 和 BPM 联合实施的复杂性及其强大能力。他还鼓励采取业务驱动而非技术驱动的方法进行 SOA 和 BPM 实施，紧随其后是“几要几不要”的建议，这些建议虽然不能确保成功，却可以降低失败的风险。

查看英文原文: Best and Worst Practices in BPM and SOA