作者：费伟伟
上海华瑞银行数字银行开发中心
要真正落地中台，首先要理解中台的含义和了解中台的价值才能进行中台落地。本篇文章将从落地中台前必须明确的4个问题、中台建设难点和落地中台的步骤这几个维度来讲解中台落地最佳实践，让大家对落地中台有个概念上的RoadMap。
1. 落地前明确4个问题
在落地中台前一定要考虑清楚以下4个问题，不要只是听说中台能够解决成本，提高创新能力，提高新产品落地速度就跟风去落地中台。中台不是银弹，一定要搞清楚中台的价值，不然最后会建设成一个四不像。
中台建设愿景是什么？
了解愿景能够帮助我们了解中台建设的目标，帮助我们判断哪些事情是符合中台建设愿景的，作为中台团队我们需要去考虑。在这之外，更重要的是帮助我们判断哪些事情不是中台要去做的，为中台做减法，这点在中台建设过程中更重要。如果不给中台做减法那么最后中台将变为一个功能大杂烩，并不是一个抽象共享可以高度复用的中台。
在建设初期，项目往往在试点阶段，可支配资源不多，如果没有明确的方向，没有明确的前台中台的功能边界，那么就会把中台团队变成一个内部共享的外包团队。
在建设中台前，对于中台建设愿景要让所有角色，上到企业管理层，下到每一位中台人员都要明确并达成一致意见，这样才能保证再未来建设和推广过程中，所有人能有一致的思想。
中台的用户是谁？
落地中台肯定需要明确中台的用户是谁？中台的用户指的是哪些前台系统需要使用中台服务，并不是传统意义上的对外用户。只有明确了中台的用户才能知道未来这个系统的服务对象，并将这些服务用户需要的功能进行抽象共享。
中台因为作为一个共享平台一定会有很多服务用户，但是中台不应该只是极力去满足各方诉求，中台团队毕竟不是前台业务的外包团队。中台需要有自己的思想和规划，要能做到听得进别人的话，还要明确自己的目标。自己的目标，就是来源于上面提到的中台建设愿景，中台的愿景往往来源于企业的战略需要。
中台建设虽然需要兼顾多方利益，但更多主要还是解决企业管理层对于公司长期生存与可持续发展的恐惧和焦虑问题。
中台的钱由谁出？
做任何一个系统都会涉及到费用问题，这个费用往往也是一个系统建设的重要问题，需要明确中台系统建设由谁出钱，往往谁出钱谁对这个系统就有话语权。
众筹模式
从各前台业务众筹，前台业务往往会关注短期利益，因为前台业务作为出资方往往希望能短期帮助自己解决问题。
因为出资方众多，导致每一方业务需求都要听，最后成为前台业务的外包团队。
统一出资模式
统一出资模式就是一个中台产品前期由公共方出资，按照产品的建设目标，相对成熟后，再逐渐让用户使用。这个公共方可以是全公司的共享产品部或者是一个中立机构。
目前在互联网公司用的比较多的模式还是统一出资模式，这样可以保证中台不会受前台业务部门所左右，能够按照自己的规划有序进行发展，不会受多个业务部门所左右。
中台的目标如何验证？
中台系统的KPI其实很难量化，前台的很多成绩都是依赖中台的共享服务，但是很难量化中台对前台业务影响多大，而且很容易背锅，中台服务有问题影响前台业务开展，前台部门往往会投诉。
所以在中台建设初期就要明确如何度量中台，防止出现后期扯皮的现象。业务中台的考核指标一般也不会设定为交易金额之类的业务KPI，这里可以参考下阿里巴巴的中台系统考核模型，阿里巴巴的中台KPI设计为：40%稳定性+25%业务创新+20%服务接入量+15%客户满意度
2. 中台建设难点
看了这么长时间中台觉得中台设计的难度跟设计一个普通系统的难度不是一个数量级的，你可能可以根据一个业务需求设计好一个系统，但是你不一定能根据一个中台产品需求设计出一个好的中台系统，中台系统的设计难度主要体现在要对这个中台领域的所有业务线都足够了解。
站在全公司的角度考虑问题
如果是企业级问题，回归到业务上，也和过去做系统完全不同。你面对的将是企业的全貌，甚至是那些未来才会出现的，现在还不知道长什么样子的潜在的创新业务。
做中台的错误思维：一直用一个系统级产品和架构的方式，试图来解决一个企业级产品和架构的问题，这种狭隘的设计思路必然会导致设计的中台系统最终还是成为一个局限在某单个业务的系统，无法顾全到全公司相关业务领域。
在设计中台的时候，我们本质上是设计一个企业级的架构，一个融入了平台新要素的企业级架构。
改变基于业务流程的架构
传统的EA方法多是比较重的流程，需要做长时间大量的调研，梳理流程，浪费了很多时间，而且流程无法高度复用。相对于传统的EA方法，设计中台需要完全换个思路，不再是重点关注业务流程，而是关注同一业务领域中不同业务流程中可以复用下沉的服务。
中台设计就是换个思路做乐高积木，让前台自己去组合。
3. 中台实施路径
这里引用ThoughtWorks总结的中台实施路径4D步骤，其中包含了Discovery、Define、Design、Delivery 4个阶段，但是目前大家讨论最多的其实都是Design阶段，讨论某一个业务中台应该下沉哪些服务，如何设计中台的产品，如何做服务设计。但是除了Design，在整个中台实施过程中，更重要的是前面两个阶段，Discovery和Define阶段，这两个阶段会去分析目前全公司的业务现状、技术现状，通过顶层设计来规划未来的业务蓝图和技术蓝图，这两个阶段会定义出目前公司内的业务方向和未来的中台整体规划，哪些业务领域适合建设中台，哪些不适合，哪个领域先建设，哪个领域后建设，框定了范围后才能保证整体中台战略路线不走偏。
Discovery：发现公司业务未来发展方向和现状
第一阶段Discovery，帮助我们在中台规划前建立全局视野。在这个过程中我们以企业愿景和战略为输入，结合行业趋势，竞争对手分析，用户客群分析，业务现状分析，IT资产盘点，全方位多角度的理解企业的战略市场环境以及业务及IT全貌，帮助我们做出最准确判断。
Discovery的过程又可以分为由外到内、自上而下和自下而上三个不同方向的过程。
由外到内
由外到内的过程其实主要是对竞争对手的分析过程，在分析之前先抬头看看目前同行业的对手都在做什么，他们的业务发展方向和产品线都有哪些，只有做到知己知彼才能百战不殆。我们要去了解同行业中的其他企业在做什么？战略是什么？数字化建设的重点又是什么？有没有同时在做中台建设？建设的目标又是什么？效果怎么样？
在了解竞争对手的同时也要去思考，并不是直接抄袭别人的战略和规划，人家在建中台我们就要建中台，这个思路肯定有问题，因为即使是同一个行业，但是由于企业背景、企业战略、主要客户群体、核心商业模式等差异，每家企业也都不相同，所以不能直接拿来主义，而是要了解之后再结合自身情况进行分析讨论。
了解外部竞争对手的过程更多的是一个拓宽自身视野的一个过程，去其糟粕取其精华。
自上而下
讨论出了企业战略之后，必须要对战略进行自上而下的拆解，不然这样的战略最终还是一句口号，没有可实施性。分解企业战略有很多方法，用的比较多的是精益价值树，用它来帮助做战略愿景的分解。
精益价值树是一种以价值成效为导向，用于分析和沟通业务愿景和战略的工具。它的核心是建立从愿景、目标到投资举措自上而下的对齐，因此采用一种逐层分解的树形结构。
这个过程，就是一个自上而下的战略分解过程，对于某一个中台，它可能只是最终推导出的一个具体的举措而已，向上还是要能追溯到对于企业的愿景和目标的关联性和价值上，匹配企业的愿景目标。
自下而上
在自上而下分解了企业的愿景和目标之后，并不是直接拿着分解的措施去开干了，还需要对企业当前的现状进行一个分析，每家企业经过长时间在市场中的摸爬滚打，能发展到现在，一定会出现各种各样的问题，如果脱离现状，无视问题直接朝着目标走那么一定会遇到很多问题。
所以我们不但要自上而下的做企业战略分解，还需要做充分的自下而上的现状分析，一方面发现和汇总之前遇到的问题和痛点，另一方面又要能跳出问题，重新从业务出发，从用户出发，去重新探索基于新技术、新架构下的一些新的方法。
Define：定义企业数字化全景规划
第二阶段是Define，帮助我们基于之前Discovery发散的各维度信息进行收敛与分析，对于中台的架构进行定义。通过对跨业务线的业务梳理进行重合度分析，并结合领域分析对业务表象之后的企业核心问题域做进一步展开和重合度分析，一起收敛推导基于中台的企业架构设计。这个阶段要分析出哪些需要建立中台，哪些不需要。
下面列举下一个完整的数字化全景规划过程：
1）首先通过各条业务线的现有业务架构进行分析，再结合识别的痛点做的根因分析，做业务架构上的改进与设计，从而对于现有的业务架构进行改进，设计出新的改进后的业务架构。
2）同时还要参考战略分解后对于各条业务线的目标和举措，融入业务架构的设计当中，使新的业务架构设计同时匹配企业战略要求以及解决短期战术痛点。
3）对于改进后的业务架构，做跨业务线的对比和分析，就能帮助我们发现不同业务线的业务功能及业务流程的重叠情况，为后续中台建设的必要性判断提供业务层面上的支撑和输入。
4）使用领域驱动设计DDD的战略分析方法，针对每条业务线，做问题域和限界上下文分析，以及关键聚合的识别，从而试图穿越流程，从领域的角度深入一层审视业务的本质，到底是在解决哪些问题域的问题，并通过问题领域中核心域、通用域、支撑域的划分，区分问题域对于企业的重要性。
5）对于各业务条线分析出的领域分析视图，做横向对比和投影，从领域层识别不同的业务线中的问题域、限界上下文以及聚合根的重合度，识别出数据以及业务功能和流程上的深层次的共性能力。
6）结合现有的业务架构以及应用架构，做各条线的应用架构设计改进，并通过分析产出IT建设的具体机会点。这些机会点可能就是目前技术架构中欠缺的，通过建设能够很好的促进业务发展。
7）再基于跨领域的业务架构分析和跨领域的领域分析，讨论判断多条业务线的业务重合度，并判断出是在业务模式上的重合、业务功能级别的重合还是业务数据领域级别的重合。基于讨论的结果决定是否又必要引入该领域的中台建设。
8）最后再分析目前现状与目标的差距，整理出具体的机会点清单，并且基于战略重要性、紧急程度、成本、资源情况、技术情况、风险等多维度做优先级排序，产出最终的RoadMap。
技巧：通过DDD领域驱动设计识别共性能力
使用DDD通过工作坊的形式来对业务流程背后的问题域和解空间做进一步分析，识别出关键聚合，再通过跨业务线的问题域取交集，找出大家公共关注的问题域和聚合，从而继续扩展来做共享场景和共享能力识别。
识别出共享问题域后再对问题域展开，就能识别出在这些重合的问题空间下，到底有哪些共性的业务数据、业务功能和业务流程，从而完成复用能力的识别。
Design：中台设计
第三个阶段是Design，帮助我们针对实施路径中的某一个产品，例如业务中台，做详细的设计，包括产品级的业务需求分析、功能及架构设计、实施计划等。
聚焦业务需求范围
对于很多企业来说，涉及的业务线都很广，做全业务的端到端梳理基本上是不可能的，这时候就要先确定业务范围，然后再这个范围内进行业务的梳理。
细化业务需求
确定业务范围后，接下来就要进行业务细化。这里建议不要根据原产品业务流程进行归纳，其实原先的流程设计可能受限于历史的各类问题，导致做了很多妥协，在中台重新细化业务的时候，可以回到问题域本身，根据第一性原则，基于用户需求在当前业务及技术条件下，重新设计解决方案，可以避免原先流程里的业务债和技术债。
通过范围内的业务架构梳理，再结合跨场景通用能力的分析，就可以对关注的问题域的业务全貌有了一定深入的理解，并且可以识别出不同业务线中一些可复用的业务数据、业务功能与业务流程。而这些通用的业务数据、业务功能、业务流程经过加工分析就形成了中台额度具体需求。
确定MVP最小可用单元
通过业务梳理，识别和整理了大量的业务中台需求，此时的中台需求，更多的是来源于定性的人为抽象，但是中台的需求往往不像前台业务系统需求那样明确，所以此时的中台需求荏苒属于高风险假设。
对于这么多高风险假设需求，如果等需求全部做完才去开始让前台接入中台，那很可能造成中台功能和前台系统的要求并不十分匹配，所以面对这样的高风险需求，通常会先上一些确定性高的和需求最小级，先上一个MVP版本。
制定迭代计划、接入计划
在开始开发前就要计划好中台的迭代计划，每个迭代计划上的功能，前台产品的接入计划，这些都要提前确定好，这样可以方便前台业务部门确定产品上线计划、推广计划，防止出现未来前台中台产品迁移和上线的混乱。
定义验证指标
对于中台来说验证指标是比较难确定的，因为在市场和用户之间隔着前台，所以在度量上就不如前台产品那么清晰。但是中台是为前台赋能的，也不能脱离业务只看技术指标，这样也不符合中台对于业务支撑赋能的定位。
所以在设置中台验证指标的时候，需要从不同维度去分析，要从业务价值作为出发点，开始拆解和推导，并按照干系人关注点的不同，从多维度、多层次的指标设计来验证中台建设的效果。
常见的中台指标有以下两部分：
1）业务层指标：
- 新业务产品中台使用情况
- 中台为新业务产品节约成本
- 中台为新业务产品带来的用户量
- 新业务产品上线时间
2）应用层技术指标：
- 新业务产品中台接口接入量
- 新业务产品中台接口稳定性SLA
- 新业务产品中台接入满意度
Delivery：中台建设和产品迁移
中台对开发团队的要求比一般的业务系统开发团队要求要高很多，因为中台所处的特殊位置，对于产品界定要求和建模的难度，都比其他前台业务产品的复杂度要高一个级别，所以建议采用小步迭代、快速建设、快速度量、快速反馈、快速调整的流程，保证中台建设是一个持续演进和被业务驱动的过程。用快速迭代和基于反馈的调整，最大程度的弥补由中台建设本身的复杂度带来的设计偏差和其他交付问题，并且注重架构的治理与守护，减少实现与设计的偏离。
产品迁移的过程是建设中台必须要面对的一个问题，中台建设完成后需要将前台产品逐步迁移到中台，对于前台产品有几种做法，最直接的就是直接基于中台产品直接重新搭建前台产品，还有种做法是改造现有前台产品，但是这对于现有产品的改造可能较多，而且如果原先的产品架构设计较复杂，那么改造的成本也是巨大的。这里推荐的做法也是，如果原业务系统架构设计较完善，开发团队对该系统把控度较高，那么直接在原基础上重构前台将服务迁移到中台，如果原产品开发团队把控度较差，那么还是直接重建前台会比较好。
总结
本篇文章从整个中台落地的全流程进行了讲解，从企业中台建设的愿景开始，到对企业现有业务的分析，再对中台需求和建设步骤重新进行聚焦，再到具体某个中台的设计过程，最后讲述了下中台建议采用敏捷迭代开发方式和前台产品的迁移。读完这篇文章大家应该对中台落地整个全貌有了个了解，需要记住一句话，中台建设不是针对某个系统的中台建设，而是从全企业角度考虑的中台建设，一定要站在高处进行中台的设计。
