你好，我是王健。
专栏9月25日上线，到现在有一个多月了。说实话，确实没有想到有那么多的朋友关心中台相关的内容，首先谢谢你的支持、鼓励、意见和反馈。
在这一个月的时间里，我也一直在持续关注着你的留言互动。简单统计了一下，到目前为止，留言总数已经超过了300条，并且每天还在持续不断地增长，心存感激的同时也感到压力倍增。
留言中有很多非常好的问题，非常在点子上，我也尽力做到有问必答，希望能对得起你的支持和时间。同时在和你的交流中，我也学到和领悟了很多新知识。
记得一位老前辈就曾说过，知识分享的过程并不是一个单纯的知识输出过程，而是一个知识输入与学习的过程，对此我深以为然。做这个专栏开始时我也给自己定了一个小目标，就是驱动自己对中台背后的知识再做一次系统化的归纳整理与学习，与更多人一起交流探讨，不断捶打与夯实这些知识，从结果来看，确实是达到了。
今天呢，是我们专栏的答疑篇，我来统一解答一些大家都比较关心的问题。但我的解答肯定不是标准答案，也可能不全面，希望你可以继续留言评论帮我补充或者指正，我们一起讨论甚至辩论，我特别喜欢这样的氛围。
为了写这篇答疑篇，我又从头到尾把这300多个问题（有的还没来得及回复）完整地看了一遍，我发现大家普遍关心的，可以归纳为下面这四个问题：
所以今天我就试着从这几个问题展开，聊一聊我的看法。因为内容比较多，我把答疑分为了上、下两篇。这一篇我们先来看前两个问题。
这个问题是大家问得最多的，其实这是三个问题，但我觉得相关，就放到了一起。
首先这个问题本身就非常有意思，它体现出目前中台的一种混乱的情况，虽然我们谈的都是中台，但是每个人口中的“中台”可能并不是一个事情。当我们谈中台与微服务的区别时，更多谈的是业务中台；当我们谈中台与中间件的区别时，则更倾向于技术中台；当我们谈中台与数据仓库的区别时，更多谈的则是数据中台。
所以这个问题更严谨的表达，应该是“业务中台与微服务”、“技术中台与中间件”、“数据中台与数据仓库”到底有什么区别？
为什么现在大家谈中台的时候，谈的都不一样呢？这一点我在每天回答问题的时候，感受特别明显。每位同学提问的时候，自己所说的“中台”都是特指的概念，是不同限界上下文（Bounded Context）中的概念（从自己的企业和场景出发），在我看来都是不一样的。这也一定程度上可以解释为什么大家谈中台的时候总是谈不清楚，其根本原因可能就是交谈的双方并不在一个上下文下。
我经常比喻，这就像是云早期的时候，大家都在谈云，都觉得自己的才是真的云，但其实大家谈的又都不是一个东西，后来才知道，原来你说的是IaaS，我说的是PaaS，他说的是SaaS……
所以我写《02 | 中台种类》这篇文章，就是希望给你一个全局视角，跳出自己对于中台的理解，我们从整体上看一下到底都有哪些不同种类的中台，先发散再收敛，再看看，中台到底是什么，到底分几类。就跟当初谈论云一样，先厘清概念，避免我们在谈中台的时候都是在不同的“限界上下文”下，感觉说的是一个词，但是其实是完全不同的概念。
那再回到问题上来，“业务中台与微服务”、“技术中台与中间件”、“数据中台与数据仓库”到底有什么区别呢？
这个我在《07 | 中台落地第二步：企业数字化全景规划》 中曾经展开具体聊过，简单来讲就是微服务更多关注技术架构层面上的问题，而业务中台更多关注业务架构层面上企业级复用的问题。业务中台不一定是微服务架构的，采用了微服务架构的也不一定就是中台，对于这部分的详细说明可以回看一下07中的阐述，这里就不赘述了。
这个问题大家问得也比较多。确实，我们看到很多技术中台就是中间件平台包装发展的产物。对于这个问题，说说我自己的理解。
技术中台强调的是更多从业务视角出发，而中间件主要是从技术去重的视角出发。具体来说，技术中台为了让业务更好地使用技术相关能力，对于技术做一些治理、安全、可用性和自助式的包装。如果能通过中台这个概念为驱动力，促使企业的内部技术平台再向业务走出一步，无论是针对用户体验做优化，还是通过产品化，让业务可以自助式（Self-Service）地使用企业技术组件的能力，如果能做到这些或是起到这样的驱动力，我觉得技术中台这个概念才有价值。
总结篇中推荐的《从平台到中台 | Elasticsearch 在蚂蚁金服的实践》，在我看来就是一个非常好的对于中间件平台（Elasticsearch平台）中台化改造的例子，你可以重点看一下。
其实不光是数据仓库，还有同学问到数据中台与大数据平台的区别。这个问题也是大家比较关心的，可能是因为数据中台确实比较火吧。
其实外边有很多文章也在讨论这个问题，在我看来，其中最大的一个区别还是数据中台和传统的数据系统出发点（视角）不一样。
原来的数据平台也好，数据湖也好，数据仓库也好，它们的出发点很多时候有局限性，应该说更是一个支撑性的技术系统，即一定要去考虑我先有什么数据，然后我能干什么，依赖现有数据的质量、现有数据的状况，来做这样一个支撑性的技术平台。
那数据中台呢？回到我们所讲的中台概念，它更多的是从业务出发，然后再来看这些业务，你需要这些数据服务，它有什么价值？至于说这些数据服务所依赖的数据有没有，只要这个服务有价值，那我们就去想办法拿到数据，如果没有能力，我们就去建设技术能力，去完成数据服务的提供。
所以，传统的数据系统（数仓、大数据平台）更多是偏技术侧，拿着数据和技术找场景；而数据中台更多的是偏业务侧，拿着场景去找数据和技术。也就是说，数据中台的思维是业务思维，它从业务问题出发，这也就是为什么业务部门对数据中台会这么欢迎。总结篇中推荐的凯哥的《火热的数据中台对企业的价值是什么？》中对此有详细的展开，对数据中台还有疑惑的话，可以重点看一下这篇。
我非常能理解大家为什么都有这样的困惑，在我看来问题就在于中台这个概念的出现并没有在技术上有任何的创新。我们仔细想想，是不是没有任何一个新的技术是由“中台”这个概念所驱动出来的？而我们大多也习惯了从技术的视角上去看待新的概念，所以自然就被搞晕了，因为各种中台所使用的技术早就在那儿好多年了，感觉没有什么新鲜玩意儿。
我认为这也是理解“中台”概念的一个坎儿，就是能否从技术的视角切换到业务的视角上，用“业务思维”来看待平台。其实这也是理解中台概念的关键所在，也是我认为的技术平台发展的一个大趋势。
为什么这么讲呢？如果我们回头来看整个IT技术的发展历程，从最早的基于具体型号的大型机的开发到操作系统的产生、编译器的产生、编程语言的产生、各种框架和库的产生、各种技术平台的产生，如果仔细思考，这就是一个“平台（抽象）不断向业务推进的过程”。从微观上看，这也是我们写的业务代码占所有代码比例逐渐增加的过程，或者说是一个我们写代码的“业务纯度”不断提高的过程。
由此可见，中台这个概念的产生，其本质就是在技术发展的趋势中，对于技术平台（微服务、中间件、大数据平台）向业务的一个再推动的过程，跟过去几十年发展的趋势一样，自然而然。
而这种演进的推动力，也就是我说的用户（业务）响应力的驱动，说白话就是被业务发展逼的。这里有一个好的例子，就是我在10总结篇中推荐的前阿里交易平台产品经理张巍老师的《七问七答，亲历者讲阿里中台落地》。从这篇文章里，我们可以看到这个驱动力是如何驱动阿里交易平台向业务中台的演进过程的。
最后引用一个同学（Pantheon）的留言。
平台感觉是可以业务无关性，比如搭建一个Hadoop平台，平台的抽象应该更高，提供这样的一个东西，具体怎么用是使用者的事情。中台的概念是业务相关性，中台是需要承载业务的，比如我现在是在教育公司，也有多个业务线，每条业务线都离不开直播上课的概念，那中台可以下沉上课系统和课表系统。不知道这样理解对不对？
我觉得Pantheon同学提的“业务无关性”和“业务相关性”这两个概念还是非常到位的。如果再回头去看问题中的“业务中台与微服务”、“技术中台与中间件”、“数据中台与数据仓库”的区别，都可以看成前者（中台）是业务友好型，或者包装了业务或者对于业务赋能做了改良与治理演进，而后者（平台）则更多是纯技术平台，也就是业务无关性。
也正是由于面向业务这样一个统一的视角，才让这三个之前在不同领域平行发展的概念走到了一起。所以我说中台是平台的下一站，是企业内平台不断扩展自己外延，对自身不断治理演进，走向业务的过程，是从资源整合向更好地对业务赋能演进的过程。
其实这个问题，之前也一直困扰着我，为此我还特地翻阅了好几遍《企业IT架构转型之道》，想看看阿里是如何对于后台系统进行定义的，结果我找了半天也没有找到，甚至连后台这个词在这本书里都没怎么出现过。
从那以后，我一直在找答案，直到从我们中国区CTO徐昊那儿听到了关于Pace-Layer Application Strategy的说法，这个说法给了我很大启发。
我们可以用SOR来理解后台，对应到企业内，就是那些所谓的核心系统，常见的例如ERP、DMS、银行的核心账务系统等。在实际的项目过程中，我们面对的问题也大多是这类系统无法满足前台系统快速业务变化的需求，也就是我们专栏里提到的齿轮匹配的问题。
再之后，有一次和前阿里交易平台产品经理张巍张老师沟通，这次沟通解决了我一个遗留很久的问题，就是为什么之前在看阿里讲中台的书中，没有对于后台的定义和其与中台的区分呢？
张老师的一些回答在总结篇里我推荐的《七问七答，亲历者讲阿里中台落地的实践》那篇文章中都能找到。总结来说，阿里的中台是由平台（例如交易平台）演进过来的，是对于平台治理演进的结果。而在阿里，后台另有所指（与一般企业理解的后台核心系统不太一样），通常指那些辅助企业运行的后台系统，例如人力系统等，与中台并没有什么关系。
这时我就发现，如果把阿里的平台（交易平台）和传统企业的后台（ERP等等），作为同一个概念用Pace-Layer Application Strategy去思考，也是都能说通的，具体的思路我在《03 | 中台定义》中已经展开阐述了。
那到这里，我们其实会有这样一个问题，为什么不同的企业对于后台的定义会有区别呢？其实了解DDD的朋友都应该清楚，一个词，例如“后台”，在不同的上下文里，可能完全代表的不同的东西。而不同的词，例如“后台”和“平台”，在不同的上下文里，可能代表的却是一个概念。
还推荐你看一下我在总结篇中推荐的《阿里的中台战略其实是个伪命题》这篇文章，这篇文章是我看到的少有的从企业架构的层面，分别从业务架构、应用架构和组织架构展开来聊对于中台和后台的概念的。这也让我意识到，不光是不同的企业对于“后台”概念不一样，当我们在谈论业务架构、应用架构、技术架构甚至是组织架构时，“后台”这个概念也是不一样的。
所以最后我也想通了，搞清楚什么是后台其实对于我来解决企业实际的问题，并没有太大的帮助，我们还是陷入到了“什么该是什么”的怪圈里。
不如从“概念到底是什么”跳脱出来，重新回到企业具体的上下文下，回到要解决的问题上，来思考中台这个概念到底能有什么帮助？在企业内，中台与现有系统，中台与平台的关系又是什么？只有在自己企业特定的背景下，我们才能有一个结论，很可能中台也同时是后台，或者也可能是后台的改进版。
说了这么多，其实是想和你分享我理解这个问题的一个心路历程，希望能帮你更好地理解这两个概念。
最后，在这里还想分享一下“笑若海”同学的留言，我觉得Ta的观点对我也非常有启发。
我觉得平台与后台的关系可以借助System of systems的概念来理解。后台对应systems，对应于企业建立的各种职能IT系统（如CRM、ERP、OA、库存管理、采购、供应链、研发、制造等）；平台对应system，将职能IT系统有机集成起来，作为一个整体对前台服务，而不是各个职能系统之间的点到点集成对前台提供服务。
平台层在互联网企业中兴起前已经存在，只是传统企业中IT部门作为辅助职能部门，缺少话语权和主导性，没能上升到企业级高度。而互联网企业敏捷、快速响应用户的企业文化将平台化做到了新的企业级高度。
平台与中台的异同——“中台是企业级能力复用平台”这一概念解释得非常准确，平台化刚被互联网企业喊出时，侧重于IT能力去重，是cost saving；中台则侧重业务能力灵活复用，是value add。
平台化/中台化本质上就是企业IT系统集成的一种设计理念，以高效的价值创造和成本控制为目标。
好了，今天的内容我们先到这里。不知道通过这个答疑篇，对于今天我们讨论的两个问题，你是否有了更多的理解。下一篇我会和你继续探讨另外两个问题。
有任何问题欢迎你继续留言，期待与你一起交流。
评论
评论