中台
厚平台 薄应用
以中台作为企业级能力复用平台来促进前台应用的快速创新
建设前需要想清楚的问题：
- 建设的愿景是什么
- 用户跟客户是谁
- 建设所需的资源由谁出
- 怎么验证中台的建设效果
烟囱式系统的弊端：
- 重复建设带来的浪费
- 打通“烟囱式”系统间交互的集成和协作成本⾼昂
- 不利于业务的沉淀和持续发展
中台种类
- 业务中台：狭义的业务中台，通过将不同业务线解决相同问题域的解决方案进行抽象与封装，通过配置化、插件化、服务化等机制兼顾各条业务线的特性需求，实现对于不同业务线的业务支撑
- [数据中台](/数据技术/数据中台.html)
- 技术中台、研发中台、移动中台...
中台的基础
回归SOA的本质：服务复用
服务需要沉淀，需要不断的业务滋养 持续发展
共享服务是创新的土壤
中台的能力
基础支撑能力：
- 支撑类核心业务
- 抽象通用能力
- 扩展能力开发
多业务支撑：
- 多租户
- 多业务身份
- 隔离保护
附加能力：
- 流程编排
- 垂直中台
中台与前台
前台：贴近客户、变化快、业务驱动
中台：复用驱动、通用抽象
核心功能从前台收敛到中台，使用前台进行差异功能定制
共享服务体系搭建
一个服务中心将给企业的多个应用提供服务
中台建设
核心业务为内核，支撑类核心业务
能力抽象 业务支撑 扩展能力 隔离能力
- 核心业务升级为中台
- 建设之初即为中台
| 建设特点\团队 | 专门团队 | 业务团队 |
|---|
| 通用化建设 | 业务化支撑| 差异化隔离 | 差异化定制| 模型抽象 | 模型具化
现状分析：工具平台、业务发展、历史中台
债务分析：代码质量、重复轮子
组织架构：各团队人手、可投入资源
全景规划
设计规划
- 确定中台愿景：愿景的价值和难点就在于充分收敛，要简短
- 确定业务梳理范围：根据愿景，抽取现有业务共性，识别中台产品的具体需求
- 细粒度业务梳理：设计思维、用户体验地图（User Journey Map）、服务蓝图（Service Map）
- 确定MVP
- 运营前置：早期就要开始制定迭代计、前台应用接入计划
- 度量前置：早期就要以战略价值和业务价值作为出发点，依据愿景，确定衡量中台建设成果的指标
建设接入
通过中台的用户分层和运营机制，就可以构建不同层次的运营体系，从而实现资源的合理调配
谁出的人跟钱多，谁的响应优先级就更高
中心化
ESB（企业服务总线）中心化服务架构的根本诉求：实现异构系统之间的交互
- 网络调用成本
- 中心点雪崩效应
去中心化
服务调用者及提供者直接交互而无需通过服务路由中介
服务中心建设原则
- 技术能力：可靠性 可用性 容错 监控
- 业务能力
为了适应不断发展的业务 服务中心必须不断发展。
服务中心的表现形态：
- 接口
- 直接提供相关工具
- 提供数据
服务中心划分原则：
- 更高的内聚，更低的耦合：服务中心之间的业务隔离性应该是比较大的
- 数据完整性原则
- 业务可运营
- 渐进性设计
问题
- 适用性 中台提供的能力不适合前台
- 需求矛盾 前台需要的能力中台需要考虑更多
确定中台的定位 明确组织保障 确立执行路径