中台架构详解(下)丨建设数据中台系列(五)

2020 年 8 月 06 日

中台架构详解(下)丨建设数据中台系列(五)

继本系列前一篇文章对中台架构作了整体性的介绍之后,本文我们将继续从组织架构的角度上展开对中台的介绍,这是中台建设中不得不谈论的话题,虽然在任何企业里这都是一个非常敏感的话题,但对中台建设来说,这一问题必须要思考清楚。另外,本文的后半部分,我们会冷静地分析一下中台所“不能”的地方,避免读者对中台产生错误的不切实际的理解与期望。本文核心观点援引自作者所著的《大数据平台架构与原型实现:数据中台建设实战》一书,全书对数据中台的理念、架构和具体实现做了详细论述。

3 中台的组织架构

组织架构无疑是一个重大而敏感的问题,但确实是在建设中台过程中不得不面对的,一家企业如果想要在中台化转型上取得成功,就必须直面这个问题。我们前面探讨烟囱式的生态系统和 SOA 架构时提到的诸多问题和挑战都与组织分工、团队协作有关,这些问题的根源都是组织架构。在过去的烟囱式生态系统下,每一个应用系统都由一个专职的团队负责,团队的核心任务与首要 KPI 是确保本系统持续稳定地运行,这使得每一个团队都必然地从本应用系统的立场和角度看待和思考问题。

然而企业的业务流程是一个有机的整体,这在客观上必然要求各个应用系统和运维团队紧密协作,这时候组织架构的问题就会显现出来。过去不管是点对点式的集成还是 SOA 改造,当它们作为一个项目交付之后,随着时间的推移,在集成新系统时又会变得像以前一样举步维艰,究其原因是并没有一个长期有效的组织架构在持续地推动系统融合。

中台架构的提出对企业的组织架构产生了巨大的影响,有了与中台相适应的组织架构,企业才能很好地完成中台建设并从中受益。中台架构有一很鲜明的特点,那就是它彻底破除了应用系统的边界,从企业的全业务领域着手,切分出业务中心,每一个业务中心所支撑的不是一个孤立的应用系统,而是企业在该领域的全部核心业务,所以每一个业务中心都需要非常专业的团队来负责,团队必须对这部分业务非常了解,而且必须站在企业的全局去支撑和把控这一业务领域。

我们来看一下阿里巴巴共享业务事业部的故事。2003 年阿里巴巴首先成立了淘宝事业部,伴随着 B2C 业务的兴起,2008 年从淘宝团队中拆分出了天猫事业部,但是这两大事业部依靠的都是淘宝的技术团队,这样带来的问题是技术团队会优先响应来自淘宝的业务需求,影响了天猫事业部的发展。另外一个问题也是很典型的,那就是这两个电商平台是完全独立的,都有各自的商品、交易、支付等功能模块,可见阿里巴巴也曾经走过烟囱架构的老路。

为了解决这个问题,阿里巴巴开始了第一次大胆的尝试,在 2009 年成立了“共享业务事业部”,主要由淘宝的技术团队构成,但是这个事业部与淘宝和天猫两个事业部是平级的,这一架构调整的用意很明确,阿里巴巴希望通过共享业务事业部来梳理和沉淀两个电商平台的业务,抽离出公共的部分,避免重复建设。但事情的发展却出乎阿里巴巴的预料,由于淘宝和天猫作为核心业务部门,显然拥有更大的主导权,共享业务事业部发展缓慢。

这一状况的转变源自聚划算的出现,聚划算作为阿里巴巴的团购业务事业部,在成立之初拥有强大的引流能力,淘宝和天猫的产品一旦进入聚划算,销售额就会暴增,因此两大事业部都迫切地想要将自己的平台和聚划算对接。此时阿里巴巴做出了一个重要决定,其他业务平台如果要和聚划算平台对接,必须通过共享业务事业部,正是这一举措让共享业务事业部找到了发展的抓手,进而将自己提升到与其他业务事业部同等的公平位置上。

从阿里巴巴共享业务事业部的故事中我们可以看到,组织架构对于中台战略的有效实施至关重要,在整个组织架构中,企业需要仔细梳理和界定关键部门的职责及相关部门之间的关系。

中台事业部

