# 中台建设方法论
# ThoughtWorks的D4
ThoughtWorks把中台从整体规划到落地交付的过程划分了四个不同的阶段，他们把它称作D4，其包含了两次发散与收敛的过程。 如图：
第一个阶段是 Discovery，帮助我们在中台规划前先建立全局视野。在这个过程中我们以企业愿景和战略为输入，结合行业趋势、竞争对手分析、用户客群分析 、业务现状分析、IT 资产盘点，全方位多角度地理解企业的战略市场环境以及业务及 IT 全貌，帮助我们做出最正确的判断。
第二个阶段是 Define，帮助我们基于之前 Discovery 发散的各维度信息进行收敛与分析， 对于中台的架构进行定义。通过对跨业务线的业务梳理进行重合度分析，并结合领域分析对业务表象之后的企业核心问题域做进一步展开和重合度分析，一起来收敛推导基于中台的企业架构设计。并基于多维度的打分，形成具体的实施路径规划，说白了就是先做什么后做什么。这里需要注意一点，此时收敛的是仍是企业架构层面，像业务中台、数据中台这种级别的产品，可能只是实施路径中的一个项目，在这个阶段也可以回答那个我们关心的问题，我们到底需不需要中台，需要哪些中台？
第三个阶段是 Design，帮助我们针对实施路径中的某一个产品，例如业务中台，做详细的设计，包括产品级的业务需求分析、功能及架构设计、实施计划等。例如对于业务中台产品，在 Design 阶段我们需要回答产品的愿景、边界、产品形态、技术架构、交付计划、成本预估等等，这个过程就是一个标准的产品设计过程，只不过在中台项目中大多是针对中台类的产品而已。
第四个阶段就是 Delivery，这个时候我们就可以针对一个设计好的中台，开始具体的交付过程，我们采用的是敏捷结合精益软件开发的方式，用快速迭代和基于反馈的调整，最大程度地弥补由中台建设本身的复杂度带来的设计偏差和其他的交付问题，并且注重架构的治理与守护，减少实现与设计的偏离。
整个 D4 过程，是一个从战略到落地，从企业架构到产品架构最终交付的过程。而且遵循敏捷与精益的思想，整个 D4 的过程也是不断迭代的，例如每一个季度到半年，我们可以重新做一次轻量的 Discovery 和 Define，来不断对企业架构做敏捷的调整，以应对市场和自身的变化和不确定性。
# Discovery：调研
从第一个阶段 Discovery 开始，我们要先建立一个对企业和行业的“全面视野”。完成这个分析和调研，我们可以使用头脑风暴工作坊来先发散再收敛聚合。
下面引用一个ThoughtWorks的完整工作坊线路图：
对于中台的整体规划，也就是回答要不要建中台、建哪些中台、谁先建谁后建这些问题，我们现在也是通过这样一个过程来评估和判断的。
一个成熟的企业在做信息化建设之前需要问自己一些问题,比如：
- 我需要花多少钱在数字化建设上？
- 我的钱应该怎么花？怎么分配？要新增哪些系统，是购买还是自研？要干掉哪些系统？优化哪些系统？继续维护哪些系统？保持哪些系统不变？
- 建个中台？
- ……
信息化建设其实本质上是一个资源分配问题，也是一个我们怎么把钱花的最值的问题，回归到问题的本质，有时候我们会发现建中台只不过是解决业务问题的其中的一个潜在选项而已，潜在的解决方案之一，即基于企业的战略和现状，我们需要在应用架构中添加一个中台层来解决目前企业遇到的问题。如图：
中台这种解决方案到底适合不适合企业，仍然是需要调研和判断的。如图所示，如果一个企业连基础的前台和后台的建设都不具备，那可能并不适合盲目搭建中台。所以，如果我们一开始就把中台作为一个确定的既定方向，难免会限制住我们的视野，有可能会错过比中台更好、更简单、更有效的解决方案，或是过早地进行过度设计，在根本不需要中台的场景下，大张旗鼓地开展中台建设，劳民伤财。
那企业到底要不要划分出一部分钱和资源来做中台建设？对公司来讲添加中台这样一个新的架构层次有什么价值？什么时候做最好？优先级怎么样？这也正是头脑风暴所主要关注和需要回答的问题。
而为了避免拍脑袋的情况出现，Discovery 作为头脑风暴的前半程，主要目的就是做充分的发散和调研，也就是利用各种工具和手段帮助我们充分了解行业趋势、竞争对手的情况、公司的战略分解以及自下而上的现状调研等信息和环境，为下一个阶段 Define 的收敛，也就是对于企业新的业务架构、应用架构、技术架构甚至是组织架构的设计，提供充分的信息支撑和依据。
整体上，Discovery 又可以简单分成由外到内、自上而下和自下而上的三个不同方向的过程。
# 由外到内：行业与竞争对手分析
在详细了解自身之前，我们有必要先将视野放开一些，看看行业的大趋势与竞争对手都在做些什么。我们其实可以看看同一个行业中的其他企业在做什么？战略都是什么？数字化建设的重点又是什么？有没有同时在做中台建设？建设的目标又是什么？效果怎么样？
但这里要注意的是，分析不一定就代表要直接借鉴，人家都在建中台我们就要建中台，这个思路不可取，因为即使处于同一个行业，但是由于企业愿景战略、商业模式、客户群体等差异，每家企业也都不尽相同。
不过向其他企业学习也有一些好处，比如：
- 一是如果其他企业有好的概念或是方法，我们可以借鉴过来，帮助自己的企业在自己的行业里取得先机。中台这个概念起始于互联网行业，目前就正在被各个行业参考和借鉴。
- 另一个好处，就是如果发现更好的机会，能够实现企业跨行业的跃进，可能就抓住了走上另一个快车道的机会。话说回来，目前很多企业的中台建设，目的就是识别企业核心能力，沉淀到中台，并以此为跳板和支撑，进行业务的创新和探索，想要跳到另一个更有发展的全新赛道上。
业界已经有了很可以直接使用的分析方法，例如常见的：五力模型，SWOT，商业模式画布，竞争对手产品线分析，竞争态势分析矩阵等。
# 自上而下：企业战略分解
如果说头脑风暴最主要的一个产出物是数字化建设的蓝图和路线图，那头脑风暴的输入就是企业层面的愿景和战略。企业如果没有明确的愿景下，就开始大范围、大规模的进行中台建设是注定会失败的。这样的企业常常连基本的两层系统的架构都没完备，没有学会走是跑不起来的。
那战略是什么呢？所谓战略，就是如何达成目标与能力的平衡，并根据环境变换做出合适的调整。如图：
依据战略平衡三角形，如果在企业的愿景和目标已经确定的情况下：
- 企业战略就可以简化理解成：结合企业自身的能力与其所处的环境，到底需要采取什么样的举措，才能实现企业预定的愿景和目标。
- 而企业战略分解就可以简化理解成：结合企业各部门自身的能力与其所处的环境，到底需要采取什么样的举措，才能实现企业预定的愿景和目标。
我们也可以**使用精益价值树（Lean Value Tree）**的工具来帮助做战略愿景的分解：
这个过程，就是自上而下的战略分解过程。而某一个中台，它可能只是最终推导出的一个具体的举措而已，向上还是要能追溯到对于企业愿景和目标的关联性和价值上，匹配和对应企业的愿景目标。
# 自下而上：现状调研与分析
每家企业经过长时间在市场中的搏杀，能生存并发展到现在，都会出现各种各样的问题和限制。如果脱离现状，无视这些问题与限制，就肯定会面临非常大的阻力与风险。所以我们不但要自上而下地做企业战略的分解，以此来帮助我们思考中台或是其他举措是否必要。同样需要充分地做自下而上的现状调研，来帮助我们了解现状和历史。一方面充分尊重过去遇到的所有问题，收集汇总痛点；另一方面又要求我们能跳出过去的限制，重新从业务出发，从用户出发，去重新探索基于新技术、新架构下的一些新的可能性。
充分且多维度的现状调研与分析，不但能让我们对于业务、应用、技术、数据、组织现状，也就是企业架构现状有一个全面清晰的认识，还可以通过访谈与调研，补充时间线上的上下文，包括过去发生了什么？为什么现状是这样子的？未来大家希望是什么样的？为什么？不过这里有一个问题你可能需要关注，那就是梳理的范围和深度。不要忘了我们此时做的是企业级的架构梳理，宽度和范围可能会远远超过我们的想象。如果深度控制不好，会发现转了半天还是在一个小的领域和业务线原地打转，今年我看到了不少此类的笑话。
面对这种问题和风险，我们其实可以：
- 先完成自上而下的企业战略分解，再开展自下而上的现状调研。因为做完战略分解，我们已经对于公司的行业、业务、愿景、战略已经有了一些了解，再开展调研的时候就会有个全局的把控，对于粒度和深度都更容易拿捏。
- 做好充分的准备，能够提前通过阅读资料和小范围调研完成的内容就提前完成。
- 制定详细的计划，可以按照现状调研的总时间倒推梳理的范围和粒度。如果时间足够，可以用两天的时间梳理一条业务线的业务架构，这样梳理就可以深入一些。但如果只有半天，则粒度可以适当放粗，先保证有一个全局业务视图。
- 建议刚开始做的时候，可以粒度粗一些，不要过早陷入细节，不过粒度到底如何控制确实需要对于公司战略以及业务有深入理解，也是最见功夫的地方，我看到了很多自以为是的咨询顾问，做了很多可笑的事情。在判断不好的时候，可以先粗一些，如果最后还有时间，也可以再做一轮调研向下再展开一层。
这里我们常用的调研和实践工具有很多，例如高层访谈、干系人地图、组织架构分析、战略设计思维、业务架构现状梳理、用户旅程、服务蓝图、领域驱动设计、应用系统现状梳理、技术架构现状梳理等等。
# Define：规划
我们通过 Discovery 从三个不同的角度和方向，对企业内外部环境进行充分的信息收集之后，得到了非常多的信息，此时运用企业架构方法分析可以形成企业的数字化全景规划，以及中台落地建设的演进路线图。同时我们要在不同业务线中寻找共性能力，总结下来基本上就是四类：业务数据、业务功能、业务流程以及通用的技术能力。
# 企业架构方法
企业架构方法如 Zachman、TOGAF 等，其实已经非常成熟了，其中应用最广的应该就属 TOGAF 了。TOGAF 的基本思路，就是从企业最新的愿景战略以及运营模式出发，设计企业的 To-Be 业务架构，然后依次推导，一步一步推导数据架构、应用架构、技术架构，就是这样一个过程。
在做以中台为潜在预设目标的企业数字化全景规划时，基于 Discovery 发散收集来的各个维度的信息，在 Define 阶段结合自上而下企业战略分解的举措和自下而上现有业务架构梳理和分析的问题及痛点，重新设计新的业务架构，同时可以进一步推导出其它的相关的架构设计。
整个过程也可以做剪裁和轻量化处理，引入了事件风暴、DDD 工作坊等协作互动形式，整个过程各个关键角色充分讨论，协作共创，力争在过程的轻量前提下，还能保证结果的准确与一致。领域驱动设计（DDD），结合事件风暴，对业务流程背后的问题域进行分析，以及通过不同业务线的问题域重合度分析，可以帮助我们透过流程洞见企业各业务的本质，寻找共性业务元素。
# 中台与微服务有什么关系?
我认为，中台和微服务没有关系。因为中台和微服务解决的是不同的问题，也处于不同的抽象层次。中台解决的是业务（数据、功能、流程）复用的问题，而微服务是一种轻量级的分布式技术架构，解决的是“组件编译时依赖”造成的问题。业务中台不一定是微服务架构的，微服务架构也不一定是为了解决能力复用的问题。
那么微服务是什么？
百度上的答案是：“所谓的微服务是SOA架构下的最终产物，该架构的设计目标是为了肢解业务，使得服务能够独立运行。微服务设计原则：1、各司其职 2、服务高可用和可扩展性”。微服务从技术上看是将组件间的依赖点从“编译时”推后到了“运行时”，这带来的好处是非常多的。因为依赖被推迟到了“运行时”，才可能实现类似于“组件独立交付”、“组件运行时动态扩展”、“组件技术异构”等好处，但同样也需要承担分布式架构带来的复杂度作为代价。
还有微服务架构要想真正发挥价值，主要一点就是其中的“服务”要做到足够稳定（说来容易做起来具难）。所以，业务中台与微服务架构并没有啥直接关系，只是因为微服务架构运行时依赖的低耦合特性，通常被用于实现业务中台中不同能力单元的团队分离、技术分离、交付周期分离等特性而已，只能算是一对好搭档。
# 平台型企业架构规划
- 首先通过各条业务线的现有业务架构分析，再结合识别的痛点做的根因分析，做业务架构上的改进与设计，从而对于现有的业务架构进行改进，设计出新的改进后的业务架构，解决现在痛点背后的问题。
- 参考战略分解后对于各条业务线的目标和举措，融入 To-Be 业务架构的设计当中，使新的业务架构设计同时匹配企业战略要求以及解决短期战术痛点。
- 对于改进后的业务架构，做跨业务线的比对和分析，就能帮助我们发现不同业务线的业务功能及业务流程的重叠情况，为后续中台建设的必要性判断提供业务层面上的支撑和输入。
- 使用领域驱动设计（DDD）的战略部分，针对于每条业务线，做问题域和限界上下文分析，以及关键聚合的识别，从而试图穿越流程，从领域的角度深入一层审视业务的本质，到底是在解决哪些问题空间的问题，并通过问题域的划分（核心、通用、支撑），区分问题空间对于企业的重要性。
- 类似于业务架构，同样对于各条业务线分析出来的领域分析视图，做横向比对和投影，从领域层识别不同的业务线中的问题域、限界上下文以及聚合的重合度。这么可能比较抽象，你、可以理解成类似于将几张半透明的画摞在一起，来找相交部分一样。帮助我们识别业务数据以及业务模式（功能 + 流程）上的深层次共性能力。
- 结合现有的业务架构及应用架构，做各条线的应用架构设计改进，并通过 As-is 和 To-Be 的应用架构做 Gap 分析，产出 IT 建设的具体机会点。
- 基于跨域的业务架构分析和跨域的领域分析，讨论判断多条业务线的业务重合度，并详细识别重合更多是在业务模式级别的重合（货控、费控）、业务功能级别的重合（登录，活动）、还是业务领域（用户数据打通）级别的重合。基于讨论结果，决定是否有必要引入中台层建设，以及根据重合情况，详细展开规划中台层的应用架构。
- 最后再分析当前现状与 To-Be 的最终规划之间的差距，产出具体的机会点列表，并且基于多维度（常见的例如战略重要性、紧急程度、成本、资源就绪情况、技术就绪情况、风险、痛点 Mapping 等）做优先级排序，产生最终的路线图。
# Design：设计
在设计阶段，我们需要回答的问题就是中台的愿景是什么？包含哪些内容？从哪儿开始落地？完成设计阶段，应该就能清晰地知道如何开始进行中台建设，可以让团队开始中台 MVP 的开发工作了。
# 确定中台产品愿景
设计的第一步还是要先搞清楚这个业务中台的愿景和目标，因为这是我们整个中台建设过程的基础，也是中台建设的初心。举一个反面的例子，我们公司对于IT建设总结下来就是一句话：”领导说要做，我们做就是了“。这样很危险～
我们可以使用工具来帮我们发散和收敛产品的愿景，这个工具就是电梯演讲（Elevator Pitch）。顾名思义，电梯演讲假设的场景，就是我们在电梯上偶遇公司管理层，能否在有限的时间内给对方讲清楚我们在做的事情，比如中台。这就要求我们做到足够的收敛。因此电梯演讲的形式，主要是限定了几个产品最关键因素，比如用户是谁，解决什么问题，差异化特点是什么等等。其中每一个要素都非常重要，如果你回答不出来，或是团队的回答不一样，就在一定程度上体现出大家对于中台建设的愿景还没有达成一致，也就为后续各种问题的出现埋下了祸根。
愿景的价值和难点就在于充分收敛。我们公司的愿景虽然也用了电梯演讲的方式，但是结果满满地铺了一面墙，看着虽然震撼，但是其实效果是大打折扣的，毕竟我们也没法在一个电梯时间复述完一整面墙的内容。
# 确定业务范围
中台产品的愿景确定后，下一步就需要进行细粒度的业务架构梳理，抽取共性，识别中台产品的具体需求了。
如果公司整体规模不是特别大，其实做全业务端到端的业务梳理是可以的，而这样的好处也是比较全面不容易出现遗漏，对于企业的业务现状能有一个整体的全貌，识别的中台共性需求也会比较准确。
如果是多业务线的大型集团型企业，做全业务的端到端梳理基本上是不可能的，要不然仅仅是协调人员就是一个麻烦的问题。这时候我们就需要先确定一个范围，再在这个范围内进行业务的梳理和展开。
那这个范围该如何划定呢？我们需要找到这个产品的愿景，有了清晰的愿景，就可以让我们的业务梳理更加聚焦。首先从业务线上来看，就不一定所有的业务线都需要梳理，如果和产品的愿景目标也没有太大的直接关系，所以可以先直接跳过。基于中台的建设愿景，我们就可以在横向端到端价值链和纵向的业务线上收敛到一个聚焦的区域。再在这个聚焦的区域中进行业务梳理和展开，就会更加有效率和聚焦。
# 细粒度业务梳理
在确定了梳理范围之后，接下来就是具体的业务梳理工作了。一般大家的做法都是基于现有的流程或系统，对现有业务的流程进行梳理，具体指的是信息流、用户流、资金流、物流的梳理工作，使用的工具也大多是流程图这种非常成熟的工具。
但是这种基于已有流程的梳理有时候会有一些限制，简单讲就是可能会基于过去遗留的业务债推导出伪中台需求。什么意思呢？就是对于一些长期且成熟的业务，现有的业务方式可能并不是一个最好的方式，而是由于长时间发展以及和过去的各种周边限制以及 IT 限制妥协的产物。举个例子，往往时间比较长的业务线都会有非常复杂的审批审核流程。但是审核和审批流程其实只是一种解决方案，要解决的问题可能是过程造假或是其他的一些内部风险和问题。复杂的审批流程也往往是信息化时代甚至是更早的纸质时代的过程管控的产物，由于信息化更多只是将线下的流程线上化，所以一直延续至今，而且为了高度复刻还原纸质时代的流程，还非常中国特色地出现了各种的奇怪的审批逻辑，例如会签等等。
但是如果我们重新回到问题域，重新思考问题本身，我们就发现可能在当今这个数字化的时代，我们可能不再需要流程审批这样一个过程。通过新的技术，我们可以用实时的审计分析或是风险识别来发现业务过程中的一些异常，甚至通过完全的自动化，消除中间人员参与的环节，从根本上解决这些问题，从而真正发挥数字化的威力。
基于现状的传统业务流程梳理不同，在业务梳理过程中可以大量地采用了基于设计思维，结合**用户体验地图（User Journey Map）和服务蓝图（Service Map）**的方式。回到业务本身，从问题域出发，以用户为中心，进行用户体验设计和业务服务蓝图的梳理。
通过范围内的业务架构梳理，再结合最后的跨场景通用能力的分析，我们就可以对关注领域的业务全貌有了一定深入的了解，并且可以识别出不同业务线中一些可复用的业务数据、业务功能与业务流程。而这些通用的业务数据、业务功能、业务流程经过加工分析就形成了中台的具体需求。对于这些需求，我们可以通过用户故事（User Story）的方式去描述。
# 确定MVP
通过业务梳理，我们识别和整理了大量的业务中台需求。值得注意的是，此时的所谓中台产品需求，更多的是来源于定性抽象，再考虑到中台的需求往往不像前台业务系统的需求那样明确，所以，从严格意义上来讲，此时的需求仍属于一系列高风险的假设。
以我今年的工作经历来看，往往一开始的需求到真正开发完成后，都与最初的设想有较大的偏差。这就意味着系统的建设周期越长，需求假设的风险和需要为之付出的代价就越大。我们在系统的建设过程中，可以引入精益创业中的 MVP 原则（Minimum Viable Product，最小可用品）。为了实现 MVP，保证做出来的 MVP 可用，我们在业务需求上采用端到端纵向切分的方式，结合需求优先级的多维度评分排序，最终确定 MVP 的需求范围，而最终落地的形式可能就是第一个迭代的用户故事列表。
# 制定迭代和接入计划
提前考量运营计划尤其是接入计划，尽量使用合理的接入计划（我看到有很多企业把这个接入计划叫作上车计划，非常形象）来规避一些风险，对于中台产品的建设非常关键。
# 定义验证指标
市面上最常见到的产品度量指标，分为了四个大类，也就是战略类、用户类、市场拓展类与降本提效类。基于每一个维度展开，都能找到很多的常用度量指标。例如：
我们一般在考虑中台的度量指标的时候，还是把战略价值和业务价值作为出发点，开始拆解和推导，并且按照干系人关注点的不同，用多维度、多层次的指标设计来审视中台建设的效果。这里要强调一下，虽然维度和视角不同，我们要保证所有指标体现的中台建设目标必须是一个。
# Delivery：交付
交付的第一步一定是要组建一支有战斗力的队伍，中台的建设需要的能力与传统产品还是有比较大的差别。孙志岗老师的中台人员能力模型，表达了对于团队能力的要求。
当组建了一支成型的中台建设团队之后，其实后续的建设工作就和我们一般的项目或产品的建设过程类似了。我们建议采用精益的产品研发流程，保持小步迭代、快速建设、快速度量、快速反馈、快速调整的流程，保证系统建设是一个持续演进和被业务驱动的过程。
# 精益产品研发流程
精益产品研发流程，主要是面对中台建设过程中的不确定性，引入精益思想来实现价值的定义和快速流动及度量，再结合敏捷开发实践，让整个软件开发过程轻量、迅速、敏捷、价值驱动。
精益思想之所以流行，关键在于其定义了一套完整的思想框架，而最终核心目标就是消除浪费、创造价值。在中台的实际建设过程中，小批量快速开发产品，快速引入度量，基于测量的数据快速对于之前的需求假设进行验证和认知，并做出快速的调整。
精益和敏捷现在确实是常常掺在一起来讲的，我很多时候没有搞清楚两者的区别。敏捷和精益到底有什么区别？简单来讲，敏捷关注的是价值确定的情况下，如何通过小步快跑的迭代方式按节奏交付价值；而精益关注的则是在价值并不确定的情况下，如何用最小成本，快速定位到真正价值点。
# 中台的运营、治理与演进
对于中台的整体治理和运营机制，目前业界的理解也不太一致，毕竟中台作为一个企业的平台类产品，服务的不是企业的最终用户，所以和互联网里经常提到的基于产品的用户侧运营还不太一样，中台在位置上更像是企业内部的一个服务企业前台应用的 ToB 产品。
做运营，我们第一步要搞清楚的产品的用户划分。中台作为一个公共服务部门，一定会碰到多个前台的需求、排期、质量要求、非功能需求出现不同的情况，甚至也会经常出现多个前台之间的需求或是非功能性需求彼此矛盾的时候。而中台的资源有限，且有自己的愿景，不可能无条件地满足所有前台用户的诉求，往往就会陷入疲于应对的状态，对前台的响应和服务质量也会急速降低。
如果我们采用产品化的思维来构建中台，那中台中所沉淀的能力并不是产品的全部，还需要再加上 NFR（非功能性需求）或是我们常说 SLA（Service-Level Agreement，服务等级协议）才是产品，因为不同的前台用户之间，不只是对于中台产品的功能本身有着不同的诉求，同样对于 NFR 或是 SLA 也有着不同的诉求。简单举个例子，比如核心业务对于中台的 SLA 稳定性的要求可能是 5 个 9，性能是 5 毫秒；而一个新的创新型应用，可能还没有用户，就不需要有这么高的要求。
既然如此，如何利用有限的资源，服务好不同用户的不同诉求呢？答案就是对于前台用户基于需要的能力和 NFR/SLA 做用户划分。这听起来可能会觉得有些新鲜，但是其实环顾一下我们周围，很多的产品都是这样来处理用户划分，从而实现用户的分层响应与运营的。
而最常见的就是三层用户划分机制（3 tiers customer segmentation）。通过对于前台用户的分层，我们就可以为不同层次的用户指定不同的需求响应机制、不同的沟通管理机制、不同的服务质量控制机制、不同的问题处理及升级机制等等。自然不同的服务类型作为前台用户也需要付出不同的成本或是资源（人或钱），甚至前台与中台可以通过签署 SLA 来实现对于前台用户的服务承诺。
通过中台的用户分层和运营机制，就可以构建不同层次的运营体系，从而实现资源的合理调配。我们也就避开了前面提到的中台建设过程中的各种问题和陷阱，对用户分级运营，从而解决需求矛盾、排期冲突、资源紧张、推广缓慢等问题。