假设你是某公司的IT员工。你所在的公司面向中高端市场，有1000名左右的员工，有十二个分公司。你负责运行产品交易系统以及分布式的Windows原始信息库。你有大容量的SAN和文档服务器，有灾难恢复系统和原始信息库。
每个公司都有测试和改进的操作，大部分操作情况如下：
1）测试和改进是用来确保被大量生产之前，内部和外部软件应用、新的基础架构以及升级工作以假定状态正常运行。
2）为了执行步骤1，完成测试和改进过程，必须首先获得完整的当前实际数据，这些数据来自他们自身的生产系统。
3）为了执行步骤2，测试和改进过程非常复杂。这需要时间、计划，甚至需要祈祷运行过程中不出问题。应用软件通常会出问题，而数据库因此必然会停止运行；基础架构的专家旋转摇柄、按下按钮，数据库重新开始运行。
4）一旦完成了步骤2，事实上测试就可以开始了。通常，进行测试和改进需要增加附加数据设置（而这些设置在被采用的时候通常已经过时了）的复本以进行不同的测试。
现在我们来讨论刚才这些步骤中出现的低效问题。首先，产品系统最可能在数据库上端运行部分应用软件。你趋向于认为你的产品数据非常重要，因此你通常至少会创建两个数据复本。你趋向于将你的产品数据放在非常昂贵的，容量最大的，能耗很高的基础结构中。你在基础架构里创建数据，接着将这些数据存放其中。然后你会创建很多数据备份，将这些数据备份也存放在基础架构中。你可能有两个、三个、四个或者更多不同时间点或者相同时间点的相同数据复本。这意味着你存放这些数据的支出是只存放一份数据的二倍、三倍、四倍或更多倍，而这不仅仅是资金消耗的问题，也将导致能源、冷却系统消耗，追踪系统等等的消耗也随之提高。
当你创建测试复本时，你趋向于将这些复本创建之后也保存在产品系统中。有时你会删除这些数据，但有时这些数据会被存放很长时间。有时你甚至会完全忘记这些数据的存在。这些复本占据了很大空间，耗费了过多能量和人力。这些备份数据将会与目标导向的产品系统中其他数据一起被再次备份。这意味着在一次文件备份中，你可能会对23个相同的数据复本进行再次备份。如果你每周进行一次完整的数据备份，你将在以前23个相同数据备份的基础上继续创建新的数据备份。
事情已经变的很糟。不仅仅是数据复本众多而耗费了资金和人力，更严重的是众多分散的现实产品的数据??这些数据被存放在产品系统、测试系统、备份系统、灾难恢复系统中以及Iron Mountain的磁带中，这都会引发潜在安全性问题。
产品系统中存在着10或100个相同数据的复本并不是真正的问题，真正的问题在于由此带来的负面影响。冗繁的数据使得产品系统运行软件、数据库缓慢，用户读取速度也会减慢。你或许会通过购买更多的大容量高速硬盘来解决这一问题，而这些硬盘却经常处于闲置状态，占据了更大的空间并且导致了更多问题。冗余的数据会对其他流程也造成影响：比如网络堵塞，因此你需要增加带宽；会导致备份服务器宕机，因此你需要更先进的服务器，导致了支出的增加。产品系统供应商倒是很高兴看到这一状况。
很难让人明白应该采取的措施不是购买更多的设备，而是应该对导致当前问题的行为进行改变。专家建议这么做：
如果你按下述步骤去做，一切都将不同。仅仅将产品系统的测试和改进过程中设置的复本进行清理，就可以释放出大量空间，同时改善了绩效并使相关支出降低。负责测试和改进的工作人员应该有一个进行彻底数据清理的持续计划。随着这一计划的开展，负责安全的员工将很高兴地看到很多系统冗繁数据减少；负责备份系统的员工也会很高兴冗余数据不再影响系统的进程；负责财务的员工也将很开心，因为测试和改进基础结构的支出随着产品数据的减少而减少。在大型机器上运行应用软件和数据库的许可证费用很高，现在这一支出降到了最低，甚至不存在。
如果你这么做了，就会看到，不仅仅是产品系统的测试和改进过程中的备份数据可以进行清理，甚至产品数据本身也可进行清理。90%构成产品的数据是有确定内容的，这部分数据不可更改。现在这些数据不再是动态的，我们是否应该用和以前一样的方式对这些数据进行备份？我们是否还应该存有四个关键备份？我们难道不应该将这些数据放到某些基础架构里，这些基础架构具有更适应当前数据状态的属性。
如果数据没有改变，但是数据属性改变了，那么仍用相同的方法来处理问题是不合适的。如果以前访问频率很高的特定交易数据现在的访问量几乎为零，我们为什么不用我们处理测试和改进过程中备份数据的方法来处理这些数据呢？如果我们将这些数据从产品系统转移出去，却保持其逻辑空间（比如，在需要的时候我们仍然可以用相同的方式对这些数据进行访问，但是显示时间会变长）。接着，通过将我们的产品数据描述为“动态的”或者“静态的”，我们可以持续更改数据。静态数据有不同的生命周期，随着时间（或基准）的变化有不同属性需求。我们将这些数据移出层级1，这样就降低了费用，这也就意味着层级1的存储器可以始终处于最佳绩效水平。
从理论上说，如果你的动态??静态数据流是可估计的，你完全不需要为产品系统购买另一块硬盘或者对另一许可证进行升级。你不应该仅仅将数据移出花费最多的、任务导向的原始数据库，而应该在适当的时候改变数据的属性需求。比如，当数据为动态时，你可能有四个关键数据备份，每四小时将这些数据备份到目标磁盘，并且每八小时对这些数据进行复制。但是当数据变成静态的并转移到了静态环境，这一过程即可停止。或许你将保证我们有一个当地的复本，还有一个当地的网上复本，另有一个复本在灾难恢复网站上，并且还有三个复本存放在磁带上。接下来你再也不需要备份数据了，因为这还有什么意义？
如果你真的这么做了，就节约了25%以上用于能源和冷却系统的预算。你应该节约更多资金，甚至会影响每股的赢利。
