数据建模与数据治理 之四

2021-11-14 18:56 浏览量:322

敏捷开发

 

K公司为某银行敏捷开发的功能并不复杂的XX核心系统,在历经多次延期之后终于投产。回顾3月初的一则新闻:因 IT 项目失败,M公司向其保险公司客户DirectLine赔偿三千六百万英镑,之前该公司指控M公司搞砸了一个影响深远的基于敏捷方法的保险平台IT项目。比较这两个敏捷项目,前者是交易系统,最后投产了(如果发生在英国,K公司是否可能面临诉讼?),后者是数据平台,已成为一个数据平台项目失败的经典案例。M公司还搞砸了另一家保险公司Co-Op的敏捷项目。


 

他们做错了什么?


 

他们都破坏了敏捷宣言的第一原则:首要任务是通过尽早并持续交付有价值的软件来满足客户的需求。这一点是事实,无可争议。


 

他们为此辩解:甲方发出了不必要的、变更范围的变更请求。从传统软件工程管理的角度看,IT方某些理由貌似很充分:甲方客户负责需求,乙方公司负责按需求实施,但是对于一个号称敏捷的项目,这样的理由显得苍白无力。


 

即他们破坏了敏捷宣言的第二原则:即使在开发后期,也欢迎不断变化的需求。敏捷过程利用变更来获得竞争优势。所谓的敏捷开发主要应对的场景是业务需求不明确,或者技术需要通过快速原型与业务沟通来确认对需求的理解。主要起因是传统的瀑布式SDLC开发流程,必须有明确的需求,从需求、设计、 开发、测试,每一阶段都要进行严格的评审,每一阶段工作的完成是下一阶段工作开始的前提。一些软件类系统项目,特别是创新性或者急于上市抢占市场的项目,很难在需求阶段分析和挖掘出所有需求,所以对于敏捷开发,需求的不确定性以及变更应该是很正常的场景。


 

敏捷开发的前提是不降低质量,提升交付效率的同时,不影响交付质量。敏捷开发要求有很好的原型、高素质的参与者以及高效的团队管理。


 

敏捷宣言强调对流程的要求,要求开发人员对其工作流程拥有完全的权限,不能容忍团队之外的任何人(包括业务用户和管理人员)的任何干扰。实际上许多大型组织没有孤立的系统,不可能提供这样的真空项目环境,需要与内部、外部其他系统交互,这些交互接口应该遵循约定的标准,不需要程序员主动自我创新。


 

团队内业务人员和开发人员每一天都必须相互合作,所有任务和交付成果必须是共同拥有和共同开发的,每个参与人都积极主动,互相信任。业务人员和开发人员之间如何沟通需求?程序员之间交互协作的接口是什么?对于一个处理业务数据的系统来说,这个接口应该就是数据接口标准,所有协作的开发人员,对于数据的结构、关系及所允许的操作,必须有一致的理解,这是他们之间的信任基础


 

以频繁交付为主要目标,不重视文档工作,往往只有少量文档,甚至没有文档,数据的元数据藏在程序中。软件应该还包括其文档,没有元数据的敏捷开发给数据治理与数据平台建设制造了大量障碍。没有元数据,下游不可能快速实现整合的模型,没有敏捷的手段或方法来给混乱的数据建模。


 

麻烦制造者


 

某些所谓的敏捷开发,IT与业务之间没有很好的沟通工具,没有透明的信任基础,很多时候是不断试错,不断推翻重建的过程。这些敏捷项目有很多相似之处:


 

  • 本该尽早投产产生价值,但由于不断地发现问题,解决问题,又产生新的问题,以致循环,陷于泥潭之中,使客户丧失信心,最终被抛弃。所以Co-Op项目原本计划产品只发布一次(一个版本)进行用户验收测试,在合同最终搞砸之前,演变成了计划“发布79次”。
  • 由于没有深刻理解已开发完成的业务需求,也没有深刻理解新的需求,只能无章法、无根据地复制和粘贴创建新表。最后把导致问题的原因推给业务用户:业务没有提出质量需求,需求不完整或者提出了变更。
  • 数据平台作为下游,从项目切身体会看,敏捷开发者把数据当作程序功能的副产品。在他们的敏捷开发中没有“规范“,或者”规范“只存在文档中,实际的敏捷开发是不受管控的随意开发,一直在制造问题,作为下游必须承担一些测试、验证甚至建议工作。
  • 只有技术概念,没有业务概念。没有概念与逻辑,只有表、记录、字段,不考虑设计的表想要表达的真实世界对象是什么。所以某些业务系统设计了数千张表并不意外。
  • 他们的思维中,只有“建”数据,没有“用”数据。他们不考虑,数据的创建仅是数据生命周期的开始,因为自己的任性,给下游造成很大的麻烦,也给自己带来了扩展与维护的困难。
  • 无客户至上思维,浪费资源的同时,也增加了数据处理的复杂性。一笔交易,要通过多张表来关联才能取得完整的信息,而且很难做到表之间的精确关联,这些表中都有数千万条记录。
  • 缺少数据库设计的基础知识与基本常识。不知道什么是业务主键,什么是代理键。不知道什么是代码值,什么是代码描述。数据关系观念浅薄,几乎不考量参考完整性。仅定义了number、timestamp、varchar2三种数据类型,大量varchar2(1)数据类型字段。大量的冗余,造成大量的数据不一致。

 

