中台即企业级能力复用平台
企业级定义了中台的范围。 它更多代表的是中台处理的问题在企业级别，即至少包含多条业务线或服务多个前台产品（团队），如果一个中台只为了支持一条业务线或产品线，那就不是中台，即使它用了服务化或是大数据等技术。
企业级这一点非常非常重要。它让我想清楚了，中台建设的事情并不是一个技术问题，而是一个要上升到企业架构的问题。做中台建设的时候，一定是跳出单条业务线、站在企业整体视角来审视业务全景。
能力定义了中台主要承载的对象。因为每家企业的核心能力是不同的，所以每家企业的中台建设都是不一样的。
复用定义了中台的核心价值，也承载了上面讲到的从平台化到中台化的演进过程。
平台定义了中台的主要形式。区别于传统的应用系统拼凑的方式，通过对于更细粒度能力的识别与平台化沉淀，实现企业能力的柔性复用，更好地支撑前台业务。
从广义上来看所有的中台，不论是业务中台还是数据中台，亦或其他中台，它都是为业务，为企业可以更好地以更低的成本、更高的质量、更快的响应速度售出产品、换取利润的服务平台。
从狭义上来看，业务中台需要具体承载支撑业务开展的必要业务元素，封装着为了保障业务可以顺利开展需要解决的必要问题空间的解决方案。
这么说可能会比较空，我有一个技巧，当我思考业务中台时，我会不断地问自己一个问题：企业的业务能够顺利开展，需要解决哪些核心问题？
比如电商的场景，如果我是一家电商企业，我业务要顺利开展，即把我的产品卖给用户，换取利润，一般要解决的核心问题无非包含：
将企业能力进行沉淀与复用。通过中台的确定性和前台的灵活性，让企业拥有快速试错、快速创新的能力。
以用户为中心的持续规模化创新
业务中台承载了企业的通用业务能力，为多业务线赋能；数据中台通过对于业务数据的二次加工，并反馈回业务中台，为业务进行数据和智能方面的赋能。
以用户为中心，从战略入手，愿景为指引，用科学有效的方法，步步为营沉淀企业级能力，辅以必要的组织与系统架构调整，方得中台。
中台建设之前我们需要判断下中台建设的“周边环境”是否已经准备就绪。如何在判断呢？主要从一下四个方面入手：
愿景即为中台建设的核心目标，“遇事不决看愿景”，这是我在做中台规划和落地过程中，说得最多的一句话。只有明确了愿景我们在后续中台建设过程中才能以此为依据判断那些事情应该中台去做那些事情是需要前台建设。
更重要的是这个愿景是需要所有的角色，上到企业管理层，下到每一位中台的相关人员都要明确并达成一致的。
干系方即明确中台的客户、用户和中台建设的所涉及的组织等。中台建设往往都会伴随企业内的组织重构以及利益和职责的再分配。
业务方更加关注中台的短期战术价值，它们更加希望中台能够快速、稳定的提供多样化的能，方便前台业务能快速响应用户需求，解决实际问题。但企业管理层却更加关注中台长期的战略价值，关注中台长期沉淀下来的复用能力。所以在中台建设过程中我们需要兼顾各方的利益，但更多主要还是解决企业管理层对于公司长期生存与可持续发展的恐惧与焦虑问题。
范围即中台建设的资源应该由谁来出，是前台业务方抽调资源（众筹模式），还在使用企业本身的战略储备资源（投融资模式），或者两者混用。
如果企业建设中台的愿景，是为了解决偏短期战术层面的痛点和问题，可以采用众筹模式加演进式的投资结构来启动，这样的好处是中台的启动会比较平滑，资源利用率高，初期新增成本较低。但如果中台建设的目标是偏长期战略层面的问题，比如业务转型，那还是建议更多地考虑使用企业战略投资，使用投融资模式，这样更利于中台建设的健康快速发展。
度量即如何衡量中台建设的成果。中台建设很难通过常见的如用户量、活跃度、市场占有率等指标去衡量其建设成果，所以在建设之初我们需要根据中台建设目标去制定中台建设成果，如阿里巴巴的中台考核就是设计成：40% 稳定性 +25% 业务创新 +20% 服务接入量 +15% 客户满意度。
以传统的企业架框架为基础（TOGAF），融入战略设计思维（DesignThinking）来解决创新的问题，融入领域驱动设计（Domain-Driven Design）来解决中台化能力识别的难题，再通过融入敏捷与精益的思想来解决过程重、流程长、变化响应力低的问题，集众家之长，调和出一套新的企业级架构方法，也就是中台这种面向用户与创新的平台型企业架构。
第一个阶段是 Discovery，帮助我们在中台规划前先建立全局视野。在这个过程中我们以企业愿景和战略为输入，结合行业趋势、竞争对手分析、用户客群分析 、业务现状分析、IT 资产盘点，全方位多角度地理解企业的战略市场环境以及业务及 IT 全貌，帮助我们做出最正确的判断。
第二个阶段是 Define，帮助我们基于之前 Discovery 发散的各维度信息进行收敛与分析， 对于中台的架构进行定义。通过对跨业务线的业务梳理进行重合度分析，并结合领域分析对业务表象之后的企业核心问题域做进一步展开和重合度分析，一起来收敛推导基于中台的企业架构设计。并基于多维度的打分，形成具体的实施路径规划，说白了就是先做什么后做什么。这里需要注意一点，此时收敛的是仍是企业架构层面，像业务中台、数据中台这种级别的产品，可能只是实施路径中的一个项目，在这个阶段也可以回答那个我们关心的问题，我们到底需不需要中台，需要哪些中台？
第三个阶段是 Design，帮助我们针对实施路径中的某一个产品，例如业务中台，做详细的设计，包括产品级的业务需求分析、功能及架构设计、实施计划等。例如对于业务中台产品，在 Design 阶段我们需要回答产品的愿景、边界、产品形态、技术架构、交付计划、成本预估等等，这个过程就是一个标准的产品设计过程，只不过在中台项目中大多是针对中台类的产品而已。
第四个阶段就是 Delivery，这个时候我们就可以针对一个设计好的中台，开始具体的交付过程，我们采用的是敏捷结合精益软件开发的方式，用快速迭代和基于反馈的调整，最大程度地弥补由中台建设本身的复杂度带来的设计偏差和其他的交付问题，并且注重架构的治理与守护，减少实现与设计的偏离。
中台建设原则：既要想得长远，又要快速切入，并保持持续演进。在应对不确定性和复杂性都异常高的中台规划与建设任务时，这样的原则尤其适合和必要。
D4 的前两部分 Discovery 和 Define 合起来，就是一个在企业级先发散再收敛的过程。这个过程有一个称呼，叫作 Portfolio Discovery（投资组合规划），简称为 PD。PD 是一个 4～8 周的头脑风暴工作坊，下图为你展示了一个完整的 PD 工作坊路线图：
对于中台的整体规划，也就是回答要不要建中台、建哪些中台、谁先建谁后建这些问题。
整体上，Discovery 又可以简单分成由外到内、自上而下和自下而上的三个不同方向的过程。
要从一家企业的发展过程这条主线上来看待中台这件事情，来看这个点。它从哪里来？为什么会出现？又将向哪儿去？甚至思考中台的下一个阶段会是什么？会被什么替代？我在观察一家企业的中台建设历程，包括整个中台大趋势的形成和发展的时候也是这样来看的。
有了线就足够了么？还不够，我们还需要再上升一个维度，来看看同一个行业中的其他线，也就是同一行业中的其他企业在做什么？战略都是什么？数字化建设的重点又是什么？有没有同时在做中台建设？建设的目标又是什么？效果怎么样？
但这里要注意的是，分析不一定就代表要直接借鉴，人家都在建中台我们就要建中台，这个思路不可取，因为即使处于同一个行业，但是由于企业愿景战略、商业模式、客户群体等差异，每家企业也都不尽相同。
最后还要跳出面，从更高的维度“体”，来审视企业所在的这个行业本身，或者从其他的行业，其他的面上来学习。
“点 - 线 - 面 - 体”的理论：中台建设对于企业发展历程是一个"点"；通过企业的发展过程来看待中台建设这件事情是一条"线"；对比类似企业建设中台这件事情就是一个"面"；站在企业所在的这个行业本身，或者从其他的行业，其他的面上来学习就是一个"体"。
行业与竞争对手分析行业有很多成熟方法，比如波特五力模型，SWOT，商业模式画布，竞争对手产品线分析，竞争态势分析矩阵等。
SWOT模型主要根据企业的内部和外部环境，找出企业自身的优势（Strengths）、劣势（Weaknesses）、机会（Opportunities）以及威胁（Threats）之所在，然后给出应对的方法。这一模型的名称正是由上述几个英文单词的首字母缩写而来。SWOT方法的优点在于考虑问题全面，是一种系统思维，而且可以把对问题的“诊断”和“开处方”紧密结合在一起，条理清楚，便于检验。
商业画布是指一种能够帮助创业者催生创意、降低猜测、确保他们找对了目标用户、合理解决问题的工具。
商业画布不仅能够提供更多灵活多变的计划，而且更容易满足用户的需求。更重要的是，它可以将商业模式中的元素标准化，并强调元素间的相互作用。
商业模式画布图 由 9 个方格组成，每一个方格都代表着成千上万种可能性和替代方案，你要做的就是找到最佳的那一个。
所谓战略，就是如何达成目标与能力的平衡，并根据环境变换做出合适的调整。
依据战略平衡三角形，在企业的愿景和目标已经确定的情况下：
精益价值树（Lean Value Tree）工具可以用来帮助做战略愿景的分解。精益价值树是一种以价值成效为导向，用于分析和沟通业务愿景、战略与投资的工具。它的核心是建立从愿景、目标到投资举措自上而下的对齐，因此采用一种逐层分解的树形结构，如下示意图：
所以我们不但要自上而下地做企业战略的分解，以此来帮助我们思考中台或是其他举措是否必要。同样需要充分地做自下而上的现状调研，来帮助我们了解现状和历史。一方面充分尊重过去遇到的所有问题，收集汇总痛点；另一方面又要求我们能跳出过去的限制，重新从业务出发，从用户出发，去重新探索基于新技术、新架构下的一些新的可能性。
这里我们常用的工具和实践也很多，例如高层访谈、干系人地图、组织架构分析、战略设计思维、业务架构现状梳理、用户旅程、服务蓝图、领域驱动设计、应用系统现状梳理、技术架构现状梳理等等。
TOGAF 的基本思路，就是从企业最新的愿景战略以及运营模式出发，设计企业的 To-Be 业务架构，然后依次推导，一步一步推导数据架构、应用架构、技术架构，就是这样一个过程。
为了解决如何从企业整体的视角，更准确地识别出多业务线之间的共性业务元素，在TOGAF的基础上融入领域驱动设计（DDD），结合事件风暴，对业务流程背后的问题域进行分析，以及通过不同业务线的问题域重合度分析，帮助我们透过流程洞见企业各业务的本质，寻找共性业务元素。
第一个问题，如果说中台就是企业级能力复用平台，那在做企业架构设计的过程中：
商业运营模型分析方法：
通过这个方法运用到中台建设上，如图：
由此可见在不同业务线存在如下公共能力：业务数据、业务功能、业务流程以及通用的技术能力。
SaaS 抽象层次高，更靠近业务，但对于业务的标准化要求高，灵活度小。业务中台正好反之，抽象层次较 SaaS 低，介于 PaaS 和 SaaS 之间（所以很多企业管业务中台叫 ApplicationPaaS，或是 BussinessPaaS），离业务较 SaaS 远一些，但更灵活。
首先通过各条业务线的现有业务架构分析，再结合识别的痛点做的根因分析，做业务架构上的改进与设计，从而对于现有的业务架构进行改进，设计出新的改进后的业务架构，解决现在痛点背后的问题。
同时还要参考战略分解后对于各条业务线的目标和举措，融入 To-Be 业务架构的设计当中，使新的业务架构设计同时匹配企业战略要求以及解决短期战术痛点。
对于改进后的业务架构，做跨业务线的比对和分析，就能帮助我们发现不同业务线的业务功能及业务流程的重叠情况，为后续中台建设的必要性判断提供业务层面上的支撑和输入。
使用领域驱动设计（DDD）的战略部分，针对于每条业务线，做问题域和限界上下文分析，以及关键聚合的识别，从而试图穿越流程，从领域的角度深入一层审视业务的本质，到底是在解决哪些问题空间的问题，并通过问题域的划分（核心、通用、支撑），区分问题空间对于企业的重要性。
类似于业务架构，同样对于各条业务线分析出来的领域分析视图，做横向比对和投影，从领域层识别不同的业务线中的问题域、限界上下文以及聚合的重合度。这么可能比较抽象，你可以理解成类似于将几张半透明的画摞在一起，来找相交部分一样。帮助我们识别业务数据以及业务模式（功能 + 流程）上的深层次共性能力。
结合现有的业务架构及应用架构，做各条线的应用架构设计改进，并通过 As-is 和 To-Be 的应用架构做 Gap 分析，产出 IT 建设的具体机会点，这样的机会点就类似于新建一个 CRM 系统之类的。
再基于跨域的业务架构分析和跨域的领域分析，讨论判断多条业务线的业务重合度，并详细识别重合更多是在业务模式级别的重合（出行、电商）、业务功能级别的重合（登录，购物车）、还是业务领域（用户数据打通）级别的重合。基于讨论结果，决定是否有必要引入中台层建设，以及根据重合情况，详细展开规划中台层的应用架构。
最后再分析当前现状与 To-Be 的最终规划之间的差距，产出具体的机会点列表，并且基于多维度（常见的例如战略重要性、紧急程度、成本、资源就绪情况、技术就
在这个阶段我们需要对建设中台所搜集到的信息做充分的收敛，这里可以推荐一个比较好的工具电梯演讲，通过这种方式可以保证我们的目标能充分的收敛、统一、简单易懂。愿景的价值和难点就在于充分收敛。
通过中台建设的愿景去决定需要梳理那些业务线。
在确定了梳理范围之后，接下来就是具体的业务梳理工作了，使用的工具也大多是流程图这种非常成熟的工具。
在业务梳理过程中大量地采用了基于设计思维，结合用户体验地图（User Journey Map）和服务蓝图（Service Map）的方式。回到业务本身，从问题域出发，以用户为中心，进行用户体验设计和业务服务蓝图的梳理，从效果上来看也是非常不错的。
在中台的建设过程中，引入了精益创业中的 MVP 原则。
在考虑中台的度量指标的时候，还是把战略价值和业务价值作为出发点，开始拆解和推导，并且按照干系人关注点的不同，用多维度、多层次的指标设计来审视中台建设的效果。这里要强调一下，虽然维度和视角不同，我们要保证所有指标体现的中台建设目标必须是一个。
精益产品研发流程，主要是面对中台建设过程中的不确定性，引入精益思想来实现价值的定义和快速流动及度量，再结合敏捷开发实践，让整个软件开发过程轻量、迅速、敏捷、价值驱动。
敏捷关注的是价值确定的情况下，如何通过小步快跑的迭代方式按节奏交付价值；而精益关注的则是在价值并不确定的情况下，如何用最小成本，快速定位到真正价值点。
如何利用有限的资源，服务好不同用户的不同诉求呢？答案就是对于前台用户基于需要的能力和 NFR/SLA 做用户划分。
