作者回复: XuToTo，你好～

好问题哈，不回答都睡不着觉了……

首先这两者不在一个抽象层次上，解决的问题也不同，BFF更多是技术架构层面，中台更多是在应用架构层面。

但是，我之前也用BFF来类比过中台，主要为了让技术同学们理解“向前看”这个概念。

不过后来觉得还是有一些不同，主要在于BFF和中台虽然都强调“向前看”，但BFF往往是专注于服务一个前台；而中台的特点就是通过抽象后可以同时服务多个前台。

如果非要类比的话，更像是由GraphQL实现的统一BFF层，不知道你是不是也能理解～

作者回复: MG，你好～

我在文中也提到了一些，可能没有讲的特别清晰。我举个例子，例如你和我，咱们是两个业务线，都有重复的用户数据，后边有一个用户中台说要整合我们两方的用户信息和用户处理逻辑。

如果对于中台来讲，只要去重就好了，那它会更多考虑你我两边有哪些数据或是功能是重复的，然后拿走，统一在用户中台里管理，只要你我没有重复中台就完成任务了，但是你我的数据被拿走了，再拿回来或是做一些调整可能就费劲了，因为中台关注的只是重复有没有消除，并不关心前台是不是可以继续很好的使用这些被“去重”的数据和功能。

所以我觉得“复用”这个词在去重的前提下，还有更多的“用户视角”，从用户的使用体验出发，关注“可复用”和“易复用”性，也就是你不能光去重把数据和功能拿走，还得提高复用性，让我前台业务还能很好的复用这些数据和功能。

去重向后，复用向前，这个视角的变化我认为也是中台的根本价值。

希望回复能帮你理解，有问题可以继续留言我们再探讨～

作者回复: 业余草，你好~ 这段，尤其是中台化与平台化的区别，困扰了我很久，算是我最近几个月，通过跟各位前辈学习到的一个我认为对我非常有关键的点。

以前我一直在试着找这两者之前的区别，并没与把它们放到一条线上来按照阶段去理解，很高兴也你也能认同~

有问题可以继续留言，我么继续交流~

作者回复: vkingnew，你好~ 感谢再次留言：） 概括的很到位哈~

作者回复: rexzhao，你好～

好问题哈，我划分前后台其实主要还是从SOR，SOD和SOI出发分析的，如果一个后台就是纯的SOR，那最核心的目标就是管理好自己该管理的企业最核心的数据，功能可能也就是简单的CRUD。

这时候其实也并不需要什么中台赋能，但是像你说的实际中我们看到的一些后台系统，本身除了对于核心数据（人力，财务）的管理外，还有很多的其他功能，例如报表之类的。

那可以理解这时候，这个后台系统已经不是单纯的SOR了，还包含了一些SOI的属性，当然中台作为SOD也可以对其赋能，例如通过数据中台对于财务数据进行二次加工，再返回到财务系统中。

不过总感觉有点奇怪，如果是我，我还是建议将这部分SOI的部分（报表）与SOD的部分（核心财务管理）分离开，这样也减少了对于SOR部分（核心财务管理）的频繁变动，增加其稳定性；又能对于SOI（报表）部分快速变化，不受核心财务模块的限制；中间再通过一层中台的SOD赋能，感觉这样整体架构更顺一些。

不过回到你具体的例子，在不了解上下文的前提下，我这也只能算是纸上谈兵，还得要看具体的情况，只是希望回复对你有所启发，更多从从解决问题的角度出发，活学活用。

感谢你的留言，有问题可以继续留言探讨～

作者回复: Darren，你好~

又见面了哈，感谢你的肯定，尤其是最后的补充，确实非常关键，我看到也有朋友提问问到了如何在复用的时候处理特性需求。

确实一般都是通过业务抽象，加扩展点（SPI，FPI等机制）来实现的，具体的案例我觉得总结篇里我推荐的滴滴的案例讲的非常好，也非常详细，大家感兴趣可以作为扩展阅读。

感谢留言，有好的想法或是反馈可以继续交流~ 下次见。

作者回复: 未来的未来，你好～

我看到这篇留言里，大家都给出了自己对于中台的理解，都非常棒～ 感谢你的分享，你的这个理解很形象哈～

对于中台，因为其包含的范围太大了，我觉得也很难或是也没必要非要找到一个唯一的理解，在不同的上下文下有不同的解读只要能帮助我们大家对齐共识，朝着同一个方向前进，规避一些问题都是好的。

