mod

极客时间专栏/说透中台/开篇词/开篇词 | 中台，昙花一现还是下一个风口？.md

@@ -0,0 +1,80 @@
+<audio id="audio" title="开篇词 | 中台，昙花一现还是下一个风口？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/31/5a/31d206e6ef4904dab834c21790e7745a.mp3"></audio>
+
+你好，我是王健，是ThoughtWorks的首席咨询师，目前专注在企业架构和解决方案的相关方向上。因为近几年沉迷中台无法自拔，同事朋友们也给我起了个花名，叫“台长”，如果你乐意也可以这么叫我，很高兴能在这个专栏与你见面。
+
+## 我与中台
+
+与中台的第一次邂逅是在2017年，当时作为首席咨询师和系统架构师第一次实际参与到了一个大型企业的中台规划和落地项目中。作为一个已经在行业里摸爬滚打了10多年的老鸟，并且无论是在分布式系统架构、微服务架构、平台化建设方面都也有了非常多年的经验和积累，面对“中台”这样一个当时在我看来不过是新瓶装旧酒的概念，坦白来讲，一开始我并没有把它放在眼里。
+
+但结果就是被啪啪打脸。整个过程推进得非常困难，从头到尾无论是我对于中台的理解还是我们规划与建设的方法都受到了客户不断的质疑和挑战，项目的范围无论从系统的层面还是从组织的层面也被扩大到几近失控。
+
+但也就是这次过程，才让我开始意识到，中台这个概念跟我之前想象的可能完全不是同一个物种。也自此，我对中台产生了浓厚的兴趣，日思夜想，遍访高人，并将所学所思所想落笔成文，期望与更多人一起探讨。
+
+截止目前，我主导或参与过的中台相关项目大大小小也有10多个了，很多疑问和困扰也在这个不断学习、思考与实践的过程中一一解开。同时今年也开始与公司和社区的小伙伴们一起，尝试沉淀一套通用的中台规划与建设方法，来帮助更多企业在中台的规划与建设过程中，少走一些我们走过的弯路。
+
+## 关于专栏
+
+虽然我对于中台非常痴迷，但当极客时间约我做中台的专栏时，我的心情还是非常复杂的。
+
+首先肯定是非常开心，因为很希望能借助这样一个平台将自己的所想所得分享给更多的人，并且更希望能听到你的观点，你的意见和你对于中台有哪些问题。我们一起努力将这个概念或是工具理解得更加透彻，并最终利用它帮助我们解决实际的问题。
+
+但同时也有一些惶恐，因为中台这个概念不像其他的技术那样成熟和清晰。业界对于这个概念本身也仍然没有一个统一的认识。我相信，这也是今天中台被大家热议的一个原因吧，大家都在关注，但是又很难讲清楚。
+
+还有中台这个概念，无论是从涉及领域的宽度还是从战略到落地的纵深高度来讲，都是非常非常大的，向上可以触及到行业趋势、企业使命愿景战略，向下又可以落地到分布式架构、遗留系统重构、架构演进与守护、质量保证等等各个方面。而且就算是同一个行业，每家企业还都不一样。
+
+想要通过一个专栏，既要把概念讲清楚，又不飘在天上，还可以指导和帮助大家将中台落地，在我看来这几乎是一个不可能完成的任务。
+
+但幸运的是，在极客时间同学专业的支持，以及不断激（催）励（稿）下，经过不断的打磨，这个专栏最终还是跟你见面了，感谢的话留到最后再讲，我先来简单讲讲我是怎么设计这门课程的。
+
+## 这门课是怎么设计的？
+
+今年IT圈中台的概念确实比较火，你可能在朋友圈或是各个媒体渠道上天天都能看到跟中台相关的文章和资讯。
+
+但是大家讲的很多都是各个企业中台建设的结果，一张大大的线框图，对企业带来了怎样怎样的好处。
+
+但中台到底是什么？从哪里来？又会到哪里去？具体又该怎么建设？这几个最基本的问题，谈到的其实并不是特别多，鲜有谈到的观点还都不太一致。
+
+如果再将问题进一步展开，你就会发现有更多的问题仍然模糊不清。你可以跟我一起想一想，以下这些问题你有过同样的疑问吗？
+
+- 中台与平台/微服务/SaaS的区别是什么？
+- 中台与前台和后台的边界怎么界定？有了中台那后台是什么？
+- 什么样的企业需要建中台，什么样的企业不需要建中台？对企业到底有哪些好处？
+- 业务中台与数据中台的关系和区别又是什么？
+- 中台建设有什么样的门槛，需要哪些准入条件？
+- 中台该怎么建？分几个阶段？需要什么样的能力？
+- 中台建设的结果好坏如何评估？谁来评估？
+- ……
+
+相信这样的问题还有很多很多。这些问题也曾困扰着我，所以我希望能通过这个专栏，为你一一解答这些困惑，或者至少能给你带来一些启发。
+
+在专栏的课程设计上，我的主要思路是分成三个部分：概念篇、落地篇和最后的答疑篇。
+
+**概念篇**
+
+在概念篇里，我首先会带你时光穿梭，重走一遍中台的诞生和发展之路，从时间的维度重新梳理一遍中台诞生的背景和几个关键点，看看它究竟从哪里来？之后会通过列举目前市面上常见的中台种类，在空间的维度同样发散，看一看各类五花八门的中台。最终通过收敛和归纳，一起来探究一下中台的本质，即当我们谈论中台时我们到底在谈些什么，给中台下个定义。
+
+**落地篇**
+
+在落地篇里，我会从概念引申到落地，看看为了避开中台建设过程中的各种坑，在开始中台建设前需要先想清楚哪些问题？需要有什么样的准入条件？中台建设方法论的本质是什么？想清楚了这些问题后，又有哪些方法和套路可以帮我们实现中台的平滑落地。
+
+但是这里有一个前提需要提前声明一下，因为我们之前也提到了，中台的种类太多了，不同企业不同种类的中台，它们的建设方式可能完全不同，但是背后的思想都是相通的。
+
+在落地篇里的后半部分，关于一个中台产品的设计与实施的内容，我会用一个最常见的业务中台建设场景来展开介绍，但是其中提到的方法和工具，对于其他的中台类型也同样适用。
+
+**答疑篇**
+
+这个专栏的答疑篇是我额外设计的一个小模块。因为中台涉及的范围之广、问题之多、复杂度之高，是很难在几次课程中就完全讲清楚的。我也非常希望在我们一起学习交流的过程中，你可以把对于中台或是我这门课程的问题提出来，我们随时在留言区进行沟通和讨论，同时我也会针对每个人都比较关心的问题，单独在答疑篇里有针对性地统一给你做一些解答。
+
+<img src="https://static001.geekbang.org/resource/image/e8/65/e897fd79ca49fe66dcb0a5f35cd00565.jpg" alt="">
+
+最后，跟你分享我最近一直在想一个问题。中台到底会不会成为下一个云计算，彻底改变我们思考问题和做事情的方式，还是它只是另一个昙花一现的新概念而已？
+
+老实说，我现在还不能确定。但是通过这两年对于中台的学习和研究，至少对于我来讲，确实受益良多，无论是在视野、产品、架构还是在技术层面上都有了一个质的变化，上了一个台阶。
+
+相信通过你我一起的学习，在了解了中台背后所代表的趋势或是理念之后，无论中台最终是两者中的哪个一个，你也一定都会有所收获。
+
+最后，感谢你的关注。你对中台有哪些了解？又有哪些困惑？你现在已经参与到一个具体的中台建设中了吗？遇到了什么挑战？收获了哪些经验？欢迎写在留言区，我也很想听到你对这门课的期待。
+
+很希望和你在专栏里再次相遇。这次，我们一起来说透中台！
+
+<img src="https://static001.geekbang.org/resource/image/1b/f6/1b3b9a2c9647d42b635b50b030a5d0f6.jpg" alt="">

极客时间专栏/说透中台/概念篇/01 | 来龙去脉：中台为什么这么火？.md

