01
小米的三大中台建设：业务+数据+技术
业务中台—从业务说起
在中台建设中，需要规范化的服务接口、一致整合化的数据、容器化的技术组件以及弹性的基础设施。并结合业务情况，判定是否真的需要中台。
小米参考了业界优秀的案例包括移动中台、数据中台、业务中台、技术中台等，再结合其业务发展历程及业务现状，整理了中台架构的核心方法论，一是企业如何共享服务，二是如何为业务提供便利。
通过中台架构方法论和规划方法论，小米信息部提出了小米业务中台建设三年战略，包含了持续优化、构建中以及待新建的系统，纵向分为企业战略、业务执行、业务支撑、数据治理四部分。在2018年成立时，系统还是比较分散的；在2019年，主要围绕中台的架构调整、技术体系下沉，强化运营配置中心三方面，实现绝大多数的共享服务，让小米复杂的业态共享一套体系，更好的支持业务；在2020年，期望整体完善，不断的持续优化。
数据中台—数字化转型的核心
今天大家都在谈数字化转型，数字化转型是转什么？从企业内部来讲，是想如何把一切都数字化，大企业讲数字化转型是很难的一件事情，但现在有些小企业已经做得非常好。系统很简单，但是可以把企业的百十家或者几百家店铺的每一个动作、每一次上下架，甚至是每次的价格变更，每个操作人员的动作，都放到系统里面做记录。
数字化转型，业务是基础，核心是数据。在数据分析及使用过程中，小米主要面临3大问题：
- 数据极度分散：数据都分散在各系统中，没有形成统一共享的数据资源池；各业务域数据尚未形成统一口径，数据从指标层面上未能很好整合。
- 数据指标混乱：数据分析功能偏重于日常统计分析，需建立完备的能支撑精细化管理需求的指标体系；需建立完备的业务分析逻辑，通过建立全面的业务分析场景，“用数据说话”，进而完成趋势预测、异常甄别、辅助决策。
数据工具量少：需要一站式的访问入口、可视化和交互性更强的数据展示方式、支持移动端访问。
（图片来源于网络）
从数据整体来讲，一般分为数据采集、数据清洗，形成数据集市，最后数据分析员才可以在BI去做分析，并提出改进流程，提高业务发展。下图是小米数据中台的架构，底层是大数据平台的基础，在大数据的基础之上搭建了一系列的应用。为了解决以上数据问题，小米信息部成立了X DATA团队专门做数据，更方便地让分析人员在系统上直接分析全部门的任何数据、做报表。只要在权限管控内，分析人员直接得到对应的数据并进行数据分析。小米想从业务端沉淀数据，在共享到X DATA大数据分析，然后发现问题在反馈到业务系统中解决问题。
在数据中台上还需要运用一些关键技术，包括：大数据离线计算、趋势预测、实时计算、自然语言处理、可视化分析、图像识别等。
数据中台对业务运营产生的价值，主要体现在生产监控、日常运营、经营管理、战略管控等方面。最底层的是生产监控管理，如实时运营监控、实时风险监控等；第三层是日常运营型分析，如日常统计分析、操作统计分析等；第二层是经营管理分析与考核型分析，如商业洞察分析、人力资源分析、财务分析、部门绩效考核等；顶层是战略管控与预测型分析，如战略绩效分析、行业对标与企业经营预测分析。
通过对数据中台的建设，小米真正意义上开始走上数据驱动的路程。数据驱动小米的设备研发、生产、供应链、销售、服务以及IOT和互联网业务，产业+互联网格局逐步成熟。数据驱动小米进步，体现在精细化运营、智慧物流探、产业互联网等方面。现在全球都在建仓，到底在什么地方建仓合适，怎么去建仓？这都是要数据分析才能得出。
未来，大数据是为人工智能准备的。
技术中台—更敏捷的开发效率
前面讲的都是偏业务线、偏分析的，但核心最终还是要回归到IT的本质，更敏捷的开发效率才是IT最终的目标。在早期烟囱式的建设中，企业拥有众多的研发团队，但团队人员的基础不一样，工具不一样，面临：重复建设、质量无保证，横向打通困难、技术栈混乱，严重阻碍业务中台建设等问题。
业务&数据中台拥有强大炮火群，为前台业务快速响应直接提供支援，而技术中台是为中台服务提供高度模块化零件&武器库，大幅缩短业务中台建设时间，提高业务中台稳定性。小米通过技术下沉，把最标准的东西沉淀出来，包括IaaS(容灾、机房、数据中心)、PaaS(中间件、研发平台、数据平台)、监控、开发过程的代码，全部陈列到底层，形成技术中台。
滴滴中台建设实践
01
中台搭建背景—业务介绍
滴滴业务包括：
出行。涵盖了专车、快车、豪车、出租车、单车、点单车、代驾等等。
车服。涵盖了加油、充电、维保、长租、短租。
国际化。即滴滴海外业务。
金融。金融相关创新业务。
02
应对多业务面临的问题
跟许多大厂遇到的问题一样，烟囱式的业务线开发团队，在技术深度上无法做到均衡，还是以业务功能实现为主。资源投入上，会存在重复造轮子的问题。数据上形成数据孤岛，浪费资源。在用户体验上还无法做到真正的统一。
03
滴滴中台发展阶段
滴滴中台的发展，经历了四个阶段：
中台前。以实现业务功能为主，往上堆模块。
The one。自上而下、⼤平台模式， 理想化的解决方案，业务发展快、变化大，有沉淀、但未达到理想效果
出行中台。最大业务孵化，⽴足于解决问题，最合适原则，出行中台建成，孵化出部分业务中台。
业务中台。支持多业务线，提升打通能力，赋能业务，提升创新能力，规范业务。
04
做对了什么、做错了什么
**
业务初创期，快速支持业务最重要，中台不是必须的
基于解决问题，快速迭代，更容易成功
最大业务孵化，最适合、最小化原则
意识升级、加强沟通，平衡多业务线
稳定、抽象
05
中台搭建宏观思路
中台搭建宏观思路：
组织升级。如何兼顾既要快速开发，又要形成技术和业务的沉淀，是对组织最大的挑战。
意识升级。从集团军大规模作战，变成特种兵为主在前线呼唤炮火的现代型作战方式。
系统升级。系统沉淀出强大的业务能力，赋能前端业务。
06
中台边界界定
中台边界界定原则：
业务通用。把业务进行抽象，如快车、专车、出租车，其共性的接单、下单逻辑抽象。
多业务。支持集团复杂的业务形态。
下沉机制。将共性业务进行下沉，提升模块的复用性，逻辑统一性。
07
滴滴中台总体架构
滴滴中台总体架构，从上往下：
业务应用层。包括出行、车服、国际化、金融业务线。
业务中台层。包括：用户中心、passport、计价中心、订单中心、支付中心、触达等中台模块。
基础设施层。如RPC框架、日志、监控、大数据平台、搜索等中间件。
08
支付中台—分领域架构设计
以支付中台为例，来了解领域架构设计。主要分成五块：支付产品、支付业务、支付能力、支付中心、运营工具。以此类推，其它业务中台模块按此进行架构规划和设计。
09
高可用、高性能技术实现
在技术架构上，业务中台要具备高可用、高性能的技术要求。各模块以服务化的方式提供能力，有统一网关、服务治理、可伸缩、分表分库数据中间件、影子数据库等。
10
中台面临问题：持续交付乏力
中台面临问题：
1，中台做着、业务看着。中台毕竟力量有限，而且业务专家多在一线，导致交付能力不足的问题。
2，中台排期久，业务不满。中台变成交付的瓶颈，导致业务的不满。
3，业务自己上，中台成为摆设。在业务压力下，许多业务线选择自己上。
11
如何提高持续交付能力？
提高交付能力，不外乎：加人、加班。除此之外，要考虑架构上支持持续加人，也就是说，加了人整个团队的效率是可以线性增加的。
12
具体解法
这里就涉及到架构治理、IT治理了，要对业务进行抽象建模，合理划分边界，人多了不打架。
配置化，尽量解耦。
标准化，使得多个团队能够协作顺畅。
插件化，把规则形成工具，强制执行。
可隔离，各模块架构数据、部署上支持隔离。
若有收获，就点个赞吧
0 人点赞
