German 
English 
Durch die Archivierung einer Datenbank bleibt die Anwendung, die die Datenbank erst nutzbar gemacht hat, nicht erhalten.
SIARD ist ein guter Ausgangspunkt. Es bietet ein offenes, softwareunabhängiges Format zur Erhaltung der Struktur und des Inhalts relationaler Datenbanken. Es verringert die Abhängigkeit von proprietären Datenbank-Dump-Formaten und unterstützt – mit geeigneten SIARD-kompatiblen Werkzeugen – bei Bedarf die Übertragung archivierter Daten in eine relationale Datenbank.
Das ist wertvoll. Es ist jedoch nur ein Teil des Problems im Zusammenhang mit der Stilllegung von Anwendungen.
Sobald das ursprüngliche System abgeschaltet ist, bitten zukünftige Nutzer nur noch selten darum, eine Tabelle einzusehen. Sie müssen einen Fall ausfindig machen, eine Rechnung nachvollziehen, die mit einem Laborergebnis verknüpften Dokumente abrufen oder die einer Entscheidung zugrunde liegenden Beweise rekonstruieren.
Ein bloßer Datenbankexport allein vermittelt ihnen diese Erfahrung nicht.
Was SIARD gut bewahrt
SIARD wurde für die langfristige Archivierung relationaler Datenbanken entwickelt. Das System erfasst Datenbankinhalte und strukturelle Metadaten in einem ZIP64-Container, wobei XML und XML-Schema zum Einsatz kommen und SQL-Standards für Identifikatoren und Datentypen herangezogen werden.
Dadurch eignet sich SIARD sowohl als Archivierungsformat als auch als Ausgabformat. Es kann Organisationen dabei helfen, Daten zu bewahren, ohne die ursprüngliche Datenbanksoftware auf unbestimmte Zeit weiter betreiben zu müssen.
Das Schweizer Bundesarchiv weist zudem auf eine wichtige Einschränkung hin: Eine SIARD-Datei ist in der Regel nicht aussagekräftig genug, um zu gewährleisten, dass die archivierten Daten auch in Zukunft interpretierbar bleiben. Daher muss möglicherweise begleitende Dokumentation zum Quellsystem und zum Datenmodell aufbewahrt werden, darunter Datenbeschreibungen, Codelisten, Systemspezifikationen, Benutzerhandbücher und Screenshots.
Genau hier kommt es auf diese Unterscheidung an.
SIARD bewahrt den Inhalt und die Struktur einer relationalen Datenbank innerhalb des definierten Geltungsbereichs des Formats. Bei der Stilllegung einer Anwendung müssen die Informationen erhalten bleiben, die die Nutzer weiterhin benötigen.
Die Lücke entsteht, wenn jemand die Daten erneut benötigt
Nachdem eine Rohdatenbank archiviert wurde, ist für den Zugriff weiterhin ein technischer Umweg erforderlich. Man benötigt ein Anzeigeprogramm, ein neues Frontend oder eine Datenbank, in die die Daten geladen werden können.
Selbst in diesem Fall werden dem Benutzer möglicherweise Tabellen- und Spaltennamen angezeigt, anstatt der Geschäftsobjekte, die in der Anwendung vorhanden waren.
Die fehlende Ebene kann Folgendes umfassen:
- Die Beziehung zwischen einem Fall und seinen Unterlagen;
- Der Kopfbereich, die Zeilen und die Anlagen, die zusammen eine Rechnung bilden;
- Bezeichnungen, Codelisten und Definitionen, die zur Interpretation der berechneten Werte erforderlich sind;
- Dokumentation relevanter Arbeitsabläufe und Geschäftsregeln;
- Der Kontext, in dem ein Ergebnis entstanden ist;
- Die Suchpfade, auf die sich die Nutzer verlassen haben;
- Die Zugriffsanforderungen, der Prüfungskontext und die Aufbewahrungsvorschriften, die weiterhin gelten müssen.
Je spezialisierter die Quellanwendung ist, desto größer kann diese Lücke werden. ERP-, Labor- und Gerätesysteme sind naheliegende Beispiele, doch dies gilt für nahezu jede Lösung mit einem komplexen Datenmodell. Die Daten mögen zwar technisch weiterhin vorhanden sein, lassen sich jedoch ohne den umgebenden Kontext, die Beziehungen und lesbare Darstellungen nur schwer interpretieren.
Beginnen Sie mit dem Geschäftsobjekt, nicht mit der Tabelle
Ein umfassenderer Ansatz zur Stilllegung von Anwendungen beginnt mit der Frage, welche Daten die Benutzer nach der Stilllegung des Systems noch abrufen müssen.
Bei einer Finanzanwendung kann es sich um eine Rechnung mit ihren Einzelposten und Anhängen handeln. Im Fallmanagement kann es sich um eine vollständige Akte handeln. Bei einem Laborsystem kann es sich um ein Untersuchungsergebnis handeln, zusammen mit Angaben zum Gerät, zum Laboranten, zur Methode, zum Datum sowie den zugehörigen Dateien, die zum Verständnis des Ergebnisses erforderlich sind.
Das sind Geschäftsobjekte. Ihre Struktur lässt sich selten eins zu eins auf eine einzelne Datenbanktabelle abbilden.
Bei einer Docbyte Vault-Lösung zur Stilllegung von Anwendungen werden die Quelldaten analysiert und um diese Geschäftsobjekte herum zusammengestellt. Relevante Daten, Metadaten und Dateien können anschließend für die kontrollierte Übernahme in das Archiv gebündelt werden. Das Archivierungsschema definiert die Struktur des Objekts, während eine lesbare Ansicht künftigen Nutzern die Interpretation erleichtert, ohne dass die stillgelegte Anwendung neu erstellt werden muss.
Dies bedeutet jedoch nicht, dass SIARD irrelevant ist. Ein SIARD-Export oder ein nativer Datenbank-Dump kann nach wie vor eine nützliche Quelle oder Komponente der Datenarchivierung sein. Der Unterschied besteht darin, dass dies nicht als fertiges Benutzererlebnis betrachtet wird.
Sichern Sie sowohl den Zugang als auch die Inhalte
Das Archiv muss zudem einen praktischen Weg zurück zu den Informationen bieten.
Vault Explorer bietet autorisierten Benutzern eine übersichtliche Benutzeroberfläche zum Suchen, Durchsuchen und Anzeigen archivierter Inhalte. Mithilfe von Suchkonfigurationen können die Felder, Filter und Ergebnisspalten angezeigt werden, die für eine bestimmte Benutzergruppe von Bedeutung sind. Verknüpfte Suchvorgänge können verwandte Objekte miteinander verbinden, sodass Sie beispielsweise von einem Fall zu dessen Dokumenten oder von einem übergeordneten Datensatz zu zugehörigen Elementen wechseln können.
Der Viewer trennt Metadaten, Vorschau und verfügbare Darstellungen voneinander. Die Nutzer können somit den Kontext des Datensatzes einsehen, lesbare Inhalte prüfen und auf die archivierten Formate zugreifen, ohne direkt mit Datenbanktabellen arbeiten zu müssen.
Dies ist der operative Unterschied zwischen der Aufbewahrung von Daten und der verantwortungsvollen Stilllegung einer Anwendung.
Fünf Fragen, die Sie sich stellen sollten, bevor Sie das Quellsystem außer Betrieb nehmen
Bevor Sie einen Datenbankexport als Lösung für die Stilllegung akzeptieren, sollten Sie sich folgende Frage stellen:
- Welche Geschäftsobjekte müssen die Nutzer später abrufen können?
- Bleiben ihre Beziehungen und Bindungen zu ihnen erhalten?
- Werden die Nutzer die Felder, Codes und den Kontext auch ohne die ursprüngliche Anwendung verstehen?
- Gibt es eine übersichtliche und strukturierte Möglichkeit, die Datensätze zu durchsuchen, zu durchstöbern und anzuzeigen?
- Kann die Organisation nach der Abschaltung die Vollständigkeit, Integrität, Aufbewahrung und den kontrollierten Zugriff nachweisen?
Sollte die Beantwortung dieser Fragen davon abhängen, dass die Quellanwendung zu einem späteren Zeitpunkt neu erstellt werden muss, ist das Auslaufkonzept unvollständig.
SIARD ist eine Komponente, nicht die gesamte Lösung
SIARD löst ein echtes Problem im Bereich der Datenarchivierung. Es bietet einen offenen Weg weg von proprietären relationalen Datenbankformaten und trägt dazu bei, dass Datenbankinhalte auch über die Lebensdauer der ursprünglichen Software hinaus verfügbar bleiben.
Ein Archiv für ausgemusterte Anwendungen muss jedoch mehr leisten, als nur Tabellen aufzubewahren.
Es muss die Bedeutung, die Zusammenhänge, die lesbaren Darstellungen und den praktischen Zugriff gewährleisten. Es muss künftigen Nutzern ermöglichen, vollständige Datensätze zu finden und zu verstehen, was sie vor sich sehen. Außerdem muss es die Kontrollmechanismen und Nachweise bewahren, die erforderlich sind, um diese Datensätze im Laufe der Zeit zu verwalten.
Die Frage lautet daher nicht lediglich, ob die Datenbank archiviert wurde.
Die bessere Frage lautet: Wenn jemand diese Informationen in fünf oder zehn Jahren benötigt, was genau wird er dann abrufen, verstehen und nachweisen können?
