Migrationen von Archivsystemen im SAP-Umfeld
Archive auf Reisen
Migrationen von Archivsystemen beschäftigen Berater, Anwender und IT-Abteilungen, seit es Archive gibt, auch im SAP-Umfeld. Sie können viele Gründe haben: die Fusion von Unternehmen, eine Neuausrichtung und Verschlankung der IT-Landschaft, die Senkung laufender Kosten. Oder ein Unternehmen will sich auf die notwendigen Funktionen eines Archivs fokussieren - gerade für SAP gibt es Archivsysteme, die ausschließlich die für SAP notwendigen Funktionen liefern - und deshalb seine Altlösung abschaffen. Für SAP ist ein Archiv ausschließlich eine Datensenke im Sinne eines externen Datenspeichers. Der Zugriff auf "ausgelagerte" Daten und Dokumente findet über einen so genannten Primärschlüssel statt, alle für eine Suche notwendigen Metadaten werden innerhalb von SAP als führendem System verwaltet. So besteht keine Notwendigkeit eines SAP-unabhängigen Dokumentenzugriffs. Der Vorteil: Ein Archivsystem braucht weder eine eigene Logik zur Metadatenverwaltung noch ein eigenes Berechtigungssystem. Klassische ECM-Lösung für SAP nicht mehr nötig Vor allem angesichts der heute existierenden modernen Speicher- und HSM-Techniken (Hierarchical Storage Management) sind deshalb klassische Archiv-, DMS- oder ECM-Lösungen (Document Management System, Enterprise Content Management) mit ihrer breiten Funktionalität im Umfeld von SAP im Grunde nicht mehr erforderlich. Dies kommt einem Paradigmenwechsel bei der Archivierung gleich: Das Archiv konzentriert sich nur noch auf die Unterstützung der standardisierten Schnittstelle Archivelink, die performante Verwaltung der zur Ablage und zum Zugriff notwendigen Metadaten und die optimierte Ansprache der für die Speicherung genutzten Speichersysteme. Generell gilt bei Migrationen: Alle Dokumente und Daten sollen auch während der Archivmigration im Zugriff bleiben, die Migration soll möglichst automatisiert erfolgen, es ist ein lückenloser Nachweis über die Vollständigkeit der Migration zu führen, eine Archivsystemmigration soll keine Applikationsänderungen insbesondere in Produktivumgebungen erfordern, für den Anwender muss die Archivsystemablösung transparent sein, und Migrationsprozesse müssen robust sein und Restart-Fähigkeit mitbringen. Zwei grobe Kategorien lassen sich hier unterscheiden: einerseits Administrations- und Systemanforderungen, andererseits Anforderungen der Anwender. Die administrativen Anforderungen sind in der Regel einfach zu erfüllen, denn eine vollständig protokollierte und automatisierte Migration ist heute mit unterschiedlichen Ansätzen gut realisierbar. Genauerer Betrachtung bedürfen die Anwenderanforderungen. Vor allem die zentrale Forderung nach der Dokumenten- und Datenverfügbarkeit während der Migration ist nur mit guter Planung zu erreichen, zumal Migrationsprozesse in der Regel erhebliche Laufzeiten mit sich bringen (Bild 1). Die tatsächliche Laufzeit hängt dabei nicht nur vom Quellarchiv ab, sondern auch von Faktoren wie Zielsystem und Sicherungszeiten. Daneben können eventuelle "Frozen Zones", in denen nicht migriert werden kann, die Laufzeit erheblich beeinflussen. Nur wenn die Archivmigration sicher im Laufe einer Arbeitswoche durchzuführen ist, ist eine ausreichende Dokumentenverfügbarkeit während der Migration gegeben. Die Ausnahme bilden Dokumente, die im SAP-Workflow mit Workitems verknüpft sind und eine zeitnahe Bearbeitung zwingend erfordern. Innerhalb oder außerhalb von SAP migrieren? Zunächst ist festzulegen, ob man die Migration innerhalb oder außerhalb des SAP-Systems durchführen will. Beide Varianten haben ihre spezifischen Vor- und Nachteile. Bei der Migration innerhalb von SAP sind insbesondere die Eigenheiten der Archivanbindung zu berücksichtigen. SAP verwaltet alle archivierten Objekte in so genannten Verknüpfungstabellen. Alle Zugriffe auf archivierte Objekte erfolgen somit immer über das Content Repository in Kombination mit der Dokumenten-ID. Genau in dieser Regelung liegt die Herausforderung einer SAP-seitigen Migration. Da SAP unterschiedliche Archivsysteme ausschließlich über unterschiedliche Content Repositories ansprechen kann, sind SAP-seitige Migrationen immer mit einem Umkopieren von einem in ein anderes Content Repository und anschließendem Bereinigen der Verknüpfungstabellen verbunden. Hierzu kann man sich im SAP verschiedener Reports und Funktionsbausteine bedienen und sie programmtechnisch zu einem mehr oder weniger semi-automatisierten Verfahren kombinieren. Die im SAP-Standard vorhandenen Reports weisen jedoch nur unzureichende Protokollfähigkeiten auf, etwaige Fehlerfälle lassen sich deshalb nur unzureichend abhandeln. SAP-seitige Migrationen verbrauchen daneben SAP-Ressourcen und können sich negativ auf die System-Performance auswirken. Die Anforderung des uneingeschränkten Dokumentenzugriffs während der Migration wird hingegen erfüllt. Insgesamt liegt der entscheidende Nachteil dieses Ansatzes darin, dass die beschriebenen notwendigen Eingriffe in die produktive SAP-Landschaft erhebliche Risiken bergen und ein sehr komplexes Change-Management erfordern - insbesondere für Großunternehmen und Konzerne eine oftmals unüberwindbare Hemmschwelle. Ungeachtet der Nachteile ist ein SAP-seitiges Migrationsverfahren immer dann sinnvoll und notwendig, wenn neben der Migration auch Bereinigungen im Archivbestand erforderlich sind. Dies kann der Fall sein bei der Aufteilung eines bestehenden Content Repositorys auf mehrere Zielarchive, beim Zusammenführen unterschiedlicher Content Repositories in ein gemeinsames, bei Teilumzügen von Archiven in neue Archive oder bei Änderungen an Drucklisteninhalten oder Datenarchiven, zum Beispiel beim Zusammenführen verschiedener SAP-Systeme. Trifft keiner der vorgenannten Fälle zu, empfiehlt es sich, die Migration außerhalb der beteiligten SAP-Systeme ablaufen zu lassen (Bild 2). Diese Vorgehensweise bedingt den Einsatz geeigneter Software, eines Migrations-Proxy-Servers. Dafür sind in SAP keinerlei Änderungen vorzunehmen und die Migration ist für alle Benutzer vollständig transparent. Sämtliche administrativen Tätigkeiten lassen sich ohne SAP-Zugriffe durchführen. Selbst die physische Migration - also das Kopieren der Archivobjekte - findet außerhalb von SAP statt und lässt sich daher auch bei abgeschaltetem SAP-System fortsetzen. Ferner muss man keine Änderungen an den SAP-Verknüpfungstabellen vornehmen, da dieses Vorgehen das Kopieren eines Content Repositorys in ein namensgleiches Repository erlaubt. Der Migrations-Server verhält sich bei Archivzugriffen aus SAP ähnlich einem Proxy-Server im Netzwerk und leitet die Anfragen an das richtige Archivsystem weiter. Eine Migrationsdatenbank dient bei diesem Ansatz der Protokollierung. Vorgehen im Projekt Archivmigrationsprojekte sind in die Phasen Konzeption, Migrationstests und Migrationsläufe zu unterteilen. Projektschwerpunkt liegt dabei in der Konzeption und dem Durchleuchten des Quellarchivs und aller darauf vorhandener Anwendungen. Oft sind viele von diesen nicht mehr im Einsatz. Festzulegen ist dann der Umgang mit ihnen und ob sie gegebenenfalls noch Aufbewahrungspflichten unterliegen. Die aktiven Szenarien sind zudem auf notwendige Bereinigungsarbeiten zu überprüfen (Datenformat-Konvertierungen, Zusammenführung von Content Repositories, geänderte Aufbewahrungszeiten etc.). Erst anschließend kann man mit der Konfiguration der Migration beginnen. Der Migrationstest stellt dann die zweite Projektphase dar. Sie dient der Überprüfung des Konzepts und einer verlässlichen Abschätzung der Laufzeit. Die Laufzeit zu kennen ist wichtig, um etwa den Kündigungszeitpunkt von Wartungsverträgen für das Altsystem abschätzen zu können oder um Aufwände für interne sowie externe Ressourcen zu bestimmen. Die finale Phase beinhaltet schließlich die eigentliche Migration des produktiven Archivs. Sie ist geprägt von regelmäßigen Kontrollen des Fortschritts und Analysen etwaiger Problemsituationen, zum Beispiel nicht mehr lesbarer Dokumente. Zum Abschluss der Migration wird das vollständige Migrationsprotokoll in die vorhandene Verfahrensdokumentation aufgenommen. So sind alle gesetzlichen Rahmenbedingungen erfüllt. Migration ja oder nein? Aufschieben lassen sich Archivmigrationen schon, abwenden auf Dauer indes nicht. Häufig bedingt die Abkündigung von Softwareständen der bestehenden Archiv- oder ECM-Lösung eine solche Migration. Aus der praktischen Erfahrung heraus lässt sich festhalten: Kann ein Unternehmen technische Verbesserungen erreichen - etwa eine höhere Integrationstiefe, bessere Performance und höhere Stabilität - und sind auch geringere Kosten gefordert, dann wird es Zeit, sich vom Altarchiv zu verabschieden und es auf eine neue Plattform zu migrieren.
Lesen Sie mehr zum Thema
