mod

极客时间专栏/说透中台/落地篇/04 | 万事预则立：中台建设前必须想清楚的四个问题.md

@@ -0,0 +1,158 @@
+<audio id="audio" title="04 | 万事预则立：中台建设前必须想清楚的四个问题" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/aa/27/aa491c625502b65e380adf35d6e2ad27.mp3"></audio>
+
+你好，我是王健。
+
+通过前几讲的分享，相信你对中台概念已经有了一些认识。
+
+现在社区里谈中台概念的人和文章比较多，但鲜有文章详细地描述落地方法。
+
+倒不是因为中台落地有多神秘，而是因为像前面提到的，中台是企业级的能力复用平台，那首先中台关注的是企业级发展的问题，一般我们把这种级别问题常常称之为企业的战略问题，而每家企业的战略不同，其核心能力也不同，自然每家企业的中台也各不相同。
+
+既然每家的中台都不同，那是不是说中台的落地方法，就只能靠自己摸索，无迹可寻了呢？
+
+答案自然是否定的，建设中台一定有章可循，只不过和其他技术类的方法相比要抽象一些。怎么讲呢？中台本质上也还是个架构问题，只不过不再是我们经常看到的技术架构，而是上升一个层次，是个企业架构的问题。
+
+所以，从今天开始，我们正式进入课程的第二部分，也就是落地篇的内容，一起来探索一下中台建设落地的方法论。
+
+你是不是已经跃跃欲试了呢？不过还是得先等一等，在正式开始讲述方法论之前，我们需要先思考一些问题。
+
+这几年我参与了很多企业的中台建设，有的是从中台建设的中后期才介入进去的，说白一点就是去救火的。刚介入的时候就发现中台建设已经到了瓶颈期，存在各种各样的问题。经过不断分析，我发现大部分问题的产生都可以归结于在中台正式开始建设前，没有想清楚以下这几个问题。
+
+所以，我们这讲就从这几个问题入手。
+
+## 从一个故事开始
+
+为了让你能更好地理解，这里我们虚拟一个例子。
+
+“极客地产”是一家房地产企业。与其他房地产企业不同的是，这家企业关注的领域比较垂直，主要负责一二线城市高科技园区周边的地产项目开发，服务的群体也主要是IT从业群体。
+
+现在整个地产行业，由于政策等原因都在向着轻资产和多元化的业务方向发展。那听说了几个大的地产龙头企业都在纷纷大张旗鼓地进行中台建设，极客地产的老板就叫来了公司里最资深也是最懂IT的小王，希望小王能担起公司中台建设的重任，助力企业未来的转型和发展。
+
+小王得知这个消息后，非常兴奋。作为对于公司信息化建设最了解的人，再加上之前对于外边大家都在谈论的中台概念也一直非常关注，知道中台对于一家企业的核心和重要程度。这么重要的任务落在了自己的肩上，小王下定决心一定要做好，不能辜负老板的信任。
+
+一眨眼，六个月的时间过去了。
+
+再看此时的小王，早已没了当初的雄心大志，反而疲惫不堪，被各方的压力压得喘不过气来，具体表现在：
+
+- 自打成立了中台团队，所有的业务都会不断地提需求过来，中台的界限本身就比较模糊，但因为人和资源一开始都是从前台借调和划分过来的，所以很难拒绝各个前台的需求，中台好像就成了所有前台业务团队共享的一个内部外包团队。需求拥堵和排期的问题也开始出现，需求多得天天加班都做不过来，前台业务还不断投诉中台的响应慢，影响了一线业务。
+- 中台团队所处的位置也比较尴尬。干系方众多，前边有各个业务前台团队，后边还要集成企业已有的各种核心系统，还要面对领导的不断督促。而且最主要的是，各方感觉对于中台都有不同的理解和诉求，甚至有些不同干系方的诉求都会相互矛盾和冲突。中台团队和小王被夹在各方中间，被各个干系方不断拉扯，非常难受。
+- 还有，中台也已经建设了一段时间了，半年也过去了，但是令小王焦虑的是，感觉并没有什么太多的建设成果出来。做的东西很乱，主要是响应各个前台业务的需求，但是前台业务也不怎么爱用，提需求的时候一个比一个积极，真正做完了需要前台接入的时候，又是用各种理由推脱，不太愿意接入。感觉中台做了和没做也没有太大的区别，并没有达到预期的效果，甚至也没想清楚预期会有什么效果。
+- ……
+
+类似的问题还有多，小王此时已经失去了初时的锋芒，天天愁眉不展。
+
+## 中台建设前必须想清楚的四个问题
+
+这虽然是一个虚拟的故事，但现实中小王这样的情况其实并不罕见。在我所接触的很多企业的中台建设过程中，都或多或少出现过类似的问题，也困扰着所有的中台团队，甚至会让企业中台建设的决心动摇，重新思考是否中台是一个正确的方向。
+
+但是在我看来，要走出这样的困境，我们需要在中台建设前想清楚四个问题。
+
+**中台建设的愿景是什么？**
+
+“遇事不决看愿景”，这是我在做中台规划和落地过程中，说得最多的一句话。
+
+太多时候我们把解决方案和问题本身混为一谈。中台只是一个解决方案而已，但是很多时候我看到人们却把中台当成了问题本身，纠结于别人的中台都是什么样子，自己的中台该是个什么样子，而不是关注中台到底有没有解决该解决的问题，甚至希望中台解决什么问题还没有想清楚。
+
+所以我经常被问到的也是，中台应该什么样？中台应该怎么建？而我一般会先反问一句：你建中台是为了解决什么问题呢？对于企业和业务又有什么价值？很多情况下，对方并不能清晰直接地回答，或是说了一堆像消除烟囱，移除孤岛等“大话”。在我看来，这就是还没有搞清楚中台建设的愿景。
+
+中台就像一个产品一样，需要一个明确的愿景，要让所有人能够清晰明确地知道，中台建设对于企业对于业务的价值，从而可以一起始终向着同一个方向持续前进。如果愿景缺失，那我们就会很容易在中台建设过程中迷失自己的方向，失去定力。
+
+愿景帮助我们了解自己中台建设的目标，帮助我们判断哪些事情是符合中台建设愿景的，作为中台团队我们需要去考虑。在这之外，更重要的是帮我们判断哪些事情不是中台要去做的，为中台做减法，这点在中台的建设过程中其实更加重要。
+
+尤其是在中台建设初期，项目往往还处于试点的阶段，可支配的人员和资源不会特别多，如果没有自己的方向，就会陷入到上面小王所处的境地，把中台变成一个内部共享的外包团队。
+
+**所以在建设中台前，第一个要问自己的就是：我们建设中台，愿景是什么？而且更重要的是这个愿景是需要所有的角色，上到企业管理层，下到每一位中台的相关人员都要明确并达成一致的。**
+
+具体怎么做到呢？我们在实际的实施过程中，会有一些工具和实践，我会在后面讲中台设计的课程中再给你展开分享。
+
+**中台的用户和客户是谁？**
+
+这个问题也同样非常关键，因为中台是企业级的事情，必然会面对组织的问题以及庞杂的干系人问题。
+
+再说得直白一些，就是中台的建设通常都会伴随企业内的组织重构以及利益和职责的再分配。如果没有搞清楚中台建设的各个干系方关系，必然在中台的建设过程中就会四面碰壁，陷入“干系人旋涡”之中，面临多方面的阻力，陷入一个非常被动的局面。
+
+所以在中台建设之前，我们最好先搞清楚中台如果作为一款产品，它的用户是谁？客户又是谁？用户和客户是一个群体么？除了用户和客户还有哪些干系方？他们对于中台都有什么期望，这些期望又是否一致呢？
+
+为了想清楚这个问题，我们可以把企业想象成一个家庭，具体到某一条业务线就像是家庭里的一个孩子，他关注的更多是我今天能不能多玩一会儿，也就是我们常说的短期的战术目标，回到企业里就是我这条业务线今年甚至这个月的KPI目标能否实现。
+
+而企业管理层就像这个家庭的家长，他关注更多的是孩子的未来，高考的时候能不能多拼过几万个别人家的孩子，实现可持续发展，也就是我们常说的长期战略目标，关注的是未来五年，十年甚至是更长的时间企业会是什么样子。
+
+而中台此时就像是一款K12的英语教育产品一样，那你思考一下，如果你是这款产品的产品经理，你会更关注谁呢？是作为产品实际用户的孩子的短期战术目标，让他玩得爽，甚至跟游戏一样？还是产品实际买单的人，也就是作为产品客户的家长的长期战略目标，甚至为了达到最好的效果，不惜牺牲孩子的用户体验？
+
+这个例子里，根本的问题在于长期战略目标和短期战术目标的矛盾。答案其实也很简单：都要关注。我们需要找到企业管理层与业务线关注点的结合点，也就是长期战略价值和短期战术价值的结合点。
+
+而且对于中台来讲，情况可能比上面提到的更复杂，他的干系方还不止是用户和客户这两方，因为其所处的特殊位置，干系方往往纷繁复杂。在保持自己方向的前提下，找到各方利益的结合点，是一件非常困难且有必要的事情。否则，在建设过程中就会受到各方的阻力，产生摩擦，导致中台很难推进落地。
+
+但反过来讲，中台也不应该只是极力去满足各方的诉求，中台团队毕竟不是业务的外包团队。中台需要有自己的思想和规划，要能做到听得进别人的话，但是还要明确自己的目标，走自己的路。而自己的目标，就是来源于上面提到的中台建设愿景，而中台的愿景也往往来源于企业的战略需要。
+
+所以，我常说，**中台建设虽然需要兼顾各方的利益，但更多主要还是解决企业管理层对于公司长期生存与可持续发展的恐惧与焦虑问题**。
+
+想清楚这一点非常重要，因为下一个问题就跟这一点相关，就是中台的钱到底该由谁出？
+
+**中台的钱由谁出？**
+
+我们常说谈钱伤感情，也往往选择避而不谈。但是钱的问题往往是很多问题背后的本质，也是中台建设过程中很多矛盾的来源。
+
+这里的钱说的比较白话，对于企业内部，可能代表的就是人和资源。所以，这个问题还可以引申到中台的人从哪来？从前台团队借调么？还是重新招聘新组建呢？一个中台建设往往会持续很长的时间，那这些人的成本又由谁来承担呢？如果说中台是为前台业务赋能的，是不是就应该从前台各业务的预算中划分出一部分作为中台的建设预算呢？
+
+这些问题如果没有考虑清楚，也会给中台建设带来非常大的麻烦。
+
+在我看来，市面上的中台建设，如果从投资结构来讲，基本上可以分为两种类型，即“**众筹模式**”和“**投融资模式**”。当然，我们还能看到这两种类型的混合模式。
+
+先说“**众筹模式**”。相信你一看就明白，众筹模式就是用户预付款，生产方承诺一定时间后提供某一类型的产品。回到中台建设的背景下，就是从业务前台集资，有钱的捧个钱场没钱的碰个人场，能出预算的出预算，能出人的出人，来组建中台团队，然后再反过来服务于前台业务团队。
+
+我在前面几讲中也提到过，中台是为前台业务而生，所以看起来前台出资源，中台为前台服务，拿人钱财替人消灾，天经地义。
+
+其实这里隐藏着很大的问题，问题就出在了中台建设的愿景和中台的投资模式的匹配上。因为业务前台优先关注的是自己短期的实际问题，从原本就资源紧张的前台业务中，再划分一定的资源来搞中台建设，业务前台作为中台建设的实际出资方，前面讲了他也会更关注短期的战术目标，自然希望中台短期就可以见效果，帮助自己解决实际的问题。
+
+如果中台的愿景就是为了解决业务方短期的问题，其实还好。但我看到的大多数中台建设的愿景都是企业战略层面的，都是为了企业长期的发展考虑而建设的。
+
+这时候如果还是采用众筹模式，就会发现非常矛盾。企业管理层，往往也是中台的发起者，他关注的更多是长期的战略目标，中台团队需要听；但前台业务团队作为中台的实际出资方和使用方，即是用户也是客户，他关注的是相对短期的战术目标，需要短期就看到中台建设的成果对于业务的实际价值，中台团队更要听。这时候中台的团队就自然会被长期目标和短期目标相互拉扯，非常难受。
+
+所以如果中台建设的愿景是解决企业长期战略的目标，那我建议尽量采用另外一种大家都比较熟悉的“投融资模式”，或者至少是投融资模式与众筹模式的组合模式。
+
+**投融资模式**，顾名思义，就是一个产品的建设前期先由投资方出资，按照产品的建设目标经过一段时间的建设期，相对成熟之后，再逐渐地让用户使用，最终通过对于用户的服务，让用户满意，实现收入并收回企业投资且盈利的模式。目前大部分的创业公司都是采用类似的模式，相信你也很熟悉了。
+
+那对于中台建设的投融资模式，就是中台建设的前期（从0到1），不是直接从前台业务团队划出资源，而是由企业本身的战略储备资源投资建设。经过一定时间的建设期，比如6个月，然后逐渐找适合的前台业务进行试点接入，如果效果好的话再推广到更多的前台业务团队。当服务稳定之后，对前台也产生了稳定的价值之后，再逐渐从前台收取一定的资源，可以是人也可以是其他资源，既所谓的收回投资并实现盈利。这里的盈利只是个比喻，可能是满足了企业管理层对于企业战略目标的需求。
+
+这种模式的好处是中台团队在中台的建设初期会有更多的自主权，在启动和脆弱期不会受到太多现有业务压力的影响，能更好地实现中台自己的建设愿景。但缺点是企业需要有较雄厚的战略资源支持，也需要有更大的战略决心。我看到很多互联网企业的中台建设，也往往都是采用类似的模式，所以在外界看来，他们的中台建设都非常直接且迅速。
+
+所以如果你所在的企业建设中台的愿景，是为了解决偏短期战术层面的痛点和问题，可以采用众筹模式加演进式的投资结构来启动，这样的好处是中台的启动会比较平滑，资源利用率高，初期新增成本较低。但如果中台建设的目标是偏长期战略层面的问题，比如业务转型，那还是建议更多地考虑使用企业战略投资，使用投融资模式，这样更利于中台建设的健康快速发展。
+
+**中台的目标怎么验证？**
+
+还记得一开始提到的小王的故事么？中台建设的另外一个难点就在于对建设结果很难做量化度量。这点不像前台的业务线或是我们常见的ToC类型的产品，可以相对容易地找到一些量化指标来度量产品的成功与否，比如常见的用户数量，用户活跃度或是市场覆盖率等。
+
+当然中台也可以说，前台之所以有这些成果，都是我中台的赋能效果，但是这往往很危险。因为我们拿不出详细的数据来证明这些用户、这些占有率里到底是有多少是因为中台建设的成果。相反，前台业务可能会说中台还拖了后腿，你看要不是前几天中台挂了两次，连累了我们前台业务，数字可能比现在还要好很多，等等。
+
+你看，中台作为前台的服务者，不但无法分享业务成功的喜悦，反而很容易被甩锅成了背锅侠。
+
+所以，以终为始，在建设前就应该思考如何验证和度量中台。通过提前考虑这个问题，让我们可以在建设的中后期规避一些扯皮和风险。
+
+目前业界有一些中台的考核标准我们可以作为参考，例如阿里巴巴的中台考核就是设计成：40%稳定性+25%业务创新+20%服务接入量+15%客户满意度。
+
+那我们自己的中台能不能简单复用人家的指标呢？答案肯定是否定的。中台建设的愿景不同，考核的方式和指标也自然不同。
+
+比如回到极客地产的这个例子，中台建设的愿景是支持业务转型，支撑的是新的业务，那可能早期就没必要要求那么高的稳定性和接入量，可能只支撑一到两个新的业务线，更多看的是服务的满意度，或是其他指标。
+
+具体到一家企业某个中台的验证指标设计，这是一个复杂过程，而且往往还会不断演进，需要结合上面提到的中台愿景、投资模式、干系人利益点以及其他相关因素来综合设计。我们用到的一些思路和想法，我会在中台的规划与设计篇再为你展开来讲。
+
+最后，建议你不要等建设完了再去考虑如何度量的问题，尽量提前考虑甚至在建设之前就约定清楚，这样才能最大程度地帮助中台建设不走偏，不乱了阵脚。
+
+## 总结思考
+
+<img src="https://static001.geekbang.org/resource/image/4e/14/4e7227674e9d524a8d4c07ed34d61514.jpg" alt="">
+
+其实中台建设是一个非常“凶险”的过程，上面的问题只是最基础的问题。
+
+想清楚这些问题之所以重要，是因为他们能帮我们判断中台建设的“周边环境”是否已经准备就绪。我们看到很多企业建设中台，有的成功有的失败，其实不是因为实力和方法上有什么太大的差别，大家碰到的问题和困难往往都是一样的。
+
+最主要还是**中台孵化的环境是否已经成熟**。有的企业最终没有成功反而是因为走得太早了，思路太超前了，周边环境还没有就绪。
+
+所以在真正地开始中台规划建设前，先问我们自己这四个问题，从我自己的经验来看，还是非常有必要和帮助的。
+
+最后， 如果你所在的企业也正在计划或者已经开始建设中台，针对今天提到的这四个问题，请你思考一下，是否已经想清楚了呢？能不能用一页A4纸把这些问题的结论写下来，然后给其他人看看，理解又是否一致呢？
+
+如果你还没有接触过中台建设，那对于今天的内容，还有什么问题吗？也请你在留言区畅所欲言，我们一起来讨论。欢迎你把今天的文章分享给自己的朋友，我们下一讲见！
+
+

