运营中台与技术中台，终于有人把业务中台、数据中台、技术中台都讲明白了

关于【运营中台与技术中台】，今天涌涌小编给您分享一下，如果对您有所帮助别忘了关注本站哦。

• 内容导航：
• 1、运营中台与技术中台：终于有人把业务中台、数据中台、技术中台都讲明白了
• 2、运营中台与技术中台，中台实战1

1、运营中台与技术中台：终于有人把业务中台、数据中台、技术中台都讲明白了

导读：2015年阿里巴巴提出“大中台，小前台”的中台战略，通过实施中台战略找到能够快速应对外界变化，整合阿里各种基础能力，高效支撑业务创新的机制。

阿里巴巴中台战略最早从业务中台和数据中台建设开始，采用了双中台的建设模式，到后来发展出了移动中台、技术中台和研发中台等，这些中台的能力综合在一起就构成了阿里巴巴企业级数字化能力。

传统企业在技术能力、组织架构和商业模式等方面与阿里巴巴存在非常大的差异，在实施中台战略时是否可以照搬阿里巴巴中台建设模式？传统企业中台数字化转型需要提升哪些方面的基本能力呢？

下面我们一起来分析分析。

作者：欧创新 邓頔

来源：华章科技

00 中台能力总体框架

中台建设过程从根本上讲是企业自身综合能力持续优化和提升的过程，最终目标是实现企业级业务能力复用和不同业务板块能力的联通和融合。

企业级的综合能力，一般包含以下四种：业务能力、数据能力、技术能力和组织能力，如图2-1所示。

▲图2-1 企业中台数字化转型基本能力框架

• 业务能力主要体现为对中台领域模型的构建能力，对领域模型的持续演进能力，企业级业务能力的复用、融合和产品化运营能力，以及快速响应市场的商业模式创新能力。
• 数据能力主要体现为企业级的数据融合能力、数据服务能力以及对商业模式创新和企业数字化运营的支撑能力。
• 技术能力主要体现为对设备、网络等基础资源的自动化运维和管理能力，对微服务等分布式技术架构体系化的设计、开发和架构演进能力。
• 组织能力主要体现为一体化的研发运营能力和敏捷的中台产品化运营能力，还体现为快速建设自适应的组织架构和中台建设方法体系等方面的能力。
• 这些能力相辅相成，融合在一起为企业中台数字化转型发挥最大效能。接下来，我们一起来看看在不同的领域应该如何实现这些能力。

01 业务中台

企业所有能力建设都是服务于前台一线业务的。从这个角度来讲，所有中台应该都可以称为业务中台。但我们所说的业务中台一般是指支持企业线上核心业务的中台。

业务中台承载了企业核心关键业务，是企业的核心业务能力，也是企业数字化转型的重点。业务中台的建设目标是：“将可复用的业务能力沉淀到业务中台，实现企业级业务能力复用和各业务板块之间的联通和协同，确保关键业务链路的稳定高效，提升业务创新效能。”

业务中台的主要目标是实现企业级业务能力的复用，所以业务中台建设需优先解决业务能力重复建设和复用的问题。通过重构业务模型，将分散在不同渠道和业务场景（例如：互联网应用和传统核心应用）重复建设的业务能力，沉淀到企业级中台业务模型，面向企业所有业务场景和领域，实现能力复用和流程融合。

图2-2是一个业务中台示例。在业务中台设计时，我们可以将用户管理、订单管理、商品管理和支付等这些通用的能力，通过业务领域边界划分和领域建模，沉淀到用户中心、订单中心、商品中心和支付中心等业务中台，然后基于分布式微服务技术体系完成微服务建设，形成企业级解决方案，面向前台应用提供可复用的业务能力。

▲图2-2 业务中台示例

在技术实现上，中台的系统落地可以采用微服务架构。微服务是目前公认的业务中台技术最佳实现，可以有效提升业务扩展能力，实现业务能力复用。

在业务建模上，中台领域建模可以采用领域驱动设计（DDD）方法，通过划分业务限界上下文边界，构建中台领域模型，根据领域模型完成微服务拆分和设计。

业务中台可以面向前台应用提供基于API接口级的业务服务能力，也可以将领域模型所在的微服务和微前端组合为业务单元，以组件的形式面向前台应用，提供基于微前端的页面级服务能力。

