Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

18.02.2000 - 

Dokumenten-Management/Es trifft jeden DMS-Betreiber

Tipps zur Migration von elektronischen Archiven

18.02.2000
Nichts fürchtet der Betreiber von elektronischen Dokumentenarchiven mehr als den Wechsel seines Systems. Gerade das abgelaufene Jahr 1999 hat aufgrund der Jahr-2000-Problematik so viele Migrationen erfordert wie nie zuvor. Eines ist klar: Alle Betreiber von Archivsystemen werden früher oder später wechseln müssen. Volker Halstenbach* beleuchtet die Probleme und gibt Empfehlungen, wie Anwender Aufwand und Risiken mindern können.

Keine Migration kommt völlig unerwartet, und doch finden viele unter einem großen Zeitdruck statt: Häufig versäumen es die Anbieter, ihre Anwender frühzeitig zum System- oder Komponentenwechsel aufzufordern. Diese arbeiten dann mit teilweise veralteten Systemen, deren Ende bereits absehbar ist und für die in einigen Fällen kein vernünftiger Support mehr gewährleistet werden kann - sei es wegen fehlender Ersatzteile oder weil die Servicetechniker nicht mehr das notwendige Know-how zur Betreuung besitzen. Daneben scheuen sich viele Betreiber eines funktionierenden Dokumenten-Management-Systems (DMS), quasi freiwillig eine Aktualisierung ihrer Lösung durchzuführen, getreu dem Motto: "Never touch a running System".

Mechanische Komponenten sind häufig einer hohen Beanspruchung ausgesetzt und haben eine auf die Nutzung ausgerichtete Lebensdauer. Bei Plattenbibliotheken (Jukeboxen) etwa orientiert sich dies an einer Maximalzahl der Armbewegungen, mit denen das System optische Platten vom Stellplatz zum Schreib-/Leselaufwerk und zurückführt. Ein internes Zählwerk überwacht die Bewegungen, ähnlich dem Zählwerk in Bürokopierern. Wird die definierte Maximalzahl überschritten, beschränkt der Anbieter nicht selten seine Serviceverpflichtung und drängt auf die Anschaffung eines neuen Geräts.

Neben rein technischen Gründen sprechen aber auch häufig kaufmännische Argumente für den Wechsel - vor allem von Komponenten. Spätestens nach Ablauf der Abschreibungsfrist sollten die betriebenen Komponenten unter Kostengesichtspunkten untersucht werden. Die Ausgaben für Neugeräte können niedriger ausfallen als die Wartungskosten der alten.

Die Garantien einiger Hersteller von Worm-Platten (Write Once Read Multiple) für eine Lebensdauer der Medien im Bereich von 30 oder inzwischen sogar von 100 Jahren sind vor diesem Hintergrund fast wertlos. In der Realität wird eine Jukebox selten länger als sechs Jahre betrieben. Innerhalb der vergangenen sechs Jahre hat sich jedoch die Worm-Technologie um drei Generationen weiterentwickelt: von 0,6 GB bis derzeit 5,2 GB pro MO-Platte (Magneto Optical).

Die Laufwerke der neuen Jukeboxen können die alten Formate zwar noch lesen, aber nur noch beschränkt schreiben. Mit dem Wechsel auf die neue Jukebox kopieren die meisten Anwender jedoch ihre Dokumentenbestände auf die neuen Platten, um Stellplätze in der Jukebox einzusparen.

Weniger offensichtlich als technische oder kaufmännische Gründe - und gerade für den Anwender schlechter absehbar - erfordern Veränderungen und Erweiterungen in der DMS-Software eine Migration. Migrationszwänge ergeben sich momentan häufig auch durch die regelrechten Übernahmeschlachten der DMS-Anbieter, denn nur wenige Hersteller können es sich dauerhaft leisten, die Programme mehrerer Systeme parallel zu pflegen und weiterzuentwickeln. Im Anschluss an die Übernahme werden die Produkte konsolidiert, und die laufenden Lösungen müssen auf die neue Plattform migriert werden.

