| 编辑推荐: |
本文主要展开介绍业务中台和数据中台到底是个什么关系
，希望对您的学习有所帮助。
来自于微信公众号推荐 ,由火龙果软件Alice编辑、推荐。 |
|
业务中台和数据中台到底是个什么关系？这也是直到现在都会被问到的经典问题之一。
其实这个问题也算是老生常谈了，相信很多同学看这个话题都看麻木了，但相信我，本篇可能会给你一些不一样的观点（希望能有所启发）。
其实这个话题我在2018年写 《白话中台战略-2：中台到底长啥样？》 中，就已经聊过当时自己对于双中台的理解，回顾一下，当时的描述是这样的：
业务中台将后台资源进行抽象包装整合，转化为前台友好的可重用共享的核心能力，实现了后端业务资源到前台易用能力的转化。 数据中台从后台及业务中台将数据流入，完成海量数据的存储、计算、产品化包装过程，构成企业的核心数据能力，为前台基于数据的定制化创新和业务中台基于数据反馈的持续演进提供了强大支撑。 业务中台与数据中台，相辅相成，互相支撑，一起构建起了战场强大的后方炮火群。
但随着这三年的实践，我发现这个描述并不足以讲清楚两者的边界，在实际的双中台架构落地的时候对于业务中台和数据中台之间的定位和关系又实际遇到了很多具体的实际的问题，靠这样一段笼统的抽象的介绍，是找不到解题思路和答案的……
你理解的业务数据双中台是不是这样子？
为了展现上面提到的我过去一段时间对于双中台关系的理解，我在给客户和社区分享双中台关系时，也一直采用下图来描述:
（图1: 之前对于双中台关系的理解）
在通过这张图描述关系时，我一般会突出几个重点：
- 业务中台与数据中台都可以直接被前台应用调用，各自负责为前台赋能业务和数据的能力①④。
- 前台应用和业务中台都会有自己的业务数据库，存储自身相关的数据
- 前台应用和业务中台的数据都会同步或是流入数据中台的数据湖（或其他存储形式）②
- 数据中台像数据工厂一样对于各种数据进行整理、分类、加工、包装，变成有价值的数据资产和数据商品
- 数据中台也可以通过数据服务为业务中台赋能③，实现业务能力智能化
不知道这样的对于双中台关系的理解，和你的理解是否一致？
至少我听过很多行业里的老师在描述到双中台关系时，很多都是采用类似的解读方式。 我一开始也是觉得非常清晰，但真正实操下去，就会发现这里其实隐藏了一个巨大的问题并没有解释清楚！
问题与困境
这个重要但隐蔽的问题就是：
当处理数据场景时，是用③ + ① 还是 ④？
（图2: 两种选择）
如果解释一下，就是当处理数据相关的场景时（例如千人千面的商品推荐 or 运营指标分析）的时候，到底是应该：
- 由业务中台团队提供相关的能力，数据中台辅助，即走③+①的通路
- 还是直接由数据中台团队直接对接前台团队，提供相关的能力，即直接走④的通路
或者这个问题再变换一下，即什么场景下是数据中台团队可以直接对前台应用提供数据与智能服务（④），什么场景下数据中台团队通过赋能业务中台团队从而间接为前台应用团队提供数据与智能服务（③+①）。
你一定会想，这个问题简单呀，只留一个通路不就成了，要么只走④，要么只走③+①，就不会出现选择的问题了？
我们一开始也是尝试这么解决的，但是实操起来发现事情并不是那么简单，无论单独采用那种方案，大家也都觉得有的场景下更适合另外一种，但是又说不清楚具体的划分标准……
其实这个问题的解题关键并不在技术层面，而是在 知识和责任边界 的划分上。如果你细心，一定会发现我上边提到双中台的时候一直在说的是业务中台团队和数据中台团队，而双中台的边界的定位问题根据康威定律，就是在定义两个团队（业务中台团队和数据中台团队）的 知识和责任边界 。
两个团队顾名思义，一个关注“业务”，一个关注“数据”，所以简单做个转换我们就找到了所有问题的关键点：
“业务”和“数据”的边界到底在哪？！ 而我的答案：没有边界！业务和数据就是一个东西。
数据就是业务曾经留下的痕迹，就像物理世界的照片和历史典籍一样，现在的业务也就是未来的数据，分析数据就是在分析过去的业务，数据就是业务加上了时间的纬度，长出了时间的翅膀而已，两者本质就是一体两面的。
而行业里一直在提的：一切业务数据化，一切数据业务化，在我看也是在表达同样的观点。
所以，这个问题是不是就变成了，我们永远无法弄清楚“业务”与“数据”的边界，因为他们本身就是一体的，没有边界的？在这个结论有点意外，让我们再重新复盘和简化一下推导逻辑：
- 根据康威定律：业务中台和数据中台的边界 == 业务中台团队和数据中台团队的边界。
- 业务中台和数据中台团队的边界 == 业务中台和数据中台团队的知识边界
- 业务中台和数据中台团队的知识边界 = “业务”与“数据”的知识边界
- 又因为如上边的分析，我们假设“业务”和“数据”本质上就是一个东西，所以“业务”与“数据”之间并没有明确清晰的知识边界
- 所以最后推导出来的结论就是：两个中台以及背后的两个中台团队也不存在清晰的边界！
完了，搞了半天，最后发现问题并不可解！……
走出困境，重新认知与定义“业务”与“数据”
其实也不是没有解决方案，既然问题的核心是对于“业务”和“数据”两个概念知识边界的模糊上，不同的解决方案本质上就是在重新定义什么是“业务”、什么是“数据”，而在企业上下文下对于这两个概念不同的定义和理解，就产生了不同企业截然不同的业务数据双中台模式。
在我看来，大体上主要有两种理解和配套的实现模式。
解法1：把“数据”定位成技术知识，研究如何让业务团队更容易的驾驭数据技术
第一类理解，把“业务”理解成“业务场景”（包含对客的和运营决策的业务知识），把“数据”狭义的理解为“数据与智能技术”（纯技术，偏工具，不关心数据本身，不关心业务知识）。
而按照这种理解，推导出的模式其实就类似之前的大数据技术平台模式，这种模式的特点是“数据中台”中的“数据”仅仅代表的只是“数据技术”（例如流批一体的数据计算平台，AI技术平台），好处是边界清晰，业务中台关注于业务场景，数据中台只关注于数据技术；缺点则是数据领域的专业型导致懂业务的人不懂技术，懂技术的人不懂业务，两者割裂，协同不起来。
其实我认为这种模式下的数据中台和之前的大数据技术平台并没有本质区别，只是换了个新概念。
正是业务场景与数据技术之间知识壁垒导致的协作问题，让很多企业前些年的大数据平台建设效果有限，平台建成了，但是业务用不起来，也不想用，最终也大多只是把之前数仓的报表搬过来用大数据平台又实现了一遍……
正是对于业务和技术之间壁垒的反思，才催生了让数据团队从“只管技术不管数据”的数据平台，向“又管技术又管业务”的数据中台模式的演进运动（但带来的问题也就是因为数据的概念被外扩，从纯技术属性向技术+业务属性拓展，也就出现了业务和数据说不清楚边界的问题）。
稍微做一个扩展，我认为最近出现的DataMesh（数据网格）是最新的对于第一类理解出现问题的另一种解题思路：即将关注点仍然放到如何让懂业务的人更容易驾驭数据的相关技术，而不是期望让懂数据技术的人也懂数据本身及其代表的业务。
图3：DataMesh(https://martinfowler.com/articles/data-monolith-to-mesh.html))
解法2：按照对客业务场景和企业内部运营决策场景划分业务和数据的边界
第二类理解，把“业务”理解成“对客业务场景”（对客渠道+业务运营），把“数据”理解成“企业内部的业务分析和决策分析场景”（报表、分析+决策）。
如果说第一类理解是从业务与技术上“横切”，那第二类理解就相当于从不同的业务场景上“纵切”：
- 业务中台是 对于企业业务模式的抽象和复用 ，解决的是对客业务场景响应和创新的问题（可以理解成企业的四肢，负责响应）
- 数据中台是 对于企业运营模式的抽象和复用 ，强调的是数据与智能驱动企业运营与决策（可以理解成企业的大脑，负责感知和决策）。
- 在任何一个场景中，两个中台都会参与，但是角色和责权利不同。在业务模式复用（响应）场景中，业务中台团队驱动，数据中台团队支持；在运营模式复用（感知）场景中，数据中台团队驱动，业务中台团队支持。
而感知决策（大脑）与行动（四肢）的配合，就形成了企业对于市场的认知闭环。
（图4：区分两类业务场景 ，细化双中台关系 ）
如果是基于这种理解，在定位业务中台和数据中台的权责和角色之前，就需要先判断当前场景到底是哪类场景：
- 如果是 响应 类场景，例如千人千面的产品推荐，就明确要采用业务中台团队驱动，数据中台团队支撑的协作方式，也就是③+①的模式。
- 如果是 感知 决策类场景，例如统计企业过去三年的销售数据做新产品定价的决策分析，就明确要采用数据中台团队驱动，业务中台团队支撑的协作方式，也就是④模式。
这样虽然并不会减少两个团队的协同，但是对于两个团队的知识边界和职责定位会更加的清晰。
有意思的是，如果你回头再去看（图1），就会发现其实就是（图4）两种场景下所有关系的叠加，而之前的混淆也是因为没有将两种业务场景进行明确的区分导致的。
总结
最后，我再试着总结提炼一下我的思路和观点：
- 广义的数据和业务是一体的，没有边界，所以广义上讲也不应该存在业务和数据两个团队。
- 但狭义上可以在企业范围内通过重新定义“业务”和“数据”的概念，定义两个团队的知识边界。
- 对于狭义的“业务”和“数据”，行业内有两种理解方向，产生了两种截然不同的双中台模式，以及所延伸出来的团队协作模式。第一种按照业务与技术划分【横切】，第二种按照业务场景（响应与感知决策）划分【纵切】。
最后的最后，无论用那种模式都可以，最主要的就是要对于企业内部所用的模式达成共识，并根据模式来进行团队边界、系统架构、和协同模式的设计，否则就会出现各种由于组织之间定位不清，边界不清所导致的企业内部摩擦，消耗大量资源的同时，还起不到起初希望达到的价值与效果。
如果你能坚持看到最后，确实非常感谢，这篇文章我写的很费劲，想把脑子中抽象的想法用文字言简意赅地表达出来确实对我是个挑战，只希望对你还有一点点的启发。如果有帮助或是有疑问，欢迎留言给我，一起交流。
|
