BPM专家了解SOA研究人员所不知的业务流程

面向服务架构的一大目标就是在面临不断的变化和不一致性时，实现业务灵活性。这里我们所说的不只是让技术更好的合作，而是要保证SOA能够满足业务需要。业务首先通过机构的业务流程反映出来。有些人可能认为SOA是以流程为核心的，但是ZapThink 与终端用户，咨询公司，以及技术供应商并不关注这些业务流程，而是关注底层的技术平台，基于标准的接口，以及系统之间的通信。事实上，有时业务流程往往过于热衷讨论SOA与业务关系。SOA本身和业务无关。但是，如果SOA所产生的一切长期影响和收益，一定和业务有关，并且是由业务所驱动的。

许多IT人员无法为SOA投资信号验证一个业务实例。因此在业务试图解决的这些问题之间一定有许多不连贯性，SOA有望解决这些问题。但是并不是所有的 IT措施都有实例，事实上，业务流程管理领域（有些人会在BPM上再加上建模和监测），他们在机构中所起到的作用并不大，除非它们能够画出特定的业务流程。但是，那些拥有BPM技术的人不在SOA讨论的重要范围之内，因此，他们的知识以及和业务之间的联系并没有转化为机构的有生力量。那么从事SOA研究人员究竟可以在他们的BPM同事那里学到什么呢，为什么我们必须将BPM研究工作和SOA研究工作分开呢？

BPM专家所了解的业务流程知识

IT人员过去常常将集成和业务流程分别对待，在信息技术发展过去的三十到四十年里，IT环境变得更为复杂了，似乎要想在相互之间进行通信和交互作用对于 IT行业来说也是十分具有挑战性，但是，像企业应用集成 (EAI)抽取转换加载(ETL)以及企业信息集成(EII)之类的技术措施重点关注解决集成问题，不需要通过业务环境证明他们的价值。如果你需要数据在系统A和系统B之间完成这个目标，为什么还要求助集成专家实现这个目标呢？但是，通过关注集成的技术问题，业务就不必重点要求集成技术人员和专家必须要理解业务环境或者业务流程了。

当集成还未完成时，业务需要找到能够解决IT领域不断变化的业务需求的方法。BPM的演化彻底将业务请求所用的时间提炼为现实可行的部分。业务流程以模型的方式被展现出来，帮助机构识别如何实现当前流程，并针对流程的变化做出改进。生产力的不断增强是BPM最为主要的价值主张之一。该价值主张可以通过减少小组管理和技术集成方法中设计到部署的时间框架得以实现。成功的BPM要求迅速开发并测试流程模型，建立并部署这些流程的用户接口，然后将这些接口连接到现有的系统当中。

BPM小组认为“对于操作业务来说业务流管理是一个自然并且完整的管理方法，操作业务高效灵活，富有创新精神，可以被那些采用原有传统管理方法的组织所接受。”我们会想到两件事，首先，BPM的定义和SOA极为相似，也许将BPM同SOA企业架构相结合就更能得到一个和业务相关的SOA视角和一个基于架构基础之上的BPM视角。事实上，要表现一个业务流程并在模型上快速迭代，会创建一个要求的逻辑，这很像一个自上而下，由模型驱动的方法，这种方法得到了 SOA团体的支持。但是企业仍然坚持用自下而上的方式建立服务，他们最先着手建立的服务不是自下而上的业务流程而是底层系统。

其次，许多SOA团体的成员从来没有听说过BPM小组，或者见过BPM参与SOA工作，另外，许多BPM会议的主题和SOA会议的主题相同，但是两个会议的听众完全不同。点我们在SOA Box ZapFlash以外的思考中就曾经介绍过。SOA技术和BPM技术之间距离超乎了人们的意料，此外许多精通SOA技术的人并不懂业务流程这门语言，他们缺乏设计业务流程的模型的技巧，并且没有参与过BPM工作，因此不了解众多BPM方法的益处以及容易犯的错误。问题在于传统集成专家和业务流程专家二者之间的分工不同。

结合BPM技术和SOA技术

似乎BPM的成果和SOA成果是完全对立的：一方面业务流程专家致力于建立一个理想的模型，另一方面一些技术人员却想展示理想的服务，但是，二者又不是完全对立的。一旦发生变化，业务流程就会需要不同的服务，按照规则，技术人员也会做出相应的变化，这样就令在现实中完成一项特定的流程更为复杂了。在企业不断的演进过程中，公司要从服务定向的角度看待BPM，以业务流程的角度对待SOA。

首先，业务流程应该展示抽象层面中不同活动以及活动之间的联系的具体细节。对于大多数人来说，这些模型都是用于指导开发所必备的文档。但是，从服务定向的角度来看，这并不是正确的方法。一方面，SOA要求必须以元数据的形式定义服务的构成，其服务构成要有可执行性，并且能够被人理解。在这种情况下，业务流程模型是运行时间的人工产物，由于其要定义流程的每一个细节，这样会使整个过程复杂化，任何分析瘫痪都会导致流程无法进行。

流程驱动的SOA认为BPM是一切重复SOA方法由上而下的，这样就会产生一个意义明确的服务合同和方法学，它们就能够对这些流程和典型服务持续、重复定义得以实现。

另外，一旦流程形成模式，固有的BPM技术就不会考虑生命周期是否完整。相反，高效的BPM要求现有的业务流程进行模仿并走查以便能够从实施的活动和已定粒度的服务意图中识别最佳条件和改进措施，以及持续的反馈。好的BPM建立高效的团队，并且能够观察出一个业务流程是在服务运行之前是如何运行的。

但是在我们谈论这个话题以前，我们首先要清楚BPM + EAI + 标准不等于SOA。许多软件供应商认为他们的SOA成果仅仅是流程，集成，基于中间件工具箱的叠加，而没有意识到SOA技术的主要目的就是通过使用灵活的服务转化现有的业务流程以便降低其复杂性。SOA是组织IT资产的一种方法，同时也是考虑业务流程和变化要求的一种方法。因此，这些公司不必将这些毫不相关的产品置于SOA的大旗下，而要重新设计自己的流程和基础设施工具，保证其是服务定向，并且由流程所驱动的。

ZapThink 采取的措施

有人提议设计一个类似面向流程架构（POA)的新名词，以便将流程驱动的SOA技术和非流程驱动的SOA技术分离出来，但是有些人会说不是面向流程的SOA技术毫无价值。

如果SOA能够利用自己从BPM学来的东西以及SOA团队中的BPM专家，不仅能够提高工作效率而且能提高业务投资者的购买力。事实上，SOA要想获得成功，必须和BPM结合在一起才能成为一个专注业务的架构措施，才能赋予业务自由应变的能力。

未经允许不得转载：DOIT » BPM专家了解SOA研究人员所不知的业务流程