Gartner Group 已经将数据仓库项目的成功率标定在大约 50％，尽管这还要依赖于您是怎样定义成功的。其他人给出的成功率低到 20％，高到 65％。不论如何，我们似乎还有提高的余地。我的经验是，DW 开发的传统的、串行的方法（在开发开始之前要进行数周或数月的建模）不足以满足我们现今所处的动态商业环境的需求了。项目涉众(stakeholder)需求的不断变更需要一种灵活、渐进的，且高度 协作的 DW 开发方法。Rational 统一过程®，或称 RUP®，定义了这样的方法。

采用一种渐进的方法进行 DW 开发的需要并不是什么新鲜的事情。Bill Inmon，公认的数据仓库之父，实际上从一开始就非常清楚这样做的需要。不幸的是，许多数据仓库的成就被不久以前的沉重缓慢的、串行过程所束缚，这些过程无疑是导致 DW 项目高失败率的主要因素。其他的因素包括：太过重视实际数据本身，而不是 DW 提供给最终用户的潜在商业价值，以及相当 天真的假设，即您需要为主要的数据实体确定“一个事实”。幸亏这些都是我们能够选择去处理的自己造成的问题。

在我开始之前，我想要宣布的是我已经将许多敏捷的概念和技术加入到依据 RUP 的 DW 项目开发方法中。我的许多建议，例如只对当前的情况做刚好够用的建模和文档编制，可能看起来是很容易应用于 DW 项目的常见的观点。其他观点在传统数据管理开发周期中似乎是异端的，举例来说，争取确定“一个事实”常常证明是价值很低的时间投入（别担心，我将在文章后面解释这为什么是真的）。我 的经验是，如果您想要真正地达到能够响应涉众需求变更的高质量的 DW，那么您需要摆脱传统技术，并采用敏捷的、基于 RUP 的方法。

为什么采用基于 RUP 的方法？

RUP 常常被看作是一个面向对象（object-oriented，OO）的开发过程，公正地说，这无疑是一个错误的说法。事实是，RUP 还经常用于使用过程化的技术，例如 COBOL，构建应用程序，用于实现基于商业成品（COTS）的商业系统，用于利用面向服务的体系结构（service-oriented architecture，SOA）构建应用程序，并且，用于利用数据仓库、数据集市(data mart)，及报告技术来构建商业智能（business intelligence，BI）系统。本文的焦点是 DW 项目。

图 1 描述了 RUP 生命周期。RUP 是一种渐进的开发方法，在 RUP 中，您会采用迭代和增量的方法。迭代的特性是由图左手边的各种规程所描述的：您在各种与需求、分析与设计、测试、程序设计等等有关的活动之间反复地迭代。随着时间的推移，您 会开发增量的版本，每次都经历一次开发的生命周期，形成系统的一个版本。在细化阶段，您开发解决高风险技术问题的架构。而且，在每个构造迭代末尾生成可运行的软件，该软件可以在内部 发布，用于测试及/或演示目的。

图 1：RUP 生命周期

下面有许多理由，讲述为什么组织选择 RUP 进行数据仓库项目的开发：