业务中台建设完成后，前台应用就可以联通和组装各个不同中台业务板块，既提供企业级一体化业务能力支撑，又可以提供灵活的场景化销售能力支撑。

02 数据中台

数据中台与业务中台相辅相成，共同支持前台一线业务。数据中台除了拥有传统数据平台的统计分析和决策支持功能外，会更多聚焦于为前台一线交易类业务提供智能化的数据服务，支持企业流程智能化、运营智能化和商业模式创新，实现“业务数据化和数据业务化”。

最近几年，数据应用领域出现了很多新的趋势。数据中台建设模式也随着这些趋势在发生变化，主要体现在以下几点。

第一，数据应用技术发展迅猛。近几年涌现出了大量新的数据应用技术，如NoSQL、NewSQL和分布式数据库等，以及与数据采集、数据存储、数据建模和数据挖掘等大数据相关的技术。这些技术解决业务问题的能力越来越强，但同时也增加了技术实现的复杂度。

第二，数据架构更加灵活。在从单体向微服务架构转型后，企业业务和数据形态也发生了很大的变化，数据架构已经从集中式架构向分布式架构转变。

第三，数据来源更加多元化，数据格式更加多样化。随着车联网、物联网、LBS和社交媒体等数据的引入，数据来源已从单一的业务数据向复杂的多源数据转变，数据格式也已经从以结构化为主向结构化与非结构化多种模式混合的方向转变。

第四，数据智能化应用将会越来越广泛。在数字新基建的大背景下，未来企业将汇集多种模式下的数据，借助深度学习和人工智能等智能技术，优化业务流程，实现业务流程的智能化，通过用户行为分析提升用户体验，实现精准营销、反欺诈和风险管控，实现数字化和智能化的产品运营以及AIOps等，提升企业数字智能化水平。

面对复杂的数据领域，如何建设数据中台管理并利用好这些数据？

这对企业来说是一个非常重要的课题。

数据中台的大部分数据来源于业务中台，经过数据建模和数据分析等操作后，将加工后的数据，返回业务中台为前台应用提供数据服务，或直接以数据类应用的方式面向前台应用提供API数据服务。

数据中台一般包括数据采集、数据集成、数据治理、数据应用和数据资产管理，另外还有诸如数据标准和指标建设，以及数据仓库或大数据等技术应用。图2-3是2017年阿里云栖大会上的一个数据中台示例。

▲图2-3 数据中台示例（图参考：2017年阿里云栖大会）

综上所述，数据中台建设需要做好以下三方面的工作。

• 一是建立统一的企业级数据标准指标体系，解决数据来源多元化和标准不统一的问题。企业在统一的数据标准下，规范有序地完成数据采集、数据建模、数据分析、数据集成、数据应用和数据资产管理。
• 二是建立与企业能力相适应的数据研发、分析、应用和资产管理技术体系。结合企业自身技术能力和数据应用场景，选择合适的技术体系构建数据中台。
• 三是构建支持前台一线业务的数据中台。业务中台微服务化后，虽然提升了应用的高可用能力，但是随着数据和应用的拆分，会形成更多的数据孤岛，会增加应用和数据集成的难度。在业务中台建设的同时，需要同步启动数据中台建设，整合业务中台数据，消除不同业务板块核心业务链条之间的数据孤岛，对外提供统一的一致的数据服务。用“业务+数据”双中台模式，支持业务、数据和流程的融合。

数据中台投入相对较大，收益周期较长，但会给企业带来巨大的潜在商业价值，也是企业未来数字化运营的重要基础。企业可以根据业务发展需求，制定好阶段性目标，分步骤、有计划地整合好现有数据平台，演进式推进数据中台建设。

03 技术中台

业务中台落地时需要有很多的技术组件支撑，这些不同技术领域的技术组件就组成了技术中台。业务中台大多采用微服务架构，以保障系统高可用性，有效应对高频海量业务访问场景，所以技术中台会有比较多的微服务相关的技术组件。

一般来说，技术中台会有以下几类关键技术领域的组件，如API网关、前端开发框架、微服务开发框架、微服务治理组件、分布式数据库以及分布式架构下诸如复制、同步等数据处理相关的关键技术组件，如图2-4所示。

