对于SOA我们一直强调最终的目标是要、应用集成，再到流程集成，这是通常实施SOA的一个顺序。但是对于SOA的实施也可以是一个迭代的顺序，即找一个有端到端流程整合的业务场景为导入，以该流程整合分析入手，从顶向下识别和分析需要整合的内容和提供的服务，形成候选服务清单后对服务进行评估，完成服务定义和服务开发，最终对服务进行编排实现我们期望的流程。

　　对于SOA实施来讲，真正要做到流程整合是比较困难的一件事情，但是如果有底层服务资产库的良好支持，那流程整合就会变得容易，所以底层服务资产库的形成，服务需求分析和服务的识别一定要以流程驱动进行，保证识别的服务具有很好的可重用性，识别的服务能够为流程服务。

　　为何要进行流程整合，因为流程之间存在断点；为何流程之间存在断点？因为业务系统只关注它自己一块具备范围的业务。为何业务系统存在这种局限性？因为业务系统往往由企业的某一个业务部门主导建设，而业务部门存在明细的业务和职权分工，业务人员在建设业务系统的时候更多的是关注业务系统能够完成本业务部分的业务支撑需要。

　　由于烟囱或竖井式的建设，导致端到端流程本身的割裂，原有大流程被业务系统拆分为多个独立的子流程，端到端流程整合变化为在各个业务系统中的各个子流程的融合。而流程融合的底层仍然是数据的交互和集成，通过数据的交互和集成以解决全流程的集成问题。

　　综合上面的分析，最核心的问题在于企业需要的是流程视图或业务视图，而现有的业务系统实现的是功能视图，业务系统现在更多的看到的是功能，而非流程；功能可以解决单个业务功能点的问题，但是无法看清楚全流程的问题。

　　再回来谈SOA下流程整合的难点，初步分析主要包括如下几个方面的内容：

• 　　前期识别的数据服务或业务服务无法为流程整合服务，主要原因是流程分析识别方法没有安装业务和流程驱动的方式进行，单纯的将原有业务系统的接口转化为服务。
• 　　业务系统建设已经初具规模，业务人员已经有根深蒂固的业务系统的概念，各自为阵，流程整合的实现最终会在流程平台或门户系统，仍然导致业务人员使用多个系统。
• 　　对于BPEL重点是业务流自动编排，对于业务流+人工工作流集成还是需要BPM工具，而两者如何更加有效集成又是关键问题，包括原有业务系统很多已有工作流工具的情况下如何进一步整合，而不是替代原有系统和原有功能。
• 　　流程整合一般有界面集成，门户一起才能发挥作用，这涉及到需要BPM提供的数据建模和界面建模工具。
• 　　流程整合，则流程建模和服务组装过程中自然涉及到业务规则，在没有规则引擎前通过BPEL来实现复杂业务规则是不现实的，而规则本身对复杂系统的可适用性仍然需要验证。

　　基于以上难点，初步考虑如下的一些思路来推进SOA流程整合的工作

　　流程整合前期重点关注端到端流程监控，以端到端流程监控为整合的切入点，这种方式下不会影响到已经固化在业务系统内部的业务功能，而解决了原有业务系统无法提供全流程视图的问题。如项目管理，供应链，财务，物流都存在可以选择的端到端监控流程。

　　重新定位BPM和BPEL工具，对于BPEL仅作为服务的组装和编排，跨流程的整合启用BPM提供的功能，BPEL编排的内容作为BPM端到端流程的子流程，这样充分利用BPM的HWF人工工作流引擎，已有的界面建模和数据建模等能力。对于BPM工具本身需要支持SOA架构，支持和SOA平台的ESB和BPEL的集成。对于BPM提供的业务流程建模工具倒是次要的。

　　进一步规范和梳理企业已有的IT建设中软件基础设施，主数据的建设情况。包括统一认证，单点，权限模型，组织模型，流程模型等，IT系统软件开发基础架构等内容，这些是进行SOA流程整合的基础。流程整合中的业务跨了业务系统，而业务本身底层需要基础主数据的支撑，这也是SOA流程整合需要主数据管理系统提供能力支持的原因。

　　前期数据服务和业务服务的识别，一定要从高端IT架构规范和分析导入，遵循流程建模和数据建模的思路，从端到端流程的逐层分解，由上到下的分析和识别服务，充分考虑服务的粒度和可重用性，这样前期实施的服务才能够真正为后续流程编排和端到端流程整合服务。