In previous post, I’ve shared my belief that we’re heading for another Y2K-type inflection point in enterprise software.
But this time, it’s not a false alarm borne of our own ignorance of what lies within our software. Today, we know exactly 
what’s in our software: volumes and volumes of data. What we don’t know is how to extract and store this data in ways that meet our business, regulatory, and legal needs – and that’s what will hurt us.
To put it bluntly, the methods we’ve used up until now haven’t worked.
WHY TAPE BACKUPS ONLY GO SO FAR
For years, most companies have taken an “only when we absolutely have to” approach to archiving data. When an application reaches the end of its useful life, the typical company will decide to retire it – and then realize they need to do something with the data it holds.
The simple solution? Tape backups. Companies often write entire applications off to tapes and stick the tapes in a vault. The idea is that if they ever need to access the application again, it will be easy enough to restore it from the tapes.
This approach is easy to incorporate into a company’s regular tape backup process. It
also offers some degree of security, because tapes are generally stored offsite.
Although this approach works well in theory, it creates some challenges and little time bombs.
For example, consider the half-life of knowledge in most organizations. As employees retire, quit, or are laid off, they take valuable technical knowledge with them.
Within a few years after an application is retired, it’s possible that all of the employees responsible for maintaining that application will have left the company. What will happen, then, when a lawsuit arises that requires IT to bring the application back online and extract reports from a certain time period?
In a best-case scenario, the company will scramble to find a consultant who has the specialized skills they need. In a worst-case scenario, they won’t even be able to find the right tapes in their vault.
I think we can all agree that it’s time for a new approach to archiving data.
Thanks in large part to the flurry of implementations just before Y2K, we’re emerging from more than a decade of rapid application uptake. Staggering amounts of data have been computerized. This is good.
But many of those applications are now nearing retirement. Meanwhile, even organizations that aren’t retiring applications are focusing more than ever on archiving data from their production applications. There’s also an encouraging trend towards data governance, and towards managing all data with a lifecycle concept. Doing so helps companies meet regulatory requirements such as Sarbanes-Oxley.
All of these trends point to one inescapable fact: archiving data can no longer be an ad hoc process that’s driven only by the need to retire applications. It should be a structured, formalized, ongoing process that fits into any corporation’s usual business workflows.
It should also revolve around a corporate repository.
THE CORPORATE REPOSITORY DEFINED
What exactly is a corporate repository? I’ll admit that the term could have different meanings to different organizations. In fairness, some companies might even argue that their tape vault is their corporate repository. So, allow me to define my terms.
- A corporate repository is the default storage location for archived and retired data. It should provide:
- A common platform for archiving data.
- A common structure for storing data.
- A common way to retrieve data.
- Common tools for managing data, including backups and purging.
Think of the problems such a repository would solve. There would be no more wondering what happened to that application you retired four years ago – its data must be in the repository. And once you found the data, you wouldn’t have to wonder how to access it. You would simply use your common data management tools, with which everyone in IT would be familiar.
Companies that put a corporate repository in place can gracefully retire any application, regardless of what platform it’s on or what format its data is in. More significantly, they will have archived the application’s data regularly up to that point, eliminating the need to scramble when the retirement date approaches.
WHERE TO GO FROM HERE
Most of what I’ve written above may not apply to small businesses. But midsized and large companies should take heed – especially if mergers and acquisitions have left them with many superfluous applications. In my upcoming posts, we’ll discuss how the concept of a corporate repository can enhance application retirement, data governance, and data storage.
