逻辑威胁要复杂得多，仅仅因为数据仓库环境的自然特性。操作系统可能会失败，数据库管理系统可能会崩溃，一个或多个应用程序可能有意无意损坏、销毁、误解数据(尤其出现在承担数据仓库给养任务的ETL过程中)。浏览器的用户界面已经把嵌入式SQL调用暴露给了SQL注入式攻击。每一个潜在的威胁都必须查明和处理; 在威胁发生之前制定补救措施要比它们发生之后好得多。PM的工作是为您的整个数据仓库安装制定一个全面的防御。如果你足够幸运有一个安全管理员，利用此人的专长和经验。

第七步：退役

可能有一天当数据仓库，或一个组件部分(分期数据库，数据集市，报告数据库，立方体)不再符合要求，解除它的时间就到了。并非每一个数据库都可以不断重构或升级，以满足新的要求。有时候，你仅仅是需要丢弃和重建，特别是如果数据库实例是“规范建立的”，即没有适当的架构充分反映企业的目标和意图。在这种情况下，作为PM，你必须同步进程。

一般来说，退役步骤以如下三种方式之一发生：没有更换的退役;移交式退役;和逐步到位/逐步淘汰的退役。“没有更换的退役”是指数据库用来执行的功能不再需要。不仅是数据库退休了，在它之上的执行功能也退休了。 “移交式退役”表明另一个数据库将取代退役的数据库，并且其对应的执行功能也将从旧的数据库迅速转移到新的。某一天，用户可能访问旧的数据库，而第二天他们将访问新的。“逐步到位/逐步淘汰的退役”表明旧的和新的数据库将并存运行一段时间，而功能和用户逐步从旧的转移到新的，直到最后再也没有用户或功能运行旧的数据库时，它就可以退役了。每个方案都有其风险和回报;作为PM你必须确定何时风险大于收益，确定哪种计划最适合您的情况。然后你必须与技术轨道和应用轨道的其他人员协同工作，计划和执行，以确保无缝转换。

良性循环

在您与这些数据仓库的各个组件打交道的过程中，随后将会有新一轮的发现，这期间你会评估随着时间而发展的新需求。发生这种情况可能来自从存储在数据仓库中的数据收集到的信息。这些新的要求可能会导致扩大增强一个或多个轨道的设计和解决方案。您需要将这些变化反映到现有的数据仓库中，这样您就可以部署更新、更好的、用户渴望利用的解决方案。为保持数据仓库像不可思议的机器一样运行，一些新的要求可能会导致日常运作的变化。

随着时间的推移，生命周期的多次迭代过程会导致数据仓库紧密联系于企业结构，直到数据仓库和业务成为无缝的整体。对于这一难题，PM的职责是确保所有活动和任务都是按照规范进行，被既定的成功指标接受，并被同步部署。即使您的数据仓库项目没有正式的PM，即使你是人力资源唯一列在这个项目上的人员，你仍然应该做一些PM会做的计划，并及时更新。然后，当管理层问：“数据仓库项目进展如何了?”你可以告诉他们项目目前处在什么阶段和已经干了些什么工作。