如果你的IT预期要令业务更敏捷，你就得转到SOA来，是吧？我不同意，为什么呢？因为大家又一次把因果混为一谈了。不管有没有SOA，一个敏捷的组织都应该能够充分地利用IT。SOA并不会让业务或者人更为敏捷。

　　敏捷性只能来自于业务和IT的创新意愿，并通过废除死板的业务流程，脱掉实现BPM、CRM和ECM这身紧身衣，放权给用户才能达到。把流程编码为僵硬的JAVA，对SOA来说无异于业务杀手。

　　为什么SOA被吹嘘到令人难以置信的程度？

　　SOA的风潮热得过头了，随后由于大家都随大流卖起产品和服务而陷于泥潭之中。《网络计算杂志》。因此曾把SOA称为最受鄙视的流行语也就不出奇了。IBM（Tivoli和WebSphere）、Oracle （Fusion）等玩起了“卖不出就改名”的游戏。是要做出某些改变，但应不仅限于产品名。

　　我们是不是甚至连错在哪儿都不知道？

　　我严重怀疑这一点。很有影响的量子物理学家David Bohm在1980年写道：“分解在我们的社会是如此之广泛，以至于干扰到了我们的认识，阻止我们去解决最简单的问题。”。似曾相识吧？我们把一切都塞进小盒子里，为每一个业务问题都购买了最佳组合的软件解决方案，现在，我们诧异地发现，它们不能工作到一起。

　　在过程的层次上，我们致力于将过程剖解为小的片段，因为这种方式下它们似乎更易于管理。1993年， Thomas Davenport所述的过程碎片是这样的：

　　实现就能连接。但更恰当的描述是福特（Foote）和育德尔（Yoder）1999年做出的，他们是这样写的：

　　我认为David Bohm是对的，分解对于我们在能力范围内进行思考、组织和计划是必要的。然而，我们周遭的世界并非由过程的片段造就的，因此当前的SOA方案将无法解决碎片化，相反，会在更高层次上导致一场软件工程的噩梦。在进行IT系统的碎片清理之前，需要对业务流程和流程变更管理好好审视一番。

　　业务流程的1911风格

　　有些人说SOA就是流程管理的延伸。然而，BPM支持者陷入了1911年的泰勒主义，而SOA把局面搞得更糟，因为仍存在碎片化的变更管理。

　　Frederick Taylor相信分解和专门化，推荐僵化的结构化企业。因此，每一个IT应用都代表着那样的一个业务流程片段，因为根据达文波特，倘不若此的话，我们就不会需要它。但业务流程又是什么呢？ Rummler和Brache（1990）提议说“业务流程是一系列设计用于为客户生产产品或服务的步骤”。这压根儿就是不对的。

　　是的，为了给用户以及流程本身更多空间，的确有部分僵化的决策流程和特定的方案。奇怪的是，好像几乎没人意识到我们需要的是创建一个拥有动态关联过程和企业通讯的敏捷企业。很显然，通信过程的内容状态是受控的，而非无缝的行动。商务沟通并不仅仅是一份文档或者电子邮件，它可以是任何东西：一份选定的菜单、一个网页、文档上的标签、一条记录、一张图片或甚至语音记录或者视频。无论在业务流程分析上要花多少时间和金钱，一旦正式的时候，商务沟通这一点仍是需要的。基于这个原因，协作工具及电子邮件现在得到了广泛使用。任何分析都需要沟通。

　　在《企业再造》一书中， Hammer和Champy提出一个很重要的建议：“单个的任务或过程都不重要，重要的只有结果”。BPM系统、BPR项目无力适应面向目标的动态性。

　　Damelio在《流程映射基础》（Basics of Process Mapping）一书中写道：“示意图和流程图令工作可视化……它们展现了某段时间的快照……”。这就是设想中的业务流程，如博姆所言。我们需要分块来进行理解，但生活的运作方式并非如此。

　　请继续关注《为什么SOA没有实现：IT与流程有何关系？》