1. API网关

微服务架构一般采用前后端分离设计，前端页面逻辑和后端微服务业务逻辑独立开发、独立部署，通过网关实现前后端集成。

前台应用接入中台微服务的技术组件一般是API网关。

API网关主要包括：鉴权、降级限流、流量分析、负载均衡、服务路由和访问日志等功能。API网关可以帮助用户，方便地管理微服务API接口，实现安全的前后端分离，实现高效的系统集成和精细的服务监控。

2. 开发框架

开发框架主要包括前端开发框架和后端微服务开发框架。基于前、后端开发框架，分别完成前端页面逻辑和后端业务逻辑的开发。

前端开发框架主要是面向PC端或者移动端应用，用于构建系统表示层，规范前后端交互，降低前端开发成本。

▲图2-4 技术中台关键技术领域

微服务开发框架用于构建企业级微服务应用。一般具备自动化配置、快速开发、方便调试及部署等特性，提供微服务注册、发现、通信、容错和监控等服务治理基础类库，帮助开发人员快速构建产品级的微服务应用。

开发框架一般都支持代码自动生成、本地调试和依赖管理等功能。

3. 微服务治理

微服务治理是在微服务的运行过程中，针对微服务的运行状况采取的动态治理策略，如服务注册、发现、限流、熔断和降级等，以保障微服务能够持续稳定运行。

微服务治理主要应用于微服务运行中的状态监控、微服务运行异常时的治理策略配置等场景，保障微服务在常见异常场景下的自恢复能力。

微服务治理技术组件一般包括服务注册、服务发现、服务通信、配置中心、服务熔断、容错和微服务监控等组件。

常见的微服务治理有Dubbo、Spring Cloud和Service Mesh等技术体系。

4. 分布式数据库

分布式数据库一般都具有较强的数据线性扩展能力，它们大多采用数据多副本机制实现数据库高可用，具有可扩展和低成本等技术优势。

分布式数据库一般包括三类：交易型分布式数据库、分析型分布式数据库和交易分析混合型分布式数据库。

• 交易型分布式数据库用于解决交易型业务的数据库计算能力，它支持数据分库、分片、数据多副本，具有高可用的特性，提供统一的运维界面，具备高性能的交易型业务数据处理能力。主要应用于具有跨区域部署和高可用需求，需支持高并发和高频访问的核心交易类业务场景。
• 分析型分布式数据库通过横向扩展能力和并行计算能力，提升数据整体计算能力和吞吐量，支持海量数据的分析。主要应用于大规模结构化数据的统计分析、高性能交互式分析等场景，如数据仓库、数据集市等。
• 交易分析混合型分布式数据库通过资源隔离、分时和数据多副本等技术手段，基于不同的数据存储、访问性能和容量等需求，使用不同的存储介质和分布式计算引擎，同时满足业务交易和分析需求。主要应用于数据规模大和访问并发量大，需要解决交易型数据同步到分析型数据库时成本高的问题，需要解决数据库入口统一的问题，需要支持高可用和高扩展性等数据处理业务场景。

5. 数据处理组件

为了提高应用性能和业务承载能力，降低微服务的耦合度，实现分布式架构下的分布式事务等要求，技术中台还有很多数据处理相关的基础技术组件。如：分布式缓存、搜索引擎、数据复制、消息中间件和分布式事务等技术组件。

• 分布式缓存是将高频热点数据集分布于多个内存集群节点，以复制、分发、分区和失效相结合的方式进行维护，解决高并发热点数据访问性能问题，降低后台数据库访问压力，提升系统吞吐能力。典型的开源分布式缓存技术组件有Redis。
• 搜索引擎主要解决大数据量的快速搜索和分析等需求。将业务、日志类等不同类型的数据，加载到搜索引擎，提供可扩展和近实时的搜索能力。
• 数据复制主要解决数据同步需求，实现同构、异构数据库间以及跨数据中心的数据复制，满足数据多级存储、交换和整合需求。主要应用于基于表或库的业务数据迁移、业务数据向数据仓库复制等数据迁移场景。数据复制技术组件大多采用数据库日志捕获和解析技术，在技术选型时需考虑数据复制技术组件与源端数据库的适配能力。
• 消息中间件主要适用于数据最终一致性的业务场景，它采用异步化的设计，实现数据同步转异步操作，支持海量异步数据调用，并通过削峰填谷设计提高业务吞吐量和承载能力。它被广泛用于微服务之间的数据异步传输、大数据日志采集和流计算等场景。另外，在领域驱动设计的领域事件驱动模型中，消息中间件是实现领域事件数据最终一致性的非常关键的技术组件，可以实现微服务之间的解耦，满足“高内聚，松耦合”设计原则。典型的开源消息中间件有Kafka等。

