03 | 中台定义：当我们谈中台时到底在谈些什么？

作者回复: XuToTo，你好～ 好问题哈，不回答都睡不着觉了…… 首先这两者不在一个抽象层次上，解决的问题也不同，BFF更多是技术架构层面，中台更多是在应用架构层面。 但是，我之前也用BFF来类比过中台，主要为了让技术同学们理解“向前看”这个概念。 不过后来觉得还是有一些不同，主要在于BFF和中台虽然都强调“向前看”，但BFF往往是专注于服务一个前台；而中台的特点就是通过抽象后可以同时服务多个前台。 如果非要类比的话，更像是由GraphQL实现的统一BFF层，不知道你是不是也能理解～

作者回复: MG，你好～ 我在文中也提到了一些，可能没有讲的特别清晰。我举个例子，例如你和我，咱们是两个业务线，都有重复的用户数据，后边有一个用户中台说要整合我们两方的用户信息和用户处理逻辑。 如果对于中台来讲，只要去重就好了，那它会更多考虑你我两边有哪些数据或是功能是重复的，然后拿走，统一在用户中台里管理，只要你我没有重复中台就完成任务了，但是你我的数据被拿走了，再拿回来或是做一些调整可能就费劲了，因为中台关注的只是重复有没有消除，并不关心前台是不是可以继续很好的使用这些被“去重”的数据和功能。 所以我觉得“复用”这个词在去重的前提下，还有更多的“用户视角”，从用户的使用体验出发，关注“可复用”和“易复用”性，也就是你不能光去重把数据和功能拿走，还得提高复用性，让我前台业务还能很好的复用这些数据和功能。 去重向后，复用向前，这个视角的变化我认为也是中台的根本价值。 希望回复能帮你理解，有问题可以继续留言我们再探讨～

作者回复: 业余草，你好~ 这段，尤其是中台化与平台化的区别，困扰了我很久，算是我最近几个月，通过跟各位前辈学习到的一个我认为对我非常有关键的点。 以前我一直在试着找这两者之前的区别，并没与把它们放到一条线上来按照阶段去理解，很高兴也你也能认同~ 有问题可以继续留言，我么继续交流~

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

作者回复: rexzhao，你好～ 好问题哈，我划分前后台其实主要还是从SOR，SOD和SOI出发分析的，如果一个后台就是纯的SOR，那最核心的目标就是管理好自己该管理的企业最核心的数据，功能可能也就是简单的CRUD。 这时候其实也并不需要什么中台赋能，但是像你说的实际中我们看到的一些后台系统，本身除了对于核心数据（人力，财务）的管理外，还有很多的其他功能，例如报表之类的。 那可以理解这时候，这个后台系统已经不是单纯的SOR了，还包含了一些SOI的属性，当然中台作为SOD也可以对其赋能，例如通过数据中台对于财务数据进行二次加工，再返回到财务系统中。 不过总感觉有点奇怪，如果是我，我还是建议将这部分SOI的部分（报表）与SOD的部分（核心财务管理）分离开，这样也减少了对于SOR部分（核心财务管理）的频繁变动，增加其稳定性；又能对于SOI（报表）部分快速变化，不受核心财务模块的限制；中间再通过一层中台的SOD赋能，感觉这样整体架构更顺一些。 不过回到你具体的例子，在不了解上下文的前提下，我这也只能算是纸上谈兵，还得要看具体的情况，只是希望回复对你有所启发，更多从从解决问题的角度出发，活学活用。 感谢你的留言，有问题可以继续留言探讨～

作者回复: hanbing，你好~ 好问题哈，也算是经典问题之一了。 不过我看了一下评论区，其实问到的并不多，正好借这个机会展开聊一聊我的理解。 对于前台和中台的界定，我们在不同的时间尝试过很多种不同的划分方式，但总觉得有局限。例如，如果最简单按照是否重复来划分，重复的放中台，特性的放前台，先不说是否重复就很难掰扯清楚，而且放到时间线上，现在一样的可能以后会不同，现在不同的难免以后也可能会相同，这本身又很难扯清楚，更别提局部重复等情况。 其他的分法，也会有同样的问题，例如按照业务重要性，那怎么判断重要性高低，这些都是问题。 我觉得要想想通这个问题，需要几个关键点： 1. 还是要想清楚，中台建设的愿景是什么（会在下一节04中展开），想好中台自己的方向和产品定位，一个清晰的愿景往往就代表了一个好的边界，这个边界能帮我们判断哪些该做哪些不该做，先做什么，后做什么。 2. 要想清楚，就像本文提到的，中台是企业级的问题，中台与前台的划分边界，其实本质上就是企业内横向的平台类组织和纵向的业务类组织的划分边界，也就是组织责任与利益的划分边界。在最后一篇总结篇里，我也会讲到，中台的核心价值就在于企业对于经济性和灵活性的平衡，而组织的碰撞（像你所描述的部门之间的争执），在我看来反而正是企业在不断追求这种平衡的“动作”，是正常的，也是必须的，我甚至认为中台与前台的边界，也只能靠不断的组织碰撞，才能找到一个最佳的平衡点，而这往往也是针对于这家企业整体经济性和灵活性的最佳平衡点。而我们要做的，就是设计一套机制，例如冲突处理升级机制，来正确的引导这种碰撞向解决问题的方向，而不是相反的方向前进。 3. 用演进的眼光来看待，不要奢望，一次想对，一次分对，一次做对，尊重变化，承认自己的弱小，追求变化响应over追求一次做对。 我现在就是用这几个角度来思考，中台与前台的边界的，具体到Action上，就是：想好愿景，合理引导组织碰撞，演进式思维。 希望我的回复，对你有启发和帮组，有问题欢迎继续留言，我们再做深入探讨~

作者回复: Mr_杨，你好～ 微服务、平台、中台这三个概念确实比较容易混淆，也是大家最关心的问题。 我在本篇中，简单讲了一下我对于平台和中台区别的看法，在07中简单讲了一下微服务和业务中台的区别。 简单讲，从企业架构层面，微服务是技术架构层面的事情，不一定解决的就是业务中台要解决的复用的问题，一个系统为了一些原因例如模块弹性，也可以是微服务架构的。平台和中台都是应用架构层面的事情，中台是平台的发展的下一站，是平台为了更好的赋能前台业务，通过对于自身的不断治理演进，向业务不断靠近，包含更多业务元素业务属性的产物。 这是我到目前的理解，在文中也展开分析和介绍了，希望对你和其他朋友区分开这这几个概念有帮助～

作者回复: Darren，你好~ 又见面了哈，感谢你的肯定，尤其是最后的补充，确实非常关键，我看到也有朋友提问问到了如何在复用的时候处理特性需求。 确实一般都是通过业务抽象，加扩展点（SPI，FPI等机制）来实现的，具体的案例我觉得总结篇里我推荐的滴滴的案例讲的非常好，也非常详细，大家感兴趣可以作为扩展阅读。 感谢留言，有好的想法或是反馈可以继续交流~ 下次见。

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