@@ -0,0 +1,139 @@
+<audio id="audio" title="01 | 来龙去脉：中台为什么这么火？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/e5/1b/e5c8a36ea54d0c89daeb65571882001b.mp3"></audio>
+
+你好，我是王健。
+
+2019年截至目前，如果说IT圈有哪些能称之为热点，那中台一定会占据一席之地，就好像一时间只要跟中台相关的企业或是新闻都会备受瞩目，什么事情如果不跟中台概念沾点儿边，就好似会落后于时代。
+
+中台一时变成了众人关注的焦点之一。
+
+但中台到底是什么？答案仍然扑朔迷离、模模糊糊，甚至还有不少人仍然在思考这个概念是否有其存在的意义，是否又是另一个被炒作的概念，只不过是昙花一现而已。
+
+我整理了一下，2019年截至目前，大半年的时间，不算看过的，光是我个人收藏的跟中台相关的文章就不下300篇。最近，为了这个课程，我又回看了一遍所有的内容，发现在每篇文章里每个作者对于中台都有着自己的角度和观点，直到现在业界仍然无法完全统一，还是众说纷纭，但可喜的是在很多方面的共识已经越来越多，中台这个概念也在慢慢褪去神秘色彩，走到你我面前。
+
+而这也是我动心做这门课的原因，我近几年一直持续专职在做中台相关的工作，有幸作为架构师和产品经理的角色亲身参与到多家大规模集团型企业的中台落地建设项目中。所以希望能够借这个机会，将所见所学整理归纳，尽力为你还原一个中台的全景，帮你理解这个概念和趋势的本质。
+
+我一直遵循着一个观点，想要搞清楚一个概念或是一门技术，就先要回到历史里，回到它诞生的时间，漫步一遍它发展的历程，去探究一下它产生的背景和原因。
+
+正所谓要知其然知其所以然。
+
+今天的内容作为这门课正篇的开篇，我想就带你回到10年前，回到中台诞生的起点，我们随着时间的脚步一起重新走一遍中台的诞生和发展之路，来看看中台究竟从哪里来，又将走向何处？
+
+## 2008~2015 关键词：孕育
+
+中台的兴起，是趋势使然。但中台这个概念，最早被大家关注，一定要算是阿里巴巴提出的中台战略。这不知道你有没有发现，有一个有意思的点，就是为什么我说中台最早被大家关注是因为阿里巴巴，而不直接说中台这个概念就创造于阿里巴巴呢？
+
+既然我们这个专栏叫作“说透中台”，这里可以多说一点，对于中台这个词，很多人认为是阿里巴巴创造的。但截止目前，业界对这个问题还有一些不同的看法和意见，因为在银行里很早就有前台、中台、后台之分，而且有意思的是，阿里巴巴在2019年阿里云峰会上海站时，在介绍阿里巴巴双中台的时候，英文翻译也同样使用了银行里中台的翻译，也就是Middle Office，但是这个概念是否与银行领域的中台概念相关，目前还没有得到任何阿里巴巴的官方信息可以佐证。
+
+但对于你我来讲，中台这个词是阿里巴巴创造的，还是确实引用的是银行业已有概念，我认为，并不是那么的重要，我们可以将关注点更多地放在在IT的上下文下，这个概念究竟是什么，究竟又能帮我们些什么。
+
+而对于阿里巴巴的中台战略，现在业界一般都认为是从2015年马云走访Supercell开始的。但是我通过关注阿里巴巴对外分享的信息，以及实际和多位阿里巴巴的同学了解之后，了解到这次走访的事件只能算是个引子，阿里巴巴的中台化进程，在这之前就已经开始了。所以，要想真正理解阿里巴巴中台产生的背景和原因，需要回到更早的时候，至少要回到2008年。
+
+因为在2008年，随着阿里巴巴战略的调整，天猫顺势而生。但因为其相较于于淘宝，有其自身的特点，所以当时天猫和淘宝就出现了重复建设的问题，也就是现在大家经常提到的烟囱式系统架构。
+
+烟囱式的系统架构，造成了大量的重复建设和资源浪费，怎么办呢？最自然的想法就是将重复的组织和系统进行整合。正因如此，阿里共享事业部正式诞生，负责将各个前台系统中的公共部分进行平台化改造，经历了一段痛苦的摸索之后，借聚划算爆发的契机，才真正奠定了阿里共享事业部的重要地位，埋下了阿里大中台战略的种子。
+
+## 2015 关键词：阿里巴巴中台战略诞生
+
+历史就像一列行驶在山脊间的列车，一切都在按照既定的方向不紧不慢地向前推进。
+
+中台这个新物种也正在时间的推进中不断孕育，只在等待一个契机的到来。
+
+2015年，终于等来了这个契机。
+
+接下来就是大家津津乐道的那个故事：在2015年，马云带领阿里众高管一起拜访了位于芬兰、号称是世界上最成功的移动游戏公司Supercell。说起这家公司，你可能会觉得比较陌生，但是提到这个公司开发的游戏，相信你一定有所耳闻，《部落战争》《海岛奇兵》《卡通农场》等等知名的游戏都出于这家游戏公司之手。
+
+但当时触动马云和阿里高管团队的是，催生了这么多火遍全球游戏的企业，却只有不到200名员工。而负责一款游戏的每个团队平均也只有5到7名团队成员。团队有充分的自由，他们可以自行决定开发什么样的产品，之后就会以最快的速度推出公测版，让市场来评判，来验证产品的好坏。一旦产品不成功，则迅速放弃，此时不但不会有任何惩罚，反而团队会举杯庆祝，之后立即做出调整继续迅速寻找新的方向。
+
+嗯，是的，这就是典型的精益创业的套路。
+
+但要想让这个机制得以正常运转，必须有一个前提，就是产品的构建时间要足够短，试错的成本要足够低，这样才能保证团队在大量的试错中，通过不断从失败中学习，持续迭代调整，尽快找到正确的方向，让创新成功的进度条快速前进。
+
+而背后支撑这个机制得以实现的，就是Supercell经过6年时间沉淀下来的游戏开发过程中那些公共的、通用的游戏素材和算法。基于这些像乐高积木一样的基础素材和算法，才可以同时支持几个小团队在几周时间内像搭积木一样快速研发出一款新游戏。
+
+这种方式触动了到访的阿里巴巴高管团队，这种理念与阿里巴巴及业界这么多年一直在尝试和构思的“厚平台，薄应用”架构方向不谋而合。就是这次拜访，坚定了阿里巴巴管理层对于组织架构调整的决心，也加速催化了阿里巴巴中台战略的正式诞生。
+
+随后不久，在2015年12月7日，时任阿里巴巴集团CEO的张勇通过一封内部信说道：“今天起，我们全面启动阿里巴巴集团2018年中台战略，构建符合DT时代的更创新灵活的‘大中台、小前台’组织机制和业务机制。”
+
+至此，阿里巴巴中台战略正式诞生，而之前的“厚平台，薄应用”也顺势变成了“大中台，小前台”。
+
+但有意思的是，在2015年阿里巴巴中台战略刚刚被提出的时候，印象中并没有掀起多大的波澜。当时大家谈论的还是花千骨和《我的滑板鞋》，而互联网圈聊的更多的也是互联网+和O2O。熟不知，一场新的战场已经开始孕育，种子已经种下。
+
+## 2017  关键词：横空出世
+
+随着2015年中台概念的诞生，经过了默默无声但暗流涌动的2016年，在2017年我们逐渐开始在社区里听到了越来越多关于中台的声音，阿里巴巴和滴滴出行不约而同地开始分享各自中台建设的经验，而与中台相关的书籍也出现在了市面上。
+
+互联网大厂的集体发声，让中台这个概念时隔了两年之后又重新回到了大家的视野当中。
+
+据我了解，很多企业无论是互联网大厂，还是一些比较有战略眼光的企业，也都是在这个时间点开始重新审视并重视这个已经出现苗头的新概念。
+
+最早一批开始动手的企业大多也是在这个时间开始了自己的中台整体规划与建设，而我也是在那个时候开始与中台结缘，关注并研究中台，实际参与到一个个客户的实际中台项目中的。
+
+但当时大家面对的问题和困难也很多，像阿里巴巴或是滴滴出行这类的企业，在分享中台的时候，更多的是以自己发展历程的角度和自己的问题出发。这也毋容置疑，但是大家回头来审视自己企业的中台建设时，每家的情况都不一样，每家的问题也不同，自己的中台到底应该是什么样子？怎么建设？这些问题很多都是在书中、在分享中找不到直接的答案，只能靠自己一点一点摸索。
+
+至此，一些勇敢的先行者们就开始了各自的中台探索之旅，虽然这注定是一条布满荆棘的道路。
+
+现在回头再看，有些当时的探索最终失败了，有些探索仍在继续。但无论如何，这些先行者们的探索和经验得失，为我们现在理解和建设中台扫清了很多障碍，没有这些探索和思考，也不会有现在的这些经验与共识。
+
+## 2018 关键词：全面爆发
+
+2018年年中，中台蓄势已久，终于迎来了全面爆发。
+
+这点我算是有亲身体验的。记得非常清楚，那应该是在2018年9月9日的中午，在同事们都趴在桌子上睡午觉的时候，我终于借午休的时间，把憋了3个多月才写完的一篇文章像往常一样发到公众号。这篇文章写的是自己这一年多来关于中台的一些思考，在我看来是篇再普通不过的文章。
+
+之后发生的事情却远远超出了我的想象，我的文章一下午的时间被各种社区大号转发，阅读量迅速突破了一万、两万、三万、四万……这对于平时写文章最多只有几百阅读量的我来说，有点一时不知所措。那时的感觉就是所有的朋友、朋友的朋友、朋友的朋友的朋友，都在转发这篇中台的文章。
+
+那也是我第一次感受到了中台的热度，它蓄势已久，终于迎来了属于自己的一次爆发。
+
+但只有这一次大讨论，还不足够。随后发生的事，你也许也还记得。来，我带你一起快速回顾一下：
+
+<li>
+2018年9月30日，腾讯宣布了7年来最大规模的组织变革，新成立了云与智慧产业事业群（CSIG）。同时，腾讯新成立了技术委员会，宣布未来将打造技术中台。
+</li>
+<li>
+2018年11月26日，阿里宣布进行组织升级，阿里云事业群升级为阿里云智能事业群，将中台智能化与阿里云全面结合。
+</li>
+<li>
+2018年12月21日，京东集团人力资源部发布关于京东商城组织架构调整的公告，公告内容称：“在新的组织架构下，京东商城将围绕以客户为中心，划分为前中后台。中台为前台业务运营和创新提供专业能力的共享平台职能。”
+</li>
+<li>
+……
+</li>
+
+也正是这一波互联网大厂眼花缭乱的集体操作，纷纷为中台接力发声站台，才正式把中台推上了舞台，迎来了全面爆发。
+
+## 2019 迷雾仍然存在
+
+中台的热度经过2018年底的爆发，延续到2019年，并没有消退的迹象，反而越发高涨。
+
+但爆发归爆发，不代表之前的问题都已经被解决，问题和困惑依然存在，丝毫没有因为概念的火爆而变得清晰，反而随着跟进的企业越来越多，问题不降反增，变得越来越多：
+
+- 中台与平台的区别到底是什么？
+- 中台到底有多少种？哪些是哪些不是？有建设顺序么？
+- 中台到底怎么建？从哪开始？怎么算结束？
+- 中台需要组织调整么？怎么调整？
+- 中台如何验证建设效果？
+- ……
+
+而这些问题这几年也一直困扰着我。如今，经过了这么长时间的探索、研究以及向前辈们取经，我也有了一些自己的思考和总结。现在，我把这些内容分享给你，跟你一起探讨这些问题的答案，帮你在自己的中台建设中扫清一些障碍。
+
+## 总结思考
+
+今天，我带你回顾了中台的发展过程。最后，我们来看看是不是可以回答开篇的那个问题了：中台到底为什么会这么火？
+
+就像很多趋势不是一股力量形成的，我认为中台的火爆至少是因为以下这四个方面的契机凑在了一起。
+
+1.互联网企业的样板效应。这个毋容置疑，在当下，互联网公司，尤其是各个大厂的样板和标杆效应还是非常强的。更何况对于中台这件事情上，互联网企业们的态度又是这么的高度一致，在以往也是很少见的，而建设效果也实实在在被大家看在眼里，让人羡慕不已。
+
+2.那互联网企业为什么会这么一致地推动中台呢？背后还有一个更深层次的原因就是今年火爆的产业互联网，在消费互联网阶段的中后期，消费侧的战场日益白热化。互联网企业为了追求持续增长，纷纷将目光转向了供给侧，这就是今年ToB也异常火爆的原因。而云和中台战略正是互联网企业进入传统行业的一个非常好的切入点，所以我们看到越来越多的互联网企业参与进传统企业上云和企业数字化转型过程中，把自己的技术和实践带到传统行业，在整个过程中，中台确实是一个很好的抓手和利器。
+
+3.正所谓一个巴掌拍不响，这个时间点确实也正好匹配到了一些行业从系统化向平台化转型的节点。通过这些年的信息化建设和积累，企业内信息化系统该建的也都建了，什么ERP、CRM等，该有的也都有了。信息化建设启动早一些的企业，内部的各个系统也开始出现前面提到的烟囱林立、数据孤岛等痛点。而信息化建设相对晚一些的企业，也正好想通过这波中台浪潮来个弯道超车，一步到位。此时再赶上一阵中台旋风袭来，家家企业都觉得自己有做中台的需求和痛点，开始了自己的中台规划与建设。
+
+4.最后，我认为还有一点也非常重要，也是底层的原因，就是这两年整体的经济大势并不太好，不确定性和不可预测性正在不断地冲击着各个企业甚至行业，而企业的管理者们对于企业未来发展的恐惧与焦虑倍增。这时候，互联网企业通过中台战略，把能力进行沉淀与复用，用确定性来应对不确定性，拥有快速试错、快速创新的能力和思路，这让传统企业看到了一个突围的方向。经济形势好的时候，大家要么都在忙着快速拓展业务，兵贵神速，怎么快怎么来；要么就是守在自己的成熟业务上，到点收成，也没有很强的动力改变。但经济形势严峻了，压力与恐惧越来越严重了，为了能保持企业未来的生存和可持续发展，或者为下次形势转好继续冲刺做好准备。所以，效仿互联网行业，中台战略也成了越来越多传统企业和行业的选择。
+
+总之所谓天时地利人和，多方的因素聚集在一起也就催生了这波中台热点。而中台的火热到底只是昙花一现？还是像云计算和微服务一样会成为IT发展的又一次重要的里程碑？目前仍未成定论，但我个人更相信后者会有非常大的可能性。
+
+最后，我也很想知道你为什么对中台感兴趣？你觉得中台为什么这么火呢？对于中台你现在最关心的问题是什么？
+
+期待跟你一起在专栏里充分讨论。也欢迎你把今天的内容分享给自己的朋友，我们下一讲见！
+
+