分布式事务主要是解决分布式架构下事务一致性的问题。单体应用被拆分成微服务后，原来单体应用大量的内部调用会变成跨微服务访问，业务调用链路中任意一个节点出现问题，都可能造成数据不一致。分布式事务是基于分布式事务模型，保证跨数据库或跨微服务调用场景下的数据一致性。

分布式事务虽然可以实时保证数据的一致性，但过多的分布式事务设计会导致系统性能下降。因此微服务设计时应优先采用基于消息中间件的最终数据一致性机制，尽量避免使用分布式事务。

技术中台是业务中台建设的关键技术基础。在中台建设过程中，可以根据业务需要不断更新和吸纳新的技术组件，也可以考虑将一些不具有明显业务含义的通用组件（如认证等），通过抽象和标准化设计后纳入技术中台统一管理。为了保证业务中台的高性能和稳定性，在技术组件选型时一定要记住：尽可能选用成熟的技术组件。

关于作者：欧创新，某大型保险公司架构师，拥有十多年的软件架构设计经验。热衷于DDD、中台和分布式微服务架构设计。在DDD、中台和分布式微服务架构设计方面有深厚的积累，擅长分布式微服务架构设计。邓頔，某大型保险公司高级工程师，全国青年岗位能手。致力于基于DDD的企业级中台微服务架构改造实践，精通前端开发相关技术栈，拥有丰富的企业级微前端实战经验。

本文摘编自《中台架构与实现：基于DDD和微服务》，经出版方授权发布。

延伸阅读《中台架构与实现》

推荐语：资深架构师撰写，系统阐述基于DDD的中台和微服务建设方法论，深刻揭示中台从领域建模到微服务落地完整过程。

2、运营中台与技术中台，中台实战1

在我的上一篇文章中，我已经为大家用一个做菜的例子通俗的介绍了什么是中台？如果大家还不清楚中台是什么，可以先看我的这篇文章《最近处处惹人爱的中台到底是什么》。本篇开始我将以系列更新的形式分多个专题来为大家详细剖析中台要怎么做？

要进行中台的建设，我们首先要意识到中台的建设与传统的业务线维护是不同的，这两者之间最大的区别就是：中台建设是一个根据企业业务方向变化而动态发展的过程。

所以要想建设好中台，我们就要学会调研与预判业务，本文以一个事业线负责人的视角，带大家来看看很多看起来毫无章法的公司业务发展路径，背后是根据什么因素不断演化的。

一、业务正常迭代流程

我们先以电商事业线为例，看看如何单一事业线如何是如何演化的。

首先在整个电商系统上线初期，由于业务量不大整个电商后台我们通常是融合在一起开发的，也就是一个后台里面集合了订单中心、商品中心、会员中心等，这些中心只是后台系统的一个独立模块。

我们就以商品中心来看，在随着业务量的增长，电商公司为了更高效的去进行商品管理会将一个商品模块开始独立并扩充变为一个独立的商品中心，让商品运营团队不再在原后台里操作。

此时我们的第一步先将商品模块独立出来成为一个全公司的商品中心的子系统。在随着发展我们发现将所有的商品操作都由一个商品中心进行维护支撑是非常费劲的，例如商品管理中的商品信息管理与进出库管理，这是两个完全不同的业务。在商品数量种类急剧上升的时候，以往我们可能是一个业务团队来管理的商品信息与库存，在此时就无法放在同一个模块中维护。

