Von der Info-Site zum Prozessportal

Es begann mit Yahoo & Co.: Mitte der Neunziger Jahre schossen im Internet Portale ins Kraut – Websites, die auf einer Seite Informationen aus verschiedensten Quellen vom Newsticker bis zum Wetterbericht kombinierten. Gleichzeitig grassierten in den Unternehmen abteilungs- und themenspezfische Intranet-Sites, oft im Dutzend und meist in Form völlig unzusammenhängender Insellösungen.
Die Idee lag nahe, auch im Intranet mit portalartigen Zusammenfassungen für Ordnung zu sorgen. Pioniere wie Vignette und Plumtree entwickelten die ersten Portal-Frameworks, mit denen sich nicht nur bestehende Intranet-Sites, sondern auch Informationen aus bisher nicht webfähigen Unternehmensanwendungen auf einer Portalseite kompakt zusammenstellen liessen. Im Lauf der Zeit kamen unzählige weitere Portallösungen hinzu; um die Jahrtausendwende umfasste der Portalmarkt über hundert Hersteller.

Idee gut, Umsetzung harzig

In der Praxis erwies sich die Idee von der unternehmensweiten Integration via Enterprise-Portal aus verschiedenen Gründen oft als Wunschvorstellung. Die ersten Portallösungen basierten auf proprietärer Technologie und arbeiteten nur mit wenigen Anwendungen zusammen. Die Portale wurden als reine IT-Projekte ohne Einbezug der Business-Einheiten hochgezogen, ERP-, CRM- und andere Enterprise-Applikationen liessen sich mehr schlecht als recht anbinden, und die Portalseiten waren derart mit Portlets überfrachtet und ohne Rücksicht auf Usability zusammengebastelt, dass von Benutzerakzeptanz keine Rede sein konnte. Mit dem zunehmenden Fokus der IT auf gesamte Geschäftsprozesse statt einzelner Funktionen wurde zudem der Nutzen einer blossen Zusammenfassung heterogener Informationsquellen immer fragwürdiger.

Portale allüberall

Die reinen Portal-Frameworks ohne eigene applikatorische Funktionalität erhielten gleichzeitig Konkurrenz durch Dokumenten-, Content-, Knowledge- und Prozess-Management-Lösungen, Business-Intelligence-Anwendungen, kollaborative Applikationen sowie ERP-, CRM- und SCM-Systeme. Deren Hersteller statteten ihre Produkte zunächst mit einem Web-Interface aus und konzipierten sie in den letzten Jahren von Grund auf neu: Eine service- und weborientierte Architektur (SOA) ist für Unternehmensanwendungen heute Pflicht.
Zur Umsetzung einer SOA bieten Middleware-Hersteller wie IBM, Oracle, Novell und BEA «SOA-Suiten» an. Diese enthalten Tools zum Erstellen von «Composite Applications», die einen kompletten Geschäftsprozess abbilden, die Funktionen für die einzelnen Prozessschritte in Form von Web Services aus vorhandenen Enterprise-Anwendungen beziehen und das Resultat dem Benutzer über ein Web-Interface anbieten. Im Grunde entspricht dies exakt der ursprünglichen Portalidee.
Im krassen Gegensatz dazu steht die Realität: In den meisten Unternehmen, die früh ein Portal einsetzten, blieb es nicht dabei. Im Normalfall entstanden aus organisatorischen wie technischen Gründen bald mehrere Portale, was der Grundidee völlig zuwiderläuft. Den Extremfall beschreibt ein Oracle-Spezialist, der in einem Unternehmen mit weniger als 50 Mitarbeitern sage und schreibe sechs verschiedene Portale antraf. Die Verbreitung standardbasierter Lösungen lässt hoffen, dass sich dieser Missstand künftig bessert.

Kriterien für die Portalwahl

Die Zahl der reinen Portal-Frameworks hat in den letzten fünf Jahren zwar dramatisch abgenommen – der entsprechende «Magic Quadrant» von Gartner verzeichnete Mitte 2005 noch 19 Hersteller. Die Wahl einer Portallösung fürs Intranet fällt aber kaum leichter: Portalfunktionalität findet sich heute fast in allen Enterprise-Anwendungen und immer mehr auch in Software für den KMU-Markt. Je nach Unternehmensgrösse und Einsatzzweck eignet sich ein simples Web-CMS nur schon aus Kostengründen und vom Ressourcenbedarf her vielleicht besser als ein aufgeblasenes Enterprise-Portal, von dem nur ein kleiner Teil der Funktionen wirklich benötigt wird. Im Kleinbetrieb genügt oft schon das Web-Interface der ohnehin installierten Business-Software.
Wo der Schwerpunkt der Unternehmenstätigkeit auf dem Umgang mit Dokumenten liegt, dürften die Portalfeatures einer Document-Management- oder ECM-Lösung den Ansprüchen besser genügen als das Portalprodukt eines ERP-Herstellers. Geht es um Wissensmanagement und kollaborative Inhouse-Publikation, kommt auch ein günstiges und ressourcenschonendes Wiki- oder Blog-System in Frage – näheres dazu lesen Sie in einer der nächsten Ausgaben.