1. RUP 解决范围风险。RUP 认识到，您的需求在整个项目中会发生变更，因此，它推行灵活的需求管理方法。我们知道，人们不善于在最开始定义需求，外力与内力同样可以激发变更，老实说，人们一旦看到已交付 的内容就会改变想法。问题在于试图在最开始定义全面的需求规格说明已经证明是非常的危险决策，因此我们不用 RUP 来做这件事。不要误解我。您需要在 RUP 的初始阶段做一些初始的需求建模，但不需要像传统主义者想得那样全面。
2. RUP 不仅专注于数据。DW 项目失败的一个主要原因是没有给涉众提供足够的商业价值。要想识别并着重于商业价值，您就需要了解该数据可能会如何在实际中使用。因此，对于获得实际需求的主要视角来说，以用途为中心的方法（通过 RUP 的用例应用来提供），优于用以数据为中心的方法。
3. RUP 尽可能早的解决技术风险。我相信太多的 DW 项目失败，是因为在项目早期所生成的详细模型所提供的错误自信。数据模型是非常详细的，您获得了“一个事实”，并且您已经在这上面花费了数月，因此那怎么会不好呢？问题在 于每个架构都在纸上、您的建模工具中，或白板上工作。直到您使用代码验证了架构，您才能确实地知道它能工作。如您将在本系列第 2 部分中见到的，RUP 的细化阶段着重于在生命周期早期解决技术风险。
4. RUP 解决财务风险。一个重要的 RUP 概念是，在细化及构造阶段迭代中，您应该增量地，在优先级的基础上交付工作软件。迭代最好定义为一个一到四周时间长的时间块，尽管非常大型且/或分布式的团队会有更长的迭代 ，在这期间项目团队将交付整个系统的一部分。尽早处理项目关键组件的增量、迭代的开发确保您首先交付最大价值的功能，并且确保您一直在将涉众的投资回报（retur n on investment，ROI）最大化。该方法还向您提供关于项目状态的具体反馈。软件开发项目进展的唯一真实量度是定期交付工作软件，以让您确定 IT 投资资源是否花得明智。
5. RUP 允许有规则的灵活性。数据仓库项目是困难的。需求很难查明，遗留数据源常常提出重大的挑战。我们需要灵活，但同时，也要提供对管理的控制等级，以使它们有效地治理开发工 作。RUP 允许这样有规则的灵活性。您可以按照您的确切需求进行裁减，以为您特定的情况提供正好合适的灵活性及精确性。

本文的主体是给出利用基于 RUP 的生命周期进行 green-field DW 项目的视图，尽管在结尾处，我探讨如何处理未来的发布版本。数据仓库真的是您的组织的技术基础架构的重要方面，因此您真的需要将其看作随时间不断演进的一系列发布版本的产品。每个发布版本都作为一个独立的项目进行管理。

RUP 的一个有趣的方面是阶段形式的连续性特点。这些阶段很像项目的季节 —— 在任何假设的一天，您可能在做一些需求工作或一些测试工作，但您更可能在项目的早期做需求工作，而不是在项目的末期。在图 1 中，这些“峰值”表示整个项目中每个规程的相关工作。在本文中，我将介绍在 DW 项目的初始阶段中会发生什么，并且在第 2 部分中，我将介绍细化、构造，及移交阶段。

处理范围风险：初始阶段

初始阶段的主要目标是为项目打下基础。您需要确定初始的范围、初始的高层计划、从商业角度对项目目标和初始项目合理性的概括看法，并且获得最初的涉众对项目的支持。注意 整个列表中单词“initial（初始的）”的使用。所有这些东西都会在整个项目过程中发展，这句话的含义是您需要让相应的工件达到目前状况足够好的程度 —— 它们不需要是完美的，它们也不需要是全面或最终的。记住，有了 RUP，做到有规则且灵活是可能的。

您初始的需求是以高层用例的形式获得的，图 2 中显示了一个实例。图 2 描述了 Behemoth Retail Company 的 Place Stock Order for Store 用例，我们为这个虚拟的组织开发数据仓库。用例的优势是，它们描述了向业务参与者提供商业价值的活动，业务参与者是与系统交互的个人或组织。还有一些系统参与者，它们是与您的系统进行 交互的外部系统，在数据仓库项目的例子中，将是您要从中提取数据的遗留数据源。

图 2：初始的高层用例说明

图 2 中的用例相当简略，只是有名称和一些典型的注释来描述主要思想。用例只提供足以让涉众很好地了解用例的范围的信息。它没有进入我们打算做的令人烦恼的细节，没有指示 使用哪个屏幕和报表，没有编制业务规则文件，并且没有列出支持该工作所需的数据单元。如果我们需要，我们可以在随后的迭代中获得这些细节，目前，我们的目标仅仅是很好地了解 范围。

这与敏捷的原则一致：敏捷的建模者一旦完成了他们的既定目标，他们就会停下来，并转移到其他的事情上。许多传统主义者与此概念对抗，认为它们需要在项目早期编制出需求细节。实际上这 样做是非常浪费时间的。当需求变更时，需求总是这样的，之前所有的投入到编制刚刚变更的内容上的工作现在都作废了。此外，真的不用急于撰写需求文档，因为如果您有能力在今 天建模，那么在您真正需要这些信息的未来时刻，您也有能力建模。但更糟糕的是，如果越长时间您没有得到编码工作所提供的具体反馈，那么您发现您是否真正了解需求的时间就会越长。总之 ，撰写全面的文档似乎是安全且轻松的事情，但事实上，它增加了项目失败的风险。

