数据建模与数据治理 之四

敏捷开发

 

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应用程序只是数据平台开发中最后几步，Scrum和XP都没有考虑到这些工作的复杂性和相互依赖。 

 

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

 

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

 

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

 

 

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

 

 

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

 

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

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

 

 

 

来源：DAMA数据管理

作者：山水模子