所以我们就需要将库存模块从商品中心中独立出来，单独成为一个库存中心事业线。接着我们在发现价格模块在商品中心中由于商品数量的增加与电商的营销方式增多，价格管理机制也需要单独完善。我们发现此时的价格管理系统也需要单独维护，因此价格系统也需要拆分为价格管理与价格走势管理。因此整个产品迭代发展的路径如下图所示。

图：电商后台系统演化

我们可以看到由商品中心我们演化出了三个独立的中心，商品中心、价格系统与库存中心。

二、企业战略演进

除了事业线的演化，下一步我们要学会掌握公司业务多元化发展历程。相比大家应该经常会在很多产品场合听到——从0到1这一词，那么从0到1到底是个什么过程？负责人又是如何定义企业发展战略的。

让我们以一家虚拟公司：A影视票务公司的业务多元化发展历程，看一个企业如何在发展中去不断根据行业发展情况，去动态调整自己的业务战略。

阶段1：行业初期探索

小明是A影视票务公司的产品经理，公司起家其实是靠卖电影票，电影票的盈利就是在挣电影票的票务服务费。一张65元线下的电影票公司能拿到20元，并以35元前后的价格出售，一张票毛利15元。

由于此时主营业务只有电影票的售卖，所以公司的产品架构如下图所示。

图：前后台模式

但是随着行业成熟不断会有竞争者进来，特别当这个市场中的巨头在发现了这一新兴市场后，投入了新的产品阿里的淘票票、猫眼电影，还有各大影院的官方APP等，但是整个市场也就是看电影的人群就这么多，此时大家为了能抢占市场份额，开始了最常见也是最有效的方法：打价格战。各大票务平台的电影售价开始竞争式下降，你卖35块，我就降到30块甚至更低。

此时小明要面对的除了商业模式上的惨烈竞争外，还有个头疼的任务，老板让他去做数据分析，主要去分析两个部分：

• 公司占有的市场份额统计：也就是每日平台日活是多少？
• 降价效果评估：同类型电影，我每降价一元，所带来的购票用户转化率是多少？来购票的用户都是哪些类型人？

面对这个样的需求，小明建设出了如下图的数据中心。

图：数据中心关键模块架构

但是由于各家的票价补贴，一时间市场很快就发展到一个饱和期了，公司利润骤降。

阶段2：业务多元化战略启动

这个时候作为一个企业的决策者就要想了，我们不能把鸡蛋都放到一个篮子里，万一哪一天在这个票务市场我们被阿里击败了，下一步公司要去哪儿挣钱呢？所以企业的业务多元化就拉开了帷幕。

正常来说，企业的多元化都是会优先考虑要去往上下游产业链条中进军，因为这样既可以巩固自己的现有业务，又能利用原来的售票的基础去实现多元化简直就是一箭双雕。

但是又要怎么进军，进军哪呢？实际上此时摆在企业的问题就已经转换为了在一个价值链中要如何锁定自己的目标？

当然这个时候作为企业中唯一的产品经理小明就被老板赋予了这个使命去进行探索，接到这个任务，小明的第一件事就是去通过市场分析了解电影的整个产业链全貌，经过一番调查他得出了整个电影产业链可以划分为如下图的7步：

图：电影产业链

那这7步中，又要从哪个环节入手呢？在将上面的调研结果与老板汇报后，他们有了这样的思考决策：

因为公司的基因毕竟不是电影专业的，而拍电影又是一个对专业度要求极高的产业。对于之前的公司业务形态中完全没有这个基础，更没有任何编剧与导演策划的能力，所以此时如果要切入电影制作领域，这个部分就需要投入很大的财力与物力去从零开始建设。而失败的风险极高，所以制作电影的前5个高门槛环节的就直接被战略放弃了，此时就排除了如下图的五步。

图：产业链排除法

此时小明再去看电影的产业链，也就只剩下来了发行和上映这两个环节，小明又进行了一次分析，他发现上映这个环节也就是将电影送去电影院进行播放，而对于上映环节本质就是要能有足够多的影院，此时影片方才会和你谈判让出利润.

那么此时作为我们一个轻资产的公司，没有线下实体的场地，如果要去进行这一步，首先要去建设电影院或者说是与其他电影院进行联合，但是这又意味着漫长的合作谈判等待与巨大资源投入，所以上映这一也就被排除掉了。