感谢你的分享，有好的想法还希望能分享出来，我们大家一起学习探讨～

作者回复: xiaosui1209，你好～

就像我文章提到的，技术中台目前还有一些争议，我看到很多的企业在做技术中台和原来的中间件平台本身上也没有太大的区别，所以常被人说只是贴个概念而已……

但是，如果我觉得中台相比与平台的价值，就是其更贴近业务，从业务视角而不是技术视角出发的话，那如果能通过中台这个概念为驱动力，促使企业的内部技术平台再像业务走出一步，无论是针对用户体验做优化，还是通过产品化，让业务可以自助式（Self-Service）地使用企业技术组件的能力，如果能做到这些或是起到这样的驱动力，我觉得在我眼中技术中台这个概念才有价值。

这里有个好例子就是在10总结篇里我推荐的蚂蚁金服搜索中台的案例，可以下载PPT看一下，他们对于技术平台和技术中台的区分原则。

希望回复能帮助到你，感谢关注，有问题继续交流～

作者回复: Mr_杨，你好～

微服务、平台、中台这三个概念确实比较容易混淆，也是大家最关心的问题。

我在本篇中，简单讲了一下我对于平台和中台区别的看法，在07中简单讲了一下微服务和业务中台的区别。

简单讲，从企业架构层面，微服务是技术架构层面的事情，不一定解决的就是业务中台要解决的复用的问题，一个系统为了一些原因例如模块弹性，也可以是微服务架构的。平台和中台都是应用架构层面的事情，中台是平台的发展的下一站，是平台为了更好的赋能前台业务，通过对于自身的不断治理演进，向业务不断靠近，包含更多业务元素业务属性的产物。

这是我到目前的理解，在文中也展开分析和介绍了，希望对你和其他朋友区分开这这几个概念有帮助～

作者回复: 水源，你好~

同意你的观点，原来我也认为只有已经烟囱林立的企业，有了痛点，才会意识到全局的治理，也只有这样的企业才需要建中台。

不过后来跟很多产品型互联网企业聊过之后，发现有一些非常有战略思维，对自己的业务和核心竞争力非常清楚的企业，一开始建第一个产品就是用中台的思路去做的，确实令人钦佩，对团队要求也极高，很容易做Over。

而中台的建设思路，一开始一步到位大而全确实比较难，我一般是分成三步：“系统服务化，服务共享化，企业中台化”，以点及面，找到不同干系方的利益结合点，快速见效，逐步推广，产品化运营。

09的时候聊了一些中台运营的思路，也是在想如何通过有限的资源，平滑的在企业内建设与运营推广中台，同时避开组织与利益等相关敏感的问题。

可以到时候有问题再展开交流~感谢留言分享。

作者回复: 文西，你好～

你觉得这样拿之前的复制一套再改一改会有什么问题么？如果每一个项目都是独立的，这样的方式也是最简单直接有效的方式，那我认为也没有上中台的必要。

如果假设你们的问题是可能之前的代码有bug，一改都得改，那其实把一些组件沉淀下来成为独立的jar就够了，只要做个修改，所有的项目一更新组件版本就可以解决这个问题。

如果假设你的问题是每次再改改的工作是重复的，那也可以看看是不是想办法把这个过程抽象一下，通过一些配置点来实现业务的灵活配置与生成。

而这个平台可能就是你们企业的“中台”，或是其他，都不重要。还是我说的，还是要回到你的问题，去找解决方案。

希望我的回复对你有所帮助～

作者回复: zart，你好~

可以参考一下10总结篇中分享的《从平台到中台 | Elaticsearch 在蚂蚁金服的实践...》，可以简单理解成给平台类产品做一个配置界面，实现自助式（Self-Service）服务，因为很多平台类的产品都是企业内部使用，所以对于界面没有很强的UI要求，大家一般都是一个白页面，加一些配置项，所以叫白屏哈~

作者回复: Gopher，你好～

感谢你的肯定，主要是很高兴看到我的内容确实对你有帮助，期待更多分享～ ：）

作者回复: 唸，你好～

有点像缓存的意思，位置上也很像。

