05 | D4模型：中台规划建设方法论概述

Sep 25, 2019

05 | D4模型：中台规划建设方法论概述-极客时间



下载APP





关闭

讲堂部落提薪训练营云原生训练营架构实战营企业版极客商城兑换中心 App下载浏览器插件

渠道合作

推荐作者

05 | D4模型：中台规划建设方法论概述

2019-09-25 王健来自北京

《说透中台》

课程介绍



讲述：王健

时长16:17大小14.91M



你好，我是王健。
上一讲，给你分享了中台建设前需要考虑的四个问题。考虑清楚这些问题能够让我们在真正开始建设中台时，提前规避一些风险。
好，现在假设这些问题我们都已经想清楚了，那中台到底该如何落地呢？
在过去两年多参与中台的建设过程中，我也确实踩了不少的坑，走了不少弯路。下面就用第二部分剩下的几篇文章，为你介绍一下，目前我们在实践中摸索整理出来的中台落地思路，希望对你有帮助和启发。
首先说明一下，就像前面文章提到过的，目前市面上的中台“种类繁多”。不同种类的中台，它们的建设方法可能完全不同，但是肯定有一些思路和方法是通用的。后续部分我将以一个业务中台的构建过程为样本，为你介绍中台落地的实践，会遇到哪些困难，梳理出一些思路和方法。
一个典型业务中台建设的开始阶段为了让你体会到中台建设的一些困难和问题，我们还用极客地产的案例来模拟一个中台建设从 0 到 1 的启动过程。
小王接到了老板的委托之后，准备开始极客地产业务中台的建设。
小王是技术和架构师出身，在公司曾主导过几个大系统的分布式服务化改造，对分布式架构设计和实施都非常有经验，对互联网公司在谈到中台时经常提的领域驱动建模啊，微服务技术架构啊，也是轻车熟路。当然了，这也是领导将这个重任交给小王的原因。
说干就干，一开始，小王还像以往一样，准备从业务需求梳理入手。但是第一个问题就把小王给难住了：到底该梳理哪些业务呢？
之前小王处理的都是单产品级别的，只要抓到这个系统的用户或是业务专家，搞清楚对于产品的需求，不管是一个多复杂的产品，都还是有一个边界的。而做中台，往往涉及到企业所有的业务线，那是不是该把企业所有的业务都梳理一遍呢？如果这么做，基本上就意味着需要调动整个公司的资源，那各条业务线为什么会配合呢？就算是业务会积极配合，那还有后续的问题，小王到底要梳理到什么粒度呢？
面对各种问题，小王开始觉得有些不太对劲。从技术和架构上来看，做中台和之前做一个分布式系统分明没有什么差别，但是面对的情况和范围以及复杂度，却完全不是一个级别的。一时间都不知道从哪里入手合适。
此时的小王，总感觉有什么不一样，但又说不出来哪里不太对，陷入了深深的焦虑之中。
做一个业务中台和做一个分布式系统到底有什么不同？不瞒你说，这个小王就是我 2017 年刚开始做中台规划与落地时的真实写照，当然案例不是这个虚拟的案例，但是当时碰到的真实情况和问题和案例里面的很类似。
而且当时我碰到的问题比这些还要多得多，例如你就算梳理完所有的业务，规划出一个中台，但你怎么证明你这个中台就是对的呢？就是最好的呢？回想那段时间确实是一段比较痛苦的经历，每天脑子里都被这些问题缠绕。而所有的问题最终都可以归纳成一个简单的问题：做一个业务中台和做一个分布式系统到底有什么不同？
不废话，还是直接给答案。经过了很长时间的思考和复盘，我和我的小伙伴发现了问题的关键点，其实非常简单，前面已经反复重复过很多遍了，就是范围不同，如果再说得明确一些，还是那三字：企业级。
为什么我反复强调这三个字呢，我知道很多人刚一开始看到这个三字的时候并没有什么感觉，但是这三个字确实是我们踩了无数坑才提炼出来的，包含了很多问题的答案。
现在回过头来看，做一个中台，当时我们使用的工具和方法以及思路其实都没有太大的问题，只是把中台这件事情的范围和难度想小了，想简单了。
相信很多人，无论是中台产品经理还是架构师，都跟我当时一样，做得更多的是系统级别或是单条业务级别的系统建设或改造。但是当我们在做中台的时候，我们处理的完全是高一个级别和范围的事情，已经跳出单个产品、单条业务线，涉及到企业的层面。
你可能会问，只是范围大了一些，又会有多大的区别呢，我只能说区别大了。
首先，如果是企业级的问题，你要解决的就是实现企业目标这个级别的问题。这样的问题本身就是模糊的，一般也都是战略级别的，所以不能只从现状的业务入手，要从企业的战略分析开始，充分考虑未来架构规划对于战略的影响。
其次，如果是企业级的问题，你将面对的就是企业的组织问题。组织问题有时候要比业务问题难处理得多得多，因为涉及到企业利益的再分配。一旦碰到组织和利益的问题，就会有各种被我称之为“为什么系列”的问题，比如最常碰到的就是为什么要配合中台？我为什么要把数据给中台？我为什么要用中台？等等类似的问题。
还有，如果是企业级的问题，回归到业务上，也和过去做系统完全不同。你面对的将是企业的业务全貌，甚至是那些未来才会出现的，现在还不知道长什么样子的潜在的创新业务。
除此之外，还会有无数类似的困难，是我们原来做一个系统和产品所不曾面对的。所以我才把“企业级”这三个字放到了我对于中台的定义里。时刻提醒自己，我在做的事情和原来做一个系统一个产品，不是一个级别的事情，完全是另外一个物种。
想清楚企业级这个问题，对我还有一个非常大非常大的启发，就是我终于想清楚了之前感觉的那些不对劲的地方到底在哪？实际上，我一直在用一个系统级产品和架构的方式，试图来解决一个企业级产品和架构的问题。现在再回头看，碰到那些问题和困难也就不奇怪了。
所以，整件事情的性质就变了，虽然我们可能还是会做业务梳理，会做微服务，会用到领域建模等等这些相同的手段，但我们要清楚，当我们在做中台的时候，我们本质上是在做一个企业级的架构，一个融入了平台新要素的企业级架构，我称之为：面向用户与创新的平台型企业架构。
那问题又来了，中台和传统 EA 有什么不同？在想明白了中台这件事情本质上就是个企业级架构的问题后，其实我并没有想象中那么兴奋，反而非常失落，这又是为什么呢？
了解企业架构（Enterprise Architecture）的朋友肯定知道，这也不是什么新的概念， 像 TOGAF 这种成熟的 EA 框架已经有 20 多年的历史了，我们经常见到的例如业务架构、应用架构、技术架构、数据架构甚至是组织架构都是包含在 EA 的完整体系内的。
我当时那种感觉怎么形容呢？就像是以为自己发现了一个新的物种，结果发现根本不是什么新东西，早已被记录在册，印在了每一本百科全书当中。那种失落感可想而知。
还好，故事后来又有了新的转机。经过不断的探索与实践，我发现传统的 EA 架构在处理像中台这种平台型的企业架构时会有很多力不从心的方面，例如：
传统的 EA 方法多是基于业务流程的梳理，产出的也多是要采购或是研发什么样的系统来解决业务流程上的一些问题，所以大多的产出物就是企业要采购像 ERP、CRM 这样的系统来解决特定领域的问题。而对于如何沉淀成平台甚至是中台，好像并不是那么适用。
传统的 EA 方法更多是解决当时信息化背景下的问题，也就是基于现状（As-is）的业务梳理，考虑如何通过系统的构建来解决业务流程的信息化改造问题。而目前大家在构建中台时，往往信息化程度已经非常高了，该有的系统都有了，而中台建设甚至是大家经常挂在嘴边的数字化建设，更多是为了未来（To-be）的业务发展和创新的问题，与传统 EA 的方法好像也不太搭。
传统的 EA 方法多是比较重的流程，需要做长时间大量的调研，产出动辄几百页的规划文档。这在十几年前信息化发展不高、瀑布式流程还占主导地位的时代也是可行和主流的，但是以现在互联网甚至是传统企业的 IT 变化速度，可能就算是花了大力气规划出来，也就过时了，也不太搭。
因此，我又重燃了对于中台规划建设方法论研究的热情，在想能不能以传统的企业架框架为基础，揉入一些新的配料，例如融入设计思维（DesignThinking）来解决创新的问题，融入领域驱动设计（Domain-Driven Design）来解决中台化能力识别的难题，再通过融入敏捷与精益的思想来解决过程重、流程长、变化响应力低的问题，集众家之长，调和出一套新的企业级架构方法，也就是中台这种面向用户与创新的平台型企业架构。
转眼间，两年多过去了，截至目前我们已经摸索出一套改良版的 EA 方法，和我上面说的一样，融合了各家所长。目前我们用这套方法已经帮很多企业进行了中台规划，还有很多已经在落地推进的过程中。可以说，这套方法已经非常成熟，所以今天正式拿出来跟你分享。
这套方法是怎样的呢？我们把它叫作“D4 模型”。
中台规划建设方法论：D4 模型之所以称之为 D4，主要是我们把中台从整体规划到落地交付的过程划分了四个不同的阶段，包含了两次发散与收敛的过程。
第一个阶段是 Discovery，帮助我们在中台规划前先建立全局视野。在这个过程中我们以企业愿景和战略为输入，结合行业趋势、竞争对手分析、用户客群分析 、业务现状分析、IT 资产盘点，全方位多角度地理解企业的战略市场环境以及业务及 IT 全貌，帮助我们做出最正确的判断。
第二个阶段是 Define，帮助我们基于之前 Discovery 发散的各维度信息进行收敛与分析， 对于中台的架构进行定义。通过对跨业务线的业务梳理进行重合度分析，并结合领域分析对业务表象之后的企业核心问题域做进一步展开和重合度分析，一起来收敛推导基于中台的企业架构设计。并基于多维度的打分，形成具体的实施路径规划，说白了就是先做什么后做什么。这里需要注意一点，此时收敛的是仍是企业架构层面，像业务中台、数据中台这种级别的产品，可能只是实施路径中的一个项目，在这个阶段也可以回答那个我们关心的问题，我们到底需不需要中台，需要哪些中台？
第三个阶段是 Design，帮助我们针对实施路径中的某一个产品，例如业务中台，做详细的设计，包括产品级的业务需求分析、功能及架构设计、实施计划等。例如对于业务中台产品，在 Design 阶段我们需要回答产品的愿景、边界、产品形态、技术架构、交付计划、成本预估等等，这个过程就是一个标准的产品设计过程，只不过在中台项目中大多是针对中台类的产品而已。
第四个阶段就是 Delivery，这个时候我们就可以针对一个设计好的中台，开始具体的交付过程，我们采用的是敏捷结合精益软件开发的方式，用快速迭代和基于反馈的调整，最大程度地弥补由中台建设本身的复杂度带来的设计偏差和其他的交付问题，并且注重架构的治理与守护，减少实现与设计的偏离。
整个 D4 过程，是一个从战略到落地，从企业架构到产品架构最终交付的过程。而且遵循敏捷与精益的思想，整个 D4 的过程也是不断迭代的，例如每一个季度到半年，我们可以重新做一次轻量的 Discovery 和 Define，来不断对企业架构做敏捷的调整，以应对市场和自身的变化和不确定性。
最后，有同学问过我，为什么叫 D4，不叫 4D？这里其实还有个小彩蛋，因为我们认为 D4 在中文里的发音有点像 Diss，代表了我们不断挑战旧的业务形式、不断创新、不断改变的一种态度，也非常符合现在企业数字化转型的浪潮。
总结思考今天这讲，我带你从一个典型的中台建设在启动阶段就会碰到的问题切入，详细阐述了做一个中台和做一个分布式系统的区别，并最终了解到中台背后的本质问题，其实是一个面向用户与创新的平台型企业架构的问题。
之后，我们又分析了为什么传统的企业架构方法在处理中台问题上有局限，结合其他的一些比较新的实践，融合而成我们现在的中台规划与建设方法论，D4 模型。
最后，为你简单介绍了一下 D4 模型的全貌和思路。截至目前我们已经通过这个方法论，在帮助多家企业开展中台的规划与落地实施。
从目前的反馈效果来讲，这个模型还是非常好用的，因为这个方法背后其实践行了一种我们称之为 Think Big，Start Small，Move Fast 的原则，既要想得长远，又要快速切入，并保持持续演进。在应对不确定性和复杂性都异常高的中台规划与建设任务时，这样的原则尤其适合和必要。
最后，给你留几个思考题：
在中台建设过程中，你遇到过什么样的问题？又是如何应对的？
你所在的企业，正在使用什么样的方法规划与建设中台？与我所讲的 D4 模型有哪些相同和不同之处？
期待在留言区和你一起探讨，也欢迎你把今天的内容分享给自己的朋友，我们下一讲见！