Noch schlechter sieht es für den Anwender aus, wenn sein Anbieter den DMS-Markt verlässt oder sein Produkt nicht weiterentwickelt. Gerade der Jahr-2000-Wechsel hat auf diese Weise einigen Altsystemen den Todesstoß versetzt. Schließlich kann auch die strategische Neuausrichtung des Anwenders zu einem Systemwechsel führen, wenn zum Beispiel ein Wechsel der Server-Plattform von Unix auf Windows NT beschlossen wird, der dann auch die DMS-Umgebung erfasst.

Dabei sind Systemwechsel mit einigen Risiken verbunden. Sorgfältige Kopier- und Konsolidierungsprozesse in Verbindung mit Protokoll- und Prüfprozessen müssen sicherstellen, dass kein unkontrollierter Verlust von Dokumenten stattfindet. Dabei sind die gesetzlich vorgeschriebenen und die hausintern gesetzten Aufbewahrungsfristen zu beachten.

Aber auch wenn alle Dokumente erfolgreich auf die optischen Platten des neuen DMS migriert wurden, kann es vorkommen, dass sich einzelne Dokumente mit der neuen Anzeigesoftware nicht darstellen lassen. Gründe hierfür sind zum Beispiel ein selten anzutreffendes beziehungsweise proprietäres Datenformat oder dass die neue Anzeigefunktion einfach nur eine geringere Menge von Dokumentenformaten unterstützt. Nicht zuletzt birgt gerade der Systemwechsel - insbesondere im Zusammenhang mit einem Plattformwechsel - die Gefahr technischer Risiken in Form von Instabilitäten (Systemausfällen) und Performanceverlusten.

Die Grenze zwischen der Komponenten- und der Systemmigration verläuft fließend: Bei der Komponentenmigration werden nur Teile des Systems (Jukeboxen, Server, Datenbanken etc.) gegen neue Elemente getauscht. Bei der Systemmigration sind zumindest die Systemsoftware und der komplette Datenbestand betroffen. Während Systemmigrationen im Idealfall nur in dekadischen Zeitabständen erforderlich werden, ist bereits ab einem DMS-Alter von rund drei Jahren mit Komponentenwechseln zu rechnen.

Unabhängig davon, um welche Art von Migration es sich handelt, muss das DMS in den meisten Fällen trotz der wechselbedingten Zusatzbelastung stabil und performant zur Verfügung stehen. Im Rahmen jeglicher Migration sind dabei grundsätzlich zwei Problemkreise zu berücksichtigen: die DMS-internen und die DMS-externen Auswirkungen.

DMS-intern sind vor allem die Schnittstellen und die gespeicherten Objektdaten zu beachten. Die internen Schnittstellen sorgen dafür, dass alle Archivsystemkomponenten verlässlich miteinander kommunizieren und ein stabiles Gesamtsystem ergeben. Hierbei handelt es sich um Software-Schnittstellen wie Datenbanken und Gerätetreiber sowie um Hardware-Schnittstellen wie Anschlüsse und Kartenerweiterungen.

