Monday, April 17, 2006

Digital preservation is more than what you think

This week, one of the topics being discussed in the class I'm teaching (IST 677 at Syracuse Univ.) is digital preservation. This is a topic that we all can understand and perhaps all feel a bit helpless about, especially when some of the things that mess us up are out of our control. For example, last week Microsoft issued critical updates to its PC software. As it turns out, one of the software patches (MS06-015) raised havoc with Hewlett-Packard hardware. An article published on Friday talked about. Fortunately, the article contained information on how to fix the problem (or at least what might work). And thankfully -- since I had installed the patch and was having very unusual MS Office problems -- the article helped me fix my system.

But what if it had been more serious? What if a digital library had installed a recommended software update that then incapacitated the library? We tend to think of digital preservation as being about preserving the files themselves, perhaps through refreshing or migrating them. But preserving also means ensuring that a third party knowingly or unknowingly does not harm the files or the system that accesses them.

Large data centers historically have tested software updated in test environments that are replications of their production environments. They test the software to ensure that it functions as promised and does not harm the system. This helps them ensure that their production systems are not damaged and that valuable data is not lost.

We tend to not be as strict with every update and every new piece of software. However, when our trusted software companies disseminate software that unintentionally harms our systems, we should begin to put in place the procedures to do like the "big boys" and test, test, test before we implement anything.


Technorati tag:

1 comment:

Anonymous said...

You make a very important point. I cut my teeth testing applications software on new versions of mainframe operating systems and spent many a weekend at work so that others would see a smooth upgrade. However even in relatively simple environments, it is impossible to test everything. This presents us with a considerable challenge as we will never (in engineering terms) be able to prove that some part of a Microsoft patchfest will not have a subtle (or not) effect. Maybe the answer is diversity of systems, something that I know the LOCKSS (www.lockss.org) folk are very keen to see in their world.