阿神 置顶2019-10-10我目前在一个化妆品企业，产品在各大电商平台销售，同时也有自建电商平台（app），我们在18年底开始中台化建设，走了一些弯路，这里分享下经验。在中台化改造之前，我们已经搭建了微服务开发平台，并在团队引入了领域驱动设计的理念。然后我们期望设计一套中台，再来改造遗留系统，但我们设计中台时对中台理解不够，对一些企业内部的业务系统，比如OMS也进行中台服务的拆解，这样导致设计的一些中台服务就这个OMS使用，能力上是不需要复用的，也就是并没有多个产品线来使用（未来也不会），辛亏这些设计还没有进入开发阶段，及时刹车，调整设计方案，把不需要服用的功能合并，实际上OMS本身就是一个中台应用，根本不需要拆细了；同时我们重点对于多个前台应用的能力进行分析和服务拆分（利用DDD方法拆分），最终我们的中台服务是满足多套前台应用使用的。所以我对中台是企业级能力复用这个很有感触，同时中台一定是考虑服务前台应用的，因为前台应用才可能有多套产品线，企业内部的业务系统一般是不需要基于现有的中台来搭建，因为这类系统就一个，本身属于一个中台应用，能够被前台应用来使用。当前企业内部的业务系统是可以基于技术中台来搭建，这个是没问题的，技术中台会提供开发平台，登录服务，短信服务等一些业务无关的组件，不论是前台应用还是内部业务系统都能使用。展开 1 19
2019-09-30中台跟平台到底什么区别，这个概念感觉很模糊作者回复: 槿，你好～
这是个好问题，这两个概念也确实模糊，很多企业做的中台和之前做平台也没什么两样。但我觉得还是有些区别的，我先引用阿里行癫在一次采访中对于这个问题的解释：
行癫：原来阿里是个平台，我也做过两年中台，我一直在琢磨中台跟平台到底有什么区别。像阿里巴巴、淘宝、天猫这种平台只要搭好了，客户直接开店就可以了，不需要关心任何事情，但我觉得中台不一样，中台自己单独的产品不能直接产生价值、不能直接对外服务，一定要变成别人产品的一部分，让别人的产品提供更好的服务，这是我理解的中台。
当然这个解释也有很多的背景和上下文，就是阿里刚提出的“被集成”。
但我觉得这个解释也能一定程度上区分出这两个概念，这也是为什么我觉得平台更多是去重，是整合，是你不要做了，来我这儿做；而中台更多是复用，是赋能，是被集成，是你还是自己做吧，但我有这些能力能帮到你，你要不试试？
也正是因为视角的变化，为了争取更多的“用户”，更好的为前台服务，也让中台更多从前台出发，从业务出发，也自然会包含更多的业务属性和业务封装。
所以我认为平台和中台的区别不再表现形式上，而主要在视角的区别上，视角的不同也会导致边界的不同，走上完全不同的道路。
不知道说的是否清楚，是否能解答你心中的疑惑。如果还有问题，欢迎继续留言，我们继续探讨～ 1 13
2019-09-26我以为我做的就是中台，看完感觉不是作者回复: 每天晒白牙，你好~ 是不是中台不重要哈，解决没解决问题才重要，在我看来中台解决的是企业级能力复用的问题，但是反过来不一定成立，企业级的能力复用也不一定只能通过平台化或是中台化来解决，可能有更简单的方式，例如集成在某些情况下可能是更有效率的解决方式，活学活用：）
3
2019-10-11老师，您好，是否可以提供一些每个阶段的成果产出物示例，这样方便我们理解每一个阶段具体要做的事情，谢谢！ 2
2019-09-29王健老师好。在本节中，我有两个问题想与老师请教一下。一、本节标题“企业数字化全景规划” 与本节总结前的一个主题“平台型企业架构设计”是什么关系？个人感觉是说的同一过程，但又好像后者更具体一些，是前者的一个显相化裁剪落地版本。还请老师点拨点拨。二、“平台型企来架构设计”过程的第5步和第7步的看起来很相似，其区别和联系又是什么呢？作者回复: 下一道彩虹，你好~
感谢评论留言，您看的很细哈。针对问题我试着回复一下：
一、可以做个类比，清楚一些。如果说TOGAF是“企业架构的设计方法”（EA）的话；那D4就是我们裁剪改良版的“平台型企业架构设计方法”（PBEA）。而本节，既“企业数字化全景规划”主要是在讲第二个D，Define的过程，也就是基于上一节收集的信息做一次收敛，形成业务架构、应用架构、技术架构…的过程。
二、如果您指的第五步和第七部就是“IT资产盘点”和“企业架构设计”的话，那第五步更多调研的是现状（As-Is）；而第七部更多设计的是蓝图（To-Be），需要结合前六步的所有信息，而IT现状只是参考信息的一个方面而已。
希望回复对您理解有帮助，如果我理解错了问题，或是还是没有讲清楚，您可以继续留言，我们再深入探讨~ 2
2019-10-14你好，文中提到微服务是由单一应用划分成很多小服务，而我们常见的一个应用能提供多个微服务（）请问微服务到底是指一个应用，还是应用里面的某个服务？作者回复: Jeremy King，你好～ 一般一个微服务指的是应用中的某个服务，是一系列API（广义）的集合，多个应用也可以share一个或多个服务～
1 1
2020-02-05微服务从技术上看无非是将组件间的依赖点从“编译时”推后到了“运行时”而已——这个诠释，很经典。
回想自己做的事情，核心就是一些基础的微服务，具体他们的价值几何，完全不是我来决定的，看调用方是谁？看调用量多少？看服务了多少订单？只要涉及商祥、结算以及覆盖了足够多的订单类型，那对应的微服务就是有价值的，否则就无关紧要了，从这一点出发，我们确实有些像中台了，我们需要被集成，需要被各个流量入口复用，我们的价值由集成者决定。- 2019-12-27SaaS 抽象层次高，更靠近业务，但对于业务的标准化要求高，灵活度小。业务中台正好反之，抽象层次较 SaaS 低，介于 PaaS 和 SaaS 之间（所以很多企业管业务中台叫 ApplicationPaaS，或是 BussinessPaaS），离业务较 SaaS 远一些，但更灵活。这也回答了很多人困扰的业务中台与 SaaS 的区别问题。
这部分是不是说反了？
SAAS应该是业务的具体实现，更加细节具体一些；而中台各业务线通用的部分，更加抽象，具体实现交给应用去组合和编排。展开 
2019-11-20服务的技术实现其实很简单，难的是这个思想的运用，业务的隔离程度有多深，我觉得极端点的就是通过数据库是否独立来判断。- 2019-11-05应该是中台更加抽象吧，面向所有不同的业务线的抽象，而SAAS结合具体业务的具体实现？
2019-10-301.中台解决企业级能力复，企业不应该为了能力复用而去建设中台。2.DDD只是微服务实现和设计的一种方法，由于DDD的要求比较高，我在经历的项目上都不建议客户去使用，如果客户能力比较强，可以尝试部分使用。
2019-10-11一看完之后最直观的感受中台不是解决技术问题，而是解决业务问题，抽取企业不同业务线的共同点，形成中台，为业务的快速推进服务
2019-10-11感觉做一个好的中台离不开好的项目管理作者回复: 守候，你好~
说的是，我看了一些回复，也发现，我讲的更多是从项目管理，产品管理，企业架构的层面来谈中台，可能是因为我决定中台就应该落在这个层面上。
而且不光是项目管理，甚至需要跳出项目内，从更高一个维度，比如项目间协调，产品间协调的角度来看待，如果只是从技术出发，很容易陷入到管理和组织旋涡里。
感谢你的分享，随时继续探讨~
2019-10-10老师好，不明白单个中台的边界如何界定，是否具有独立服务的能力，和其他中台又是什么关系？
2019-10-09DDD（领域驱动设计）这个之前想学习过，老师这么说了，看来很重要，似乎是构建中台的一个重要思维设计工具。打算去了解一下。编辑回复: 极客时间马上会上线一个DDD的专栏
1
2019-10-08中台可以说是提供服务的，微服务只是使用服务的一个成员而已。文章太多术语不太懂，感觉 DDD 是自身的短板
2019-10-07感觉中台更像是为前台提供服务的 "平台"
2019-09-29王健老师好，现在两个词最火，一个是中台，一个是数字化，在很多文章中，两者都是混到一起说，那如何描述这两者之间的关系？
2019-09-26路线图有高清的没作者回复: jiaoenzhao，你好~
路线图虽然做了脱敏处理，但是还是怕会有一些问题，所以故意适当做了一些模糊化处理，主要是为了展示一个完整的思路，示意一下~ 感谢理解哈~