作者回复: 刘丹，你好~

首先感谢支持。首先案例的问题，因为我实际参与的项目更多是帮助客户来规划与落地中台，但是客户的信息和案例我需要严格保密，所以有很多案例，但是无奈无法分享。

所以我才想办法虚构了一个地产行业的极客地产的虚拟案例，来表达我一些观点，不过因为案例是虚构的，展开会比较理想，没法把问题都体现出来。

这也确实是我写这个专栏的一个难点，又不好讲具体实际的案例，又想要讲明白讲落地。

不过我在想后续能不能把一个虚拟的案例打磨的丰满一些，把之前碰到的一些问题和关键点都揉进去，虽然虚构但仍然可以还原一个中台建设的全貌和关键细节，如果真的打磨出这么一个案例，也会第一时间分享给大家。

最有一个关于系统架构师底层技术的资料，其实市面上有很多，尤其是数据中台相关的大数据技术，或是业务中台经常涉及的微服务、分布式架构的书。

但我想你问这个问题肯定是觉得中台和这些应该不一样，想了解一些中台相关的特别的技术架构，这点我理解其实中台（例如数据中台）在技术层面本质上和技术平台（例如大数据平台）本身就无法分的很清楚，只是在业务侧的边界有一些区别，中台包含更多的业务属性，但是在很多技术也是重合的。

所以结合技术相关的资料和书（例如大数据技术），再结合一些产品化的书，在技术架构的基础之上，继续超越技术，关注中台产品，例如数据中台的愿景，定位，用户，运营这些……这种资料的组合，可能对于理解中台会更有帮助。

作者回复: delishi，你好~

不好意思，回复的有点晚：）

我仔细看了一下您的留言，关于Gartner分析师的观点我也像你一样，大面上是比较认同的。互联网很多的场景比较适合业务中台，是因为主要关注在业务的横向扩展上，例如滴滴的出行模式和阿里的交易模式的横向（多产品线，多地区）扩展，而像您说的银行不同业务条线之间的共性确实不像互联网企业这么明显。

但也向你说的，不明显不代表没有，可能就需要很强的分析与抽象能力，比如（不算是银行领域专家，拍脑袋）很多业务表面上看似不同，是不是其本质上就是储蓄模式、信贷模式……这几种能？感觉还是有可能的，因为到最终的核心也都是记账（高度抽象）。

还有很多的银行，现在都在跟欧洲那边的开放银行的概念，是不是我可以将银行的核心能力和模式抽象沉淀到中台（叫不叫中台无所谓），对外对接行业，做场景，做生态呢？

所以，如果是我，可能也不会一巴掌拍死，还是按照我说的方法，从愿景，从问题出发，从一个场景一个问题开始，看看到底中台或是中台的理念适不适合，然后在慢慢演进，或许还真能走出一条银行领域自己的中台之路呢：）

所以正好也匹配你从小处着手，找一个切入点，在慢慢扩展到其他业务条线的方式。

最后其实也没有什么更好的建议，还是那句，不要为了建中台而建中台，先想好，如果没有中台，我们有哪些问题处理不了？这些问题有没有其他更好的方式，为什么中台是最好的解决方案？想清楚了这些问题，再按照你的思路展开具体实施就可以了。

希望我的回复对你有些帮助，有问题可以随时留言，我们继续探讨~ 不好意思回复晚了，久等了……

作者回复: Geek_fa647d，你好~ 为什么呢？是我介绍的方式或是思路与你之前的方法和思路完全不在一个方向么？那能不能讲讲咱们这边是如何来设计中台系统的，我们一起纷纷，差别到底在哪？没准有一些好的方式我也可以学习一下，再补充到我的方案里呢~ 期待你的留言~ 感谢支持。

作者回复: vkingnew，你好~

感谢耐心看到最后，你说的没错哈，因为中台涉及的是到达了企业架构层面，展开太大了，所以我在构思专栏的时候主要是想快速来一个从古到今，从面到里，从0到1的中台建设全景，从内容上来看也更多的偏重企业架构（EA）和产品设计研发的端到端过程，会碰到的问题以及如何应对等，给大家快速建立一个对于概念的理解以及对于建设全过程的全景图。

但是有一点需要说明一下，就是这个专栏不是只针对数据中台，而是讲的再抽象一层的大的中台概念，属于企业架构层面。而无论数据中台，业务中台只是中台范畴内的两种不同的类型而已，属于应用架构层面。

确实现在外边文章和书籍，针对技术人员关注的点比较多，但是从企业架构师以及产品经理的视角的解读比价少，所以内容在这方面做了一些偏重，算是一个定位，也有你提到的一些问题和不足，虚心接受，再次感谢花费宝贵时间学习、交流和反馈建议~

如果有问题，还可以继续留言，我能解答的一定解答，解答不了的就找人帮忙解答，我们这么多人学习也一定有很多比我厉害的专家，尤其是在数据中台方面，也希望听到大家的反馈和意见，互相学习，互通有无~

作者回复: 下一道彩虹，你好~ 总结的好精辟哈，感觉我那么多字白打了……[掩面] 你说的对，知易行难，知行合一，开始操练起来吧，很多问题都是真正做的时候才会碰到，也是真正碰到才能理解。再次感谢支持，有问题和反馈还希望继续留言交流~~