分享给需要的人，Ta购买本课程，你将得9元

生成海报并分享

赞 10

提建议

04 | 万事预则立：中台建设前必须想清楚的四个问题

06 | 中台落地第一步：企业战略分解及现状调研（Discovery）

 写留言

精选留言(28)

西蒙
2019-09-29
请教老师，如何做一个数据中台？数据中台和大数据平台，数据仓库有什么区别与联系？
作者回复: 西蒙，你好～数据中台的设计与建设方式，我们用的是一种叫LDD（Lean Data Discovery，精益数据创新）的方法，由于篇幅有限，本专栏就没有展开介绍。这个方法其实也是同样借鉴了双菱形，两次发散再收敛的过程，从业务价值从场景出发（而不是从技术和数据出发），做跨业务线的数据资产诊断识别，再配合数据与AI的技术底座建设，一起来完成从数据到场景的打通的。这么说可能比较干，我在总结篇里分享了两篇凯哥（我司数据与智能团队负责人）的数据中台的文章，开个对于数据中台的理解比我深的多，LDD也是他和团队一起通过实践摸索出来的，对于数据中台感兴趣的话可以看一下，以及公众号的其他文章～希望回复对你有帮助，感谢～
共 3 条评论
24
壶中无酒
2019-09-26
每个公司或企业对自己的中台建设都不一样，无法照搬模仿，是需要根据公司的战略方向和业务做出一个自己的企业级复用中台，让公司业务能够得到更好更快地发展。
作者回复: 壶中无酒，你好~ 首先很认同你的观点，至少从我看到的这么多家做中台的，很少有一样的，甚至说的都不是一个东西。不过补充的一旦，中台也是分层的，越靠技术其实离业务越远，反而越通用（例如大家的微服务平台都差不多），缺点是复用程度低，需要前台做大量的工作；反而越靠近业务，则通用性越差，但是因为离业务越近，所以复用的威力也越大，对前台的支撑也赋能效果也越显著。所以如果说两个不同的企业，技术中台都差不多的话，我觉得倒是没什么问题（可以想想为什么互联网卖云都是卖的技术平台和组件…），因为跨行业通用嘛。但是很少有听说直接卖业务中台的，因为行业间通用性低。但也有例外，就是只切入一个非常垂直的行业，例如零售行业，因为有了新的约束，自然也有有了更多的可能性（不知道能不能理解）。所以也正是因为在一个具体的行业或是场景下，通用的平台可以像业务再走一步（Headless CMS、Headless Commerce）…… 所以这也能解释为什么业界很多做中台的都是只针对特定的领域，比如房地产，汽车，金融。因为这样就能沉淀一些行业内通用的业务能力，然后进行高层次抽象复用，我觉得也没什么问题。总之，非常认同你的观点，这也是为什么我讲的多是一些通用的方法论，因为只有向后抽象一层，才能同时满足更多的不同的行业和场景。希望回复对你有启发，如果有反馈可以继续留言，我们继续探讨~
共 2 条评论
17
二蛋
2019-10-17
前面几讲更多的是领导或者公司战略级别的思考和规划，作为中台的核心技术人员，实打实每天要写代码，想解决方案，日常工作思维要做哪些改变？工作模式了又应该是怎样的了？目前感觉我们就是公司内部的外包，就火队员。
作者回复: 二蛋，你好~ 好问题哈，所有的公司愿景啊、战略啊，这些大面上偏虚的东西，最终都会沉淀到每一个系统，每一个API，每一行代码上，否则也没有任何价值，就真的是炒概念了。作为中台的核心技术人员（我去年的时候也开在一个中台的核心系统里做设计写代码，今年相对少一些），我们其实才是决定最终中台建设是否能达到最终效果的关键所在。中台最终不会只停留在PPT里，最终能否达到预期的效果，也是靠我们一笔一笔设计和写出来的。那对于作为每天写代码的技术人员的我们，我认为最重要的一是也要理解我们所做的中台产品的大面上的事情（产品愿景、目标、定位、客户、用户等等），因为这些因素都会影响到我们对于产品的设计，也是这个专栏更多关注的点。对应到你的问题，也就是工作思维有哪些改变这一点，我觉得就是需要技术人员有更多的“产品思维”，多想几个为什么，而不是每天只是重复的实现一个个功能。中台产品的愿景和形态比较模糊，这是区别于其他2C类产品的比较重要的一点，所以也需要在产品思维上有更多的思考，否则很容易设计偏，做偏。聊完了产品层面，再回到我们关心的技术层面，我认为中台产品的设计与开发，需要比一般产品更强的抽象，设计和代码能力，好的中台不是只是把大家拼在一起，交给一个团队就可以了的。真正能发挥出中台的能力，必须要有很强的抽象、设计与实施能力，如今DDD、TDD又一次焕发了第二春，也是于此有一些关系。而作为中台的核心技术人员，我们不但要具备更强的产品思维，了解更多的业务知识和培养自己的业务视角，同时在技术上无论是设计能力、抽象能力、还是技术运用的能力、还是写出好代码（易读易维护）的能力都提出了更高的要求。但是理想虽丰满，显示则骨感。像你说的很多时候我们因为各种各样的原因，成为了内部的救火队员，疲于奔命。首先这种情况并不少见，和一些阿里的朋友聊过，其实大家遇到的问题是差不多的，只不过差异在于是否积极想办法解决。就像我在10总结篇中推荐的张巍老师的文章《七问七答，亲历者讲阿里中台落地的实践》中描述的2015年当时阿里交易平台的实际情况也是一样的，只不过人家看到了问题，还开始着手解决问题，开始注重对于平台能力的治理，也一定自下而上催生了中台的实际产生。所以我最后的一点点小的建议就是，有问题正常，每家企业都有问题，我们可以找一个点着手开始思考如何改进，如果治理，日拱一卒，持续演进，看看能不能通过不断的努力扭转局面。因为不了解具体项目的上下文，只能基于我的经验给一些建议，希望对你有所启发和帮助~
共 2 条评论
9
钱
2020-02-05
读后感觉很高大尚，对于提高认知视野有所帮助，不过具体落地远远不够，需要掌握的更多的知识。敏捷思维+精益创业+技术创新+项目管理+业务熟练，既要有全局视野，又能深入业务和技术细节，这是技术架构+业务经理+产品经理的混合体。
3
亮点
2019-10-02
王老师，您好。没有太理解为什么会拿‘中台’和‘分布式系统’在一起对比，我理解‘中台’是一种理念，‘分布式系统’是一种技术架构，是一种实现方式，即中台最后落地，也可以用分布式架构实现，我理解可能有误，烦请指正，谢谢。
作者回复: 赵强强，你好～你理解没误哈，也正是我想表达的。拿中台与分布式系统对比，是因为很多人，尤其是技术出身的人，确实是就把业务中台就简单理解成微服务，从而导致用微服务做系统的思路和方法做中台建设，必然会遇到一些问题。（这通过大家的留言就能看出来，很多人都在问中台与微服务的区别）。可能是我文中没有表达清楚，希望回复能帮你解释清楚，有问题可以继续留言探讨～
4
Nick
2019-10-16
我看到了一片汪洋的概念
作者回复: 哈哈，可能我自己习惯了这些概念了，所以不觉得什么吧，我已经注意尽量用白话来表达了，可能还是功力有限…… 一些概念其实就是一层窗户纸，网上查一查就捅破了，不要被吓住……多了解点概念也有好处不是：）
3
明翼
2019-10-05
总结的感觉都是干货！通过这个文章也了解到什么人才最适合做中台的架构师，领域驱动，精益创新，微服务，至少要有这几个方面经验，任重道远，要学习的地方还有很多。
1
(╯‵□′)╯︵┻━...
2019-10-02
D4方法非常像方案服务流程，“改良版EA方法”很贴切，方法的适用范围好像比中台课题大得多，对此想听听您的见解。另外能顺带介绍一下EDGE和战略设计思维吗？
共 2 条评论
1
豆浆不放糖
2022-08-14 来自北京
好像被一字不差的搬运到csdn了。 https://blog.csdn.net/u013522009/article/details/125082523 是否需要维权？
Jacqueline 牛晓莉
2022-05-27
要从企业的战略分析开始，充分考虑未来架构规划对于战略的影响。这句话，我怎么觉得应该是：要从企业的战略分析开始，充分考虑战略对未来架构规划的影响？我本人就在带着一个中台部门，好惨啊，一开始跟要饭的似的，说出来都是泪。
Geek_5ce858
2020-06-23
请问一下教育中台大概是什么概念呢？我之前一直做的数据中台，但是越做对中台的理解越迷茫，感觉有些抽象。
kawayi
2020-05-05
其实就是提供企业中台的规划与落地实施策略，当然也不一定就是中台
张于刚
2020-04-10
王老师，中台项目很多都是给客户做定制开发的项目，每个项目都有成本预算，所以一般的软件开发都是设定项目周期，上线交付，客户付款。如果采用敏捷的方式，对于客户需求响应和交付确实很好，但是需求一直在滚动，怎么保障项目投入在预算之内，公司可以获益呢？
. .
2020-03-29
数据中台需求源源不断，如何界定边界
马菲特
2020-03-11
有了中台以后，后台还需要吗？实在搞不懂中台和后台的区分
地球王子
2020-03-02
您好，老师，基于中台的企业架构对于做技术开发的同事是不是更多是承接前面4D设计出来的产品规划与设计，传统上做业务分析的人员，则更贴近业务要转型为产品经理这样角色，设计出对应的产品？
技术我爱你
2020-01-21
第二个D感觉对人员要求很高，既要懂全局业务又要懂技术，这个很难，尤其不同领域业务也不同，老师是怎么解决这个问题的？
zzz333
2020-01-07
觉得也可以理解成“产品化”，中台跟原来单业务系统的一个明显区别，就是要“走出去”，当它是个产品，在企业内部销售。如果是原来业务系统，思路就是“我为企业增加/增强一个业务，企业为业务买单”，而中台思路是，“我在内部sell一个产品，企业为我的产品买单”。所以区别在转变看法，把做项目转变成做产品。
杜do度
2020-01-06
牛掰啊，大神……我们隔壁团队在做中台，我好奇就订阅了这个专栏学习下……看得我一愣一愣的……开眼界，o(∩_∩)o 哈哈
小老鼠
2019-12-14
如何了解企业未来的发展趋势，是不是要向CEO甚至董事长请教？唯一可以预测的是未来不可预知！
作者回复: 未来不可预知，但是所有的企业都有愿景和发展战略，行业也有行业的发展趋势。可以向CEO或是董事长请教，不过一般都很难。可以通过一些公司的使命愿景价值观，行业的一些调研，竞品的一些分析，领导的一些讲话里分析出企业目前的投入重点和发展趋势。当然唯一不变的就是变化，也不能因为一直变化就不做计划，没有计划也谈不上变化哈，我们要做的就是有计划，且不断调整。

