在这个阶段许多方法要求原型或试点项目。“7D法”不需要。至多，作为应用层的设计活动中的一部分，你可以做一个“点击模式”--一种输入/输出屏幕的快速呈现模型，不涉及或只有极少的代码但却能给利益攸关方可视化的概念，同时又不会吃掉宝贵的时间和资源。如果试点或原型是必要的，那么选择其中的一个切片(slice)作为试点，完成“7D法”的每一步。“7D法”不区分试点，原型和产品系统--它们都被视为项目。

如果按照“7D法”设计了一个原型，并且最终进入了产品(大多数原型都是这样)，然后您必须比第一个切片更仔细地选择第二个切片。如果这些切片不能成功地集成在一起，如果他们不支持您在发掘步骤发现的企业宗旨和意图，那么您在创建“烟囱”， 这是信息的群岛，整合彼此只会遇到困难，在某些情况下，甚至根本不可能.

第三步：开发

数据轨道开发步骤主要有两个部分：第一个涉及将数据模型映射到其对应的物理设计(实质是关系数据仓库和OLAP立方体的蓝图)，规划数据库的大小，必要时对表进行分块，为数据仓库对象设定命名约定以便业务用户和技术用户都能适应，并制定索引和识别索引候选名单的策略。第二部分涉及数据从外部数据源到数据仓库的提取转换加载(ETL)。包含在第二部分但不局限于这一部分的是数据转换服务( DTS )/SQL Server整合服务( SSIS)补丁的开发与测试，导入/导出和T-SQL脚本开发和测试，以及对外部数据源组件的数据整合测试，这些数据不会导入到数据仓库。

技术轨道的开发步骤包括审查，测试和选择产品，并提供其作品的体系结构设计。为了组成通信链路的各个层--物理层、数据链路层、网络层以及传输层，会话和表现层，这样做是必需的。虽然许多产品把多层无缝打包到一个解决方案，但有必要认识到这些层中的每一个在未来的负载要求和性能要求，并提前为这些需求作好准备。为了从新的数据仓库交付数据，您应该选定数据仓库的服务器和存储解决方案，以及新的，最终用户面临的硬件。这样做是为了产品数据仓库和分期数据库--DTS/SSIS软件包和T-SQL脚本在这里执行，从外部数据源导入数据，以及把可操作和精心料理的数据导入到关系数据仓库和OLAP立方体中。根据发掘阶段收集到的需求，您的数据仓库环境可能还要支持数据集市，快照，和报告数据库，因此，也要准备为这些方面考虑环境。

应用轨道开发步骤听起来很简单：只要开发终端用户应用程序。然而，这可能是整个过程中最复杂和费时的任务，并且可能是代价最高的--如果没有认真制定和考虑成功的度量标准。正是在这一阶段，范围蠕变(不断增加特性和功能，而不考虑对其他两个轨道的设计和开发的影响)可能像鱼雷一样破坏项目。除了开发终端用户应用程序，您也不得不制定测试这些应用程序的计划，您需要制定终端用户培训计划以便用户能学会如何使用这些应用软件。在每一个里程碑，你必须确保获得相关各方的签字或验收。

这可能听起来很明显，但多少令人惊讶的是不知道有多少开发项目是在产品环境中阶段化和测试的!别这样做，只是不要这样做!为开发，测试，和组件划分搭建一个单独的物理环境。对业务系统要这样做--同样，对BI/数据仓库也要这样做。

第四步：部署

部署数据仓库和部署交易数据库是不一样的，通常，您以一种快速、包罗万象的风格部署一个交易数据库-周五晚上终端用户在使用旧式系统，而周一上午他们登录到新的数据库。数据仓库通常是递增式地部署到整个企业的各类用户中。这种递增的速度和各个组使用数据仓库的次序是包含在部署阶段中部署计划的一部分。

理想的情况下，数据仓库的部署以一种迅速级联的层次进行，首先是技术就位--服务器，存储设备，通信链接等，系统软件的安装，测试并准备投入产品。然后是数据轨道各组件的展开--数据仓库数据库(关系型和OLAP )的建立，以及ETL进程的联机。在最终的应用层添加之前往往会打住一下，当您通过ETL进程让数据流从外部来源进入各种不同的数据仓库数据库和立方体时，进行必要的测试和调整。然后应用层被部署。您可能想要逐渐地部署应用层，因为企业内部的不同人员有不同的等级。

作为一个PM，你发挥着非常重要的作用。在你的指导和引导下，三个轨道将按预定计划到达部署阶段，避免数周数月的“误点”忧虑。一旦技术和数据轨道就绪并测试，并准备继续，那么开始展开应用层。没有用户界面( UI)的数据仓库对任何人都是没用的，而一个尺寸不足，弱工程系统架构的数据仓库会因性能太差而不会被企业用户采用。

第五步：每一天

日常业务运营的管理是非常重要的;而这常常在规划和开发过程中被忽视。你不仅必须确保定期(每日，每周等)进行维护，包括硬件和软件，还必须要不断监视所有系统的性能和增长。正如我一开始所说，数据仓库永远不会结束;随着越来越多的用户发现数据的内在价值，并创造新的，有时甚至是具有挑战性的方式来查询数据仓库，它会继续增长和扩大。有些PM的任务有时你必须准备承担，包括确保所有的系统(硬件，通信链路，系统软件)的全面运作，打最新的补丁和升级。当业务瓶颈出现时尽可能快地诊断和解决问题; 确保所有需要做备份的系统及时备份，实际上，有备份工作定义和计划，并要求所有的备份恢复测试，后续测试，开发，或报告数据库。

业务不是静止的，它们必须不断地改造自己，以保持竞争力。数据仓库数据管理员的职责就是跟踪数据的使用，评估数据的重要性，并检测业务什么时候开始需要转变。随着业务模式的变化，将会需要更新，更好，更灵活，可能更复杂的用户应用程序，数据管理员应该能感知到这些要求。有时，当业务方向和重点变化到了一定的程度，就需要重新进入发掘阶段，生命周期将回到原点。洗涤，漂洗，重复下去。

第六步：防护

捍卫你的数据仓库涉及的不仅仅是采取定期备份或确保没有任何应用程序包括SQL查询可能会开放给SQL注入式攻击。你必须计划整个范围和宽度的捍卫，因为数据仓库包含了企业最宝贵的资产--它的数据，以一种经过编译的，清理过的，以及(在某些情况下)信息化了的格式存在。

数据仓库的威胁通常分为两类，物理的和逻辑的。物理方面的威胁可以是外部的(龙卷风，洪水，火灾，地震)或内部(有意的，偶然的)。您可以防止来自物理方面威胁的做法既可以是采用简单的限制访问计算机和通信室，也可以如位于地理上相距甚远的容错站点上的镜像服务器般复杂(且昂贵)。物理防御取决于您的恢复时间和恢复点目标，也就是多少时间你的数据仓库离线你可以忍受和多少数据丢失你可以承担。