现在摆在A公司面前的就只剩下了发行的这个业务，发行是什么呢？其实就是帮助电影公司去做宣传，让人们知道这个电影，具体来说分为线上的信息分发与线下的电影院渠道合作两部分。

此时老板在听完小明的阐述后，觉得这个方案很合适。

之前的售票业务，让A公司已经积累一大群的电影消费者的画像与用户来此购买电影票习惯的沉淀，这完全可以进行精准投放电影广告。而接下来只需要去与线下影院建立一个发行的渠道合作就行了。

有了这样的分析后，老板就让小明策划了一个新业务线：发行业务线，主要帮助电影厂商去做发行外包，具体业务为由A公司向自己平台的用户去推荐电影与线下统一向各大影院发布电影信息。而对应的系统功能拓展也如下图所示。

图：新业务线加入后的产品架构

而影视公司在看到这个业务后也纷纷选择了这种外包方式，因为这比以往的电影公司在地铁站无差别的烧广告靠谱多了，A公司的所有的用户都是电影用户，可以说这个平台已经将电影爱好人群筛选出来了，在这投放广告的精准度将大幅提高。

伴随着新业务的发展，原来在票务业务线中专门有一部分人员是去维护影院信息与影院关系的，而新成立的发行业务线要想与影院建立发行关系，需要去进行线下拜访洽谈，也需要这样一份的影院资料，包含影院的介绍信息，影院地址与影院联系人名单。

阶段3：企业内部资源整合

此外由于帮助影视公司发行，也就意味着与影视公司建立起了良好的合作关系，那么这个时候相较于其他票务公司都能获得的排片上市的公开信息之外，我们还可以从电影公司拿到很多内部消息与更早的一手信息源，这个时候无疑可以大大丰富我们的电影资讯库，与同行建立起竞争壁垒。

但是这个时候小明仔细研究这两个业务，他发现这两者有很多重叠的部分，小明开始想我是否能把两个业务线中的模块进行一个合并，让一个服务方同时为两者提供服务，大家觉得是不是有点像业务中台的感觉了？没错，这就是业务中台需求来源的最标准场景。

于是公司业务架构调整开始了，将电影资料库、影院信息库进行了合并形成公司级统一的影视资料库，为两个业务线同时提供服务。

那么这个时候，这家A公司实际上就从一家票务平台演变成了发行平台，票务平台也变为了发行里的一个板块。

但是进入发行平台战略，A企业的后患还未消除，本质上这个业务拓展只是更换了战场，只是暂时的甩开了对手。那如果阿里也进入了这个发行领域和我再次竞争，那我有什么办法去排除这个敌人呢？

再回到产业链中去查看，此时小明发现在这个行业中要想得到话语权，我们就要从电影的最上游，也就是电影投资方去入手。

事实上电影中最大的利益方是谁呢？不是演员也不是导演，这俩本质上都是打工的，真正的挣大钱的就是出品方即投资方。所以小明就向老板建议让我们成为投资方，去锁定唯一的发行权，这样让自己参与到电影制作中去，直接控制主导了宣发，不允许别家来卖票，只能自己去卖，从而完整控制了整个行业。

至此A公司又从发行平台演化成了出品平台。总结下A公司的发展历程，先后经历了3个阶段，如下图所示。

图：公司发展的三次转型

到这我们这个案例就讲完了，实际上这个也正是进入互联网下半场后C端企业典型的一个业务发展路径：向自身产业链的上下游进发。可以看到任意一个企业的发展方向很多时候都是由多个因素共同组成的，所以我们平时谈及的“从0到1”、中台业务都需要大家能把握企业这种动态发展的规律，去准确预判出每个阶段中业务的演进方向。

#专栏作家#

三爷，三爷茶馆，人人都是产品经理专栏作家。曾万达高级产品、MBA特约讲师、独立创业者，现某支付公司产品线负责人，拥有多款集团项目从零到一经验并带领实现商业化布局。

本文关键词：技术中台运营可分为能力运营，运营中台功能模块，技术中台运营的核心，运营中台主要是做什么?，技术中台运营可分为能力运营承载运营两个层面。这就是关于《运营中台与技术中台，终于有人把业务中台、数据中台、技术中台都讲明白了》的所有内容，希望对您能有所帮助！