异构系统集成平台是什么?它与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,请问这个秒杀是成功还是失败?到最后到底是业务问题、技术问题,还是营销问题?
就是数据是我们在经营过程中的必要条件,而不是充分条件。有了这个条件不代表业务成功,但是没有这个必要条件,这个业务是不成立的。