【核心议题】在数据生命周期管理实现过程中，与原有的存储数据分层或备份等方案是否冲突，如何匹配？

在很多情况下，规划跟不上需求，甚至是被需求倒逼着走。在某一阶段为解决特殊的问题而提出的解决方案，反而可能会对后面的整体规划带来不便。

在规划实施数据生命周期管理的时候，一定要从企业的实际情况出发。对企业现有的业务系统进行梳理和评估，比如在线数据、近线数据和归档数据分别对应的性能要求、可用性可靠性要求。然后再根据这些细分的需求去匹配存储。在基本目标和大框架制定的情况下，再结合自己的实际情况来做选择，能利用现有架构的方案优先考虑。
比如企业的IT软件和开发能力强劲，并且现有的架构已经成型，可以考虑在现有基础上深挖。比如可以在现有的数据库同步方案的基础上做分库，将生产的oltp类型数据库和基于olap类型的查询库分开。或者做基于etl的数据仓库等，都可以在用户原有的架构之上去规划实施。
如果用户的的技术实力较弱，或者属于软件开发外包类型的。也可以基于存储硬件来做实施。闪存存储、高端存储、高密度大容量存储、磁带存储等都可以匹配数据生命周期的各个阶段。存储架构中原有的分层存储、备份系统等都可以被整合到现有的解决方案中。比如如果原有的存储架构使用了tsm备份软件、gpfs文件系统。那么这两者在承载原有功能的同时，可以整合其他存储系统、利用gpfs的策略引擎、tsm hsm存储空间管理等功能，可以更好的实现用户需求。

最近两年刚好参与了两次大的企业信息系统升级，我的理解是，如果业务模块是整体升级，在这个过程中，是整理存储与数据的最佳时机，而如果是业务系统没有升级计划，只是平稳运行的话，那么存储的扩容、迭代，投入更多的人力、精力去优化是更好的选择

个人认为企业的核心数据，即保存在关系型数据库中的那些关键数据，这些系统应该保持平稳的发展脚步，逐步过渡逐步发展。而另外一些文件式存储业务系统，可以大踏步地向前走，直接革新采用一些新型的分布式存储技术以及NOSQL技术。

最安全稳定的方法就是逐步改造，直接重建对大多数企业都不太适合；挑最重要的，最急需改造的先做，然后在逐步对各系统依照重要性进行改造。