Daneben müssen die gespeicherten Dokumente im Vorfeld einer Migration umfassend untersucht werden. Hierbei ist zunächst eine Liste aller im DMS vorliegenden Objektformate zu erstellen. So kennt selbst das in jedem DMS für gescannte Dokumente verwendete und scheinbar standardisierte Tagged Image File Format (TIFF) neben unterschiedlichen Kompressionsstufen zahlreiche Varianten, so etwa bezüglich der Auflösung oder der Frage, ob alle Dokumentenseiten in einer einzigen TIF-Datei untergebracht sind (Multi-Page-TIF) oder getrennt gespeichert wurden (Single-Page-TIF). Für großformatige Dokumente (DIN A0) wird außerdem häufig ein "gekacheltes" TIF-Format (Tiled TIF) verwendet, bei dem die gesamte Zeichnung in kleine Rechtecke aufgeteilt wird; die Anzeigefunktion muss dann immer nur einzelne Kacheln dekomprimieren, was Rechnerressourcen spart und die Anzeigegeschwindigkeit steigert. Die meisten DMS verwalten neben gescannten Dokumenten weitere Objekttypen. Vom Umfang her überwiegen sogar die per Cold (Computer Output On Laserdisk) übernommenen Objekte deutlich die Zahl der gescannten Dokumente. Gerade Cold-Objekte besitzen häufig eine komplexe Dokumentenstruktur, die zwischen Inhaltsdaten (zum Beispiel Rechnungsdaten) und Formulardaten (Ressourcen) unterscheidet. Während die Ressourcen (Firmenlogo, Dokumentenlayout, Fonts etc.) möglichst platzsparend einmalig im DMS gespeichert werden, müssen die Inhaltsdaten pro Dokument abgelegt und verwaltet werden. Das Dokument wird DMS-intern mit den zugehörigen Ressourcen verknüpft, damit bei einer nachträglichen Dokumentenanzeige und beim Ausdruck das gleiche Dokument entsteht, das ursprünglich gedruckt wurde. Der korrekten Versionsverwaltung der verknüpften Ressourcen fällt dabei eine entscheidende Rolle zu, sie muss ebenfalls sauber migriert werden.

Da Cold-Dokumente typischerweise im Druckprozess entstehen, werden diese häufig im verwendeten Druckdatenformat (AFP, Xerox Metacode, HPGL, PCL-5 etc.) gespeichert. Genau wie jeder einzelne Drucker nur bestimmte Druckdatenformate unterstützt, sind DMS-Anzeigefunktionen im Normalfall auf eine beschränkte Zahl von Druckdatenformaten ausgerichtet. Es ist also wichtig festzuhalten, welche Druckdatenformate in den Cold-Schnittstellen verwendet werden.

Nach der Aufnahme der im DMS gespeicherten Objekte ist für jeden Objekttyp zu klären, wie seine Speicherung im neuen DMS aussehen soll. In einigen Fällen müssen Formatkonvertierungen durchgeführt werden, da das ursprüngliche Format veraltet ist oder vom neuen DMS nicht unterstützt wird. Die Schwierigkeit liegt darin, genau die Objekte zu identifizieren, die das problematische Format aufweisen: Das Dokumentenformat ist ein Attribut des gespeicherten Objekts und wird nicht selbstverständlich in der Objektdatenbank hinterlegt.

Im zweiten Schritt ist für jedes zu konvertierende Dokumentenformat ein geeigneter Konverter zu finden. Dieser muss nicht nur in der Lage sein, eine saubere Konvertierung durchzuführen, er muss außerdem stabil und performant arbeiten. Der Grund dafür liegt auf der Hand: Bei der Aufgabenstellung der Objektmigration handelt es sich vornehmlich um ein Massenproblem. Der Datenbestand gespeicherter Dokumente beträgt oft mehrere hundert Gigabyte und übersteigt bei großen Anwendern zuweilen die Terabyte-Grenze. So ist es nicht verwunderlich, dass sich allein die Objektmigration über Monate hinziehen und das gesamte Projekt Systemmigration durchaus eine Laufzeit von über einem Jahr haben kann.

Inzwischen haben sich Dienstleistungsanbieter auf die Planung und Durchführung von Migrationen spezialisiert. Obwohl sich deren Leistungsspektrum vor allem auf die auf optischen Datenträgern gespeicherten Objektdaten beschränkt, lassen sich gerade die reinen Konvertierungszeiten hierdurch drastisch verringern. Während das Kopieren von optischen Beständen auf dem eigenen DMS eine nicht unerhebliche Systembelastung hervorruft und deshalb häufig ausschließlich über Nacht durchgeführt wird, stellen Dienstleister zumeist eigene Systeme bereit und führen die Konvertierungen im Idealfall auf der Basis von Sicherheitskopien der optischen Platten durch. In diesem Fall bleibt das Produktionsumfeld von jeglicher Konvertierbelastung verschont.

