Keep it All or Slice and Dice?
Easiest post on this site.
Back in the 80s data storage was at a premium, particularly in mainframes. I remember thinking that the 160MB hard disk in my new computer was absurd and that I’d never fill it – now a single video file can be 10 times that size and can be easily accomodated on all your devices.
This massive reduction in the cost of storing data simplifies the decision process on whether to archive an entire application or only parts of it.
Dissecting an application is a complex and potentially risky process that requires:
- Business insight on what data is required and what can be disposed of
- Technical analysis to map the retained/disposed data onto the database
- Technical analysis to understand the reference data required to support the retained data
- Documentation of the decisions and analysis
- Test plans, scripts and runs demonstrating that the data retained is accurate and complete
All of the above takes time and money, and still carries the risk that a mistake is made and required data is purged or impared due to reference data being purged. And even if the process is completed without error the decision to slice and dice could still be used in court by an opposing lawyer to give the perception that required data was purged.
Bottom line – data storage costs aren’t a good reason to purge part of an application being archived.
Should Applications Ever Be Dissected Before Archiving?
There are potentially valid business reasons why a dissection is appropriate. These include:
- Removing data for business entities or products that have been sold and cannot be retained long term.
- Removing data that is beyond data retention and could represent a future liability.
- Removing data that needs or soon will need to be removed for Data Privacy reasons.
Conclusion
Unless there are very unusual circumstances keep it simple. Data storage costs are far cheaper than the cost and risk of analyzing, documenting, performing and testing an application dissection.
