对于软件项目实施，我原来谈的比较多的就是希望通过软件产品的产品化程度来降低软件项目实施的难度和工作量，同时尽量的将项目实施工作自动化掉。这估计也是大部分软件企业希望的一个产品研发加项目实施的演进方式。

回到我们自己的ESB服务总线来看，我们经常强调ESB总线是一个技术平台尽量不要涉及到具体的业务规则逻辑，包括我们最早用BPEL封装编排服务的时候也是这个思路，我们希望总线只负责存粹的接口服务代理接入，协议转换等基础事项，同时丰富服务接入后的后期管控治理能力。

在这种模式下，虽然我们的实施自动化程度和实施效率都提升了很多，但是带来的问题也很明显。就是对客户的一些个性化需求满足度并不太好，其次就是由于ESB本身是技术平台不涉及业务，导致ESB总线和业务的绑定度很低，同时业务部门本身对ESB总线的感知度也低。这不仅仅是ESB总线无法体现业务价值的问题，而是ESB产品项目很难被业务部门认可而逐渐被其它项目取代的问题。

业务驱动IT，因此IT系统最大的价值还是为业务目标和业务流程服务，对企业核心价值链支撑度最大的系统往往也是最重要的系统。这些系统在企业进行IT系统建设规划和预算分配的时候往往都会特别照顾。而对于技术类平台往往相对优先级就更低，虽然我们也一直在强调SOA项目的实施本身带来的业务价值，业务敏捷性的提升。但是由于这种价值很难显性化，因此也很难带来很明显的说服力。

这周我们前面几篇文章都在思考建立企业中台能力服务层的文章，而从这些文章编写里面，也让自己认识到有时候重实施往往也并不是坏事。回到SOA项目建设中，这种实施不仅仅是简单的接口服务接入管理，而是我们原来谈的SOA架构规划咨询，服务识别和梳理，包括SOA整个治理管控规范体系的建设工作。而这些工作必须要切入业务，从端到端业务流程和跨系统流程交互梳理入手，从核心的数据架构，数据域分类，主数据的识别入手。只有这样你才能够真正形成对企业可复用的核心能力资产，而不是简单的已有遗留接口适配接入。

在整个流程分析，服务梳理和识别完成后，就会涉及到最终的服务定义和服务开发工作。服务开发和上线本身就是对已有业务系统关键能力的暴露和开放，对企业服务资产库的逐步积累。但是服务开发就涉及遗留系统的改造，对于一些遗留系统很多企业连开发商都找不到了，这种情况如何处理？在我们原来的思路我们一般都不接这种接口开发的事情，但是这往往就导致我们梳理规划的接口服务很难真正最终接入并注册到ESB，形成服务能力对外提供。

而这也是我们提出实施可以再重一点的关键，其一重在前期的流程分析梳理，服务识别和定义，形成真正可重用，有业务价值的服务。其二就是能够在熟悉业务和系统后，接管一些遗留系统的接口开发和运维工作。为客户提供一个交钥匙工程，而不是要客户去协调多方厂家。在这种模式下可以看到，SOA业务价值和能力会进一步体现，同时也会业务进一步绑定。

软件实施类项目都是需要以人力投入为主，虽然辛苦但是也是能够最终接触到客户现场真实需求的关键点，好的产品不一定为客户带来价值，只有好的产品+好的实施往往才能够为客户真正带来最大价值。