日本一意孤行?国际原子能机构认为福岛处理水排海计划符合国际安全标准

大清都亡了多少年了,跳个僵尸舞怎么了?

普里戈津之死!我的三点评论!

从福岛核废水说起:我们是在谈科学还是讲立场

我现在承认:以前对川普的看法是错误的!

生成图片,分享到微信朋友圈

自由微信安卓APP发布,立即下载! | 提交文章网址
查看原文

不是任何一个数据平台都可以称为数据中台的!(上)

The following article is from ICT销售与大客户联盟 Author Robert Xu

困惑
前些日子,一位在某知名企业数据中心任职的资深人士,提交了一份辞职信,摘录部分内容如下:
“......我还是决定离开了......,
我希望的工作状态是,能在工作中获得成就感。这种成就感并非是您理解的仅限于收入的增长,我以为我最大的成就感就在于能发挥自己的专长并因此创造价值,同时能用自己的工作成果影响决策者,帮助决策者作出更好更及时的决策。
目前,绝大部分企业,还是以业务部门为主导的,因为他们是企业发展的一个很重要的驱动,他们有大量的时间和机会,与市场客户和企业的决策层接触,但是他们的困惑是无法获得准确的数据或者是需要的数据。而我的困惑是尽管十分努力也十分艰辛的去完善我们的数据服务能力,但仍然是与一线如隔河相望般的不知道如何满足他们的需求。另一方面,尽管您一直强调企业的数据管理与IT管理,但是这些似乎与企业的战略、业务等脱节的十分的厉害,我们企业的利润获取决策与数据管理几乎没有半毛钱的关系,或者是我理解错了,也许反正有那么一些关系吧。
从大数据平台建设,到数据管理(包括元数据管理)、数据治理等一路走来,得到的感觉就是,反正你们IT部门要干,其他的企业也在干,那么你们就干吧。我们得不到来自其他业务部门和研发部门等的支撑和背书,也从没想过这些东西与企业的利润有半毛钱的关系。
工作就在从建设数据、到数据混乱,再到维护数据、再回到建设数据的的怪圈中循环。
......”
这是数据技术从业者的困惑,其实也是企业的困惑。
随着企业的发展,必然会产生更多的各类业务数据,同时,这些数据的积累也为企业实现业务数据化和数据业务化带来了更多的可能性。
但是,现实情况却是:企业的数据烟囱却越来越多,不单单一个个的业务系统和应用系统仍然是一个个烟囱,就连新建设的大数据平台也成了一个个垂直的新的数据中心。
打通数据并将其按照一个统一的标准进行建设,以达到技术降本、应用提效、业务赋能的目标,是众多企业面临的问题。
数据中台应运而生
下图是某公司在给某企业做数据中台时,通过现场调研看到的数据现状。

这是一个较为典型的企业数据现状,在这种数据结构下,带来的的问题也十分的明显,无论是技术还是业务都不会有好的体验,数据对业务的支撑几乎没有可能有好的结果。
从业务层面来看,业务体验十分不好:
1、数据的命名不规范不一致、口径不统一、算法不一致等等导致数据不标准,使得业务困扰。
这也是很多做报表的工具尽管提供了所谓拖拉拽的填报方式,在实际工作中很少有人用的原因。
2、业务的新需求必将产生新的烟囱式的开发,因而开发周期长,效率低,而且,这种开发使得面向应用的服务化能力不足,从而导致业务响应速度慢。
3、不断的重复建设,导致任务链越来越冗长,任务也越来越繁多,导致系统的计算资源越来越紧张,数据时效性很差。
从技术层面来看,技术人员沮丧不爽且资源大量浪费:
1、烟囱式开发导致重复建设严重,技术资源大量浪费。
2、新应用新业务上线困难,下线更为困难。
3、源系统或业务变更,结果又不能及时反映到数据上
4、众多系统的数据不标准,导致研发和维护十分的困难
数据中台就是为解决这些问题而生。数据中台是从IT时代进入到DT时代的必然产物,IT时代和DT时代的最大差异其实就是商业模式的转变,在IT时代是以流程为驱动的,而DT时代是以数据为驱动的。从流程驱动转向数据驱动的必然结果就是数据中台的应运而生。
通俗的讲,数据中台就是这样一个平台:数据平台提供数据服务能力支撑。
在IT时代,像Google,微软等知名企业发布了很多的平台框架,这些平台上的业务系统都是以流程驱动,以业务为核心的,在此基础上,我们常常提及的SOA架构,实质上就是一种服务设计的框架,实现的是服务的复用。由于这些SOA服务框架,针对的都是个性化的业务需求,只能实现以组件模块的形式做编写复制,无法形成真正意义上的数据通用。
类似的还有,不少厂商提供的ETL工具,可以说它们也不能算是数据中台的产品,它们只是一个偏系统级的应用。
DT时代发生了什么?随着大数据,人工智能新技术的发展,一个新的窗口机遇突然就这样来了---数据中台来了。
因为在DT时代,主要几个核心技术组件都发生根本性的变化:
1、虚拟化和超融合的迅速发展,导致围绕IOE体系架构下各种协议标准必须做资源调度的优化。
2、分布式计算、容器化、机器学习、人工智能等技术框架的发展,导致IOE大架构出现断崖式迁移。
这种变化倒逼原来的PaaS层开始发生变化,开始出现以数据变现、数据管理为驱动力的强劲势头,进而使得PaaS层开始出现以数据驱动为核心的框架体系。
以数据驱动为核心的框架体系使得企业可以充分利用数据价值,方便的提供服务应用。
最终,数据中台就呼之即出了。
数据治理:始于数据,终于数据,一个奇怪的自我循环