极客时间专栏/说透中台/概念篇/02 | 中台种类：你听说的中台真的是中台吗？.md

@@ -0,0 +1,118 @@
+<audio id="audio" title="02 | 中台种类：你听说的中台真的是中台吗？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/57/65/57cae3bc05923e02d5bb05c5f80ec865.mp3"></audio>
+
+你好，我是王健。
+
+上一讲我带着你一起重走了近十年的中台发展之路，从时间的维度了解了中台发展的背景，也帮你分析了中台兴起背后的一些原因。
+
+不过最后的时候我们聊到，直到目前，中台的概念仍然存在着很多迷雾，中台到底是什么？中台到底该长什么样子？有哪些种类？对企业到底有什么价值？我需不需要建中台？这些问题在你心中可能仍然没有确切的答案。
+
+今天我就带你一起看一看，截至目前出现过的一些不同种类的中台，看看从这些看似不同种类的中台背后，我们能不能找到一些共同的特点。下一讲我会带你一起来探寻中台的本质，来解答你心中的疑惑。
+
+至于中台的分类，我把目前出现的这些中台分为“主流”和“非主流”两类，下面就带你一一来看。
+
+## 主流代表：业务数据双中台
+
+<img src="https://static001.geekbang.org/resource/image/17/ca/1721ba484ffe9ca733483eb80f1725ca.jpg" alt="">
+
+**业务中台**
+
+业务这个词，其实是有些宽泛的，我听到很多人口中说的业务都不是一个概念。为此，我还特地做了一些功课。业务，更白话一些来说，就是为了售出产品、换取利润，各行业中需要处理的商业上的相关事务。所以在早期我们通常会把销售叫作业务员。
+
+网易副总裁汪源就曾在网易云创峰会上提到过：“所有的中台都是业务中台”。对于这个提法，我也是认同的，因为从广义上来看所有的中台，不论是业务中台还是数据中台，亦或其他，都是为业务，为企业可以更好地以更低的成本、更高的质量、更快的响应速度售出产品、换取利润服务的。
+
+换个角度看，从企业架构的层面看，应用架构、技术架构、数据架构都是要匹配公司的业务架构的，因为“业务”，即售出产品、换取利润是企业的核心目标。
+
+好，既然所有的中台都是业务中台，那我们经常提到的业务数据双中台中的业务中台，这里的究竟代表的是什么呢？依我来看，**我们常提到的业务中台，是狭义层面的业务概念，业务中台需要具体承载支撑业务开展的必要业务元素，封装着为了保障业务可以顺利开展需要解决的必要问题空间的解决方案**。
+
+这么说可能会比较空，我有一个技巧，当我思考业务中台时，我会不断地问自己一个问题：**企业的业务能够顺利开展，需要解决哪些核心问题？**
+
+比如电商的场景，如果我是一家电商企业，我业务要顺利开展，即把我的产品卖给用户，换取利润，一般要解决的核心问题无非包含：
+
+- 我的用户是谁？从哪里来？
+- 我卖的产品是什么？从哪里来？
+- 怎么让用户知道我卖的产品？
+- 用户为什么会买我卖的产品？
+- 用户怎么买？
+- 货怎么送？
+- 用户怎么退换货？
+- 怎么才能让用户不断地买？
+
+这些就是一个电商业务能够正常开展所需要解决的最基本最核心的问题，在DDD（领域驱动设计）中，对于这些企业业务开展需要关注的核心问题空间有个专有名词，就是**问题域**。大家常说的用户域、订单域等等的叫法也来源于此。
+
+而对于一家电商企业的不同业务线，大多是因为卖的产品不同，或是卖的区域不同，用户群体不同，但是这些问题也都是要解决的，大多数情况下解决的方法也是相通和类似的。这就是业务中台之所以能够存在的原因。
+
+所以，我们常提到的业务中台，可以理解成狭义的业务中台，通过将不同业务线解决相同问题域的解决方案进行抽象与封装，通过配置化、插件化、服务化等机制兼顾各条业务线的特性需求，实现对于不同业务线的业务支撑。
+
+<img src="https://static001.geekbang.org/resource/image/86/cf/86043cc4a24c4256d5b97b21825c36cf.jpg" alt="">
+
+**数据中台**
+
+讲完了业务中台，我们再来看目前热度最高的数据中台。数据中台为什么这么火热？我总结下来主要是这么几个原因。
+
+1. 见效快。目前大部分传统企业的问题还在于数据不通，“数据孤岛”现象比较严重，数据中台的建设对于痛点的解决直接，驱动力强。
+1. 组织调整负担小。一般来说，有一定规模的企业都已经有了大数据团队或是BI团队，这个团队自然就承载着相关的职能，不需要再做大的组织调整。
+1. 有一定技术基础储备。大部分企业都进行了多年的数据仓库建设，或是随着前几年大数据的浪潮，已经构建了多年的大数据技术平台。
+1. 大势所趋。大家都在讲DT（Data Technology）时代，对于数据的价值，企业的认识也越来越深刻，大家已经意识到数据不再只是一种运营辅助分析的工具，而逐渐成为企业的核心资产和竞争力。
+
+组织变动小，技术也有了基础，痛点明显，成本低，见效快，又是大势所趋，那么数据中台成为人们关注的热点也就不为怪了。
+
+但是，既然现在都在提业务数据化，数据业务化，既然两个概念也在相互转化和融合，那数据中台与业务中台之间又是什么关系呢？究竟什么才是数据中台？跟过去建设的数据仓库和大数据平台又有什么区别和联系呢？
+
+相信，这些也是很多关注数据中台的同学特别在意的问题。
+
+关于业务中台与数据中台的关系，我比较赞同阿里巴巴技术方案总监谢纯良在一次InfoQ采访中提到的观点：“**业务中台就是在产生数据，数据中台是做数据的二次加工，并将结果再服务于业务，为业务进行数据和智能的赋能。**”
+
+而对于数据中台与传统数仓和数据平台的区别，关键在于数据中台相对于数仓、大数据平台，向前台、向业务又迈出了一步，不再只是关心技术层面大数据底座的打造，同时开始更多地关注企业层面的数据治理以及数据资产化的内容：包括但不限于数据的资产化管理（质量、成本、安全），数据服务的构建，数据的体系化建设（统一模型和指标）等。
+
+为了方便理解，在ThoughtWorks我们经常把数据中台比喻成一个数据工厂，通过收集到原材料仓库，经过厂房流水线的数据加工，最终作为数据产品进入到产品仓库，通过数据商店，以各种方式（例如数据API的方式）对于前台或是业务中台赋能，整个过程通过控制中心进行协调调度。
+
+这个比喻形象生动地体现了数据中台对于数据的二次加工的过程，同时还描述了通过数据实验室承载为数据赋予智能，通过办公室完成数据的治理与资产化的相关处理。
+
+<img src="https://static001.geekbang.org/resource/image/67/e8/67ce98414b65553dfa6244b4f71867e8.jpeg" alt="">
+
+介绍完了我们最常见的业务数据双中台，这里做个小结。
+
+业务中台与数据中台相辅相成，互相支撑，互为输入输出。业务中台承载了企业的通用业务能力，为多业务线赋能；数据中台通过对于业务数据的二次加工，并反馈回业务中台，为业务进行数据和智能方面的赋能。两者的紧密配合一起为企业构建起了商业战场强大的后方炮火群，这也就构成了最著名的业务数据双中台模式。
+
+## 非主流系列
+
+在业务数据双中台之外，还出现过各式各样的中台，而这些中台的出现也让原本还比较清晰的中台概念变得有些模糊。那接下来我就快速为你介绍一些这几年我所接触过的中台，在我讲述的过程中，你也可以思考一下，这些中台中哪些是李逵，而哪些是李鬼，谁才真正配得上中台的称号，谁又是来蹭流量的。
+
+**技术中台**
+
+除了业务数据双中台，最常被提到，在我看来介于主流和非主流之间的就得属技术中台了。技术中台相比业务中台和数据中台，边界也会更加清晰，简单来讲就是在CloudNative下将使用云或其他基础设施的能力、各种技术中间件的能力进行整合和包装。过滤掉技术细节，提供简单一致、易于使用的应用技术基础设施的能力接口，助力前台和业务中台、数据中台的快速建设。不过业界也有说法，认为技术中台没有很强的业务属性，只是一些中间件的集合，顶多算是个中间件平台而已，称不上中台，你怎么看呢？
+
+**研发中台**
+
+软件开发是一项工程，涉及到管理、流程、测试、团队协作等等方面。如何将企业的开发流程、最佳实践沉淀成可重用的“能力”，从而助力创新性应用的快速开发迭代，也是我们看到的很多企业正在做的事情，我们可以管这种关注开发效能管理的平台叫作研发中台。
+
+**移动中台**
+
+在移动互联网时代，移动优先的原则已经成为不争的事实，将App开发过程中的通用技术组件进行封装沉淀到移动中台中，就可以在构建新的App时大量复用已有组件和能力，快速构建和响应。
+
+**管理中台**
+
+最近很多企业开始尝试把中台思维应用到企业内部，重新对“人”“事”“流程”“企业运营”进行平台化/中台化改造。试图通过中台化建设，加速企业管理标准化和提升运营能力。
+
+**组织中台**
+
+在穆胜老师的书《释放潜能：平台型组织的进化路线图》中，通过分析了海尔平台化组织的演进过程，他提出了组织中台的概念。组织中台很像企业中的内部风投和创新孵化机构，为前台组织和团队构建创新型前台应用提供类似于投资评估（项目甄别）、投资管理、投后管理（孵化与风控），真正从组织和制度上支撑前台组织和应用的快速迭代和规模化创新。
+
+好了，非主流系列我们就介绍到这里。其实远远不止这些，其他还有像财务中台、采购中台、供应链中台、AI中台、运营中台、安全中台等等，也曾出现在我们的视野里，今天就不一一展开了。
+
+## 总结思考
+
+最后来做个总结。这一讲我带着你一起纵览了一下现在市面上比较常见的中台种类，此时的你可能比之前感觉更蒙了，原来还有这么多不同种类的中台存在，到底哪个是李逵那个李鬼，也傻傻分不清楚。而中台到底是什么这个终极问题，此时也一定还缠绕在你的脑海里。
+
+不用担心，通过前两讲的发散，我想让你和我一样，先把视野打开，从时间的维度和空间的维度先建立起一个全局观，下一讲我们就将做第一次收敛，来探究中台的本质。
+
+最后，给你留几个思考题：
+
+- 你自己企业有中台吗？是哪种类型？
+- 对于以上提到的这些中台，你是否也有不同的理解？
+- 除了我们今天讲到的，你还见过哪些种类的中台？
+- 你自己是否有一个标准来判断哪些是中台？
+
+欢迎你在留言区发表自己的观点，期待和你一起讨论。也欢迎你把今天的内容分享给自己的朋友，我们下一讲见！
+
+

