中台到底是个什么鬼？终于有人讲清楚了！
点击上方 "程序员小乐" ，关注公众号
8点20分，第一时间与你相约
每日英文
Be impulse sometimes reflects your passion for life; Be impulse all the time reflects your innocence of the life.
还能冲动，说明你对生活还有激情；总是冲动，说明你还不懂生活。
每日掏心话
时光悄悄地流，岁月静静地走。给自己一片天空，无论风雨，勇敢飞翔；给自己一抹微笑，从容自信，洒脱坚定。
来自：六六老爹 | 责编：乐乐
链接：jianshu.com/p/5680a3d20050
图片来自网络
正文
最近BATJ互联网巨头频繁提到中台，大有中台一统天下之势。作为一名爱学习的PM（主要是心慌）怎么能不做一个弄潮儿呢？通过学习大牛们的分享试着去解剖中台。
本文旨在快速梳理中台浅层次知识，希望完成以下5点认知目标：
1.什么是中台？
2.为什么建中台？
3.各大互联网公司是如何搭建中台的？
4.用什么原则建设中台？
5.所有公司都适合建中台吗？
1.什么是中台？
在说这个问题之前，需要首先应该定义2个概念：前台和后台。
前台：由各类前台系统组成的前端平台。每个前台系统就是一个用户触点，即企业的最终用户直接使用或交互的系统，是企业与最终用户的交点。例如用户直接使用的网站，手机App，微信公众号等都属于前台范畴。
后台：由后台系统组成的后端平台。每个后台系统一般管理了企业的一类核心资源（数据+计算），例如财务系统，产品系统，客户管理系统，仓库物流管理系统等，这类系统构成了企业的后台。基础设施和计算平台作为企业的核心计算资源，也属于后台的一部分。
2.为什么建中台？
定义了前台和后台，对于第二个问题（企业为什么要建中台），同样先给出我的答案：
因为企业后台往往并不能很好的支撑前台快速创新响应用户的需求，后台更多解决的是企业管理效率问题，而中台要解决的才是前台的创新问题
大多数企业已有的后台，要么前台根本就用不了，要么不好用，要么变更速度跟不上前台的节奏。
我们看到的很多企业的后台系统，在创建之初的目标，并不是主要服务于前台系统创新，而更多的是为了实现后端资源的电子化管理，解决企业管理的效率问题。这类系统要不就是当年花大价钱外购，需要每年支付大量的服务费，并且版本老旧，定制化困难；要不就是花大价钱自建，年久失修，一身的补丁，同样变更困难，也是企业所谓的“遗留系统”的重灾区。
总结下来就两个字“慢”和“贵”，对业务的响应慢，动不动改个小功能就还要花一大笔钱。
有人会说了，你不能拿遗留系统说事儿啊，我们可以新建后台系统啊，整个2.0问题不就解决了。
但就算是新建的后台系统，因为其管理的是企业的关键核心数据，考虑到企业安全、审计、合规、法律等限制。导致其同样往往⽆法被前台系统直接使用，或是受到各类限制⽆法快速变化，以⽀持前台快速的创新需求。
此时的前台和后台就像是两个不同转速的⻮轮，前台由于要快速响应前端用户的需求，讲究的是快速创新迭代，所以要求转速越快越好；⽽后台由于⾯对的是相对稳定的后端资源，⽽且往系统陈旧复杂，甚至还受到法律法规审计等相关合规约束，所以往往是稳定至上，越稳定越好， 转速也自然是越慢越好。
所以，随着企业务的不断发展，这种“前台+后台”的⻮轮速率“匹配失衡”的问题就逐步显现出来。
随着企业业务的发展壮大，因为后台修改的成本和⻛险较⾼，所以驱使我们会尽量选择保持后台系统的稳定性，但还要响应用户持续不断的需求，自然就会将大量的业务逻辑(业务能力)直接塞到了前台系统中，引入重复的同时还会致使前台系统不断膨胀，变得臃肿，形成了一个个⼤泥球的“烟囱式单体应用”。渐渐拖垮了前台系统的“⽤户响应⼒”，用户满意度降低，企业竞争力也随之不断下降。
中台就是在这样的环境下诞生。
华为在几年前就提出了“⼤平台炮火支撑精兵作战”的企业战略，“让听得到炮声的人能呼唤到炮火” 这句话形象的诠释了大平台⽀撑下小前台的作战策略。这种极度灵活又威力巨⼤的战法，使之可以迅速响应瞬息万变的战场，一旦锁定目标，通过大平台的炮火群，迅速精准对于战场进行强大的火⼒支援。
我们先试着给中台下个定义：
中台是真正为前台而生的平台（可以是技术平台，业务能力甚至是组织机构），它存在的唯一目的就是更好的服务前台规模化创新，进而更好的响应服务引领用户，使企业真正做到自身能力与用户需求的持续对接。
中台就像是在前台与后台之间添加的⼀组“变速⻮轮”，将前台与后台的速率进行匹配，是前台与后台的桥梁。它为前台而生，易于前台使用，将后台资源顺滑流向用户，响应用户。
中台很像Pace-Layered中的SOD，提供了比前台（SOI）更强的稳定性，以及⽐后台（SOR）更高的灵活性，在稳定与灵活之间寻找到了⼀种美妙的平衡。
3.各大互联网公司是如何搭建中台的？
看看各大企业对于建设中台的对外呈现吧。
1）阿里云——业务数据双中台
阿里云中台主要由业务中台和数字中台并肩构成了双中台，并肩支撑所有前台业务。
2）端点科技——企业中台产品（业务中台和数据中台）
端点科技的企业中台产品：将企业的核心能力以数字化形式沉淀到平台，形成以服务为中心，以业务中台和数据中台构建起数据闭环运转的运营体系，供企业更高效地进行业务探索和创新，以数字化资产的形态构建企业差异化的核心竞争力。
3）聚龙云
4.用什么原则建设中台
可以看到，包含互联网企业在内的各大企业都开始风风火火地进入了中台建设，那么企业在建设中台应该符合哪些原则呢？以下是笔者个人从产品思维出发，思考的对于建设中台的几点原则：
1）通用
标准统一，实现数据打通、可通用性。
数据打通是需要整合企业内部被“部门墙”割裂的数据。
不过，数据究竟要打通到什么程度，每个企业可能有不同的做法。
比如，扎克伯格在3月7日发布文章《以私域为中心的社交网络愿景》中正式提出将打通Facebook旗下App，将实现Whatsapp上可以接收Facebook、Instagram的信息。而马化腾在18年11月第五届世界互联网大会的论坛上则说：“我们要从用户的角度来考虑，把个人信息和数据保护放在优先地位，而不能套用其它公司的做法，把数据直接去任意打通。”他强调腾讯不会任意打通数据，技术中台会打通，但数据中台会特别谨慎。
2）组件化
中台提供的服务最好以组件化的方式让业务端可以即取即用。组件化设计可以避免系统间耦合性大，牵一发而动全身。这需要针对共用服务进行抽象设计。通过抽象出的组件化服务提供，前台业务端可以以组合挑选的方式“按需取件”，减少重复建设得以实现。
3）可复用
中台提供的服务是应该可以即取即用的。不仅如此，这次用完，下次还来。业务A用了，业务B也来用。一个中台提供出的公用服务的价值高低，是“可用”和“可复用”的区别。
服务的高复用是对技术层级上针对共用服务的抽象设计能力的一大考验，需要尽可能近地靠近业务、靠近用户。
4）可共用
基础服务有了，那通过中台向前台提供“相应的服务”还是提供“一揽子的服务”？取决于服务提供的可开放共用的程度。就像我们看到，各大互联网决定中台建设的开始，总是要伴随企业层级的组织架构的调整。虽然各部门权限、各业务属权，恐怕不是一句“开放共享”的愿景就能完全解决和无差别共用的，但是通过开放共享实现“可共用”的目标终究是中台建设的原则。
5）可扩展
在一揽子的服务都可输出后，业务量可能会短时间大大激增。能扛得住大流量高峰时期的高并发、高可用将成为一个大挑战。底层的可灵活扩展能力将非常重要。企业应当应用DevOps、Docker等先进的开发技术理念，在中台建设前就开启数字化的技术转型。
5.所有企业都应该建设中台吗？
问这个问题前，还不如我们思考一下，什么样的企业才适合建设中台？以下是笔者个人的观点：
1）业务规模达到一定程度
使用中台意味着企业拥有可沉淀的一定量级的IT资产，企业要充分复用这些IT资产才可以突破当前瓶颈、更高效的赋能业务。但只有企业的业务规模和业务价值达到一定程度才能具备沉淀实施的条件，否则就是杀鸡却用宰牛刀。比如运营商、保险、银行、金融等拥有大量数据的传统国企和BAT这类大互联网公司，它们不仅拥有丰富的数据资产，而且IT规模足够大，建设中台是它们进行企业升级的绝佳方案。
2）已经实践了“系统化、中心化、平台化”
“系统化、中心化、平台化、中台化”，是一个企业在数字化道路上行进的路线。如果一个企业已经成功地实践了“系统化、中心化、平台化”的过程，并比较饱和状态地支撑了前台业务，那么这个企业也许是可以开始考虑向下一步“中台化”的迈进了。
3）有魄力做组织架构重构
中台一定是企业级别的开放共享，否则它将只是某一个事业部或分公司旗下的功能平台而已。我们看到，阿里、腾讯、京东和百度，在开始决定中台建设之际，对于企业层级的组织架构大调整同时发生了，各部门权限和各业务属权发生了大震动。有魄力做组织架构重构的企业，才更适合快速高效地做中台建设。
上述的3个条件，是一个企业开启自我中台建设成功的必要充分条件，缺一不可！
当然，自觉不适合中台建设的企业，也不会就此错过中台带来的好处。不少企业已经开始推出toB的中台产品，未来可能就能像我们用toB的平台产品一样，我们也能低成本地使用中台产品。
小结
一句话总结中台：采用高内聚、低耦合的架构，将IT服务化相通的能力提取出来，将复杂的系统逻辑沉淀到底层，连接后台与前台。
欢迎在留言区留下你的观点，一起讨论提高。如果今天的文章让你有新的启发，学习能力的提升上有新的认识，欢迎转发分享给更多人。
欢迎各位读者加入程序员小乐技术群，在公众号后台回复“加群”或者“学习”即可。
猜你还想看