IT-Archivierung: Mission erfüllt?

Quelle: Wikipedia

In diesem Blog-Beitrag verwende ich absichtlich den Begriff IT-Archivierung und nicht etwa elektronische Archivierung. Es geht mir nämlich um sämtliche Aspekte der Archivierung was die IT betrifft – und da geht es auch um physische Archivierung. Deshalb gefällt mir persönlich der Begriff elektronische Archivierung nicht besonders gut. Als erstes möchte ich kurz eine Übersicht geben, welche Objekte potentiell archiviert werden müssen. Dabei habe ich keinen Anspruch auf Vollständigkeit der Liste:

Entstehung in der IT ...
Anwendungsdaten (aus funktionalen Anforderungen)
System-/technische Daten (aus nicht funktionalen Anforderungen)
Software (ausführbarer Code inkl. benötigte Ressourcen)

Entstehung ausserhalb der IT, Archivierung mittels IT ...
Geschäftskorrespondenz
Geschäftsabschlüsse
Verträge

Hardware zum späteren Anzeigen ...
Rechner (Server/PC)
Anzeige- und Bedienperipherie (Tastatur, Maus, Bildschirm u.a.)
Laufwerke (CD-ROM, Festplatten etc.)


Herausforderungen im Detail

Anwendungsdaten
Anwendungsdaten können sehr vielseitig sein. Typische (Schul-) Beispiele sind etwa Kunde (Name, Vorname, Geburtsdatum etc.), Kundenadressen, Bestellungen, Rechnungen und Artikel etc. Oftmals werden solche Daten in Datenbanken gespeichert und die optimale Archivierung von Daten in Datenbanken ist alles andere als einfach. Welche Daten müssen per wann archiviert werden? Und vor allem, wie kann man diese später wieder in einem sinnvollen Kontext anzeigen? Projekte zur gesetzes konfromen Archivierung von Anwendungsdaten (insbesondere in Datenbanken) sind aufwändig in der Planung und sollten nicht unterschätzt werden. Vor allem Aspekte wie das Suchen und Wiederfinden sowie anzeigen von solchen Daten sind anspruchsvoll in der Umsetzung. Vor allem dann, wenn man aus Gründen des Datenvolumens nicht immer die ganze Datenbank archivieren kann oder auch wichtig aus Sicht Compliance, nicht die ganze Datenbanken archivieren darf.

System-/technische Daten
Zu diesen Daten zählen Informationen aus Log-Einträgen, Informationen zur Verfügbarkeit, Informationen zu Verbindungen (Protokolle etc.) sowie zur Security (Benutzeranmeldungen, Benutzen von Objekten etc.). Für diese Kategorie gibt es zwei Herausforderungen: 1) Identifikation der Daten, welche eine Software (ein Software-System) überhaupt speichert und 2) Automatische Erschliessung von allen relevanten Daten. Aber auch hier ist der Aspekt der späteren Lesbarkeit in sinnvollem Kontext nicht selten eine Herausforderung.

Software
Zu dieser Kategorie von Informationen die potenziell archiviert werden müssen, zählen zum einen die Software, welche Daten erstellt, erstellt hat und zum anderen Software, mit welche die archivierte Software wieder in sinnvollem Kontext angezeigt werden kann. Das kann dieselbe sein wie die Daten erstellende, es kann aber auch eine Software eigens für diesen Zweck sein. Die Herausforderung besteht darin, dass man eine Lauffähige Umgebung mit allen Ressourcen archiviert. Nur einfach die Installations-CD in ein Archivregal stellen reicht nicht. Zum einen hat man die Software nach der Installation parametrisiert und zum anderen braucht man auch ein Betriebssystem, um diese laufen zu lassen. Auch dieses muss archiviert sein, damit die Software Jahre später auch noch ausgeführt werden kann.

Entstehung ausserhalb der IT
Hier sind es vorwiegend digitalisierte Informationen (bspw. mittels Scanner) wie Briefe, Rechnungen, Unterzeichnete Geschäftsabschlüsse, Unterzeichnete Berichte und Meldungen etc. Die Herausforderung sind hier aus meiner Erfahrung am kleinsten und es gibt am meisten Standardlösungen für solche Aufgaben. Es werden einzelne Objekte (meist Dateien) mit ID in einem Format wie PDF/A oder Tiff erstellt. Diese werden zusammen mit einem Index mit Metadaten in einer Archvierungslösung archiviert.

Hardware
Hier geht es darum, dass jene Hardware archiviert wird, welche zum späteren Anzeigen von archivierten Daten gebraucht wird. Die Herausforderungen besteht hier vor allem im Konzept, wann welche Hardware separat funktionsfähig beiseite gestellt (archiviert) werden muss. Es braucht natürlich nicht für jede Anwendung einen eigenen Server im Archiv. Sobald es aber einen Medienbruch gibt,oder andere Einflussfaktoren ändern, muss für die Legacy-Archive entsprechend Hardware „archiviert „ werden, damit die Daten eben auch Jahre später noch gelesen werden können.


Qualitätskontrollen / Lesetests
 
Es ist unerlässlich, dass in bestimmten zeitlichen Abständen getestet wird, ob definierte archivierte Objekte mit den archivierten Ressourcen noch gelesen werden können.


Geeignete Medien / Infrastruktur
 
Es sind längst nicht alle Speichermedien geeignet oder zulässig zum Archivieren von elektronischen Daten. Billige CD-R beispielsweise sind mit weniger als 10 Jahren nicht mehr (zuverlässig) lesbar. Nebst einmal beschreibbaren optischen Datenträgern (zum Beispiel CD-R) kommen zur konformen Archivierung vor allem WORM (True-/Soft- und Hardware WORM) zum Einsatz. Diese sind jedoch relativ kostspielig und ein gutes Archivierungskonzept zur Reduktion der Datenmenge lohnt sich nach wie vor (auch aus anderen Gründen als den Speicherkosten).


Erfahrungen und Konklusion
 
Meine Erfahrung aus verschiedenen Projekten zeigt, dass die Mission IT-Archivierung alles andere als erfüllt ist. Am besten umgesetzt sind elektronische Archivsysteme, welche meist externe Dokumente als zuweisbare Objekte archivieren. Grosse Lücken gibt es hingegen, bei den meisten anderen Arten von Informationen. Beispielsweise alte Adressen. Häufig sind diese noch im produktiven System, aber eben nicht korrekt archiviert. Noch grösser ist meines Erachtens die Lücke beim Archivieren von verwendeter Software, respektive Software, mit welcher Archivierte Informationen angezeigt werden kann. Ebenfalls dazu gehört die ganze Hardware, damit die Software und somit die Daten später verwendet werden können. Die ganze Datenaufbewahrung, zu welcher auch die Datenarchivierung gehört, ist organisatorisch ein Problem, welches in vielen Unternehmungen noch nicht genügend gelöst worden ist. Es versteht sich von selbst, dass ich hier kein Menetekel an die Wand schreiben will. Dennoch darf das Risiko nicht unterschätzt werden. Ich empfehle auf jeden Fall, diese Risikokategorie im Rahmen von ORM auf dem Radar zu behalten und allenfalls geeignete Massnahmen einzuleiten. Sonst läuft man Gefahr, dass Unternehmensdaten  verloren gehen.

Wie sieht das Archivierungskonzept für Anwendungsdaten und Software bei Ihnen aus? Wann führen Sie Lesetests aus? Dies sind Fragen, welche auch Compliance interessieren müssen.