资讯详情

为何此时才写中台

中台的风已经吹了好几年，为何此时才来写这篇文章？两方面最主要原因：一是近几年作者忙于实施各中台相关项目，确实没有时间静下心来写作；二是自从阿里提出中台概念以来，各类公司为了赚中台的钱，尚未有多少成功落地案例就开始各种宣传，大概知道个理论就开始夸夸其谈，谈了没多久，还没有几家企业真正成功落地了中台，又爆出阿里准备去中台化，中台不适合支撑创新等言论。这个社会太浮躁，一知半解最危险，特别是中台项目，动则成百上千万的投入，里面各种新概念伴随着各种坑，故作者想想还是不要误人，等真的经过亲身项目实践总结，带有深度思考后再来分享，期望能真正给各位准备做中台或对中台有兴趣的朋友一些中肯的意见参考。

海睿咨询团队成员近年来与某头部珠宝零售企业合作共同搭建业务中台，作者作为乙方项目经理，近乎全职驻场参与中台项目，为客户提供了中台架构规划咨询、业务流程及系统功能设计咨询、系统实施选型及监理服务，项目历时整整两年，总投资额过千万，系统现已正式上线并投入使用。与此同时，从中台理念刚出来时，海睿团队就开始负责为多家大中型零售消费企业提供前、中、后台的整体系统规划咨询服务，尤其近些年，更为多家企业提供中台领域相关的深度咨询服务。

中台渊源及适用场景

相信时至今日关于中台的概念大家或多或少已有些了解，若对中台尚未有基础认识的朋友建议先去搜一些其它的介绍性文章了解下了再继续看作者以下的内容，这里就直奔要点，不再做基础的概念性介绍。

1、  中台渊源： 

作者从中台概念出来没多久就开始与各个中台相关互联网厂商密切接触，踏着产业互联网的浪潮，借着马老板们的名望，各大互联网产商雄心勃勃，想着以中台为切入口，颠覆传统行业信息化建设，扛起传统企业数字化建设的大旗。但刚开始时作者觉得这帮互联网的哥们还是有些膨胀的，或者说是“飘”的，这种飘一是源于过往ToC业务做得太成功，觉得再加上资本的加持，应该没有自己搞不成的事；二是觉得自己技术架构得到过类似阿里双11高并发等场景的考验，从技术层面应该是完虐传统软件的；三是低估了传统企业，特别是一些头部大企业供应商选型时技术以外的影响因素对最终决策的影响度。总结下就是一帮基本不太懂传统企业业务的哥们，带着所谓中台的领先技术理念（云原生），且当时其实也没啥真正的成功案例，就开始往前冲，然后各种软文满天飞，随便做一个什么系统都号称是中台，一下出来各种中台，如业务中台、技术中台、组织中台、移动中台、财务中台、物联网中台、AI中台等，搞得作者也跟着迷糊了一段时间，花了大量的时间去思考、探究及验证到底什么才是真正意义上的中台。

当然现在互联网公司们在这方面已成熟很多，一是因为招了很多咨询公司的顾问，一定程度上弥补了些之前不太熟悉传统企业业务的短板；二是因为经历了更多经验累积更丰富，理解了在ToB行业已经沉淀了几十年的传统咨询公司和软件公司们也并非纯靠忽悠而毫无实力，故迄今很多互联网企业也不再像以前那样仅是鼓吹中台，而是站在更全面、更深入的视角去整体看待传统企业的数字化建设。

 最近又有很多软文在讲“去中台化”，中台才搞没几年又要开始去了吗？作者不知道这帮大哥们有没有把中台的价值和适用场景真正搞清楚，而此时写这篇文章的目的就是为了把此问题先和大家讲清楚：

