答疑篇（下） | 你问我答，关于中台还有哪些困惑？
该思维导图由 AI 生成，仅供参考
中台与前台的边界如何界定？
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
本文围绕中台概念展开讨论，强调了对中台建设愿景的明确和产品定位的重要性。作者提出了演进式思维和合理引导组织碰撞的重要性，并讨论了中台是否在炒概念的问题。文章强调了对中台概念的深入思考和开放态度，以及对新技术的审慎态度和主动思考能力。同时，作者引用了Cheng同学的话，强调以用户为中心，从战略入手，用科学有效的方法沉淀企业级能力，方得中台。整体而言，本文强调了对中台概念的深入思考和开放态度，以及对新技术的审慎态度和主动思考能力。
《说透中台》，新⼈⾸单¥29
全部留言(22)
- 最新
- 精选
- Single感谢王健老师的课程，我这边正在参与一个数据中台项目的开发，中台一期结尾了，我们这边做的是单纯的数据中台，所以存在很多想象不到的问题： 1.现在中台沦落成了为各个业务系统找系统bug的系统。 2.中台构建在阿里的dataphin 产品（没有元数据监控），导致各种上云问题。 3.中台的交付是和业务系统数据保持一致，导致交付很难受。 4.业务系统都不爱用中台，用起来一堆问题 马上开始二期的中台建设了，还是不建立业务中台，感觉二期开发和交付压力会特别大。
作者回复: Single，你好~ 首先非常感谢你分享自己的实际项目的经验和经历，也能体会和理解到你碰到的问题和困难。 对于这些问题，我在没有上下文的前台下很难给出什么有建设性的意见。但我总觉得可能数据中台如果作为一个独立的产品，其产品定位和边界是不太清晰的，产品的稳定性和SLA也没有做的很完备，导致前台业务都不太爱用中台，因为会导致业务系统出现连带问题。 所以是不是可以再二期的中台建设开始时，按照我分享的内容，对于中台产品的产品愿景，产品边界，产品的用户运营体系，产品的验证体系，产品的SLA做一些更细粒度的规划，会对产品的演进和保护有帮助呢？ 只是抛砖引玉，希望有所启发，没有更多的上下文，不好妄下定论：）
2019-11-2827 
Expif老师好，咨询一个问题，我们公司也打算进行中台的搭建。 背景：目前分为前端系统和后端系统，前端系统包含所有的APP，小程序，H5，公众号及对应的后台系统(做业务聚合、为App等提供数据组装、展示等功能)；后端系统主要包含应用系统，比如客户系统，核算系统，产品系统，订单系统等；两个部门在20年都制定了中台建设计划。目前是前端的业务变化较快，前端的后台系统也承担了部分业务流程的功能。 因为中台是定义为企业级的可复用的，所以对于前后端都要建中台您有什么建议吗，是非要放到一个部门建立还是两个部分公共建设，因为是跨部门可能就会涉及到一些利益相关冲突，所以想看下您的建议，谢谢。作者回复: j7py9，你好~ 很好的问题哈，目前我看到的很多企业要不就是前端后端都建中台，要不就是各个BU，BG之间都建中台，但这也不一定就是错的。 关键点还是在于这些中台的“产品定位”到底是不是重合的，如果说中台是企业级能力复用平台，那也就是看各个中台承载的能力到底是不是重合的。 回到你这个案例，从你的表述来看，后端的中台更像是常见的构建企业级业务中台的案例。而前端也有相应的后台系统，有点类似BFF层，做数据的聚合和一些跨中心的业务流程。那到底前台该不该有自己的中台呢？ 我觉得还得具体分析这些所谓的数据的聚合和跨中心的业务流程只是属于前端展示的范畴，还是背后其实隐含着企业的核心业务，只不过被理解成了前端展示才需要的一些概念。 如果是前者，那前端对于BFF封装一个小中台，做跨APP的BFF能力复用也是可以的。但如果是后者，则需要将这些隐含的业务概念和业务流程识别出来，沉淀到后端的中台层中。 所以我的观点是，前端和后端都有一些自己的后台或是中台，其实也是可以的。主要看两个中台承载的能力是什么？是否存在冲突和重复。如果存在的话，还是需要对两个中台从企业的层面进行清晰的产品定位，才能确定这些冲突或是重复的能力归属。如果不扯清楚，肯定少不了彼此之间的组织和利益冲突。
2019-11-226
少盐理论化，概念化，抽象的东西，初级的计算机工程师目前很难理解，融会贯通和应用作者回复: 绿茶，你好~ 确实有一点抽象，因为中台这个概念本身就不是一个单纯的技术问题，更像是企业架构层面的问题。而这个层面的问题确实也会偏抽象。 不过我也是一个十多年的“老开发”，曾经沉迷代码无法自拔，不过随着打怪升级，肯定会从开发到架构到高级架构到企业架构，这样一个打怪升级的过程，相信很多人或主动或被动也是绕不开的。 希望这个系列能有一些启发，或是种一一个种子，如果有一天碰到了类似的问题，可以回来看看是否有帮助哈~
2020-04-0623
momo老师，想问下，你觉得什么是中台思维？如何从现有业务发掘中台？作者回复: momo，你好~ 我觉得在平台思维的基础上，中台思维就是“业务驱动”，更多从如何为业务更好的赋能的角度上来思考平台的建设，而不只是从技术“去重”的视角上出发。 如何从现有的业务发掘中台，我在前边介绍的企业架构梳理，D4模型，服务蓝图梳理，领域分析（DDD），跨领域共性分析（包括数据、流程、功能、模式），都是我们现在实施的从多业务线发掘中台所采用的方法，可以参考一下~
2019-12-102
Demon.Lee一刷结束，感恩，我还会回来的~作者回复: Demon.Lee，你好~ 感谢你的支持，等你回来~：）
2019-11-241- 钱勇受益匪浅，正好在考虑公司的中台建设，期待王老师的后续专栏
作者回复: 钱勇，你好~ 感谢支持，有新的感悟一定后续分享，多谢多谢~
2019-11-181 - afx因为我是测试工程师，我比较关心，中台在测试平台上的应用有哪些？老师能讲讲吗？给个思路
作者回复: afx你好～ 因为中台这波浪潮主要是偏向业务侧的，而测试领域偏技术侧，所以谈到的比较少。不过测试平台也是属于技术平台的范畴，和技术中台的思路应该也是相通的，即试图更多站在业务赋能的视角而不只是技术平台统一的视角来看待平台的建设。 举个例子，我之前看到过很多企业的测试平台，并不考虑测试场景的设计、测试用例的设计、测试策略的设计、测试方案的设计，只是将关注点放到了测试平台的技术方案打造上。平台效果演示非常酷炫，但是业务使用不起来，要不太复杂，要不不好用，不满足自己的要求。针对这些问题测试平台也不管，认为这应该是业务团队自己要去解决的。 如果中台概念能让我们测试平台跨出技术的边界，就像数据中台不只考虑大数据技术，还要考虑数据资产管理，数据服务一样。我们测试中台还会涉及到上面说的测试策略、测试场景、测试方案的设计上，贴近业务，融入业务，那我认为才算是完成了测试平台的中台化改造。 希望对你有所启发，有问题继续交流～
2019-11-121 
Dear。Done，2019-11-29。 接下来，周末整理图谱，以及学习一下课程里推荐的那些文章。作者回复: Dear。，你好~ 赞哈，整理的图谱如果可以的化，也可以留言分享给其他同学哈，希望课程对你有所启发和帮助，感谢感谢~
2019-11-29
旅途中de陌生人在替客户规划中台，太难作者回复: 你好，碰到同行了哈～ 其中辛苦大家不言而喻了，一起努力哈～
2019-11-12- afx提问: 公司要搞中台了，最近了解了一下中台，想问问，问题一:中台在软件测试中的运用有哪些？问题二:测试人员怎么面对公司的中台进行测试？
作者回复: afx，你好～ 又见面了哈，关于第一个问题，我在你的另一个问题里已经展开回复了，这里对于第二个问题我谈谈想法。 中台怎么测试，说简单也简单说难也难。怎么说呢，如果说简单，是从功能测试角度来看的，中台本身也是个产品，也有产品目标和具体的需求，研发怎么也需要按照需求开发自测，所以只要需求说明验证即可，和测其他的产品一样，只不过可能需要了解一些技术层面的基本知识，例如API，鉴权之类的就可以了，也不需要深入到技术细节。 那为什么说难也难呢？因为我认为测试应该不只测试实现是否按照需求实现的，需要测试的是业务价值本身，要有业务的视角。但对于中台这样一个偏中后端的系统或是平台，了解和验证其业务价值就会比较困难。这不光是测试的难点，可以说是整个中台建设的难点，前面已经提到了。 例如在TW，因为我们注重质量和价值交付，所以我们的QA（不叫测试），甚至需要比研发甚至产品更了解业务，那当面对中台这样的平台型产品，需要的各个方面的能力的要求也就更高。不光要了解单个产品的业务，还要了解产品线以及多条产品线的业务，对人的要求极高，不过反过来想对人的提高也非常有帮助。 所以总结一下，就是从测试本身并没有什么变化，但是需要了解的业务范围会比原来大一个数量级，对测试人员的业务能力也要求更高。 希望能回答到你的问题^_^
2019-11-12
