Data Vault 2.0方法论——项目计划

由于数据仓库是软件的一部分，许多来自行业的学术研究人员和专业人员都同意这样一个事实，即来自软件工程学科的方法可以应用于数据仓库项目。我们已经讨论了一些著名的项目计划方法。

Data Vault 2.0方法的项目规划能力来自PMP。与敏捷的Scrum方法不同，它强调在一个sprint冲刺中有一个正式的项目计划。每个项目有一个项目计划:包括要完成的任务、作为任务输出的预期结果以及将执行任务的角色。根据项目类型的不同，有不同类型的角色来执行项目：
业务发起者：应该在项目与业务和愿景之间建立一致性。

• 代表项目进行沟通，特别是与高级管理人员沟通;
• 成为项目的主要倡导者，并获得其他主要利益相关者的承诺;
• 安排资源，确保项目成功;
• 确保通过问题的升级能在组织层面上得到有效解决来促进问题的解决;
• 通过提供指导、辅导和领导来支持项目经理;
• 并建立项目的持续性，以确保这个项目产出是可持续的。

技术业务分析师:是向业务部门报告的高级用户，但具有一定的技术技能，包括理解数据模型和直接利用或编写SQL的能力。

• 建立标准和访问控制列表;
• 优先变更需求;
• 建立新的要求;
• 为一般业务用户创建新的报告;
• 帮助团队调试alpha版本;
• 参与信息集市的开发和设计;
• 并创建用户算法训练的材料。

项目经理:负责确保项目团队完成项目。

• 制定项目计划，管理团队的项目任务绩效，确保项目发起人和其他利害关系人对可交付成果的接受和批准。
• 负责沟通，例如状态报告、风险管理和无法在项目团队中解决的问题的升级。

IT经理:确保业务的连续性和业务的成功。

• 监督项目并确保他们有效地使用资源。
• 客观地向管理团队提建议，在哪些方面IT可能会对业务产生影响;
• 就成本、工时和需要满足的标准达成一致意见，并在整个项目过程中对其进行监控;
• 帮助组织顺利地从遗留系统过渡到新系统;
• 并向管理层汇报目前项目的最新进展。

ETL开发人员:负责提取、转换、加载(ETL)过程的开发人员。

• 执行数据或者控制流从源系统到集结区的加载。
• 执行数据或者控制流从集结区到原始DataVault的加载。
• 执行数据或者控制流从原始DataVault到业务仓库和信息集市的加载。
• 负责创建虚拟集市；
• 在ETL实施软业务规则，即所要求的业务。

报表开发人员:基于信息集市、业务仓库表或(在极少数情况下)直接在原始数据仓库上实现业务驱动的报表。

• 在大多数情况下，他们不需要为此实现任何业务规则;
• 在极少数情况下，实现业务报告可能需要在报告中直接实现有限的业务规则。
• 在大多数情况下应该避免这种情况，因为性能会下降，可重用性也有风险。

数据架构师/信息架构师:负责的信息架构和数据集成。

元数据管理员:负责元数据的建设。

• 负责元数据设计的规划;
• 改进元数据开发的框架;
• 协调与其他角色和项目的活动以及沟通;
• 为需要使用元数据的所有内部成员和外部人员，管理他们对元数据的访问级别。

变更管理人员:确保新功能在推出时不会干扰其他IT或业务服务，也负责确保在环境中可以进行新的发布，并且不受其他项目的阻碍。

许多组织错误地将职责分配给人员，而不是定义的角色。在团队中定义角色的好处是，可以用另一个有技能的人代替这个角色的人——例如，如果当前的人离开了组织或改变了项目。角色定义在很多方面对组织有帮助:这些角色定义帮助人力资源部门在自由市场上为工作找到合适的人;新员工有可能很快确定自己的职责，并完成他们应该完成的工作;最后，明确的职责可以帮助团队在处理开发项目中自然产生的问题时决定谁做什么。

在数据仓库中，项目团队已经知道大多数所呈现的角色。技术业务分析师是个例外。该角色充当业务和IT之间的中间功能。图3.2给出了这个角色的特征和职责的更多信息。

图 3.2 技术业务分析师

图 3.2 技术业务分析师

