企业是否需要建立中台,有什么标准可以自我判断?

用什么标准判断一个企业是否需要构建中台?不要为了建设而去建设

参与12

5同行回答

zftangzftang  其它 , 小白一枚
数据中台解决的问题可以总结为如下三点:效率问题:为什么应用开发增加一个报表,就要十几天时间?为什么不能实时获得用户推荐清单?当业务人员对数据产生一点疑问的时候,需要花费很长的时间,结果发现是数据源的数据变了,最终影响上线时间。协作问题:当业务应用开发的时候,虽然和别的项...显示全部

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

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

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

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

收起
互联网服务 · 2020-05-21
浏览2044
匿名用户匿名用户  其它 , 某银行
我认为,是否建立中台,需求是其次,最重要的是数据治理工作是否已完成。如果数据治理已经较为成熟的实施了,那么,数据中台只是一个自然而然的事情,因为你有了标准化的数据,自然会去想到如何应用。而如果数据治理工作不到位,那么即使你有中台的需求,中台已经建立了,也会慢慢的“荒废”...显示全部

我认为,是否建立中台,需求是其次,最重要的是数据治理工作是否已完成。
如果数据治理已经较为成熟的实施了,那么,数据中台只是一个自然而然的事情,因为你有了标准化的数据,自然会去想到如何应用。而如果数据治理工作不到位,那么即使你有中台的需求,中台已经建立了,也会慢慢的“荒废”掉。

收起
银行 · 2020-06-12
浏览1589
sxtycxxsxtycxx  解决方案经理 , 人工智能(计算机视觉)
首先要明确的数据中台不是一个信息化产品,不是一套技术,而是一套对于数据的一套管理机制或是方法等要不要建数据中台没有标准,企业应该就实际需求要定夺,同时还要看看企业现有的信息化基础,例如现在企业面临的问题、数据的积累程度、领导是否重视、信息化在企业中的定位...显示全部

首先要明确的数据中台不是一个信息化产品,不是一套技术,而是一套对于数据的一套管理机制或是方法等
要不要建数据中台没有标准,企业应该就实际需求要定夺,同时还要看看企业现有的信息化基础,例如现在企业面临的问题、数据的积累程度、领导是否重视、信息化在企业中的定位

收起
互联网服务 · 2020-06-10
浏览1527
木讷大叔爱运维木讷大叔爱运维  运维老兵 , 互联网+金融
数据中台建设必要性的论证是每家机构必做的功课,目前没有一个成熟且可量化的论证方案。这次讨论交流中也有很多朋友在咨询,这里我结合金融数据中台的建设实践,分享一个论证方案的思路,供各位参考。整体思路:Step1 :数据中台的“能力“有哪些 -> Step2 :企业当前数据体系的“...显示全部

数据中台建设必要性的论证是每家机构必做的功课,目前没有一个成熟且可量化的论证方案。这次讨论交流中也有很多朋友在咨询,这里我结合金融数据中台的建设实践,分享一个论证方案的思路,供各位参考。

整体思路

Step1 :数据中台的“能力“有哪些 -> Step2 :企业当前数据体系的“痛点“有哪些 -> Step3 :企业建设数据中台的技术储备是否满足 -> Step4 :数据中台”完整版“与”轻量版“的选择

下面我简明扼要提一下每个论证环节的要点:

**论证环节 1 :数据中台的“能力“有哪些
**
数据中台本质是通过数据技术统一标准和口径,对 “ 全域 ” 数据进行采集、加工、存储,治理形成一个口径统一的数据服务中间层,进而高效为业务层和决策层提供数据支撑。抽象几个关键词方便理解中台的“能力“:( 1 )数据质量治理的抓手(抓口径)、( 2 )数据出口治理的抓手(抓出口)、( 3 )数据服务的仓库(抓内容)、( 4 )高效迭代、高效运营(敏捷交付)。

**论证环节 2 :企业当前数据体系的“痛点“有哪些
**
数据中台理念对大企业更具吸引力,可以对症很多企业成长到一定规模后的“数据病”。数据中台是否能够对症下药,需要我们架构师能够清晰分别和总结出各自企业的“数据病”症结。

