6 Referenzarchitektur (S. 155-156)

Basierend auf den in den vorigen Kapiteln ermittelten fachlichen und technischen Anforderungen wollen wir in diesem Kapitel eine Referenzarchitektur für Unternehmensportale vorstellen. Der Name deutet es bereits an: Eine solche Architektur kann als Orientierung dienen, wird aber so gut wie nie ohne Anpassungen auf die konkreten Anforderungen übertragen werden können. Deshalb geben wir zu Beginn des Kapitels Hinweise zum Umgang mit einer Referenzarchitektur, bevor wir die fachliche und die technische Sicht auf eine solche idealisierte Portalarchitektur entwickeln.

6.1 Gebrauchsanleitung für eine Referenzarchitektur

Eine Softwarearchitektur beschreibt nach Balzert (1996) die Struktur des Softwaresystems durch Systemkomponenten und ihre Beziehungen untereinander. Eine Beziehung beschreibt jede mögliche Verbindung zwischen zwei Komponenten, dynamisch oder statisch. Entsprechend ist eine Referenzarchitektur die idealisierte Darstellung der Komponenten eines Softwaresystems sowie der Beziehungen und der Aufgabenteilung zwischen diesen Komponenten. Abhängig von der jeweiligen Betrachtungsweise lassen sich technische und fachliche Darstellungen finden. Auch wenn beide Modelle im Folgenden getrennt voneinander beschrieben werden, ergibt sich doch erst aus der Kombination der beiden Sichtweisen eine ganzheitliche Betrachtung des Portals. Erst dieser Blick auf das Ganze schafft das Bewusstsein für die Komponentenvielfalt und das Beziehungsgeflecht eines Portalsystems. Die Betrachtung der Architektur eines Unternehmensportals aus der Vogelperspektive ermöglicht den Überblick und die notwendige Orientierung in diesem komplexen Thema.

Die beiden Betrachtungsweisen der Portalarchitektur leiten sich aus den in den Kapiteln 4 und 5 beschriebenen fachlichen und technischen Anforderungen ab. Dabei abstrahiert das Architekturmodell von den konkreten Anforderungen und gruppiert gewünschte Funktionen und Services zu Architekturkomponenten. Folglich wirken sich einige technische Anforderungen auch auf das fachliche Architekturmodell aus und umgekehrt. So haben z.B. die technischen Möglichkeiten der Datenaufbereitung in Abhängigkeit von den Ausgabemedien (z.B. Webbrowser) Auswirkungen auf die fachliche Gestaltung der Benutzungsoberfläche. Die Betrachtung der jeweils anderen Architektursicht und der entsprechenden Anforderungen hilft, die Vollständigkeit der identifizierten Komponenten zu überprüfen. So setzt beispielsweise die fachliche Anforderung durchgängiger Geschäftsprozesse das Vorhandensein und die Integration eines EAI-Servers sowie eines Workflowsystems voraus. Nur in seltenen Fällen wird ein Architekturmodell in seiner Gesamtheit den tatsächlichen Gegebenheiten eines Portalprojekts bzw. Portalprodukts entsprechen. In der Regel muss das Modell an die unternehmensspezifischen Anforderungen und Rahmenbedingungen des Portalprojekts angepasst werden.

Das idealtypische Architekturmodell dient hier als Leitfaden und Instrument der Qualitätssicherung bei der Konzeption und der Implementierung des Portals. Die Abbildung des Modells auf die tatsächlichen Gegebenheiten ist nicht trivial. Dies liegt zum einen an der Tatsache, dass Portalprodukte in der Regel nicht alle Komponenten des Architekturmodells vollständig beinhalten. Zum anderen werden von verschiedenen Produktherstellern unterschiedliche Begrifflichkeiten verwendet. Erschwerend kommt hinzu, dass das Produktmarketing durch eine freie absatzorientierte Interpretation der fachlichen und technischen Begriffe Erwartungen weckt, die das Produkt schlussendlich nicht erfüllt. Folglich ist es erst durch eine tiefgehende Analyse der Produktfunktionalitäten einerseits und der Anforderungen des Unternehmens andererseits möglich festzustellen, welche Produkte die Anforderungen des Unternehmens tatsächlich abdecken. Die Themen Anforderungsanalyse und Softwareauswahl werden im Kapitel 8 ausführlich dargestellt. Kapitel 9 und 10 beleuchten die wichtigsten Aspekte der Einführung, des Betriebs und der Weiterentwicklung eines Unternehmensportals.