本文来自于 Rational Edge：这个分为两部分的系列文章概述了如何将基于 IBM Rational 统一过程（RUP）的方法用到数据仓库（data warehouse，DW）项目中，这些项目可以在遇到最终用户的需求变更时，交付高质量解决方案，从而减少您的商业及技术风险。本文概述了与传统、串行的 DW 开发方法相关的问题，介绍了 RUP 的渐进式的方法是如何更加适合 DW 开发的，并且概述了这种项目的初始阶段。

　
　图 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 的一个有趣的方面是阶段形式的连续性特点。这些阶段很像项目的季节 —— 在任何假设的一天，您可能在做一些需求工作或一些测试工作，但您更可能在项目的早期做需求工作，而不是在项目的末期。在图 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 生命周期，数据仓库的未来版本 —— 对，你的工作永远不会做完 —— 是怎样开发的。