作者回复: atom992，你好~ 感谢支持，其实中台本身就算是一类平台型项目或是产品，只不过多了一些业务元素或是上下文，更拥抱业务而已。但是底层的方法和工具都是相通的~

作者回复: IT民工大叔，你好～ 书多不一定都看哈，捡感兴趣的书或领域看就成了：）

作者回复: David Mao，你好～

首先感谢你的肯定～ 关于你的问题，坦白来讲，数据中台我实际参与的并不是特别多，更多的是在整体规划（前两个D，数据中台只是里边的一个规划点而已）和围绕业务中台展开具体设计和实施（后两个D）。

但是对于数据中台我也一直保持关注，这方面以我浅显的认识，我认为难点并不在于大数据技术平台的搭建（虽然也很重要），而在于从真正的业务场景出发（而不是数据和技术出发），对于企业的数字资产的识别与整理，以及企业级数据指标的统一，也就是阿里提的OneData。

这块我就不班门弄斧了，以免误人子弟，这个领域推荐我司的凯哥，他在这方面有非常深入的理解，在总结篇里也推荐了他的两篇讲数据中台的文章。其中也详细分析了数据中台和数仓大数据区别这种大家都关心的问题。或是了解一下阿里的Dataphin（产品介绍的几个视频也讲到了类似的概念），希望这些信息对你有帮助～

感谢你的留言，希望我的推荐对你有帮助～

作者回复: 小P，你好～

首先非常感谢你的留言，洋洋洒洒这么多字，能感受到你的肯定，也很高兴看到我的一些思考对你的一点点启发。

我经常说，看书就像是照镜子，其实书一直在那里，没变… 但是不同的人，甚至是同一个人不同的阶段看，都会有不一样的感悟，所以我们看时其实就像照镜子一样，镜子没变，变的是我们自己。

所以你能感悟到这么多，主要也是因为自己本身已经意识到了很多的点，我的专栏不过是帮你又明确和确认了一些，系统化的整理了一下，最根本还是你自己的功劳哈～

你的留言中，我看到了最难的是一点就是从问题出发，把新概念当成新的工具，但最终眼里还是始终看的问题，“让数据透明化资产化”。

所以这样就不会颠倒了问题和方案，也是我一直在提的要了解和运用好中台，但不要为了中台而中台的一个观点。

最后再次感谢你的留言，对我也是一个很大的肯定和反馈，谢谢～

作者回复: 大壮哥，你好～ 很高兴看到讲的东西能对应到你们现在的问题，更希望能提供一些启发，帮助你能解决这些问题。 中台的建设确实困难重重，需要解决一个接一个到问题，但阳光总在风雨后，相信一定也能克服困难，有一个圆满的结果。感谢留言分享，期待后续的交流～

作者回复: Dareen 聂微东，你好～

感谢留言，首先很高兴对你还是有些帮助～

期待你的总结和笔记，整理完也可以发到这里，我们一起来学习一下，有反馈也可以探讨。

评论区确实藏龙卧虎，很多问题都很在点上，一些我的回复也算是对于内容的补充（我感觉我写回复的字数应该已经快超过正文了……）。很多问题也被重复问到，也能体现出大家都关心的内容和问题点。

我也建议其他同学有时间的话，不要忽略了评论区的内容～可能错失一些正好是你需要的内容或是你正关心的问题～

最后，还是得感谢一下你的支持和信任以及认可，有问题随时留言，期待你的分享～

作者回复: 高老猫，你好~ 怎么理解这里的消息和中间件呢？按照我的理解的消息中间件，就算是做了隐喻，也感觉怪怪的，能不能展开说一下你的思路，我们再继续深入的探讨一下？：）

作者回复: 天秤vs永恒，你好~

很有可能哈，如果这些服务真的能帮助我们实现企业某些能力的复用，那我觉得就算是了。

不过还得看是什么具体的“中台”，如果是技术的话，我觉得还得看接入服务的用户体验，这里你提到了“申请”，没有具体的上下文，不知道作为用户接入服务的体验是如何？我认为中台不光是接入，还得体验好。

如果是业务中台呢，那只是一些微服务，增删改查，复用个用户数据，我觉得还算是中台的初级阶段。对于业务抽象分层，并对高级别的业务模式通过配置化和插件化的复用，我觉得才能真正发挥出业务中台的作用。

数据中台，如果只是对于数据工具的复用，没有做到对于数据的治理和资产化管理，以及对于使用数据的体验优化，例如自助式的中台能力使用，也只能算是初级的能力复用。

所以中台概念比较宽泛，只是代表一种趋势，是与不是其实并不重要，能通过这个趋势驱动我们不断跨越边界，持续改进才是好的~

希望对你有帮助~

作者回复: elephant，你好~ 也谢谢你的支持和关注，希望对你有所启发帮助，保持交流~

作者回复: 祥敏，你好~

感谢你的支持，为你点赞~就像你说的，学习一个知识最好的方式就是实践，在实践中不断反思沉淀，必有所收获，正所谓知行合一。

不过有问题可以欢迎提出来，咱们一起探讨，可能也会少走一些弯路，我说的不一定就是对的，但至少能给一些启发和不用的角度，也能有所帮助不是~ ：）

作者回复: 多谢鼓励和肯定，差的还远，还在不断学习，有好的想法一定还会持续输出，多谢多谢🙏