异构系统集成平台如何让企业降本增效

异构系统集成平台是什么？它与pi、esb等产品有何差异？与主数据平台有什么关系？

其实我们老说异构系统集成平台，它仅仅是我们在企业中最常见的业务场景：就是接口怎么做。

第一，企业到底有什么保障结构，是谁和谁连接，有多少连接，这都是我们面对的问题。站在整个企业端，我们解决异构系统之间相互数据的通讯等事情，一定要有一个统一的平台。

第二，这两年非常热的话题叫做数据治理。

从技术的角度，时间维度上了很多不同的系统后，这些系统之间已经互相不认识了，为了认识，数据治理方案会推荐企业上MDM系统和标签系统，这两个系统解决了数据的标准化问题。

但其实数据治理项目在企业当中是费力不讨好的事情，因为你要请业务人员去维护这些主数据，打标签，然后IT再通过主数据等分发到其他业务系统，这是一个事倍而功半的事情。

所以像主数据系统，在国内除了外企，绝大部分企业都上得不是很成功的原因就是：它的技术方案非常完美，但应用层面比较失败。为了解决IT的问题，IT又找IT的工具，让业务人员去解决。

大家都知道所有系统建设的初期都是按功能模块建设，比如今天我要上CRM，明天要上ERP，后天上POS。这个建设过程很容易，但当企业规模已经到了20亿以上，中大型企业所有的应用之间都需要进行数据互通，这个时候问题就来了，大数据量并发的时候，原本正常的接口就很容易出现问题。

业务的问题。系统接通过程中牵扯到数据质量，如何帮助业务运营，把数据质量给搞好。

技术的问题。从IT负责人的角度来看，做规划我尽可能把技术问题的成本降至最低，而把更多的时间精力去放到业务层上去。IT如果不深度介入业务，it就是一个工具型的部门，工具型部门大家知道它的价值点就非常低。所有我希望找到一个类似于在这种接口层面上的服务，让我整个开发成本降至最低。

坦诚来讲，企业的信息化从总体来讲分为两类：一种是从0到1，从没有到建起来；一种是从1到n。

从1到n的过程解决的就是建设的问题，最核心的工作量就在集成。所以在IT的信息化建设过程中，像SAP、Oracle、IBM都推出了集成的工具，有pi，有esb，它们是必然的产物。

十年前我们围绕一个核心系统的业务数据做拓展，以点为中心，然后这些点去服务其他的软件系统。在这个时候是解决数据的转换问题，比如我a系统里某一个人的字段是account，在b系统里是custom。

而新的业务架构是API的事情，API不仅仅是一个数据接口，而是一段业务逻辑。通过把一个个点的串联，编排，让它形成一个完整的，这时候就需要新的技术架构去支撑它。

还有一个核心问题是，像pi，esb等系统应用出了问题后很难解决，现在大家基本上是通过重启服务器这种很被动的模式去解决。为什么会有这样的问题，就是我们以前的系统基本上都是在内部应用系统进行数据交换，数据流量很小。但现在，尤其是零售行业、时尚行业，我们会想掌握终端的数据，建立起全渠道各种微商城等和终端互联之后，业务的数据量会急剧提升。原来的系统没办法做高并发性的扩展，只能依靠一台非常厉害的单体机器和非常强的数据库来支撑它，但是这个东西是有瓶颈的。

现在我们的虚拟化技术支撑高并发量的时候要解决三个层面的问题。

第一个层面，通过微服务改造一下中台的业务组，把这些组件通过重新的编排，可以尽快形成一个新的业务。

第二个层面，在形成快速能力的时候，我们原有系统的接口数据交换还是要支持的。

第三个层面，在大问题发生时，我们怎么去排除这种直连数据库的模式，一定要有把数据库需要的这种能力编排输出成服务的结构。

所以现在来讲，异构系统集成平台和传统的esb、pi的思路是一致的，但它新的技术模式、解决方案和高效性等，是以前的系统不具备的。

如果我们把自己定义成运营IT的话，前期你做的所有项目建设都叫隐性工程。我举个例子，今天我和谦哥说出去跑步，谦哥说今天跑完步能让你的身体变好吗？的确今天跑步没办法现在就让身体变好，但当你坚持到了60天，那么身体状况一定有所改变。

Esb就有点像跑步，你必须跑步60天以上，才能够看到效果。

API从某种意义上来说，是把自己的能力进行暴露，在暴露的过程中要考虑几个问题。第一，暴露过程的安全性，我们叫权限；第二，暴露过程中如何做到整体的性能可控，并且变成服务模式，按照容器的方式去部署。

但esb不是，我用Tob和Toc来形容，esb就像Tob。这二者的区别就像Excel中，Tob就是行数很少，列数很多，Toc就是列数很少，但行数很多。

那么api跟传统的pi和esb到底有什么区别？