在 Behemoth 数据仓库项目中，我们很容易获得几十个，要不然就是几百个用例。在初始阶段，一些用例会描述为图 2 中所见的详细级别，其他的对成功不是关键的，因此我们可能目前只给它们一个名字。要组织这些用例，或者至少连通要管理的所有范围，您可能决定生成一个或更多的用例图。您的用 例模型由用例图，加上支持文档组成：也就是，用例说明及角色描述（如果您选择将它们编制为文件）。牢记您的用例模型的核心是用例，不是图，所以这通常是您的重点。

在项目中，涉众的参与是关键的 —— 我强烈推荐让涉众积极参与敏捷建模（Agile Modeling），涉众不但日常参与您的项目，而且自己直接参与实际的建模工作。任何人都可以将用例写成图 2 中所示的详细级别，那么为什么不让业务专家，也就是了解业务的人，直接参与用例的撰写呢？

在初始阶段里，您应该开始从业务角度和技术角度考虑系统的初始架构了。对于数据仓库，这通常意味着分别创建高层概念模型和高层部署图。图 3 描述了利用 Rational Data Architect (RDA) 生成的 Behemoth DW 的初始概念模型，图 4 描述了由 Rational Software Architect (RSA) 创建的初始的统一建模语言(UML) 部署图。注意概念模型是如何只确定主要业务实体的，例如 Customer、Store 和 Item，以及这些实体之间的关系的。这里，我们只需要这样的详细级别，以开始确定相应数据的可能来源。当我们需要时，我们可以再次处理细节。同样地，部署图只说明足够的细 节，以令团队了解技术工作的可能范围。如我们将在第 2 部分中看到的，这些模型将在项目过程中演进。

图 3：初始的概念模型

图 4：最初的部署模型

如果存在企业标准 —— 例如数据命名规范、用户界面设计指南、程序设计指南，或建模指南 —— 那么在此采用它们。如果不存在，那么您希望开发一些，或更好的是，采用现有的行业标准。仅仅通过在 Internet 上寻找，您能够找到的东西就非常惊人了。所有的工作都是 RUP 环境规程的一个方面。

在项目的这一点上，很重要的是开始做一些基本的范围和架构上的决定。您打算为具体到点的解决方案构建一个或多个数据集市吗？您打算为整个企业构建一个数据仓库吗？ 您试图满足组织商业智能的所有需求吗？别担心，您可以利用基于 RUP 的方法完成所有这些项目，但是您仍需确定范围，以便您有一个明确的目标。出于本文的目的，让我们假设您将为整个企业构建一个数据仓库。

您也要为项目开发高层计划，并且为下一个或两个迭代开发详细的计划。高层次的项目计划处理主要的相关性和整个策略，然而，详细的迭代计划处理目前战术的问题，如同建 模一样，提前一点点工作，并且以即用即做（just in time，JIT）的方式处理细节似乎最好。当您计划该项目时，不要忘记考虑长期的问题，例如对仓库的操作、支持和不断的改进。（在此量级的项目中，如果您不愿意着眼于数据仓 库总体拥有利益（total benefit of ownership，TBO）和总体拥有成本（total cost of ownership，TCO），那么您倒不如现在就停止！）

在每个 RUP 阶段的末尾，您会做出通过或者不通过的决策。在初始阶段的末尾，主要的问题是您的范围、进度和预算是否与涉众达成一致，以及构建仓库的可行策略是什么。次要的问题包括 您是否有可控的项目政策，并且开始了数据管理和数据治理的有效策略。

在初始阶段有一些您希望避免的普遍的误区：