首先，作者所理解的中台渊源，并不是常说的“敏前台、强中台、稳后台”架构或马老师看了个游戏公司后的领悟之类的，当然这些说法也没啥错，但是不算这事的本质。真正渊源应是因为阿里具有全中国近乎最高的高并发应用场景（双11），2020年每秒并发峰值约50万单左右，这么高的并发访问量对服务器配置要求超高，传统的IOE硬件资源是一笔超高的费用，然而过了双11，日常的销售里其实又没有这么高的并发，硬件资源买得太多又是一种极大浪费，怎么解决这个问题，那就是采用分布式系统架构，用微服务、容器等技术，再结合devops体系及敏捷开发方法部署到云上，这些共同构成了云原生的概念，当然云原生还有其它很多优势不仅仅只是在硬件成本方面。

分布式的技术架构相比传统单体式软件架构确实有本质的提升，但理论上这套架构适用于任何系统，而非仅是“中台”，如今中台这么火，仅是因为中台确实往往具备对系统的三高要求（高性能、高并发、高可用）及对弹性收缩硬件资源需求，再加上中台是新概念，对传统企业来讲意味着是一个新系统，算是一块空白市场/增量市场，理论上市场需求较大，所以两者自然而然的联系到了一起，也才有了后续很多技术型创业企业以此（云原生）为卖点之一在打单过程中进行各种宣传，实际上中台是不是一定要用云原生/微服务的架构，作者的理解是“不一定”，到底用哪种架构还是要取决于企业本身的业务模式、业务体量及业务复杂程度，云原生体系较大程度上增加了技术的复杂程度，需要更多，甚至多很多的技术资源投入方才能支撑，且微服务的方式会增加后续的运维复杂度，同时微服务架构的搭建往往不是一趋而就的，后续地持续运营亦非常重要，这意味着运维端也需要投入更多资源，所以如果企业业务量并非很大、业务复杂度也不是太复杂，且中长期来看业务量也不太会出现指数级暴增，即系统并不太可能会遇到性能瓶颈，那单体应用反而会是更好地选择，同时做下集群（负载均衡）、数据库优化、分库分表等一样可以支撑。

总结下中台产生及流行的本质源于技术的革新，如若没有云原生技术架构体系，从系统视角看（数字营销）中台就约等于OMS【交易中台】 + CRM/SCRM/CDP/MA（这几个现在业界概念有些混，不同厂商的产品功能定义切分不完全一样）【客户中台】，但对于绝大多数传统企业，中台要真做好的关键却更多在于业务/产品而非技术，切忌舍本逐末以为换了个好的技术架构系统就好了，系统的本质是对业务的承载，对业务的理解和洞察不够深刻，且没有较强的规划设计能力，怎么可能光凭技术领先就能做出好的业务系统。

2、中台适用场景

基于过往多年中台项目相关经验，作者总结了有三种情况最适合做中台，一是各业务板块是相关多元化的集团型企业，即总部下各板块业务模式和业务能力高度相似，仅是产品或服务有所不同，各板块存在大量业务能力共性，如都有订单管理、商品管理、库存管理等能力需求；二是企业本身有全渠道营销业务，即企业的营销不依赖于某单一渠道，而是多点开花，终端客户与企业互动交易具备全渠道、碎片化、多触点的特征，此时企业在交易管理及客户运营层面会有统一管理及能力复用的需求；三是企业业务具有周期性，即业务量有波峰波谷，典型代表如电商业务存在双11、618等，不同时间段对服务器性能要求不同才更适合云原生架构，可充分运用云的灵活伸缩的弹性算力。将凡存在以上三种情况之一，都可以考虑搭建企业中台，如若三种情况都存在，那就不要犹豫赶紧上吧。

因文章篇幅长度关系，本文将分上、中、下三篇进行发表，上篇主要讲中台渊源及适用场景，中篇将详细讲述业务中台的建设方法，下篇将讲述对数据中台建设的观点看法及相关核心问题答疑，若以上内容看完尚觉意犹未尽的朋友欢迎关注我司公众号，中、下篇也即将于近期陆续发布。