由于中台的定位在于支持企业的共享业务,所以必须要由一个专职的实体部门对其负责,而不能是一个虚拟组织,这个部门必须要被赋予足够大的权限,过去分散于多个业务部门和系统运维团队的部分职责需要拆分并重组到中台部门,由中台统一管理和负责。

中台各业务中心

中台各业务中心的人员一般来自该中心对应的过去某个核心业务系统,如用户中心团队的骨干应该来自原 CRM 系统,被划归到中台的个人和团队将面临一次内部转型,他们过去只对单一业务系统负责,而现在需要站在企业的全局来看待和梳理相关业务,这需要中台团队在广度上要能触达各个业务渠道的前端需求,同时要在深度上不断地挖掘和提炼共享业务,并最终落地到中台服务上。中台各个业务中心的职责划分必须清晰明确,特别是在一些关联性较强的业务领域上一定要做好切割,将各方的职责界定清楚。

中台与前台团队的关系

前台团队直接面向市场和终端用户,从这个角度来看前台团队扮演着中台用户的角色。一方面,前台团队经常会提出各种各样的需求,有些需求可以在团队内部消化,有些则需要中台团队的支持,这时候前台团队就会对中台团队产生依赖;另一方面,对于中台团队来说,也非常需要来自前台的业务“滋养”。因此两个团队应该维持紧密的合作关系,这对于能否成功建立中台架构是非常关键的,如果两个团队之间在合作上出现问题就会导致两种可能的后果:

  • 如果前台团队强势,就会组织力量在自己可控的范围内实现自己的需求,导致一些本该出现在中台上的共享服务被放在了某个前端应用上,这在客观上弱化了中台的“威力”,同时会导致其他前台应用重复建设该功能,这是在“开倒车”;
  • 如果前台团队弱势,就会放弃或推迟新的构想和尝试,这会让企业逐渐失去抓住市场机遇的能力。

4 中台不是“银弹”

前面花了大量的篇幅讨论了中台的各种优势,但是我们也必须理性客观地看待它,就像讨论以往出现过的任何新技术和新理论一样,我们可以看重或推崇它们的优势,但不能过分笃定或夸大它们的作用。中台是一种非常理想化的架构,当企业进化到这样先进的架构时自然可以借助中台创造巨大的业务价值。也可以反过来说,因为企业自身的组织和业务足够先进而催生了中台架构(从某种意义上来说这才是中台的真正由来),两者是相辅相成的。建设中台的难度是非常大的,其难度并不技术上,更多是在业务和组织架构上。

最近两年,中台的火爆让很多企业都跟风尝试,但真正成功的案例还不多,业界对中台的讨论也很激烈,有人认为中台可能仅仅是一种“乌托邦”,因为它过于理想化,在现实中缺乏生存的土壤,很多企业的现有组织形态与中台是不符甚至是对立的,这样的企业盲目上马中台项目必然是要失败的。这里我们不妨思考一下:为什么烟囱架构在企业中普遍存在?尽管我们在前面讨论了它的各种问题,但是至少有一点是烟囱架构的优势,那就是它的目标指向性极强,它是专门用于解决某一业务问题的,相应地,它背后的技术和业务团队的职责也是高度清晰的,这种目标指向性会驱使组织高效地运转,即使在不同的团队和环节上存在重复建设,在某些时候,付出这种代价也是值得的。

在这种视角下反观中台,我们会看到,业务中心在对业务的广度和深度上都有一个介入度的问题。从广度上看,不同业务部门、不同业务方向上的业务需求都可能全部或部分落地到中台上,而中台部门需要根据自身的情况来指定开发的优先级,这就决定了在中台建设过程中,并不是所有的业务请求都能得到及时的响应,业务端的体验会与之前烟囱架构有一定的落差;从深度上看,在垂直方向上的业务问题一部分是由前台应用处理掉的,另一部分是由中台解决的,这一点我们在前面讲如何进行前台和中台切分时也提到过,这会导致过去的单一业务问题由单一系统负责变成前台和中台两个参与方或团队负责,如果我们用目标指向性来度量这一状况,显然中台不如烟囱架构有优势,简单地说就是容易出现前台和中台之间的“扯皮”现象。