1. 认为这是传统的需求阶段。在 RUP 中，确保我们了解需求是如此的重要，以至于我们在整个生命周期中都在探究，而不仅仅只在项目的最开始。
2. 认为您需要让您的模型和计划完美。您只需要让它目前足够好就够了。我们将会看到，在下面讨论构造阶段时，实际上相当直接地采用渐进的方法构建数据仓库。
3. 在项目的开始，试图创建全面的数据模型。实际上，您甚至可能根本不需要数据模型。许多数据仓库项目似乎总是迷恋这样的观念，那里存在一个数据事实的单一版本 ，存在公共、共享的原始基准数据，也许甚至是您主要的业务实体的定义。这是个好的看法，但不要让它妨碍您的团队及时交付重要的商业价值。事实上是，组织中各个不同的部分 采用不同的工作方式，不同的优先级，以及不同的约束。可能不存在一个单一的共享事实，而如果有的话，也将随时间变化。最近我经过伦敦的希思罗机场，整个隧道都是 HSBC 的一系列广告（参见http://www.yourpointofview.com/hsbcads_airport.aspx）。这些广告非常直 接。它们展示了两个类似的图片，每个图片下面有不同的广告语。然后它们再次展示了同样的图片，但替换了广告语。问题在于人们以不同的方式看世界，作为一个金融机构，它们理解这个问题，并且据此 足够灵活的采取行动。我的建议与此有直接的关系：采用实际的方法，并且认识到，当进入建模时，回报率将是逐渐缩小的，而且您会很快到达拐点，在这个拐点处，对数据建模进一步的 投资会减少对组织的整体价值。传统数据仓库工作的失败率已经说明了这一点。

以后的文章

在本系列的第 2 部分，我将介绍在细化、构造和移交阶段所发生的事情。您将会看到，通过开发端到端的系统工作框架，在细化阶段如何处理技术风险。您将会看到根据涉众变化的需求和优 先级，在构造阶段数据仓库是怎样演进的。您将会看到在移交阶段，怎样有效地将数据仓库部署到产品环境中。最后，我将向您展示，通过不断地经历 RUP 生命周期，数据仓库的未来版本 —— 对，你的工作永远不会做完 —— 是怎样开发的。

参考资料

• 您可以参阅本文在 developerWorks 全球网站上的 英文原文。
  
  
  
• 您可以参阅 Rational Edge 电子月刊中文版 的其他文章。
  
  
  
• 阅读三部本组成的系列文章，“交付灵活有效的数据仓库解决方案”：
  
  
• Rational Method Composer 及 RUP 参考资料页提供插件链接、文章，及工具，用于采用并使 RUP 适合您独特的需求：Rational Unified Process 与 Rational Method Composer 专题
  
  
• W.H. Inmon 撰写的书籍 Building the Data Warehouse: 4th Edition 为成功的数据仓库开发提供世界级的建议：http://www.amazon.com/exec/obidos/ASIN/0764599445/ambysoftinc
  
  
• S.W. Ambler 撰写的书籍 Agile Modeling: Effective Practices for Extreme Programming and the Unified Process by S.W. Ambler 介绍了用来将建模及文档编制工作流线化的被证实的技术：http://www.ambysoft.com/books/agileModeling.html
  
  
• BI Best Practices Chat Program 提供极好的论坛，以听取来自 IBM Business Intelligence 团队的前沿思想：http://www-306.ibm.com/software/data/education/bichat.html
  
  
• 参见 IBM Solution Builder Express 以了解更多关于商业智能及其他解决方案领域的详细信息：http://www.ibm.com/partnerworld/solutionsbuilder
  
  
• Claudia Imhoff 和其他人在她的 blog 中讨论数据仓库失败率：http://www.b-eye-network.com/blogs/imhoff/archives/2005/03/failure_of_data_1.php
  
  
• 查看 IBM DB2 Business Intelligence 的官方 Web 站点，获得更新的产品信息：DB2 数据仓库、分析和发现
  
  
• 要了解更多关于商业智能的技术参考资料，请参见 developerWorks 上的 DB2 Business Intelligence 部分：DB2 Business Intelligence 技术资源中心
  
  
• 阅读 DB2 Magazine，了解关于 DB2 数据挖掘、程序设计、系统管理、目录管理等等的技术及商业层特性。DB2 Magazine 中文版
  
  
• 浏览 IBM 在线红皮书，深入了解广泛的技术主题。http://www.redbooks.ibm.com/
  
  

关于作者

为本文评分

评论

回页首

内容

• 为什么采用基于 RUP 的方法？
• 处理范围风险：初始阶段
• 以后的文章
• 参考资料
• 关于作者
• 建议