* How old data and code can live forever
How to preserve content in a useful fashion is a problem that intrigues many in library and academic IT. If you are storing a copy of some presentation to the Board related to the decision to, say, open a medical school, how do you preserve that material for posterity?
A PowerPoint file is not likely to be readable by current data systems in 20 years, let alone 50 or a hundred. A PDF might fare better – if someone keeps the reader technology alive that long. What about plain-text encoding, with instructions in the top to describe the contents? Just moving the problem back a layer, to ASCII or the like.
The problem is a real one for some businesses. It has been imposed from the outside for some. Some branches of pharmaceutical research are required to hold onto data permanently, for example.
Others have taken the burden on themselves, as Nemertes’ recent research on security and information protection reveals. A little more than 25% of participants in the research said it was now their company policy to retain all currently archived types of records forever. The reason here is fear of lawsuits, of course, rather than an interest in corporate history. The risks of failing to produce information when it is requested in court, even when there is not any regulatory or legal obligation to have saved it, are now deemed greater than the costs or risks of retaining it.
The only viable alternative up to now for keeping data readable has been to reformat it every few years. In an archival situation this would also mean moving it from time to time to from the medium-term storage format of choice when last reformatted to the current format of choice. That might mean 9-track tape to Qic, Qic to DAT, DAT to DLT, and so on. In fact, the medium can be harder to keep alive than the data formats stored on it – anyone still have a QIC drive to read a QIC tape with? A 5.5-inch floppy drive?
Virtualization technologies now offer new hope for the forever-ists. Now, it is possible to contemplate a system by which, rather than reformatting data files again and again, ad infinitum (with likely corruption or data loss always a threat), the data center folk would encapsulate the entire software environment needed to read the data, in the form of a virtual machine instance, and store that along with it. Have some important loan-processing business logic embedded in PowerBuilder apps on an ancient Windows NT 3.5 machine? Snapshot it, and be able to run it forever on whatever pool of host boxes you favor this year if you need to retrieve data.
Want to keep using that logic in production? The same idea is of course applicable (and has already been applied) to legacy applications. Rather than rewrite them for a new platform or architecture, make sure they can talk on TCP/IP if they don’t already, perhaps by giving them some new Web-services wrappers (or whatever your favorite flavor of abstraction is) and then encapsulate them in a virtual server and keep them alive until the application is no longer needed.
If the virtualization platform changes in either scenario (as they are certain to do) expect it to become possible for the old one to be virtualized to run under the new one – just another nesting doll, with some ancient COBOL code and a bunch of ISAM files full of EBCDIC data at the center.
Creating worlds within worlds will certainly help save data from loss, a boon to the archivists for sure, but will also promote the “let the old code be, build something new” philosophy of application development and could lead to archeological layering of dizzying complexity in a large enterprise’s (or government’s) software infrastructure.
I didn’t say this would always be a good thing, did I? What do you think?