极客时间专栏/说透中台/落地篇/05 | D4模型：中台规划建设方法论概述.md

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

极客时间专栏/说透中台/落地篇/06 | 中台落地第一步：企业战略分解及现状调研（Discovery）.md

@@ -0,0 +1,144 @@
+<audio id="audio" title="06 | 中台落地第一步：企业战略分解及现状调研（Discovery）" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/0b/14/0bbccf40eddf6f1f4377214acfe4f914.mp3"></audio>
+
+你好，我是王健。
+
+上一讲我为你介绍了我们中台建设方法论的概述和来源。那从这一讲开始，我就带你一一展开我们做中台规划与建设的这四个阶段，介绍每个阶段的目标和一些常用的工具与实践。
+
+好了，那我们就从第一个阶段Discovery开始，也就是我们要先建立一个对企业和行业的“全面视野”。
+
+那为什么要先做这件事情呢？这里多说一句，其实D4的前两部分Discovery和Define合起来，就是一个在企业级先发散再收敛的过程。我们公司内部对这个过程有一个称呼，叫作Portfolio Discovery，简称为PD。实际实施时，PD是一个4～8周的头脑风暴工作坊，下图为你展示了一个完整的PD工作坊路线图，帮助你理解。
+
+<img src="https://static001.geekbang.org/resource/image/9e/48/9e1d2d060ffba969f9b482b1681f3a48.jpeg" alt="">
+
+对于中台的整体规划，也就是回答要不要建中台、建哪些中台、谁先建谁后建这些问题，我们现在也是通过PD这样一个过程来评估和判断的。那你可能会有疑问，为什么PD这样一个方法，可以帮助我们做中台的规划判断呢？这里我们先简单来说明一下。
+
+## 为什么用PD这样的方式规划中台？
+
+Portfolio Discovery翻译成中文就是投资组合规划，应用在企业里就相当于产品线规划。说得直白一些，就是假如我是一家公司的CIO，今年手里有1个亿的可支配IT预算，我最关心的就是在接下来的一段时间（可能是1年，也可能是3~5年），为了企业发展的目标，
+
+- 我需要花多少钱在数字化建设上？
+- 这些钱该怎么花？怎么分配？要新增哪些系统，是购买还是自研？要干掉哪些系统？优化哪些系统？继续维护哪些系统？保持哪些系统不变？
+- 要不要建个中台？
+- ……
+
+你看，说白了还是钱怎么花最值的问题，本质上也都是资源分配的问题，如何在资源有限的前提下找到最好的投资组合，或者说如何把钱花在最该花的地方上。
+
+而建中台只不过是其中的一个潜在选项而已，潜在的解决方案之一，即基于企业的战略和现状，我们需要在应用架构中添加一个中台层来解决目前企业遇到的问题。
+
+<img src="https://static001.geekbang.org/resource/image/7e/f0/7e3a9824ed3b3c413e372517116f64f0.jpg" alt="">
+
+中台这种解决方案到底适合不适合企业，仍然是需要调研和判断的。所以，如果我们一开始就把中台作为一个确定的既定方向，难免会限制住我们的视野，有可能会错过比中台更好、更简单、更有效的解决方案，或是过早地进行过度设计，在根本不需要中台的场景下，大张旗鼓地开展中台建设，劳民伤财。
+
+那企业到底要不要划分出一部分钱和资源来做中台建设？对公司来讲添加中台这样一个新的架构层次有什么价值？什么时候做最好？优先级怎么样？这也正是PD所主要关注和需要回答的问题。
+
+而为了避免拍脑袋的情况出现，Discovery作为PD的前半程，主要目的就是做充分的发散和调研，也就是利用各种工具和手段帮助我们充分了解行业趋势、竞争对手的情况、公司的战略分解以及自下而上的现状调研等信息和环境，为下一个阶段Define的收敛，也就是对于企业新的业务架构、应用架构、技术架构甚至是组织架构的设计，提供充分的信息支撑和依据。
+
+整体上，Discovery又可以简单分成由外到内、自上而下和自下而上的三个不同方向的过程。
+
+## 由外到内：行业与竞争对手分析
+
+所谓知己知彼百战不殆，在详细了解自身之前，我们有必要先将视野放开一些，看看行业的大趋势与竞争对手都在做些什么。
+
+记得梁宁老师就曾经在得到专栏《产品思维30讲》中提过“点-线-面-体”的理论。如果说中台本身只是一个点，那它可能只是一家企业发展到一定阶段的产物，不是开始也肯定不是结束。所以，要从一家企业的发展过程这条主线上来看待中台这件事情，来看这个点。它从哪里来？为什么会出现？又将向哪儿去？甚至思考中台的下一个阶段会是什么？会被什么替代？我在观察一家企业的中台建设历程，包括整个中台大趋势的形成和发展的时候也是这样来看的。
+
+有了线就足够了么？还不够，我们还需要再上升一个维度，来看看同一个行业中的其他线，也就是同一行业中的其他企业在做什么？战略都是什么？数字化建设的重点又是什么？有没有同时在做中台建设？建设的目标又是什么？效果怎么样？
+
+但这里要注意的是，分析不一定就代表要直接借鉴，人家都在建中台我们就要建中台，这个思路不可取，因为即使处于同一个行业，但是由于企业愿景战略、商业模式、客户群体等差异，每家企业也都不尽相同。
+
+最后还要跳出面，从更高的维度“体”，来审视企业所在的这个行业本身，或者从其他的行业，其他的面上来学习。而这么做一般会有两个好处：
+
+<li>
+一是如果其他面上有好的概念或是方法，我们可以借鉴过来，帮助自己的企业在自己的行业里取得先机。中台这个概念起始于互联网行业，目前就正在被各个行业参考和借鉴。
+</li>
+<li>
+另一个好处，就是如果发现更好的面、更好的行业，能够实现企业跨行业的跃进，可能就抓住了走上另一个快车道的机会。话说回来，目前很多企业的中台建设，目的就是识别企业核心能力，沉淀到中台，并以此为跳板和支撑，进行业务的创新和探索，想要跳到另一个更有发展的全新赛道上。
+</li>
+
+说了那么多行业调研与竞争对手分析的好处，那具体怎么来做呢？其实业界已经有了很多非常成熟的方法，你可以直接使用，例如常见的：**五力模型，SWOT，商业模式画布，竞争对手产品线分析，竞争态势分析矩阵等**。
+
+## 自上而下：企业战略分解
+
+如果说PD最主要的一个产出物是数字化建设的蓝图和路线图，那PD的输入就是企业层面的愿景和战略。
+
+我们之前关于愿景谈得比较多了，应该也比较容易理解，就是到达一定时间希望企业可以变成的样子或是达到的目标，例如对于极客地产这个例子，愿景可能就是2022年实现业务从重资产到轻资产的转型，更具体比如服务类业务占总收入的比例要达到70%以上。
+
+在这里再多说一句，我们也确实见到过很多企业在并没有明确企业愿景的前提下，就开始了大范围、大规模的中台建设。这就像是舰队在还没有明确目的地的前提下，就贸然出海一样，很可能随波逐流，最后迷失在汪洋的海上，弹尽粮绝。所以如果一家企业是这样的情况，一定需要先补上这一部分的内容。
+
+在这里呢，我们就先假设在开始规划中台前，企业就已经有了明确的愿景和战略作为PD的输入。
+
+再来看战略这个词，我们理解起来可能就会觉得比较模糊和虚。在《论大战略》这本书中就提到：“所谓战略，就是如何达成目标与能力的平衡，并根据环境变换做出合适的调整”。
+
+下面是我们经常用到的战略平衡三角形，可以帮助你理解战略这个相对较虚的概念。
+
+<img src="https://static001.geekbang.org/resource/image/bf/72/bfb25666ac33363d5ce70507483d0e72.jpg" alt="">
+
+通过这个战略平衡三角形，我们简单地做一些数学变换，就可以解释“企业战略分解”到底是什么了。下面这个推导过程，可能有些烧脑，如果一时理解不了可以多看几遍，相信会对你理解战略这个词有很大的帮助。
+
+好，我们开始。依据战略平衡三角形，在企业的愿景和目标已经确定的情况下：
+
+- 企业战略就可以简化理解成：结合**企业自身**的能力与其所处的环境，到底需要采取什么样的举措，才能实现企业预定的愿景和目标呢？
+- 而企业战略分解就可以简化理解成：结合**企业各部门自身**的能力与其所处的环境，到底需要采取什么样的举措，才能实现企业预定的愿景和目标呢？
+
+好，推导完毕。而对于企业战略的分解，业界也有很多工具和实践，例如BMGovernance设计的企业战略分析模型等。但为了应对变化越来越快的市场环境，在PD中我们使用的是**精益价值树**（Lean Value Tree）的工具来帮助做战略愿景的分解的。
+
+精益价值树是一种以价值成效为导向，用于分析和沟通业务愿景、战略与投资的工具。它的核心是建立从愿景、目标到投资举措自上而下的对齐，因此采用一种逐层分解的树形结构，如下示意图：
+
+<img src="https://static001.geekbang.org/resource/image/84/6c/84e4ea6c74157c2246f10a6c895f776c.jpeg" alt="">
+
+这个过程，就是我说的自上而下的战略分解过程。而某一个中台，它可能只是最终推导出的一个具体的举措而已，向上还是要能追溯到对于企业愿景和目标的关联性和价值上，匹配和对应企业的愿景目标。
+
+## 自下而上：现状调研与分析
+
+如果把企业战略分解理解成从企业愿景自上而下的分析推导过程，那是不是直接按照推导出的举措具体实施就可以了呢？
+
+往往还是不够的，因为每家企业经过长时间在市场中的搏杀，能生存并发展到现在，都会出现各种各样的问题和限制。如果脱离现状，无视这些问题与限制，就肯定会面临非常大的阻力与风险。
+
+所以我们不但要自上而下地做企业战略的分解，以此来帮助我们思考中台或是其他举措是否必要。同样需要充分地做自下而上的现状调研，来帮助我们了解现状和历史。一方面充分尊重过去遇到的所有问题，收集汇总痛点；另一方面又要求我们能跳出过去的限制，重新从业务出发，从用户出发，去重新探索基于新技术、新架构下的一些新的可能性。
+
+这里我们常用的工具和实践也很多，例如**高层访谈、干系人地图、组织架构分析、战略设计思维、业务架构现状梳理、用户旅程、服务蓝图、领域驱动设计、应用系统现状梳理、技术架构现状梳理**等等。
+
+充分且多维度的现状调研与分析，不但能让我们对于业务、应用、技术、数据、组织现状，也就是企业架构现状有一个全面清晰的认识，还可以通过访谈与调研，补充时间线上的上下文，包括过去发生了什么？为什么现状是这样子的？未来大家希望是什么样的？为什么？
+
+不过这里有一个问题你可能需要关注，那就是梳理的范围和深度。不要忘了我们此时做的是企业级的架构梳理，宽度和范围可能会远远超过我们的想象。如果深度控制不好，会发现转了半天还是在一个小的领域和业务线原地打转。
+
+所以面对这种问题和风险，我建议你：
+
+<li>
+先完成自上而下的企业战略分解，再开展自下而上的现状调研。因为做完战略分解，我们已经对于公司的行业、业务、愿景、战略已经有了一些了解，再开展调研的时候就会有个全局的把控，对于粒度和深度都更容易拿捏。
+</li>
+<li>
+做好充分的准备，能够提前通过阅读资料和小范围调研完成的内容就提前完成。
+</li>
+<li>
+制定详细的计划，可以按照现状调研的总时间倒推梳理的范围和粒度。如果时间足够，可以用两天的时间梳理一条业务线的业务架构，这样梳理就可以深入一些。但如果只有半天，则粒度可以适当放粗，先保证有一个全局业务视图。
+</li>
+<li>
+建议刚开始做的时候，可以粒度粗一些，不要过早陷入细节，不过粒度到底如何控制确实需要对于公司战略以及业务有深入理解，也是最见功夫的地方。在判断不好的时候，可以先粗一些，如果最后还有时间，也可以再做一轮调研向下再展开一层。
+</li>
+
+这样的现状调研工作，对于一个中型的有四五条不同业务线的企业，我们实际实施大概需要2～4周左右的时间，当然还要视客户而定。完成调研工作后，我们就对企业各方面的现状有了一个比较全面的了解，并且也收集到了每条业务线大量的痛点和问题，这样就有了对未来架构的展望。
+
+在做自下而上的各条业务线调研时，我们使用的工具并不是传统的业务流程图，而是结合设计思维的思想，使用**用户旅程结合服务蓝图的方式**进行的，具体的内容会在08讲，介绍一个业务中台的设计过程时再展开为你介绍。
+
+## 总结思考
+
+至此，我们就通过由外到内的行业分析、竞争对手调研，自上而下的企业战略分解，以及自下而上的基于现状的企业各个维度的调研，做了充分的发散，收集到足够的信息。
+
+整个PD的过程（包括下一讲要讲到的Define过程）我们都是以工作坊的方式进行的，相关角色在一起头脑风暴、充分讨论，产生最后的成果，整个过程非常轻量高效。
+
+<img src="https://static001.geekbang.org/resource/image/71/cc/71fafa04595e38a4857ccefd9e63d0cc.png" alt="">
+
+而完成了PD中的前半部分Discovery后，下一步就是要根据这些收集到的原料信息，进行信息的分析整合，收敛形成具体的中台建设规划，也就是PD的后半部分，Define的过程，我将在下一讲中为你介绍。
+
+最后还是给你留几个思考题：
+
+<li>
+你所在企业的愿景是什么？战略又是什么？推导到你所在的部门，举措又是什么？
+</li>
+<li>
+你所在的企业真的需要建中台么？是否能与企业愿景匹配？
+</li>
+
+欢迎你把自己的思考写在留言区和大家讨论，也欢迎你把今天的内容分享给自己的朋友，我们下一讲见！
+
+

