说透中台（落地篇二）--学习笔记

07 | 中台落地第二步：企业数字化全景规划（Define）

企业级架构方法

企业架构方法已经非常成熟了，应用最广的是 TOGAF，它的基本思路是从企业最新的愿景战略以及运营模式出发，设计企业的 To-Be 业务架构，然后依次推导，一步一步推导数据架构、应用架构、技术架构。

在以中台为潜在预设目标的企业数字化全景规划中，参考 TOGAF 思路，基于 Discovery 发散收集来的各个维度的信息，在 Define 阶段结合自上而下企业战略分解的举措和自下而上现有业务架构梳理和分析的问题及痛点，重新设计新的业务架构，并进一步推导出其它的相关的架构设计。

中台复用的能力类型到底有几种？

总结下来基本上就是四类：业务数据、业务功能、业务流程以及通用的技术能力。

通过领域分析识别共性能力

对于已经梳理的业务，使用领域驱动设计结合事件风暴（EventStorming）这两个工具，通过工作坊的形式来对业务流程背后的问题空间和解空间做进一步的分析，识别出关键聚合，再通过跨业务线的问题域叠加投影，找出大家共同关注的问题空间和聚合，从而继续扩展来做共性场景和能力识别。

中台与微服务有什么区别和联系?

业务中台要解决的是业务能力如何快速复用的问题，就算背后是一个大单体，只要暴露出来的 API 能够满足业务能力快速复用的目的也是可以的

微服务架构的关键点是“能够被独立地部署”，这是评判一个微服务架构是否能发挥其价值的关键因素。

业务中台与微服务架构并没有直接关系，只是因为微服务架构运行时依赖的低耦合特性，通常被用于实现业务中台中不同能力单元的团队分离、技术分离、交付周期分离等特性而已，只能算是一对好搭档。

平台型企业架构设计概览

• 业务架构上的改进与设计
• 使用领域驱动设计（DDD）的战略部分，针对于每条业务线，做问题域和限界上下文分析，以及关键聚合的识别
• 对于各条业务线分析出来的领域分析视图，做横向比对和投影，从领域层识别不同的业务线中的问题域、限界上下文以及聚合的重合度
• 基于跨域的业务架构分析和跨域的领域分析，讨论判断多条业务线的业务重合度
• 分析当前现状与 To-Be 的最终规划之间的差距，产出具体的机会点列表

08 | 中台落地第三步：中台的规划与设计（Design）

确定中台产品愿景

推荐一个简单好用的工具来帮我们发散和收敛产品的愿景--电梯演讲（Elevator Pitch）。

电梯演讲假设的场景，就是我们在电梯上偶遇公司管理层，能否在有限的时间内给对方讲清楚我们在做的事情，比如中台。

愿景的价值和难点就在于充分收敛。很多企业的愿景虽然也用了电梯演讲的方式，但是结果满满地铺了一面墙，看着虽然震撼，但是其实效果是大打折扣的，毕竟我们也没法在一个电梯时间复述完一整面墙的内容。

确定业务梳理范围

进行细粒度的业务架构梳理，抽取共性，识别中台产品的具体需求。

基于中台的建设愿景，我们就可以在横向端到端价值链和纵向的业务线上收敛到一个聚焦的区域。再在这个聚焦的区域中进行业务梳理和展开，就会更加有效率和聚焦。

细粒度业务梳理

在业务梳理过程中采用了基于设计思维，结合用户体验地图（User Journey Map）和服务蓝图（Service Map）的方式。回到业务本身，从问题域出发，以用户为中心，进行用户体验设计和业务服务蓝图的梳理，从效果上来看也是非常不错的。

确定 MVP

在中台的建设过程中，引入了精益创业中的 MVP 原则（Minimum Viable Product，最小可用品），也实现了体原则中的 Start Small。

运营前置：制定迭代计划及接入计划

提前考量运营计划尤其是接入计划，尽量使用合理的接入计划来规避一些风险，对于中台产品的建设也非常关键。

度量前置：定义验证指标

我们在之前讲中台建设前需要想清楚的四个问题时，已经讲到过了。具体为什么需要将度量指标设计前置到开发之前，之前已经阐述过了，在这里我就为你分享一些度量指标的设计思路。

对于中台来讲，难就难在与市场和用户之间还隔着一层前台，所以在度量上就不如直接接触用户的前台系统这么清晰。但是我们讲中台是为前台业务赋能的，又不能脱离开业务，单纯只在技术上做一些度量。

所以我们一般在考虑中台的度量指标的时候，还是把战略价值和业务价值作为出发点，开始拆解和推导，并且按照干系人关注点的不同，用多维度、多层次的指标设计来审视中台建设的效果。