江苏龙网

  1. 首页 > 人文 > >

技术编程大咖说中台 | 中台不是“银弹”！


_本文原题：大咖说中台 | 中台不是“银弹”！
技术编程大咖说中台 | 中台不是“银弹”！
本文插图
作者 | 耿立超
来源 | 《大数据平台架构与原型实现：数据中台建设实战》
本质上 ， 中台是一种中心化、平台化的企业组织架构和业务形态 ， 当这样的组织和业务架构投射到IT 系统上时会自然地形成我们今天讨论的IT 意义上的“中台” 。 笔者曾经参与过不少定位为统一平台的项目 ， 其中有不少失败的案例 ， 对于这个问题有一点个人的思考：也许中心化系统都是反传统管理体制的 ， 烟囱式的生态系统是企业组织架构在IT 上的投影 ， 小到“数据湖” ， 大到中台 ， 没有强力对等的中心化组织去主导 ， 结果是很难预料的 。
继本系列前一篇文章对中台架构作了整体性的介绍之后 ， 本文我们将继续从组织架构的角度上展开对中台的介绍 ， 这是中台建设中不得不谈论的话题 ， 虽然在任何企业里这都是一个非常敏感的话题 ， 但对中台建设来说 ， 这一问题必须要思考清楚 。 另外 ， 本文的后半部分 ， 我们会冷静地分析一下中台所“不能”的地方 ， 避免读者对中台产生错误的不切实际的理解与期望 。 本文核心观点援引自作者所著的《大数据平台架构与原型实现：数据中台建设实战》 一书 ， 全书对数据中台的理念、架构和具体实现做了详细论述 。
中台的组织架构
组织架构无疑是一个重大而敏感的问题 ， 但确实是在建设中台过程中不得不面对的 ， 一家企业如果想要在中台化转型上取得成功 ， 就必须直面这个问题 。 我们前面探讨烟囱式的生态系统和SOA 架构时提到的诸多问题和挑战都与组织分工、团队协作有关 ， 这些问题的根源都是组织架构 。 在过去的烟囱式生态系统下 ， 每一个应用系统都由一个专职的团队负责 ， 团队的核心任务与首要KPI 是确保本系统持续稳定地运行 ， 这使得每一个团队都必然地从本应用系统的立场和角度看待和思考问题 。
然而企业的业务流程是一个有机的整体 ， 这在客观上必然要求各个应用系统和运维团队紧密协作 ， 这时候组织架构的问题就会显现出来 。 过去不管是点对点式的集成还是SOA 改造 ， 当它们作为一个项目交付之后 ， 随着时间的推移 ， 在集成新系统时又会变得像以前一样举步维艰 ， 究其原因是并没有一个长期有效的组织架构在持续地推动系统融合 。
中台架构的提出对企业的组织架构产生了巨大的影响 ， 有了与中台相适应的组织架构 ， 企业才能很好地完成中台建设并从中受益 。 中台架构有一很鲜明的特点 ， 那就是它彻底破除了应用系统的边界 ， 从企业的全业务领域着手 ， 切分出业务中心 ， 每一个业务中心所支撑的不是一个孤立的应用系统 ， 而是企业在该领域的全部核心业务 ， 所以每一个业务中心都需要非常专业的团队来负责 ， 团队必须对这部分业务非常了解 ， 而且必须站在企业的全局去支撑和把控这一业务领域 。
我们来看一下阿里巴巴共享业务事业部的故事 。 2003 年阿里巴巴首先成立了淘宝事业部 ， 伴随着B2C 业务的兴起 ， 2008 年从淘宝团队中拆分出了天猫事业部 ， 但是这两大事业部依靠的都是淘宝的技术团队 ， 这样带来的问题是技术团队会优先响应来自淘宝的业务需求 ， 影响了天猫事业部的发展 。 另外一个问题也是很典型的 ， 那就是这两个电商平台是完全独立的 ， 都有各自的商品、交易、支付等功能模块 ， 可见阿里巴巴也曾经走过烟囱架构的老路 。
为了解决这个问题 ， 阿里巴巴开始了第一次大胆的尝试 ， 在2009 年成立了“共享业务事业部” ， 主要由淘宝的技术团队构成 ， 但是这个事业部与淘宝和天猫两个事业部是平级的 ， 这一架构调整的用意很明确 ， 阿里巴巴希望通过共享业务事业部来梳理和沉淀两个电商平台的业务 ， 抽离出公共的部分 ， 避免重复建设 。 但事情的发展却出乎阿里巴巴的预料 ， 由于淘宝和天猫作为核心业务部门 ， 显然拥有更大的主导权 ， 共享业务事业部发展缓慢 。


推荐阅读


上一篇：新机发布华为机器狗曝光，将用于智能识别和目标定位

下一篇：大事|创业板注册制明天开闸！11件大事不得不知，史上十大活跃股曝光