极客时间专栏/说透中台/概念篇/03 | 中台定义：当我们谈中台时到底在谈些什么？.md

@@ -0,0 +1,171 @@
+<audio id="audio" title="03 | 中台定义：当我们谈中台时到底在谈些什么？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/ec/b9/ecc451856210c1dc51d2998c5243d6b9.mp3"></audio>
+
+你好，我是王健。
+
+前面两讲，我带你从时间维度重新走了一遍中台的发展历程，又在空间维度为你介绍了目前市面上出现过的各类中台。
+
+估计你现在一定被这么多种类的中台搞的有点晕头转向了，这些中台都称的上是中台么？感觉和之前一直在做的平台也没有什么两样啊？
+
+这也是我过去几年一直在内心不断问自己的问题。这一讲作为概念篇的最后一篇，我就试着带你跳出时间与空间的维度，来分析一下企业为什么要建中台？当我们谈中台时，我们到底在谈些什么？
+
+## 企业为什么要建中台？
+
+我们先来看企业为什么要建中台？想要回答这个问题，咱得先解决另一个问题，那就是企业为什么需要平台化？
+
+企业为什么需要平台化呢？先给我的答案：
+
+**因为在当今这样一个互联网时代，用户才是商业战场的中心，为了快速响应用户的需求，借助平台化的力量可以事半功倍。**
+
+这背后的逻辑很简单，不断地快速响应、探索、挖掘、引领用户的需求，才是企业得以生存和持续发展的关键因素。
+
+那些真正尊重用户，甚至不惜调整自己、颠覆自己来响应用户的企业，将在这场以用户为中心的商业战争中得以生存和发展。反之，那些在过去的成就上故步自封，存在侥幸心理希望用户会像之前一样继续追随自己的企业，则会被用户淘汰。
+
+很残酷，但这就是这个时代最基本的的**企业生存法则**。
+
+<img src="https://static001.geekbang.org/resource/image/37/41/37813dedcd050e7631b5570559d27341.jpeg" alt="">
+
+而平台化之所以重要，就是因为在这场以用户为中心的现代商业战争中，它赋予或加强了企业最核心的能力：**用户响应力**。平台化思想（Platform Thinking）恰好鼓励企业不断抽象沉淀自己核心的底层能力，通过平台化包装，得以更好地赋能前台业务，用底层的确定性来帮助企业应对前台业务以及最终用户需求的不确定性。
+
+从结果来看，在不确定性当道的当今商业战场，真正的弄潮儿也大多是那些具备平台化思维并很早就开始发力平台建设的企业，这也在一定层面上佐证了平台化对于一家企业的重要性。
+
+<img src="https://static001.geekbang.org/resource/image/b2/08/b219e6820853365ac7bc985a1da22f08.jpeg" alt="">
+
+好，现在我们想明白了第一个问题，企业为什么需要平台化。但是平台化并不是一个新概念，很多企业在这个方向上已经做了多年的努力和积淀。那为什么最近几年“中台”这个相对较新的概念又会异军突起？对于企业来讲，传统的“前台+后台（或是平台）”的平台化架构为什么不能满足企业的要求呢?
+
+这就引出了我们的核心问题：企业为什么要建中台？
+
+同样，先给我的答案：
+
+**中台化是平台化的下一站，是平台不断对于自身治理演进、打破技术边界、逐渐拥抱业务、容纳业务、具备更强的业务属性的过程。中台关注为前台业务赋能，真正为前台而生。**
+
+为了能够更清楚地讲解我的观点，这里需要先定义一下，在今天我们讨论的上下文中，前台和后台分别指什么。
+
+<li>
+前台：由各类前台系统组成的前端业务平台。每个前台系统都是一个用户触点，大多是企业最终用户直接使用的系统，是企业与最终用户的交点。例如用户直接使用的网站、手机App、微信公众号、小程序等都属于前台范畴。
+</li>
+<li>
+后台：由后台系统组成的后端支撑平台。每个后台系统一般管理了企业的一类核心资源（数据+计算），例如财务系统、产品系统、客户管理系统、仓库物流管理系统等，这类系统构成了企业的后台。（在和很多互联网的朋友聊过之后，在互联网企业很多并没有后台的概念，更多直接使用平台的概念，例如分为前台层和平台层，但位置和作用与传统企业里的后台相似，我这里直接统一使用后台这个概念来代表。）
+</li>
+
+定义了前台和后台，我们再回过头来看企业为什么要建中台这个问题。
+
+我们看到很多企业的后台，在创建之初的目标，并不是主要服务于前台系统的业务创新，而更多的是为了实现后端资源的电子化管理，解决企业管理的效率问题。这类系统要不就是当年花大价钱采购的套装软件，需要每年支付大量的服务费，并且版本有的也已经非常老旧了，定制化困难；要不就是花大价钱自建，年久失修，一身的补丁，同样变更困难，基本改不动了，也是企业所谓的“遗留系统”的重灾区。
+
+可以这么说，大多数企业已有的后台，要么前台根本就用不了，要么不好用，要么变更速度就根本跟不上前台业务发展的节奏。总结下来就两个字“慢”和“贵”，对业务的响应慢，动不动改个小功能就还要花一大笔钱。
+
+有人会说了，你不能拿遗留系统说事儿啊，我们可以新建后台系统啊，整个2.0，问题不就解决了？
+
+这是一种解决问题的思路，不过就算是新建的后台系统，因为后台管理的往往是企业的关键核心数据，考虑到企业安全、审计、合规、法律等限制，这样的系统也往往⽆法被前台系统直接使用，或是受到各类限制⽆法快速变化，不能⽀持前台快速的业务创新需求。
+
+此时的前台和后台就像是两个不同转速的齿轮，前台由于要快速响应前端用户的需求，讲究的是快速迭代创新，所以要求转速越快越好；而后台由于面对的是相对稳定的企业核心后端资源，而且往往系统陈旧复杂，甚至还受到法律法规、审计等相关合规约束，一般是追求稳定至上，越稳定越好， 转速也自然是越慢越安全。
+
+所以，随着企业业务的不断发展，这种“前台+后台”的齿轮速率“匹配失衡”的问题就逐步显现出来了。
+
+企业业务不断发展壮大，后台修改的成本和风险越来越⾼，这就驱使我们尽量保持后台系统的稳定性，但同时还要响应用户持续不断的需求，怎么办？最自然的就是将大量的业务逻辑（业务能力）直接塞到前台系统中，因为前台离用户近，响应也相对快。
+
+但是这样也是有代价的，这样的后果就是引入重复，同时还导致前台系统不断膨胀，变得臃肿，形成了一个个大泥球的“烟囱式单体应用”。这个局面的结果就是，前台系统的“用户响应力”被渐渐拖垮，用户满意度逐渐降低，企业竞争力也随之不断下降。
+
+对于这样的问题，Gatner在2016年发布了一份报告Pace-Layered Application Strategy。报告中给出了一种解决方案，即按照“步速”将企业的应用系统划分为三个层次（正好契合前中后台的三个层次），不同的层次采用完全不同的策略。
+
+而Pace-Layered Application Strategy也为“中台”产生的必然性，提供了理论上的支撑。
+
+<img src="https://static001.geekbang.org/resource/image/2f/7a/2f4475a0c32840d0f92f26d342e7267a.jpeg" alt="">
+
+在这份报告中，Gatner提出，企业构建的系统从Pace-Layered的角度来看可以划分为三类：SOR（Systems of record ），SOD（Systems of differentiation）和SOI（Systems of innovation）。每一类的系统都有着不同的变化速率，因此也会有不同的生命周期，适合不同的技术架构和不同的开发过程，甚至是采用不同的投资模式。
+
+回到之前说的后台与前台的两层架构，如果映射到这个模型上其实就是只有SOR（后台）与SOI（前台）的两层应用架构。这样的情况下，我们又要尽力保持后台（SOR）系统的稳定可靠，⼜要前台系统（SOI）能够⼩而美，快速迭代。因此就自然出现了上文提到的“齿轮匹配失衡”的问题，感觉鱼与熊掌不可兼得。
+
+怎么办？Pace-Layered中的SOD就是答案，它提供了比前台（SOI）更强的稳定性，以及比后台（SOR）更高的灵活性，在稳定与灵活之间寻找到了⼀种美妙的平衡。
+
+中台就是SOD。有了这层“中台”，我们既可以将早已臃肿不堪的前台系统中稳定通用的业务能力“沉降”到中台层，为前台减肥，恢复前台的响应力；又可以将后台系统中需要频繁变化或是需要被前台直接使用的业务能力“提取”到中台层，赋予这些业务能力更强的灵活度和更低的变更成本；或者干脆直接对于后台进行中台化改造，通过配置化、自助化、白屏化等形式为后台加速，从而为前台提供更强大、更迅捷、更易用的“能力炮火”支援。
+
+中台就像是在前台与后台之间添加的⼀组“变速齿轮”，将前台与后台的速率进行匹配，是前台与后台的桥梁和润滑剂。它为前台而生，易于前台使用，将后台资源顺滑地通过前台导流向用户，支撑企业更好地响应用户。
+
+好了，现在我们可以小结一下，回答企业为什么需要建中台这个问题了。很简单，企业在平台化的过程中，为了能不断地给前台业务提供更好的服务，来支撑企业对于用户的持续响应，增加企业的用户响应力，企业需要构建自己的中台。
+
+## 给中台下个定义
+
+讲了这么关于中台的来龙去脉，以及种种表现形式，也讲了我对于企业平台化与中台化的理解，但你可能仍然会觉得比较抽象，所以我想，一定要试着给中台下个定义。
+
+为什么需要一个定义呢？倒不是因为别的原因，我是觉得需要给自己一把简单的尺子，让我能轻易记住中台的特性，并能用它来快速判断一个所谓的中台是不是满足我对于中台的理解，所以我给中台的定义就是：
+
+**企业级能力复用平台。**
+
+很简单，是不是有点失望？但是为了找到一个我觉得还靠谱的定义，我几乎花了快两年的时间，期间有各种各样的定义曾浮现出来，但至少到目前为止，我觉得只有这个定义最贴切、最简单、也最准确，它能解释几乎所有我碰到的关于中台的问题，例如：
+
+- 为什么会有那么多中台？
+- 中台化与平台化的区别是什么？
+- 中台化和服务化的区别是什么？
+- 中台该怎么建设？
+- ……
+
+这9个字看起来简单，重要的是其背后对“中台”价值的阐释，下面就让我为你一一拆解来看。
+
+**1.企业级**
+
+企业级定义了中台的范围。不是说一个企业只能有一个中台，也不代表一个中台就是只能包含一家企业，企业级更多代表的是中台处理的问题在企业级别，即至少包含多条业务线或服务多个前台产品（团队），如果一个中台只为了支持一条业务线或产品线，那就不是中台，即使它用了服务化或是大数据等技术。
+
+企业级这一点非常非常重要。它让我想清楚了，中台建设的事情并不是一个技术问题，而是一个要上升到企业架构的问题。做中台建设的时候，一定是跳出单条业务线、站在企业整体视角来审视业务全景。
+
+想清楚了这一点，我对中台的理解就有了一次质的变化，也终于知道为什么一开始用做系统服务化的方式做中台会面临那么多的问题，比如最常见的组织和干系方以及利益再分配的问题。
+
+从中台的兴起与爆发我们也能看到一个趋势，就是越来越多的企业，无论是想提升自身的运营效率，还是出于业务创新发展的需求，都已经把企业全局视角、跨业务线的能力沉淀，提到了前所未有的战略高度。
+
+**2.能力**
+
+提到中台，最常听到的一个词就是“能力”。可能是因为能力这个词足够简单，又有着足够的包容度与宽度。
+
+能力定义了中台主要承载的对象。
+
+能力的抽象解释了为什么会有那么多种类中台的存在，也能解释为什么每家企业的中台都不一样，因为不同的企业之所以能够同时存在，就是因为其核心能力不同，可以满足用户不同层面的需求，也就是我们常说的差异化竞争力。
+
+**3.复用**
+
+复用定义了中台的核心价值，也承载了上面讲到的从平台化到中台化的演进过程。传统的平台化对于“可复用性”和“易复用性”并没有给予足够的关注，更多关注的是如何消除掉重复的能力建设，既所谓的“去重”。
+
+但中台的提出和兴起，体现出一种对于前台业务的使用体验更加关注的趋势。让人们通过对于“可复用性”和“易复用性”的关注，将目光更多地从平台内部的建设转换到平台对于前台业务的支撑上。这里有一个从治理到赋能的视角转换，既从“去重”到“复用”的关注上。
+
+“去重”与“复用”虽然经常一起出现，一起被提及，但是谈论的完全不是一件事情，目的不同，难度也不同。“去重”讲的更多是向后看，是技术驱动的；“复用”讲的更多是向前看，是业务驱动和用户驱动的。而正这个视角的转变，我认为是理解中台概念的关键，所以
+
+- “复用”是中台更加关注的目标；
+- “可复用性”和“易复用性”是衡量中台建设好坏的重要指标；
+- “业务响应力”和“业务满意度”是考核中台建设进度的重要标准。
+
+这也能解释为什么很多互联网企业，将对于平台的治理，通过业务抽象以及可配置化和白屏化的改造升级，把这个过程称之为对于平台的中台化改造过程。
+
+**4.平台**
+
+平台定义了中台的主要形式。区别于传统应用系统拼凑的方式，中台通过对于更细粒度能力的识别与平台化沉淀，实现企业能力的柔性复用，更好地支撑前台业务，来满足对于业务的快速响应和复用的需求。
+
+“**企业级能力复用平台**”这个定义虽然看起来简单，但经过这么长时间对于中台的实践与思考，我觉得这个定义背后所代表的意义是目前对中台价值的最贴切的阐释。
+
+- “**企业级**”定义了中台的范围，区分开了单系统的服务化与微服务；
+- “**能力**”定义了中台的主要承载对象，能力的抽象解释了各种各样中台的存在；
+- “**复用**”定义了中台的核心价值，传统的平台化对于易复用性和前台的用户体验并没有给予足够的关注，中台的提出和兴起，让人们通过可复用性将目光更多的从平台内部设计转换到平台对于前台业务的支撑上；
+- “**平台**”定义了中台的主要形式，区别于传统的应用系统拼凑的方式，通过对于更细粒度能力的识别与平台化沉淀，实现企业能力的柔性复用，更好地支撑前台业务。
+
+## 总结思考
+
+今天我们从企业为什么需要平台化入手，讨论了企业又为什么需要建中台。结合前两讲的内容给出了我的观点，不知道对你有没有启发，让我最后再来总结一下。
+
+**以用户为中心的持续规模化创新**，是中台建设的核心目标。企业的用户响应能力和规模化创新能力，是互联网时代企业综合竞争力的核心体现。**平台化包括中台化只是帮助企业达到这个目标的手段，并不是目标本身。**
+
+中台（⽆论是技术中台、业务中台还是组织中台）的建设，根本上是为了解决企业响应力困境， 弥补创新驱动需要快速变化的前台和稳定可靠驱动需要变化周期相对较慢的后台之间的矛盾，提供⼀个中间层来适配前台与后台的配速问题，打通并顺滑链接前台需求与后台资源，帮助企业从整体上不断提升用户响应力。
+
+所以，中台到底是什么根本不重要，如何想方设法持续提高企业对于用户的响应力才是最重要的。而平台化或是中台化，只是恰巧走在了这条正确的大道上。
+
+最后我们给中台下了一个定义，既“**企业级能力复用平台**”。有了这个定义后，我们不仅可以把它当作一把尺子来丈量一个中台是否货真价实，对于如何建中台的思路也能豁然开朗。
+
+因为如果说“中台就是企业级能力复用平台”的话，那“中台化”也就是“**利用平台化的思维和手段梳理、识别、沉淀与复用企业级核心能力的过程**”。
+
+好了，从下一讲开始我们就正式进入落地篇，一起来看看我们是如何规划与落地实施中台的。
+
+最后，给你留几个思考题：
+
+- 你的企业真的需要中台吗？
+- 如果让你用一句话来给中台下个定义，你会怎么讲？
+- 在你所在的企业，中台是解决方案还是问题本身？
+
+期待你在留言区分享自己的想法，也欢迎你把今天的内容分享给朋友，和他一起学习讨论。我们下一讲见！
+
+