由于该角色位于业务和IT之间，技术业务分析师的工作是缓和双方之间的关系，并防止他们之间出现“越过围栏”的心态。这种双方没有相互理解和相互支持一起工作的心态往往是项目失败的根本原因。这类项目的特点是业务需求不明确，技术工件不符合业务需求，也不符合IT所理解的需求，以及由于未经测试或测试不完整（从业务角度）而导致的不可靠软件。通常情况下，双方会互相指责，而且双方都非常确信对方犯了错误。

这也是为什么Data Vault 2.0团队不建议将业务与IT角色分开的原因。取而代之的是，两组应该一起工作，每个角色都要关注自己的职责。如果可以的话，团队应该在同一地点工作以提高效率。重要的是在业务和IT以及每个角色之间建立一个协作级别和相互理解，以防止出现前一段中概述的情况。这是项目经理的责任，如果在项目过程中组开始相互分离，就需要持续的行动。

需要从业务方面建立的部分理解是，我需要一种方法，在为期两周的sprint冲刺中相对不受日常问题的影响而工作。操作中出现的问题必须安排在下一个sprint冲刺中。为了实现这一点，IT部门也必须改变他们的想法:他们的工作应该是让业务部门在没有IT部门参与的情况下自己解决一些(如果不是大部分的话)问题。这就是“托管式”自助业务智能(BI)发挥作用的地方。Data Vault 2.0标准为IT部门提供了指导方针，指导他们如何以业务用户可以自行使用的方式提供数据。这就需要将责任转移到业务上。例如，IT不应该负有修复企业数据仓库中的数据的责任，以弥补业务系统中的错误。业务部门有责任修复这些错误，以便IT部门通过数据仓库将数据传回业务部门，在那里他们可以应用业务规则将数据转换为信息。IT将利用这些知识使经常使用的信息集市规范化。

为了防止任何一方的中断，对系统需求的变更需要一个已建立的流程。图3.3显示了这个DataVault2.0需求变更沟通流程。

图 3.3 DataVault2.0需求变更沟通流程

图 3.3 DataVault2.0需求变更沟通流程

新的变更请求通常起源于项目的业务方面。IT需要评估风险和对当前生产系统的影响。这就是为什么变更请求从业务用户通过发起人（决定需求变更的优先级）通过技术业务分析员（帮助将业务需求转化为技术项）传输到负责调度的IT经理和项目经理。当IT完成风险评估后，它将此信息返回给业务部门，以便根据风险和影响评估，他们可以做出是否应该实现需求变更的最终决定。如果业务部门决定继续处理需求变更，IT部门将在下一个sprint冲刺中安排需求变更，这取决于业务部门之前的优先级安排。然后，他们负责新工件的开发和随后的交付。在业务人员测试了变更(除了开发测试)并验收变更之后，正式的落款将使IT部门从这个需求变更的更多职责中解脱出来。

当开发数据仓库系统的新版本时，开发团队使用与传统软件开发团队相同的方法。他们在开发过程的早期使用Alpha（内测）版本来测试新版本，Beta（公测）版本易于针对有限的业务受众和生产的Gamma（候选）版本进行测试。Alpha（内测）版本应该只影响技术团队成员直至技术业务分析师。

除了技术IT团队之外，在Alpha（内测）版本中通常有3到5个技术业务分析师。当IT部门向分析师发布新报告时，应该明确指出，这些报告不打算向业务部门分发，因为报告或多维立方体（数据集）中的信息可能是错误的，甚至是糟糕的。尽管如此，技术业务分析师还是会收到这些报告，以帮助他们发现这些错误或识别错误计算。在数据仓库项目的前两三个sprint冲刺之后，一个Alpha（内测）版本被分发给技术业务分析师是很常见的。

一旦新版本达到Beta（公测）状态，就会向更多的技术业务分析师、业务赞助商和选定的业务经理以及其他对新版本的功能有既得利益的用户显示该版本。

Beta（公测）版本已经经过IT和业务代表的彻底测试，不再包含任何明显的或已知的错误。然而，由于发布状态的性质，生成的报告仍然不适合流通。取而代之的是，有限的团队使用这些报告来识别开发和技术业务分析师到目前为止尚未识别的问题。如果有限的团队同意产品发布的准备工作，数据仓库系统将进入Gamma（候选）状态。

Gamma或生产版本被部署并提供给所有业务用户。这种方法密切遵循CMMI，它是Data Vault 2.0方法的一部分。后续文章介绍Data Vault 2.0方法的CMMI。