BPM和SOA(整理中...)

明显的趋势就是BPM与 SOA的融合，通过SOA组合单独业务和流程实现复杂的业务应用。已经是一种必然趋势。

当企业的业务流程发生变化时，技术人员不得不花费极大的精力去进行维护和修改，这样做不但增加了企业构建IT的成本，对原先程序功能的修改可能还会带来许多无法控制的风险。但是SOA的出现解决了上述问题。

随着IT在企业中发挥越来越大的作用，有一个问题无法避免地产生了。当管理部门为了达到快速适应市场需求变化或者追求更高效率的目的对流程进行优化时，我们的IT系统能否快速适应这种改变？

SOA的协同软件将管理抽象为表单和流程两个主要的应用服务，这些服务分别应用在行政、人事、项目、财务、物流、客户等管理领域，成为记录这些管理内容和管理过程的核心功能，以实现基于同一功能平台上的个性应用。

例如：请假是由请假表单，和申请、层层批示、审核、确认等一系列流程组成；报销是由报销表单，和申请、审批、复核、付款等一系列流程组成。请假表单和报销表单分别记录不同的内容，但调用的是同一表单处理程序；其处理流程也不同，但调用的同一个流程引擎。请假表单和报销表单的格式，会随着管理的要求有所变化，请假与报销的流程规则也会不断优化与改进，这些变化与改进无须重新修改软件，而是在原有功能平台上重新设置即可，并且这些设置不需要高深的IT知识，普通业务人员只要会操作Office就可操作，真正成为一个由业务人员自主掌握的工作平台。

当业务人员在描述需求时一定会以业务的角度来进行阐述，然而当技术人员接收到该信息后会以技术的角度考虑如何实现。如图2所示，这种思维方式的不对称性看似不会带来太大的问题， 然而如果仔细观察，还是会发现一些有趣的现象。

图2 业务需求与系统实现

技术人员在潜意识中，只会将他认为可能重复出现的代码进行封装，以备将来的重复使用，但技术人员常常不清楚哪些业务上的功能在将来可能会需要进行频繁修改和重复使用。所以在实现企业的业务逻辑时，技术人员通常会使用面向过程的方法对现实业务进行描述。

如此一来，最常见的情况就是实现不同“详细流程”的代码常常会掺和在一起（如详细流程1与详细流程2）、共用一批内存变量。这就直接导致了实现不同流程的程序代码不可分离和重组，这在技术上称为“高耦合”。最终，在将来当企业希望改变流程的顺序时，就不得不对代码进行大量的重新编写和调整；当希望在别的流程中希望使用另一个流程中已实现的详细流程时，代码却无法顺利地从原来的流程中进行分离。所以当企业的业务流程发生变化时，技术人员不得不花费极大的精力去进行维护和修改，这样做不但增加了企业构建IT的成本，对原先程序功能的修改可能还会带来许多无法控制的风险。

SOA的出现解决了上述问题。

SOA（面向服务架构）

提到SOA，大多数人首先会联想到Web Service技术，甚至很很多人认为SOA就是将不同应用系统的功能以Web Service的方式部署出来，做到跨系统、跨平台的调用，以此降低企业IT实现总体拥有成本的效果。而事实上，这些特点和益处都仅仅是Web Service这一特定技术所提供的，而非SOA最主要的目的和功效。

  “服务”的意义非常广泛，现实生活中的服务无处不在，那么SOA（面向服务架构）中的服务究竟指的是什么？SOA中的服务又如何能帮助企业的IT系统快速敏捷地应对业务流程的变化呢？

如果仔细观察企业的运作，我们会发现其实企业的各个部门都在提供各式各样的服务，财务部门提供与资金相关的服务，后勤部门提供物流、仓储相关的服务。

由于BPM的理念是采用增量的方式优化流程，通常情况下业务流程的改变不会大幅度影响各个部门所提供的基础服务的性质，而是通过重新组合这些基础的业务服务，构建新的业务服务以及达到优化流程的效果。

  BPM的这个特点给了我们一个很大的启示：如果能够运用企业的业务服务进行建模，然后再运用技术进行实现，那么这样构建出的程序将非常地敏捷和高效。由于通过这种方式实现的程序功能的粒度粗细完全符合企业业务服务的粒度，当企业的流程发生变化时，IT系统可以运用重用已有系统功能的方式快速地适应变化。

所以，SOA中的服务指的企业各个部门所提供的业务服务。

所以当企业构建SOA时，首先要做的第一步就是对企业的业务服务进行建模，建模方式应该如图3所示。首先按企业的业务流程自上而下的进行建模，然后根据已经完成建模的业务流程，自下而上地对企业的业务服务进行建模。只有用这种顺序进行建模，才能保证最后得到的服务颗粒粗细能够满足企业流程变化的需要。

图3 运用业务服务进行建模

可以将不同层面的模型联系在一起，无论是业务流程与业务服务之间的、还是业务服务与技术服务之间的。如图3所示，由于最终的技术服务是根据业务服务得出的，而业务服务又是根据企业的业务流程得出的，这三者之间最终形成了统一。对于企业业务流程的变化，IT系统可以运用重新组合已有技术服务的做法轻松应对。

BPM与SOA之间的关系非常巧妙。通过上文可以看出，运用SOA可以轻松灵活地应对BPM对流程进行的增量改变。反之，如果企业的IT实施了SOA架构，却没有使用BPM对流程进行管理，那么SOA架构的价值将大打折扣，所以BPM与SOA之间是一种相辅相成的关系。灵活地结合运用BPM与SOA，才能使企业的业务流程变得更加高效，企业IT架构变得更加敏捷。

问：SOA现在比较热门，各大管理软件厂商现在已经推出或者即将推出基于SOA架构的产品。您认为这是IDS Scheer新的发展机遇吗？
洪：那是肯定的。我们以前常常谈的是IT要服务于流程，现在有客户的声音是：流程也要服务于IT。为了达到这个目的，德国汉莎航空的CIO从成本角度考虑则认为：改动商业套件的灵活性成本太大，不如对企业的流程做响应的配套改动。如果业务流程本身的设计是一个整体而并非模块化的，就无法与基于SOA的ERP软件相匹配。所以在基于SOA的ERP即将大行其道的时候，在技术和管理上都对业务流程也提出了相应的要求。
实际上，我们已经推出了ARIS for SOA英文版，汉化版目前还没有。它的特点就是在ARIS里面建立起流程模型，并把它能够有效地传递到不同的软件开发的语言中去。作为工具来讲ARIS for SOA主要作用是连接管理层面上的业务设计和软件开发的工具和语言。

问：IDS Scheer如何实现业务流程和SOA架构的相匹配？
洪：我们认为，要实现SOA架构的业务流程，需要从两个层面上来看，第一，企业的流程管理需要有统一的平台。对于描述流程架构的数据，需要有统一的存放地点。这个是做好业务流程管理坚实的基础。
第二，需要收集大量的数据来支持企业的流程。当企业流程模块化之后，顾问是需要清楚的了解为这个流程服务的员工的人数、设备的配置等等数据支撑流程，这些也是企业需要做的基础工作。在这个前提下，我们就能够去探索如何建立一个灵活、规范、标准的流程架构，之后再把这个流程架构的信息“无缝”传递到SOA对应的数据库里面去，从而保证了在业务层面上，流程架构到软件功能的过渡顺利进行。