但缓存往往是单纯的解决性能问题，所以一般没有太多业务逻辑的，只是单纯的让数据离用户更近一些，后台是主，缓存是辅，当出现不一致的情况下也往往以后台为SSOT（Single source of truth）。

这一点感觉中台就有些差别，首先中台往往承载了企业的核心业务逻辑，甚至是中台为主，后台为辅，当出现中后台不一致的情况下，也往往以中台为SSOT（这种感觉有点像你用一些支持离线功能的文本编辑器，断网了还可以继续编辑，联网了，内容会以app为准，再同步到后台）。

希望我的解释能帮你更好的搞清楚这两个概念之间的区别和联系，有问题也可以继续留言探讨～

作者回复: hanbing，你好~

好问题哈，也算是经典问题之一了。

不过我看了一下评论区，其实问到的并不多，正好借这个机会展开聊一聊我的理解。

对于前台和中台的界定，我们在不同的时间尝试过很多种不同的划分方式，但总觉得有局限。例如，如果最简单按照是否重复来划分，重复的放中台，特性的放前台，先不说是否重复就很难掰扯清楚，而且放到时间线上，现在一样的可能以后会不同，现在不同的难免以后也可能会相同，这本身又很难扯清楚，更别提局部重复等情况。

其他的分法，也会有同样的问题，例如按照业务重要性，那怎么判断重要性高低，这些都是问题。

我觉得要想想通这个问题，需要几个关键点：
1. 还是要想清楚，中台建设的愿景是什么（会在下一节04中展开），想好中台自己的方向和产品定位，一个清晰的愿景往往就代表了一个好的边界，这个边界能帮我们判断哪些该做哪些不该做，先做什么，后做什么。
2. 要想清楚，就像本文提到的，中台是企业级的问题，中台与前台的划分边界，其实本质上就是企业内横向的平台类组织和纵向的业务类组织的划分边界，也就是组织责任与利益的划分边界。在最后一篇总结篇里，我也会讲到，中台的核心价值就在于企业对于经济性和灵活性的平衡，而组织的碰撞（像你所描述的部门之间的争执），在我看来反而正是企业在不断追求这种平衡的“动作”，是正常的，也是必须的，我甚至认为中台与前台的边界，也只能靠不断的组织碰撞，才能找到一个最佳的平衡点，而这往往也是针对于这家企业整体经济性和灵活性的最佳平衡点。而我们要做的，就是设计一套机制，例如冲突处理升级机制，来正确的引导这种碰撞向解决问题的方向，而不是相反的方向前进。
3. 用演进的眼光来看待，不要奢望，一次想对，一次分对，一次做对，尊重变化，承认自己的弱小，追求变化响应over追求一次做对。

我现在就是用这几个角度来思考，中台与前台的边界的，具体到Action上，就是：想好愿景，合理引导组织碰撞，演进式思维。

希望我的回复，对你有启发和帮组，有问题欢迎继续留言，我们再做深入探讨~

作者回复: 下一道彩虹，你好~

看到你已经读完了，刚回复完10的留言，发现03还有一个。

看下来感觉可能你我的视角比较类似哈，之前我也是你上面提到的这样一个迷茫的状态。也是不断的碰壁和思考，以及跟不同视角的人，不同企业的人交流碰撞，试图探索中台地图的全景。一直在纠结中台到底是什么，长啥样，在不断的挑战各种问题。

不过最终还是向您最后说的，知难行更难，开始做了，做的多了，面对的问题也多了，反而很多原来的知识片段连起来了，也看的透了，心态也平和了，也就没那么迷茫了，走着走着也就走出来了。

很高兴能有一些共鸣和帮助，也很感谢极客时间这个平台也给我了这样一个机会，和更多的人探讨，期待与你再次交流~~

作者回复: 毛毛，你好~

又见面了😁，好问题哈。我的回答就是：

对于个性化需求，能放前台的放到前台，不要什么都往中台放；不能放中台的就做一层抽象，通过配置化和插件化，来支持个性化需求。

当然这又会引出另一个经典的问题，就是前台与中台的边界到底该怎么界定，这块我是通过结合中台的愿景和现状分析来识别和界定的，后续会展开讲到。

而中台内的配置化和插件化、服务化的过程，我这么讲比较干，可以参考10总结篇中滴滴出行中台的构建思路，我觉得在这方面是一个非常好的案例，讲的思路也比较细。

学到后边，有问题继续留言，我们继续沟通交流~