在数据中台出现之前,已经有很多的数据平台了,比如:数据仓库、数据平台、数据湖等等。
它们和数据中台有什么差别?
我以为最大的差别在于出发点不同,由于出发点不同,必然导致效果的不同。
数据仓库、数据平台、数据湖,这些个平台的出发点其实还是一个支撑性的技术系统。
它们的共同点是:首先考虑我有什么数据,然后才定义我能干什么。所以,在这样一个出发点的前提下,数据质量和元数据管理就是特别需要强调的事情。
然而,数据中台的第一出发点是业务本身,不是数据!
建设的出发点是:解决企业的业务问题,企业的业务需要什么样的数据服务的问题是重要的出发点,所以它不管原有的系统里有什么数据。要解决的数据服务说依赖的数据,原有数据平台中有,那最好,拿来用!
因为数据只是我们解决问题过程中需要的素材,是我们实现业务发展的一种方式。只要我们的业务有价值,那么,我们就要设法去拿到数据。
没有能力的话,就去建设这个技术能力,目的是有一个:完成数据服务的提供。
数据变现的核心是什么呢?就是业务和开发必须紧密衔接。
企业什么时候需要做数据中台呢?当发现数据问题导致变现困难的时候!
数据变现需要数据往前端跑,过去的架构是业务的后端是IT支撑,IT的后端才是数据。所以数据是业务的后端的后端。
要想实现数据变现,充分挖掘数据的能力,就需要数据跑向业务前端,这是势!是DT时代不可逆的势!
势不可违,损我者昌,逆我者亡!传统的数据仓库、数据平台、数据湖等难以实现这样的势,还好,观念的突破给我们带来了数据中台的框架,它能帮我们更好的创造数据价值。

