03 | 中台定义：当我们谈中台时到底在谈些什么？
企业为什么要建中台？
请订阅文章所属专栏。
精选留言(57)
笑若海 置顶我觉得平台与后台的关系可以借助System of systems的概念来理解，后台对应systems，对应于企业建立的各种职能IT系统（如CRM ERP OA 库存管理 采购 供应链 研发 制造等）；平台对应system，将职能IT系统有机集成起来，作为一个整体对前台服务，而不是各个职能系统之间的点到点集成对前台提供服务。
平台层在互联网企业中兴起前已经存在，只是传统企业中IT部门作为辅助职能部门，缺少话语权和主导性，没能上升到企业级高度。而互联网企业敏捷、快速响应用户的企业文化将平台化做到了新的企业级高度。
平台与中台的异同——“中台是企业级能力复用平台”这一概念解释的非常准确，平台化刚被互联网企业喊出时，侧重于IT能力去重，是cost saving，中台则侧重业务能力灵活复用，是value add。
平台化/中台化本质上就是企业IT系统集成的一种设计理念，以高效的价值创造和成本控制为目标。2019-10-06 19
XuToTo那么所谓的 BFF 是否算是一种「中台」呢？作者回复: XuToTo，你好～
好问题哈，不回答都睡不着觉了……
首先这两者不在一个抽象层次上，解决的问题也不同，BFF更多是技术架构层面，中台更多是在应用架构层面。
但是，我之前也用BFF来类比过中台，主要为了让技术同学们理解“向前看”这个概念。
不过后来觉得还是有一些不同，主要在于BFF和中台虽然都强调“向前看”，但BFF往往是专注于服务一个前台；而中台的特点就是通过抽象后可以同时服务多个前台。
如果非要类比的话，更像是由GraphQL实现的统一BFF层，不知道你是不是也能理解～2019-09-25 3 22
业余草中台化是平台化的下一站，是平台不断对于自身治理演进、打破技术边界、逐渐拥抱业务、容纳业务、具备更强的业务属性的过程。中台关注为前台业务赋能，真正为前台而生。作者回复: 业余草，你好~ 这段，尤其是中台化与平台化的区别，困扰了我很久，算是我最近几个月，通过跟各位前辈学习到的一个我认为对我非常有关键的点。
以前我一直在试着找这两者之前的区别，并没与把它们放到一条线上来按照阶段去理解，很高兴也你也能认同~
有问题可以继续留言，我么继续交流~2019-09-26 1 10
rexzhao老师你在文中说，中台关注为前台业务赋能，真正为前台而生。如果前台的概念是最终用户直接使用的系统，而后台则是企业内部的财务管理系统，资源管理系统。 那为什么中台不能也为后台赋能呢？我们之前给客户做的系统或服务就是在用户之前的HR管理或财务管理系统上做很多的报表的制作和修改，中台能帮到这类系统吗？谢谢。作者回复: rexzhao，你好～
好问题哈，我划分前后台其实主要还是从SOR，SOD和SOI出发分析的，如果一个后台就是纯的SOR，那最核心的目标就是管理好自己该管理的企业最核心的数据，功能可能也就是简单的CRUD。
这时候其实也并不需要什么中台赋能，但是像你说的实际中我们看到的一些后台系统，本身除了对于核心数据（人力，财务）的管理外，还有很多的其他功能，例如报表之类的。
那可以理解这时候，这个后台系统已经不是单纯的SOR了，还包含了一些SOI的属性，当然中台作为SOD也可以对其赋能，例如通过数据中台对于财务数据进行二次加工，再返回到财务系统中。
不过总感觉有点奇怪，如果是我，我还是建议将这部分SOI的部分（报表）与SOD的部分（核心财务管理）分离开，这样也减少了对于SOR部分（核心财务管理）的频繁变动，增加其稳定性；又能对于SOI（报表）部分快速变化，不受核心财务模块的限制；中间再通过一层中台的SOD赋能，感觉这样整体架构更顺一些。
不过回到你具体的例子，在不了解上下文的前提下，我这也只能算是纸上谈兵，还得要看具体的情况，只是希望回复对你有所启发，更多从从解决问题的角度出发，活学活用。
感谢你的留言，有问题可以继续留言探讨～2019-09-30 7- vkingnew中台 个人的理解，承上（前台）启下（后台），提高数据等公共资源的复用能力，提高开发和服务的效率，对前中后台来说即高内聚低耦合，各司专职。
作者回复: vkingnew，你好~ 感谢再次留言：） 概括的很到位哈~
2019-09-26 7 
MG老师您好，请问“复用”和“去重”有什么区别呢？我能理解“去重”，即是“去掉重复的”，那么既然“去掉”了“重复的”了，不就是在“复用”了么？请老师指教，谢谢！作者回复: MG，你好～
我在文中也提到了一些，可能没有讲的特别清晰。我举个例子，例如你和我，咱们是两个业务线，都有重复的用户数据，后边有一个用户中台说要整合我们两方的用户信息和用户处理逻辑。
如果对于中台来讲，只要去重就好了，那它会更多考虑你我两边有哪些数据或是功能是重复的，然后拿走，统一在用户中台里管理，只要你我没有重复中台就完成任务了，但是你我的数据被拿走了，再拿回来或是做一些调整可能就费劲了，因为中台关注的只是重复有没有消除，并不关心前台是不是可以继续很好的使用这些被“去重”的数据和功能。
所以我觉得“复用”这个词在去重的前提下，还有更多的“用户视角”，从用户的使用体验出发，关注“可复用”和“易复用”性，也就是你不能光去重把数据和功能拿走，还得提高复用性，让我前台业务还能很好的复用这些数据和功能。
去重向后，复用向前，这个视角的变化我认为也是中台的根本价值。
希望回复能帮你理解，有问题可以继续留言我们再探讨～2019-10-01 2 6- xiaosui1209业务中台和数据中台的意义很清晰，但是技术中台呢？企业的技术架构一直以来就是向着平台化组件化演进的，技术架构提供的能力也本来就是企业级可复用的，那么我们为什么要说技术中台这个词，它和企业传统的技术架构的本质区别在哪里？
作者回复: xiaosui1209，你好～
就像我文章提到的，技术中台目前还有一些争议，我看到很多的企业在做技术中台和原来的中间件平台本身上也没有太大的区别，所以常被人说只是贴个概念而已……
但是，如果我觉得中台相比与平台的价值，就是其更贴近业务，从业务视角而不是技术视角出发的话，那如果能通过中台这个概念为驱动力，促使企业的内部技术平台再像业务走出一步，无论是针对用户体验做优化，还是通过产品化，让业务可以自助式（Self-Service）地使用企业技术组件的能力，如果能做到这些或是起到这样的驱动力，我觉得在我眼中技术中台这个概念才有价值。
这里有个好例子就是在10总结篇里我推荐的蚂蚁金服搜索中台的案例，可以下载PPT看一下，他们对于技术平台和技术中台的区分原则。
希望回复能帮助到你，感谢关注，有问题继续交流～2019-10-14 2 
Mr_杨一直关注中台相关的内容，但一直无法准确制定中台，平台，微服务这几个关系和边界。
说说我的理解，比如交易平台，提供的只是交易的通用服务，比如成单，查询，改单，可以认为这是微服务(不知是否准确)。这种服务只是抽象了功能，和交易行为，无法区分不同业务线的交易，这时候就需要中台将业务抽象化，比如外卖，线上，线下交易所需要的流程不同，(线上和外卖需要履约流程），这时候就需要中台将交易业务流程进行组合抽象，对外提供不同业务的执行流程。
总结一下就是微服务或者平台是对功能的抽象，中台是对业务的抽象，欢迎大家给不同意见作者回复: Mr_杨，你好～
微服务、平台、中台这三个概念确实比较容易混淆，也是大家最关心的问题。
我在本篇中，简单讲了一下我对于平台和中台区别的看法，在07中简单讲了一下微服务和业务中台的区别。
简单讲，从企业架构层面，微服务是技术架构层面的事情，不一定解决的就是业务中台要解决的复用的问题，一个系统为了一些原因例如模块弹性，也可以是微服务架构的。平台和中台都是应用架构层面的事情，中台是平台的发展的下一站，是平台为了更好的赋能前台业务，通过对于自身的不断治理演进，向业务不断靠近，包含更多业务元素业务属性的产物。
这是我到目前的理解，在文中也展开分析和介绍了，希望对你和其他朋友区分开这这几个概念有帮助～2019-09-30 1 2
未未的未来个人理解，中台：满足业务需求的即开即用的工具箱。作者回复: 未来的未来，你好～
我看到这篇留言里，大家都给出了自己对于中台的理解，都非常棒～ 感谢你的分享，你的这个理解很形象哈～
对于中台，因为其包含的范围太大了，我觉得也很难或是也没必要非要找到一个唯一的理解，在不同的上下文下有不同的解读只要能帮助我们大家对齐共识，朝着同一个方向前进，规避一些问题都是好的。
感谢你的分享，有好的想法还希望能分享出来，我们大家一起学习探讨～2019-09-28 2
Pantheon平台感觉是可以和业务无关性,比如搭建一个hadoop平台,平台的抽象应该更高,提供这样的一个东西,具体怎么用是使用者的事情,中台的概念是业务相关性,中台是需要承载业务的,比如我现在是在教育公司,也有多个业务线,每条业务线都离不开直播上课的概念,那中台可以下沉上课系统和课表系统,不知道这样理解对不对2019-09-28 2
水源我认为某些项目驱动型企业在刚开始的阶段，并不会从全局视角体识别出自己具备哪些可以复用的的“能力”，因为烟囱建的太多了。项目负责人、技术负责人都在围绕各类需求修补烟囱。这时开展中台策略，由于人手问题、项目进度问题，会另大家无从下手。而系统服务化，应该是比较好的切入点，对于烟囱中存在一个或者两个主要通病（痛点）的部分，抓出来进行服务化尝试，使他逐渐演化为中台的一部分，在不影响项目进度的前提下，体会到“能力”的存在。然后再对烟囱逐步拆分，中台化。作者回复: 水源，你好~
同意你的观点，原来我也认为只有已经烟囱林立的企业，有了痛点，才会意识到全局的治理，也只有这样的企业才需要建中台。
不过后来跟很多产品型互联网企业聊过之后，发现有一些非常有战略思维，对自己的业务和核心竞争力非常清楚的企业，一开始建第一个产品就是用中台的思路去做的，确实令人钦佩，对团队要求也极高，很容易做Over。
而中台的建设思路，一开始一步到位大而全确实比较难，我一般是分成三步：“系统服务化，服务共享化，企业中台化”，以点及面，找到不同干系方的利益结合点，快速见效，逐步推广，产品化运营。
09的时候聊了一些中台运营的思路，也是在想如何通过有限的资源，平滑的在企业内建设与运营推广中台，同时避开组织与利益等相关敏感的问题。
可以到时候有问题再展开交流~感谢留言分享。2019-09-26 2 2
Darren一个中台的构建过程是：功能->系统->平台->中台，我觉得老师的定义特别的棒，看到后恍然大悟，我在上节课的留言虽然和老师定义的‘企业级服用能力’有点类似，但是没有老师的清晰明了，最后稍微补充下，企业级的复用能力，可能各个能力在被复用的时候，或多或少有稍许不同，在中台化实现的时候们，可以通过扩展点去实现。作者回复: Darren，你好~
又见面了哈，感谢你的肯定，尤其是最后的补充，确实非常关键，我看到也有朋友提问问到了如何在复用的时候处理特性需求。
确实一般都是通过业务抽象，加扩展点（SPI，FPI等机制）来实现的，具体的案例我觉得总结篇里我推荐的滴滴的案例讲的非常好，也非常详细，大家感兴趣可以作为扩展阅读。
感谢留言，有好的想法或是反馈可以继续交流~ 下次见。2019-09-26 2
文西老师，我们是一家做外包项目的公司，很多小项目可能功能都差不多，但是每次都是拿之前的代码复制一套再改改，这种需要中台吗？作者回复: 文西，你好～
你觉得这样拿之前的复制一套再改一改会有什么问题么？如果每一个项目都是独立的，这样的方式也是最简单直接有效的方式，那我认为也没有上中台的必要。
如果假设你们的问题是可能之前的代码有bug，一改都得改，那其实把一些组件沉淀下来成为独立的jar就够了，只要做个修改，所有的项目一更新组件版本就可以解决这个问题。
如果假设你的问题是每次再改改的工作是重复的，那也可以看看是不是想办法把这个过程抽象一下，通过一些配置点来实现业务的灵活配置与生成。
而这个平台可能就是你们企业的“中台”，或是其他，都不重要。还是我说的，还是要回到你的问题，去找解决方案。
希望我的回复对你有所帮助～2019-10-13 1 1- zart请问老师，白屏化是指啥？
作者回复: zart，你好~
可以参考一下10总结篇中分享的《从平台到中台 | Elaticsearch 在蚂蚁金服的实践...》，可以简单理解成给平台类产品做一个配置界面，实现自助式（Self-Service）服务，因为很多平台类的产品都是企业内部使用，所以对于界面没有很强的UI要求，大家一般都是一个白页面，加一些配置项，所以叫白屏哈~2019-10-10 1 
Gopher老师的见解很深刻、全面，大赞，感谢解惑！～
花了2个小时来学习这篇文章、查资料、做笔记～如获至宝🤪🤣作者回复: Gopher，你好～
感谢你的肯定，主要是很高兴看到我的内容确实对你有帮助，期待更多分享～ ：）2019-09-30 1
唸看了老师这几篇文章，我个人感觉有点像缓存的味道，只不过缓存的是服务而不是具体的数据库数据，而且需要更高的包容性，这么理解对吗作者回复: 唸，你好～
有点像缓存的意思，位置上也很像。
但缓存往往是单纯的解决性能问题，所以一般没有太多业务逻辑的，只是单纯的让数据离用户更近一些，后台是主，缓存是辅，当出现不一致的情况下也往往以后台为SSOT（Single source of truth）。
这一点感觉中台就有些差别，首先中台往往承载了企业的核心业务逻辑，甚至是中台为主，后台为辅，当出现中后台不一致的情况下，也往往以中台为SSOT（这种感觉有点像你用一些支持离线功能的文本编辑器，断网了还可以继续编辑，联网了，内容会以app为准，再同步到后台）。
希望我的解释能帮你更好的搞清楚这两个概念之间的区别和联系，有问题也可以继续留言探讨～2019-09-28 1
hanbing前台和中台的边界应该如何准确的界定？公司也在建中台，前台和中台经常因为边界问题该你做还是我做产生争执，应该如何准确的定义边界呢？作者回复: hanbing，你好~
好问题哈，也算是经典问题之一了。
不过我看了一下评论区，其实问到的并不多，正好借这个机会展开聊一聊我的理解。
对于前台和中台的界定，我们在不同的时间尝试过很多种不同的划分方式，但总觉得有局限。例如，如果最简单按照是否重复来划分，重复的放中台，特性的放前台，先不说是否重复就很难掰扯清楚，而且放到时间线上，现在一样的可能以后会不同，现在不同的难免以后也可能会相同，这本身又很难扯清楚，更别提局部重复等情况。
其他的分法，也会有同样的问题，例如按照业务重要性，那怎么判断重要性高低，这些都是问题。
我觉得要想想通这个问题，需要几个关键点：
1. 还是要想清楚，中台建设的愿景是什么（会在下一节04中展开），想好中台自己的方向和产品定位，一个清晰的愿景往往就代表了一个好的边界，这个边界能帮我们判断哪些该做哪些不该做，先做什么，后做什么。
2. 要想清楚，就像本文提到的，中台是企业级的问题，中台与前台的划分边界，其实本质上就是企业内横向的平台类组织和纵向的业务类组织的划分边界，也就是组织责任与利益的划分边界。在最后一篇总结篇里，我也会讲到，中台的核心价值就在于企业对于经济性和灵活性的平衡，而组织的碰撞（像你所描述的部门之间的争执），在我看来反而正是企业在不断追求这种平衡的“动作”，是正常的，也是必须的，我甚至认为中台与前台的边界，也只能靠不断的组织碰撞，才能找到一个最佳的平衡点，而这往往也是针对于这家企业整体经济性和灵活性的最佳平衡点。而我们要做的，就是设计一套机制，例如冲突处理升级机制，来正确的引导这种碰撞向解决问题的方向，而不是相反的方向前进。
3. 用演进的眼光来看待，不要奢望，一次想对，一次分对，一次做对，尊重变化，承认自己的弱小，追求变化响应over追求一次做对。
我现在就是用这几个角度来思考，中台与前台的边界的，具体到Action上，就是：想好愿景，合理引导组织碰撞，演进式思维。
希望我的回复，对你有启发和帮组，有问题欢迎继续留言，我们再做深入探讨~2019-09-28 1 1
下一道彩虹现在正在为企业策划建中台，看了各种中台思想，各种中台理念的碰撞，各种中台需求的接入，各种验证、排除、越做越迷茫。在这个时候与这个专栏相见。我现在的情况很帖合“ 不愤不启，不悱不发” 这句话中学生的状态。 感谢王健老师经验总结，感谢极客时间提供这个平台！作者回复: 下一道彩虹，你好~
看到你已经读完了，刚回复完10的留言，发现03还有一个。
看下来感觉可能你我的视角比较类似哈，之前我也是你上面提到的这样一个迷茫的状态。也是不断的碰壁和思考，以及跟不同视角的人，不同企业的人交流碰撞，试图探索中台地图的全景。一直在纠结中台到底是什么，长啥样，在不断的挑战各种问题。
不过最终还是向您最后说的，知难行更难，开始做了，做的多了，面对的问题也多了，反而很多原来的知识片段连起来了，也看的透了，心态也平和了，也就没那么迷茫了，走着走着也就走出来了。
很高兴能有一些共鸣和帮助，也很感谢极客时间这个平台也给我了这样一个机会，和更多的人探讨，期待与你再次交流~~2019-09-25 1
毛毛可复用，即功能模块需要有通用性。如何解决不同前台的个性化需求呢？
中台：从前台拆分出通用的功能模块，具有可复用、迭代快的特点。作者回复: 毛毛，你好~
又见面了😁，好问题哈。我的回答就是：
对于个性化需求，能放前台的放到前台，不要什么都往中台放；不能放中台的就做一层抽象，通过配置化和插件化，来支持个性化需求。
当然这又会引出另一个经典的问题，就是前台与中台的边界到底该怎么界定，这块我是通过结合中台的愿景和现状分析来识别和界定的，后续会展开讲到。
而中台内的配置化和插件化、服务化的过程，我这么讲比较干，可以参考10总结篇中滴滴出行中台的构建思路，我觉得在这方面是一个非常好的案例，讲的思路也比较细。
学到后边，有问题继续留言，我们继续沟通交流~2019-09-25 1
张玉鹏平台化侧重于IT能力去重，是cost saving；中台则侧重业务能力灵活复用，是value add。
这句话说得好！2019-12-09