Diese Seite wird nicht mehr gepflegt. Bitte besuchen Sie www.PROJECT-CONSULT.de
This website is no longer updated. Please visit www.PROJECT-CONSULT.de
Überlegungen zur Architektur von Dokumenten-Management- und elektronischen Archivsystemen
Anforderungen
Architekturansatz
Strategie der Trennung in eine Ablage- und eine Archivebene
Datenbankgestützte Verwaltung
Grundvoraussetzungen
Komponenten
Ausblick

Von Dr. Ulrich Kampffmeyer
Kampffmeyer

Top
Anforderungen
Betrachtet man die Benutzeranforderungen an Dokumenten-Management-Systeme, wie sie z.B. durch das SIZ Sparkasseninformatikzentrum oder die Schwarzwaldgruppe definiert wurden, so ergeben sich sehr unterschiedliche Anforderungen:
zum einen soll mit dynamischen, veränderlichen Informationen in heterogenen, verteilten und offenen Systemen gearbeitet werden,
zum zweiten ist aber eine revisionssichere Langzeitarchivierung auf optischen Speichern gefordert.
Diese beiden Ansprüche vertragen sich nur dann, wenn eine klar strukturierte und in separate Ebenen aufgeteilte Systemarchitektur gewählt wird. Die Aufgabe dabei ist, einerseits die ständigen Veränderungen bei Anwendungen im Büroumfeld mit neuen Programmen, neuen Formaten, neuen Schnittstellen etc. mit den Erfordernissen einer langfristigen, womöglich über Jahrzehnte erforderlichen Archivierung zu vereinen.
Top
Architekturansatz
Für ein EDMS müssen sinnvoller Weise drei Ebenen unterschieden werden:
die Clienten-orientierte Anwendungsebene. Sie dient zum Speichern, Suchen, Anzeigen, Drucken und Bearbeiten von Dokumenten. Hierbei kann es sich um spezialisierte Clienten oder um Enabling vorhandener Anwendungen handeln
die Server-orientierte Ablageebene für aktuelle und temporäre Informationen. Sie dient zur Speicherung von in Bearbeitung befindlichen Dokumenten, als Zwischenspeicher und zur Aufbereitung von Informationen für Anzeige, Druck, Speicherung etc.
die Server und Optical Disk Library orientierte Langzeitarchivebene. Sie dient zur langfristigen, revisionssicheren Archivierung von großen Informationsmengen auf nur einmal beschreibbaren optischen Speichermedien (WORM).
Top
Strategie der Trennung in eine Ablage- und eine Archivebene
Ablageebene
Die Ablageebene verwaltet alle dynamischen Informationen mit einem kurzzeitigen Speicherzyklus. Dort befindliche Informationsobjekte müssen noch nicht vollständig für die Langzeitarchivierung indiziert sein, es können mehrere Versionen eines Informationsobjektes vorhanden sein, in der Ablageebene kann kontrolliert gelöscht, vereinigt, verschoben und verändert werden, es existieren anpassbare Dienste zur Aufbereitung der Informationsobjekte und sie dient zum Verteilen von Informationsobjekten.
Speichermedien sind Festplatten. Die Dienste sind so auszulegen, daß sie einfach parametrisiert, ergänzt und ersetzt werden können, wenn dies durch neue Applikationen oder Veränderungen der Systemumgebung erforderlich wird. In der Ablageebene können innerhalb eines logischen Gesamtsystems mehrere Ablagen existieren. Die Ablageebene ist so ausgelegt, daß sie mehrere, auch unterschiedliche Langzeitarchivsysteme unterstützt. Die Schnittstelle zum Langzeitarchiv ist möglichst statisch und generisch auszulegen, die Schnittstellen zu Clienten und Applikationen dagegen müssen individuell angepaßt und entsprechend den Veränderungen der Anwendungen gepflegt werden. Die Ablage fungiert damit als „Puffer“, damit die Informationen im Langzeitarchiv möglichst lange und ohne Anpassungen unterschiedlichsten Anwendungen bereit-gestellt werden können.
Die Funktionalität der Ablage wird heute zum Teil durch spezialisierte Dokumenten-Management-Systeme wie SAROS, DOCUMENTUM etc. oder durch datenbankunterstützte Groupwareprodukte wie LOTUS NOTES dargestellt. Zum Teil arbeiten diese Systeme bereits mit selbstbeschreibenden (self-contained) Informationsobjekten (z.B. SAROS nach dem Shamrock-Modell).
Archivebene
Die Langzeitarchivebene besitzt ein oder mehrere Verwaltungssysteme (IRS) für ein oder mehrere Massenspeichersubsysteme (z.B. Jukeboxen für optische Speicher, Magnetband-Libraries oder CAR-Systeme). In ihr werden vollständig indizierte Informationsobjekte langfristig und unveränderbar archiviert (langfristiger Speicherzyklus, der jedoch auch die spätere Ausgliederung nicht mehr benötigter Bestände von Informationsobjekten erlaubt). Der Zugriff erfolgt durch einen eineindeutigen Schlüssel (Unique Identifier) über die oder eine der Index-Datenbanken, der vom Verwaltungssystem der jeweils betroffenen Langzeitarchivkomponente in die physikalische Adressierung für den Zugriff auf das Speichermedium umgesetzt wird. Die Informationsobjekte werden auf Anforderung eines Clienten oder eines Batch-Prozesses in der Ablageebene als Kopie zur Verfügung gestellt. In der Kopie des Informationsobjektes ist im Header vermerkt, daß es sich um eine Kopie eines unveränderlichen Objektes aus dem Langzeitarchiv handelt. Ziel ist, möglichst wenig Intelligenz in der Langzeitarchivebene zu besitzen, damit sie über einen langen Zeitraum unverändert Bestand haben kann. Alle erforderlichen Anpassungen, Konvertierungen etc. werden in der Ablageebene durchgeführt. Die Schnittstelle zur Datenbank und zur Ablageebene soll daher möglich statisch und generisch sein, damit sie über einen langen Zeitraum unverändert bleiben kann.
Die Funktionalität des Langzeitarchivs wird heute durch traditionelle elektronische Archivsysteme angeboten, jedoch fehlt in der Regel die Ablageebene und die Handhabung von verteilten Archiven mit übergreifendem Zugriff. Hierbei werden jedoch in den seltensten Fällen selbstbeschreibende Informationsobjekte archiviert. Eine Reihe von Anbietern speichert die Informationen im Originalformat mit separat archivierten Index- und Verwaltungsinformationen (aber auf dem gleichen optischen Medium).
Top
Datenbankgestützte Verwaltung
Verbunden und verwaltet werden diese drei Schichten durch eine oder mehrere Datenbanken, die den Zugriff auf die gespeicherten Informationen erlauben. Hierbei kann es sich durchaus um unterschiedliche Datenbanken handeln (relational, hierarchisch, Volltext u.a.), sofern sie für den Zugriff auf das Verwaltungssystem der Langzeitarchivierungskomponenten den Unique Identifier benutzen und die Informationsobjekte nicht als BLOBs direkt in der Datenbank gespeichert sind (Datenbank nur als Referenzsystem). Professionelle Datenbanken, die verteilbar sind, sind insbesondere bei großen Informationsmengen vorzuziehen. Die Datenbanken müssen sowohl von Clienten online, von Anwendungen indirekt und von Batch-Prozessen transparent für die Speicherung und das Wiederfinden von Informationsobjekten angesprochen werden können.
Top
Grundvoraussetzungen
Aus dem bisher Dargestellten ergeben sich folgende Grundvoraussetzungen:
Standardisierte Schnittstellen für heterogene Systemplattformen
Standardschnittstellen zwischen den drei Ebenen (diverse zwischen Clienten und Anwendungen auf der einen Seite, Ablage nebst Ablagediensten und Datenbankservices auf der anderen Seite sowie zwischen Ablage und Datenbankservices einerseits und Langzeitarchiv andererseits). Als Schnittstelle für den Clienten zur Ablage und Datenbank kommt ODMA in Frage. Für die Datenbanken empfiehlt sich SQL. Für die Bereitstellung und Handhabung von Informationsobjekten können Filesysteme und/oder spezielle Repository-Systeme ein-gesetzt werden. Die Schnittstellen müssen für die verschiedenen, gängigen Betriebssystemplattformen (MVS, UNIX, OS/2, Windows, Windows NT, Mac OS etc.) mit gleicher Funktionalität zur Verfügung stehen.
Client/Server-Architektur
Alle Serverprozesse sind Dienste im strengen Sinn einer C/S-Architektur (mehrere Dienste können sich einen Server teilen, ein Dienst kann aber auch auf mehrere Server verteilt werden). Alle Module der Ablage und des Archivs sind Dienste (Services) in diesem Sinn. Gegenüber den Client-Anwendungen und Applikationen (Server-Prozesse) verhalten sich die Ablage und ihre Dienste als Server, gegenüber dem Langzeitarchiv verhält sich die Ablage in der Regel als Client. Dies bedeutet, daß als Dienste auch über Server-to-Server-Prozesse ansprechbar sein müssen (z.B. für Fax-, Scanner- und andere Dienste). Die Dienste müssen für alle gängigen Betriebssysteme mit gleichen Schnittstellen und gleicher Funktionalität zur Verfügung stehen.
Skalierbarkeit
Die Skalierbarkeit ist derart auszulegen, daß ein logisches Gesamtsystem sich mehreren Datenbanken, mehreren Ablagen und mehreren Langzeitarchivsubsystemen zusammensetzen kann, wobei jede der Komponenten in sich erweitert oder um gleichartige Komponenten ergänzt werden kann. Ein Gesamtsystem kann daher auf einem physikalischen Server liegen oder aber über eine Vielzahl von Servern aufgeteilt sein. Dabei darf es keine Rolle spielen, welcher Art der Server ist, unter welchem Betriebssystem er läuft und in welche Netzwerkumgebung er eingebunden ist.
Selbstbeschreibende Informationsobjekte mit Unique Identifier
Der Begriff Informationsobjekt (herkömmlich auch Dokument genannt) wird bezogen auf alle Objekte, die in DV-Systemen mit Software erfaßt, verarbeitet, verwaltet und reproduziert werden können. Ein Informationsobjekt liegt im DV-System als Datei oder Bestandteil einer Datei vor. Informationsobjekte können unterschiedlichen Inhalt haben und in sich geschachtelt sein. Die in der Ablage- und Archivebene gespeicherten Informationen werden als selbstbeschreibende Objekte behandelt.
Die Informationsobjekte besitzen daher eine Headerkomponente, der alle notwendigen Identifizierungs- und Verwaltungsinformationen beinhaltet. Entsprechende Objektstrukturen waren bereits in DFR (ISO 10166) und Shamrock (IBM, SAROS) definiert worden. Dies erlaubt die Handhabung unterschiedlicher Versionen und den kontrollierten Dokumentenaustausch, bei dem Informationsobjekte auch den Verwaltungsbereich eines logischen Ablage- und Archivsystems verlassen können. Sie tragen dann alle notwendigen Informationen für den Zugriff, den Datenschutz, Formate des Inhalts, Autor etc. mit sich. Der Unique Identifier ist so zu konzipieren, daß er zumindest in einer Branche wirklich eineindeutig ist. Einige Organisationen habe für ihren Geltungsbereich bereits Vorschläge für Unique Identifier erarbeitet, die die Eineinddeutigkeit von Informationsobjekten für ihre verschiedenen Standorte hinweg sichern. Die ODMA-Gruppe hat Vorschläge für weltweit eineindeutige Unique Identifier unterbreitet. Eine ISO- oder DIN-Standardisierung wäre wünschenswert.
Der Unique Identifier sichert, daß jedes Objekt nur einmal vorhanden ist, verschiedene Datenbanken das gleiche Archiv nutzen können und daß versandte Informationsobjekte auch konsistent in externe Ablage- und Archivsysteme wieder integriert werden können. Das Verfahren käme auch Scan-Dienstleistern entgegen, die Medien mit fertig konfektionierten Informationsobjekten liefern können, die mit einfachen Mitteln in das Ablage- und Archivsystem integriert werden können. Die Auswertung der Headerkomponenten erlaubt zu dem auch das Recovery von Systemen, wenn die Index-Datenbank oder das IRS zerstört sind. Selbstbeschreibende Informationsobjekte sind daher eine Grundvoraussetzung für verteilte Lösungen und auch für die Unterstützung einer lokalen Offline-Bearbeitung, wie durch die Schwarzwaldgruppe gefordert.
Die Inhalte von Informationsobjekten können sein:
Unahbhängig vom Inhalt der Information wird erst durch die Kapselung mit einen standardisierten Header, der auch den Unique Identifier beinhaltet, das selbstbeschreibende Informationsobjekt gebildet.
Top
Komponenten
Die folgende Aufstellung gibt einen Überblick über die wichtigsten Module und Dienste, die für die Realisierung eines EDMS / Ablage- und Archivsystems erforderlich sind:
Clientmodule
lokales Dokumentenmanagement zur Verwaltung der auf dem Clienten vorgehaltenen Dokumente inkl. Caching.
Erfassung von Dokumenten mit Indizierung (auch separat einbindbar in Anwendungen)
Suche und Hitlistenanzeige von Dokumenten (auch separat einbindbar in Anwendungen)
hierarchische Darstellung von Dokumenten (lokal, Ablage; auch separat einbindbar in Anwendungen)
Viewer
Import / Export (inkl. Spawnen von Anwendungen)
Drucken
Schnittstelle zur Ablageebene inkl. Datenbankservice
Ablagedienste, -module und -tools
Datenbankservices (Speicherung von Indizes, Retrieval, Verwaltung der Informationsobjekte)
Caching von Informationsobjekten (Speicherhierarchie)
Informationsobjektverwaltung (im Filesystem oder Repository)
Lokalisierung (da bereits in einem logischen Ablage-/Archivsystem mehrere Datenbanken, Ablagen und Archive vorhanden sein können, wird eine Lokalisierungskomponente benötigt, die über die Struktur der Indexdatenbanken und der Speicherorte Informationen enthält. Der Lokalisierungsdienst beinhaltet ferner auch die Informationen über entfernte Archive mit Zugriffsrechten, Struktur der Datenbanken und Art des Verbindungsaufbaus. Die Lokalisierungskomponente erlaubt damit den Zugriff und die Navigation über unterschiedliche und an verschiedenen Orten liegende Indexdatenbanken mit zugehörigen Ablage-/Archivsystemen)
Konvertierungsdienste (z.B. Erzeugung von Informationsobjekten mit Generierung eines einheitliches Formates für die Ablage- und Archivebene, Wandlung älterer Formate, Import von Druckoutput-Dateien mit automatischer Aufbereitung und Indizierung etc.)
Versionsmanagementdienste (z.B. Verwaltung und Kontrolle unterschiedlicher Versionen in der Ablageebene, Verwaltung benutzter Applikationen mit Historie, Verwaltung von Konvertierungs- und Viewermodulen mit Bereitstellung zur Anzeige älterer Dokumente, Verwaltung von elektronischen Layouts und Hintergrundfaksimiles, Konsistenzprüfung in verteilten Systemen etc.)
Replikationsdienste (z.B. zur Generierung von Kopien, Dopplung von Dokumenten zur parallelen zweifachen Archivierung, Update des lokalen und der im logischen Speicherraum befindlichen, externen Lokalisierungsdienste bei DB-, Speicherort- Zugriffs- oder anderer struktureller Änderungen etc.)
Anbindung oder Einbindung in zentrale Benutzerverwaltungen (damit nicht separate Benutzerverwaltungssysteme für Ablage/Archiv gepflegt werden.
Routing (Versenden, Empfangen, Verschieben und Kopieren zwischen den verschiedenen Ebenen und zwischen mehreren logisch verbundenen Ablage-/Archivsystemen auf Basis der Informationen des Lokalisierungsdienstes)
Dienst zur Erzeugung des Unique Identifier
Schnittstellen zu Anwendungen (andere Dienste, Client-, Host- und Serveranwendungen) Schnittstelle zur Archivebene
Anwender-orientierte Tools zur Pflege der Datenbank (z.B. für Schlagwortlisten, Statistiken, Anwenderteil der Benutzerverwaltung etc.)
Administrator-orientierte Tools (z.B. Wiederanlauf, Recovery, Auslastungskontrolle, Speicherverwaltung, Statistik, Parametrisierung der Dienste, Rechteverwaltung etc.)
Archivdienste, -module und -tools
IRS Information Retrieval System (Lokalisierung der angeforderten Informationsobjekte auf den Medien, Verwaltung und Kontrolle des verfügbaren Speicherraums, online-, nearline und offline-Medienverwaltung, Prioritätensteuerung für Zugriff, Organisation lesender und schreibender Zugriff auf unterschiedlichen Laufwerken, Speicheroptimierung, Fehlerbehandlung etc.)
Formatierung von Medien
Austausch von Medien
Duplizierung von Medien (1:1, sequentielle Sicherungskopien etc.)
Caching für Performanceoptimierung
Administrator-orientierte Pflege- und Überwachungstools
Schnittstelle zur Ablageebene und zu den Datenbankservices
Top
Ausblick
Zahlreiche dieser Module, Tools und Dienste sind bereits in modernen Produkten vorhanden. Systeme, die über alle in den Anforderungen der Schwarzwaldgruppe und der hier beschriebenen Architektur benötigten Komponenten verfügen, sind am Markt jedoch noch kaum verfügbar. Besondere Probleme bereiten den Anbietern derzeit offenbar die Kombination von dynamischer und Langzeitarchivebene, der kontrollierte und konsistente Dokumentenaustausch, die Einbindung von Office-Produkten mit ihren Anforderungen an Versionsmanagement und kooperatives Arbeiten sowie die Handhabung von verteilten Systemen. Da die benötigte Funktionalität in Produkten mit unterschiedlicher Ausrichtung wie herkömmlichen Archivsystemen, spezialisierten Dokumenten-Management-Systemen und bestimmten Groupware-Produkten bereits vorhanden ist, kann dennoch in naher Zukunft mit marktreifen Lösungen gerechnet werden.
Rechtshinweis
© CopyRight PROJECT CONSULT 1996 - 2003
Autorenrechte Dr. Ulrich Kampffmeyer

Rechtshinweis
Autorenrechte
Zum Download sind auschließlich die Beiträge in der Rubrik Download vorgesehen. Als PDF bereitgestellte Beiträge enthalten auch die zugehörigen Grafiken.
Download
Zitierung dieser Webseite:
Überlegungen zur Architektur von Dokumenten-Management- und elektronischen Archivsystemen
Dr. Ulrich Kampffmeyer
PROJECT CONSULT Unternehmensberatung, Hamburg 1996
PROJECT CONSULT Webseite http.//www.PROJECT-CONSULT.com
Rubrik „Wissen/Artikel“
Deep Link: http://www.PROJECT-CONSULT.com/home.asp?SR=225
Abruf der Seite am „Datum“

Top
Seitentitel: Artikel_DM-Architektur, Zitierung: http://www.PROJECT-CONSULT.com/home.asp?SR=225
Zuletzt aktualisiert am: 22.3.2003
CopyRight © 1992-2012 PROJECT CONSULT Unternehmensberatung Dr. Ulrich Kampffmeyer GmbH
20251 Hamburg, Breitenfelder Str. 17, Tel.: +49-40-46076220, E-Mail, Rechtshinweis
Optimiert für MS Explorer 5.x, 6.x, 1024x768 Pixel, Cookies(on), JavaScript(on)
Diese Seite wird nicht mehr gepflegt. Bitte besuchen Sie www.PROJECT-CONSULT.de
This website is no longer updated. Please visit www.PROJECT-CONSULT.de