极客时间专栏/说透中台/落地篇/07 | 中台落地第二步：企业数字化全景规划（Define）.md

@@ -0,0 +1,186 @@
+<audio id="audio" title="07 | 中台落地第二步：企业数字化全景规划（Define）" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/2b/b2/2b64fa7e9796aade1394b5da7c8713b2.mp3"></audio>
+
+你好，我是王健。
+
+上一讲，我们通过Discovery从三个不同的角度和方向，对企业内外部环境进行充分的信息收集之后，得到了非常多的信息。那这一讲我们就来讲一讲，如何通过对这些信息的分析和收敛，运用企业架构方法，最终分析形成企业的数字化全景规划，并最终推导出我们PD的一个重要产出物，也就是一个中台落地建设的演进路线图。
+
+那首先需要给你介绍一下什么是**企业级架构方法**。
+
+## 企业级架构方法
+
+企业架构方法如Zachman、TOGAF等，最长的已经有20多年的历史了，可以说已经非常成熟了。其中应用最广的应该就属TOGAF了，在市场上占据了至少半壁江山，也最为我们所了解。TOGAF的基本思路，就是从企业最新的愿景战略以及运营模式出发，设计企业的To-Be业务架构，然后依次推导，一步一步推导数据架构、应用架构、技术架构，就是这样一个过程。
+
+<img src="https://static001.geekbang.org/resource/image/1c/69/1cd2e944f38d6a7f1d0386bdd9b92669.png" alt="">
+
+我们现在在做以中台为潜在预设目标的企业数字化全景规划时，也参考了TOGAF的这个思路，基于Discovery发散收集来的各个维度的信息，在Define阶段结合自上而下企业战略分解的举措和自下而上现有业务架构梳理和分析的问题及痛点，重新设计新的业务架构，并进一步推导出其它的相关的架构设计。
+
+只不过相对于传统的企业架构方法，整个过程做了剪裁和轻量化处理，引入了**事件风暴**、**DDD工作坊**等协作互动形式，整个过程各个关键角色充分讨论，协作共创，力争在过程的轻量前提下，还能保证结果的准确与一致。
+
+但这里有一个关键点，因为前面提到过中台从架构层面就是平台型的企业架构，那对比过去我们常做的系统型企业架构，如何从企业整体的视角，更准确地识别出多业务线之间的共性业务元素，对我们来讲也是个不小的新挑战。
+
+为了解决这个问题，前面讲方法论概述的时候其实已经提到过，我们是在整个企业架构设计的过程中融入了领域驱动设计（DDD），结合事件风暴，对业务流程背后的问题域进行分析，以及通过不同业务线的问题域重合度分析，帮助我们透过流程洞见企业各业务的本质，寻找共性业务元素。
+
+给这个过程做个比喻，就像是给业务照了一个B超一样，帮助我们更好地透过现象看到内在的实质。
+
+对于企业架构方法，例如TOGAF的相关资料比较多，这里就不展开了，我在最后的总结里会给你一些参考资料，你可以进一步拓展阅读。
+
+那利用剩下的篇幅，我想着重讲一些在企业架构设计实施过程中与中台相关的常见问题。
+
+## 中台复用的能力类型到底有几种？
+
+第一个问题，如果说中台就是企业级能力复用平台，那在做企业架构设计的过程中：
+
+<li>
+我们到底要在不同业务线中寻找哪几类共性能力？
+</li>
+<li>
+我们经常讲的业务中台中的业务到底又具体指的是什么呢？
+</li>
+<li>
+那为什么中台一般都是业务、数据、技术这三者的组合呢？
+</li>
+
+为了回答这几个问题，先来给你看一个模型：
+
+<img src="https://static001.geekbang.org/resource/image/3f/20/3f4fefec9e47bcef963a8a9883108820.jpg" alt="">
+
+这是哈佛大学出版社2006年出版的一本讲企业架构战略的书里提到的一个商业运营模型（Business Operating Model），它提出两个象限：
+
+<li>
+横轴代表标准化（Standardization），标准化越高，你可以简单理解成企业就是通过业务模式（业务功能+业务流程）的复用实现业务线的扩展。比如像电商网站的各个垂直网站，或是全球化，都是通过将电商的业务模式复用，通过复用到不同的垂直领域，或是不同的地区来实现不同业务线的扩展。
+</li>
+<li>
+纵轴代表集成（Integration），也可以理解成数据集成，这种运营模式的企业就是通过对数据的复用，来实现业务线的扩展的。比如最常见的像腾讯，通过对微信用户数据的集成和复用（导流），来帮助新的业务线（例如游戏）快速扩展。
+</li>
+
+那为什么要提到这个模型呢，因为这里的“商业运营模型”就很像我们中台里的能力复用方式，即你复用的到底是业务模式；还是复用的是业务数据；还是两者都不是，只是复用了更底层的技术部分。
+
+<img src="https://static001.geekbang.org/resource/image/94/5a/94f9f732161731923c11da7af8d6bf5a.jpg" alt="">
+
+我来稍微解释一下。
+
+如果两条业务线，数据也是一套，业务流程也一模一样，那很简单，它们其实就可以共用一套系统，这也就是我们最常见的大单体系统。但这越来越成为一个反模式，除非在一些标准化极高的场景，例如核心财务系统。
+
+如果两个不同的业务线之间，业务模式很相似，但是数据反而需要隔离开，那就是右下的区域。一般可以通过业务中台来沉淀通用抽象的业务流程，或者直接使用多租户的企业内部SaaS来实现业务模式的复用。在这个象限，业务中台与SaaS的区别只是抽象粒度和层次的不同，本质上要解决的问题都是一样的，即业务模式复用。
+
+SaaS抽象层次高，更靠近业务，但对于业务的标准化要求高，灵活度小。业务中台正好反之，抽象层次较SaaS低，介于PaaS和SaaS之间（所以很多企业管业务中台叫ApplicationPaaS，或是BussinessPaaS），离业务较SaaS远一些，但更灵活。这也回答了很多人困扰的业务中台与SaaS的区别问题。
+
+这里可以多说一句，国外最近出现了一种Headless Commerce（无头电商），去年也出现过Headless CMS。我认为这波国外Headless的趋势，就很像是国内的中台一样，也是在PaaS和SaaS之间在找到一个新的抽象层次而已。
+
+好，说完了右下，再来说左上，指的是那些虽然业务模式不同，但是可以通过数据的集成、打通与复用来实现业务线扩展的场景，一般也可以通过业务中台和数据中台来解决。因为业务中台里承载的也有数据，或是说业务中台生产的就是业务数据。
+
+而前面提到过，数据中台则是对于业务中台生产的数据，进行二次加工，例如一些大数据计算、跨域的业务数据整合计算或是一些AI赋能场景。
+
+好了，希望通过上述的分析，能帮你理解这些不同中台（包括业务中台，数据中台，技术中台，以及业务中台与SaaS，业务中台与数据中台）的概念和差别。
+
+而回到一开始的问题，我们到底要在不同业务线中寻找哪几类共性能力？现在也非常清晰了，总结下来基本上就是四类：**业务数据、业务功能、业务流程以及通用的技术能力**。
+
+## 通过领域分析识别共性能力
+
+既然企业可复用的能力就是以上这四大类，那抛开相对独立的技术能力不谈，对于剩下的业务数据、业务功能和业务流程三类共性业务能力，具体来说，我们要如何识别呢？
+
+还是举极客地产的例子，对于物业业务线和长租公寓业务线这两条业务线，表面上看起来解决的是完全不同的问题。但是这并不能代表这两条业务线之间没有业务数据、业务功能或是业务流程复用的场景呀，比如最直接的就是打通连接物业的业主数据和长租公寓的用户数据，通过例如最简单的积分机制共享，来实现物业业主向长租公寓用户的转化，实现用户的导流和新业务热启动，加速新兴业务的快速发展。
+
+那到底怎么才能透过业务流程识别出有哪些类似的能力复用场景呢？没错，就是**领域驱动设计（DDD）**。
+
+我们就是对于已经梳理的业务，又深入了一层，使用领域驱动设计结合事件风暴（EventStorming）这两个工具，通过工作坊的形式来对业务流程背后的**问题空间**和**解空间**做进一步的分析，识别出关键聚合，再通过跨业务线的**问题域**叠加投影，找出大家共同关注的问题空间和聚合，从而继续扩展来做共性场景和能力识别。
+
+这里我说了很多词，像问题空间、解空间、问题域、聚合，这些都是DDD的常用术语，很好理解。如果你还不熟悉DDD，建议先自己查一查再回来看。当然了，专栏最后的总结部分我也会给你推荐一些相关的学习资料。
+
+<img src="https://static001.geekbang.org/resource/image/8c/4c/8c71eb65099105743e22d107f71c544c.jpeg" alt="">
+
+而整个过程也是采用头脑风暴和工作坊的形式。
+
+<img src="https://static001.geekbang.org/resource/image/c7/15/c7e982898b84d9637584f44408b9ab15.png" alt="">
+
+回到极客地产的例子，大家在一起充分讨论，展开对物业业务线和长租公寓业务线的事件风暴，结合领域驱动设计战略部分的问题域分析以及聚合分析，我们就能知道这两个不同的业务线，有哪些问题空间是重合的，比如客户域或是运营域的部分。
+
+然后再对问题域展开，就能识别到在这些重合的问题空间下，到底有哪些共性的业务数据、业务功能和业务流程，从而完成复用能力的识别。
+
+## 中台与微服务有什么区别和联系?
+
+说完了业务，我们再来谈谈在技术架构设计中，大家最关心也是同样感到困扰的另外一个问题，就是业务中台与微服务架构有什么关系？这也是谈及中台时经常会被问到的问题，至少能排到Top5里，正好讲到技术架构部分，我稍微谈一下我的理解。
+
+先给出我的答案：这俩没关系！
+
+是不是有点反直觉，毕竟这两个概念经常被一起提，很多讲业务中台的书讲到技术架构也都在讲微服务，你怎么说这俩没关系呢？
+
+别急，且听我慢慢道来。
+
+总的来说，业务中台与微服务解决的是不同的问题，也处于不同的抽象层次。
+
+前面提到了业务中台解决的是业务领域的业务（数据、功能、流程）复用的问题，而微服务架构作为一种轻量级分布式技术架构，解决的是技术领域的“组件编译时依赖”造成的问题。
+
+而且业务中台不一定是微服务架构的，微服务架构也不一定是为了解决能力复用的问题。
+
+首先来看业务中台。业务中台要解决的是业务能力如何快速复用的问题，就算背后是一个大单体，只要暴露出来的API能够满足业务能力快速复用的目的也是可以的。这个很容易理解，那我就着重解释一下我对于微服务架构的看法。
+
+提到微服务，不得不说目前被业界普遍接受并采用的我司首席科学家Martin Fowler给微服务下的定义：
+
+<img src="https://static001.geekbang.org/resource/image/d2/6f/d26bada830115ef399d234d332650d6f.png" alt="">
+
+这里边有个关键点，我认为没有引起大家足够的重视，以致于我认为目前市面上绝大多数的号称微服务架构的系统从老马的定义上来看，都是伪微服务架构。这个关键点就是“**能够被独立地部署**”，我认为翻译成“能够被独立地交付”更贴切，而这点也是我认为评判一个微服务架构是否能发挥其价值的关键因素。
+
+这也是我前边提到的“组件编译时依赖”的问题。其实组件化一直是大家都追求的，例如我们常见的jar包和各种开源的组件本身就是很好的组件化封装。微服务从技术上看无非是将组件间的依赖点从“编译时”推后到了“运行时”而已。
+
+不要小看这一点变化，带来的好处是非常多的。因为依赖被推迟到了“运行时”，才可能实现类似于“组件独立交付”、“组件运行时动态扩展”、“组件技术异构”等好处，但同样也需要承担分布式架构带来的复杂度作为代价。
+
+那为什么说大多数的微服务架构都是伪的呢？因为有集成测试或其他因素存在，导致实际上并没有做到真正的独立交付（注意不是部署）。为此我还写过一篇文章《你的微服务敢独立交付么？》，讲的就是如何在不需要集成测试的情况下，利用契约测试的策略设计真正实现微服务的独立交付，充分释放微服务架构的价值，有兴趣的话可以看一看。
+
+<img src="https://static001.geekbang.org/resource/image/dc/a2/dcfed0b2ac6db88625536de50ab85ea2.png" alt="">
+
+还有微服务架构要想真正发挥价值，主要一点就是其中的“服务”要做到足够稳定（说来容易做起来具难）。
+
+所以，业务中台与微服务架构并没有啥直接关系，只是因为微服务架构运行时依赖的低耦合特性，通常被用于实现业务中台中不同能力单元的团队分离、技术分离、交付周期分离等特性而已，只能算是一对好搭档。
+
+## 平台型企业架构设计概览
+
+最后我们还是快速过一遍，一个完整的平台型企业架构的规划过程。
+
+1.首先通过各条业务线的现有业务架构分析，再结合识别的痛点做的根因分析，做业务架构上的改进与设计，从而对于现有的业务架构进行改进，设计出新的改进后的业务架构，解决现在痛点背后的问题。
+
+2.同时还要参考战略分解后对于各条业务线的目标和举措，融入To-Be业务架构的设计当中，使新的业务架构设计同时匹配企业战略要求以及解决短期战术痛点。
+
+3.对于改进后的业务架构，做跨业务线的比对和分析，就能帮助我们发现不同业务线的业务功能及业务流程的重叠情况，为后续中台建设的必要性判断提供业务层面上的支撑和输入。
+
+4.使用领域驱动设计（DDD）的战略部分，针对于每条业务线，做问题域和限界上下文分析，以及关键聚合的识别，从而试图穿越流程，从领域的角度深入一层审视业务的本质，到底是在解决哪些问题空间的问题，并通过问题域的划分（核心、通用、支撑），区分问题空间对于企业的重要性。
+
+5.类似于业务架构，同样对于各条业务线分析出来的领域分析视图，做横向比对和投影，从领域层识别不同的业务线中的问题域、限界上下文以及聚合的重合度。这么可能比较抽象，你可以理解成类似于将几张半透明的画摞在一起，来找相交部分一样。帮助我们识别业务数据以及业务模式（功能+流程）上的深层次共性能力。
+
+6.结合现有的业务架构及应用架构，做各条线的应用架构设计改进，并通过As-is和To-Be的应用架构做Gap分析，产出IT建设的具体机会点，这样的机会点就类似于新建一个CRM系统之类的。
+
+7.再基于跨域的业务架构分析和跨域的领域分析，讨论判断多条业务线的业务重合度，并详细识别重合更多是在业务模式级别的重合（出行、电商）、业务功能级别的重合（登录，购物车）、还是业务领域（用户数据打通）级别的重合。基于讨论结果，决定是否有必要引入中台层建设，以及根据重合情况，详细展开规划中台层的应用架构。
+
+8.最后再分析当前现状与To-Be的最终规划之间的差距，产出具体的机会点列表，并且基于多维度（常见的例如战略重要性、紧急程度、成本、资源就绪情况、技术就绪情况、风险、痛点Mapping等）做优先级排序，产生最终的路线图。
+
+<img src="https://static001.geekbang.org/resource/image/9d/95/9d51971d51ea295b33584c0f72b21e95.jpg" alt="">
+
+## 总结思考
+
+通过本讲与上一讲对于一个完整Discovery和Define过程的讲解，我们就完成了一个从行业和企业战略目标及愿景出发，到最终形成基于中台的企业级架构的完整过程。当然这个过程要比文字描述的复杂得多，不过通过讲述，希望你能建立一个平台型企业级架构梳理的全貌。
+
+看到此时，你可能会问，我只是想做个中台，需要搞这么麻烦的战略规划吗？
+
+我的回答非常肯定：**非常必要**。
+
+因为从我经历的很多实际的中台建设案例来看，很多都是因为缺少了这样一个Discovery和Define的过程，导致中台的建设目标非常模糊，只有一些高大上的口号，并没有想清楚到底需不需要建设中台，以及中台建设到底对于企业代表着什么。
+
+还有些情况，当我们最后收敛后，发现虽然中台建设的必要性是存在的，但是对于当前企业和行业的现状，并不是优先级最高的事情，或是并不具备相关条件，这个时候贸然开展中台建设也是非常危险的。
+
+只有到这里，通过Discovery和Define的分析，得出我们确实需要一个业务中台，并且优先级也非常高，那接下来如何建设业务中台呢？下一讲我继续为你带来第二层的发散（Design）与收敛（Delivery）。
+
+最后给你留几个思考题：
+
+<li>
+你之前听说、了解或使用过企业架构方法吗？
+</li>
+<li>
+你有使用企业架构的方法来做中台的整体规划吗？
+</li>
+<li>
+在企业级的中台规划层面你有什么问题和经验可以分享吗？
+</li>
+
+欢迎在留言区发表你的观点，也欢迎你把今天的内容分享给身边的朋友，我们下一讲见！
+
+

