精华内容
下载资源
问答
  • 中台建设

    千次阅读 2021-02-20 09:27:11
    中台建设

    前言

     

    中台建设,是近两年非常火热的一个话题,从产品中台,到技术中台,再到组织中台,各种概念、理念,以及方法论被深度的研究、探讨。

     

    对于互联网产品领域来讲,中台更多的是2B产品建设中涉及的课题,因为软件系统的抽象复用,更多的是做复杂B端系统建设中面临的问题。因此,中台产品设计,是所有B端产品经理应该深度关注的课题。

     

    针对B端产品设计领域,中台产品到底该如何设计?有何特点?设计的本质是什么?有何挑战?本文将从全新的视角,重新审视中台产品建设,让您更加深刻地理解中台产品设计精要。 

     

    一、经典视角下的中台建设

     

    首先,我们有必要回顾下经典的中台建设视角。一般来讲,行业内往往从组织中台、产品中台、数据中台、技术中台这四个主题切入并探讨中台建设。

     

    组织中台:组织中台研究的是企业内部的组织结构设计,如何通过合理的权责划分,以及管理架构搭建,提高业务部门的经营能力,迅速响应市场变化,并且能够让企业提升整体跨部门跨业务线协作效率,降低运营成本,实现标准化管理。所谓组织中台的设计思路,实际上已经存在了很多年了,在集团企业中,往往采取事业部制的组织形态,再配合各种共享服务中心的建设,实现前后端业务分离,前端业务保持机动性,后端业务提供火力支援。类似于财务共享服务中心FSSC(Financial Shared Service Center),人力资源共享服务中心HRSSC(Human Rersources Shared Service Center),其实就是典型的中台管理思路下的组织形态和职能部门建设的方法,如下图。

     

    图片

    一个常见的事业部制的组织机构图

     

    产品中台:产品中台研究的是企业内部的软件系统如何进行抽象和设计,从而让企业的软件系统就像搭建积木一样灵活,可以重复高效利用现成的软件组件,快速组装开发出新的软件系统,从而节约软件开发成本,并能够快速支持新业务开展。很多文章也把这类中台产品称作业务中台,或业务中台产品。

     

    目前被广泛讨论的产品中台包括电商交易中台、账号中心中台等,其中电商交易线又被更加广泛的探讨,包括了订单中台、支付中台、商品中台、促销中台等。

     

    产品中台还有另一层含义,即能够给全公司全企业提供一致服务的管理软件产品,也可以纳入产品中台的范畴,例如呼叫中心、项目管理软件。从某种程度上来讲,这些标准化软件产品也是中台产品。

     

    数据中台:数据中台研究的是企业内部的数据管理、治理问题,以及数据产品体系和数据底层结构的搭建问题。数据中台研究的范畴,包括企业统一的数据安全、数据规范、元数据管理、数据编码管理,以及数据仓库、数据集市的拓扑架构,也包括大数据底层和运算能力建设和复用。要注意的是,数据中台更多的关心从业务和产品层面对数据的治理、管理、应用,而非技术层面问题。

     

    技术中台:技术中台研究的是软件产品的技术实现过程中,哪些技术上的处理能力和架构可以进行抽象复用,例如消息中间件MQ,分布式计算框架Hadoop,分布式服务框架HSF,各种Open API等等。技术中台是纯粹从技术实现底层来思考基础服务和基础模块的复用能力,其设计思路和产品中台一脉相承,是技术人员需要深度思考的问题。

     

    以上四个主题,涵盖了互联网模式下对于企业中台建设的所有课题范围,其中,对于产品经理来讲,工作相关性最强,最需要关注的是产品中台和数据中台。

     

    实际上,上述四个主题,也正是传统企业信息化建设中非常核心的企业架构EA(Enterprise Architecture)理论,对企业业务管理的IT视角下的切分。其中组织中台对应EA中研究的企业业务架构EBA(Enterprise Business Architecture)中的组织架构治理部分,产品中台对应EA中研究企业应用架构的EAA(Enterprise Application Architecture),数据中台对应EA中研究企业数据架构的EDA(Enterprise Data Architecture),技术中台对应EA中研究企业技术架构的ETA(Enterprise Technology Artchitecture)。

     

    关于EA的论述,可能让很多纯互联网背景的同学读起来很困惑,但实际上,互联网企业所谓的中台建设思路,逃不出经过几十年沉淀的信息技术理论框架,以及管理理论框架。而传统信息技术理论,在互联网企业的B端产品建设中具有极强的参考、借鉴价值。

     

    然而,我们今天讨论的主题,还不是研究企业架构EA对中台建设的指导,而是尝试从更加深层次的角度,去探索产品中台、数据中台的设计本质,尤其是对于B端产品经理来讲非常核心的产品中台的设计精要。

     

    对于产品中台,目前公认的关键要点包括如下关键词:企业级、抽象、下沉、复用,这些关键词代表了产品中台建设的特点,同时也是在企业应用架构设计中需要深层次思考的问题。(所谓企业应用架构,是指企业内部的各个软件系统,应该以什么样的形式建设、组合,从而高效的支持企业的经营运作)

     

    因此,如果要深层次的思考软件产品的企业级抽象、下沉、复用问题,可以从以下三个角度进行全新的审视,分别是:基于抽象复用的视角,基于架构合理性的视角,基于业务统一管理的视角。

     

    我们通过从这三个视角切入,可以全面的解构中台产品设计的要义,并且可以更加全面的穷举中台建设的方法论、要点和难点。

     

    二、基于抽象复用的视角建设中台

     

    1、建设的目的

     

     

    所谓抽象复用,是指对软件中重复的功能和模块进行抽象并下沉一层。

     

    什么叫抽象?什么叫下沉?我们举例说明。

     

    如下图,有两个系统I和II,其中系统I中具有模块M,系统II中具有模块N,经过分析发现,模块M和N的功能高度类似重复,完全可以抽象合并,避免重复建设。

     

    图片

    识别共性模块

     

    现决定将模块M和N分别从系统I和II中剥离出来,如下图。

     

    图片

    抽离共性模块

     

    将M和N剥离出来后,我们对其功能进行抽象合并,如下图。M和N合并后,得到模块A + B + C,其中A是M和N中共有的功能,B和C分别是针对系统I和II提供的一些定制化功能。虽然有少量功能无法做到完全合并和复用,但新模块中绝大多数功能集合A已经被高度抽象,可以被系统I和II复用。而被剥离合并后的全新模块A+B+C,将会下沉一层,作为基础服务,为系统I和II提供支持。如下图。

     

    图片

    合并共性模块

     

    以上案例,演示了系统功能如何被合并、抽象、下沉,这种设计思路,节约了软件研发成本,是一种非常经典的中台设计思路。

     

    接下来,我们通过一个实践案例,进一步演示这种设计思路。

     

    2、案例:统一客户视图建设

     

     

    1)案例背景

     

    某流量型互联网公司,变现模式主要为针对中小企业的广告售卖,业务团队包括电话销售团队(IS,Inbound Sales),外勤线下销售团队你(OS,Outbound Sales),以及客服团队。三个业务团队有着各自独立的业务系统支持其运转,每个业务系统中既有个性化功能,例如针对IS的外呼管理、针对OS的拜访管理、针对客服的关怀回访;也有功能高度类似的重复功能,例如客户管理列表,客户详情页。系统架构图如下图所示。

     

    图片

    重复的客户详情页建设

     

    2)遇到的问题

     

    三套业务系统各自有产品研发团队维护,系统早期为了快速支持业务从而分别建设,快速响应业务诉求,为业务发展立下了汗马功劳。但随着系统的逐步成熟,其中一些问题也逐渐凸显,首要问题就是功能重复开发建设问题。虽然三个业务部门对客户关注的侧重点不同,但基本诉求是一致的,希望能看到客户所有的重要信息。因此,三个系统的客户详情页功能已经高度类似,而每次针对客户资料的调整变化,需要三个研发团队分别重复开发三遍,非常浪费人力资源。

     

    3)解决方案

     

    为了解决三套业务系统中高度类似的客户详情页的重复开发问题,也为了给业务人员提供一致的、准确的客户视图,公司决定将客户详情页模块从三个业务系统中剥离,将功能合并后,建设“统一客户视图(ECIF)”模块,该模块拥有一致的客户数据底层,并提供完整的客户信息查询服务化接口,以及可以嵌入业务系统直接使用的客户详情页面组件。“统一客户视图”将作为中台产品,为各个业务系统提供企业客户数据查询的服务以及视图。如下图。

     

    图片

    将客户详情页抽象下沉建设统一客户视图中台

     

    任何业务系统,既可以调用该模块的成熟接口查询客户数据并自己设计前端页面,也可以直接嵌入“统一客户视图”提供的现成的客户详情页组件,并且该页面组件还可以进行灵活的权限配置,定义针对不同的业务系统、不同用户角色的数据查看、编辑范围。

     

    由此,我们完成了对客户详情页的抽象下沉,三套曾经重复开发的页面被合并成了一套,以后研发团队只需要维护这一套页面,研发人力得到了释放。

     

    这就是典型的基于抽象复用的视角设计的中台产品。这种模式有一个显著特点,即软件的抽象和复用是成本问题,不影响业务。案例中,虽然有三套客户详情页被重复建设,但只是个资源浪费问题,并不会影响到业务的开展。

     

    3、面临的挑战

     

     

    对软件功能模块进行抽象复用,是具有很强挑战性的工作。如果分析不当或经验不足,有可能做出错误的抽象方案。

     

    我们总是希望能够对软件和功能进行正确的抽象决策,让抽象出的系统和模块具有高度重叠的特性,例如下图这样。

     

    图片

    期望的抽象结果

     

    然而受限于经验不足,或掌握的信息不足,很可能做出错误的判断和设计,做出了错误的抽象决策,最后被抽象的系统模块,并不能被充分复用,只是制造了一个畸形的别扭的模块,生硬的把一堆毫无关联的功能强行捏在一起,给研发工作反而带来的更大的麻烦,如下图。

     

    图片

    错误的抽象结果

     

    我们将通过实际案例,给大家演示这种设计错误。

     

    4、案例:订单中心的建设

     

     

    1)案例背景

     

    某互联网公司同时开展了电商业务和电影票业务。每条业务线都有独立的C端系统、后台交易系统(包括商品管理、订单管理、促销管理)来支持业务。为了追逐潮流,公司决定将两条业务线的订单中心合并,实现订单中台,如下图。

     

    图片

    并不一定正确的订单中台

     

    2)错误的决策

     

    实际上,公司经营的B2C电商业务和影票业务,在交易形态上有较大区别,尤其体现在订单模块的设计上,订单的状态机、数据模型和财务账务处理模式完全不同,强行将两者合并后,并没有太多的共性模块和功能,最终只是表面上看起来实现了订单中台,但是里边的功能模块各自独立,各自运转,完全没有抽象和复用。

     

    3)扩展难题

     

    现在,公司管理者以为拥有了强大的“订单中台”,可以为任何新业务的快速开展提供支持。很快,公司决定开展机票售卖业务,针对机票业务,有独立的C端,商品管理,促销管理。但是当产品经理和工程师开始期待订单中台的强大能力时,遗憾的发现订单中台无法给机票业务提供任何现成的功能复用能力,机票的订单模型和电商以及影票都不相同。

     

    机票业务线的设计人员面临一个尴尬的局面,要么“政治正确”的将机票订单中心纳入订单中台统一建设,但实际上这会严重降低开发效率,因为中台研发团队肯定不会像机票业务自己的研发团队那样重视新业务的开展;要么就抛弃订单中台,自己独立开发订单模块,但这样做又会显得订单中台没有产生该有的价值。如果你是机票业务的负责人,该怎么权衡取舍呢?此时的系统架构如下图。

     

    图片

    订单中台并不能很好的支持机票业务

     

    可见,订单中心,在不同业务模式下,并不一定适用于中台化建设,设计人员要有足够的思辨能力,判断产品形态上是否值得抽象下沉,是否能够提供复用能力。然而这也是软件工程设计中非常难的部分。

     

    任何软件系统的设计,都是基于归纳法,而非演绎法,即软件设计人员总是通过对现有世界和业务的总结提炼,完成软件设计,而无法通过推测演绎,完成软件设计。设计人员无法对业务的未来做出预测,只能基于有限的经验,尽量的保证设计的灵活性和正确性。理解这一点非常重要,这会让你在软件设计、产品设计时心存敬畏之心,不会一味地追求短期无法论证的结论而产生的严重的过度设计。

     

    5、实践中的建议

     

     

    以下是基于抽象复用的视角建设中台的几条建议。

     

    • 明显具备共性的模块尽早抽象

     

    B端产品的体系化设计中,很多形态的产品是具备明显共性的,可以尽早的进行抽象设计,这样在系统架构建设的早期,就能做出正确的设计方案,而且并不会增加多少研发工作量,但会让未来的系统扩展更加轻松。例如,业务系统的统一权限管理系统、单点登录系统、组织架构系统、公告系统、短信系统,这些系统都应该尽早抽象建设。

     

    • 不确定共性的模块事后抽象

     

    例如统一客户视图、订单中心、商品系统,这些软件模块,很难判断在多业务线场景下能够完全复用,如果对于是否抽象拿不准主意,完全可以先不做抽象,等业务渐渐明确后,有足够的信息作出充分的分析和判断,再决定是否合并抽象。

     

    • 避免人力外包中台

     

    中台的建设一定要有合理的原因,如果只是为了中台而中台,会让系统的架构混乱,工作效率反而降低。而且很容易产生“人力外包中台”现象,即下游业务团队把中台团队当做乙方来合作,“反正你们要帮我们打理好这些模块,不管是否合理,需求提交给你就必须得高优支持,否则就是不支持业务一线”,这样会让中台产品和中台团队失去该有的气质,形成团队间的敌意和隔阂。

     

    三、基于架构合理性的视角建设中台

     

    1、建设的目的

     

     

    软件的应用架构设计,不是随意任性的系统、模块组合,而是有着深刻的设计方法论与合理性诉求。为了满足应用架构合理性的要求,很多时候需要将软件抽象并下沉一层。

     

    所谓应用架构合理性,是为了避免因为应用架构设计的不合理,而造成业务问题。企业中软件系统的建设,很容易出现两个常见问题,一个叫做烟囱应用,一个叫做数据孤岛。

     

    企业内部的软件系统,很多都是为了某个独立的业务部门而设计研发,例如CRM,WMS,OA。这些系统设计初衷是支持业务部门的独立运作,而企业内部跨部门的业务流程和数据传递是无处不在的。如果业务系统没有做很好的架构设计或服务化处理,那么系统之间就无法通信交流,业务流程就会被割裂,每一个应用系统就像一根根烟囱一样,互无联系,这就是“烟囱应用”。烟囱应用会造成部门墙,让企业的业务无法顺畅流转运作。

     

    图片

    烟囱应用

     

    因为烟囱应用的存在,每个应用系统生产的数据会更加孤立,系统之间数据没有关联,没有打通,系统之间的数据就像一座座孤岛,彼此独立,数据的价值被严重弱化,数据孤岛会造成严重的业务问题,接下来的案例,会演示数据孤岛问题,以及如何通过中台化的架构设计思路解决该问题。

     

    图片

    数据孤岛

     

    2、案例:客户主数据的建设

     

     

    1)案例背景

     

    某公司开展了线下零售店和线上商城两条业务线,由于这两条业务线开展之初是独立经营建设管理,因此系统建设也是由两个产研团队分别负责,这就造成了线上和线下业务分别有一套客户数据库。现在公司设立了独立的客服一级部门同时服务于线上线下业务,而客服人员使用的客服业务系统,是不能同时访问两套客户数据库的,因此只能将两套客户数据库冗余成一套针对客服业务系统使用的客户数据库。此时,公司内部一共有三套客户数据库,各自像孤岛一样存在。如下图所示。

     

    图片

    客户数据存在孤岛

     

    2)遇到的问题

     

    显然,上述应用架构存在严重的数据孤岛问题,并且会产生严重的业务问题。具体如下:

     

    • 线上客户如果想体验线下服务需要重新注册会员,客户体验极差;

    • 线下客户如果想体验线上业务需要重新注册账号,客户体验极差;

    • 线上线下客户数据重复,无法识别唯一性;

    • 呈现给客服人员的客户数据是同步后的具有滞后性;

    • 客服无法准确识别客户信息并帮助客户修改资料;

    • 企业无法做线上线下客户消费的关联性分析,无法做交叉销售。

     

    3)解决方案

     

    因为应用架构设计的不合理,导致业务受到严重影响,客户体验差。如何解决多个业务系统中存在的数据孤岛问题呢?实际上解决办法也很简单,就是将客户数据库合并后只保留唯一的一份客户数据资料,所有下游业务系统都访问这个唯一的客户数据库,进行客户数据的增删改查操作。此时,系统之间的拓扑结构发生了改变,新的应用架构图如下图。

     

    图片

    通过主数据设计思路解决孤岛问题

     

    这种针对企业的核心的、相对稳定不容易变化的、被充分共享的数据,叫做主数据MDM(Master Data Management),通过主数据的设计思路,可以很好地解决烟囱应用和数据孤岛问题,尤其是数据孤岛问题。主数据作为一种基础服务,正是一种中台化的治理理念。企业内常见的主数据包括客户主数据、供应商主数据、组织机构主数据、商品主数据等等。你可能之前没有听到过主数据的概念,但仔细想想,实际上主数据在B端产品的架构设计中时刻存在。

     

    基于应用架构合理性的视角来构建中台,这种模式的特点,是软件的抽象和架构设计会影响业务,这和基于抽象复用的视角构建中台有着显著地区别,前者如果不做抽象和下沉,会造成很多业务问题,例如案例中提到的客户管理问题;后者如果不做抽象和下沉,只是成本问题,不影响业务,例如之前统一客户视图的案例,虽然开发资源浪费,但系统的问题并不会影响业务开展。

     

    3、面临的挑战

     

     

    有时候,对于企业来讲,正确的架构并不一定是合理的选择,反而错误的架构可能更有益于业务发展。理想化的架构设计,可能反而会拖慢业务节奏。这是架构设计中经常面临的问题,我们通过一个案例来进行阐述。

     

    4、 案例:账号中心的建设

     

     

    1)背景

     

    某互联网公司起家于短视频业务,业务发展良好,市场占有率高,短视频产品功能形态丰富。公司基于各方面考虑,决定同时开展理财业务,希望在火爆的P2P市场中狂欢一场。

     

    公司的短视频业务的账号中心,建设初期就采用了服务化的思路,因此很好的和短视频前台业务的C端APP实现了解耦合,实际上已经实现了中台化的建设部署。面对新开展的理财业务,产研负责人决定复用一套账号中心(Passport),从而发挥中台产品优势,为新业务赋能。理财业务的产品技术体系是独立的,虽然想完全独立研发所有的前后端系统,但是迫于压力,不敢违背公司搞大中台、小前台的指导思想,决定复用基于短视频业务构建的账号中心中台来开展业务。整个架构图如下图。

     

    图片

    理财业务复用了短视频业务的账号中心中台

     

    2)遇到的问题

     

    账号中心作为中台产品,除了为短视频业务提供服务,还能快速赋能新业务,支持理财业务开展业务。理财业务只需要建设对应的APP C端和简单的管理后台,对于比较复杂的账号中心,完全不用浪费人力从头开发。看起来,完美的架构发挥了优势,支持了业务。产研负责人很开心,中台理念得到了落地,在老板面前有面子。然而事实真的如此么?

     

    理财业务开展过程之中,需要针对账号中心做较多的个性化功能定制,例如需要实线账号的信用认证管理,地址管理,银行卡管理等等,相对于短视频业务的账号中心,理财业务对账号中心的功能要求、安全性要求、风控要求更高。理财团队给账号中心提交了一堆需求,但是账号中心的响应速度非常缓慢,因为两个团队不是一个产研体系,也没有管理关系,账号中台团队总是将理财业务的需求优先级调到最低。

     

    因为账号中台的响应速度慢,理财业务负责人多次找老板沟通协调,但公司对待理财业务的态度又变的有些暧昧,并没有保持最强有力的支持,这下就比较尴尬了,理财业务虽然有自己的研发团队,但是账号中心用的却是中台的,而中台团队又不是很支持理财业务(按照中台团队的说法,理财业务提交的需求个性化太强,工作量巨大,对短视频业务一点价值都没有,投入产出比低,优先级低),导致业务进展缓慢,不能很好地支持客户需求和业务发展诉求,浪费了宝贵的竞争时间,只能眼睁睁的看着对手攻城略地,越走越远。

     

    可见,设计了正确的中台产品,以及保证了架构的合理性,在某些情况下,反而会影响到业务的快速发展。

     

    5、 实践中的建议

    5. 实践中的建议

     

    架构设计的核心目标是支持业务发展,某些时候可以允许不合理的架构存在。

     

    在Passport的案例中,理财业务实际上是按照独立公司、独立品牌运作的,包括产品研发团队都是独立的。作为一个不确定性高、市场变化迅速的创新业务,极有可能运作半年后项目就中止了,这时候业务上更希望保持快速的响应和落地能力,而不是考虑软件架构是否合理,即便理财业务独立开发了Passport,即便理财业务发展成功、最后又需要将两套Passport合并,即便两套Passport合并非常麻烦,成本高,但是,至少业务通过快速响应,迅速切入市场,取得了成功。

     

    而且,有些时候,所谓的中台化改造,架构合理性设计,会严重影响到原有系统和业务的稳定性。例如,假设新开展的B2B业务,要复用B2C业务的订单中心,将B2C业务的订单中心实现中台化改造,那么问题来了,B2C业务作为公司的核心主营业务,承担了每日十几万的订单交易量,营收占公司整体营收的95%。而B2B业务作为创新实验项目,预计每个月只能带来几十万的GMV,并且,如果要将B2C的订单中心中台化,兼容B2B业务,要承担非常高的系统改造风险。那么问题来了,有必要为了架构合理的中台化建设,而承担高风险(甚至有可能把主营业务的核心B2C订单系统干趴下),去支持小体量的创新业务么?

     

    产品设计人员、架构师、产研负责人,在面临这些问题时,必须谨慎思考,基于对业务、市场、系统、代码、架构、人员、团队,各方面进行综合判断后,做出决策,即便有时候做出的决策在系统架构上看起来是错误的,但对于公司和业务的长远利益来讲上是正确的。

     

    四、基于业务统一管理的视角建设中台

     

    1、建设的目的

    5. 实践中的建议

     

    企业发展到一定阶段后,往往会出现集中化管理的诉求,对之前各自独立的子公司、事业部,在某些方面实现集中化的管理控制,一方面为了加强集团管控能力,另一方面也是因为业务协同经营需要。

     

    如果想实现这类业务诉求,就必须通过对软件的下沉和抽象,来实现业务的集中化管控。下边,我们来通过案例进行说明。

     

    2、案例:集团多业务线统一客户销售管控

    5. 实践中的建议

     

    1)案例背景

     

    某保险集团经过多年发展,实现了寿险、财险、理财稳定的业务三角。三条业务线分别由独立的全资控股子公司经营,三家公司的所有业务系统,从C端到B端,也全部独立建设,互无交集。简化版的系统架构如下图。

     

    某集团三条业务线下的系统架构

     

    2)业务诉求

     

    三家公司独立经营,保持了充分的灵活性,能够快速响应市场变化,取得了成功。但是,随着经营的深入,有一些问题也逐步暴露,并且变得越来越严重,总部高度关注,需要尽快解决,典型问题如下:

     

    • 三家公司经常出现重复采购流量的现象,浪费集团营销成本;

    • 三家公司往往对同一个客户重复营销,造成客户投诉;

    • 客户价值不能充分挖掘,跨业务线的交叉销售和向上销售做的不好。

     

    现在,集团下定决心解决这些问题,而解决这些问题,必须通过软件产品的中台化建设来实现。

     

    3)解决方案

     

    针对集团面临的三点问题,解决方案如下:

     

    • 建立集团的统一客户标识数据库(作为集团统一客户管理中心的核心模块来建设),从集团层面识别客户唯一性,确保各个业务线采买流量时能够正确过滤已有客户,节约成本;

       

    • 具备客户唯一性识别的能力后,可以实现集团层面的统一客户营销管理、客户旅程管理、以及防骚扰控制。通过统一客户管理中心实现客户旅程模块、防骚扰控制模块,将控制策略插入到各个子公司的销售系统中,确保各个子公司的销售触达任务开始之前首先要经过集团层面的控制中心的校验和管理,从而确保同一客户不会同时被几条业务线的销售重复骚扰;

       

    • 统一客户管理中心还可以实现交叉销售模块,针对某些业务场景下的客户数据,进行跨业务线的销售任务分发,例如识别某寿险客户经济实力较好,则将客户推送到理财业务的销售系统,尝试二次销售转化。

     

    整个系统架构如下图。

     

    图片

    通过集团统一客户管理中心实现跨业务线的客户销售管控

     

    综上可见,集团层面,如果想对各个子公司的客户资料、客户营销、客户触达进行统一管理,就必须建立统一客户管理中心,首先实现客户唯一性标识,其次基于客户唯一性标识落地各种统一客户管理策略。集团统一客户管理中心,正是中台设计思路的实践应用。而集中化的业务管理诉求,则必须通过软件的抽象和架构设计来实现,这也是这种中台建设模式的特点。

     

    3、面临的挑战

    5. 实践中的建议

     

    业务集中管控的策略,总是滞后的,这是因为业务开展很长的一段时间中,各个业务线独立运作,相安无事,即便有一些小问题,也是可以容忍的,或无关紧要的。但是当企业规模增长到一定阶段,业务线之间的管理问题会越来越突出,之间的协同问题也会越来越明显,此时就有必要进行集中化的管理和控制。

     

    滞后的业务管理决策,会对系统建设带来较大的挑战,因为各个业务线、事业部、子公司的系统已经发展的非常成熟,针对成熟的系统,去调整架构,改变系统和业务的逻辑,置入新的外部逻辑,是一件很有挑战的事情。

     

    针对未来可能的集中管控诉求,是否能够在系统架构上提前布局,做好结构性的设计,以便未来的某一天,业务需求发生时,能够顺畅、轻松的进行支持么?实际上这也是不现实的,因为业务上的需求是一个未知数,没必要对未知的需求做架构上的过度设计。

     

    总之,集中化的业务管理诉求总是滞后的,这会给系统、中台的设计和实现带来挑战。设计人员要对这个问题有清晰地认知。

     

    4、 实践中的建议

    5. 实践中的建议

     

    针对业务集中管控诉求下的中台建设,有以下建议。

     

    • 不要过多考虑未来不一定发生的事情

     

    集中管控是不一定发生的需求,产品设计初期和中期,没有必要为未来不确定的事情提前做过多的布局,因为很有可能未来根本用不到,却会产生过度设计,造成开发资源的浪费,甚至也会让系统架构看起来非常奇怪。例如,案例中的集团客户管理中心,在寿险、财险发展初期和中期,有必要在系统上做出这样复杂的架构设计么?在各自独立经营的子公司推进这种架构的落地,如果没有明确的收益和价值,难度和成本巨大。

     

    • 通过业务价值和业务诉求驱动系统迭代抽象

     

    没有明确的收益和价值,却采用了这种集中控制调度的软件架构设计,这会让各个事业部的核心销售系统被割裂,被控制,被牵制,恐怕各个事业部是不会愿意配合这种项目的。即便这种架构很合理,在可预期的未来一定是必须的,但是在当前阶段下却没有任何价值,还会影响各个事业部各自的工作。没有业务价值和业务诉求的系统迭代抽象工作,是很难推动落地的。

     

    • 项目必须有高管介入确保推进

     

    即便业务上已经有明确的诉求,公司决定了执行架构调整,实现集中管控,项目的推进,依然会阻力重重,因为这种调整首先会打破原有的利益格局,也会造成工作习惯的巨大改变。这类集中管控的项目,如果想成功落地,必须有集团层面的,超越了各个下游业务线的非常高级别的管理人员牵头挂帅,管理团队必须有统一的认识,通过强有力的项目管理手段,才能保证在项目执行过程中化解任何困难,成功落地。

     

    五、三种视角下中台建设模式的总结

     

    我们已经分别介绍了基于抽象复用的视角、基于架构合理性的视角、基于业务统一管理的视角,这三种视角下的中台建设模式,以及每种模式的建设目的、建设特点、面临的挑战。汇总后得到下表。

     

    图片

     

    这三种视角(或叫三种模式),从左到右,业务属性从弱到强。即最左侧的抽象复用的视角,纯粹是成本问题,和业务关系不大;中间的架构合理性的视角,具备了一定的业务含义和业务价值;最右侧的业务统一管理的视角,则完全是个业务问题了。

     

    任何系统的中台化建设,都可以从这三个视角中找到影子,要么是基于其中的某个视角建设,要么是基于其中的某两个视角来建设。

     

    例如,统一客户视图、报表引擎,这类产品纯粹是成本问题,遵循着抽象复用视角下的中台建设特点。主数据、账号中心、数据集市,这类产品兼具了架构问题和业务问题,遵循着后两种视角下的中台建设特点;而防骚扰、大积分体系(即集团多套积分体系的打通和汇兑中心),则纯粹是基于业务出发而建设的产品中台,遵循着业务统一管理视角下的中台建设特点。

     

    在很多情况下,中台产品兼具了多种属性,例如,订单中心、账号中心、组织机构管理、权限管理,这些中台产品,既是研发成本问题,也是架构问题,同时还会影响业务。再例如,支付、清结算、促销重心、商品中心等中台产品,则既是为了解决业务问题,也是为了解决架构问题,同时也可能还解决了成本问题。

     

    总之,上述三种中台建设的视角,在一定程度上穷举了产品中台(即产品经理关注的软件产品的中台化,也就是媒体上常说的业务中台)建设中的所有出发点和可能性。你可以思考下,目前你所接触的中台,是否处于上述三种视角下的某一种或某几种,通过我们的论述,你是否对相关中台产品设计的特点和要点有了更深刻的认识和理解呢?

     

     

    https://mp.weixin.qq.com/s/J-U53-e0LN6cCBxUfHeGqg

    展开全文
  • 数据中台的典型功能架构:广义的讲数据中台是直接服务于业务系统的数据服务工厂,狭义上讲,数据中台就是可复用的数据API。站在企业架构的角度,从广义上来讲,数据中台(包含数据平台,数据仓库)...

    数据中台的典型功能架构:

    广义的讲数据中台是直接服务于业务系统的数据服务工厂,狭义上讲,数据中台就是可复用的数据API。

    站在企业架构的角度,从广义上来讲,数据中台(包含数据平台,数据仓库)应该提供的服务如下图所示:

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

    做中台之前,首先需要知道业务价值是什么,从业务角度去思考企业的数据资产是什么。数据资产不等同于数据,数据资产是唯一的,能为业务产生价值的数据。对于同一堆数据,不同业务部门所关注的数据指标可能完全不同,怎么让各个跨域的业务变成统一的标准,就需要规划企业的数据全景图,将所有有可能用上的、所有对企业有可能有价值的数据都规划出来,最终梳理出企业的数据资产目录。

    在这个时候不需要考虑有没有系统、有没有数据,只需要关注哪些数据是对企业业务有价值的。这一层不建议做得太细,太细就难以形成标准,不能适用于多个场景了。

    数据治理是数据中台很重要的一个领域,ThoughtWorks认为在现在业务边界消失、需求快速变化的情况下,企业需要具备精益数据治理的能力 — — Lean Data Governance。传统的中心化、事前控制式的数据治理方式,要改变为去中心化、事后服务式的治理方式。

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

    从广义上来讲,数据中台要为企业提供强大的数据资产的获取和存储的能力。但是这个能力不是数据中台的核心功能,很多企业可以基于原来的数据平台,数据仓库等已有的工具来提供数据采集和存储的能力。

    3.数据的共享和协作

    企业的数据中台一定是跨域的,需要让所有的人都知道数据资产目录在哪里。不能因为数据安全,就不让大家知道企业有什么数据。没有共享和开放,数据没有办法流动起来,没有流动的话数据的价值产生的速度就会非常慢。

    所以在数据安全的基础上,企业的数据资产目录要对利益相关者、价值创造者开放,要让业务人员能够做到“Self-Service”。

    数据资产目录是数据中台很核心的一个基础能力,但是往往目前很多的企业都尚未建立这个能力,这也是导致数据在企业内部不开放,不共享,不被利用的很重要的一个原因。

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

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

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

    数据中台需要保证数据服务的性能和稳定性,以及数据质量和准确性,还需要具备强大的服务治理能力。数据服务要在一开始就有整体的顶层设计,从而能够将数据服务做分类,打标签,能够更方便的被搜索被调用,让好的服务浮现出来,让质量不高的服务自动的退市被销毁。

    数据中台是一个生态平台,在数据中台上面会不断生长各种数据服务,所以从一开始就构建好数据服务的治理结构是非常重要的,就想经营一个市场一样。

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

    如果数据中台最终只是做到把数据给到业务人员,那它就只是一个搬运工的角色,数据中台的核心是为业务应用提供有业务价值的数据服务。所以度量和运营数据服务的能力是数据中台的业务能力。

    数据中台应该能够对提供的数据服务及相关行为做持续跟踪和记录,包括哪些数据服务被哪个部门使用、用了多少次等,通过这些去度量每一个数据服务的业务价值。

    数据中台是一个需要用互联网思维去经营的利润中心平台,数据中台的经营分析人员需要分析,了解为什么今天上午这个财务部门的人用了数据中台、调用了十次,下午他不用了,原因是什么,调用了这些数据服务的人通常还会调用哪些其他的数据服务。

    这些都需要相应地做记录、做日志、做分析,要把数据当做像电商平台一样去经营,然后实时地根据这些业务行为数据去提醒数据服务提供方,调整、改变、优化数据服务,这才是可经营的数据中台,也只有这样业务部门才能得到最快的支持和响应。

    一个数据中台的典型逻辑功能架构单初步定义:

    企业数据中台的团队如何构建:

    数据中台是距离业务更近的能力平台,数据中台是一个需要持续运营的数据服务业务平台,所以数据中台的团队不仅仅是一个技术团队,应该将数据中台当做一个产品团队来构建,整体的结构如下:

    数据中台提供两类服务:

    一类是数据资产目录,数据探索,数据分析等服务,让业务和应用部门的人员能够在数据中台上协作的玩数据。

    一类是数据服务,让各个业务系统能够调用这些服务,包括决策分析类的非实时服务和实时的嵌入式交易规则服务。

    对应到这两类服务,数据中台的团队应该包括以下三组:

    中台运营团队:

    将整个数据中台的服务和功能作为产品来运营,对应的绩效是用户满意度,用户存留,这些用户相关的指标。

    中台开发团队:

    负责数据中台的功能层开发,包括平中台本身的架构,中台上的应用(客户服务,业务监控等)功能的开发,对应的绩效是功能的稳定性和客户的满意度。

    数据服务开发团队:

    负责数据中台之上的数据服务的开发,包括数据处理链的开发,服务的开发等,对应的绩效是数据服务的稳定性, 性能和客户的满意度等。

    参考这样的三个团队组成, 分别应该包括如下角色:

    数据中台架构师:进行整体数据中台的技术架构设计,保证数据中台架构的可持续性,稳定性和扩容弹性。

    DataOps工程师:从基础能力上保障数据中台的运行的稳定性和持续演进。

    数据工程师:数据处理工程师,负责数据的获取,处理,建立数据处理链。

    数据服务产品团队:数据服务的产品团队,包括产品经理(PO),业务分析师,体验设计师,还有算法工程师,和数据工程师和数据运营分析师一起协作,创新、设计、生产数据服务。

    数据运营分析师:将数据服务作为产品来运营的数据运营分析师,通过对数据服务上线后被调用的情况的分析来运营数据服务,像经营一个互联网产品一样来经营数据服务。

    数据中台某种角度上,上是一个数据服务的创新、生产、交易的数据服务市场,那么企

    业对于数据中台整体的绩效评价方法也就出来了,那就是:

    企业评价数据中台的标准:数据中台服务的客户,也就是业务系统的满意度。

    数据中台支撑技术:

    建设数据中台一般需要一整套如下典型的支撑技术:

    指标管理系统:指标是中台与前台之间最关键的接口,也是建设数据中台的牛鼻子,因为它是最核心的业务语言,且指标不一致、数据常出错是建设数据中台最常见的出发点。如果指标体系没有统一的方法论,进行统一建设,那么就很难说是数据中台。指标管理系统一般要实现一套一致的方法论(如原子 / 派生 / 复合指标、维度、修饰词等),做好指标的业务和技术口径管理,还需要支持指标的审批管理。数据中台的指标无法交给各前台业务自助式的建设。

    数据服务系统:类似于在线业务中台需要通过API网关提供标准化的服务,数据中台也需要一个标准化的服务方式,通常称为数据服务系统,也可以说是数据网关或数据门户。类似于别的网关类产品,数据服务系统需要提供鉴权、日志审计、流控、协议转换(如SQL Dialect之间的转换)等功能,也应该发展多引擎融合查询、逻辑模型等扩展功能以提高服务接口的稳定性和实现的灵活性。

    元数据管理系统:元数据管理是整个数据中台的基础和中心,所有的其他系统都依赖元数据管理。元数据管理首先要做好的当然是数据模式或目录(catalog)的管理,至少要知道中台里都有什么数据。对复杂的数据中台来说,数据血缘也很重要。没有血缘信息,不知道数据间的依赖关系,数据质量肯定管不好,因为不知道一个数据的质量问题怎么来,又进而会影响什么。

    同样的,如果没有血缘,数据资产也肯定管不好,因为不知道什么数据有价值什么没价值,这就像如果你不知道一个函数被谁调用,你就不知道它是不是死代码一样。元数据管理系统往往也需要提供一个基础的访问界面,通常称之为数据地图。

    数据仓库开发与管理系统:除了指标管理,数据仓库的开发是将一大堆初始数据建设梳理成一个漂亮的数据中台的核心过程。一般来讲数据中台更适合用Kimball的维度建模方法而非数据仓库之父Bill Inmon所提倡的方法,这是因为Inmon强调顶层设计,而Kimball强调至下而上。

    如果要建设数据中台,肯定是因为前台业务复杂多变,这时强调顶层设计会导致中台建设缓慢、僵化。因为中台虽然应该是由组织高层决策,但目的却是为了支持前台业务,而不是为了控制。*支持而不是控制*,这一点绝不能本末倒置。

    数据质量管理系统:所有复杂的系统都需要专业的质量管理,在线业务系统有一系列的弹力设计和APM等监控运维工具,数据中台也需要专业的质量管理。数据质量管理系统通常设计为支持丰富的稽核 / 校验 / 比对规则,监控数据是否准确、实时、一致,还要做到及时的报警,分析影响面,提供快速修复的手段等。

    但这些手段只能发现和补救问题,不能预防问题,要预防问题,还要通过测试工具减少代码bug、通过资源弹性应对性能波动、通过优先级调度优先满足重要业务需求等。

    相对来说,当前数据中台领域的质量管理没有在线业务领域的成熟,如在线业务领域的测试手段远比数据领域的精细,在线业务领域很常见的熔断、限流、服务降级等模式在数据领域都没有成熟的实践方法(优先级调度可以说是实现了部分的服务降级功能),随着数据中台越来越广泛和重要,这些技术应该也需要持续发展,但技术上的挑战不小。

    数据安全管理系统:数据中台因为汇集了组织所有有价值的数据资产,因此良好的安全管理是必须的。细粒度的权限和审计是基础,一般的还需要隐私 / 敏感数据的脱敏处理、数据加密(特别是将数据托管在第三方平台之上时)、数据泄漏防护(比方说一种常见的方法是限制将数据下载到本地的数据量)等技术。发展到高级阶段甚至可能还需要联邦学习、数据沙盒等技术。

    数据资产管理系统:在数据质量和安全单列的情况下,数据资产管理主要负责的是数据的生命周期管理、成本的统计分析与优化等工作。

    同时,数据中台还需要强大的大数据计算引擎、数据集成 / 同步 / 交换引擎,还往往需要一套敏捷BI系统:

    大数据计算引擎:数据中台要管理的数据规模和复杂度往往都很高(否则搞中台属于为赋新词强说愁),所以传统的数据库和数据仓库基本上支撑不了。当前的技术环境下,基于Hadoop MapReduce或Spark几乎是唯二的选择,当然这也包括了这两者之上的Hive和Spark SQL。能有SQL就用SQL,易于维护,也易于数据血缘的收集。除此之外,流处理可能还需要Flink,交互式查询可能要引入Impala或GreenPlum。

    数据集成 / 同步 / 交换引擎:一方面数据中台需要强大的数据集成和同步能力才能吸纳各方数据。集成和同步的概念相近,同步更强调实时性。另一方面,数据中台往往由多种数据计算引擎构成,就需要同步或交换引擎实现不同引擎见的数据交换。

    敏捷BI系统:建设数据中台通常最重要的目的是为了支持业务运营和决策,为此需要基于数据中台进一步开发数据产品。敏捷BI系统是开发数据产品快速、轻型的手段,能够尽快尽早的发挥数据中台的价值。

    此外,对于互联网业务,统一的埋点引擎往往也是数据中台所需要的。如果埋点的逻辑都不统一的话,建数据中台的时候会发现数据的源头就是乱的,后续也都没法做。其他行业业务,数据采集也属于基础工作,也是要先做好的。

    数据中台技术选型参考:

    在搭建数据中台方面,基于开源技术的选型,尤其是Hadoop生态圈有非常多的选择,从数据整体流向来看各大层级的选型。

    数据抽取层:sqoop和flume是两大主流工具,其中sqoop作为结构化数据(关系型数据库)离线抽取,flume作为非结构化日志接入;

    数据存储层:Hadoop文件系统Hdfs大家都比较了解,而kafka作为流式数据总线应用也非常广泛;

    计算与调度层,包括:

    离线计算:离线计算主要是hive,spark,也有部分选用tez

    实时计算:前些年storm,spark比较流行,最近几年大家纷纷往Flink转型

    数据调度:除了像Airflow Azkaban Oozie等,易观开源的Dolphin-scheduler也非常活跃

    数据引擎层:也就是我们常说的OLAP层,我们看到这一层里的选择非常多,就不一一列举了,(业务需求带动技术进步的典型,选择丰富主要是可以适配不同的数据应用场景)。从概念上讲分为ROLAP、MOLAP以及两者混搭。MOLAP提前做一些预计算,以生成Cube的方式,达到空间换取查询效率;而ROLAP是即查即用,效率完全取决于查询引擎的性能,我个人认为从将来看,ROLAP的趋势会更加明显,因为没有中间的数据链路。但目前看来,没有一个统一的引擎足以支撑各类数据场景(这或许是将来的机会~);

    数据可视化层:比较主流的有Metabase、Superset、Redash,也可以选择阿里、百度的一些开源控件。

    在开源技术的选择里,我们看到各层里都有越来越多国内开源的工具(也充分体现了我们在大数据技术领域的进步)。除了以上列举的这些,整个Hadoop生态圈的技术选择非常多,可以结合自己的实际场景选择自己的架构,在选型层面可以参照的一些原则,比如:

    是否有鲜活的成功案例,优先找自己类似业务场景;

    接口的开放性,与其他组件的兼容性;

    社区活跃性度&发展趋势。

    互联互通社区


    互联互通社区专注于IT互联网交流与学习,关注公众号:互联互通社区,每日获取最新报告并附带专题内容辅助学习。方案打造与宣讲、架构设计与执行、技术攻坚与培训、数据中台等技术咨询与服务合作请+微信:hulianhutongshequ

    展开全文
  • 0、前言 当前,大部分企业不再建设从源数据采集到分析应用的烟囱式系统,更...阿里的中台是从管理的角度出发,以中台事业部集中数据搜索,技术及产品,数据共享等多个部门的功能。其他组织或企业建设数据中台不一定需

    0、前言

    当前,大部分企业不再建设从源数据采集到分析应用的烟囱式系统,更倾向于数据集中采集、存储,并应用分层建设。这种方式一方面有利于应用系统的快速部署,另一方面也保证了数据的集中管理与运营,体现数据的资产、资源属性。

    数据中台的出现弥补了数据开发和应用开发之间由于开发速度不匹配而出现的响应力不足等缺陷问题。

    数据中台是国内学者提出的概念,起始于阿里的“大中台、小前台”概念。阿里的中台是从管理的角度出发,以中台事业部集中数据搜索,技术及产品,数据共享等多个部门的功能。其他组织或企业建设数据中台不一定需要成立中台事业部,但是数据集中治理与提升数据价值转换效率的思路是一致的。

    一、通用体系架构

    不同的企业对数据有不同的需求。企业数据应用不断更新迭代,企业的中台系统也需要不断变化。

     从数据处理与数据治理两个维度出发,可以设计一个解耦的数据中台体系架构。该数据中台体系架构具有一定的柔性,可按照企业应用需求进行组合,或者对单个模块进行扩充,能满足大多数企业数据中台建设的需求。

     数据中台体系架构示例

    数据中台的通用体系架构如上图所示,该中台体系架构以减少功能冗余和提高功能复用为原则,把数据中台解耦为 6 个可以分别独立建设、演进的功能子系统。

    数据结构与数据处理子系统是数据中台体系架构的核心,数据治理是提升数据价值的重要手段。该数据中台体系架构的通用性表现在以下几点:

    • 综合考虑了数据中台的各种要素,参考这个架构进行建设可以有效提升数据资产价值,提供数据及服务的共享。

    • 参考这个数据中台体系架构,企业可以一次规划、分步实施。首先建设处理子系统及数据存储子系统,然后根据业务发展需求,逐步补充数据采集、数据安全及数据治理子系统。

    • 该数据中台由 6 个解耦的子系统组成。企业在立项建设时可以灵活组合,每个子系统单独招标建设,也可以把多个子系统合并招标建设。数据中台通用体系架构包含数据存储框架、数据采集框架、数据处理框架、数据治理框架、数据安全框架及数据运营框架等 6 大部分。

    1.1 数据存储框架

    数据中台的核心是数据,数据通过采集系统获取,然后数据经过处理框架加工,并接受数据治理框架的管理,同时也要接受数据安全管理框架的管理,最后开放的价值数据将通过数据运营框架对外提供数据服务。

    数据中台的数据架构应该独立规划,并采用合理的技术架构对不同类型的数据进行存储。

    数据存储框架中,无论数据采用对象存储、块存储还是数据库存储技术,各种中台数据可按照上图所示分类管理。

    • 源数据:主要由采集框架进行管理,数据治理框架按照数据特征把数据简单分为结构化和非结构化数据两大类,而规范化分域数据则是数据治理框架对全量数据的规范化分域整理。宽表数据是数据关联的结果,利用宽表数据可以对人、事、地、物、组等对象进行完整的数据画像,同时宽表数据也可以作为上层模型数据的中间层数据。
    • 元数据和标签数据:都是对数据的描述,其中元数据用来对数据的客观属性进行表示,标签数据更倾向于管理者对数据的主观表述及等级划分,比如质量等级标签、安全标签、属性标签等。
    • 主数据:需要在各系统间频繁更新、交换,且需要独立的存储空间进行维护管理。

    1.2 数据采集框架

    数据中台的采集框架应对纳入数据中台的各种源数据进行统一采集管理。数据采集框架中应提供多种数据采集方式,如文件传输协议采集、数据库采集、接口应用程序接入采集、流式采集及网络爬虫采集。

    同时采集框架应按照数据采集规范对源数据进行预处理,从而去除明显不需要的数据及多余数据,并对采集过程进行管理。虽然数据中台的体系架构没有统一模板,但各企业数据采集框架基本一致。

    1.3 数据处理框架

    数据处理是每个数据应用的基本环节之一,经典的数据抽取、转换和加载(ETL)处理流程在数据采集预处理、数据整合、数据建模等多个地方均要使用。单独建设数据处理框架有利于数据处理工具组件的集中开发与管理,也有利于数据中台数据处理任务的协调与调度。

    数据处理框架专门负责数据处理相关的任务,包括批处理、流处理、人工智能分析、数据清洗、数据交换及查询,此外数据处理的相关工具组件可在处理框架中配置。任务调度模块在数据处理框架中处于居中指挥的作用,并对运行的数据处理任务进行监控及异常处理等操作。

    1.4 数据治理框架

    广义的数据治理不仅包含提升数据价值的内容,如数据管理、数据目录、数据质量等,也包含数据安全管理及数据共享服务。

    数据安全管理与数据价值提升是一个矛盾体,如果由一个厂商或开发团队进行数据安全管理及数据价值提升相关软件的开发,则开发者的操作难免有所偏向,而且矛盾不容易公开,少了冲突也就少了优质的解决方案。

    另外,数据共享与数据治理的其他内容也存在相同的问题。因此,建议数据中台的数据治理框架中不包含数据安全与共享的相关内容。

    数据治理框架包含数据目录、数据管理、模型管理和数据质量 4 个模块:

    • 数据地图、数据资产目录、知识图谱及数据血缘的主要作用是展示数据的属性及相互关系,因此都纳入数据目录模块。

    • 数据模型能提高数据中台对外部应用需求的反应能力,固化的中间模型数据需要专门管理。模型管理包括模型目录、模型血缘及模型地图等。

    • 数据管理又可以细分为元数据管理、主数据管理、标签数据管理及源数据管理。

    • 数据质量管理模块按照制定的数据标准及数据稽核规则对数据中台中的数据进行质量管理。

    1.5 数据安全框架

    数据已经成为数据资产,数据安全框架是数据中台必不可少的组成部分。数据安全叠加在数据中台其他功能框架之上,数据采集、处理、交换、共享等每个环节均必须实施安全控制策略。安全框架可以分为日志管理、用户认证、权限管理及加解密等几个功能模块。

    此外,安全全门户也可以对外提供安全能力封装,展示数据中台的安全态势及安全视图。

    1.6 数据运营框架

    数据中台的核心功能是综合众多数据应用的数据处理及数据治理功能,集中建设、集中管理、减少冗余、增加复用。数据中台的最终目的还是为其他应用或开发者提供数据服务,而对外数据服务功能将直接面向不确定的外部对象。

    因此单独建设数据运营,一方面有利于针对外部用户提供针对性功能;另一方面,数据运营模块作为用户与数据中台核心数据服务之间的中间层,可以有效隔离外部用户直接控制、接触核心数据及应用,可保护数据中台的安全性及内部功能的稳定性。

    综合以上因素,数据运营应配置运营门户、能力开放、数据开放及运营监控等功能:

    • 运营门户:对数据中台管理者提供管理门户,对开发者提供开发者门户。对内部应用提供内部应用门户,对外部应用提供外部应用门户。运营门户针对不同的用户提供不同的通道并开放不同的数据中台能力。

    • 能力开放:把数据中台的数据处理能力、数据分析能力等经过适当的封装后对用户提供服务,可以是微服务,也可以是 API 接口,或者直接提供二次开发能力。

    • 数据开放:通过数据目录,数据/模型展示(可视化、数据视图等)为其他数据应用系统提供数据服务。

    • 运营监控:对数据中台的总体运营情况进行监控管理,包括硬件环境、软件环境,并且确定监控指标,按需求提供运营日报,处理告警信息。

    二、典型架构

    数据中台的目标是让数据持续用起来,通过数据中台提供的工具、方法和运行机制,把数据变为一种服务能力,让数据更方便地被业务所使用。下图所示为数据中台总体架构图,数据中台是在底层存储计算平台与上层的数据应用之间的一整套体系。

     数据中台屏蔽掉底层存储平台的计算技术复杂性,降低对技术人才的需求,让数据的使用成本更低。通过数据中台的数据汇聚、数据开发模块建立企业数据资产。通过资产管理与治理、数据服务把数据资产变为数据服务能力,服务于企业业务。数据安全体系、数据运营体系保障数据中台可以长期健康、持续运转。

    2.1 数据汇聚

    数据汇聚是数据中台数据接入的入口。数据中台本身几乎不产生数据,所有数据来自于业务系统、日志、文件、网络等,这些数据分散在不同的网络环境和存储平台中,难以利用,很难产生业务价值。

    数据汇聚是数据中台必须提供的核心工具,把各种异构网络、异构数据源的数据能够方便地采集到数据中台进行集中存储,为后续的加工建模做准备。

    数据汇聚方式一般有数据库同步、埋点、网络爬虫、消息队列等;从汇聚的时效性来分,有离线批量汇聚和实时采集。

    2.2 数据开发

    通过数据汇聚模块汇聚到中台的数据,没有经过什么处理,基本是按照数据的原始状态堆砌在一起的,这样业务还是很难使用。数据开发是一整套数据加工以及加工过程管控的工具,有经验的数据开发、算法建模人员利用数据加工模块提供的功能,可以快速把数据加工成对业务有价值的形式,提供给业务使用。

    数据开发模块主要是面向开发、分析人员,提供离线、实时、算法开发工具以及任务的管理、代码发布、运维、监控、告警等一些列集成工具,方便使用,提升效率。

    2.3 数据资产体系

    有了数据汇聚、数据开发模块,中台已经具备传统数仓平台的基本能力,可以做数据的汇聚以及各种数据开发,就可以建立企业的数据资产体系。之前说数据资产体系是中台的血肉,开发、管理、使用的都是数据。大数据时代,数据量大,增长快,业务对数据的依赖也会越来越高,必须考虑数据的一致性和可复用性,垂直烟囱式的数据和数据服务的建设方式注定不能长久存在。

    不同的企业因业务不同导致数据不同,数据建设的内容也是不同的,但是建设方法可以相似,数据要统一建设,笔者建议数据按照贴源数据、统一数仓、标签数据、应用数据的标准统一建设。

    2.4 数据资产管理

    通过数据资产体系建立起来的数据资产还是一套偏技术的数据体系,业务人员比较难理解。资产管理是以企业全员更好理解的方式,把企业的数据资产展现给企业全员(当然要考虑权限和安全管控),数据资产管理包括对数据资产目录、元数据、数据质量、数据血缘、数据生命周期等进行管理和展示,以一种更直观的方式展现企业的数据资产,提升企业的数据意识。

    2.5 数据服务体系 

    前面利用数据汇聚、数据开发建设企业数据资产,利用数据管理展现企业的数据资产,但是并没有发挥数据的价值。数据服务体系就是把数据变为一种服务能力,通过数据服务让数据参与到业务,激活整个数据中台,数据服务体系是数据中台存在的价值所在。

    企业的数据服务是千变万化的,中台产品可以带有一些标准服务,但是很难满足企业的服务诉求,大部分服务还是需要通过中台的能力快速定制。数据中台的服务模块并没有自带很多服务,而是提供快速的服务生成能力以及服务的管控、鉴权、计量等功能。

    2.6 运营体系和安全体系

    通过前面的数据汇聚、数据开发、数据资产、资产管理、数据服务,已经完成了整个数据中台的搭建和建设,也已经在业务中发挥一定的价值。

    运营体系和安全体系是数据中台得以健康、持续运转的基础,如果没有它们,数据中台很可能像个一般项目一样,一期搭建起平台、建设部分数据、尝试一两个应用场景之后而止步,无法正常地持续运营,不能持续发挥数据应用价值,这也就完全达不到建设数据中台的目标。

    三、不同行业数据中台解决方案

     

     

     

     

     

     四、总结

    建设数据中台,实现企业或机构数据资产的高效管理和数据价值最大化,为机构带来了数据平台化的运营机制,有望解决应用开发与数据开发速度不匹配的问题。利用数据中台,可以将机构的核心技术或团队凝聚在一起,建设机构内强大的数据开发、运营等团队,提升机构的团队的硬实力和软实力。

    虽然一个良好的架构对一个信息系统的后期扩容及运维有重要作用,但总体架构设计只是数据中台建设的第一步,每一个功能模块还有很大的细化空间,如不同类型数据的存储技术选型、数据安全合规审计技术、数据模型设计等。在具体项目中,数据共享与安全保护的平衡点、新技术的引用等,都需要进一步细化研究。

    展开全文
  • 数据中台必备的“五大”核心能力

    千次阅读 2021-11-15 15:37:11
    结合以往我们再数据治理积累的经验,我们认为数据数据中台必须具备“盘”、“规”、“整”、“用”以及价值变现的五大核心能力。 1.盘 随着金融机构业务多元化发展,机构内部存在大量系统、应用以及功能的...

        结合以往我们再数据治理中积累的经验,我们认为数据数据中台必须具备“盘”、“规”、“整”、“用”以及价值变现的五大核心能力。

     

    1.盘

        随着金融机构业务多元化发展,机构内部存在大量系统、应用以及功能的重复性、烟囱式建设,导致巨大的数据资源、计算资源、人力资源的浪费。同时组织壁垒也导致数据孤岛的出现,使得内、外部数据难以全局规划。而数据作为资产,为了合理利用资产,就需要进行数据盘点,体现内部数据分布现状与外部数据收集情况,规划数据资产的构成,打通异构数据,统一外部数据采集,理清家底。

    2.规

        金融机构数据资产体系建设必须围绕业务价值,从推动业务数据向数据资产转化的角度来建设。

        传统的数字化建设往往局限在单个业务单元,忽视了数据多业务关联的属性,缺乏对数据的深度理解。数据中台必须连通全域数据,通过统一的数据标准,构建规范的、紧密结合业务的、可扩展的数据标签体系。

    3.整

        “整”指的是发现数据资产存在的问题,提升机制,保障数据资产的质量。数据中台必须提供数据资产的管理能力,以及面向价值变现的数据资产管理体系,以实现数据资产价值最大化。

    4.用

        为了尽快地让数据资产用起来,数据中台必须提供快速、便捷的数据服务能力,让相关人员,包括但不限于技术人员能快速地开发出数据应用,支持数据资产场景化能力的快速输出,以满足业务多元化的时长诉求。

        数据中台必须提供可视化的数据分析,数据洞察源于数据分析,数据资产只有服务于业务分析,才能紧密贴合业务场景,以达到价值最大化的目的。

    5.价值变现

        大部分金融机构数据资产目前仅仅为内部业务使用,我们成为隐性价值变现,很少能直接提供数据交易产生显性价值变现。

        在数据中台的建设中,我们更希望通过数据中台提升跨部门的普适性价值能力,在降本增效的前提下,更好地管理数据应用。通过数据洞察,驱动业务创新通道;跨业务场景数据应用,赋能金融机构融合创新。

    展开全文
  • 业务中台、数据中台、技术中台到底是什么?

    千次阅读 多人点赞 2021-03-16 13:48:38
    00 中台能力总体框架01 业务台02 数据台数据应用技术发展迅猛数据架构更加灵活数据来源更加多元化,数据格式更加多样化数据智能化应用将会越来越广泛03 技术台1. API网关2. 开发框架3. 微服务治理4. 分布式...
  • 导读:2015年阿里巴巴提出“大中,小前台”的中台战略,通过实施中台战略找到能够快速应对外界变化,整合阿里各种基础能力,高效支撑业务创新的机制。阿里巴巴中台战略最早从业务台和数据中台...
  • 文章摘自与数据同行 作者:郭东白 ...(2)反人性:中台团队会通过强制收编前端能力来扩大自己的能力(3)过度设计:中台经常以最全的最复杂的实现来应对任何一个简单的应用场景。大量成熟行业...
  • 简介:业务中台产品BizWorks重磅发布,这可以看作是阿里云在 “做厚中台” 战略上继 “云钉一体”之后的又一个新动作! 10 月 19 日,2021 云栖大会正式开幕,连续举办多年的云栖大会俨然已经成为了国内科技产业...
  • 前台、中台、后台到底是什么?

    千次阅读 2021-03-16 09:06:22
    前台、中台、后台到底是什么?01 前台02 中台1. 业务中台2. 数据中台03 后台 作者:欧创新 邓頔 来源:大数据DT 导读:很多人提到中台时自然会问:“既然有中台,那是否有前台和后台?它们各自的职责又是什么呢? ...
  • 数据中台入门到精通系列讲解 https://blog.csdn.net/wenyusuran/category_9162242.html 按照数据处理的链路,从数据采集、到数据存储、数据打通、到数据应用我们是怎么做的。首先来看一下什么是中台: 1.什么...
  • 数据中台之数据服务

    2021-04-13 17:34:43
    一. 简介 DataWorks数据服务旨在为企业搭建统一的数据服务总线,帮助企业统一管理对内对外的API服务。...数据中台 数据服务 架构 1. 生成API 数据服务支持通过可视化配置的向导模式,快速将关系型数据库和NoSQL
  • 业务中台数据一致性方案

    千次阅读 多人点赞 2021-10-10 16:40:21
    如下图所示,业务台就是将平台的通用能力进行下沉,避免重复建设,形成底座平台能力,上层的各个应用服务都是基于中台能力进行快速构建。但是随着应用规模的扩大,原本在单体应用不是问题的问题,在微服务架构...
  • 来源dbaplus,作者马金韬本文主要内容包含以下几部分:数据中台的产生:数据工作的痛点、数据中台的产生、中台的实质爱奇艺数据中台的定义:理解数据中台、数据中台的发展历程、输出和定位爱奇艺...
  • 数据中台的终极使命是赋予数据资产价值变现的能力,无论是通过业务赋能的形式隐性变现,还是通过数据服务公开交易的直接变现。它们都需要一个很重要的基础条件“数据资产化”。 数据中台做为金融机构各业务系统的...
  • 阿里拆中台

    2020-12-30 12:08:00
    1、阿里拆中台 当初张勇提出中台战略是想打造:统一技术架构、产品支撑体系、数据共享平台、安全体系等等。把整个组织“横”过来,支撑上面多种多样的业务形态。不可否认阿里的中台,在近5年的发展过程,有力地...
  • 浅谈中台方法论

    2021-01-06 16:37:17
    架构师必须具备结构化思维,...中台是企业级共享服务平台,中台也是能力的枢纽和对能力的共享;中台不是微服务,因为中台不仅是一种技术架构,还是企业进行数字化转型的整体参考架构;以服务的方式提供共享能力的平.
  • 怎样建设AI中台

    千次阅读 2021-11-03 11:41:08
    AI中台就是AI产品的研发平台吗? 建设AI中台就是建设一个AI的研发平台吗? 什么样的企业需要建设AI中台? AI中台该如何建设? 要知道怎样建设AI中台,首先要弄清楚什么是AI中台,AI中台解决的问题是什么。要明确AI...
  • 原文:腾讯汤道生:腾讯开放中台能力 助力产业升级 3. 台从哪来的 你玩过《海盗奇兵》吗?那《部落冲突》、《皇室战争》呢?咋滴,玩游戏还和台有关系? supercell(超级细胞),芬兰移动游戏巨头。拥有《部落...
  • 详解阿里的中台战略

    千次阅读 2020-12-19 17:20:00
    去年的时候,我所在的公司就提出要打造自己的中台战略,于是就去学习了相关内容,其中一本《企业IT架构转型之道:阿里巴巴中台战略思想与架构实战》内容不错,现在把其中一些读书笔记分享给大家,希...
  • 数据中台 -- 学习笔记(一)

    千次阅读 2021-04-22 17:23:39
    能力”指定了中台的主要承载对象,能力的抽象解释了各种各样的中台的存在;“复用”定义了中台的核心价值,过去的平台化对于易复用性并没有给予足够的关注。 中台的兴起,使得人们的目光更多的从平台内部,转到...
  • 业务中台的困境、及可能的解

    千次阅读 2021-06-29 16:10:50
    有一个事情已经困扰我很久了——大中、小前台作为战略已经提出很久了,在业界也掀起了不小的波澜,可是反观阿里的业务中台,为什么总觉得旁边有朵小乌云,感觉哪里不对劲。 业务中台小乌云 建一所房子,你要挖坑打...
  • 写在前面答案是由问题驱动产生的,我们既然想落地一个框架、系统,必然需要回答很多问题,这样既可以保证最终方案对现在问题是有收益的,也可以保证落地路径的一致性,防止跑偏。通过一步步回答中台领域...
  • 我认为:中台其实就是提供各种能力到上层 2.中台业务测试流程 需求阶段: 做正确的事比正确地做事更重要,问题发现越晚,修复的成本就越高,在需求阶段测试左移,开发测试产品一起参与需求评审,测试参与技术...
  • AI 中台的定位AI 中台是实现 AI 技术在千行百业快速研发、共享复用和高效部署管理的智能化基础底座,是智能化能力普惠的关键基础设施可以认为,AI 中台是企业中台的重要组成部分,以加快...
  • 如下表: 我按照各每个系统大概列了一些数据中台比较核心需要的能力,当大家在采用某一种系统的时候,某一种方案的时候,可以对照一下。也不是每一个你们都会关注,但是这是从我们经验经常用得到的。比如作为数据...
  • 本文围绕当前媒体机构的转型需求,百分点科技大数据技术团队系统地介绍了百分点科技媒体数据中台建设方法论及实践成果。 一、媒体数据中台建设背景 以报纸、出版、广播电视等为代表的传统媒体,和以网站、新闻...
  • 什么是技术中台

    2021-06-08 14:01:04
    技术中台说白了就是强调资源整合、能力沉淀的平台体系,当技术前台实现业务功能时,为他们提供底层的技术、数据等资源和能力的支持。 ▌技术中台赋能企业敏捷业务 主要是提高并发的需求。但是高并发不是没有成本的...
  • 业务中台

    2021-01-14 15:02:08
    定义中台我认为可以有两个角度, 一个是从中本身的价值和出发点来:中台是在多个部门之间共享的开发资源所提供的业务能力、数据能力和计算能力的集合;另一个定义从中的相对定位来:前台是面向终端用户的一组...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 664,705
精华内容 265,882
关键字:

中台能力

友情链接: MFRC500demo.rar