Ohne Aufwand kein Portal

Der Implementationsaufwand für ein Unternehmensportal darf auf keinen Fall unterschätzt werden. Er beträgt je nach dem gewünschten Grad der Integration mit anderen Anwendungen ein Mehrfaches der Lizenzkosten. Diese wiederum richten sich ebenfalls nach den Integrationsmöglichkeiten, aber auch nach der Skalierbarkeit.
Ein typisches Beispiel ist die Abstufung der drei Websphere-Portalprodukte von IBM: Die Einstiegsvariante Websphere Portal Express kostet für 20 User rund 2700 Franken. Sie kommt mit Content- und Dokumentenmanagement, bietet Integrationsmöglichkeiten mit Notes, Exchange und diverser Business-Software und stellt in der optionalen Plus-Variante auch Kollaborations-Features wie virtuelle Team-Arbeitsräume bereit. Sie lässt sich aber nur auf einem einzelnen Server betreiben. Wer Skalierbarkeit wünscht, benötigt die vielfach kostspieligeren Editionen Enable oder Extend (mit zusätzlichen Such- und Analysefunktionen), die zudem ausschliesslich mit Pro-Prozessor-Lizenzen zu Preisen ab 90’000 Euro erhätlich sind.
Günstige Portallösungen mit KMU-tauglichem Lizenzmodell und vergleichsweise einfacher Implementation zumindest für die Basisfunktionalität gibt es auch von den deutschen Herstellern Abaxx und United Planet sowie von Oracle. Der Sharepoint Server von Microsoft ist ebenfalls relativ günstig und geniesst mit seiner engen Office-Integration eine Sonderstellung. Wie der folgende Artikel zeigt, dürfte die Microsoft-Portallösung in der kommenden Version 2007 den Mitbewerbern einiges an Kopfweh bereiten.

Das braucht ein Intranet-Portal

Ungeachtet der Unternehmensgrösse – ausser im Kleinstbetrieb, wo ein vollständiges Enterprise-Portal ohnehin wenig bringt – sollte eine Portallösung für den firmeninternen Einsatz einen Grundstock an Basisdiensten und Anwendungen mit sich bringen:

•
Layout- und Navigationsmanagement: Möglichst einfach zu bedienende Tools für die Zusammenstellung der Portalseiten aus den einzelnen, anwendungsspezifischen Portlets (bei Microsoft Webparts genannt) und den Aufbau der Site-Navigation. Gängig sind heute browserbasierte WYSIWYG-Oberflächen, die von den Herstellern oft als «Portal Builder» bezeichnet werden. Eine universell einsetzbare Portallösung bietet die Möglichkeit unterschiedlicher Layouts für verschiedene Endgeräte (PC oder Thin Client, PDA, Mobiltelefon...). Auch die besten Layout-Management-Tools machen eine sorgfältige Planung der Portalsite nach Massgabe von Usability-Kriterien jedoch nicht überflüssig.

•
Content Management: Ein reines Portalframework überlässt das Content Management einem separaten CMS. Dennoch bieten die meisten Portallösungen Funktionen zur Verwaltung von Text- und Bildinhalten, oder die Portalsuite enthält auch das CMS-Produkt des Herstellers. Andererseits verschwimmen die Softwarekategorien Portal, Content und Document Management zusehends: Die heute verfügbaren Enterprise-Content-Management-Systeme, früher
meist als Document Management gehandelt, bieten für viele Einsatz­szenarien genügend eigene Portalfunktionalität. Anwender der ECMS-Produkte von Day, EMC, Hum­ming­­bird, Red Dot, Filenet und anderen Herstellern können oft auf ein separates Portalframework verzichten. Ähnliches gilt für Knowledge-Management-Lösungen wie Lifelink von Opentext. Business-Intelligence-Lösungen bieten mit konfigurierbaren Dashboards zwar auch eine gewisse Portalfunktionalität, die sich jedoch grundsätzlich auf die Präsentation der BI-Analysen beschränkt.

