数据仓库2.0方法的定义项目
有时，这需要首先构建一些依赖关系，比如设置初始的数据仓库基础设施。然而，最初应该避免最终的数据仓库基础设施。从小处着手，但使其可扩展。需求不断增长的基础设施。
通常，架构师尝试一层一层地创建数据仓库解决方案:他们决定一组初始的源系统来交付所有需要的报告或OLAP(联机分析处理)立方体。然后，他们实现整个staging area来捕获所有的源表，包括装载表的ETL。一旦他们完成了登台区，他们就开始尽可能地对企业数据仓库建模，因为将来联系it太贵了。在ETL工作负载工作实现之后，创建一个数据集市以最终满足业务用户。这种方法通常需要几个月，如果不是几年的话，包括几个阶段的调试和错误修复。然而，当需求改变时(这个例子中的架构师会说“过于频繁”)或者业务需要额外的功能时(在许多情况下，最初的架构师已经离开了组织)，问题就出现了。
鉴于Data Vault2.0标准中的可扩展模型和架构以及敏捷方法，数据仓库架构师不再需要遵循这种方法。数据仓库不是以横向的方式，一层一层的建立，而是根据特点以纵向的方式建立。数据仓库计划的总体目标是相同的，但是现在是在功能的逐步交付中实现的。BI团队的目标是在快速和频繁的发布中交付所需的功能，如本章前面章节所述。为了做到这一点，函数的范围必须限制在尽可能与其他函数分离的单个函数中。
实现这一目标的建议方法是使用需求工程中范围定义的方法和个别特性的实现，如图3.11所示。
在图中所示的例子中要实现的特性是一个报告，但是它也可以是用户需要的任何其他工件。例如，它可以是OLAP立方体中的新维度或属性、单个新OLAP立方体(具有最小维度)或用于文本挖掘的语料库。一旦业务确定了工件的范围并对其进行了描述，它就开始识别构建这个单一报告所需的源(源系统中的表)。接下来，确定信息集市的目标，以评估交付所需报告(或其他功能)的适当位置。一旦执行了这种识别，工程师就可以对所需的数据进行分级，构建和加载数据库实体，并构建集市。当遵循这个过程时，源表中的所有数据都在Data Vault中加载和建模，而不是部分属性集。所以源表只能联系一次，不能多次。为了评估数据的可用性，应该能够跟踪哪些数据已经加载到企业数据仓库中。部分加载的数据使得评估更加复杂，这是我们想要避免的。此外，只从源表中加载部分数据会产生更复杂的Data Vault卫星。
定义要在迭代中开发的工件(即需求变更)是迭代成功的重要前提。适当的范围界定降低了团队不能在sprint时间框架内完成和部署变更的风险。如果你不确定所需的变化范围，那么短时间的两周甚至一周的冲刺是不可能实现的。此外，由于Data Vault2.0模型，团队现在可以跨业务线逐步构建解决方案，因此他们可以在实施范围内保持灵活性。
我们应该注意两个反对意见:第一个反对意见是实现来自一个源的所有表，以保持集成源系统的低成本——在这种情况下，加载当前解决方案不需要的数据。加载这些数据需要额外的ETL能力，这需要更大的初始基础设施。此外，来自一个源系统的所有源表的实现可能不会在一个sprint中完成，可以用来实现要交付给业务的特性的人力是受约束的。这种努力常常超过了评估已经存在于数据仓库中的数据的复杂性(注意表格是很容易的)。另一个问题是，当源表在组装区域中实现时，将数据集成到Data Vault中也是一个好的做法。否则，当两个系统可能不同步时，需要额外的复杂性来评估数据仓库的当前状态。如果遵循这种做法，加载所有源表需要完整的建模和加载相应的Data Vault表。
第二个反对意见是，为了达到最终的解决方案，多次接触目标是很昂贵的。这可能是正确的，但最终目标是在一个sprint中为业务提供可操作的、有用的功能，因为它降低了失败的风险:业务不接受解决方案，例如，因为它不符合书面要求，在此期间需求发生了变化，或者一旦业务用户实际使用了解决方案，解决方案将被证明是错误的。
这种垂直信息传递方法是在sprint中实现的。根据组织能力，这可能需要两到三周的时间。因此，Data Vault的建模不应该需要几个月的时间。相反，模型应该在冲刺阶段创建。如果用的时间更长，这是一个很好的指标，冲刺幅度太大。在这种情况下，应该从sprint中删除该功能。删除所有不需要用单一特性交付的内容是本次sprint的重点。确保业务用户明白这个特性还没有交付——但是在以后的sprint中。通常，业务用户认为该功能被完全删除是因为它在计划中被从sprint中删除了。然而，这是错误的，因为缺少的功能将在下一次迭代或迭代后很快交付。业务用户一旦看到项目的进展，自然会接受这个程序。
在sprint中实现一个新功能之前，您需要定义它。然而，需求收集过程与实现过程非常相似。通常，企业对要在数据仓库中实现的功能有一个大致的概念。但它仍然有许多问题需要回答，例如关于数据源、聚合或转换数据的业务规则、数据类型、用例等问题。为了回答这些问题，使用了一组需求。
为了支持需求收集的敏捷方法，需求是沿着流程收集的。与传统的数据仓库不同，这些需求是在项目开始时收集的。我们项目中最有效的方法是使用原始集市，并快速将数据推送到需求会议进行审查。这些原始集市用于为参加需求会议的有限数量的业务用户创建报告或多维数据集，但不用于分发。这是因为原始集市包含的原始数据可能会也可能不会完全实现业务规则。通过演示给用户看这些报告，问他们“这个报告怎么了？”事实证明，业务用户可以很容易地指出报告中的问题，并通过这样做，提供实现最终报告所需的所有业务规则。
这种需求收集方法的步骤如下:
到目前为止，它已经控制了交货时间。他们有责任敏捷到这一步。下一步由项目的业务方面驱动:
一旦收集了需求，至少是部分需求，它通过执行业务规则和其他需求来再次驱动项目:
在这些业务规则被IT实现之后，项目的业务方可以审查和测试输出，如果他们对最终的结果不满意，他们将要求进一步的修改。然而，这些修改变成了需求变更，并在随后的sprint中实现。所描述的敏捷需求收集过程帮助业务用户表达他们的业务规则。对于他们中的许多人来说，传统的对需求文档的关注太抽象了，并且阻止了所需的识别来识别报告草案的问题。
建议的方法是记录这些需求会议，并为组织中的每个人建立一个Wiki网站。会议记录，包括对发现的业务规则的描述，应该在网站上注册，以确保需求收集过程的透明度。Web2.0机制使参与者可以根据自己的理解发表评论，甚至修改业务规则。这种方法首先确保需求是正确的。如果网站上有很多讨论，可能需要召开另一次需求会议来澄清任何未解决的问题，然后才能开始实施。在实际实施之前举行这些讨论意味着对组织的巨大益处和生产力的提高，这是项目总体成功的促成因素。为了做出团队的功能可以在一次sprint中完成的正确假设，这对于定义范围非常重要，团队必须能够对完成某些功能所需的努力做出正确的估计。这个话题将在下一篇文章中讨论。