极客时间专栏/说透中台/落地篇/08 | 中台落地第三步：中台的规划与设计（Design）.md

@@ -0,0 +1,187 @@
+<audio id="audio" title="08 | 中台落地第三步：中台的规划与设计（Design）" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/65/74/6592da8d7e1dc6f14785c27ee048d674.mp3"></audio>
+
+你好，我是王健。
+
+前两讲我们通过Discovery结合Define，完成了D4模型中的第一轮在企业级别的发散和收敛。我们站在企业的高度，基于企业愿景和内外部环境，通过自上而下的战略分解和自下而上的现状调研，再应用企业架构方法的分析，来确定最终的平台型企业架构，并回答到底要不要建中台、需要哪些种类的中台建设、谁先建、谁后建这些问题。
+
+那从这一讲开始，我们就要进入D4模型的第二轮发散和收敛。站在一个中台产品的视角，来看看到底应该怎样对其设计并落地实施，也就是D4中的Design和Delivery的两个阶段。同样，本讲先从Design开始，我们以一个业务中台的设计和实施为样本，讲述一下这个阶段的思路和关键点。
+
+好了，这时候还需要借用一下极客地产的例子。
+
+我们假设，经过了第一轮企业级的的调研与架构设计，小王及其团队发现确实迫切需要构建一个极客地产自己的业务中台，来实现企业2022年的战略目标，也就是从重资产业务为主向轻资产的服务业务为主转型，更好地为极客地产的用户群体，即IT从业人员提供多场景服务。
+
+那下一个问题就来了，这个业务中台该如何构建呢？业务中台的搭建又需要从何开始呢？
+
+这节课我们就一起探讨下中台部分的具体设计和启动问题。在当前的这个例子，就是对于极客地产的业务中台（后续简称极客中台）的设计过程。
+
+在设计阶段，我们需要回答的问题就是极客中台的愿景是什么？包含哪些内容？从哪儿开始落地？完成设计阶段，应该就能清晰地知道如何开始进行中台建设，可以让团队开始中台MVP的开发工作了。如果对于什么是MVP不太清楚，不用担心，后续会介绍到。
+
+<img src="https://static001.geekbang.org/resource/image/3e/96/3ea5329ad50cd68abfdc26ccadb31996.jpeg" alt="">
+
+## 确定中台产品愿景
+
+讲到现在，你肯定知道了，第一步还是要先搞清楚这个业务中台的愿景和目标，因为这是我们整个中台建设过程的基础，也是中台建设的初心。
+
+还记得我们之前提到过的么，中台的建设就是一条布满荆棘之路，充满曲折。在过程中我们会遇到各种各样的问题与选择。而一个好的中台愿景能让我们始终保持初心，不轻易迷失方向。
+
+那如何来为中台制定一个好的愿景呢？我一般到一个企业去做中台相关的咨询时，我问对方中台建设负责人的第一个问题都是：你们说要做中台，那中台建设的愿景是什么？
+
+我得到的大多数都是肯定的回答，毕竟没有谁会承认自己的项目连个目标和愿景都没有。但是一旦追问到愿景具体是什么的时候，一般就会开始一段漫长的讲述，从公司的历史到现状、从行业聊到企业管理层最近的讲话，总之我总结下来就是：领导说要做中台，我们做就是了。
+
+我认为这样是比较危险的。毕竟我们前面提到过，中台的愿景作为所有问题的出发点，需要足够简单明确，才能做到像一个指南针一样，成为我们中台建设过程中指引方向的工具，也才能做到前面提到过的“遇事不决看愿景”。
+
+这里推荐给你一个简单好用的工具，我们经常用这个工具来帮我们发散和收敛产品的愿景，当然对于中台也是同样适用的，就是**电梯演讲**（Elevator Pitch）。
+
+顾名思义，电梯演讲假设的场景，就是我们在电梯上偶遇公司管理层，能否在有限的时间内给对方讲清楚我们在做的事情，比如中台。这就要求我们做到足够的收敛。因此电梯演讲的形式，主要是限定了几个产品最关键因素，比如用户是谁，解决什么问题，差异化特点是什么等等。其中每一个要素都非常重要，如果你回答不出来，或是团队的回答不一样，就在一定程度上体现出大家对于中台建设的愿景还没有达成一致，也就为后续各种问题的出现埋下了祸根。
+
+你不要小看这么一个小小的电梯演讲，感觉只要回答几个问题就可以了。从我实际的经验来看，每次规划中台产品愿景的讨论都会超时，一开始觉得可能这么简单的事情，一个小时就能搞定了，后来因为讨论过于激烈，时间拓展到半天时间，到现在我们一般都会预留半天甚至是一整天的时间，来做中台产品愿景的充分发散和收敛。
+
+但即使我们花了这么多的时间，我仍然认为这是十分有必要的。在愿景的讨论上花再多的时间也是值得的，因为这会影响我们中台设计与建设的后续走向，一旦形成，也就会成为我们中台建设的基础，这一步的重要性怎么渲染也不为过。
+
+这里有一个问题，还是要提一下，**愿景的价值和难点就在于充分收敛**。但我见过很多企业的愿景虽然也用了电梯演讲的方式，但是结果满满地铺了一面墙，看着虽然震撼，但是其实效果是大打折扣的，毕竟我们也没法在一个电梯时间复述完一整面墙的内容。还是那句话，做加法易，做减法难。
+
+<img src="https://static001.geekbang.org/resource/image/69/26/6981179d4364844f8bb0987f375cd826.png" alt="">
+
+## 确定业务梳理范围
+
+中台产品的愿景确定后，下一步就需要进行细粒度的业务架构梳理，抽取共性，识别中台产品的具体需求了。
+
+但是，同样是企业级的原因，此时我们面对的问题往往就是不知道该从哪里下手。毕竟中台有企业级属性，就算是业务梳理也会涉及到企业的全业务线，而且是端到端全流程的梳理工作，工作量之大也往往让人望而却步。
+
+<img src="https://static001.geekbang.org/resource/image/0c/d8/0c0bebb1e31e240c0446df0547a25ad8.jpeg" alt="">
+
+是不是所有的业务线都要梳理？是不是端到端的所有阶段都要梳理？业务梳理要到什么样的粒度？这些都是经常面对的问题。
+
+一般到这里，不同企业的情况就不一样了。如果公司整体规模不是特别大，其实做全业务端到端的业务梳理也是可以的，而这样的好处也是比较全面不容易出现遗漏，对于企业的业务现状能有一个整体的全貌，识别的中台共性需求也会比较准确。
+
+但是很多企业，尤其是中台诉求最高的往往是一些多业务线的大型集团型企业。对于这种规模的企业，做全业务的端到端梳理基本上是不可能的，要不然仅仅是协调人员就是一个麻烦的问题。这时候我们就需要先确定一个范围，再在这个范围内进行业务的梳理和展开。
+
+那这个范围该如何划定呢？还是那句，遇事不决看愿景，这时候我们前面讨论的中台愿景就有用武之地了。
+
+还用极客地产为例，中台建设的愿景是希望通过将成熟业务的能力进行沉淀，并复用到其他新型的轻资产业务线例如长租公寓业务中，通过能力的复用快速实现业务的轻量化转型（具体的电梯演讲这里就不展开了）。
+
+而目前的情况是，极客地产专注于服务IT群体，地产和物业业务发展成熟，有了非常健全的IT基础设施。现在针对这一人群挖掘出了很强的长租公寓需求，但是长租公寓作为新的业务线，无论是从投资拓展、设计、招标采购、工程建设、装修改造、客户管理到物业运营等等，这些方面都是从零开始。
+
+回到业务梳理范围的问题上，有了清晰的愿景，就可以让我们的业务梳理更加聚焦。
+
+首先从业务线上来看，就不一定所有的业务线都需要梳理。还是看极客地产这个例子，旗下涉猎广泛，还有业务线专注在投资、文化和教育等方面，因为这些业务线都是长期独立发展，与前面提到的极客地产中台产品的愿景目标也没有太大的直接关系，所以可以先直接跳过。
+
+然后就是从端到端的业务价值链上。通过分析，由于企业的战略是轻资产服务化，所以对于像地产行业的工程建设，也就是盖楼盖房的部分，与企业基于轻资产战略投注的新业务都不适用，所以也不需要再进行梳理。
+
+至此，基于中台的建设愿景，我们就可以在横向端到端价值链和纵向的业务线上收敛到一个聚焦的区域。
+
+再在这个聚焦的区域中进行业务梳理和展开，就会更加有效率和聚焦。
+
+<img src="https://static001.geekbang.org/resource/image/6a/c4/6a4ed7864f1bd56d5e6d02e00b4851c4.png" alt="">
+
+## 细粒度业务梳理
+
+在确定了梳理范围之后，接下来就是具体的业务梳理工作了。
+
+一般大家的做法都是基于现有的流程或系统，对现有业务的流程进行梳理，例如在电子商务领域大家经常提到的四流，具体指的是信息流、商流、资金流、物流的梳理工作，使用的工具也大多是**流程图**这种非常成熟的工具。
+
+但是这种基于已有流程的梳理有时候会有一些限制，简单讲就是可能会基于过去遗留的业务债推导出伪中台需求。什么意思呢？就是对于一些长期且成熟的业务，现有的业务方式可能并不是一个最好的方式，而是由于长时间发展以及和过去的各种周边限制以及IT限制妥协的产物。
+
+举个例子，往往时间比较长的业务线都会有非常复杂的审批审核流程。但是审核和审批流程其实只是一种解决方案，要解决的问题可能是过程造假或是其他的一些内部风险和问题。复杂的审批流程也往往是信息化时代甚至是更早的纸质时代的过程管控的产物，由于信息化更多只是将线下的流程线上化，所以一直延续至今，而且为了高度复刻还原纸质时代的流程，还非常中国特色地出现了各种的奇怪的审批逻辑，例如会签等等。
+
+<img src="https://static001.geekbang.org/resource/image/15/16/15592b4bc1f1d373ca82995aa6c7cb16.jpeg" alt="">
+
+但是如果我们重新回到问题域，重新思考问题本身，我们就发现可能在当今这个数字化的时代，在大数据和AI已经广泛应用的今天，甚至可能不再需要流程审批这样一个过程。通过新的技术，我们可以用实时的审计分析或是风险识别来发现业务过程中的一些异常，甚至通过完全的自动化，消除中间人员参与的环节，从根本上解决这些问题，从而真正发挥数字化的威力。
+
+<img src="https://static001.geekbang.org/resource/image/8f/d3/8f50128f984d74d884e4db9c4a5d01d3.jpeg" alt="">
+
+这种回到问题域本身，回到问题的原点，基于用户需求在当前的业务及技术条件下，重新设计解决方案的思维方法，可以避开上面提到的业务债陷阱，也多用于创新型业务的设计过程，而这种思维方式也大量参考和借鉴了**设计思维**（Design Thinking）的方法。
+
+所以和基于现状的传统业务流程梳理不同，我们在业务梳理过程中大量地采用了基于**设计思维**，结合**用户体验地图**（User Journey Map）和**服务蓝图**（Service Map）的方式。回到业务本身，从问题域出发，以用户为中心，进行用户体验设计和业务服务蓝图的梳理，从效果上来看也是非常不错的。
+
+<img src="https://static001.geekbang.org/resource/image/84/dd/845e745812f67622748606332a5f80dd.jpeg" alt="">
+
+当然不是说哪种方法更好，不同的工具和方法有不同的适用场景和优劣势，如果都能灵活掌握，甚至可以结合使用，充分发挥出各自的优势。
+
+通过范围内的业务架构梳理，再结合最后的跨场景通用能力的分析，我们就可以对关注领域的业务全貌有了一定深入的了解，并且可以识别出不同业务线中一些可复用的业务数据、业务功能与业务流程。而这些通用的业务数据、业务功能、业务流程经过加工分析就形成了中台的具体需求。对于这些需求，我们是通过**用户故事**（User Story）的方式描述的。
+
+<img src="https://static001.geekbang.org/resource/image/ef/df/ef05adf4c6f819ad8f1484471c8515df.jpeg" alt="">
+
+## 确定MVP
+
+通过业务梳理，我们识别和整理了大量的业务中台需求。值得注意的是，此时的所谓中台产品需求，更多的是来源于定性抽象，再考虑到中台的需求往往不像前台业务系统的需求那样明确，所以，从严格意义上来讲，此时的需求仍属于一系列高风险的假设。
+
+从我实际参与的中台建设项目来看，往往这些一开始设想的中台需求，到真正开发完成之后，都与最初的设想有很大的偏差。这就意味着，中台建设的周期越长，需求假设的风险和需要为之付出的代价就越大。
+
+所以，我们在中台的建设过程中，引入了精益创业中的**MVP原则**（Minimum Viable Product，最小可用品），也实现了我之前提到的整体原则中的Start Small。
+
+为了实现MVP，保证做出来的MVP可用，我们在业务需求上采用端到端纵向切分的方式，结合需求优先级的多维度评分排序，最终确定MVP的需求范围，而最终落地的形式可能就是第一个迭代的用户故事列表。
+
+<img src="https://static001.geekbang.org/resource/image/50/17/5078b8d84d2ddd763086d3a0a6819a17.jpeg" alt="">
+
+那已经有了具体的用户故事列表，是不是我们就可以开始着手开发了呢。先别急，有两个事情，我们建议在开始中台建设之前就需要考虑，那就是运营计划和度量指标。
+
+## 运营前置：制定迭代计划及接入计划
+
+首先我们来看看运营计划。对于中台可能就是中台产品推广、前台（用户）接入计划以及接入后的运营支持。
+
+我过去看到的情况是，中台建设的中后期才开始考虑这些问题，往往就有些晚了。而且很多情况下，前台是不会停下来等中台建设完，等接入后再开始自己的业务演进，所以往往都是前中台并行。
+
+这个过程就很像是我们开发中的分支开发一样，修改的又是同一块内容，所以当合并的时候就会非常痛苦。
+
+所以提前考量运营计划尤其是接入计划，尽量使用合理的接入计划（我看到有很多企业把这个接入计划叫作上车计划，非常形象）来规避一些风险，对于中台产品的建设也非常关键。具体的运营策略，在下一篇中讲为你展开介绍。
+
+<img src="https://static001.geekbang.org/resource/image/a0/1b/a0ff9f1ab999ce681327bda4adb0b01b.jpeg" alt="">
+
+## 度量前置：定义验证指标
+
+另一个需要在中台产品建设开始之前就要想清楚的就是度量指标。这一点，不知道你是否还记得，我们在之前讲中台建设前需要想清楚的四个问题时，已经讲到过了。具体为什么需要将度量指标设计前置到开发之前，之前已经阐述过了，在这里我就为你分享一些度量指标的设计思路。
+
+首先，我们先来看看一般我们常用的有哪些指标。我把市面上最常见到的产品度量指标，分为了四个大类，也就是战略类、用户类、市场拓展类与降本提效类。基于每一个维度展开，都能找到很多的常用度量指标。
+
+<img src="https://static001.geekbang.org/resource/image/22/43/22771d9d06434a8f289387b701397643.jpeg" alt="">
+
+而对于中台来讲，难就难在与市场和用户之间还隔着一层前台，所以在度量上就不如直接接触用户的前台系统这么清晰。但是我们讲中台是为前台业务赋能的，又不能脱离开业务，单纯只在技术上做一些度量，例如接口稳定性和接口数量等，这样也不符合中台对于业务支撑赋能的定位和价值。
+
+所以我们一般在考虑中台的度量指标的时候，还是把战略价值和业务价值作为出发点，开始拆解和推导，并且按照干系人关注点的不同，用多维度、多层次的指标设计来审视中台建设的效果。这里要强调一下，虽然维度和视角不同，我们要保证所有指标体现的中台建设目标必须是一个。
+
+<img src="https://static001.geekbang.org/resource/image/ae/11/ae40951f0b750773536ae307085c8f11.jpeg" alt="">
+
+而具体到实施方法，因为每一个中台产品都是不一样的，所以很难给一个标准的答案。在实操过程中，建议你多换位思考，多问几个“怎么（How）”。相信你比较熟悉5Why分析法，这里我们可以稍微改一下，用**5How**来驱动验证指标的设计。
+
+举个例子，如果我站公司管理层的视角：
+
+<li>
+那我怎么判断中台建设的成果？如果回答是看对于新业务的赋能，
+</li>
+<li>
+那我怎么验证对于新业务的赋能效果？如果回答是看新业务的上线速度，
+</li>
+<li>
+那我怎么验证新业务的上线速度？如果回答是看新业务从立项到上线的时间，
+</li>
+<li>
+那我怎么验证……
+</li>
+
+你看，大家经常会说度量比较难，其实每个人心里都有一杆秤，只不过我们没有把这个秤清晰地表达出来。通过5How，我们可以不断追问，将每个人心中的这杆秤发掘出来，来更好地指导我们中台产品的建设和推进。
+
+## 总结思考
+
+本节课以一个业务中台的建设过程为例，以业务中台的愿景作为切入点，介绍了电梯演讲的工具，再基于中台建设愿景，明确业务梳理的范围和优先级。
+
+明确了业务梳理的切入点和范围之后，我们就可以基于设计思维进行以用户为中心的业务流程梳理和服务设计了，再结合领域驱动设计进行业务模型梳理，最终再通过跨业务线的综合分析，识别共性业务数据、业务流程、业务模式的中台需求。
+
+之后通过引入精益创业中的MVP原则，对于中台需求基于业务优先级采用端到端纵向切分的方式，最终确定中台建设的启动点，也就是第一阶段的具体建设内容。
+
+最后有了中台产品运营机制和度量指标的分析与设计之后，我们就可以正式地立项并进入到交付阶段具体实施了。
+
+那下一讲我我们就正式进入到D4的最后一个阶段，也就是Delivery的交付阶段，看看我们在交付阶段使用的思路和方法，以及要注意的问题。
+
+最后给你留几个思考题：
+
+<li>
+你们的业务梳理过程是怎么样的？中台需求是怎么分析出来的？
+</li>
+<li>
+你们采用了MVP原则了吗？是如何规避中台建设的需求假设风险的？
+</li>
+
+请在留言区写下你的思考，和我一起讨论，也欢迎你把今天的内容分享给身边的朋友，和他一起学习，我们下一讲见！
+
+