向一些业务系统IT人员调研数据模型,绝大部分不知道什么是数据模型,或认为只有数据仓库才需要数据模型。他们不知道关系数据模型的作用,第3范式是设计关系数据库的要求,并不是数据仓库的独特主张。因此,他们生产源源不断的问题数据,他们成了麻烦制造者

 

数据模型支持敏捷开发


 

敏捷方法并不是只有Scrum或XP,敏捷是指能够快速推进,及早持续交付。传统软件工程强调软件的重用以提升质量与开发效率,数据与数据模型也可以重用。数据与业务,相对于流程、程序,有更多的确定性与稳定性。数据模型是对业务与数据的知识积累,无论流程怎么优化或再造,业务内涵很难发生颠覆性改变。互联网只是一个渠道,在互联网上经营存贷款业务,改变不了业务本质。


 

数据不是流程的副产品,数据建模比流程建模更重要或者至少同等重要。当一个敏捷项目必须抛弃重来的时候,至少还有数据模型可以重用。有些银行核心系统已经经历过多次升级换代,应该总结提升形成一套符合本行特色的核心交易数据逻辑模型,作为未来升级换代的快速原型。


 

一些所谓的敏捷开发方法反对或回避模型设计,认为设计模型延误了开发时间,是敏捷开发的主要瓶颈,主张直接从需求到直接建物理表,进入编程开发阶段,从而产生了大量的需要治理的数据问题。不需要数据模型、跳过模型设计的敏捷开发,是不了解数据模型的作用与价值,是对数据库设计的曲解与无知偏见。开发者通过数据模型达成对业务与数据的共同理解,是敏捷开发合作、共享与信任的基础。


 

数据平台敏捷开发方法


 

传统数据仓库开发备受责难的一点是建设周期长,可能会失去业务机会,他们甚至建议不再需要关系数据库管理系统和基于它们的数据仓库。这是个伪问题——越过数据治理的敏捷开发。


 

根据《哈佛商业评论》,平均而言,创建的数据记录中有47%具有严重影响工作的错误。根据ForresterResearch研究报告,数据探索和集成步骤花费了DW / BI工作的50%至80%。集成驱动了80%以上的价值。数据分析项目80%的时间花费在准备数据上,而非创造价值。


 

对于数据驱动的业务数据集成项目,Scrum或任何其他功能驱动的软件开发方法都不是正确的方法。所有流行的开发独立的交易系统的敏捷软件开发方法,都专注于尽可能快地编写和交付高质量软件,从未为以数据为中心的业务集成解决方案而设计,无需过多考虑或关注数据,例如数据剖析、数据标准化、数据建模、数据集成设计、解决数据争议等等,所有这些数据管理活动都需要从企业角度出发,并且工作量很大开发前端BI应用程序只是数据平台开发中最后几步,ScrumXP都没有考虑到这些工作的复杂性和相互依赖。 


 

数据平台不是软件开发Project,而是业务数据持续整合的Programs。这样的商业智能计划应该是持续的,随着业务需求的变化变得越来越复杂。


 

Inmon推荐Larissa Moss螺旋式方法开发数据仓库,并已证明了价值。螺旋式方法非常适合不知道自己想要什么的用户。商业智能功能通常以探索方式开发,业务人员最终将在看到他们想要的东西时才知道他们想要什么,一旦他们得到了想要的需求,他们就会提出更多的需求。


 

螺旋方法的目标是建立可重用资产的清单,帮助组织摆脱废件与返工的死亡螺旋,将重点放在可重用组件上。包含3条平行路径:数据管理路径、数据交付路径与元数据管理路径,那些所谓的快捷交付,常常忽略了数据管理与元数据管理


 

 

为了使螺旋式开发方法获得成功,Inmon推荐采用一种企业数据处理方法—“七流方法,即企业参考模型、企业知识协调、信息工厂开发、数据剖析与映射、数据清洗、基础设施管理、总体数据质量管理共七个高级活动流,如下图。


 

 

成熟的行业数据模型给螺旋式开发提供了很好的参考原型。可以根据数据的重要性按主题或按数据源或按主数据、交易数据的不同来组织迭代,不需要等数据仓库所有主题设计完之后设计应用。

 

敏捷开发的不对数据建模的交易系统,不断产生数据问题,他们是麻烦制造者。

敏捷开发的不对数据治理的数据平台,不可能交付高价值数据。

 

 

 

来源:DAMA数据管理

作者:山水模子

上一篇:什么是时序数据?如何治理?有哪些应用场景?终于有人讲明白了

下一篇:数据模型与数据治理(三)

  • 分享:
龙石数据
咨询电话: 0512-87811036,18013092598
联系我们
商务联系微信

商务联系微信

0512-87811036,

18013092598

咨询电话