精华内容
下载资源
问答
  • 技术中台的作用是什么? 技术前台 技术中台什么情况下,才有必要做技术中台? | 前提1:技术组织结构垂直化 | 前提2:业务线又多又复杂 有了技术中台,是不是就能上天? 总结 就在刚过去的半年里,「...

    目录

    技术中台的作用是什么?

    技术前台

    技术中台

    在什么情况下,才有必要做技术中台?

    | 前提1:技术组织结构垂直化

    | 前提2:业务线又多又复杂

    有了技术中台,是不是就能上天?

    总结


     

    就在刚过去的半年里,「中台」成了技术圈内讨论的热门词汇,就连一些名不见经传的小公司,也都纷纷喊出了「要向中台转型!」的口号,甚至有人说「不做中台,那就等着死吧!」

    如果我没有记错,「中台」思想源自于2015年,马云参观一个著名的游戏公司Supercell之后提出了,简言之就是“小前台、大中台”,随即阿里就成立中台事业群,并取得了很好的成效。

    随后,美团点评也开始走中台策略,腾讯在去年的组织架构调整中,也提出建设具有 “腾讯特色的技术中台”。

    技术中台的作用是什么?

    要搞明白这点,你需要先搞清楚「技术前台」、「技术中台」与 「技术后台」 之间的关系,以及他们各自扮演的角色与作用。

    先来说说我们的「技术前台」。

    技术前台

    「技术前台」,说白了就是为业务部门开发功能的技术团队。

    如果是ToC的业务,交付物必须贴近终端用户,如果是ToB的业务,交付物需要满足商家的需求。

    脑海中必须时刻牢记 “小步快跑,快速试错” 的理念,业务说啥,就是啥,业务要怎么做,你就怎么做。

    另外,研发资源的投入基本和业务对等,业务需求多,人数增加,业务需求少,人数相应减少,而且团队组织也基本按功能线来划分。

    运用的技术栈也相对单一,以Java语言为例,通常 “1个NG + 1个War/N个Jar + 1个数据库” 就搞定了,而其余的技术服务都将由「技术中台」提供。

    「技术前台」的核心价值体现在对业务逻辑的理解与实现上,是技术向业务传递价值的阶梯。

    我觉得在这点上,与线下销售团队的前台营销有一些类似。

    技术中台

    再来说说我们的「技术中台」。

    「技术中台」,说白了就是强调资源整合、能力沉淀的平台体系,当「技术前台」实现业务功能时,为他们提供底层的技术、数据等资源和能力的支持。

    这怎么理解?

    从这张图中可以看到,「技术中台」有点像编程时的适配层,起到承上启下的作用,将整个公司的技术能力与业务能力分离,并以产品化方式向前台提供技术赋能,形成强力支撑。

    在什么情况下,才有必要做技术中台?

    俗话说 “知己知彼,百战不殆”,在我看来,面对技术问题时,“知己” 比 “知彼” 更为重要。

    在实施「技术中台」之前,我们是否要静下心来对自己进行 “灵魂拷问”?比如说,当前的时机是否已经成熟?或者怎么才叫成熟?

    在我看来,要想做「技术中台」,客观环境需先满足两个前提:技术组织结构垂直化业务线又多又复杂

    否则,「技术中台」的结果只会是两种:一场闹剧 或者 一笔赔钱的买卖。

    | 前提1:技术组织结构垂直化

    曾经有朋友说过,每家公司的组织结构演进都是一部心酸血泪史。我很费解,问为什么?

    他说,因为这中间掺杂着太多的主观判断与情感纠葛。

    比如,某员工认为公司管理混乱,组织架构来回调整,今天拆这个团队,明天合那个团队,纯属病急乱投医,高管都是些横行霸道,滥用资源的傻逼货,借机搞人,这公司,没救了。

    但高管们大呼冤枉,觉得组织架构调整的目的是为了提高产出和人效,如果你干得不爽可以离开,这种事情,本来就不可能让每个人都满意,既得利益者肯定大加赞赏,而失去利益者肯定狂喷不止,不用理会。

    的确,这种 “自我革命式” 的调整,基本不可能一步到位,需要一个过程慢慢演化,而在这个过程里,自然会遭遇很多的阻力或质疑。

    瞧瞧这结构,经典的职能分工模式,有什么问题吗?

    我不但说不出问题,甚至能找出一万个理由说明这种模式的好处。开发按业务线分开,测试与运维形成上下层关系,谁也不想管对方,两边的老大也是评级的,相安无事

    那什么情况下才会觉得这种模式有问题呢?

    客观的说,职能分工模式更适合瀑布式开发模式。先谈需求,再谈工期,随后按部就班地往下做

    但当用户的需求开始变的多种多样,业务方时不时的就要上一个新功能,做一个新系统的时候,你会发现开发出来的系统很难变更,至少很难快速变更。

    于是,你把开发按系统功能进行重组,每个团队都围绕 “交付速度” 开展工作,但这样又遇到了两个新的问题:

    • 多种多样的中间件,每个团队独立选型中间件,没有统一的维护,没有统一的知识积累,无法统一保障SLA。

    • 开发与测试、运维之间目标不一致(比如测试A君,开发要求你只做功能测试,快上线,但测试老大却要求你做非功能测试,保障质量,避免背锅……到底听谁的?),陷入永无休止的扯皮与争吵。

    面对这两个新的问题,我们做出了调整:

    • 成立平台架构组,负责中间件、自动化测试/运维、数据库等技术工具或服务的开发、维护。

    • 把质量管理部中的测试团队,与系统运维部中的应用运维团队,按照系统功能拆分至各开发团队,由原开发经理负责,形成各自独立的Feature Team。

    到这个时候,虽然整个组织结构还未完全实现垂直化分工,但已基本能够达到 “快速试错,小步快跑” 的目标。

    另外,这更像平台化的另一种雏形,就是逐渐把一些公共、底层的技术能力抽象出来,与业务逻辑分离,并形成各种接入式基础服务,同时可以为多个业务线提供服务。

    也就是说,打造「技术中台」的前提是平台化,而平台化的先决条件是「组织结构垂直化,技术工具公共化」

    如果没有这样的前提,就失去了打造「技术中台」的立身之基。

    | 前提2:业务线又多又复杂

    曾经有朋友问我,技术的核心价值是什么?我的答案是 “改变世界”。

    他说,别扯淡,好好说话。

    他说,对业务驱动型的公司来说,技术的核心价值是 “降低成本,提升效率”,而单从架构设计的角度来看,想达成这项目标的两个手段是「通用性」与「复用性」

    现在想想,这句话可以完美的衔接到「技术中台」上去。

    回顾几年前,我们的业务逻辑也曾非常单一,要么用你的银行卡买卖基金,要么用你的电子钱包买卖基金,方便,快捷。

    渐渐地,随着业务创新业务增多,需要前后台系统定制开发,逻辑兼容难度增加。

    在这样的局势下,为满足企业规模扩大和多样化经营对组织机构的要求,公司开始转向事业部制,按产品、地区或市场(顾客) 划分经营单位。

    为了应对业务方的这次调整,我们开始将业务开发中的一些共享服务分离出来,成立了业务中台组(由于本文以技术中台为主,业务中台的内容将不进行展开说明)

    将可以复用的服务和代码,交由这几个组开发出服务来,给业务组使用,这样数据模型会统一,业务开发的时候,首先先看看有哪些现成的服务可以使用,不用全部从零开发,也会提高开发效率。

    与「业务中台」相呼应,「技术中台」就像一个工具大仓库,里面放满了各式各样的技术工具,无论是哪个团队,哪个人,快速找到自己的工具,拿来就用就行了。

    而维护工具的这群人,不用贴近业务开发,每天的任务就是研究如何使用这些工具,如何调优,遇到问题如何Debug,形成知识积累。

    有了这么一群专职的人,就可以根据自身的情况,选择有限几个技术栈集中研究,限定业务组只使用这些工具,可保证选型的一致性。

    如果你只有一条业务线,那就别搞「技术中台」了,把人凑在一堆,又省钱,又省力。

    有了技术中台,是不是就能上天?

    理论上讲,当业务线变多且越来越复杂,前台与后台之间的“技术债”会随之变多,重复造轮子与沟通成本太高的现象会增多,通过技术中台可以一定程度上来解决这个问题。

    这种理论看似完美,但在实际执行上却困难重重。

    设想下,如果「技术中台」做得太多,资源投入就会很大,无法形成正向的利益传导;

    如果「技术中台」做得太少,又无法深入理解业务,导致适配方案落地性变差,渐渐失去价值。

    这句话怎么理解?

    十年前,我在某金融软件公司工作,随着客户数的增多,成本与效率/质量的矛盾日益凸显。

    设想下,从一波人维护一套代码,渐渐变成一波人维护几套代码,这样一来,Bug增多,效率下降,抱怨也随之变多,再加上甲方挖人,最后人员离职,团队土崩瓦解,Game Over……

    在这种情况下,一般公司会采取三种应对措施:

    1. 一对一服务 - 项目制:多个团队,多套代码,多套标准,服务多家客户,但这样一来成本又难以承受,时间一长,肯定资不抵债。

    2. 一对多服务 - 标准化:一个团队,一套代码,一套标准,服务多家客户,但客户不买账,客户说我的需求都是个性化的,你别来某某标准来引导我,叫你咋做,你就咋做,不愿意?那您走,我找别人家做。

    3. 一对多服务 - 产品化:一个团队,一套代码,多套标准,服务多家客户,通过技术与配置化的手段,利用SOA思想,打造自己的产品化平台,但对技术投入要求较高,尤其是核心人才的依赖较大,中小型企业一般都很难留住这些人,只要他们一走,公司基本完蛋。

    回想下,当年那些叱诧风云的软件公司,又有几家活下来了?以金融业为例,恒生算是在第二条路上走的比较成功的,而我们当年却死在了第三条路上。

    在我看来,我们的「技术中台」就是一家 “乙方服务公司”,而我们的「技术前台」更像是一家 “甲方电商公司”。

    不可否认,有了这家 “乙方服务公司” 之后,在面对大型项目及快速多变的业务时,技术的投入与主动权更强了,但由于理念、职责、节奏与使命不同,外加 “屁股决定脑袋” 的立场,前台与中台之间很容易引发矛盾。

    从职责角度来说,前台是 “快速应对业务变化”,中台是 “稳定高效提供服务”。

    一个追求效率,一个追求质量,这矛盾是天然存在的。

    怎么理解?我来举个小例子说明下。

    前台部门的A团队和B团队,由于业务需要同时向「技术中台」提出要接入缓存服务的需求

    「技术中台」的中间件产品线中有一套基于Proxy的自研分布式缓存系统,已在其他业务线运行多年,但由于A团队与B团队的技术债都各不相同,必须通过增加适配器才能完成接入

    而此时人手又不够,按重要程度排序,只能先接A团队,但B团队也有需求,又等不及,怎么办呢?就先给他来个Redis接着玩玩吧,等A团队接好了再来接你的。

    一个月后,等A团队接完了,找到B团队,这时痛点已不存在,团队的激情自然不高,毕竟没有收益,就不了了之了。

    几个月后,安全团队提出要对Redis集群进行改密,由于A团队接入的是「技术中台」的缓存中间件产品,采用代理模式,并通过控制台操作,既方便,又快捷,找个晚上,5分钟内,全部搞定。

    但B团队用的是直连Redis的模式,密码嵌入在SDK中,不仅在改密过程中需要前台与中台联动,而且还需要在改密后重启应用服务,这样一来,只有配合应用发布的周期才能干这件事。

    最终,原本五分钟可以搞定的事,整整搞了三周才搞定,「技术中台」的运维同学更是陪熬了多次通宵,还因为人为疏忽引发了一次事故。

    就在这件事过去的一年时间里,由于B团队系统的业务规模逐渐增大,Redis数量也逐渐增多,「技术中台」的运维成本与风险也随之上涨。

    这期间,中台曾多次与前台交涉,希望能够通过适配的方式将A团队接入缓存中间件,但始终未能达成。

    在「技术中台」看来,“你们只顾自己,不管别人,功劳你们拿,黑锅我们背?”

    在「技术前台」看来,“你TM懂个屁!我们都快被业务逼疯了,你们不就多费点人工吗?多加点班会死吗?总扯一些理念干嘛?对你没收益的事,你干嘛?”

    因为这样的分工模式,导致这种矛盾在工作中很多,而且似乎并没有更好的方法彻底解决。

    有人说,要解决很简单,要么强压,要么加大投入,下下狠心就得了。

    先来说说强压,似乎能够在短时间内达到目的,但纯属 “杀敌一千自损八百” 的招数,难道要业务研发团队停下手上的活,倾巢而出一起搞技术改造吗?更何况,前台承受的压力,是中后台团队无法想象的。

    退一步说,抛开 “互相理解” 这个话题,强压的套路等同于 “攻城为上,攻心为下”,对今后的管理与团队氛围都会带来诸多的麻烦。

    再来说说加大投入,看看我上面提到的 “死在路上的软件公司们”,还想加大中后台的投入吗?

    如果你不是大厂,还是算了吧。

    那句话怎么说来着?最悲惨的结局是,你的技术中后台越发强大,但你的业务规模却在逐渐萎缩。

    可悲,可叹。

    总结

    在互联网时代,技术圈似乎从来不缺少热议话题,但有质量,有深度,且能解决实际问题的却少之又少。

    现在人人都在讨论「中台」,今天「产品中台」,明天「数据中台」,这个说能提高效率,那个说能排除万难,聊得不亦乐乎。

    对于企业来说,话题热不热并不重点,方案牛不牛逼也不重要,关键是能帮助用户找到效率、质量与成本的平衡点,或许才算是一个合格的「技术中台」。

    展开全文
  • 到底什么是数据中台

    万次阅读 多人点赞 2019-07-22 21:00:00
    最近可能大家听到“数据中台”这个词越来越频繁了,有时候我跟一些朋友聊起来,也是都在说这个,但是一直不知道这到底是个什么。最近就看到这篇文章,觉得说的还挺好的,分享给大家看...
        

    最近可能大家听到“数据中台”这个词越来越频繁了,有时候我跟一些朋友聊起来,也是都在说这个,但是一直不知道这到底是个什么。最近就看到这篇文章,觉得说的还挺好的,分享给大家看看,希望大家看完能对数据中台有一些认识。


    转载来源

    公众号:AI 前线

    声明:本文由微信公众号 「AI 前线」原创(ID:ai-front),未经授权不得转载

    阅读本文大概需要 12 分钟。


    导读:数据中台被誉为大数据的下一站,由阿里兴起,核心思想是数据共享,并在 2018 年因为“腾讯数据中台论”再度成为了人们谈论的焦点。在 3 月 15 日 ThoughtWorks 技术雷达峰会上,关于数据中台的话题也获得了众多参会者的热烈关注。如今似乎人人都在提数据中台,但却不是所有人都清楚数据中台到底意味着什么。数据中台是只有大厂才需要考虑的高大上的概念吗?普通企业该不该做数据中台?数据中台的出现会给现有数据从业者们带来颠覆式的挑战吗?带着上述问题,InfoQ 在技术雷达峰会上采访了 ThoughtWorks 数据和智能总监史凯,谈谈他对于数据中台的看法。
    数据中台不是大数据平台!

    首先它不是一个平台,也不是一个系统,如果有厂商说他们有个数据中台卖给你,对不起,它是个骗子。

    要回答数据中台是什么,首先要探讨一下中台到底是什么。虽然没有明确的定义,但是作为理工直男,我们可以先把中台看作是一种中间层。既然是一种中间层,那么中台确实是一种十足技术用语,我们可以完全从技术角度来探讨了。

    我们可以应用 Gartner 的 Pace Layer 来理解为什么要有中间层,这样可以更好地理解中台的定位和价值。Pace Layer 里提到,可以按照事物变化的速度来分层,这样可以逐层分析并设计合理的边界与服务。

    640?wx_fmt=png

    在数据开发中,核心数据模型的变化是相对缓慢的,同时,对数据进行维护的工作量也非常大;但业务创新的速度、对数据提出的需求的变化,是非常快速的。

    数据中台的出现,就是为了弥补数据开发和应用开发之间,由于开发速度不匹配,出现的响应力跟不上的问题。

    数据中台解决的问题可以总结为如下三点:

    1. 效率问题:为什么应用开发增加一个报表,就要十几天时间?为什么不能实时获得用户推荐清单?当业务人员对数据产生一点疑问的时候,需要花费很长的时间,结果发现是数据源的数据变了,最终影响上线时间。

    2. 协作问题:当业务应用开发的时候,虽然和别的项目需求大致差不多,但因为是别的项目组维护的,所以数据还是要自己再开发一遍。

    3. 能力问题:数据的处理和维护是一个相对独立的技术,需要相当专业的人来完成,但是很多时候,我们有一大把的应用开发人员,而数据开发人员很少。

    这三类问题都会导致应用开发团队变慢。这就是中台的关键——让前台开发团队的开发速度不受后台数据开发的影响。

    史凯总结说,“数据中台是聚合和治理跨域数据,将数据抽象封装成服务,提供给前台以业务价值的逻辑概念”。

    如下图所示:

    640?wx_fmt=png

    DData API 是数据中台的核心,它是连接前台和后台的桥梁,通过 API 的方式提供数据服务,而不是直接把数据库给前台、让前台开发自行使用数据。至于产生 DataAPI 的过程,怎么样让 DataAPI 产生得更快,怎么样让 DATA API 更加清晰,怎么样让 DATA API 的数据质量更好,这些是要围绕数据中台去构建的能力。

    数据中台和数据仓库、数据平台的关键区别

    这是现在数据行业大家经常讨论的问题,到底数据仓库、数据平台和数据中台的区别是什么。

    640?wx_fmt=png

    概括地说,三者的关键区别有以下几方面:

    1. 数据中台是企业级的逻辑概念,体现企业 D2V(Data to Value)的能力,为业务提供服务的主要方式是数据 API;

    2. 数据仓库是一个相对具体的功能概念,是存储和管理一个或多个主题数据的集合,为业务提供服务的方式主要是分析报表;

    3. 数据平台是在大数据基础上出现的融合了结构化和非结构化数据的数据基础平台,为业务提供服务的方式主要是直接提供数据集;

    4. 数据中台距离业务更近,为业务提供速度更快的服务;

    5. 数据仓库是为了支持管理决策分析,而数据中台则是将数据服务化之后提供给业务系统,不仅限于分析型场景,也适用于交易型场景;

    6. 数据中台可以建立在数据仓库和数据平台之上,是加速企业从数据到业务价值的过程的中间层。

    数据仓库具有历史性,其中存储的数据大多是结构化数据,这些数据并非企业全量数据,而是根据需求针对性抽取的,因此数据仓库对于业务的价值是各种各样的报表,但这些报表又无法实时产生。数据仓库报表虽然能够提供部分业务价值,但不能直接影响业务。

    数据平台的出现是为了解决数据仓库不能处理非结构化数据和报表开发周期长的问题,所以先撇开业务需求、把企业所有的数据都抽取出来放到一起,成为一个大的数据集,其中有结构化数据、非结构化数据等。当业务方有需求的时候,再把他们需要的若干个小数据集单独提取出来,以数据集的形式提供给数据应用。

    而数据中台是在数据仓库和数据平台的基础上,将数据生产为为一个个数据 API 服务,以更高效的方式提供给业务。

    数据中台应该具备什么能力?

    大数据和人工智能大火之后这几年,很多人一直在提一个说法,那就是“数据是新的石油”。但史凯的观点却有些不同,在他看来,数据不等于数据资产,如果没有从业务的角度对数据进行规划,再多的数据也无法产生价值。

    史凯认为数据中台最核心的一个关键组件是数据资产目录。“我们认为,一个企业的数据要能够充分发挥价值,很重要的一个前提条件就是这个企业的数据结构和数据资产目录是对整个企业开放的。所有人都能够通过这个资产目录了解公司有哪些类别的数据、包含什么属性、源数据由谁管理,这样就可以快速搞清楚这些数据是不是自己需要的。但数据本身可以不开放,因为数据是有隐私信息和安全级别的。”

    大企业内部业务众多,不同业务可能存在很多重复数据。所谓的数据资产目录就是把数据的模型去重、归一、梳理,变成一个树状结构,这个树状结构不直接对应数据库中的字段。以航空货运为例,其数据资产可能包括货机、客运机的辅舱,一架货机就是一个数据资产目录的节点,而货机的各种属性(如货机型号、空间大小、年份等)就是这个节点下面的数据模型。数据资产目录做的事情就是从业务层面出发制定数据标准,将企业业务相关的数据资产模型抽取出来,这跟后面用什么数据库去存储、用什么结构去存储、存成结构化还是非结构化都没有关系。它相当于把企业的业务从数据层面做了一个梳理,用数据的语言把企业的业务模型还原出来。数据资产目录做好之后,后面才是用什么技术手段、从哪里提取数据来映射到这个数据资产目录。

    除了开放,数据资产目录还应该具有标签描述、可检索,这样才能最大程度地方便真正使用数据的人,以最快的速度找到他们需要的东西。

    在 ThoughtWorks 提出的精益数据创新体系中将企业所需要具备的数据能力概括为以下六种,具备了这六种能力,企业才具备成为数据驱动的智能企业的基础,而这些能力的承载平台,就是数据中台:

    640?wx_fmt=png

    1. 数据资产的规划和治理

    做中台之前,首先需要知道业务价值是什么,从业务角度去思考企业的数据资产是什么。数据资产不等同于数据,数据资产是唯一的,能为业务产生价值的数据。 对于同一堆数据,不同业务部门所关注的数据指标可能完全不同,怎么让各个跨域的业务变成统一的标准,就需要规划企业的数据全景图,将所有有可能用上的、所有对企业有可能有价值的数据都规划出来,最终梳理出企业的数据资产目录。在这个时候不需要考虑有没有系统、有没有数据,只需要关注哪些数据是对企业业务有价值的。这一层不建议做得太细,太细就难以形成标准,不能适用于多个场景了。数据治理是数据中台很重要的一个领域,ThoughtWorks 认为在现在业务边界消失、需求快速变化的情况下,企业需要具备精益数据治理的能力——Lean Data Governance。传统的中心化、事前控制式的数据治理方式,要改变为去中心化、事后服务式的治理方式。

    640?wx_fmt=png

    1. 数据资产的获取和存储

    数据中台要为企业提供强大的数据资产的获取和存储的能力。

     3. 数据的共享和协作

    企业的数据中台一定是跨域的,需要让所有的人都知道数据资产目录在哪里。不能因为数据安全,就不让大家知道企业有什么数据。没有共享和开放,数据没有办法流动起来,没有流动的话数据的价值产生的速度就会非常慢。所以在数据安全的基础上,企业的数据资产目录要对利益相关者、价值创造者开放,要让业务人员能够做到“Self-Service”。

      4. 业务价值的探索和分析

    数据中台不仅要建立到源数据的通路,还需要提供分析数据的工具和能力,帮助业务人员去探索和发现数据的业务价值。一个好的数据中台解决方案中需要针对不同业务岗位的用户提供个性化的数据探索和分析的工具,并且在此基础上一键生成数据 API,以多样化的方式提供给前台系统。

    1. 数据服务的构建和治理

    数据中台需要保证数据服务的性能和稳定性,以及数据质量和准确性,还需要具备强大的服务治理能力。数据中台是一个生态平台,在数据中台上面会不断生长各种数据服务,所以从一开始就构建好数据服务的治理结构是非常重要的,数据服务需要可以被记录、可被跟踪、可被审计、可被监控。

       6. 数据服务的度量和运营

    如果数据中台最终只是做到把数据给到业务人员,那它就只是一个搬运工的角色。数据中台还需要具备度量和运营数据服务的能力,能够对中台上提供的数据服务及相关行为持续跟踪和记录,包括哪些数据服务被哪个部门用了多少次等,通过这些去度量每一个数据服务的业务价值。

    史凯认为,数据中台是一个需要用互联网思维去经营的利润中心平台,数据中台的经营分析人员需要分析业务,了解为什么今天上午这个财务部门的人用了数据中台、调用了十次,下午他不用了,原因是什么,调用了这些数据服务的人通常还会调用哪些其他的数据服务。这些都需要相应地做记录、做日志、做分析,要把数据当做像电商平台一样去经营,然后实时地根据这些业务行为数据去提醒数据服务提供方,调整、改变、优化数据服务,这才是可经营的数据中台,也只有这样业务部门才能得到最快的支持和响应。

    为什么人人都需要数据中台?

    数据中台并非只有大公司才需要的高大上的玩意。

    ThoughtWorks 从 2017 年到现在,已经帮助多家大型国内外企业建设数据中台,其中有体量巨大的企业级数据中台,也有部门级的小数据中台。

    “未来所有的企业核心都会变成加工数据的企业,而数据中台是数据价值化的加工厂,所以所有的企业都需要数据中台的能力,数据中台一定是未来每个企业的标准配置。”

    在史凯看来,数据中台并不意味着“大而全”的数据平台。根据企业的规模和业务的不同,数据中台可大可小,规模、复杂度可能都不相同,但它对业务产生的价值是一样的。

    当企业评估自己是否应该建设数据中台时,应该从哪些方面来考虑?史凯认为,从战略角度来说,每个企业都需要建立自己的数据中台;从战术角度来说,当企业发现自己的数据开发利用的速度和应用开发的速度不匹配的时候,就需要考虑构建数据中台。

    原来很多企业在做应用系统的时候,什么都不考虑直接上单体架构,一上来就先做数据库,然后在上面建应用。ThoughtWorks 建议现在的企业,即使不做数据中台、不去立一个叫做“数据中台”的项目,但是在做应用的时候,最好把这个应用分成三层,业务层、数据中台层、源数据层,在一开始做应用的时候就把三个层次抽象出来。

    数据质量差所以做不了数据中台?No!

    历史遗留的数据质量问题经常让大家对数据的利用和价值产生质疑。2018 年,史凯在与不同企业沟通过程中经常听到的一句话就是,“我们现在还没有到利用数据这一步,因为(应用系统中的)数据质量太差”。

    每次听到这句话,史凯脑子里就好像听到了另外一句话,“还没到培养孩子的时候啊,孩子太小了”。

    不能因为数据质量差,就不去利用数据。恰恰是因为没有去做后面的事情,所以数据质量才差。而且也不能因为数据质量差就抛开业务场景、试图全面解决数据质量的问题,这样得不到业务部门的支持,也无法从数据工作中产生业务价值。所以 ThoughtWorks 建议的恰恰是利用做应用、做业务的需求,同步解决数据质量问题。

    史凯认为,数据质量问题,根本上是在构建应用之初缺乏整体数据规划和数据思维导致的问题。原来的流程类应用构建之初,只考虑了如何让流程跑起来,缺乏对这个应用在整个企业的数据全景图(Data Landscape)中的定位的分析,没有从源头上优化数据的存储、流转,从而更好地与其他的系统中的数据去对齐口径、统一语言,将流程问题抽象成领域模型问题,再将领域模型抽象成数据模型。

    建设数据中台的挑战及应对策略

    建设数据中台最大的挑战在于前期能否从业务层面梳理清楚有业务价值的场景,以及数据全景图,而不仅在于后期的技术建设。

    数据中台建设面临的挑战包括:

    • 梳理业务场景:搞清楚数据中台如何对业务产生价值。

    • 建设数据中台的优先级策略:需求可能大而全,但我们不能直接建大而全的数据中台,应该根据业务重要性来排需求的优先级。

    • 数据治理问题:和业务独立开的数据治理少有成功的,大的数据标准要有(数据资产目录),通过数据资产目录将共有的纬度、共性的业务模型提炼出来,在此基础之上数据治理需要跟业务场景紧密结合。

      数据中台的建设需要两个战略耐心

    数据中台是为了加快从数据到业务价值的产生速度,但是它的生产过程依然是需要时间、有很多复杂的工作要做的,所以对于数据中台的投资方和数据中台的建设方来讲,都需要对应的战略耐心。

    640?wx_fmt=png

    • 对于投资方来讲,要充分认识到数据中台类项目的价值和局限性。在现在的组织结构和技术成熟度下,数据中台依旧是一个技术平台,对于业务价值的产生是一个加速的过程。但是业务对于数据的需求不会因为有了数据中台就减少,数据中台也不是哆啦 A 梦,不能随心所欲地变出各种业务想要的服务。这依然是一个需要统筹规划、敏捷迭代、演进建设的系统性工程,所以需要要管理好期望,有一定的战略耐心。

    • 对于建设方来讲,要充分认识到数据中台建设的复杂度,不要操之过急,不要期待毕其功于一役。史凯的建议是要从小中台做起,围绕具体有价值的业务场景去建设,尽量不脱离场景去搞周期长、大而全的纯工具平台建设。

      数据中台也可以小而美

      建设数据中台的关键考量包括两方面。

    首先数据中台一定要与业务价值对齐。构建数据中台,最重要的不是技术,也不是数据质量好不好,而是数据思维和数据文化。数据思维就是要建立起从数据的视角去思考问题的方式;数据文化就是要把数据和业务当成一体去看,而不是只将数据当作一个支持工具。想清楚业务对于数据的诉求是构建数据中台的第一步,哪怕暂时不能想的太细,也要去想,想不清楚就先不要做。

    不要在业务场景还没有明确、优先级还不清晰、价值度量体系尚未建立起来的时候,就建立大而全的数据平台,并且把所有的数据都存起来。企业都是追求投入产出比的,大而全的数据平台往往会面临尴尬的局面,一堆功能看上去很有用,应该都能用上,但是缺乏应用场景,真的有了场景,发现也不能开箱即用,还需要众多的定制化。

    其次,数据中台应该从小数据、小场景做起。

    数据中台是面向场景而非面向技术的,这种与客户的业务、企业的结构和信息化发展阶段有着紧密的相关性的业务基础架构,是很难买一个大而全的产品来一劳永逸解决的。

    可以通过下面这个图来解释构建中台的原则:

    640?wx_fmt=png

    一开始的时候需要顶层设计,面向业务愿景制定中台的整体规划,全面的梳理数据创新全景蓝图,这就是上图左边的黑色框架部分,通过业务愿景驱动出所有的业务场景探索,从而推导出数据中台的全景架构、技术支撑。

    但是在实施的时候,要从具体的业务场景出发。从高价值数据集场景做起,然后顺着这个场景竖切,找到数据全景图中的一个或多个数据集合,从小数据场景落地,这样才能快速验证价值。大处思考,全局拉通,避免后续的数据孤岛,但是从小数据集切入,从可实现性高的场景启动。然后一个个的场景做起来,业务价值和中台能力也就同步建立起来了。

    总的来讲就是,“设计阶段横着走,落地阶段竖着切。”

    数据中台团队和技术选型

    数据中台团队通常需要包含以下角色:

    • 业务专家团队:了解业务、梳理业务场景,确定数据资产与业务场景的一一对应关系,确定业务场景的优先级,为数据中台的建设提供依据。

    • 数据工程团队:建设和维护数据中台,包括 ETL、数据采集,以及数据中台性能和稳定性保证,利用中台的工具采集、存储、加工、处理数据。

    • 数据分析团队:分析数据价值、探索场景,生产更多的数据服务。

    • 数据治理团队:梳理数据标准、构件数据安全和隐私规范,利用开源去中心化的数据治理工具(比如 atlas、wherehows)来围绕业务场景解决数据质量和安全问题。

    • 智能算法团队:为数据分析、业务探索提供智能和算法工具。

    而这样的一个团队的工作就构成了一个数据生产线,一个从数据到业务服务的数据服务工厂,这个工厂有生产车间(Data Pipeline)、研发中心(数据实验室)、管理办公室(数据治理),还有产品展示中心(数据服务商店)。

    640?wx_fmt=png

    数据工厂是一个逻辑概念,不是一个大而全的产品,ThoughtWorks 结合过去几年的实践给出了一个数据工厂组件选型的参考架构,这些推荐的架构和组件,很多都体现在过去 ThoughtWorks 推出的技术雷达中并进行了详细解释,如下:

    640?wx_fmt=png

    数据中台的出现对于现有数据团队的挑战

    前面已经提到,数据中台是企业的 Data API 工厂,用更高效、更协同的方式加快从数据到业务的价值,能够给业务提供更高的响应力。所以数据中台距离业务更近,这对于传统企业的数据业务来讲,是一个重大的变化,同时给原来的数据团队也会带来巨大的挑战。

     1. 对数据分析人员的业务要求提高了

    企业传统的数据工作和业务工作分工明确、界限清晰,业务人员负责业务需求,提出业务问题,并将业务问题拆解成一个个清晰的数据问题,然后数据工程师和数据分析师在这个清晰的问题下解题。

    但是,在数据中台出现后,数据中台是一个赋能平台,它会沉淀、提供很多数据分析工具和数据服务,能够让不具备专业数据能力的业务人员也可以进行一些简单的数据分析,产生业务的洞察。这就意味着在数据中台的支持下,相对简单清晰的业务问题会更多的由业务人员自己解决掉,那么传递到专业数据人员的问题,都会是更加复杂的问题。这对于数据人员的业务理解能力就加强了,他 / 她们必须具备快速理解业务的能力,才能够体现出专业性和优势。

     2. 对于数据人员的工程能力要求提高了

    原来的数据分析工作属于个体工作方式,每一个数据科学家、数据分析师就是一个独立的工作单元,业务部门给出业务问题,他们通过自己擅长熟悉的工具和方法给出结果。但是在数据中台出现后,他们一方面获得了更多数据分析的武器和工具,能够站在前人的基础上工作,提高了效率和准确度,另外一方面,他们也需要掌握更多的平台化的数据分析工具,比如 Jupyter Notebook,同时也被要求能够把自己分析的结果转化成数据服务,沉淀到中台。

     3. 数据团队需要具备更多的业务视角

    原来的数据分析团队是一个功能型团队,更多以数据智囊团的身份存在。大部分情况下,距离业务比较远,更不要提对业务的结果负责。而在数据中台出现后,数据中台距离业务会越来越近,甚至直接影响和参与业务的运行,数据团队将慢慢脱离数据智囊团的身份,逐渐从后台走向前台,直接负责一个个数据服务,而这些数据服务是会直接参与到业务当中、产生业务价值的。这样的定位变化,要求数据团队具备更多的业务视角,要更关注业务价值,直接对齐企业的业务目标去工作。

    所以,数据中台的出现,不仅是一个技术平台,它对于企业而言是一个系统化的工作,企业数据相关的流程、职责、分工都要有对应的调整,才能达成整体的目标。

    数据中台 VS 数据隐私

    对于数据中台来说,数据隐私和安全性也是非常重要的问题。可能很多人还记得前些日子马化腾针对“腾讯数据中台论”的回应。去年腾讯组织架构调整进程中实现了技术打通,而对数据打通保持谨慎态度。马化腾在 18 年 11 月的世界互联网大会上回应“数据中台论”:“腾讯不能套用很多其他公司的做法,把数据直接去任意打通。因为在我们的平台里面,大量全部都是人和人之间的通信、社交行为数据,如果说数据可以任意打通,给公司业务部门或者给外部的客户用,那是会带来灾难性的后果。这方面我们要更加谨慎,我们要从用户的角度来考虑,把个人信息和数据保护放在优先地位。”很多人将这解读为腾讯不做数据中台,史凯却不这么认为。

    在他看来,腾讯的回应并不是说他们不做数据中台,而是强调要在数据隐私上做更多的工作。其实所有的数据安全和隐私的保护都需要从场景出发。史凯认为,“不能从纯数据层面来看数据隐私,数据隐私是不能脱离场景的”。如果纯粹从数据层面,而不从业务场景层面去管理数据隐私,就会带来两方面的问题,要么数据被管理的非常死,阻碍了业务价值的产生;要么数据隐私管理就会有漏洞。

    史凯举了一个例子,比如我们讲的用户交易数据,如果不关联用户基本信息,交易数据本身对于用户来说是不具备隐私风险的,因为它不关联到任何一个用户个体。所以,是可以对脱敏后的用户交易数据进行分析和利用的。

    另一方面,如果脱离场景谈数据隐私,也可能会导致忽略了潜在的安全问题。有时候如果不把场景关联起来,可能两个数据看上去没有安全问题,但其实外人把这两个数据关联起来就产生价值了。这也是为什么在一开始的时候就要把所有的场景,尽可能地全部分析出来。

    另外,设置权限、数据分级审核、库级数据脱敏等都是可以提升数据安全的手段。现代数据中台必须具备数据调用行为的监控和记录机制,反过来也能增强对数据安全和隐私的保护。

    数据中台的下一步

    当前国内外已经有不少公司开始投资建设数据中台,大家比较熟悉的包括阿里、华为、联想、海航、上汽、壳牌等。

    在史凯看来,数据中台当前处于上升发展期。虽然未来数据中台未必还叫做数据中台,但它一定会成为企业必备的基础组件。

    世界正在从信息化向数字化发展。信息化是指大部分的工作都在物理世界里完成,然后用信电脑的数字化世界解决一小部分问题。数字化则是把人从物理世界搬到数字化世界。从这个角度来讲,数据中台将会变成物理世界的业务在数字化世界的一个还原。

    数据中台设计的初衷是将计算与存储分离,从狭义上来说,真正最核心的数据中台可以是没有存储的。但就当前的情况来看,广义的数据中台在未来一段时间内仍会涵盖数据仓库、数据湖等存储组件,“数据工厂”这个概念可能更适用于现在的阶段。但随着数据中台的发展,未来很有可能不再需要数据湖了。

    最后,史凯也提到了阿里中台战略中的另一个中台——“业务中台”。他表示“当前业务中台更偏实时交易,是从上往下沉淀业务;数据中台目前更偏分析、决策和洞察,为业务提供 T+N 和 T+0 的数据服务,但是再往前走,数据中台跟交易会慢慢结合得更为紧密。随着计算能力越来越强,以及微服务架构的进一步发展,未来业务中台和数据中台可能会融为一体。”

    采访嘉宾

    史凯,ThoughtWorks 数据和智能总监,精益数据创新体系的提出者,2019 年被评选为 DataIQ100 的数据赋能者,有近 20 年年的企业信息化、数字化转型架构和实施经验,为众多大型客户提供数字化转型战略略规划和咨询实施服务。

    技术雷达是 ThoughtWorks 推出的公益的、不限行业的技术选型趋势报告,至今已坚持十年,旨在以雷达的表现形式,通过清晰的解读,给技术人员提供高质量、落地性强的技术平台、工具框架方面的选型指导,助力企业数字化转型。


    推荐阅读

    1

    跟繁琐的命令行说拜拜!Gerapy分布式爬虫管理框架来袭!

    2

    跟繁琐的模型说拜拜!深度学习脚手架 ModelZoo 来袭!

    3

    只会用Selenium爬网页?Appium爬App了解一下

    4

    妈妈再也不用担心爬虫被封号了!手把手教你搭建Cookies池

    崔庆才

    静觅博客博主,《Python3网络爬虫开发实战》作者

    隐形字

    个人公众号:进击的Coder

    640?wx_fmt=gif640?wx_fmt=jpeg640?wx_fmt=gif

    长按识别二维码关注


    好文和朋友一起看~
    展开全文
  • 互联网公司的中台到底是什么

    千次阅读 2019-11-04 23:16:39
    互联网公司的中台到底是什么?2.中台有哪些类型?3.中台有哪些困境?4.互联网公司中台的现状 5.关于中台的建议 1 台化据说是马云参观 Supercell 后在阿里巴巴提出的,要求“大中、小前台”的模式。目标也很...

    中台最近又成了比较热的话题,结合我对中台的认知,试图跟你回答下这些问题:1.互联网公司的中台到底是什么?2.中台有哪些类型?3.中台有哪些困境?4.互联网公司中台的现状 5.关于中台的建议

     

    1

    中台化据说是马云参观 Supercell 后在阿里巴巴提出的,要求“大中台、小前台”的模式。目标也很明确:小前台距离一线更近,便于快速决策、敏捷行动;剩下的交给支撑部门做。

     

    Supercell 的中台化究竟是什么呢?

     

    首先,Supercell 一直倡导“Less is more”的组织文化,整体公司员工数量保持在极度精简的水平,在去年底也没有超过 400 人,而 2018 年营业利润大约是 5.1 亿欧元(39 亿人民币)。在这样精英文化的氛围下,CEO Ilkka Paananen 力求员工不要被流程和管理机制束缚,给每个小团队足够的决策权。而且由于资源稀缺,每个小团队可以更加聚焦手中的资源,选择做最重要的事情。(Supercell 中的 cell 也是表达这个意思。)

     

    640?wx_fmt=png

    (Supercell 的中台理念示意图)

     

    这是组织中台化。 

     

    组织中台化对游戏的价值显而易见。游戏本来是创意行业,把决策权给业务前台、中台结构放权、CEO 主要来完成大家资源的支撑和整合,是合理的。

     

    其次,据说 Supercell 是一定程度上实现了技术中台化,即前台业务团队可以利用现有的各种技术模块,快速敏捷地试错。(这点待求证,毕竟游戏的复杂度很高,不知能中台化到什么程度。)

     

    这是技术中台化

     

    技术中台化的核心目的是成本。成本可以从两个维度看,一个是资源浪费方面的成本,即公司有三四个业务线都在做同样的事情了,那技术上实现能不能融合可复用的部分?另一个则是时间成本,即新业务能够足够敏捷地去使用既有的技术模块去做探索。

     

    实际上,实现中台化的环境是相当苛刻的。连 Paananen 自己都说,他认为Supercell 的经验不是对所有公司都有效,有它自己的特殊性。他觉得 Supercell 的每个员工,都是能在外面成立公司自己当老板的,因此这种精英文化和中台化在公司得以保持。

     

    2

    反观国内的互联网公司,这几年都陆续提到了、或者在践行中台化。我了解到的许多中小企业,也在追随大公司的脚步,搭建中台能力。

     

    不过中台化显然不是万能的提效方案,也不是适用于各种公司各种领域的。夸张点说,很多人口中所说的中台化,每个字儿看起来都一样,但压根都不是一件事情

     

    除了刚刚提到了组织中台和技术中台,还存在数据中台和业务中台。我们按照难易程度倒序逐一论述。

     

    其一,技术中台(基础服务中台)。

     

    技术中台指的是将大家都通用的技术能力聚合到一起,由同一个团队负责,防止重复造轮子,是最容易实现的中台化。核心价值是降成本,刚刚提到了。

     

     

    各公司的基础服务,以账号体系为代表,都已经是中台化的了。淘宝、天猫、飞猪等业务之间,快车、专车、顺风车等业务之间,美团外卖、酒旅、团购之间,必然要做打通。

     

    其二,数据中台。

     

    顾名思义,表面上数据中台是各业务的数据能够打通。不过在实际运用中,又分为多种。

     

    基本的数据采集、数据仓库建立和数据分析能力的共享,其实是数据技术中台的范畴,是将做数据相关工作的技术团队整合,来支持各业务。核心价值是降成本。

     

    各业务线的数据打通、数据共享和协同运用,则属于业务中台的范畴,是以业务目标牵头的(比如阿里的88VIP会员的前提就是用户数据打通)。

     

    有时这两者是耦合在一起的,既有技术能力的共享,又有业务支撑。不过在国内数据分析的认知还比较浅(认为数据都是拉报表的),后者往往效果不佳。前者在不少互联网公司倒是确实落地了。

     

    在有些公司,数据中台只是很粗浅地把数据整合到一起,并没有解决任何问题,或者让整合产生什么价值。阿里云中间件架构总监谢纯良曾经说过,许多公司的数据中台就是把数据加工成“大屏”,搞一个展示用的“大屏”就以为实现了中台。意思就是,数据中台如果不为业务服务,或者说为业务中台服务,那就没有价值。

     

    其三,业务中台。

     

    既然技术模块可以抽象出来复用,那业务模块是不是也可以?在淘宝时用过的营销策略,能不能直接挪到飞猪用?专车的策略能不能直接给快车用?这就是业务中台的概念。

     

    很显然的,由于业务存在更高复杂度,因此难度更大。

     

     

    业务中台是各大公司追求的最终效果:前台业务敏捷推进,后台业务稳固支持。不过真实情况往往事与愿违,难尽人意,真正做到业务中台运转良好的,很少见。

     

    其四,组织中台。

     

    组织中台刚刚讲 Supercell 时提到了,是嫁接在前三种中台基础上,再加入“放权机制”的中台结构。

     

    阿里的中台业务支撑能力可以支持新的电商相关业务快速创新;字节跳动把增长能力中台化,头条的增长部队可以快速投入到抖音中去,甚至可以投入到海外各个国家各个产品;美团有试错小团队,会利用既有的技术能力、用户流量等资源快速试错,找到新的方向,包括外卖在内都是这样来的。

     

    这些都是组织中台的体现。组织中台与其说是中台能力,倒不如说是内部创业的空间。它的核心价值应该在于“旧业务能否帮到新业务”,很考验组织能力。有的公司内部创业,封闭隔离,跟这个公司自己投资了个新团队,没啥区别。

     

    3

    中台的难点有几个关键矛盾:

    • 中台团队离业务远

    • 中台需求的优先级难排序

     

    先说中台团队离业务远。

     

    为什么中台化的难度是:技术-数据-业务-组织?因为越往后,越需要业务团队的介入,越要有业务认知才能做到中台。而中台团队,天然就是离业务远的。

     

    各公司跟中台团队的协作,都存在很大的低效问题,一线的前台业务团队,要反复与中台沟通,才能讲清楚业务需求的背景,在大公司,跨部门协作都会徒增成本。另外对于中台业务团队来说,长期离业务很远,没有成长性,在判断需求时也不准确,很难获得前台业务团队的信任。

     

    久而久之,就变成了中台团队纯支撑、被动接需求的状态,成为“鸡肋中台”。更大的问题在于,中台团队的价值就是整合需求、抽象能力的,在对用户和业务不够了解的前提下,这块就会做得特别吃力。如果是多个前台业务的需求有了冲突,中台团队未必能做好协调,多方要反复沟通扯皮。

     

    针对这个问题,通常有两个解决方案:

     

    第一,中台职责直接由最大业务方来担任。

     

    像贝壳的中台模块,就是由二手房先行推进的;而大多数通用的乘客司机产品流程,在滴滴也都是快车先发起的。最大的业务方离业务足够近,能自己决策判断大多数需求,更加高效。

     

    这样以来,就从“硬找一个中台团队来收集大家需求”变成了“老大哥发挥余热,把自己的能力共享出来”,具体要怎么用,仍然是各自团队来决策和执行。

     

    第二,让中台团队做业务闭环。

     

    这只适用于少部分情况,即中台业务本身可以自闭环。常见的比如各公司的账号体系(包括注册登录)、阿里的支付和订单流程、滴滴的地图和导航。这些业务与其它业务的关联度不大,可以解耦,可以自己完成从用户到业务的认知和决策,那就可以独立出来自己做,其它业务希望使用的时候,对接通用接口就可以了。

     

    而大多数中台团队负责的业务不太容易自闭环。比如滴滴不同业务线的接单流程,就很难抽象出来让中台团队直接闭环自己做;或者像阿里不同业务线的商品部分、订单流程部分和支付部分可以抽象,但用户体验方面,不同前台业务差异太大,则很难抽象。

     

    再说,中台需求的优先级难排序。

     

    很现实的问题是,中台团队会面临无数的需求,要处理优先级问题。怎样处理,很难有标准。

     

    你可以说,用业务指标即可,比如哪个前台业务方的需求能创造更大业务价值。这当然可以,但这有悖于前面提到的“中台化是为了前台业务更高效,尤其辅助创新业务”的作用。因为很简单,你的创新业务没几个用户的时候,就永远得不到中台支持,那还做个毛线。

     

    结果往往就是,若严格按照量化收益来排序,小业务和创新业务的个性化需求永远排不上,最后就只能自己完成,又是在“去中台化”了。

     

    这个问题暂时没有什么太好的解法。跟每个公司的人聊,几乎都会碰到,小业务或者边缘业务对中台业务部门的诟病,认为不够支持,需求都被堵死。除了自己做,只能寄希望于,自己需要的,中台部门恰好已经提供了。

     

    4

    各公司的中台化现状,基于我的访谈和了解,可以做一个简单的描述。

     

    腾讯从大半年前提出中台化之后,已经由 TEG 牵头陆续实现底层技术的一些整合,以账户体系为主。数据的整合也在做了,不过应该更多类似数据仓库的建设这种底层整合。从业务中台来说,搜索、广告、信息流都在陆续整合,基本是钦定某家的方式,分别是浏览器、广点通、FCC(信息流与内容社区业务线) 牵头做。微信仍然是飞地,不受任何中台化影响,自给自足。

     

    腾讯的难度应该是最大的,因为众所周知,山头林立,遍地赛马。一些新业务,无数团队都在做,而且是完全“去中台化”的方式在做。我有个朋友所在的团队,对内部严格保密地做新项目,怕被发现成了靶子,对外反倒是没有那么保密,很是魔幻。

     

    阿里的业务中台化应当是做得最好的。网传的这张示意图较好地描述了阿里中台架构的情况。

     

    640?wx_fmt=png

     

    中间的“业务平台”中,各中心(Center)承担自闭环的业务,是我前文中提到的对“离业务远”的第二个解决方案。由于电商环境下各环节的用户需求和体验都有较高相似度,且阿里的组织文化建设得足够高效,在阿里的中台部门不会存在太多“中台鸡肋”的情况,能够深入参与业务。

     

    比如,阿里的用户中心( User Center )就是统一账户管理部门,负责用户画像、用户标签等一系列基础能力建设,同时也会负责前端体验(比如“我的淘宝”)。商品中心(Item Center)会负责商品详情页,既有后端的信息逻辑,也有前端的体验。不管是“我的淘宝”还是“商品详情”,中台部门都是提供一套完整的基础能力,由淘宝、天猫以及各种前台业务部门自己去个性化使用(可以简单理解成换皮)。

     

    贝壳的中台刚刚提到了,是由二手部门牵头做,把二手和其他业务都面临的业务模块(房源管理、CRM系统、经纪人带看/跟进能力、合同签约等)抽象出来,提供给大家使用。中台部门没有单独拿出来,而是跟业务部门强耦合。

     

    滴滴除了基础服务会有平台产品部和一些支持部门(基础信息、风控等),快车的不少业务模块就是实际上的中台(例如提供接单流程、营销工具)。网约车虽是核心业务,但与其它业务相对解耦(单车、代驾、顺风车、国际化、车服),对外中台化的模块不多,主要还是一些基础服务。

     

    字节跳动的中台以用户增长(投放拉新为主)、技术(算法为主)和商业化(广告为主)三个部门为主,近期新增了直播中台。很明显的,这几块业务在各个方向业务上复用性比较强,业务独立性也足够。这样就能与阿里的中台类似,可以深入业务的同时保持中台的独立。头条的组织化极其看中效率,因此统一支持,效果俱佳。举个例子,用户增长团队是手握预算、以bp身份介入许多业务、有许多产品功能上的决策权的,这跟有的公司的用户增长其实就是市场投放而已,截然不同。

     

    美团很少提到自己的中台战略或者能力。内部在搭建的主要也是基础服务中台和数据中台。对于业务中台来说,美团业务模式之间的差异性导致不太容易抽象(团购-外卖-酒旅-物流-新零售-单车-网约车)。不过美团的组织建设对新业务非常友好,每个新业务都是得到了老业务支持(当然前提是数据本身做得足够好)后生长出来的,无论是底层技术业务的支持,还是人力资源的支持,又或者是流量的支持。因此可以说美团具备一定的组织中台文化。

     

    京东提出中台化后,也搭建了技术中台、数据中台,以及部分业务中台(比如搜索中台、营销中台)。从结构上跟阿里比较类似,不过相对低效一些,业务方与中台的协作不够顺畅,会出现前文提到的各种问题。

     

    整体来说,各司的中台存在几个特征:

     

    • 基础服务(账号、支付、安全、风控等)能力的中台,相对都很完备。技术中台基本多多少少都在搭建了,渗透业务的程度各有不同。

    • 数据中台也大都在搭建中,不过还是侧重提供“采集、存储、取数”的能力,虽说降低了研发成本,但跨部门协作通常会增加协作成本;这样的中台,距离能提供业务决策洞察的数据中台,恐怕还比较远。真正一般数据分析的工作都是各业务内自己闭环,自己完成。

    • 业务中台视情况而定,有的公司业务之间天然不适合做中台化。对于适合的公司,最常见的方式,一种是难以解耦闭环的情况,就采用“老大哥”式的方法,由核心业务来提供支持,比如贝壳、滴滴;另一种是中台有机会掌握自己的业务,比如阿里的电商中台、字节跳动的增长中台。

     

    最后,对于中台化的问题,说几个总结。

     

    • 中台化还是要遵循“具体问题,具体分析”的道理。没有放之四海而皆准的中台化策略,有的业务就不需要中台化,有的中台化反而会适得其反。有的公司压根就只有一个业务,或者有几个业务都没有重复造轮子的现象,那硬去学习阿里的中台,一定是东施效颦了。看阿里谢纯良的采访,包括我跟阿里的朋友了解到的,阿里的中台也是“痛极思变”的过程,在跌跌撞撞中成长的,不是老板一声令下就全部到位的。

    • 中台化的目标都是降低成本,分两种:第一,现存业务之间重复造的轮子合并,降低成本;第二,为某些业务尤其新业务提供能力,可以低成本快速试错。

    • 对于有的大公司,中台化不是个技术问题,反而变成了组织问题,就是各业务线要不要接受别人提供的东西,还是我就要自己做;以及对于新业务来说,能否得到老业务既有能力的支持。

    • 对产品经理和运营来说,一定要加入可以业务自闭环的团队,不要加入纯支撑的中台团队。离业务远会很容易成为“鸡肋中台”。比如在许多公司,基础服务的中台,压根是没有产品和运营这样的业务岗的,都是技术。

    展开全文
  • 什么是数据中台?全面解读数据中台

    千次阅读 多人点赞 2019-06-04 16:49:54
    伴随着云计算、大数据、人工智能等IT技术迅速发展及与传统行业实现快速融合,一场由数字化和智能化转型带来的...阿里在今年发布“双中台+ET”数字化转型方法论,“双中台”指的是数字台和业务中台。 数据...

    伴随着云计算、大数据、人工智能等IT技术迅速发展及与传统行业实现快速融合,一场由数字化和智能化转型带来的产业变革正在孕育。

    随着企业规模不断扩大、业务多元化——中台服务架构的应运而生。“中台”早期是由美军的作战体系演化而来的,技术上说的“中台”主要是指学习这种高效、灵活和强大的指挥作战体系。阿里在今年发布“双中台+ET”数字化转型方法论,“双中台”指的是数字中台和业务中台。

     

     

    数据中台是什么

    数据中台是一套可持续“让企业的数据用起来”的机制(它不是一款产品或项目),一种战略选择和组织形式,是依据企业特有的业务模式和组织架构,通过有形的产品和实施方法论支撑,构建一套持续不断把数据变成资产并服务于业务的机制。

    preview

    数据中台是指通过数据技术,对海量数据进行采集、计算、存储、加工,同时统一标准和口径。数据中台把数据统一之后,会形成标准数据,再进行存储,形成大数据资产层,进而为客户提供高效服务。这些服务跟企业的业务有较强的关联性,是这个企业独有的且能复用的,它是企业业务和数据的沉淀,其不仅能降低重复建设、减少烟囱式协作的成本,也是差异化竞争优势所在。

    数据中台需要具备数据汇聚整合、数据提纯加工、数据服务可视化、数据价值变现4个核心能力,让企业员工、客户、伙伴能够方便地应用数据。

    preview

    广义的数据中台包括了数据技术,比如对海量数据进行采集、计算、存储、加工的一系列技术集合,今天谈到的数据中台包括数据模型,算法服务,数据产品,数据管理等等,和企业的业务有较强的关联性,是企业独有的且能复用的,比如企业自建的2000个基础模型,300个融合模型,5万个标签。它是企业业务和数据的沉淀,其不仅能降低重复建设,减少烟囱式协作的成本,也是差异化竞争优势所在。

    preview

     

    preview

    建立数据中台的原因

     

    数据中台和业务中台相比,面临的情况可能会更加复杂一点。建立数据中台的原因:

     

    • 大数据可以告诉决策者一些潜在的规律,以数据来证明或判断决策。以往我们会用数据来证明我们的决策对错,现在我们用数据来引导我们做出对的决策。在大数据时代,样本就是全体,大数据可以防止伪造和偏差。

    • 数据催生人工智能。数据是人工智能的根基,并且可以进行融合形成新的数据。数据给我们无限的创新,让我们不停去尝试。

    • 数据是机器人的指令,我们形成数据服务思维。数据是不断变化的,让机器智能成为决策环节,运营就可以智能化。

     

     

    中台的目标是提升效能、数据化运营、更好支持业务发展和创新,是多领域、多BU、多系统的负责协同。中台是平台化的自然演进,这种演进带来“去中心化“的组织模式,突出对能力复用、协调控制的能力,以及业务创新的差异化构建能力。为什么数据中台如此重要呢,大致有以下四个原因:

     

    1、回归服务的本质-数据重用

     

    浙江移动已经将2000个基础模型作为所有数据服务开发的基础,这些基础模型做到了“书同文,车同轨”,无论应用的 数据模型有多复杂,总是能溯源到2000张基础表,这奠定了数据核对和认知的基础,最大程度的避免了“重复数据抽取和维护带来的成本浪费。”

    曾经企业的数据抽取就有多份,报表一份,数据仓库一份,地市集市一份,无论是抽取压力、维护难度及数据一致性要求都很高。同时,统一的基础模型将相关业务领域的数据做了很好的汇聚,解决了数据互通的诉求,这点的意义巨大,谁都知道数据1+1>2的意思。

     

    2、数据中台需要不断的业务滋养

     

    在企业内,无论是专题、报表或取数,当前基本是烟囱式数据生产模式或者是项目制建设方式,必然导致数据知识得不到沉淀和持续发展,从而造成模型不能真正成为可重用的组件,无法支撑数据分析的快速响应和创新。其实,业务最不需要的就是模型的稳定,一个数据模型如果一味追求稳定不变,一定程度就是故步自封,这样的做法必然导致其他的新的类似的数据模型产生。

     

    数据模型不需要“稳定”,而需要不断的滋养,只有在滋养中才能从最初的字段单一到逐渐成长为企业最为宝贵的模型资产。

     

    以报表为例,企业报表成千上万的原因往往也是没有沉淀造成的,针对一个业务报表,由于不同的业务人员提出的角度不同,会幻化出成百上千的报表,如果有报表中台的概念,就可以提出一些基准报表的原则,比如一个业务一张报表,已经有的业务报表只允许修改而不允许新增,自然老报表就会由于新的需求而不断完善,从而能演化成企业的基础报表目录,否则就是一堆报表的堆砌,后续的数据一致性问题层出不穷,管理成本急剧增加,人力投入越来越多,这样的事情在每个企业都在发生。

     

    3、数据中台是培育业务创新的土壤

     

    企业的数据创新一定要站在巨人的肩膀上,即从数据中台开始,不能总是从基础做起,数据中台是数据创新效率的保障。研究过机器学习的都知道,没有好的规整数据,数据准备的过程极其冗长,这也是数据仓库模型的一个核心价值所在,比如运营商中要获取3个月的ARPU数据,如果没有融合模型的支撑,得自己从账单一层层汇总及关联,速度可想而知。

     

    在如今的互联网时代,企业都在全力谋求转型,转型的关键是要具备跟互联网公司一样的快速创新能力,大数据是其中一个核心驱动力,但拥有大数据还是不够的,数据中台的能力往往最终决定速度,拥有速度意味着试错成本很低,意味着可以再来一次。

     

    4、数据中台是人才成长的摇篮

     

    原来新员工入职要获得成长,一是靠人带,二是找人问,三是自己登陆各种系统去看源代码,这样的学习比较支离破碎,其实很难了解全貌,无法知道什么东西对于企业是最重要的,获得的文档资料也往往也是过了时的。

     

    现在有了数据中台,很多成长问题就能解决,有了基础模型,新人可以系统的学习企业有哪些基本数据能力,O域数据的增加更是让其有更广阔的视野,有了融合模型,新人可以知道有哪些主题域,从主题域切入去全局的理解公司的业务概念,有了标签库,新人可以获得前人的所有智慧结晶,有了数据管理平台,新人能清晰的追溯数据、标签和应用的来龙去脉,所有的知识都是在线的,最新的,意味着新人的高起点。

     

    更为关键的是,数据中台让新人摆脱了在起步阶段对于导师的过渡依赖,能快速的融入团队,在前人的基础上进行创新。数据中台天然的统一,集成的特性,有可能让新人打破点线的束缚,快速构筑起自己的知识体系,成为企业数据领域的专家。

     

    当然,数据中台的建立不是一蹴而就的,每个企业都应该基于实际打造独有的中台能力,在这个过程中,需要遵循一些原则:

     

    首先,企业的组织架构及机制需要顺势而变。比如以前负责数据的部门或团队往往缺乏话语权,面对业务需求往往是被动的接受的角色,这让一切数据中台的想法化为泡影,需要为数据中台团队授权。

     

    其次,要改变工作方式。现在很多企业的数据团队的主要工作内容就是项目管理、需求管理等等,当一个项目完成后又投入到下一个项目,做好一个需求后又开始负责下一个需求,这样的工作确实非常锻炼人的组织、协调能力,但这样能力的提升与工作时间的长短并不是呈线性增长的,虽然增加了项目和需求管理经验,但并不能在某一个专业领域得到知识和经验的沉淀,随着时间的流逝,越来越多的人会失去最初的工作积极性和创造性,事实上,数据人员只有深入的研究业务、数据和模型,端到端的去实践,打造出数据中台,才是最大的价值创造,才能使得持续创新成为可能。

     

    第三,数据中台的团队要从传统的支撑角色逐步向运营角色转变。不仅在数据上,在业务上也要努力赶超业务人员,中台人员要逐步建立起对于业务的话语权,不仅仅是接受需求的角色,更要能提出合理的建议,能为业务带来新的增长点,比如精确营销。

     

    最后,中台是适合公司特点的。最合适的中台是当你深入了解业务、产品、系统、组织,而且不仅了解今天在哪里,还要了解过去是怎么演变而来,未来又会怎么演化。只有当了解所有的东西之后,才能做出较好的中台架构设计。

    总结:数据中台是把业务生产资料转变为数据生产力,同时数据生产力反哺业务,不断迭代循环的闭环过程——数据驱动决策、运营

    展开全文
  • 什么中台

    千次阅读 2019-10-25 12:17:40
    文章目录中台——为前台而生一、没有中台的时代——传统项目二、中台的出现背景(1)国外(最先)(2)国内(部分)A. 阿里巴巴B. 华为三、什么中台四、为什么要做中台五、前后台三者之间的关系六、中台的分类...
  • 前台、中台、后台到底是什么

    千次阅读 2021-03-16 09:06:22
    前台、中台、后台到底是什么?01 前台02 中台1. 业务中台2. 数据中台03 后台 作者:欧创新 邓頔 来源:大数据DT 导读:很多人提到中台时自然会问:“既然有中台,那是否有前台和后台?它们各自的职责又是什么呢? ...
  • 伴随着云计算、大数据、人工智能等IT技术迅速发展及与传统行业实现快速融合,一场由数字化和智能化转型带来的...阿里在今年发布“双中台+ET”数字化转型方法论,“双中台”指的是数字台和业务中台。 数据中台...
  • 历史背景 马老师13年参观欧洲的游戏公司:Supercell,将该公司的Supercell...中台的强大重点在“”,而不是一味的“大而一统”,要真正能为前台采取快速行动提供有价值的火力支援。 有了中台,前台的业务不用从0
  • 前台、后台我知道,中台什么呢? 今天一早起来,整个互联网圈都被腾讯的组织架构调整刷屏了,甚至有些人对腾讯新的6大事业群如数家珍,侃侃而谈,搞得比对自家公司的组织架构还清楚一样。 腾讯进行组织架构调整...
  • 浅谈:什么中台

    万次阅读 2019-01-18 10:55:37
    第一次听到“中台”这个词,是实习期间在参与公司的一个电商项目时,当时冒出的想法是中台什么鬼,之前只听过有“前台”和“后台”,居然还有个“中台”这样一个神奇的存在。 那…… 中台到底是什么?通过查阅...
  • 大中小前台

    千次阅读 2019-06-26 09:04:17
    1.什么是“大中、小前台” 关键词:精准打击、管理高效、资源整合、灵活敏捷 阿里巴巴 “大中、小前台”机制的提出,某种程度上是从传统的事业部制向准事业部制的转换。就阿里巴巴而言,“前台”就是贴近最终...
  • 通俗易懂解释什么是“中台

    千次阅读 2019-10-03 09:15:35
    通俗易懂解释什么是“中台” 随着互联网公司崛起,“中台”这个词也进入了人们的视线。BAT 等公司纷纷推出了自己的中台系统。那么,什么中台系统?它是如何诞生的?它长什么模样?我们为什么需要它?一串串的...
  • 中台是个什么鬼?

    万次阅读 多人点赞 2019-01-26 11:36:17
    从去年开始,好像就有一只无形的手一直将我与“微服务”、“平台化”、“台化”撮合在一起,给我带来了很多的困扰和思考与收获。故事的开始源于去年的技术雷达峰会,我在会上做了一...
  • 2、《中台什么样子》,带大家对中台有一个直观的印象,一起看看中台到底“长什么样”; 3、《中台的定义》,我们能否给「中台」这个相对抽象的概念找到一个清晰的定义,通过定义能让抽象的概念清晰化,从而明确...
  • 大数据的“数据中台”是什么

    千次阅读 2020-04-13 14:10:10
    从去年大火到今年的“数据中台”几乎变成了企业圈内人人探讨的热门话题,但究竟什么是数据中台? 数据中台是一个思维,一个概念,更是一种趋势。简单来说,数据中台连接数据前台和后台,突破数据局限,为企业提供更...
  • 来源:中国电子报“忽如一夜春风来,千树万树梨花开。” 这首诗形容当前“中台”概念的风靡非常恰当。IT圈里不乏新的概念、新的“网红”,如今,“中台”一词占据了C位,成为软硬...
  • 什么中台架构?

    万次阅读 2019-07-22 11:50:44
    具有创新性、灵活性的“大中、小前台”的机制,即作为前台的一线业务会更敏捷、更快速的适用瞬息万变的市场,而中台将集合整个集团的运营数据能力,产品技术能力,对各前台业务形成有力的支撑。整体内容如下: ...
  • 灾备经常提到的RTO和RPO是什么意思 https://zhidao.baidu.com/question/1706463534212352700.html RTO(Recovery Time Objective,RTO)恢复时间目标,指在故障或灾难发生之后,一电脑、系统、网络或应用停止...
  • 中台的末路

    千次阅读 2019-09-26 14:41:11
    各大公司都在吹捧中台理念。仿佛中台是业务复杂性的救世主。是某些架构师和 PM 的新出路。各种割韭菜的讲中台的课程层出不穷。 当然,吹牛逼的时候大家都是拣好的说,苦逼的东西就只有内部人士知道。中台到底靠谱...
  • 阿里“小前台、大中”的解读

    千次阅读 2018-10-17 11:21:35
    审核去年底阿里巴巴集团CEO发出内部信,宣布组织结构全面升级,建设整合阿里产品技术和数据能力的强大中台,进而形成“小前台,大中”的组织和业务体制,使前线业务更加灵动、敏捷,迎接未来新商业环境带来的机遇...
  • 白话解读“中台”技术

    千次阅读 2019-08-14 12:47:58
    什么中台系统?它是如何诞生的?它长什么模样?我们为什么需要它?一串串的问题不禁浮现在我们的脑海,今天我们就带着这些问题,一起走进中台什么中台中台诞生任何一个软件系...
  • 阿里大中小前台解读

    万次阅读 2018-12-19 16:20:59
    什么是大中,小前台 大中,小前台的开发模式本质上就是资源集中化,中台通过集合整个集团的运营数据能力,产品技术能力,来对各前台业务形成强力支撑。通过技术台化,将产品开发的流程变得更加简洁高效,每一...
  • 本书从阿里巴巴启动中台战略说起,详细阐述共享服务体系如何给企业的业务发展提供了支持。介绍阿里巴巴在建设共享服务体系时如何进行技术框架选择,构建了哪些重要的技术平台等,此外,还介绍了组织架构和体制如何更...
  • 我看中

    千次阅读 2019-08-01 22:01:00
    中台最近又成了比较热的话题,结合我对中台的认知,试图跟你回答下这些问题:1.互联网公司的中台到底是什么?2.中台有哪些类型?3.中台有哪些困境?4.互联网公司中台的现状 ...
  • 最近阿里巴巴分享了《阿里巴巴数据中台实践》这个PPT(自行搜索原始文章),对于数据中台的始作俑者,还是要怀着巨大的敬意去学习的,因此仔细的研读了,希望能发现一些不一样的东西。 读这些专业的PPT,实际是非常...
  • 早在今年四月份,便开始看《大数据之路:阿里巴巴大数据实践》一书,再迅速过了邓中华老师这本《大数据大创新:阿里巴巴云上数据中台之道》,基本上可以窥见阿里数据中台的建设过程以及一些技术细节。其中宗华作为一...
  • 大概意思就是所有的公共逻辑都给你定义好了,你想创新还创新不了,我只能说这个中台没留钩子,没给自定义的后门,让你们家的中台设计者好好思考一下,中台没能约束你创新,是你的中台本身没创新,产品逻辑还没捋顺...
  • 大中+小前台概念

    万次阅读 2018-01-03 15:45:57
    作者:东子 ... 来源:知乎 ...1.什么是“大中、小前台” 关键词:精准打击、管理高效、资源整合、灵活敏捷 阿里巴巴 “大中、小前台”机制的提出,某种程度上是从传统的事业部制向准事业部制的转换。

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 78,137
精华内容 31,254
关键字:

强中台什么意思