GDPdU und elektronische Archivierung - PROJECT CONSULT ...
GDPdU und elektronische Archivierung - PROJECT CONSULT ...
GDPdU und elektronische Archivierung - PROJECT CONSULT ...
Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.
YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.
<strong>GDPdU</strong> <strong>und</strong> <strong>elektronische</strong> <strong>Archivierung</strong><br />
Vortrag Dr. Ulrich Kampffmeyer am 26.11.2003<br />
ÜBERREUTER MANAGER AKADEMIE<br />
Tagung „Digitale Betriebsprüfung <strong>und</strong> <strong>elektronische</strong> <strong>Archivierung</strong>“<br />
Migration: Beispiele für Ursachen <strong>und</strong> Notwendigkeit<br />
Migration bei Aufgabenerweiterung <strong>und</strong> Ausbau von Systemen<br />
• Die Skalierbarkeit <strong>und</strong> Kaskadierbarkeit eines Archivsystems ist hier von<br />
Bedeutung<br />
Migration durch Unternehmenszusammenführung<br />
• Die Zusammenführung lässt sich nur durch eine integrierende Middleware<br />
mit Anpassung vorhandener Archive oder durch die Migration in eine<br />
Lösung bewältigen<br />
Je nach dem wie gut <strong>und</strong> sorgfältig Sie Ihre Systeme geplant <strong>und</strong> eingerichtet haben,<br />
gibt es verschiedene Typen der Migration. Harte Migration, diese wird immer dann<br />
notwendig, wenn Sie etwas bei der Systemauswahl falsch gemacht, wenn Sie sich<br />
eine „exotische Insel“ als Lösung angeschafft haben. Bei einem Systemwechsel<br />
müssen dann Anwendung, Datenbank <strong>und</strong> alle Daten migriert werden. Aus<br />
Erfahrung weiß ich, dass dies bei proprietären Lösungen zwei, dreimal so teuer<br />
werden kann, wie die ursprüngliche Installation. Und es ist ein aufwendiger,<br />
langwieriger Prozess.<br />
Hat man sorgfältiger geplant, auf Standards, Schnittstellen <strong>und</strong> Modularität geachtet,<br />
hat man die Möglichkeit einer weichen Migration. Dies bedeutet, dass man die<br />
Speichersubsysteme <strong>und</strong> die Medien weiter benutzen kann, <strong>und</strong> nur die Index-<br />
Datenbank, Anwendung <strong>und</strong> Client migriert.<br />
Der ideale Weg ist aber der, dass man seine Systeme so auslegt, dass man unter<br />
einer Zwischenschicht, einer Middleware, unterschiedlich alte, von verschiedenen<br />
Anbietern stammende <strong>und</strong> beliebig strukturierte Systeme gleichermaßen benutzen<br />
kann. Dies gibt Ihnen die Möglichkeit, alte Archive auszualtern, neue Informationen<br />
nur in die jüngeren Systeme zu schreiben <strong>und</strong> die alten nur noch für den Lesezugriff<br />
zu nutzen, dies alles nur mit einem Client, unter einer Benutzeroberfläche, so dass<br />
der Anwender nicht wissen muss, wo kommt eigentlich die archivierte Information<br />
her. Die Herausforderung der integrativen Migration ist der transparente Zugriff auf<br />
unterschiedliche Systeme.<br />
K<strong>und</strong>e: UEBERREUTER Projekt: Tagung <strong>GDPdU</strong> Autor: Kff<br />
Thema: <strong>GDPdU</strong> <strong>und</strong> <strong>Archivierung</strong> Topic: Teilnehmerhandout Status: fertig<br />
Datei: Handout_Text_Ueberreuter_Kampffm Datum:<br />
eyer_<strong>GDPdU</strong>.doc<br />
28.11.2003 Version: 1.0<br />
© <strong>PROJECT</strong> <strong>CONSULT</strong> GmbH 2003 Seite 69 von 99
Change language