本文的讨论主要是提醒读者客观理性地看待中台架构,毕竟它还是相对新的一种思想,业界需要更多的时间去实践和检验,对于这个行业的从业者而言,我们应该保持一种积极的、谨慎乐观的态度看待它。不过相较于业务中台,本系列着重讨论的数据中台并没有这么多不确定的挑战,不管是理论还是实现技术都是比较明朗和确定的。

作者介绍

耿立超,架构师,14 年 IT 系统开发和架构经验,对大数据、企业级应用架构、SaaS、分布式存储和领域驱动设计有丰富的实践经验,热衷函数式编程。目前负责企业数据中台的架构设计和开发工作,对 Hadoop/Spark 生态系统有深入和广泛的了解,参与过 Hadoop 商业发行版的开发,曾带领团队建设过数个完备的企业数据平台,个人技术博客: https://laurence.blog.csdn.net/ 作者著有《大数据平台架构与原型实现:数据中台建设实战》一书,该书已在京东和当当上线。

建设数据中台系列

企业数据能力测评:认清现状,布局未来丨建设数据中台系列(一)

怎么走着走着就变“烟囱”了呢?丨建设数据中台系列(二)

SOA 为什么不“香”了?丨建设数据中台系列(三)

中台架构详解(上)丨建设数据中台系列(四)

“数据中台”有何不同?丨建设数据中台系列(六)

“数据中台”怎么建?丨建设数据中台系列(七)

2020 年 8 月 06 日 11:11 932

评论

发布
暂无评论
发现更多内容

读 Guide to Java String Pool

shengjk1

Java java string pool string pool

程序员不可不知的:2020年测试六大趋势

陈琦

人工智能 开源 DevOps 敏捷开发 测试

SpringBoot+Mybatis Plus多租户动态数据源

zane

数据库 Spring Cloud mybatis

字节码编程,Javassist篇二《定义属性以及创建方法时多种入参和出参类型的使用》

小傅哥

javassist 字节码编程 字节码插桩 小傅哥

JDK源码分析之 ArrayList

Wh1

源码分析

DDD 实践手册(1.Get Started)

Joshua

领域驱动设计 DDD 系统架构 架构模式

如何优雅的使用GDB调试Go

newbmiao

go golang Docker debug gdb

说说最近升级protobuf-go的一些坑

newbmiao

golang gRPC proto-buf protoc-gen-go

Dig101 - Go之string那些事

newbmiao

go 源码分析 string

Dig101-Go之读懂interface的底层设计

newbmiao

go 源码分析 interface iface eface

Laravel 7 新特性 - 流畅的字符串操作

Middleware

php laravel string

变革之路的思考

龙眼果

字节码编程,Javassist篇一《基于javassist的第一个案例helloworld》

小傅哥

javassist 字节码编程 字节码插桩 小傅哥

云原生时代的通用策略引擎:OpenPolicyAgent入门系列

newbmiao

go 微服务 云原生 k8s 工具

Dig101 - Go之聊聊struct的内存对齐

newbmiao

go 源码分析 struct memory -layout

本地开发环境搭建利器--vagrant

aoho

DevOps 运维 vagrant

Filebeat + Kafka + Elasticsearch + Kibana 实现日志收集与管理

AlwaysBeta

大数据 kafka elasticsearch elastic 数据分析

招聘小思考

水色

彻底明白如何设计一个良好的 API

Yezhiwei

Dig101 - Go之读懂map的底层设计

newbmiao

go 源码分析 hashmap

Dig101-Go之interface调用的一个优化点

newbmiao

go 源码分析 interface devirtualization

远程办公钉钉使用体验

冯夷

钉钉

Dig101-Go之for-range排坑指南

newbmiao

go golang

ANTLR入门(一)

zane

编程语言 ANTLR

如何批量将Word表格转为Excel

newbmiao

自动化 工具

从高盛的技术“开源”看金融业软件发展未来

fino星君

open-source 金融科技 数字化生态

Dig101 - Go之灵活的slice

newbmiao

go 源码分析 slice

100字:对数时间复杂度

韩小非

算法 时间复杂度

ANTLR 入门(二)

zane

编程语言 ANTLR

翻译: Effective Go (3)

申屠鹏会

翻译 gol

OKR实践中的痛点(2):对不qi,对不qi

大叔杨

OKR Scrum 敏捷 敏捷开发

中台架构详解(下)丨建设数据中台系列(五)-InfoQ