极客时间专栏/说透中台/落地篇/09 | 中台落地第四步：中台的建设与接入（Delivery）.md

@@ -0,0 +1,96 @@
+<audio id="audio" title="09 | 中台落地第四步：中台的建设与接入（Delivery）" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/a0/d0/a0ba28305bb2b5edf6f9823f867432d0.mp3"></audio>
+
+你好，我是王健。
+
+通过上一节课介绍的内容，我们最终拿到了一个作为切入点的中台场景，并且通过业务梳理识别出对于数据、流程、功能的复用需求，并结合MVP原则，找到第一个快速验证的需求集，结合前台的接入条件，形成了第一个小的中台建设冲刺计划，并以终为始，在开始前确定好中台建设的验证指标，有了需求、计划、验收条件。
+
+如果能够顺利通过企业内部的立项审核和流程，那么恭喜你，你已经有了第一个正式的中台项目。
+
+接下来就进入了D4的第四个阶段，也就是最后一个但可能也是时间最长的交付阶段了。
+
+而交付的第一步一定是要组建一支有战斗力的队伍，中台的建设需要的能力与传统产品还是有比较大的差别。给你分享一个孙志岗老师的**中台人员能力模型**，我认为非常有启发，希望也能帮助你理解中台对于团队能力的要求。这个模型孙老师写过一篇文章，文章中还提到了中台建设过程中一些难点，我会把文章统一放到最后一篇总结中作为扩展阅读推荐给你。
+
+模型中的“爱多思”指的是网易教育中台。
+
+<img src="https://static001.geekbang.org/resource/image/b6/05/b65c322f9cfa44414e295c3fb0eac205.png" alt="">
+
+当组建了一支成型的中台建设团队之后，其实后续的建设工作就和我们一般的项目或产品的建设过程类似了。但是因为中台所处的特殊位置，对产品界定要求和对建模的难度，都比其他终端产品的复杂度要高一个级别，所以我们建议采用**精益的产品研发流程**，保持小步迭代、快速建设、快速度量、快速反馈、快速调整的流程，保证中台建设是一个持续演进和被业务驱动的过程。
+
+## 精益产品研发流程
+
+这里叫精益产品研发流程，主要是面对中台建设过程中的不确定性，引入精益思想来实现价值的定义和快速流动及度量，再结合敏捷开发实践，让整个软件开发过程轻量、迅速、敏捷、价值驱动。
+
+精益这个词相信你应该并不陌生，上一讲我们讲到的MVP就来自于精益创业。市面上大家还经常提到精益软件开发、精益生产制造等等，本质上都是将精益思想作用于某一个垂直领域的成果。
+
+精益思想之所以流行，关键在于其定义了一套完整的思想框架，而最终核心目标就是消除浪费、创造价值。在中台的实际建设过程中，我们也建议引入精益思想，结合到软件的开发过程中，小批量快速开发产品，快速引入度量，基于测量的数据快速对于之前的需求假设进行验证和认知，并基于此做快速的调整。
+
+这里你可能会有个疑问，敏捷和精益到底有什么区别？
+
+其实精益和敏捷现在确实是常常掺在一起来讲的，我发现很多时候大家并没有搞清楚两者的区别。简单来讲，**敏捷关注的是价值确定的情况下，如何通过小步快跑的迭代方式按节奏交付价值；而精益关注的则是在价值并不确定的情况下，如何用最小成本，快速定位到真正价值点**。
+
+我们发现，由于中台建设的复杂度非常高，所以将精益思想结合敏捷思想应用到中台的建设和开发过程，再配合后边马上会谈到的中台运营机制的建立，可以让我们更好地应对中台建设过程中的各种问题，例如最经典的中台边界界定问题。
+
+至于我们具体的做法，你可以参考下图，其中涉及的工具和实践都是比较成熟了，这里就不做展开了。其中最主要的就是通过数据运营，也就是基于度量指标的持续验证，来对之前做的需求价值假设做快速验证，并且不断调整，在精益思想中就叫尽善尽美。而团队要做的就是不断地加速这个反馈环路的运转速度。速度越快，我们应对不确定性的能力就越强，交付中台产品价值的能力也就越强。
+
+<img src="https://static001.geekbang.org/resource/image/ef/ef/ef22647effaea3b61826905ea8f394ef.png" alt="">
+
+当然整个过程是一个复杂的系统性工程，一般都会涉及到像云化工程，微服务及服务化能力构建，Devops相关能力构建，数据运营能力构建，敏捷精益过程改进，遗留系统服务化改造，架构守护与演进，以及与中台相关的治理与运营架构构建等工程。
+
+## 中台的运营、治理与演进
+
+除了中台的建设过程，同样不能忽视的就是对于中台建设过程中的持续治理及演进，以及真正接入了前台之后对于中台的运营管理。
+
+目前市面上我们碰到的很多中台建设过程中的困难和问题，在我看来都是没有做好中台的治理与运营导致的。对于中台的整体治理和运营机制，目前业界的理解也不太一致，毕竟中台作为一个企业的平台类产品，服务的不是企业的最终用户，所以和互联网里经常提到的基于产品的用户侧运营还不太一样，中台在位置上更像是企业内部的一个服务企业前台应用的ToB产品。
+
+而对于企业内部的toB平台类产品如何做运营，也是目前业界比较关注的点。今天我就讲几点我认为比较关键的部分，注意这几个问题，能让我们在中台建设过程中少走一些弯路，少遇到一些坑。
+
+而第一步要搞清楚的，就是**中台产品的用户划分**。
+
+看到这里相信你肯定会疑惑，中台作为企业内部的平台类产品，所有的前台都应该是中台的潜在用户，尤其又都是自己企业内部的兄弟部门，为什么还要为前台用户做划分呢？
+
+这就是有意思的地方，也是我在过去中台建设过程中吸取的教训。一开始我们在中台建设过程中，也并没有对于前台做任何划分，一视同仁、平等对待。
+
+但是中台作为一个公共服务部门，一定会碰到多个前台的需求、排期、质量要求、非功能需求出现不同的情况，甚至也会经常出现多个前台之间的需求或是非功能性需求彼此矛盾的时候。而中台的资源有限，且有自己的愿景，不可能无条件地满足所有前台用户的诉求，往往就会陷入疲于应对的状态，对前台的响应和服务质量也会急速降低。
+
+怎么办呢？问题的根本在于，虽然我们说中台是企业级能力复用平台，但我们经常会忽略的一点就是，如果我们采用产品化的思维来构建中台，那中台中所沉淀的能力并不是产品的全部，还需要再加上NFR（非功能性需求）或是我们常说SLA（Service-Level Agreement，服务等级协议）才是产品，因为不同的前台用户之间，不只是对于中台产品的功能本身有着不同的诉求，同样对于NFR或是SLA也有着不同的诉求。简单举个例子，比如核心业务对于中台的SLA稳定性的要求可能是5个9，性能是5毫秒；而一个新的创新型应用，可能还没有用户，就不需要有这么高的要求。
+
+**Offering = Capability + SLA/NFR**
+
+既然如此，如何利用有限的资源，服务好不同用户的不同诉求呢？答案就是对于前台用户基于需要的能力和NFR/SLA做用户划分。这听起来可能会觉得有些新鲜，但是其实环顾一下我们周围，很多的产品都是这样来处理用户划分，从而实现用户的分层响应与运营的。
+
+而最常见的就是**三层用户划分机制**（3 tiers customer segmentation）。通过对于前台用户的分层，我们就可以为不同层次的用户指定不同的需求响应机制、不同的沟通管理机制、不同的服务质量控制机制、不同的问题处理及升级机制等等。自然不同的服务类型作为前台用户也需要付出不同的成本或是资源（人或钱），甚至前台与中台可以通过签署SLA来实现对于前台用户的服务承诺。
+
+<img src="https://static001.geekbang.org/resource/image/29/5b/2945d8b72e162943c7ed6ad663cef05b.jpg" alt="">
+
+举个例子， 当我们开始中台建设时，可以只找到一个或是两个种子用户，作为Tier1级别的用户来服务。对于这个种子用户的需求作为最高优先级的需求来对待，并建立例行的沟通机制和服务响应机制。因为此时的服务还处于初建时期，还不是特别的成熟，所以可以采用“免费”的方式动用企业的战略资源来进行建设。这样，对于前台用户来讲，资源是免费的，而且是一对一式服务，自然也会乐意配合到中台的建设过程中。
+
+当中台建设到一定阶段之后，对于种子用户的服务已经接近稳定，有了一定的能力沉淀，也能释放出一定的资源了，就可以利用释放出来的资源开始为Tier3层的用户构建自助服务控制台（Self-Service Console），并着手构建中台产品的运营团队，制定Tier3层的NFR/SLA。在很多互联网企业，这个过程常常由于做出来的自助服务控制台比较粗糙，看起来也像是对于平台服务的增强和可用性优化和治理的过程，大多数就是一个白屏幕，加一些的配置选项，所以常被称为“**平台的白屏化**”。
+
+当中台的自助服务控制台创建完成，Tier3层次的SLA也构建完成后，我们就可以重新签订SLA，将之前的Tier1用户迁移到Tier3层次，即完成之前种子用户从定制化服务到自助式服务的迁移过程，从而释放出更多的资源用于接入新的前台用户。
+
+如果由于种种原因，无法一步到位实现服务的完全自助化，还可以通过构建Tier2层的SLA，也可以通过重新签订SLA，将之前的Tier1用户迁移到Tier2层次，通过“自助+VIP服务”的方式，保持对前期种子用户服务连贯性的同时释放出尽可能多的资源。
+
+此时我们就已经有了三层的用户划分机制，可以在企业内更大范围地发布Tier3的自助式服务，通过这种方式实现更多用户的接入。同时，因为已经释放出一些中台的资源，我们就可以继续选取下一个关键的种子用户（一般是关键业务），作为新的Tier1级用户开始第二轮中台建设的推进。
+
+至此，通过中台的用户分层和运营机制，就可以构建不同层次的运营体系，从而实现资源的合理调配。我们也就避开了前面提到的中台建设过程中的各种问题和陷阱，对用户分级运营，从而解决需求矛盾、排期冲突、资源紧张、推广缓慢等问题。
+
+## 总结思考
+
+本次课我们从一个中台项目的启动开始，引入了精益产品研发流程，把精益思想和敏捷实践结合到中台的研发建设过程之中，加快价值流动、快速反馈、快速调整，从而更好地应对中台建设过程中的复杂度和不确定性。
+
+之后我又给你分享了中台建设过程中的运营与治理机制。我并没有深入到运营机制的细节之中，而是从整体思路上，强调了如何对用户进行分层治理，合理调配精力与资源，通过用户的分层SLA机制来实现中台建设的平滑推进以及产品化演进。
+
+所以，最后还是要强调一下，中台建设的过程是一个长期且艰苦的过程，不但需要企业具备技术、业务、组织的基础，还需要做好持续探索和演进的决心、耐心和准备。
+
+最后给你留几个思考题：
+
+<li>
+你所在企业的中台建设过程是什么样的？与文中提到的方法有哪些相同和不同呢？
+</li>
+<li>
+你所在企业的中台运营与治理机制是什么样的？有没有做用户划分？是不是存在文中提到的一些需求排期冲突、资源不够、响应变慢等问题呢？
+</li>
+
+期待你在留言区分享自己的案例和思考，也欢迎你把今天的内容分享给身边的朋友，我们下一讲见！
+
+