Der zweite Aufgabenkomplex entfällt auf die Migration der externen DMS-Schnittstellen. Fast kein DMS wird als Funktionsinsel betrieben, sondern über Schnittstellen als integrierter Bestandteil einer kaufmännischen oder technischen Lösung, etwa im Rahmen der Reklamationsbearbeitung oder der Rechnungsprüfung. Bei einem DMS-Wechsel sind diese externen Schnittstellen ebenfalls sorgfältig zu migrieren.

Ein DMS ist selten eine FunktionsinselAuch hier ist es notwendig, zunächst den Ist-Zustand vollständig aufzunehmen, wobei eine Liste aller technischen Abhängigkeiten zwischen der DMS-Lösung und anderen Systemen (Desktop-, Host- oder Client-Server-Anwendungen) erstellt werden muss. Ein besonderes Augenmerk gilt dabei der Art und Weise, wie das DMS in andere Umgebungen integriert ist. Soweit eine Anwendung das DMS als integriertes System verwendet, findet in der führenden Applikation eine Verknüpfung zum DMS statt, meist in Form einer eindeutigen Dokumentenkennung (Dokumentennummer) - ein Beispiel ist die R/3-Archivelink-Umgebung, in der das DMS als integrierter Bestandteil von SAP betrieben wird.

Bei einem Systemwechsel ist es durchaus wahrscheinlich, dass jedes Dokument eine neue, vom DMS vergebene Dokumentenkennung erhält. Die Verknüpfung zwischen dem führenden Anwendungssystem und dem DMS muss also in der führenden Anwendung ebenfalls migriert werden: Die alte Kennung ist durch die neue zu ersetzen.

Da nahezu jedes DMS sein eigenes API besitzt, das bei der Gestaltung der benutzerspezifischen Oberfläche einbezogen wird, fällt die Migration der bestehenden Anwendung auf das neue DMS-API ebenfalls in die To-do-Liste. Nicht zuletzt sind automatisierte Übernahmeverfahren etwa für Cold-Dokumente konzeptionell zu überarbeiten und den neuen DMS-Gegebenheiten anzupassen.

Um die hier angesprochenen Probleme und Risiken zu verringern, empfiehlt es sich, Migrationsaspekte bereits während der Planung und Auswahl einer DMS-Lösung zu berücksichtigen. Bei DMS-Anbietern, die bereits zum Zeitpunkt der Systemauswahl Werkzeuge dafür bereitstellen, besteht die begründete Hoffnung, dass diese Tools auch dann noch verfügbar sind, wenn der Anwender sie später benötigen sollte. Man sollte sich also Kopier- und Konvertierwerkzeuge sowie Export- und Importroutinen zeigen lassen, die neben einer reinen Kopie eine echte Konsolidierung unterstützen. Erst dann können die neuen Worm-Plattenkapazitäten optimal genutzt werden.

Außerdem ist sicherzustellen, dass das ausgewählte System mehrere Jukebox-Typen gleichzeitig betreiben kann und Bestände zwischen diesen Jukeboxen ausgetauscht werden können.

Zur Vermeidung einer allzu komplexen Migration empfiehlt es sich in vielen Fällen, eine kontinuierliche Aktualisierung einzelner Komponenten während des DMS-Betriebs durchzuführen. Sollte sich der komplette Systemwechsel jedoch unausweichlich andeuten, beugt eine frühzeitige Planung und vor allem eine geordnete Systemauswahl vor, dass für eine möglichst lange Zeit keine weitere DMS-Migration ansteht.

* Volker Halstenbach ist Partner der auf Dokumenten-Management- und Workflow-Beratung spezialisierten Zöller & Partner GmbH in Sulzbach/Taunus.

Abb.: Magneto-Optical-(MO-)Platten haben sich in den letzten sechs Jahren um drei Generationen weiterentwickelt. Quelle: Halstenbach