极客时间专栏/说透中台/答疑篇/答疑篇（上） | 你问我答，关于中台还有哪些困惑？.md

@@ -0,0 +1,134 @@
+<audio id="audio" title="答疑篇（上） | 你问我答，关于中台还有哪些困惑？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/6a/1b/6a6e1c8b3708e7f928fe366a5b79e91b.mp3"></audio>
+
+你好，我是王健。
+
+专栏9月25日上线，到现在有一个多月了。说实话，确实没有想到有那么多的朋友关心中台相关的内容，首先谢谢你的支持、鼓励、意见和反馈。
+
+在这一个月的时间里，我也一直在持续关注着你的留言互动。简单统计了一下，到目前为止，留言总数已经超过了300条，并且每天还在持续不断地增长，心存感激的同时也感到压力倍增。
+
+留言中有很多非常好的问题，非常在点子上，我也尽力做到有问必答，希望能对得起你的支持和时间。同时在和你的交流中，我也学到和领悟了很多新知识。
+
+记得一位老前辈就曾说过，知识分享的过程并不是一个单纯的知识输出过程，而是一个知识输入与学习的过程，对此我深以为然。做这个专栏开始时我也给自己定了一个小目标，就是驱动自己对中台背后的知识再做一次系统化的归纳整理与学习，与更多人一起交流探讨，不断捶打与夯实这些知识，从结果来看，确实是达到了。
+
+今天呢，是我们专栏的答疑篇，我来统一解答一些大家都比较关心的问题。但我的解答肯定不是标准答案，也可能不全面，希望你可以继续留言评论帮我补充或者指正，我们一起讨论甚至辩论，我特别喜欢这样的氛围。
+
+为了写这篇答疑篇，我又从头到尾把这300多个问题（有的还没来得及回复）完整地看了一遍，我发现大家普遍关心的，可以归纳为下面这四个问题：
+
+- 中台与微服务、中间件、数据仓库到底有什么区别？
+- 中台和后台的区别具体在哪里？
+- 中台与前台的边界如何界定？
+- 中台到底是不是在炒概念？
+
+所以今天我就试着从这几个问题展开，聊一聊我的看法。因为内容比较多，我把答疑分为了上、下两篇。这一篇我们先来看前两个问题。
+
+## 中台与微服务、中间件、数据仓库到底有什么区别？
+
+这个问题是大家问得最多的，其实这是三个问题，但我觉得相关，就放到了一起。
+
+首先这个问题本身就非常有意思，它体现出目前中台的一种混乱的情况，虽然我们谈的都是中台，但是每个人口中的“中台”可能并不是一个事情。当我们谈中台与微服务的区别时，更多谈的是业务中台；当我们谈中台与中间件的区别时，则更倾向于技术中台；当我们谈中台与数据仓库的区别时，更多谈的则是数据中台。
+
+所以这个问题更严谨的表达，应该是“业务中台与微服务”、“技术中台与中间件”、“数据中台与数据仓库”到底有什么区别？
+
+为什么现在大家谈中台的时候，谈的都不一样呢？这一点我在每天回答问题的时候，感受特别明显。每位同学提问的时候，自己所说的“中台”都是特指的概念，是不同限界上下文（Bounded Context）中的概念（从自己的企业和场景出发），在我看来都是不一样的。这也一定程度上可以解释为什么大家谈中台的时候总是谈不清楚，其根本原因可能就是交谈的双方并不在一个上下文下。
+
+我经常比喻，这就像是云早期的时候，大家都在谈云，都觉得自己的才是真的云，但其实大家谈的又都不是一个东西，后来才知道，原来你说的是IaaS，我说的是PaaS，他说的是SaaS……
+
+所以我写[《02 | 中台种类》](https://time.geekbang.org/column/article/140064)这篇文章，就是希望给你一个全局视角，跳出自己对于中台的理解，我们从整体上看一下到底都有哪些不同种类的中台，先发散再收敛，再看看，中台到底是什么，到底分几类。就跟当初谈论云一样，先厘清概念，避免我们在谈中台的时候都是在不同的“限界上下文”下，感觉说的是一个词，但是其实是完全不同的概念。
+
+那再回到问题上来，“业务中台与微服务”、“技术中台与中间件”、“数据中台与数据仓库”到底有什么区别呢？
+
+- **业务中台与微服务的区别？**
+
+这个我在[《07 | 中台落地第二步：企业数字化全景规划》](https://time.geekbang.org/column/article/140113) 中曾经展开具体聊过，简单来讲就是微服务更多关注技术架构层面上的问题，而业务中台更多关注业务架构层面上企业级复用的问题。业务中台不一定是微服务架构的，采用了微服务架构的也不一定就是中台，对于这部分的详细说明可以回看一下07中的阐述，这里就不赘述了。
+
+- **技术中台与中间件的区别？**
+
+这个问题大家问得也比较多。确实，我们看到很多技术中台就是中间件平台包装发展的产物。对于这个问题，说说我自己的理解。
+
+技术中台强调的是更多从业务视角出发，而中间件主要是从技术去重的视角出发。具体来说，技术中台为了让业务更好地使用技术相关能力，对于技术做一些治理、安全、可用性和自助式的包装。**如果能通过中台这个概念为驱动力，促使企业的内部技术平台再向业务走出一步，无论是针对用户体验做优化，还是通过产品化，让业务可以自助式（Self-Service）地使用企业技术组件的能力，如果能做到这些或是起到这样的驱动力，我觉得技术中台这个概念才有价值**。
+
+总结篇中推荐的[《从平台到中台 | Elasticsearch 在蚂蚁金服的实践》](https://mp.weixin.qq.com/s/Dob6Kjm6v7gE4o7B1HhqLA)，在我看来就是一个非常好的对于中间件平台（Elasticsearch平台）中台化改造的例子，你可以重点看一下。
+
+- **数据中台与数据仓库的区别？**
+
+其实不光是数据仓库，还有同学问到数据中台与大数据平台的区别。这个问题也是大家比较关心的，可能是因为数据中台确实比较火吧。
+
+其实外边有很多文章也在讨论这个问题，在我看来，其中最大的一个区别还是**数据中台和传统的数据系统出发点（视角）不一样**。
+
+原来的数据平台也好，数据湖也好，数据仓库也好，它们的出发点很多时候有局限性，应该说更是一个支撑性的技术系统，即一定要去考虑我先有什么数据，然后我能干什么，依赖现有数据的质量、现有数据的状况，来做这样一个支撑性的技术平台。
+
+那数据中台呢？回到我们所讲的中台概念，它更多的是**从业务出发**，然后再来看这些业务，你需要这些数据服务，它有什么价值？至于说这些数据服务所依赖的数据有没有，只要这个服务有价值，那我们就去想办法拿到数据，如果没有能力，我们就去建设技术能力，去完成数据服务的提供。
+
+所以，**传统的数据系统（数仓、大数据平台）更多是偏技术侧，拿着数据和技术找场景；而数据中台更多的是偏业务侧，拿着场景去找数据和技术**。也就是说，数据中台的思维是业务思维，它从业务问题出发，这也就是为什么业务部门对数据中台会这么欢迎。总结篇中推荐的凯哥的[《火热的数据中台对企业的价值是什么？》](https://mp.weixin.qq.com/s/a_sJa8I8kefvq8KsTqenqg)中对此有详细的展开，对数据中台还有疑惑的话，可以重点看一下这篇。
+
+我非常能理解大家为什么都有这样的困惑，在我看来问题就在于**中台这个概念的出现并没有在技术上有任何的创新**。我们仔细想想，是不是没有任何一个新的技术是由“中台”这个概念所驱动出来的？而我们大多也习惯了从技术的视角上去看待新的概念，所以自然就被搞晕了，因为各种中台所使用的技术早就在那儿好多年了，感觉没有什么新鲜玩意儿。
+
+**我认为这也是理解“中台”概念的一个坎儿，就是能否从技术的视角切换到业务的视角上，用“业务思维”来看待平台**。其实这也是理解中台概念的关键所在，也是我认为的技术平台发展的一个大趋势。
+
+为什么这么讲呢？如果我们回头来看整个IT技术的发展历程，从最早的基于具体型号的大型机的开发到操作系统的产生、编译器的产生、编程语言的产生、各种框架和库的产生、各种技术平台的产生，如果仔细思考，这就是一个“**平台（抽象）不断向业务推进的过程**”。从微观上看，这也是我们写的业务代码占所有代码比例逐渐增加的过程，或者说是一个我们写代码的“业务纯度”不断提高的过程。
+
+由此可见，中台这个概念的产生，其本质就是在技术发展的趋势中，对于技术平台（微服务、中间件、大数据平台）向业务的一个再推动的过程，跟过去几十年发展的趋势一样，自然而然。
+
+而这种演进的推动力，也就是我说的用户（业务）响应力的驱动，说白话就是被业务发展逼的。这里有一个好的例子，就是我在10总结篇中推荐的前阿里交易平台产品经理张巍老师的[《七问七答，亲历者讲阿里中台落地》](https://mp.weixin.qq.com/s?__biz=MzI3NTI5NDk4NA==&amp;mid=2247483773&amp;idx=1&amp;sn=c0e1448c02b0ce4bd36e2f02a8dbb37c&amp;chksm=eb07bf1adc70360c0cc81eb96d1c6705986b47a41e38d210aac2988b823a6a88b326db0a20e3#rd)。从这篇文章里，我们可以看到这个驱动力是如何驱动阿里交易平台向业务中台的演进过程的。
+
+最后引用一个同学（Pantheon）的留言。
+
+> 
+平台感觉是可以业务无关性，比如搭建一个Hadoop平台，平台的抽象应该更高，提供这样的一个东西，具体怎么用是使用者的事情。中台的概念是业务相关性，中台是需要承载业务的，比如我现在是在教育公司，也有多个业务线，每条业务线都离不开直播上课的概念，那中台可以下沉上课系统和课表系统。不知道这样理解对不对？
+
+
+<img src="https://static001.geekbang.org/resource/image/d9/dd/d9059f636f56127b9e8a68186b444cdd.jpg" alt="">
+
+我觉得Pantheon同学提的“业务无关性”和“业务相关性”这两个概念还是非常到位的。如果再回头去看问题中的“业务中台与微服务”、“技术中台与中间件”、“数据中台与数据仓库”的区别，都可以看成前者（中台）是业务友好型，或者包装了业务或者对于业务赋能做了改良与治理演进，而后者（平台）则更多是纯技术平台，也就是业务无关性。
+
+也正是由于面向业务这样一个统一的视角，才让这三个之前在不同领域平行发展的概念走到了一起。所以我说**中台是平台的下一站，是企业内平台不断扩展自己外延，对自身不断治理演进，走向业务的过程，是从资源整合向更好地对业务赋能演进的过程**。
+
+## 中台和后台的区别具体在哪里？
+
+其实这个问题，之前也一直困扰着我，为此我还特地翻阅了好几遍《企业IT架构转型之道》，想看看阿里是如何对于后台系统进行定义的，结果我找了半天也没有找到，甚至连后台这个词在这本书里都没怎么出现过。
+
+从那以后，我一直在找答案，直到从我们中国区CTO徐昊那儿听到了关于Pace-Layer Application Strategy的说法，这个说法给了我很大启发。
+
+我们可以用SOR来理解后台，对应到企业内，就是那些所谓的核心系统，常见的例如ERP、DMS、银行的核心账务系统等。在实际的项目过程中，我们面对的问题也大多是这类系统无法满足前台系统快速业务变化的需求，也就是我们专栏里提到的齿轮匹配的问题。
+
+再之后，有一次和前阿里交易平台产品经理张巍张老师沟通，这次沟通解决了我一个遗留很久的问题，就是为什么之前在看阿里讲中台的书中，没有对于后台的定义和其与中台的区分呢？
+
+张老师的一些回答在总结篇里我推荐的《七问七答，亲历者讲阿里中台落地的实践》那篇文章中都能找到。总结来说，阿里的中台是由平台（例如交易平台）演进过来的，是对于平台治理演进的结果。而在阿里，后台另有所指（与一般企业理解的后台核心系统不太一样），通常指那些辅助企业运行的后台系统，例如人力系统等，与中台并没有什么关系。
+
+这时我就发现，如果把阿里的平台（交易平台）和传统企业的后台（ERP等等），作为同一个概念用Pace-Layer Application Strategy去思考，也是都能说通的，具体的思路我在[《03 | 中台定义》](https://time.geekbang.org/column/article/140065)中已经展开阐述了。
+
+那到这里，我们其实会有这样一个问题，为什么不同的企业对于后台的定义会有区别呢？其实了解DDD的朋友都应该清楚，一个词，例如“后台”，在不同的上下文里，可能完全代表的不同的东西。而不同的词，例如“后台”和“平台”，在不同的上下文里，可能代表的却是一个概念。
+
+还推荐你看一下我在总结篇中推荐的[《阿里的中台战略其实是个伪命题》](https://mp.weixin.qq.com/s/R15Iys1v79y_rmkvsbVkAA)这篇文章，这篇文章是我看到的少有的从企业架构的层面，分别从业务架构、应用架构和组织架构展开来聊对于中台和后台的概念的。这也让我意识到，不光是不同的企业对于“后台”概念不一样，当我们在谈论业务架构、应用架构、技术架构甚至是组织架构时，“后台”这个概念也是不一样的。
+
+所以最后我也想通了，搞清楚什么是后台其实对于我来解决企业实际的问题，并没有太大的帮助，我们还是陷入到了“什么该是什么”的怪圈里。
+
+不如从“概念到底是什么”跳脱出来，重新回到企业具体的上下文下，回到要解决的问题上，来思考中台这个概念到底能有什么帮助？在企业内，中台与现有系统，中台与平台的关系又是什么？只有在自己企业特定的背景下，我们才能有一个结论，很可能中台也同时是后台，或者也可能是后台的改进版。
+
+说了这么多，其实是想和你分享我理解这个问题的一个心路历程，希望能帮你更好地理解这两个概念。
+
+最后，在这里还想分享一下“笑若海”同学的留言，我觉得Ta的观点对我也非常有启发。
+
+> 
+我觉得平台与后台的关系可以借助System of systems的概念来理解。后台对应systems，对应于企业建立的各种职能IT系统（如CRM、ERP、OA、库存管理、采购、供应链、研发、制造等）；平台对应system，将职能IT系统有机集成起来，作为一个整体对前台服务，而不是各个职能系统之间的点到点集成对前台提供服务。
+
+
+> 
+平台层在互联网企业中兴起前已经存在，只是传统企业中IT部门作为辅助职能部门，缺少话语权和主导性，没能上升到企业级高度。而互联网企业敏捷、快速响应用户的企业文化将平台化做到了新的企业级高度。
+
+
+> 
+平台与中台的异同——“中台是企业级能力复用平台”这一概念解释得非常准确，平台化刚被互联网企业喊出时，侧重于IT能力去重，是cost saving；中台则侧重业务能力灵活复用，是value add。
+
+
+> 
+平台化/中台化本质上就是企业IT系统集成的一种设计理念，以高效的价值创造和成本控制为目标。
+
+
+<img src="https://static001.geekbang.org/resource/image/b0/05/b0b91a3d45755dba17406d38eba74405.jpg" alt="">
+
+好了，今天的内容我们先到这里。不知道通过这个答疑篇，对于今天我们讨论的两个问题，你是否有了更多的理解。下一篇我会和你继续探讨另外两个问题。
+
+有任何问题欢迎你继续留言，期待与你一起交流。
+
+

极客时间专栏/说透中台/答疑篇/答疑篇（下） | 你问我答，关于中台还有哪些困惑？.md

@@ -0,0 +1,93 @@
+<audio id="audio" title="答疑篇（下） | 你问我答，关于中台还有哪些困惑？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/e7/fb/e7c989b15985184f40e8e9a9da2fe9fb.mp3"></audio>
+
+你好，我是王健。
+
+这一节我们继续来聊大家普遍关心的另外两个问题：
+
+- 中台与前台的边界如何界定？
+- 中台到底是不是在炒概念？
+
+## 中台与前台的边界如何界定？
+
+对于前台和中台的界定，我看很多同学也问到了。
+
+我在不同的时间尝试过很多种不同的划分方式，但总觉得有局限。例如，如果最简单按照是否重复来划分，重复需求放中台，特性需求放前台，先不说是否重复这件事就很难掰扯清楚，而且放到时间线上，现在一样的可能以后会不同，现在不同的难免以后也可能会相同，以后再做迁移又要付出额外的迁移成本，这本身也很难扯清楚，更别提局部重复等情况。
+
+其他的分法，也会有同样的问题，例如按照业务重要性，那怎么判断重要性高低，这些都是问题。
+
+我觉得要想通这个问题，还是需要这么几个关键点。
+
+首先还是要想清楚，中台建设的愿景是什么，想好中台自己的方向和产品定位，**一个清晰的愿景往往就代表了一个好的边界**，这个边界能帮我们判断哪些该做哪些不该做，先做什么，后做什么。就像一个产品一样，例如微信，我们谁都能想出很多的功能，而且也都有必要，但是如果没了愿景，我们就不知道什么该做什么不该做（什么更重要），如果一股脑儿添加进去，而不会做取舍，最终也会变成一个四不像而失败。
+
+当然有了愿景，肯定也还是会拿捏不好，这时候就得用演进式的视角和技术来帮我们解决这个矛盾了。将关注点从如何设计正确，转变到如何让变化更加容易，一旦变化变得廉价，我们也就不用那么在乎一开始的决定是否正确了，反正大概率都是错误的。也就是用演进的眼光来看待，不要奢望，一次想对，一次分对，一次做对，尊重变化，承认自己的弱小，**追求变化响应over追求一次做对**。
+
+如果再深入思考一下，可能**中台与前台的边界问题，不是技术的边界问题，而是组织的边界问题**。就像我一直反复强调的，中台是企业级的问题，中台与前台的边界划分，其实本质上就是**企业内横向的平台类组织和纵向的业务类组织的边界划分，也就是组织责任与利益的边界划分**。
+
+在总结篇里，我也讲到了，中台的核心价值就在于企业对经济性和灵活性的平衡，而组织的碰撞（比如部门之间的争执），在我看来反而正是企业在不断追求这种平衡的“动作”，是正常的，也是必须的，我甚至认为中台与前台的边界，也只能靠不断的组织碰撞，才能找到一个最佳的平衡点，而这往往也是针对于这家企业整体经济性和灵活性的最佳平衡点。
+
+这个过程虽然是痛苦的，就像是发烧的时候各种症状，虽然难受，但是一定程度就是自身机能在调整以及起作用的过程，也是企业战略落地和转型的具体表现。我常常有种感觉，这种碰撞甚至都有可能是企业转型的根本与实质。而我们要做的，就是设计一套机制，例如冲突处理升级机制，来正确地引导这种碰撞向解决问题的方向、而不是相反的方向前进。
+
+我现在就是从这几个角度来思考中台与前台的边界问题的，总结一下就是：**想好愿景，演进式思维，合理引导组织碰撞**。
+
+## 中台到底是不是在炒概念？
+
+关于概念炒作，专栏里也提到过，我一开始的时候也是这么认为的，觉得现在这个时代太浮躁了，大家整天都在炒概念，后来反思其实是因为概念太多自己不想学习的一种自我保护的抵抗情绪。
+
+但是，经过几次对于技术“看走眼”之后，我开始提醒自己，对于一个新的概念，要先抱着开放和学习探索的心态，去了解、去思考这个“概念”背后到底是什么？有那么多概念，为什么只有这个这么受人关注、有“炒作”的空间？
+
+事出必有因，只不过可能不是表面的样子而已。
+
+阿里提出中台，肯定有其背景和上下文。那么多企业都效仿，必然有其理由，可能只是把这个概念“嫁接”到了自己的企业里而已，甚至可能代表与阿里或其他公司完全不同的意义。
+
+我们常说语言的边界就是思想的边界，而每一个新概念的产生就像是一个新的“流行词”火起来一样，肯定是人们找到了一个新的语言来代表之前无法清晰表达的意思。**新概念本身是没错的，因为新概念往往代表着新的边界、新的约束，而新的边界和约束也往往就是新价值的来源**（例如SOA和微服务、虚拟化和云）。
+
+炒作本身也没错，一个新的东西，无论是新的层次还是新的边界产生，如果其本身能创造新的价值，让更多人知道这个价值，帮助更多人解决遇到的问题，也是挺好的事情。
+
+所以我的观点是，永远保持好奇，先接纳，再判断。不要轻易把门关上，可能会错失掉一些新的东西，就算是进去转了一圈，最后发现并没有什么新的价值，其实也没有多大的损失，学习有时候不能太功利。
+
+技术的发展，前面也提到了，在我看来，也正是在一个过程中滚滚向前的。在这个过程里，新概念不断产生发展，新的边界和新的抽象层次不断发现与包装沉淀，而抽象层次又不断向业务方向推进（操作系统-&gt;编程语言-&gt;库&amp;框架-&gt;业务组件服务或中台……）。
+
+不过话也要说回来，也要有自己的主动思考能力，需要快速判断概念是否值得继续投资自己的资源，毕竟人的精力也是有限的，不要在价值不大的新概念上浪费太多的精力，及时踩下刹车。而对于如何判断是否需要“止损”，我个人的经验很简单，我有一个方法，我把它叫作“循环提问法”。
+
+<li>
+新的技术在解决什么问题？为什么之前的技术不能解决？它的核心突破点是什么？本质是什么？
+</li>
+<li>
+新的技术和其他解决类似问题的技术有什么关系？有什么区别？
+</li>
+<li>
+新的技术为什么在现在这个时间段出现？为什么在现在爆发？为什么之前没人想到这种新的解决方案？
+</li>
+<li>
+新的技术和我现在正在做的事情是否相关？新的技术和我想做的事情或方向是否相关？
+</li>
+
+以我自己为例，我在面对一个新概念的时候，首先是抱着开放的心态，先别一棍子打死，主动去了解一下，到底为什么火？背后有什么趋势或是本质？
+
+然后再主动思考，这个概念是否是我的方向，我是否需要继续投资（时间和精力）？需要花多大的精力？
+
+相信通过这样一个过程，在不浪费太大精力和资源的前提下，我们也能学到更多的知识。
+
+这一点推荐一个工具，也就是Gartner每年都会推的**新兴技术成熟曲线**。对于一个新概念，我们也可以用这样一个曲线，从一个技术的全生命周期视角来思考，它到底正处于哪个阶段，然后再判断我们是该踩下油门还是该踩下刹车了。
+
+<img src="https://static001.geekbang.org/resource/image/c4/a4/c42430c4241c60f89a9773311cf172a4.jpg" alt="">
+
+## 总结
+
+好了，在这两期答疑中，我针对大家留言中都比较关注的问题，统一聊了一些我的看法和理解，希望对你有一些启发或帮助。
+
+当然问题还有很多，我也会持续关注和回复。所以，非常推荐你不要只看完专栏正文，有时间和精力的话，也把评论区的留言和讨论看一看，应该会有非常大的启发。当然了，也特别希望你能贡献出自己的问题或是思考，让这个小小的专栏能发挥出更大的价值。
+
+有同学问我为什么能问出这么多好问题，其实答案很简单，就是实践。**很多道理你我都懂，但是只有真正的实践，才能不断地碰到各种实际的问题，也只有不断地实践，才能在发现问题、解决问题的循环往复中持续向前，对于一个技术或是概念才能有更加深入的理解**。
+
+最后，我想引用Cheng同学的一句话作为本篇的结尾：
+
+> 
+以用户为中心，从战略入手，愿景为指引，用科学有效的方法，步步为营沉淀企业级能力，辅以必要的组织与系统架构调整，方得中台。
+
+
+<img src="https://static001.geekbang.org/resource/image/4a/89/4a55ad00b13a7dc25409426249fda089.jpg" alt="">
+
+谢谢你！我们留言区见！
+
+

极客时间专栏/说透中台/结课测试/结课测试｜“说透中台”100分试卷等你来挑战.md

@@ -0,0 +1,10 @@
+
+你好，我是王健。
+
+到这里，《说透中台》这门课程已经全部结束了。我给你准备了一个结课小测试，来帮助你检验自己的学习效果。
+
+这套测试题共有 20 道题目，包括9道单选题和11道多选题，满分 100 分，系统自动评分。
+
+还等什么，点击下面按钮开始测试吧！
+
+[<img src="https://static001.geekbang.org/resource/image/28/a4/28d1be62669b4f3cc01c36466bf811a4.png" alt="">](http://time.geekbang.org/quiz/intro?act_id=101&amp;exam_id=214)

极客时间专栏/说透中台/落地篇/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)