Unternehmensportale (eBook)

Martina Großmann ist Mediengestalterin für Digital- und Printmedien und Marketing-Kommunikationswirtin. Sie arbeitet derzeit als IT Business Consultant in der Competence Area "Enterprise Content Management" bei der Resco GmbH in Hamburg. Holger Koschek ist Diplom-Informatiker. Er studierte Informatik mit Vertiefungsgebiet Softwaretechnik und Nebenfach BWL. Derzeit arbeitet er als IT Business Consultant in der Competence Area "Business Collaboration Technologies" bei der Resco GmbH in Hamburg.  

Inhaltsverzeichnis 13
Einleitung 19
Zielgruppe 19
Der Aufbau dieses Buchs 20
Beispiele 23
Konventionen 23
Webseite 24
Kurz gefasst 24
1 Begriffe 26
1.1 Ein gemeinsames Verständnis 26
1.2 Unternehmen 27
1.3 Informationsmanagement 28
1.4 Prozessmanagement 36
1.5 Applikationen und Dienste 37
1.6 Integration 40
1.7 Miteinanderarbeit (Collaboration) 43
1.8 Portal 45
1.9 Unternehmensportale 49
2 Abgrenzung 55
2.1 Content-Management-Systeme 55
2.2 Enterprise Application Integration (EAI) 60
3 Motive und Grenzen 66
3.1 Warum ein Portal einführen? 66
3.2 Wem nützt ein Unternehmensportal? 67
3.3 Motive 68
3.4 Grenzen 83
4 Fachliche Anforderungen 93
4.1 Abbildung und Steuerung von Geschäftsprozessen 93
4.2 Einheitliche integrierte Sicht auf Daten 101
4.3 Personalisierung 108
4.4 Single Sign-On 112
4.5 Sicherheit 116
4.6 Benutzer- und Rollenmanagement 119
4.7 Ergonomie der Benutzungsschnittstelle 122
4.8 Multimodaler Zugriff 124
4.9 Zukunftssicherheit 126
5 Technische Anforderungen 129
5.1 Integration 129
5.2 Implizite Beziehungen zwischen Datenquellen 139
5.3 Modelle für Metadaten 143
5.4 Datensicherheit 146
5.5 Verfügbarkeit 146
5.6 IT- Sicherheit 152
5.7 Skalierbarkeit 153
5.8 Verteilbarkeit 154
5.9 Modularer Entwurf: Entkoppelte Komponenten 159
5.10 Standardtechnologien und offene Schnittstellen 161
5.11 Trennung von Content und Design 163
5.12 Performanz 165
6 Referenzarchitektur 169
6.1 Gebrauchsanleitung für eine Referenzarchitektur 169
6.2 Fachliches Architekturmodell 171
6.3 Technische Referenzarchitektur 184
7 Standards 196
7.1 Der Nutzen von Standards 196
7.2 Basistechnologie XML 198
7.3 Standards für Präsentation und Layout von Portalinhalten 209
7.4 Standards für Integration 218
7.5 Standards für Portaltechnik 221
7.6 Standard für Portalinhalte: RSS 228
7.7 Standard für Prozesse: WfMC Workflow Reference Model 231
7.8 Standards für Content Management 233
8 Das richtige System 236
8.1 Portale für jede Unternehmensgröße 236
8.2 Anforderungsanalyse 243
8.3 Softwareauswahl 263
8.4 Marktübersicht 266
9 Projektorganisation 272
9.1 Spezielle Herausforderungen in Portalprojekten 272
9.2 Die Schritte des Projektmanagement- Prozesses 277
9.3 Iteratives Vorgehen 294
9.4 Inhalte vor- und aufbereiten 295
9.5 Portalmarketing 298
9.6 Den Projekterfolg messen – Nutzenbetrachtung 300
10 Betrieb und Evolution 302
10.1 Portalmarketing 303
10.2 Bereitstellung aktueller und relevanter Informationen 307
10.3 Die Redaktion eines Unternehmensportals 308
10.4 Erkennen von Integrationspotenzialen 312
10.5 Miteinanderarbeit in Portalen 313
10.6 Das lernende Projekt 315
10.7 Release Management 318
11 Nutzenanalyse und Erfolgskontrolle 324
11.1 Was nützt der Nutzen? 324
11.2 Return on Investment (ROI) 326
11.3 Total Cost of Ownership (TCO) 331
11.4 Nutzensicherung 333
12 Vorgehensmodell 335
12.1 Warum ein Vorgehensmodell? 335
12.2 Das Vorgehensmodell für Portalprojekte 337
13 Ausblick 347
13.1 Anforderungen der Unternehmen an die Portale von morgen 347
13.2 Die Entwicklung des Portalmarkts 349
13.3 Technische Entwicklungen 351
13.4 Fazit 360
Literaturverzeichnis 361
Stichwortverzeichnis 366

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.