•
Personalisierung: Viele Portale geben dem Endanwender die Möglichkeit, die Anordnung der Portlets selbst zu bestimmen. Das ist aber nur der unwichtigere Aspekt der Personalisierung: Eine gute Portallösung ermöglicht individualisierbare Navigationsstrukturen und selektive Präsenta­tion der Inhalte, beides regelbasiert aufgrund der Mitarbeiterfunktion. Besonders wichtig ist Personalisier­ung für Business-to-Consumer-Portale. Die rollenbasierte Präsentation ist aber auch für die Business-to-Employee-Portale, um die es hier geht, nicht ohne Bedeutung.

•
Enterprise Search: Nur eine Suchfunktion, die unternehmensweit alle auch vom Portal abgedeckten Anwendungen berücksichtigt, bringt wirklichen Nutzen. Das stellt an die Suchmaschine extreme Anforderungen. Sie muss mit den unterschiedlichsten Quellen strukturierter und unstrukturierter Daten umgehen können. Eine gute Enterprise Search Engine ist derzeit den High-End-Portallösungen vorbehalten, wie auch das IBM-Beispiel zeigt: Nur die Extend-Variante kommt von Haus aus mit einer vollen Enterprise-Suchfunktion.

•
Single-Sign-On: Der Benutzer sollte sich möglichst nur einmal am Portal anmelden und darauf Zugang zu allen freigegebenen Anwendungen erhalten. Die meisten Portallösungen bieten heute eine Single-Sign-On-Funktion, und praktisch alle Unternehmensanwendungen unterstützen die Benutzeranmeldung über einen zentralen Verzeichnisdienst, auf den auch das Portal zurückgreift. Die Voraussetzungen wären also gegeben. In der Praxis scheut man aber offenbar oftmals den Aufwand zur Einführung einer einheitlichen Benutzeranmeldung.

•
Workflow- und Prozessmanagement: Noch nicht alle Portallösungen bieten integriertes Business Process Management. Die Erweiterung vom blossen Präsentations- zum Prozessportal ist aber momentan klar der wichtigste Trend. Die neuen BPM-Standards wie BPEL und BPEL4Pepole werden erheblich zur Metamorphose der Portal­frameworks beitragen

Offene Standards für Portale

Damit ein Portal Informationen aus den verschiedensten Datenquellen und Anwendungen unter einer gemeinsamen Oberfläche präsent­ieren kann, braucht es allgemein gültige Regeln, die über die Basis der Web-Services-Standards SOAP und WSDL hinausgehen. Die wichtigsten offenen Interoperabilitätsstandards für Portale im Überblick:

• JSR 168: Java-API für die Inter­operabilität zwischen Portlets und Portlet-Containern, verabschiedet Ende Oktober 2003. Ein JSR-168-konformes Portlet lässt sich unabhängig von der Umgebung, mit der es ursprünglich erstellt wurde, in beliebigen Portalen einbinden.

•
JSR 170: Java-API für den implementationsunabhängigen, bidirektionalen Zugriff auf den Inhalt von Content-Repositories, verabschiedet Juni 2005. Ein «Content Repository» bietet laut der Spezifikation «Content Services» wie autorbasierte Versionierung, Volltextsuche, fein granulierte Zugriffssteuerung und Kategorisierung der abgelegten Inhalte. Ermöglicht Portalen den reibungslosen Zugriff auf beliebige Content-Management-Systeme.

•
WSRP (Web Services for Remote Portlets): Technologie-agnostisches Web-Service-Interface für den Zugriff auf und die Präsentation von Portlets, die auf einem entfernten Server gehostet sind, verabschiedet August 2003. Die WSRP-Definition unterscheidet «Producer» (der Container, in dem das in Frage stehende Portlet gehostet wird, plus Metadaten zur Beschreibung des Portlets) und «Consumer» (das Portal, in dem das Portlet schluss­endlich angezeigt werden soll).

•
SCA (Service Component Architecture): Bisher nur vage definierter Standard für Service-orientierte Architekturen. SCA beschreibt Business-orientierte Softwarekomponenten zum Einsatz in Composite- und anderen Anwendungen.

•
SDO (Service Data Objects): Technologie zum einheitlichen Zugriff auf heterogene Daten in einer SOA. Ursprünglich von IBM und BEA konzipiert, Version 2.0 mit erweiterter Beteiligung als Teil der SCA verabschiedet.

•
BPEL (auch WS-BPEL, Business Process Execution Language): ­
XML-basierte Sprache zur Definition von mehrstufigen Geschäftsprozessen als Abfolge von Web-Services «Orchestration». Da die BPEL-Definition sich nur mit per Web-Services automatisierten Prozessen befasst, haben IBM und SAP Mitte 2005 eine Erweiterung namens BPEL4People vorgeschlagen, die auch menschliche Aktivitäten berücksichtigen soll – konkret ist BPEL4People bisher allerdings weder durchdefiniert noch irgendwo implementiert.

18 Enterprise-Portal-Frameworks