凡是以产品销售为其服务形态的,大概率是不适合用的
数据中台的概念由阿里巴巴首次提出,它是一个承接技术,引领业务,构建规范定义的、全域可连接萃取的、智慧的数据处理平台,建设目标是为了高效满足前台数据分析和应用的需求。
数据中台是涵盖了数据资产、数据治理、数据模型、垂直数据中心、全域数据中心、萃取数据中心、数据服务等多个层次的体系化建设方法。
这么说好抽象,也好广泛。似乎数据中台无所不能。
每一次技术的进步,都会用这样一些大而全的概念来概括。反正不是技术大拿都听不明白。
这其实是技术跟业务的差异。要是数据中台也这么推广的话,估计也会走向老路。当年,数据仓库如火如荼的在祖国大地和全球范围兴起,也是说的天花乱坠的,BI也是这样,报表也是这样,但慢慢的人们却意识到了它们的局限性。
而这种局限性的认识,是在付出了较大,甚至是极大的代价后才认识到的。
直到今天,仍然有人问我:为什么数据仓库不能称为数据中台?为什么数据平台就不能更好的创造价值?
其实,这还是对企业的变现能力和驱动力的理解或者是思维的方式是处于IT驱动还是数据驱动的差异。应该说,不同的业务处于不同的阶段需要采用不同技术体系。
同样的问题,如:上云,还是不上云?上ERP还是不上ERP?等等。
现在没有上软件的企业已经很少,谈论成功不成功也没有多大意义。前些日子,看到过一个关于数据中台是否成功的标准,定了一些指标,看上去还蛮有点道理的。建设的厂商以多少天上线就算成功了,就算交钥匙了。而且,很多厂商标榜着自己的软件比之前的系统更有好处。
但实际情况可能是,用户有说不完的苦,处理不完的事。
既然软件都已经上了,成功失败用户都得认。问题是如何冷眼看结果,对当下的业务管理要做出正确的评价,企业是不是真的适合或者该升级了!
存在问题不可怕,最怕是不知道存在问题,不知道外面世界的变化,我们在这里就给企业用户一些建议,让用户可以用来自评就可以得出结论。
数据中台,虽说是一种业务管理思想带来的,在大数据横行的今天,他地区发挥出了越来越重要的作用。但是,数据中台还是以软件作为载体来体现的,因此,数据中台作为数据变现的管理思想是不会错的,但是,作为软件就必须有一种可衡量的标准。
数据中台的内核,简单的来说,包括两方面:
一个是应用数据的技术能力,
另一个是数据资产的管理。
还是有点抽象吧?
基本的衡量标准:
1、升级的标准:
数据中台,作为企业数据管理的平台,那么,首先,就必须有能力为企业的各种业务提供实时统一的数据支持,所有的业务变迁都可以反馈或者从平台抽取的。从这个维度可定出一个升级的标准:
看企业业务管理中用到了多少零散的、人工处理的数据报表,数一数有多少张便可,好的数据中台是没有这类需要人工处理的数据来源或者表格的。
1、有问题:超过5张,数据中台就已经出状况了,有问题存在;
2、有大问题:超过10张,业务已经就遇到比较大的问题;
3)、有严重的问题:超过20张,业务问题一定是很严重了;
4)、玩完了、崩溃了:超过50张的,数据中台可以说已经形同虚设,别想什么数据变现了。
2、应对变化的标准:
另一个维度的标准就是数据平台应对变化的能力,数据中台必须能够支持企业内外环境的变化,业务模式的调整,甚至是人员岗位的变动等。
1、有问题:超过1天的,响应就有问题了;
2)、有大问题:超过3天的,响应就是慢的了;
3)、有严重的问题:超过5天的,对业务的影响已经很大了;
4)、玩完了、崩溃了:超过10天的,数据中台对对业务的促进已经没有,甚至已经成了拖累了。
用这二个维度的指标为标准,对照自己企业的现状,就可以直接发现问题。
谈标准,是在提醒用户,别忘记了自己的建设数据中台的初心。用户与厂商的初心是不一样的。用户是要解决业务的实际问题,而厂商是把软件平台卖出去,至于结果如何,关心是不够的。
记得初心,实在太重要。但是,你的数据中台,真的处理所有需要的数据服务了吗?
可以这么说:凡是以产品销售为其服务形态的,都是没有处理好的。这样的数据中台大概率来说是不能适用的。

(欢迎大家加入数据工匠知识星球获取更多资讯。)

联系我们

扫描二维码关注我们


微信:DaasCai

邮箱:ccjiu@163.com

QQ:2286075659

热门文章


没有中台的命,却得了中台的病


阿里数据中台维度建模规范、维度模型设计及模型实施方法论


报告老板:中台项目成功了,CTO也被搞走了!


“上中台吗?会送命的那种!”

实战案例 |如何参照阿里OneData构建数据指标体系?

我们的使命:发展数据治理行业、普及数据治理知识、改变企业数据管理现状、提高企业数据质量、推动企业走进大数据时代。

我们的愿景:打造数据治理专家、数据治理平台、数据治理生态圈。

我们的价值观:凝聚行业力量、打造数据治理全链条平台、改变数据治理生态圈。

了解更多精彩内容


长按,识别二维码,关注我们吧!

数据工匠俱乐部

微信号:zgsjgjjlb

专注数据治理,推动大数据发展。

: . Video Mini Program Like ,轻点两下取消赞 Wow ,轻点两下取消在看

文章有问题?点此查看未经处理的缓存