极客时间专栏/说透中台/落地篇/10 | 总结：中台落地工具资源汇总.md

@@ -0,0 +1,189 @@
+<audio id="audio" title="10 | 总结：中台落地工具资源汇总" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/f3/be/f30f610908fd3c3a9751cbcbfc07debe.mp3"></audio>
+
+你好，我是王健。感谢你一直陪我走到了这里。
+
+这一路，我们时间穿梭，回到过去，从中台的历史开始，重新审视了一遍中台的诞生与发展之路，又从现在的一片繁华中洞悉中台的本质与其背后的趋势。
+
+之后我还为你分享了我们中台建设方法论的来源、思想、原则与实践，也就是D4模型。一起来复习一下，就是两轮“发散与收敛”，第一轮Discovery和Define，第二轮Design和Delivery，对应中台落地的四个阶段：企业战略分解及现状调研、企业数字化全景规划、中台的规划与设计、中台的建设与接入 。我们以极客地产的例子作为一个引子，带你完整走了一遍一个中台的建设之路。
+
+我知道，关于中台的内容当然远远不止于此，有很多没有讲到的内容，例如数据中台和技术中台，组织准备我们也没有展开。
+
+虽然有些遗憾，但是作为一个小小的专栏，既然叫作“说透中台”，那我们就**以少为多**（Less is more），不求大而全，只为给你还原一个中台的全貌，送你一张相对完整的中台地图。地图中的每个角落，都还有凶险和惊喜，而对于中台实际的探险、具体的历程，也只能待你自己去探索、去发现、去体验。
+
+这就结束了么？我们说透中台了么？我觉得还差一点点，还有一个问题没有回答。
+
+**开头，我们以终为始；最后，我们以始为终。**
+
+重新回到开篇我在思考的那个问题，中台到底是大势所趋还只是昙花一现呢？或者，到现在了，我们可以换个说法，企业架构向平台型演进的趋势，到底是大势所趋还只是昙花一现呢？
+
+再说一遍，我更相信是前者，为什么呢？因为：“**用户**”。
+
+你有没有想过，为什么中台会在互联网成功？传统的企业也有同样的痛点和问题，为什么没有催生出一个成功的中台或是相关概念出来，转而成为互联网的追随者呢？
+
+这里的差别，不在业务，更不在技术，而在于：**你眼里看的到底是谁？！**
+
+互联网企业需要中台，不是锦上添花，而是生存所迫，是因为**恐惧**。因为竞争过于惨烈，谁能抢到用户，谁能获取用户的芳心，谁能留住用户，谁就能干掉别人获得成功。这不是政治需要，也不是技术需要，这是**生存需要**，是一场你死我活的搏杀。所以，互联网企业天生眼里盯着的就是用户，这是为了生存，刻在了基因里的。
+
+而用户，则被“**惯坏了**”，又要求你产品层出不穷，不断迭代更新；还得要经济便宜，不舍得多付出一点成本。
+
+你有没有想过，这两类需求本身就是矛盾的，又要灵活又要经济，企业还没的选择，为了生存也必须无条件地继续满足用户的各种“**无理要求**”。而中台或是说平台型企业架构，我认为也是这样一个用户至上时代企业得以生存和发展的必然产物，为什么呢？
+
+不知道你是否听过，在IT圈有一句老话，“任何软件工程遇到的问题都可以通过增加一个中间层来解决！”。
+
+而在企业层面，中台这个新的中间层的产生，就是为了调和这个“灵活”与“经济”的矛盾。
+
+前台纵向，承载了企业的灵活性；中台横向，承载的是企业的经济性；而前台与中台的分离、博弈与平衡，本质上就是企业作为一个整体灵活性与经济性的分离、博弈与平衡。
+
+而一切的一切，所有的问题，企业为什么要建平台？为什么要建中台？为什么要变成平台型的企业架构？为什么要变成平台型的组织？
+
+归根到底，其实答案一直在那里，在我们身边的墙上，那六个通红的大字：“**以用户为中心**”。而关键就是它最终到底是在墙上、在嘴上，还是在眼里、在心里。
+
+而“**以用户为中心**”这六个字，就是我整个专栏所有问题的最终答案，也是我从开始研究中台到现在最大的收获。如果说所有的工具与套路都是中台的招式的话，那这六个字就是心法。
+
+最后的最后，将这个心法分享与你，希望你也能早日参透其中的奥妙，超越各种表面的招式，做到手中无剑心中有剑。
+
+今天是我们中台课程正文的最后一讲，我为你准备了一个学习资料包，主要是我精选的图书和文章，我都根据内容做了分类。如果你有精力通读这些内容，中台落地相关的思路和方法，你都能有所收获。
+
+具体怎么利用这些资料呢？简单说说我的建议。如果你更关注宏观的企业级战略相关的内容，可以展开阅读战略与变革和平台型组织相关内容；如果关注我们讲到的企业级架构相关的内容，那企业架构相关的内容肯定可以帮到你；如果你更多只是关注一个具体中台的设计与落地实践，那推荐你阅读设计思维、领域驱动设计、敏捷&amp;精益以及架构演进的相关内容。
+
+好了，我们的课程先告一段落，欢迎你继续分享自己的思考与收获，或者说一说自己遇到的问题和困惑，我会一直在这里，期待和你在答疑篇再见面！
+
+## 荐书
+
+**1.中台概念**
+
+- 《企业IT架构转型之道 阿里巴巴中台战略思想与架构实战》
+- 《中台战略：中台建设与数字商业》
+
+**2.战略与变革**
+
+- 《论大战略》
+- 《战略的本质》
+- 《领导变革》
+- 《商业模式新生代》
+- 《系统思考》
+
+**3.平台型组织**
+
+- 《释放潜能：平台型组织的进化路线图》
+- 《重塑海尔：可复制的组织进化路径》
+- 《赋能：打造应对不确定性的敏捷团队》
+
+**4.企业架构方法**
+
+- 《TOGAF标准9.1版》
+- 《企业级业务架构设计：方法论与实践》
+- 《决胜B端：产品经理升级之路》
+
+**5.设计思维**（DesignThinking）
+
+- 《战略设计思维》
+- 《创新设计思维》
+
+**6.领域驱动设计**
+
+- 《领域驱动设计：软件核心复杂性应对之道》
+- 《实现领域驱动设计》
+- 《领域驱动设计模式、原理与实践》
+
+**7.敏捷&amp;精益**
+
+- 《精益思想》
+- 《精益创业》
+- 《精益企业：高效能组织如何规模化创新》
+- 《看板方法：科技企业渐进变革成功之道》
+- 《持续交付：发布可靠软件的系统方法》
+
+**8.架构演进**
+
+- 《演进式架构》
+- 《架构整洁之道》
+- 《微服务设计》
+
+## 荐文
+
+**1.中台概念**
+
+<li>
+[对话阿里云总裁行癫：最详解密阿里云顶层设计和底层逻辑](https://mp.weixin.qq.com/s/tmVt26x9Ejvkz6EFL9tQlg)
+</li>
+<li>
+[湖畔大学阿里CEO张勇：找人的核心，就看2点](https://mp.weixin.qq.com/s/LB-twf6v0Xv5QFW2a09q5w)
+</li>
+<li>
+[什么是中台，什么不是中台。所有的中台都是业务中台](https://mp.weixin.qq.com/s?__biz=MzIwNjg0NjU4OQ==&amp;mid=2247483675&amp;idx=1&amp;sn=1160f90ab8ebfa9aea841aa1adba1de8&amp;chksm=971a2e09a06da71ff0bcf319e5d139dfdfdc50eae8832a42b721f82f079d58d4fc8db198c480&amp;scene=21#wechat_redirect)
+</li>
+<li>
+[到底啥是平台，到底啥是中台？李鬼太多，不得不说](https://mp.weixin.qq.com/s/-2LrJ_s4djXo542BrIy70A)
+</li>
+<li>
+[平台战略==中台战略？](https://www.jianshu.com/p/799a8205572b)
+</li>
+<li>
+[在构建数据中台之前，你需要知道的几个趋势](https://mp.weixin.qq.com/s/OD4MSmAjVUqFKItfJMdfKA)
+</li>
+<li>
+[火热的数据中台对企业的价值是什么？](https://mp.weixin.qq.com/s/a_sJa8I8kefvq8KsTqenqg)
+</li>
+<li>
+[你真地需要一个中台……吗？| 商业洞见](https://mp.weixin.qq.com/s/LZ6RVz-XkdhcCYyVjG9RHw)
+</li>
+<li>
+[阿里的中台战略其实是个伪命题](https://mp.weixin.qq.com/s/R15Iys1v79y_rmkvsbVkAA) （从企业架构看中台）
+</li>
+
+**2.中台与组织**
+
+<li>
+[白话中台战略-4：Platform as a Product(组织篇)](https://mp.weixin.qq.com/s/DxjRze7GmtIpOrC1FxdWAQ)
+</li>
+<li>
+[中台禁区：为什么最关键的组织架构却鲜少人谈？](https://mp.weixin.qq.com/s?__biz=MjM5MDE0Mjc4MA==&amp;mid=2651018922&amp;idx=1&amp;sn=26ac29a28433ce64f65a7675ddc0b546&amp;chksm=bdbeaef98ac927efce317a5bae726db2c847eab77c8ccffe0f38ea1f246aaa12aa4674d3bff7#rd)
+</li>
+
+**3.建设经验**
+
+<li>
+[从平台到中台 | Elasticsearch 在蚂蚁金服的实践经验](https://mp.weixin.qq.com/s/Dob6Kjm6v7gE4o7B1HhqLA) （平台与中台）
+</li>
+<li>
+[滴滴出行构建业务中台应对软件复杂度的具体对策与实践](http://developer.51cto.com/art/201712/559758.htm)
+</li>
+<li>
+[七问七答，亲历者讲阿里中台落地的实践](https://mp.weixin.qq.com/s?__biz=MzI3NTI5NDk4NA==&amp;mid=2247483773&amp;idx=1&amp;sn=c0e1448c02b0ce4bd36e2f02a8dbb37c&amp;chksm=eb07bf1adc70360c0cc81eb96d1c6705986b47a41e38d210aac2988b823a6a88b326db0a20e3#rd)
+</li>
+<li>
+[我的一年中台实战录](https://mp.weixin.qq.com/s/hvrPMvn6pyvD88eRUwwGkg) （网易教育中台实战录）
+</li>
+<li>
+[跳开 DDD 和中台概念看阿里巴巴交易平台的问题及解决思路](https://mp.weixin.qq.com/s/4IAOCNNb2bRbOgMSI0Yx2Q)
+</li>
+<li>
+[阿里玄难：面向不确定性的软件设计几点思考](https://mp.weixin.qq.com/s/Uc_wJSVQr7sSz2js2pb3OA)
+</li>
+<li>
+[不要做中台！不要做！不要……要](https://mp.weixin.qq.com/s/IbIqWrhVXltLMpuDjWzdJA) （中台人员能力模型）
+</li>
+
+**4.方法论相关**
+
+<li>
+[谈谈企业的规模化创新](http://insights.thoughtworkers.org/enterprise-innovation/)
+</li>
+<li>
+[以愿景与目标驱动，让创新无处不在](http://insights.thoughtworkers.org/lean-value-tree/) （精益价值树）
+</li>
+<li>
+[当用户不是客户，需求价值怎么定？| 商业洞见](https://mp.weixin.qq.com/s/EhpeuNWePP23n9CxFo3yjg) （用户与客户）
+</li>
+<li>
+[架构设计实践思路：什么是架构，怎么画架构图？](https://mp.weixin.qq.com/s/eGNbRFKAli35CJu4aYN_4w)（企业架构展开解释）
+</li>
+<li>
+[Microservices Guide](https://martinfowler.com/microservices/) （微服务）
+</li>
+<li>
+[EventStorming](https://www.eventstorming.com/) （事件风暴）
+</li>
+
+[<img src="https://static001.geekbang.org/resource/image/d8/43/d834f97239685a2ed99b8ec3b7570043.jpg" alt="">](https://jinshuju.net/f/OfdES4)