BPM与企业IT
在上世纪九十年代，BPR(业务流程再造)的概念曾风靡一时。BPR的理念是通过摒弃过时的、低效的流程，从零开始设计与运用最优化的业务流程，达到在相对较短的时间内取得效益的最大化的目的。
其后各大企业和咨询公司都对BPR寄予厚望、并尝试使用BPR的理论对企业流程进行改造。不幸的是，大多数案例都以失败告终。大家在惨痛的教训中得出的教训是，在现实世界中，真的想要完全摒弃原来的业务流程，设计一套完美的流程来进行执行，无论是对企业本身还是企业的员工，都不是那么容易的事情。更何况世界上本就没有完美的流程，因为市场的需求总是在不断变化和前进的。
在BPR的风潮过去一段时间后，一种新的概念-BPM(业务流程管理)应运而生。BPM与BPR之间的最大区别就在于：BPR是摒弃已存在的流程，从零开始;而BPM则是在原先已存在的流程上进行增量改变与优化，以达到提高流程效率的目的。
图1 ARIS流程管理平台
随着IT在企业中发挥越来越大的作用，有一个问题无法避免地产生了。当管理部门为了达到快速适应市场需求变化或者追求更高效率的目的对流程进行优化时，我们的IT系统能否快速适应这种改变?
当业务人员在描述需求时一定会以业务的角度来进行阐述，然而当技术人员接收到该信息后会以技术的角度考虑如何实现。如图2所示，这种思维方式的不对称性看似不会带来太大的问题， 然而如果仔细观察，还是会发现一些有趣的现象。
图2 业务需求与系统实现
技术人员在潜意识中，只会将他认为可能重复出现的代码进行封装，以备将来的重复使用，但技术人员常常不清楚哪些业务上的功能在将来可能会需要进行频繁修改和重复使用。所以在实现企业的业务逻辑时，技术人员通常会使用面向过程的方法对现实业务进行描述。
如此一来，最常见的情况就是实现不同“详细流程”的代码常常会掺和在一起(如详细流程1与详细流程2)、共用一批内存变量。这就直接导致了实现不同流程的程序代码不可分离和重组，这在技术上称为“高耦合”。最终，在将来当企业希望改变流程的顺序时，就不得不对代码进行大量的重新编写和调整;当希望在别的流程中希望使用另一个流程中已实现的详细流程时，代码却无法顺利地从原来的流程中进行分离。所以当企业的业务流程发生变化时，技术人员不得不花费极大的精力去进行维护和修改，这样做不但增加了企业构建IT的成本，对原先程序功能的修改可能还会带来许多无法控制的风险。
SOA的出现解决了上述问题。
