SOA对我们是个比较尴尬的阶段。过后我们发现这个阶段对业务只有一个贡献，就是产出了中国企业特有的OA应用, 即办公自动化。说得具体一点，就是SOA是个了不起的技术体系，但是它真正产生的业务价值，是作用到了那些做ERP的时候根本不看重的、零散的流程上面,也就是企业的办公自动化。那怎么会出来这样的一个情况呢?

说SOA意义深远，概念层面它体现的是紧耦合向松耦合演进的技术框架;流程层面体现的是服务的共享化。但SOA不是一个项目，更不是一个产品，而是一个过程。我们的过程有了开头，建立了数据总线，定义了接口标准。但被随后在互联网、移动、云等等概念的冲击下，没能把SOA的过程延续推进。

另外当时的切入点也是为了解决众多系统点到点接口混乱的局面，并没有定位到SOA原有的本质意义上。那时我们还是纯技术的把数据接口都拉到了数据总线上。之后确实思考过应该有一个服务总线，但受限于根深蒂固的ERP流程理念，未能厘清服务与流程的区别，也未能确定是从业务的角度来定义服务，还是从系统的角度来定义服务。这同时也是个服务颗粒度的问题。也就是说虽然我们意识到SOA提供了从技术向业务的方向拆解服务的可能性，但没有领会应该从业务操作步骤的角度来生出服务。我们之前ERP建设中形成的流程实际不是操作步骤，而是各个操作步骤生成的结果数据构成的前后道管控关系。这一点今天只要在淘宝上买过东西都能理解了。淘宝不谈流程，但你不会为未下单物品付款，因为有看不见的数据流在起作用。如果回到ERP，更能说明我们之前做的流程都是淘宝上不可见的，而淘宝上的可见服务则不是ERP所能包含的。

在这些问题尚处懵懂状态时，互联网时代来临，企业信息化建设的第三个阶段也到来了。SOA就成了半生不熟的尴尬存在。第三阶段以开放互联网为媒介，打破企业围栏，建立内外连接，势必采取异步对接的松耦合架构。与SOA松耦合架构其实是一脉相承的。

SOA出现时旨在实现企业内架构松耦，走到今天，变身为原本就是松耦合的企业内外业务关系的技术实现，这也是自然而然的结果。一些敏感的企业IT人已经意识到这一技术走向，于是在企业内部系统建设中重启BPM建设，将BPM建设成服务总线。

提到这点我要特别推荐一本书——《云计算与SOA》。现在读一本2011年的书看起来有些过时。但如果致力于跨越之前提到的SOA尴尬阶段，建立服务架构，平滑构建内外(云服务)钩稽关系，进而进化到微服务，本书可以提供一个清晰的脉络。