对于SOA架构规划和ESB服务总线实施价值在我前面文章中已经多次提到过，感觉还是写的比较理论化，这篇文章还是真正从问题出发进行ESB实施价值分析。

首先我们还是从问题出发，很多企业准备实施ESB核心的驱动不是真正业务驱动，而先试IT部门已经自己感觉上的业务系统太多，接口太多太乱难以管理。那谈到这个问题就先要去思考接口多和难以管理究竟导致了哪些问题，因为难管理本身不是问题，而由于接口难管理影响到业务和业务系统运行才是问题。

基于以上，我们需要做一些问题分解和展开的思考。

简单的业务系统使用故障或Bug由于只涉及到业务系统方，因此问题边界和定位准确无歧义。但是如果涉及到接口问题，往往就涉及到2个以上业务系统，如何准确快速定位并划清责任边界就没那么简单。如果对于业务系统全部外购没有自己IT团队的企业，业务系统对企业来说完全是黑盒，企业完全依赖厂商来解决问题，降低了IT部门本身的话语权和决策能力。

因此这不再是简单的接口排查问题，更是一个后续如何建立全局IT控制权的问题。

那么建设ESB总线也不是简单的通过集中化总线实现接口标准化和统一管理，而是希望通过接口和服务的标准化，逐渐将业务系统这个黑盒打开，至少也要争夺跨系统交互和对外协同部分的控制权力，而不是完全依赖于厂家。相信大家已经看到很多企业被业务系统厂商绑架的情况，即刚开始业务系统厂家以亏本或低价中标，后续系统升级和接口运维收取高价的情况。

而建设了ESB平台，一方面是将业务系统黑盒逐步打开，其次是ESB平台真正能够实现对接口的统一管控，实时的接口运行日志查看，问题分析，安全管理，性能监控等核心内容。只要和接口相关的都统一到一个ESB平台统一完成，而不是像原来排查接口问题需要协调，查看多个业务系统日志。

注意，对于企业建设ERP，供应链，财务，HR等各类业务系统，往往都会有一个业务牵头部门，真正这些业务系统能够实施成功需要的是业务部门和IT部门的高度协同和配合。涉及到业务系统系统IT部门想去牵头并主动推给业务部门相对困难，除非是这个企业本身业务管理水平太低。

我们看到对于接口涉及到的业务和数据集成规则和逻辑，这个刚好是各个业务部门或业务系统之间的中间灰色地带，也就是说这部分内容本就不该属于单个业务系统或单个业务部门。自然业务部门往往不会牵头这个事情，业务系统也往往被动做这个事情。如果企业已经有流程管理部，可以看到这部分跨企业多业务部门的业务协同应该属于流程管理部去梳理和调研清楚的职能。

正是接口这块灰色地带，其牵头部门往往正是企业IT部门，所以也经常可以看到企业CIO往往会主动推动ESB和集成平台的建设。但是大家都知道ESB平台属于集成中间件，其建设的价值很难说马上让业务领导和业务部门感受到效果，那么为何IT又要牵头去做这个事情?

如果简单的说是IT将这个没有人管的灰色地带真正管理起来，并且标准化和自动化的管理好，以方便更好的支撑业务系统和端到端流程的高效运转。深入点来说即是IT部门本身需要有一些自己主导的系统建设来提升其地位和主导权，而类似ESB和BPM正好可以起到这个作用。通过这块的标准化，已有即使是业务部门牵头建设的业务系统，涉及到业务系统间集成了也需要IT部门来主导和完成，否则业务系统就是一个无用的孤岛。而牢牢的把控住这个企业内业务系统间的信息中枢，自然提升了IT部门的价值和地位。

3. 接口变更和运维难

前面已经谈到过由于接口是灰色地带，往往没有统一的管理方法和规范，而接口本身应该和业务系统和功能模块一样，也完成遵循软件工程的需求，设计，开发，测试，上线部署和运维的全生命周期管理。所有和接口相关的都应该有接口需求文档，业务交互场景可以查看，有详细的接口设计文档和接口开发源代码归档。

但是实际情况接口类的相关文档缺失严重，业务系统各方都不重视这块的文档和规范标准。这直接导致了在业务发生变更涉及到接口变化的时候，接口变更风险极大，一个接口往往开发的越来越复杂不断的堆砌代码上去，同时负责接口维护的人也不断的流动和替换。到了最后任何一个人对当初接口的设计初衷，接口内部实现的逻辑，如果接口改动可能会影响到哪些业务系统方都无法讲清楚。

在这种情况下，接口的修改往往很容易引起多个业务系统间的连锁故障，正是这个问题导致很多企业明知道接口乱和有问题也不敢轻易去改和优化。导致这个问题的原因当然也是由于没有统一的接口管理部门和平台原因。

接口运维难也是同样的道理，由于接口涉及到多方，接口实现本身又在业务系统内部，导致接口运维牵扯面很广，一旦接口出问题排查和解决都相对麻烦。同时各个业务系统厂商可能还会推卸责任，这些已经不再是简单额形成标准化的运维流程能解决的问题。

4. 接口问题真正影响到业务

大家可能认为这点应该放到第1点来说，之所以放到最后说的原因是接口问题真正影响到业务，很多也不一定需要上ESB集成平台，而是应该进一步做好接口问题分析和性能优化。业务系统提供的接口本身就存在性能问题，那么即使上了ESB平台往往问题仍然还存在。

接口对业务的影响常见的主要还是体现在实时性，一致性，性能几个方面。

业务部门用户在采购系统里面创建生效的采购订单，可能要1天以后才会同步到ERP系统，如果本身同步失败又需要等到下次接口同步。对于这种定时同步方式一定会影响到数据和业务集成的实时性。而一致性也是常见问题，不如采购系统中有某个采购物料，而由于接口同步错误，导致该物料在ERP系统中没有，这些都导致了某一个时点数据在各个业务系统中不一致。

性能也是最近几年由接口触发的另外一个关键问题，即由于接口本身的大数据量或大并发调用，直接影响到了业务系统本身业务功能使用的性能。这个问题随着企业业务量增加，接口访问的并发和数据量都会增大，导致问题在后续使用中逐渐爆发出来。

这个问题一方面是可以通过接口本身的性能优化解决，其实更加重要的解决方式仍然是通过ESB提供的高性能消息中间件实现彻底解耦，以及实现数据推送时候的缓冲;同时还可以采用ESB本身的一些大数据和服务集成技术来提升集成效率，降低对业务系统的影响。

原来我们谈ESB价值谈的最多的就是实现接口服务的统一管控和治理，实现可重用的服务目录资产库，但是说实话很多企业往往意识不到这个点，认为很抽象，因此写下上面这些内容供参考。