Die Buzzword-Karriere war beeindruckend: Innerhalb kürzester Zeit wurde "Enterprise-Portal" zu einem der meistgebrauchten Begriffe in der IT. Wenn sich die Fokussierung von Anbietern auf wenige Schlagworte mit der Bereitschaft der Adressaten trifft, Inhalte nur oberflächlich zu prüfen, entsteht im Nu die schönste Begriffsverwirrung. Unter einigen, nicht wirklich definierten Schlagworten werden immer wieder vielschichtige Konzepte, komplexe und höchst simple Produkte sowie unterschiedlichste Kompetenzen subsumiert.
Die Diskussion um Enterprise-Portale drehte sich in der Vergangenheit meist um die Frontends. Dieser Ansatz greift jedoch viel zu kurz. Zwar ist auch beim Bau eines Hauses die Gestaltung der Außenfassade wichtig, um eine positive Erwartungshaltung zu erzeugen. Noch wichtiger aber sind ein Architekturplan, um alle benötigten Funktionsräume und Schnittstellen zur Außenwelt bereitzustellen, sowie eine effiziente Infrastruktur, um die Funktionsräume mit allen internen und externen Ressourcen zu versorgen.
Die alleinige Beschränkung auf Frontends (unter Einbeziehung neuer Features wie Personalisierung und Community) mag im B-to-C-Bereich vielleicht noch gerechtfertigt sein, da hier die Verweildauer der Nutzer auf der Website das Messkriterium darstellt. Enterprise-Portale hingegen haben eine andere Zielsetzung: Der Beziehungspartner zum Unternehmen (Mitarbeiter, Kunde, Lieferant, Investor, öffentliche Verwaltung, Wettbewerber) nutzt die Web-Seite vor allem deshalb, weil er konkrete Informations- oder Prozessbedürfnisse befriedigen will. Dieses Nutzeranliegen an zentraler Stelle schnell und qualitativ hochwertig zu erfüllen ist das Ziel. Dazu können sehr umfangreiche Transaktionen und Analysen notwendig sein.
Hinzu kommt eine weitere Herausforderung. Während des E-Hypes wurde nahezu jedes Projekt budgetiert, das irgendeinen Internet-Bezug hatte und ein (oftmals wenig spezifiziertes) Bedürfnis der Nutzer ansprach. Als Folge daraus entstand eine Menge neuer, Web-fähiger Applikationen. Diese brachten jeweils ihre eigene Systemadministration, Kundendatenverwaltung, Security-Konzepte und Transaktionsverwaltung mit. Still und leise hat sich damit die Anzahl der zu administrierenden heterogenen Systeme im Unternehmen deutlich erhöht.
Konfuse ArchitekturenDie Dynamik des Internet verhinderte weit gehend den strukturierten Aufbau auf Basis eines durchdachten Architekturplans und die Koordination im Rahmen eines Gesamtprojektmanagements. Die "Integration" sah meist so aus, dass die verschiedenen Frontends an existierende Backend-Systeme angebunden wurden, so dass einige Daten ausgetauscht werden konnten. Fast jeder Anbieter, der ein SQL-Statement oder einen RFC schreiben konnte, ernannte sich selbst zum "Marktführer bei der Integration aller beliebigen Backend-Systeme". Mit zunehmender Reife der Projekte stellen deren Manager nun fest, dass die implementierten Schnittstellen sehr zahlreich und zudem äußerst kompliziert geworden sind.
Das große Experimentierfeld jenseits der "offiziellen" Unternehmens-IT wurde insbesondere von Newcomern genutzt, die im Management komplexer Architekturen unerfahren waren. Nun ist die Phase der Ernüchterung eingetreten, denn neben den unbestritten positiven Folgen sind inzwischen auch die negativen Auswirkungen der Euphorie unverkennbar: Neue Web-Anwendungen haben die Gesamtkomplexität der IT nochmals deutlich erhöht. Damit ist es noch schwieriger geworden, das Ziel eines Enterprise-Portals wirklich zu erreichen, nämlich internen und externen Teilnehmern an einem einheitlichen Zugang schnell, zuverlässig und qualititiv hochwertig alle benötigten Informationen und IT-Funktionen bereitzustellen.
Heterogene LandschaftenEnterprise-Portale mit dieser Zielsetzung haben eine "Umbrella"-Funktion. Sie sollen einerseits alle im Unternehmen (und künftig im Unternehmensverbund) vorhandenen Daten verfügbar machen, anderseits aber den Zugang gegen unberechtigten Zugriff schützen. Neben Sicherheitsfragen, die eine größere Sensibilisierung insbesondere des Managements erfordern, aber prinzipiell gelöst werden können, ist die größte Herausforderung dabei zweifellos die heterogene IT-Landschaft, aus der heraus Informationen einheitlich zugänglich werden sollen. Diese Heterogenität hat verschiedenste Ausprägungen: bei Hardware und Betriebssystemen, bei den Datenmodellen, bei den Datenhaltungs- und Datenbank-Management-Systemen, bei den Schemata und schließlich bei den Dateninhalten.
Ein Lösungsansatz zur Überwindung der Heterogenität innerhalb des Unternehmens ist zweifellos die Einführung eines zentralen Datenbanksystems, das alle Daten einheitlich verwaltet. Dies wurde auch vielfach versucht. Unternehmensweite Datenmodelle führten jedoch zu sehr mächtigen Systemen, die oft nur schwer handhabbar, unübersichtlich und langsam wurden. Außerdem ist kein Datenbank-Management-System für alle Einsatzfälle optimal geeignet. Ein universeller Ansatz hat sich daher bislang nicht durchgesetzt. Zurzeit etablieren sich eher spezielle Systeme, die dedizierte Aufgaben performant ausführen können.
Ein weiteres Problem ist der große Aufwand bei der Einführung eines zentralen Systems. Existierende Anwendungen müssen verändert oder gar abgelöst werden. Eine Anpassung eines Legacy-Systems scheitert oft, weil kein Quellcode beziehungsweise keine Dokumentation mehr zur Verfügung steht.
Das Abschalten wiederum ist schwierig, da die Datenbestände vollständig und korrekt übernommen werden müssen. Auch muss das Altsystem meist noch einige Zeit parallel mitlaufen, da die neu implementieren Methoden keine Rückverfolgung der bisherigen geschäftlichen Vorgänge ermöglichen. Die "saubere" Migration und der Parallelbetrieb lassen die Kosten deutlich ansteigen. Der Einsatz eines zentralen Systems birgt somit zahlreiche Risiken und Nachteile.
Ein alternativer Ansatz zur Überwindung der Heterogenität im Unternehmen sind föderierte Systeme. Bestehende (heterogene und autonom arbeitende) Datenbank- und Datenhaltungssysteme werden zu einem Gesamtsystem "föderiert". Dabei behalten die Einzelsysteme weit gehend ihre Autonomie. Bestehende Anwendungen können unverändert und ohne Leistungsverlust weiterlaufen, neue greifen über einen zentralen Zugang auf die föderierten Datenbestände zu. Damit lassen sich Applikationen sanft einführen und existierende Datenbestände behutsam migrieren. Das Risiko eines Fehlschlags wird deutlich gemindert.
Autonome KomponentenEin föderiertes Datenbanksystem besteht aus mehreren heterogenen, autonom arbeitenden Komponenten-Datenbanksystemen, die über eine Föderierungsschicht miteinander kooperieren. Diese flexibel erweiterbare Schicht hat die Aufgabe, einen zentralen und einheitlichen Zugang auf die Datenbestände im angeschlossenen Verbund der Föderation bereitzustellen. Dabei wird einerseits in lose und andererseits in eng gekoppelte Systeme unterschieden: Bei Ersteren greifen die Applikationen mit einer speziellen Multidatenbanksprache auf die heterogenen Datenbanksysteme zu, bei Letzteren stellt der Föderierungsdienst ein globales Schema für alle Anwendungen bereit.
Bei der Entwicklung dieses Konzeptes mussten bekannte, bereits gelöste Themen neu betrachtet werden. So beinhalten beispielsweise relationale Datenbank-Management-Systeme heute selbstverständlich Methoden zur Konsistenz- und Integritätssicherung im Rahmen der ACID-Eigenschaften (ACID = Atomicity, Consistency, Isolation und Durability). Die Wissenschaft musste diese Fragen erneut eingehend untersuchen und hat die notwendigen Methoden neu beschrieben.
Entsprechende Werkzeuge zum Aufbau von föderierten Strukturen stehen den IT-Architekten heute mit Applikations-Servern, EAI-Tools, Data-Movement- und Replikations-Servern zur Verfügung. Außerdem können für ergänzende Fragestellungen spezielle Projektlösungen eingesetzt werden, wie zum Beispiel ein Tool zur Konsistenzprüfung und -sicherung bei lose gekoppelten föderierten Systemen.
Interessant dabei ist, dass sich zwischen dem Konzept der föderierten Strukturen und dem sich zunehmend abzeichnenden Verständnis von Enterprise-Portalen ein hoher Ähnlichkeitsgrad erkennen lässt. Enterprise-Portal-Projekte sind nichts anderes als sehr komplexe, hochgradig anspruchsvolle Integrationsprojekte.
Neu daran ist nicht die Technologie, sondern der Grad der mehrdimensionalen Komplexität bei den Anforderungen an Architekturdesign, Schemata, Datenmigration, Schnittstellen-Management - und natürlich auch das Projekt-Management selbst.
Bei Enterprise-Portalen muss die Frage der Heterogenität in einem noch komplexeren Kontext gelöst werden, nämlich zwischen einem oder mehreren Unternehmen. Nur wenn allen Personengruppen, die mit dem Unternehmen in Beziehung stehen (Mitarbeiter, Investoren, Kunden, Lieferanten, Geschäftspartner, öffentliche Verwaltung), ein universeller Zugang verschafft wird, kann das eigentliche Ziel realisiert werden: Geschäftsprozesse unternehmensübergreifend zu organisieren - etwa beim Supply-Chain-Management oder dem E-Procurement. Die gleichen Abstimmungs- und Klärungsprozeduren, die innerhalb des Unternehmens notwendig sind, um Daten aktuell, korrekt und konsistent zu verwalten, werden nun zwischen den verknüpften Unternehmen durchlaufen. Die Daten müssen bezüglich Syntax und Semantik angeglichen werden, was alle Informationsobjekte (Produkte, Finanzen, Kunden) und Prozessschritte betrifft.
Und erneut müssen scheinbar gelöste Fragen neu durchdacht werden, beispielsweise für den Fall einer Lieferkette, wenn ein Kunde ein neues Auto bestellt: Für gewöhnlich reicht der Hersteller umgehend den Auftrag an die angebundenen Lieferanten weiter. Alle Beteiligten haben bestmögliche Kenntnis über den Kundenbedarf und können frühzeitig Produktionsentscheidungen treffen. Aber wie verhält sich der Verbund, wenn der Kunde nach elf Tagen von seinem 14-tägigen Rücktrittsrecht Gebrauch macht? Wer trägt die Verantwortung für die Gesamttransaktion "Storno"? Wer trägt die Kosten für das Roll-Back, insbesondere dann, wenn es aufgrund technischer Probleme nicht komplett ausgeführt wird?
Lebenszyklus einer TransaktionEin B-to-B-Prozess meint nicht nur die elektronische Datenweitergabe - dies wäre lediglich EDI in XML. Vielmehr stößt eine Steuerungsinstanz eine globale Transaktion an, die von mehreren betroffenen Geschäftspartnern parallel oder sequenziell abgearbeitet wird. Nach deren Ausführung werden entsprechende Bestätigungen (Commits) an die Steuerungsinstanz zurückgemeldet.
Relativ einfach ist dieser Vorgang noch bei einer klar definierten zentralen Steuerungsinstanz. Mit zunehmender Konzentration der Unternehmen auf ihre Kernkompetenzen und ihre Einbindung in Business-Networks kann es aber auch zu dezentralen Initialisierungen von Teilprozessen kommen. Die Folge daraus ist, dass der Beginn und das Ende einer Transaktion verschwimmen. Laufende Forschungen im Bereich der Agenten-Software untersuchen derartige Aufgaben; die Fragen sind von einer endgültigen Klärung jedoch noch ein gutes Stück entfernt.
Die Beispiele zeigen, dass die Einführung eines Enterprise-Portals eine hochkomplexe Herausforderung ist. Eine Gesamtarchitektur ist notwendig, wobei den IT-Architekten mit dem Konzept der föderierten Systeme ein praxiserprobter, wissenschaftlich fundierter Ansatz zur Verfügung steht.
Das Ende der Monolithen?Er ist auch zur Lösung der genannten Probleme bei der Prozessabwicklung zwischen Unternehmen hilfreich: Aus funktionaler Sicht kommt lediglich eine zusätzliche Abstraktionsebene hinzu. Ein B-to-B-Prozess stellt über Unternehmensgrenzen hinweg ein mehrstufiges föderiertes Konstrukt dar, und die Methoden der Föderation sind - zumindest in leicht modifizierter Form - wieder einsetzbar.
In der Vergangenheit haben häufig zentralistische, monolithische Systeme die Architekturkonzepte dominiert. Das Internet fordert nun eine Dynamik, die nur durch flexible, offene Architekturen erreicht werden kann - es findet ein gravierender Paradigmenwechsel statt. Föderierte Systeme stellen ein Leitbild dar, mit dem E-Business-Strategien erfolgreich realisiert werden können.
*Thomas Fehling ist Business-Development-Manager E-Business bei der Sybase GmbH in Düsseldorf.
Abb: Föderierte Systeme
Bestehende Datenbank- und Datenhaltungssysteme werden zu einem Gesamtsystem "föderiert". Die Komponenten bleiben weitgehend erhalten. Quelle: Sybase