数式科技亮相ECIO2020华东CIO峰会，低代码中台赋能

导语企业更应该关注中台级的服务，并且如果没有低代码加持的中台，其实都是在收企业的智商税。

7月17-7月18日，2020华东CIO峰会于上海成功举办。会议汇聚了全球五百强、中国五百强、华东地区各省百强等中大型企业CIO和企业负责人，共同交流与探讨新形势下企业如如何应对信息化管理与数字化转型变革的挑战。

数式科技受邀参与本次大会，凭借产品在中台领域的出色表现荣膺大会组委会评出的“华东CIO最信赖品牌”。，数式科技CEO陈鹏程以《低代码中台，新技术赋能新商业》在会上作主题分享。

推火网以下为演讲实录

大家好，我是数式科技的陈鹏程，非常荣幸有机会站在这个台上跟大家做这个分享，今天我分享的主题是《低代码中台，新技术赋能新商业》。

在分享前先做个简单的自我介绍，我做过阿里淘系和天猫的核心交易链路和导购链路的架构师、也是早期菜鸟网络的总架构师，后面在阿里云新零售事业部做中台架构对外输出工作，负责阿里云中台的原生交付团队帮助阿里云在业务中台领域树立多个标杆客户，现在是数式科技的创始人和CEO。

在我的职业生涯里，完整的经历过互联网的中台架构变迁，又是最早一批把业务中台带进企业的实践者。所以在我们公司有一句话叫“你没踩过的坑我都踩过，数字化转型不走弯路”。这是都是源于我们丰富的实战经验。我一直践行着通过技术创新让业务中台更好地服务企业，更多的企业能真正用起来。

当下，中台是一个从2016年到现在都一直很火的词，之所以从提出到现在持续这么久而热度不减，究其原因其实是企业在当下数字化经济时代的核心诉求发生了变化。在信息化时代，企业主核心焦虑更多在意内部、流程的管理，以及自身效率的提升问题;但今天企业主的核心诉求聚焦在外部、商业、数据以及运营。在这个核心发生的变化的时候，对于企业来说，他们其实更关注的是自身敏捷响应业务需求的能力。相信在信息化时代，大家都听过一句话“上ERP找死，不上ERP等死”，其实就是反应企业内部效率管理问题。而在数字化经济时代的今天，企业核心问题在于解决当外部商业不断快速的发生了变化时，业务部门随之对业务创新提出了高需求，而这时候企业到底有没有这样能力去支撑和实现这些诉求，这背后的所需要的正是敏捷响应业务的能力。

从技术演进看中台架构

阿里的中台并不是老马一句话就设计出来的，它一共经历了四个阶段，三次演进。最早在2008年的时候，阿里自身IT还是烟囱式的架构，当时淘系一共300名工程师，经常会碰到即便加人效率也提升不上去的情况，第一个问题就是我们每改任何的一个功能都要做全量回归;第二个则是性能问题，哪怕我们可以部署很多实例，数据容量不够了，本质上是性能拓展和开发上线效率的难题。针对这种情况我们通过做了“千岛湖”和“五彩石”两个项目将阿里IT从烟囱式到服务化的转变，即所有服务模块拆分开来，解决了架构性能问题，不再有单点故障，它沉淀的是什么呢?是互联网的一些中间件和研发框架。

三淘(淘宝、一淘、淘宝商城)时期，我们做了很多微服务，如订单、交易、营销、结算等，因为各个BU还是各自都做了自己的一套系统，这时候我们发现其实有很多重复的没必要的建设，产生了很大一部分的能力浪费。对于消费者来说，他们所面对的前端界面肯定是一致的，我们后端系统的割裂对我们业务创新会带来极大的挑战，且人力成本消耗浪费也很庞大。为了提升业务响应能力我们完成了服务化到平台化的转变，这种转变的核心在于自上向下去做整体的架构设计，将能力领域重组并且做成熟，我们成立了“共享业务事业部”，把公共的业务能力划归到共享业务事业部去做，如我们的交易中心、商品中心、结算中心等，此时我们注重的还是业务边界职责的划分。

那么阿里又是是如何从平台化演进到中台的呢?现在阿里发展的越来越快，可能有上百个BU，这个时候就会碰到推火网以下问题新的业务需求不断提给交易平台，排队的情况也愈演愈烈，就有种原始的烟囱式架构那种感觉。这个时候我们做了一个决定，去掉“业务”两字，变为“共享事业部”，那我们到底共享的是什么?其实是为业务提供标准能力，例如交易场景中的担保交易、货到付款等基础能力的标准化，然后由上层业务自身去决定如何实现创新。从平台化到中台，它核心解决的是快速和低成本的创新。这个时候我们更注重的是业务能力标准、运行机制、业务分析方法论、配置管理和执行系统这一系列问题。以上就是阿里中台演进的一个完整过程。

企业更需要的是中台级的服务

中台架构为代表的数字化趋势是非常明显而且不可逆的，业务打通，技术打通，数据打通，这是企业的基本诉求。中台的诞生对于目前很多企业来说其实是一个比较大的一个刚需。对于要上中台的企业来说，到底我们今天是为什么买单?是为中台级的服务买单，还是为中台级的团队买单，还是为中台级的项目买单?在回答讲这个问题之前，我先大胆抛出我自己多年中台实践下来的观点企业更应该关注中台级的服务，并且如果没有低代码加持的中台，其实都是在收企业的智商税。

大部分中台公司都会告诉我们中台是需要持续迭代的，快速演进的，所以企业要去构建一个中台级的团队，然后不断的去完善这个迭代。但对一家企业来说，如果我已经有了这样一个中台级的团队，那我再找一个中台级的软件公司来给我服务呢。反过来说，这种说法背后意思其实是如果中台建设一旦出了问题，即对业务的响应速度不够快时，责任就又回到了企业即我们在座的CIO身上，那是因为团队没有建设起来。而另一方面，实际上大部分企业也并不太能招到那么多精通互联网架构的人才和好的研发人员。，如果让甲方企业去靠自建一个完美匹配的团队去上中台来维持这样一个庞大的体系，其实反而是起到副作用的。除此之外，运维这么一套庞大的体系，也可能需要向这类中台公司去支付额外的一些底层诸如PaaS、Devop等成本。，的结果往往可能是各位花了钱，但没有达到效果，这便是中台今天的一个困境大多数企业组织的能力其实是达不到当下互联网中台的要求。这也是我们为什么说中台需要结合低代码。如果现在还有中台公司告诉你说，你需要庞大的团队去运作，然后去支撑这个业务，那我觉得你可以大胆去讲，我们需要的是中台级的服务，我们需要敏捷响应业务的能力，我能否不建这样的团队，同样去享受这样的能力呢?