人生的第一次直播献给了右军和 TGO。
1、几位嘉宾，你们怎么看中台建设，有人把它当成了灵药，也有人说不灵。先请各位聊聊，中台究竟要解决哪些问题？
对我来说，在大多数时候，中台主要解决没有中台造成的焦虑问题。
就好像当年别人家里有了「家庭影院」，于是家家户户不整几个音箱功放就觉得自己的日子过得很不是滋味一样。
因此，可能有 95% 的公司，组织和业务都还没有准备好，因此建设中台不解决任何问题：搞明白中台是什么并且遏制住建设中台的冲动才解决问题。
这也是为什么 TGO 组织的这种讨论挺好的。
剩下那 5%，在公司的组织和业务都成熟的情况下，中台主要就是解决一个复用的问题：笼统来说，软件最大的优势就是低成本复用所以 scale 的时候边际成本很低。
只不过，过去我们解决复用主要是通过平台化，或者具体来说，通过暴露 API 或者暴露结构化、单元化的服务来复用。这种复用是没有业务属性的，业务方需要自己非常熟悉各种平台的各种 API，自己根据自己的业务逻辑去调用和拼装。其次这样的复用也是没有组织依托的，并不会有一个有运营、有服务的团队来跟业务沟通需求。中台只是通过：
- 站在业务角度对可复用的领域模型的处理进行完整的封装
- 通过组织的支撑对中台的运营和服务进行闭环的支撑
来更进一步解决了平台化复用遇到的一些问题。
综上，我觉得如果公司一个主线业务都没有跑通，或者事业部事业群之间没有明显可以复用的功能或者没有复用的组织基础，那就先别整中台，先好好学习什么是中台。
2、从组织的角度讲，如何确定中台项目的KPI并找到主要驱动人?
首先中台我觉得既然它跟平台有很大的不同就是有业务属性，有组织支撑，所以它一定是一个一把手工程：CEO 必须非常支持。
在此基础上，因为中台是解决能力复用的问题。所以横跨多条业务线的角色和组织是比较合适来思考和推进中台建设的。在大部分的组织里面， CTO 干这个可能比较好一些，因为销售、产品、运营一般是闭环到业务里面的比较独立的模块，很难要求某个业务里面的产品来抽象公司的业务都可以复用的中台：大部分情况下他们应该只是中台的用户，能提高质量的需求就已经很好了。但是如果 CTO 没有业务思考和抽象的能力，做起来也是够呛的。
KPI 的话，既然是为了复用，那么核心的就是一些跟效能有关的：使用量、易用性相关的指标。比如接入的数量、调用的次数等等，以及可靠性、是否自助等等。除此之外，接入中台的前台业务方的评价也可以是 KPI 的一部分。甚至，为了倒逼中台组织懂业务和承担业务职责，在早期还可以考虑和前台的技术部门共背一些指标：比如前台技术部门的 SLI、SLO、lead time 相关的，甚至是直接共背业务指标。
3、中台建设遇到过哪些困难，如何解决？
前面说了，中台需要专门的组织支撑，所以首先会遇到组织发展上的困难。
中台组织层面的方法论目前是很不成熟的。无论是按职能的，还是按项目的，还是矩阵的公司，你从现有的组织架构里面拆出中台和前台、后台的团队，然后还要确定这些团队之间的边界和职责，没有明确的方法。所以怎么调整是需要根据每个公司自己的情况做调整的。
组织架构调整的过程肯定会出现矛盾和冲突。特别是因为敏捷流程和产品经理的崛起，现在很多的技术负责人是靠手下面有多少研发，加多上班，拢了多少事情在手里，来保证自己的安全的。
DevOps、微服务，推行过程中都会有类似的挑战。
然后是系统架构上的困难。业务领域的抽象需要对业务的理解也需要技术的深度。有一些基础设施是必须完备的：比如统一的 API 网关，比如端到端的全链路的监控，比如容器化。你的云原生平台怎么做？CNCF 里的哪些自建？哪些用开源的？哪些用付费的？像我们很早就在生产环境全 Docker 化了，再比如 k8s 还不是现在这个地位的时候，我们选择了它而不是 mesos 或者 swarm。你的 PaaS 这层怎么做做什么？你的业务上能够复用的东西是什么？怎么抽象？怎么服务各个业务方？比如数据上，你的数据平台怎么搭建？元数据怎么管？指标体系怎么建？数仓怎么建？提供哪些数据产品（通常 BI、画像这些是最开始的选择）。
4、业务中台和数据中台建设有哪些区别?
这是一个答起来有点困难的问题，因为中台的定义是很模糊的。定义还很模糊的时候，就很难去谈区别。就好像有人问你幸福和快乐有什么区别一样，好像可以聊得很精彩，但其实什么是幸福什么是快乐每个人的定义都不一样，很容易鸡同鸭讲。
按照我对中台的定义，它一定要是针对业务领域的能力复用，它一定要有组织去运营去服务，因此，我心里所有的中台肯定都可以叫业务中台。数据中台可以说是特殊一点的中台。除开业务中台和数据中台，别的中台我觉得都没有叫中台的资格。
比如我看到很多同学在讲技术中台，对于我来说，好像大家讲的就是技术中台一般好像里面就是机器、云、容器等等 IaaS、PaaS 就是基础设施，我不太知道它为什么要被叫成技术中台，因为里面很多东西是没有业务属性的，也不需要运营的。
如果我们对业务中台和数据中台进行一下定义，这个问题可能是可以回答的。
如果你仅仅把业务里面一些相对独立的 domain，比如订单、用户、交易等等叫成业务中台，那么这算是一个相对狭义但确定的定义。
类似的，如果有一个部门负责对数据平台、数据仓库、数据治理等方面进行整合，并通过数据产品给各个业务方自助使用，那可能他们干的就叫「数据中台」。
这样来定义业务中台、数据中台的话，它们的内容就有了明显的区别，那么建设起来也就有了明显的区别。
比如业务上，在解决了基础设施的问题之后，怎么去确定有哪些 domain？如何进行抽象？里面有哪些能力可以被复用？
比如数据上，怎么先通过统一的数据通道、数据平台把数据的采集、清洗、存储统一？在此基础上，怎么通过面向业务支持而不是通过行政命令来实现包括数据质量、数据安全、元数据、生命周期管理在内的数据治理？最终怎么通过数据产品把数据的价值提供给业务方然后得到业务的反哺？
这次直播我最大的感受就是很多人对中台的认知还是很模糊的。不如我就，比较过分地说几点我的结论：
- 如果你还在想是不是要做一个中台，最好别做；
- 如果你是请外面的咨询公司来做中台，最好别做；
- 如果你是做外包的公司，可能你自己会有一个中台（复用嘛，前台改吧改吧就给客户实施了），但是别给用户做中台，随便人家多想要。