这里以金融机构的数据体系发展到数据仓库阶段时,举例分析所面临的“数据病”,以及论证环节 1 中总结的数据中台“能力”能否对症这些“痛点”:

金融机构在目前的市场化阶段,各业务条线在一线经营上,为寻求新的增长点,提出了诸多个性化数据分析和服务的述求,在没有数据中台时,要满足诸多业务条线的数据需求,数据分析师需要在后台数据仓库上完成 T+1 的数据加工,然后将数据文件推送给各个业务前台系统,每个前台系统都维持一个小规模的数据团队,专门负责将数据文件转化为自己领域内的数据服务,实现业务述求。这种模式下痛点以及对数据中台架构选型的要求主要体现在以下几点:

( 1 )痛点 1 :存储浪费大。数据以文件方式分发到各前台系统,均需要占用业务库宝贵的存储资源,尤其是通用场景数据(例如用户画像标签等),重复的资源浪费尤为突出,亟需集中化的存储和服务替代分散模式,体现在架构选型上,即需要 “ 云化的异构存储能力 ” 支撑;

( 2 )痛点 2 :传递效率低。文件式数据传递链路以 T+1 批量为主,数据需要 “ 一股脑 ” 全部加载进本地数据库后方可使用,数据获取的效率远低于通过服务 “ 按需 ” 调用获取指定内容(例如指定客户信息、指定机构指标)。数据中台为了支持前端各具业务特色的数据应用场景,需要借助 “ 微服务 ” 解耦和组装;

( 3 )痛点 3 :人力投入大。众多前台系统的数据转化工作收归沉淀在中台后,为了继续保持对业务场景迭代诉求的快速响应,就需要通过技术手段降本增效,提升中台持续交付能力。体现在技术诉求上,就是需要 “ 云化的部署运营能力 ” 支撑;

**论证环节 3 :企业建设数据中台的技术储备是否满足
**
接下来要看,各位架构师所在的机构是否具备论证环节 2 中提到的数据中台“技术门槛”,例如包括“微服务”、“云化的异构存储能力”、“云化的部署运营能力”,概括出来就是目前另一个流行的理念“云原生”,数据中台的架构诉求与云原生有着“天然”的技术契合,这个在我另一篇发表过的文章中有详细阐述。这里将技术储备的要点,列出如下:

**论证环节 4 :数据中台”完整版“与”轻量版“的选择
**
分析清楚了 1-3 环节,那么我们基本具备了构建数据中台“完整版”的素材,这个“完整版”是一个包含一些列工具平台和管理规范的大工程,笔者所在机构构建的数据中台涵盖 Store 存储体系、 Service 服务体系、 Open 路由体系、 Plus 管理体系 4 大体系十余个子系统。

但实际实践上,数据中台建设其实是有轻、重之分的,这时候就是考验我们架构师功底的时候,如何从庞大的体系中,抽取各家机构最关注的“轻量版”进行建设。举个例子,如果关注中台能力 1 “数据质量治理的抓手(抓口径)”,那么数据服务目录、数据指标管理两项功能模块就是必备功能;如果关注中台能力 4 “高效迭代、高效运营(敏捷交付) ” ,那么一套支持容器化运营的 devops 工作台、一组云原生底座则不可或缺。

限于篇幅,不能完整展开每一项论证环节,各位架构师可以选取关注点,深入交流。

收起
金融其它 · 2020-06-04
浏览1989
StevenSteven  IT顾问 , steven
中台的本质是复用,复用的目的是提高效率,减少投入,减少重复建设、提高可用性、降低耦合性、提升安全性等。需不需要中台,看企业自身的现状和发展规划显示全部

中台的本质是复用,复用的目的是提高效率,减少投入,减少重复建设、提高可用性、降低耦合性、提升安全性等。需不需要中台,看企业自身的现状和发展规划

收起
证券 · 2020-05-24
浏览1984

提问者

wanggeng
系统运维工程师某银行
擅长领域: 服务器存储数据库

问题来自

相关问题

相关资料

相关文章

问题状态

  • 发布时间:2020-05-21
  • 关注会员:6 人
  • 问题浏览:4025
  • 最近回答:2020-06-12
  • X社区推广