第一，一个API平台一旦构建上去，我们可以逐步地建设，迈的每一步都可以看到异构系统之间被打通，包括服务可编排，服务特别化，并发量，都可以在这个平台上面得到比较好的价值体现，而不是一个单纯的隐性工程。

第二，现在的IT建设中心不再是单一功能、单一模块的建设，而是做集成。

第三，新零售在疫情之后，会和物联网做深度的绑定，数据与设备之间、软件与人之间做大量数据的互通。如果我们还用传统的思路，几百条几千条接口的服务治理就变成迫在眉睫的事情，原因很简单，当连线越来越多的时候，一个服务出现问题就会牵涉到若干个服务的崩溃。

异构系统集成平台和主数据系统的关系

主数据系统和异构系统集成平台有什么关系？如果我现在上了主数据系统，还需要异构系统集成平台吗？或者说异构系统集成平台可以代替MDM系统吗？

第一，如果上了主数据系统，那么通过异构系统集成平台去做数据的分发，有非常多的优势，更灵活，更稳定。

第二，主数据解决的其实是整个公司里面跨系统之间的数据标准化。而在做数据治理的时候，我们认为应该先做企业的业务流向的梳理，再做IT系统支撑数据流的支撑体系，然后再按照新的业务流找到源头。

异构系统集成平台在从原系统直接调用数据分发，在做数据内容的转换时，是完全可以取代主数据系统的。

在我看来，把一家企业的需求进行分析，分为三种需求，第一种需求就是核心需求，业务逻辑还是通过传统系统来做；第二种需求是Toc类的；第三种需求是行政类的。

Toc类和行政类需求在并发量不是特别高的时候，我们就希望开发成本非常低。我在整个IT规划过程中，就会用API平台加低代码开发平台。

假设一家企业有二十几套系统，当若干个服务起来一个，通过低开平台去调用API，那么一些行政类的需求就快速达成了，节约了大量的开发成本。

当然我们也碰到一个瓶颈，基于若干个系统的整个业务服务的梳理，通过数据中台、业务中台去做的话，市场难度还蛮高的。那我能不能在这个之外，再构建一个API平台，只要是整个动态过程中有业务数据，通过API平台分门别类，再把这种模型开放给非开放人员，通过低开平台去调用，这就变成了一个百花齐放的事情。

第一，快反。业务创新的时候，IT一定要快速地响应。低代码开发平台是一个非常好的工具，但在中国有一些很独特的场景，我们平台上设计出来运行 的东西，一定要依赖这个平台才能跑起来。

第二，复用。怎么复用？坦诚来讲就是把原来建设系统的能力，包括建立IT生产的快速复用能力，就是无人化、自动化。

互通互联。在建立起自动流水线，无人化或少人化之后，怎么让系统互联互通，其实就是异构系统要做的事情。

异构系统集成平台项目是否必须做数据治理的咨询

如果说企业没有过服务治理的项目，我认为在上异构系统集成平台之前是有必要做这一步的。但如果有些企业已经做了数据治理，也上了MDM系统，我认为还是直接上异构系统集成平台比较好。

因为我们会发现如果你通过数据治理咨询的模式，搞清楚业务流向、it的支撑体系，业务和it的数据的关联关系之后做出这种规划，而且对未来的接口输出的内容和标准做出规划之后，会发现主数据系统是不太需要，但是标签系统需要。

所以这时候我们通过你所处的角色来定义这个事情。如果说你想做一些创新性的事情，其实从技术架构上应该做的；但是如果说你为了降低风险，就是为了提升一些运行的效率，而且让自己整个企业运行处在一个可看可控的了解范围的时候，其实直接上这套系统就可以。

就是说异构系统集成平台也可以没有咨询项目，但歆哥你从甲方角度来讲，需不需要把它变成数据治理咨询项目中的一部分，或者说需不需要起一个咨询项目？

第一，企业如果把数字化、信息化当成它的核心能力的话，数据治理从一开始到企业生命的结束，都要一直去做。我们称之为数据的颗粒度，数据的多维性。

第二，未来30年企业发展过程中的核心竞争力就是数据。我们把数据的质量称为刀，刀都不够锋利的话，谈何去用刀。

第三，回到整体IT建设的层面上来说，我一直强调问题思维，边界思维，和交互保障。我们在做整个数据治理，集成平台构建的时候，要跟具体业务相关联。

比如我今天要做秒杀，我们就势必要提供足够多的库存深度，这是必要条件。如果在营销端拉来成千上万的消费者，结果库存深度只有1000，请问这个秒杀是成功还是失败？到最后到底是业务问题、技术问题，还是营销问题？

就是数据是我们在经营过程中的必要条件，而不是充分条件。有了这个条件不代表业务成功，但是没有这个必要条件，这个业务是不成立的。