Ein Architekturmodell für
Portale im Technischen Vertrieb
Von der Fakultät Maschinenbau
der Universität Stuttgart
zur Erlangung der Würde eines Doktor-Ingenieurs (Dr.-Ing.)
genehmigte Abhandlung
Vorgelegt von
Dipl.-Inform. Thorsten Gurzki
aus Stuttgart
Hauptberichter: Univ.-Prof. Dr.-Ing. Dieter Spath
Mitberichter: Univ.-Prof. Dr.-Ing. Prof. e.h. Dr.-Ing. e.h. Dr. h.c. mult. Engelbert Westkämper
Tag der Einreichung: 20. Januar 2006
Tag der mündlichen Prüfung: 03. August 2006
Institut für Arbeitswissenschaft und Technologiemanagement (IAT), 2006
Berichte aus dem
Fraunhofer-Institut für Produktionstechnik und
Automatisierung (IPA), Stuttgart,
Fraunhofer-Institut für Arbeitswirtschaft und
Organisation (IAO), Stuttgart,
Institut für Industrielle Fertigung und
Fabrikbetrieb (IFF), Universität Stuttgart
und Institut für Arbeitswissenschaft und
Technologiemanagement (IAT), Universität Stuttgart
Herausgeber:
Univ.-Prof. Dr.-Ing. Prof. E.h. Dr.-Ing. E.h. Dr. h.c. mult. Engelbert Westkämper
und
Univ.-Prof. Dr.-Ing. habil. Prof. E.h. mult. Dr. h.c. mult. Hans-Jörg Bullinger
und
Univ.-Prof. Dr.-Ing. Dieter Spath
IPA-IAO Forschung und Praxis
Ein Architekturmodell
für Portale im
Technischen Vertrieb
Nr. 442
Thorsten Gurzki
Fachverlag · 71296 Heimsheim
Dr.-Ing. Dipl.-Inform. Thorsten Gurzki
Fraunhofer-Institut für Arbeitswirtschaft und Organisation (IAO), Stuttgart
Univ.-Prof. Dr.-Ing. habil. Prof. E.h. mult. Dr. h.c. mult. Hans-Jörg Bullinger
ord. Professor an der Universität Stuttgart
Präsident der Fraunhofer-Gesellschaft, München
Univ.-Prof. Dr.-Ing. Dieter Spath
ord. Professor an der Universität Stuttgart
Fraunhofer-Institut für Arbeitswirtschaft und Organisation (IAO), Stuttgart
D 93
ISBN 3-936947-95-3 Jost Jetter Verlag, Heimsheim
Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere
die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und
Tabellen, der Funksendung, der Mikroverfilmung oder der Vervielfältigung auf anderen Wegen
und der Speicherung in Datenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiser
Verwertung, vorbehalten. Eine Vervielfältigung dieses Werkes oder von Teilen dieses Werkes
ist auch im Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheber-
rechtsgesetzes der Bundesrepublik Deutschland vom 9. September 1965 in der jeweils
gültigen Fassung zulässig. Sie ist grundsätzlich vergütungspflichtig. Zuwiderhandlungen
unterliegen den Strafbestimmungen des Urheberrechtsgesetzes.
© Jost Jetter Verlag, Heimsheim 2006.
Printed in Germany.
Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem
Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche
Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten
wären und daher von jedermann benutzt werden dürften.
Sollte in diesem Werk direkt oder indirekt auf Gesetze, Vorschriften oder Richtlinien (z. B.
DIN, VDI, VDE) Bezug genommen oder aus ihnen zitiert worden sein, so kann der Verlag keine
Gewähr für die Richtigkeit, Vollständigkeit oder Aktualität übernehmen. Es empfiehlt sich, ge-
gebenenfalls für die eigenen Arbeiten die vollständigen Vorschriften oder Richtlinien in der
jeweils gültigen Fassung hinzuzuziehen.
Druck: printsystem GmbH, Heimsheim
Univ.-Prof. Dr.-Ing. Prof. E.h. Dr.-Ing. E.h. Dr. h.c. mult. Engelbert Westkämper
ord. Professor an der Universität Stuttgart
Fraunhofer-Institut für Produktionstechnik und Automatisierung (IPA), Stuttgart
Geleitwort der Herausgeber
Über den Erfolg und das Bestehen von Unternehmen in einer marktwirtschaftlichen
Ordnung entscheidet letztendlich der Absatzmarkt. Das bedeutet, möglichst frühzeitig
absatzmarktorientierte Anforderungen sowie deren Veränderungen zu erkennen und
darauf zu reagieren.
Neue Technologien und Werkstoffe ermöglichen neue Produkte und eröffnen neue
Märkte. Die neuen Produktions- und Informationstechnologien verwandeln signifikant
und nachhaltig unsere industrielle Arbeitswelt. Politische und gesellschaftliche Verände-
rungen signalisieren und begleiten dabei einen Wertewandel, der auch in unseren Indu-
striebetrieben deutlichen Niederschlag findet.
Die Aufgaben des Produktionsmanagements sind vielfältiger und anspruchsvoller ge-
worden. Die Integration des europäischen Marktes, die Globalisierung vieler Industrien,
die zunehmende Innovationsgeschwindigkeit, die Entwicklung zur Freizeitgesellschaft
und die übergreifenden ökologischen und sozialen Probleme, zu deren Lösung die Wirt-
schaft ihren Beitrag leisten muss, erfordern von den Führungskräften erweiterte Perspek-
tiven und Antworten, die über den Fokus traditionellen Produktionsmanagements deut-
lich hinausgehen.
Neue Formen der Arbeitsorganisation im indirekten und direkten Bereich sind heute
schon feste Bestandteile innovativer Unternehmen. Die Entkopplung der Arbeitszeit von
der Betriebszeit, integrierte Planungsansätze sowie der Aufbau dezentraler Strukturen
sind nur einige der Konzepte, welche die aktuellen Entwicklungsrichtungen kennzeich-
nen. Erfreulich ist der Trend, immer mehr den Menschen in den Mittelpunkt der
Arbeitsgestaltung zu stellen - die traditionell eher technokratisch akzentuierten Ansätze
weichen einer stärkeren Human- und Organisationsorientierung. Qualifizierungspro-
gramme, Training und andere Formen der Mitarbeiterentwicklung gewinnen als Diffe-
renzierungsmerkmal und als Zukunftsinvestition in Human Resources an strategischer
Bedeutung.
Von wissenschaftlicher Seite muss dieses Bemühen durch die Entwicklung von Methoden
und Vorgehensweisen zur systematischen Analyse und Verbesserung des Systems
Produktionsbetrieb einschließlich der erforderlichen Dienstleistungsfunktionen unter-
stützt werden. Die Ingenieure sind hier gefordert, in enger Zusammenarbeit mit anderen
Disziplinen, z. B. der Informatik, der Wirtschaftswissenschaften und der Arbeitswissen-
schaft, Lösungen zu erarbeiten, die den veränderten Randbedingungen Rechnung
tragen.
Die von den Herausgebern langjährig geleiteten Institute, das
- Fraunhofer-Institut für Produktionstechnik und Automatisierung (IPA),
- Fraunhofer-Institut für Arbeitswirtschaft und Organisation (IAO),
- Institut für Industrielle Fertigung und Fabrikbetrieb (IFF), Universität Stuttgart,
- Institut für Arbeitswissenschaft und Technologiemanagement (IAT), Universität Stuttgart
arbeiten in grundlegender und angewandter Forschung intensiv an den oben aufgezeig-
ten Entwicklungen mit. Die Ausstattung der Labors und die Qualifikation der Mitarbeiter
haben bereits in der Vergangenheit zu Forschungsergebnissen geführt, die für die Praxis
von großem Wert waren. Zur Umsetzung gewonnener Erkenntnisse wird die Schriften-
reihe „IPA-IAO - Forschung und Praxis“ herausgegeben. Der vorliegende Band setzt diese
Reihe fort. Eine Übersicht über bisher erschienene Titel wird am Schluss dieses Buches
gegeben.
Dem Verfasser sei für die geleistete Arbeit gedankt, dem Jost Jetter Verlag für die
Aufnahme dieser Schriftenreihe in seine Angebotspalette und der Druckerei für saubere
und zügige Ausführung. Möge das Buch von der Fachwelt gut aufgenommen werden.
Engelbert Westkämper Hans-Jörg Bullinger Dieter Spath
Vorwort
Die vorliegende Arbeit entstand während meiner Tätigkeit als wissenschaftlicher Mitarbeiter am
Institut für Arbeitswissenschaft und Technologiemanagement der Universität Stuttgart (IAT) und am
Fraunhofer-Institut für Arbeitswirtschaft und Organisation (IAO).
Herrn Prof. Dr.-Ing. Dieter Spath, Leiter des Instituts für Arbeitswissenschaft und Technologie-
management der Universität Stuttgart (IAT) und des Fraunhofer-Instituts für Arbeitswirtschaft und
Organisation (IAO), gilt mein Dank für die wohlwollende Förderung der Arbeit und die Übernahme
des Hauptberichts.
Herrn Prof. Dr.-Ing. Prof. e.h. Dr.-Ing. e.h. Dr. h.c. mult. Engelbert Westkämper, Leiter des Instituts
für Industrielle Fertigung und Fabrikbetrieb (IFF) der Universität Stuttgart und des Fraunhofer-
Instituts für Produktionstechnik und Automatisierung (IPA), danke ich für die Übernahme des
Mitberichts meiner Arbeit.
Mein Dank gilt Priv.-Doz. Dr.-Ing. habil. Dipl.-Inform. Anette Weisbecker für die inhaltliche
Begleitung meiner Arbeit mit wertvollen Hinweisen und konstruktiver Kritik sowie die genaue
Durchsicht.
Stellvertretend für alle Kolleginnen und Kollegen bedanke ich mich bei Dr.-Ing. Henning Hinderer,
Dipl.-Inform. Joannis Vlachakis und Dipl.-Kffr. Anja Kirchhof für die fachlichen Diskussionen und
wissenschaftlichen Anregungen im Rahmen unserer gemeinsamen Arbeit am Institut. Dies gilt in
gleicher Weise auch für die zahlreichen wissenschaftlichen Hilfskräfte und Praktikanten, die mit ihrem
Einsatz und Engagement einen wertvollen Beitrag zur Projektarbeit des Competence Center Business
Integration leisten. Stellvertretend seien Herr Patrick Schweizer und Herr Erik Müller genannt, die
zum Gelingen eines der mit dieser Arbeit verbundenen Projekte beigetragen haben.
Ein ganz besonderer Dank gilt meinen Eltern, die mir meinen beruflichen Werdegang ermöglicht
haben und mich jederzeit unterstützen.
Ich danke Sonja Funk für ihre Geduld während der Entstehung neuer Ideen.
Stuttgart, im August 2006 Thorsten Gurzki
Inhaltsverzeichnis
Abbildungsverzeichnis .......................................................................................................................... 13
Tabellenverzeichnis............................................................................................................................... 15
Verzeichnis der verwendeten Abkürzungen.......................................................................................... 16
Verzeichnis der Komponentenabkürzungen.......................................................................................... 19
1 Einleitung...................................................................................................................................... 20
2 Motivation und Vorgehensweise .................................................................................................. 21
2.1 Übersicht und Betrachtungsraum......................................................................................... 21
2.2 Begriffsbestimmungen und Abgrenzung ............................................................................. 21
2.3 Vorgehensweise und Aufbau der Arbeit .............................................................................. 22
3 Stand der Wissenschaft und Technik............................................................................................ 24
3.1 Relevante Themenfelder ...................................................................................................... 24
3.2 Eigenschaften von Portalen.................................................................................................. 24
3.3 Leistungen und Organisation des Technischen Vertriebs .................................................... 26
3.3.1 Allgemeine Aufgabenstellung des Vertriebs ................................................................... 26
3.3.2 Leistungen des Technischen Vertriebs ............................................................................ 26
3.3.3 Organisation des Technischen Vertriebs ......................................................................... 28
3.3.4 Der internetbasierte Vertrieb ........................................................................................... 28
3.4 Ansätze zur softwaretechnischen Unterstützung des Technischen Vertriebs ...................... 29
3.5 Softwarearchitekturen für die Erstellung webbasierter Anwendungen................................ 31
3.5.1 Allgemeine Definition der Softwarearchitektur .............................................................. 31
3.5.2 Übersicht der Ansätze zur Realisierung webbasierter Anwendungen............................. 31
3.5.3 Aufbau webbasierter Architekturen................................................................................. 32
3.5.3.1 Der Komponentenbegriff ........................................................................................ 33
3.5.4 Common Gateway Interface ............................................................................................ 34
3.5.5 Eingebettete serverseitige Skriptsprachen ....................................................................... 34
3.5.6 Plattformen zur Erstellung webbasierter Anwendungen ................................................. 35
3.5.6.1 Sun ONE Architektur.............................................................................................. 35
3.5.6.2 Microsoft .NET Architektur.................................................................................... 37
3.5.6.3 Gegenüberstellung und Bewertung......................................................................... 37
3.6 Portalsoftwarearchitekturen ................................................................................................. 39
3.6.1 Übersicht und Anwendungsgebiete ................................................................................. 39
3.6.2 Grundlegende Funktion ................................................................................................... 39
3.6.3 Softwaretechnischer Aufbau und Module ....................................................................... 40
3.6.4 Gegenüberstellung und Bewertung.................................................................................. 42
3.7 Integrationsarchitekturen ..................................................................................................... 44
3.8 Architekturmodelle für Portale ............................................................................................ 46
10
3.8.1 Übersicht und Anwendungsgebiete ................................................................................. 46
3.8.2 Gegenüberstellung und Bewertung.................................................................................. 48
3.9 Zusammenfassung der Grundanforderungen und Defizite .................................................. 50
4 Entwicklung eines Architekturmodells für Portale im Technischen Vertrieb .............................. 51
4.1 Definition des Lösungsansatzes der Arbeit.......................................................................... 51
4.2 Vorgehen und Methodik zum Aufbau des Architekturmodells ........................................... 52
5 Prozessarchitektur für Portale....................................................................................................... 54
5.1 Übersicht und Eigenschaften ............................................................................................... 54
5.2 Ableitung der vertriebsrelevanten Portalprozesse................................................................ 54
6 Anwendungsarchitektur für Portale .............................................................................................. 57
6.1 Übersicht und Eigenschaften ............................................................................................... 57
6.2 Definition abstrakter Komponenten..................................................................................... 57
6.3 Schichtenmodell für Portale................................................................................................. 58
6.3.1 Definition der Abstraktionskriterien................................................................................ 58
6.3.2 Ableitung des Schichtenmodells...................................................................................... 58
6.3.3 Schichtenmodell im Kontext von Portalsoftware ............................................................ 60
6.4 Komponentenarchitektur für Portale.................................................................................... 61
6.4.1 Identifikation der Komponenten...................................................................................... 61
6.4.2 Komponenten der Schicht Portalanwendungskomponenten (PAK)................................ 61
6.4.2.1 Softwaretechnischer Aufbau................................................................................... 61
6.4.2.2 Darstellung von PAK auf Portalseiten .................................................................... 63
6.4.2.3 Ableitung der Portalanwendungskomponenten ...................................................... 64
6.4.3 Komponenten in der Schicht Portalsystemkomponenten (PSK) ..................................... 66
6.4.3.1 Softwaretechnischer Aufbau................................................................................... 66
6.4.3.2 Shop-Komponente (SHOP) .................................................................................... 66
6.4.3.3 Konfigurationskomponente (KONF) ...................................................................... 68
6.4.3.4 Content-Management-Komponente (CM).............................................................. 69
6.4.3.5 Produktberatungskomponente (BER) ..................................................................... 71
6.4.3.6 Community-Komponente (CMK)........................................................................... 72
6.4.4 Komponenten in der Schicht Betriebliche Informationskomponenten (BIK) ................. 72
6.4.4.1 Softwaretechnischer Aufbau................................................................................... 72
6.4.4.2 Customer-Relationship-Management-Komponente (CRK).................................... 73
6.4.4.3 Enterprise-Resource-Planning-Komponente (ERK)............................................... 74
6.4.4.4 Katalogdatenmanagementkomponente (KDM) ...................................................... 75
6.4.4.5 Dokumentenmanagementkomponente (DM).......................................................... 75
6.4.4.6 Workflow-Management-Komponente (WFM)....................................................... 77
6.4.4.7 Groupware-Komponente (GPW) ............................................................................ 77
6.4.4.8 Autorisierungs- und Authentifizierungskomponente (AUTH) ............................... 78
11
7 Datenarchitektur für Portale ......................................................................................................... 80
7.1 Übersicht und Eigenschaften ............................................................................................... 80
7.2 Charakterisierung der Daten und Ableitung des statischen Datenmodells .......................... 80
7.3 Darstellung und Erweiterung der Notation .......................................................................... 81
7.4 Grunddatenmodell Konfiguration ........................................................................................ 81
7.5 Grunddatenmodell Katalog .................................................................................................. 82
7.6 Grunddatenmodell Kommunikation, Kooperation und Unternehmensinformation............. 83
7.7 Grunddatenmodell Transaktion............................................................................................ 84
7.8 Weitere Grunddatenmodelle ................................................................................................ 85
8 Infrastrukturarchitektur für Portale............................................................................................... 86
8.1 Übersicht und Eigenschaften ............................................................................................... 86
8.2 Beschreibung der softwaretechnischen Portalinfrastruktur ................................................. 86
8.2.1 Schnittstellen zwischen Portalsoftware und PAK ........................................................... 86
8.3 Modell für die Suche im Portal ............................................................................................ 87
8.3.1 Definition des Suchraums und Einbindung der Suche .................................................... 87
8.3.2 Konsolidierung und Darstellung der Ergebnisse ............................................................. 88
8.4 Authentifizierungs- und Rollenmodell................................................................................. 89
8.4.1 Verwaltung von Nutzern, Rechten und Rollen................................................................ 89
8.4.2 Authentifizierungsebenen und Single-Sign-On-Verfahren ............................................. 90
8.5 Personalisierungs- und Individualisierungsmodell .............................................................. 91
8.5.1 Definition von Prozesszielgruppen.................................................................................. 93
8.6 Modell für die Abbildung von Komponenten...................................................................... 94
9 Kommunikationsarchitektur für Portale ....................................................................................... 96
9.1 Eigenschaften und Übersicht ............................................................................................... 96
9.2 Schnittstellenmodell für Portale........................................................................................... 96
9.3 Entwicklung von Komponentenintegrationsmustern für Portale ......................................... 98
9.4 Datenformatmodell für den Datenaustausch in Portalen ................................................... 100
9.4.1 Interne und externe Datenstrukturen ............................................................................. 100
9.4.2 Allgemeine Dokumentenformate................................................................................... 100
9.4.3 Standards für den Austausch von Katalogen und Geschäftsdokumenten...................... 101
9.5 Bewertung der Einsatzmöglichkeit im Architekturmodell ................................................ 102
9.6 Entwicklung von Adaptions- und Transformationsmethoden ........................................... 105
9.6.1 Verfahren zur Transformation von Datenstrukturen ..................................................... 106
9.6.2 Verfahren zur Adaption von HTML auf Präsentationsebene ........................................ 106
9.6.2.1 Adaptionsmethodik: Maskierung.......................................................................... 106
9.6.2.2 Adaptionsmethodik: Selektion.............................................................................. 107
9.6.2.3 Adaptionsmethodik: Aggregation ......................................................................... 107
9.6.2.4 Adaptionsmethodik: URL-Rewriting.................................................................... 107
12
9.6.3 Verfahren zur Transformation von XML-Dokumenten ................................................ 108
10 Methodik zur Anwendung des Architekturmodells.................................................................... 110
10.1.1 Übersicht und Vorgehen............................................................................................ 110
10.1.2 Architekturanwendung im Wasserfallmodell............................................................ 110
11 Einsatz und Evaluation des Architekturmodells......................................................................... 113
11.1 Bedeutung und Kriterien.................................................................................................... 113
11.2 Portalarchitektur für den Vertrieb von Elektrowerkzeugen ............................................... 113
11.2.1 Ausgangssituation des Technischen Vertriebs .......................................................... 113
11.2.2 Zielsetzung ................................................................................................................ 114
11.2.3 Projektvorgehen ........................................................................................................ 114
11.2.4 Prozessarchitektur ..................................................................................................... 114
11.2.5 Anwendungsarchitektur ............................................................................................ 115
11.2.6 Datenarchitektur ........................................................................................................ 118
11.2.7 Kommunikationsarchitektur...................................................................................... 119
11.2.8 Infrastrukturarchitektur ............................................................................................. 122
11.2.8.1 Personalisierung und Individualisierung............................................................... 122
11.2.8.2 Authentifizierung und Umsetzung Single Sign On............................................... 122
11.2.8.3 Suche..................................................................................................................... 123
11.2.8.4 Abbildung der Komponenten auf Systeme ........................................................... 123
11.2.8.5 Maßnahmen zur Anpassung der Systeme ............................................................. 124
11.3 Weitere Anwendungsszenarien.......................................................................................... 125
11.4 Evaluation des Architekturmodells .................................................................................... 126
12 Zusammenfassung ...................................................................................................................... 129
12.1 Zusammenfassung der Ergebnisse ..................................................................................... 129
12.2 Ausblick und weitere Entwicklungen ................................................................................ 130
13 Summary..................................................................................................................................... 132
14 Literatur und Quellen.................................................................................................................. 134
Anhang A – Portalarten im Unternehmenskontext ............................................................................. 153
Anhang B – Überblick über eingebettete Skriptsprachen ................................................................... 154
Anhang C – Standards im Bereich Portale .......................................................................................... 155
Anhang D – Ergebnisse der Unternehmensbefragung ........................................................................ 156
Anhang E – Prozessübersicht .............................................................................................................. 158
Anhang F – Funktionskarten für Komponenten.................................................................................. 163
Anhang G – Weitere Datenmodelle .................................................................................................... 170
Anhang H – Authentifizierungsstati für die Prozesse des Architekturmodells ................................... 173
Anhang I – Beispielvorgang Adaption ................................................................................................ 174
Anhang J – Anwendungsfall Komponentenlandkarte PAK................................................................ 175
Abbildungsverzeichnis
Abbildung 1: Aufbau und Vorgehen der Arbeit.................................................................................... 23
Abbildung 2: Untersuchungsbereich des Stands der Wissenschaft und Technik.................................. 24
Abbildung 3: Ebenen der Portaleigenschaften ...................................................................................... 26
Abbildung 4: Der Vertriebsprozess nach Brandstetter und Fries .......................................................... 26
Abbildung 5: Betrachtungsraum für Ansätze zur Realisierung webbasierter Anwendungen ............... 32
Abbildung 6: Aufbau von 3-Schicht-Architekturen, 4-Schicht-Architekturen und 4-Schicht-
Architekturen mit EAI/Middleware ................................................................................ 32
Abbildung 7: CGI-Anwendungsarchitektur .......................................................................................... 34
Abbildung 8: Architektur mit eingebettetem Skriptsprachen-Application-Server ................................ 35
Abbildung 9: Architektur von J2EE...................................................................................................... 36
Abbildung 10: Aggregation mit PVK am Beispiel Portlets .................................................................. 40
Abbildung 11: Referenzarchitektur für Portalsoftware ......................................................................... 42
Abbildung 12: Aufbau von Architekturmodellen am Beispiel der ISA ................................................ 46
Abbildung 13: Elemente und Aufbau des erweiterten Portalarchitekturmodells auf Basis der ISA..... 52
Abbildung 14: Schichtenmodell des Architekturmodells...................................................................... 59
Abbildung 15: Schichtenmodell im Kontext von Portalsoftware.......................................................... 61
Abbildung 16: Model-View-Controller-Schema im Kontext des Portals ............................................. 62
Abbildung 17: Darstellung von PAK mit verschiedenen PVK ............................................................. 63
Abbildung 18: Grunddatenmodell Konfiguration ................................................................................. 82
Abbildung 19: Grunddatenmodell Katalog ........................................................................................... 83
Abbildung 20: Grunddatenmodell Kooperation, Kommunikation, Unternehmensinformation............ 84
Abbildung 21: Grunddatenmodell Transaktion..................................................................................... 85
Abbildung 22: PAK-spezifische Einzelsuche und integrierte Portalsuche. Darstellung
an Beispielen. ................................................................................................................ 88
Abbildung 23: Authentifizierungsebenen der Portalarchitektur............................................................ 90
Abbildung 24: Gegenüberstellung: Personalisierung von Websites nach Leimstoll/Schubert
und abgeleitete Personalisierung von Portalen für den Technischen Vertrieb .............. 92
Abbildung 25: Ausprägung der Personalisierung und Individualisierung auf Komponentenebenen ... 93
Abbildung 26: Bestandteile der Kommunikationsarchitektur ............................................................... 96
Abbildung 27: Schnittstellenmodell mit Kommunikationspfaden ........................................................ 97
Abbildung 28: Maskierung mit Tags................................................................................................... 107
Abbildung 29: Selektion mit Tags....................................................................................................... 107
Abbildung 30: Aggregation mit Tags.................................................................................................. 107
Abbildung 31: XSLT-Transformation in einer PAK zur Darstellung von HTML.............................. 109
Abbildung 32: Anwendungsbereich des Architekturmodells im Kontext des Wasserfallmodells...... 110
Abbildung 33: UML-Aktivitätendiagramm für den Vorgehensprozess zur Anwendung des
Architekturmodells ...................................................................................................... 112
14
Abbildung 34: Kundenszenario des Anwendungsfalls........................................................................ 114
Abbildung 35 Unternehmensspezifische Ausprägung des Schichtenmodells für das
Vertriebsportal.............................................................................................................. 115
Abbildung 36: Portal-MVC am Beispiel der Portalanwendungskomponente PWB ........................... 116
Abbildung 37: Ansicht einer Portalseite mit zwei Portalvisualisierungskomponenten (PVK) der
Portalanwendungskomponente (PAK) PWB und einer Portalvisualisierungs-
komponente (PVK) der Portalanwendungskomponente (PAK) UINF ....................... 117
Abbildung 38: Ansicht der Bearbeitung von Content in der Portalsystemkomponente (PSK) CM.... 117
Abbildung 39: Ausprägung des Grunddatenmodells am Beispiel Transaktion (Teilmodell) ............. 119
Abbildung 40: Übersicht der Anwendungs- und Kommunikationsarchitektur im Anwendungsfall .. 120
Abbildung 41: Kommunikation am Beispiel der Portalanwendungskomponenten (PAK) SHOP
und KNF...................................................................................................................... 121
Abbildung 42: Ansicht einer Portalseite mit Portalvisualisierungskomponenten (PVK) der
Portalanwendungskomponenten (PAK) KAT, KNF und UINF.................................. 121
Abbildung 43: Portalarten im Unternehmenskontext.......................................................................... 153
Abbildung 44: Priorisierung von Prozessen/Anwendungen................................................................ 156
Abbildung 45: Grunddatenmodell PAK Produktwahlunterstützung und Beratung ............................ 170
Abbildung 46: Grunddatenmodell Dokumente und Contentverwaltung............................................. 171
Abbildung 47: Grunddatenmodell Autorisierung................................................................................ 172
Abbildung 48: Beispielvorgang Adaption........................................................................................... 174
Tabellenverzeichnis
Tabelle 1: Beschreibung der Anwendungseigenschaften von Portalen................................................. 25
Tabelle 2: Zusammenfassung: Beschreibung der Leistungen des Technischen Vertriebs.................... 27
Tabelle 3: Funktion und Bewertung vertriebsunterstützender Systeme................................................ 30
Tabelle 4: Definitionen des Begriffs Softwarearchitektur..................................................................... 31
Tabelle 5: Definitionen des Begriffs Komponente................................................................................ 33
Tabelle 6 Gegenüberstellung und Bewertung der Ansätze zur Realisierung webbasierter
Anwendungen........................................................................................................................ 38
Tabelle 7: Darstellung und Bewertung von Portalsoftware................................................................... 43
Tabelle 8: Darstellung und Bewertung von Integrationsarchitekturen.................................................. 45
Tabelle 9: Vergleich und Bewertung der Architekturmodelle für Portale ............................................ 49
Tabelle 10: Definition der Detailziele der Arbeit.................................................................................. 51
Tabelle 11: Prozessarchitektur in Form der Portalprozesslandkarte ..................................................... 55
Tabelle 12: Übersicht der Prozessbündel .............................................................................................. 56
Tabelle 13: Portalanwendungslandkarte................................................................................................ 65
Tabelle 14: Bewertung von Darstellungsmethoden für Suchergebnisse ............................................... 89
Tabelle 15: Rollengattungen im Portalkontext...................................................................................... 94
Tabelle 16: Komponentenabbildungsmatrix mit Bewertung der Abbildung auf Systemklassen.......... 95
Tabelle 17: Integrationsmuster für Portale .......................................................................................... 104
Tabelle 18: Bewertung der Eignung von Datenformaten und Integrationsmuster für wesentliche
Datenklassen..................................................................................................................... 105
Tabelle 19: Abbildung der Komponenten auf Systeme....................................................................... 124
Tabelle 20: Überblick über gängige eingebettete Skriptsprachen ....................................................... 154
Tabelle 21: Darstellung, Gegenüberstellung und Bewertung der Standards im Bereich Portale ........ 155
Tabelle 22: Priorisierung von Prozessen/Anwendungen..................................................................... 157
Tabelle 23: Authentifizierungsstati für die Prozesse des Architekturmodells..................................... 173
Tabelle 24: Anwendungsfall Komponentenlandkarte PAK ................................................................ 175
Verzeichnis der verwendeten Abkürzungen
AAW Auftragsabwicklung
AE Anwendungseigenschaft
API Application Programming Interface
ARIS Architektur integrierter Informationssysteme
BAPI Business Application Programming Interface
BIK Betriebliche Informationskomponente
BIS Betriebliche Informationssysteme
CAS Computer Aided Selling
CGI Common Gateway Interface
CLR Common Language Runtime
CMF Content Management Framework
CMS Content-Management-System
COM Component Object Model
CORBA Common Object Request Broker Architecture
CPF Corporate Portal Framework
CPI-C Common Programming Interface for Communications
CRM Customer-Relationship-Management
CSCW Computer Supported Collaborative Work
CSS Cascading Style Sheets
CSV Comma Separated Values (auch: Character Separated Values)
CTS Common Type System
cXML Commerce XML
DB Datenbank
DBMS Datenbank-Management-System
DCE Distributed Computing Environment
DCOM Distributed Component Object Model
DIN Deutsches Institut für Normung e.V.
DLM Document-Lifecycle-Management
DMS Dokumentenmanagement-System
DRT Document Related Technologies
DTD Document Type Definition
DV Datenverarbeitung
EAI Enterprise Application Integration
ebXML Electronic Business XML
ECM Enterprise-Content-Management
EDI Enterprise Data Interchange
17
EDM Engineering-Data-Management
EDV Elektronische Datenverarbeitung
EJB Enterprise Java Beans
ER Entity-Relationship
ERP Enterprise Resource Planning
FastCGI Fast Common Gateway Interface
FO Formatting Objects
HTML Hypertext Markup Language
HTTP Hypertext Transfer Protocol
HW Hardware
IDL Interface Definition Language
IL Intermediate Language
IP Internet Protocol
ISA Informationssystemarchitektur
ISO International Organisation for Standardization
J2EE Java 2 Platform Enterprise Edition
JCA Java Connector Architecture
JCP Java Community Process
JDBC Java Database Connectivity
JDBC Java Database Connectivity
JIT Just-in-Time Compiler
JMS Java Message Service
JNDI Java Naming and Directory Interface
JSR Java Specification Requests
JVM Java Virtual Machine
KM Knowledge-Management
KMU Kleine und mittelständische Unternehmen
LDAP Lightweight Directory Access Protocol
MOM Message Oriented Middleware
MSIL Microsoft Intermediate Language
MSMQ Microsoft Message Queue
MVC Model-View-Controller
OASIS Organization for the Advancement of Structured Information Standards
ODBC Open Database Connectivity
OLAP Online Analytical Processing
OMG Object Management Group
PAK Portalanwendungskomponente
PDF Portable Document Format
18
PDM Product-Data-Management
PRICAT Price/Sales Catalogue
PSK Portalsystemkomponente
PVK Portalvisualisierungskomponente
RFC Remote Function Call
RPC Remote Procedure Call
SGML Standard Generalized Markup Language
SOAP Simple Object Access Protocol
SSO Single Sign On
SW Software
TAD Technischer Außendienst
TCP Transmission Control Protocol
TF Technische Funktionalität
TID Technischer Innendienst
TU Technische Unterstützung
UML Unified Modeling Language
UN/CEFACT United Nations Centre for Trade Facilitation and Electronic Business
UN/EDIFACT United Nations Electronic Data Interchange For Administration,
Commerce and Transport
URL Uniform Resource Locator
VAD Vertriebsaußendienst
VDI Verband Deutscher Ingenieure
VID Vertriebsinnendienst
WSRP Web Services for Remote Portlets
xCBL XML Common Business Library
XLINK XML Linking Language
XML Extensible Markup Language
XSD XML Schema Definition
XSL Extensible Stylesheet Language
XSLT XSL Transformations
Verzeichnis der Komponentenabkürzungen
AUTH Autorisierungs- und Authentifizierungskomponente
BER Produktberatungskomponente
CM Content-Management-Komponente
CMK Community-Komponente
CRK Customer-Relationship-Management-Komponente
DM Dokumentenmanagementkomponente
ERK Enterprise-Resource-Planning-Komponente
GPW Groupware-Komponente
KAT Portalanwendungskomponente Katalog
KDM Katalogdatenmanagementkomponente
KNF Portalanwendungskomponente Konfiguration
KOMM Portalanwendungskomponente Kommunikation
KONF Konfigurationskomponente
KOOP Portalanwendungskomponente Kooperation
PORT Portalumgebung (Portalsoftware)
PWB Portalanwendungskomponente Produktwahlunterstützung und Beratung
SHOP Shop-Komponente
SUCHE Portalanwendungskomponente Suche
TRANS Portalanwendungskomponente Transaktion
UINF Portalanwendungskomponente Unternehmensinformation
WFM Workflow-Management-Komponente
1 Einleitung
Die alleinige Fokussierung auf Innovation, Produktqualität und Preis im Marketing und Vertrieb von
Industriegütern genügt den aktuellen Marktanforderungen nicht mehr. Die Anbieter von Gütern
werden gefordert, in Kundennutzen-Kategorien zu denken [Backhaus 2003]. Diese Forderung wird
durch die Verschärfung des Wettbewerbs im Zuge der Entwicklung der Informationsgesellschaft, mit
der Möglichkeit Produkte und Angebote informationssystemgestützt oder automatisiert zu
vergleichen, weiter gestärkt. Die Methoden und Technologien des E-Business stellen dabei eine
effiziente Möglichkeit zur Schaffung von verstärkter Kundenansprache und -orientierung in Vertrieb
und Marketing dar. Mehr als 76 Prozent der Unternehmen sehen in diesem Anwendungsbereich eine
steigende Bedeutung von E-Business [Kelkar et al. 2003].
Die Kundenorientierung und damit der Kundennutzen wird als Alleinstellungsmerkmal zu einem
wesentlichen Faktor für den Erfolg eines Unternehmens am Markt [Picot et al. 2003],
[Westkämper 2001]. Personalisierte und auf die Kundenbedürfnisse bzw. Zielsegmente angepasste
Prozesse und Leistungen stellen ein wichtiges Merkmal für die Differenzierung vom Wettbewerber
dar. Parallel zur Steigerung der Kundenbindung ist die Steigerung der Effizienz des Vertriebs eine
weitere Herausforderung für Unternehmen. Zu den bestimmenden Faktoren gehören in diesem
Teilbereich die Senkung der Kosten für Kundenkontakte, kurze Prozessausführungszeiten und
aufeinander abgestimmte Kontaktkanäle [Alt et al. 2004]. Diese allgemeinen Anforderungen
manifestieren sich im besonderen Maße im Vertrieb technischer Produkte. Dieser weist mit
verschiedenen Vertriebszielgruppen innerhalb der Kundschaft (z. B. Verwender, Entscheider,
Einkäufer), heterogenen Käufermärkten und der Einbeziehung sowohl standardisierter als auch
individueller Produkte hohe Anforderungen bezüglich Kundenorientierung und Effizienz auf (vgl.
[Bonart 1999], [Kleinaltenkamp 2000]). Grundlage für Verbesserungen in diesen Problembereichen
des Technischen Vertriebs ist die Bereitstellung einer homogenen Kundenschnittstelle, welche die
kundennahen Prozesse eines Unternehmens für Kunden personalisiert und integriert bereitstellt. Aus
informationslogistischer Betrachtungsweise ist eine abstrahierte und kombinierte Sicht auf die
Informationen in bestehenden Systemen notwendig (vgl. [Spath 2003]). Portale bilden durch die
Integration kundenorientierter Prozesse entlang der hierfür notwendigen Anwendungen eine
Basistechnologie zur Realisierung [Puschmann und Alt 2004]. Neben einer Kostenreduktion, z. B.
durch Verlagerung des Service auf automatisierte portalbasierte Verfahren, lässt sich eine
Dynamisierung von Preisen und Produkten erreichen [Grimm 2004].
Den Vorteilen eines Portals für den Technischen Vertrieb steht die grundlegende Problematik
gegenüber, dass für die Umsetzung von Portalen am Markt keine umfassenden Standard-
softwareprodukte verfügbar sind (vgl. [Bullinger 2002]). Die angebotene Software stellt
Grundfunktionen für die Realisierung von Portalen zur Verfügung. Daher ist für Unternehmen die
Notwendigkeit gegeben, die Systeme der betrieblichen Informationssysteminfrastruktur im Rahmen
einer individuellen Portalarchitektur zu integrieren [Leser et al. 2004]. Eine Integration führt jedoch
mit der zunehmenden Zahl der hierfür relevanten Bestandssysteme zu einer hohen Komplexität der
Gesamtarchitektur [Schelp und Winter 2002].
Als grundlegende Herausforderung für Unternehmen und insbesondere deren Datenverarbeitungs-
abteilungen stellt sich die Definition einer Portalarchitektur dar, die in einem ganzheitlichen Ansatz
auch das Thema der Integration abdecken muss [META Group 2002].
2 Motivation und Vorgehensweise
2.1 Übersicht und Betrachtungsraum
Die vorliegende Arbeit fokussiert das Themenfeld des Entwurfs integrativer Portalarchitekturen für
den speziellen Anwendungsfall des Technischen Vertriebs aus softwaretechnischer Sicht. Hierfür
untersucht die Arbeit bestehende Architekturen auf ihre Bedeutung und Eignung für den
softwaretechnisch orientierten Entwurf eines Portals und entwickelt eine Architektur, die den
Anforderungen des Technischen Vertriebs genügt.
Der Untersuchungsbereich teilt sich somit auf in die Fachebene mit der Betrachtung der Leistungen
und Organisation des Technischen Vertriebs als Anwendungsfeld sowie in die Architekturebene mit
der Betrachtung bestehender Architekturen für die Erstellung integrativer Anwendungen.
2.2 Begriffsbestimmungen und Abgrenzung
Der Vertrieb umfasst insbesondere den Bereich des Absatzes, unter dem die Vorbereitung, Anbahnung
und Abwicklung vertriebs- und absatzbezogener Tätigkeiten verstanden wird [Bullinger 1995]. Er
befasst sich u. a. mit der Pflege der Beziehungen zwischen Hersteller und Handel bzw. Kunden
[Schneck 1998]. Entsprechend ist der Vertrieb in dieser Arbeit aus betriebswirtschaftlicher Sicht zu
verstehen. Der Technische Vertrieb ist durch seine Fokussierung auf gewerbliche Abnehmer
charakterisiert. Der Begriff des Technischen Vertriebs mit seinem Bezug zu Industriegütern lässt sich
anhand seiner englischen Übersetzung „Industrial Marketing“ verdeutlichen [Pepels 1998].
Die Arbeit behandelt den Teilbereich Service im Rahmen seiner Notwendigkeit für den Technischen
Vertrieb (vgl. [Westkämper und Warnecke 2004]). Hierbei werden die Begriffe After Sales Support,
Kundendienst und Service im Kontext der Arbeit synonym verwendet (vgl. [Vasen 2003]). Die
vorliegende Abhandlung grenzt sich an dieser Stelle gegenüber dem über den reinen Vertrieb
hinausgehenden Service, z. B. in den Bereichen Wartung, Fernwartung im Kundendienst und
Instandhaltung für Anlagen, ab. Der Vertrieb wird von einer Vielzahl verschiedenartiger
Softwaresysteme, wie z. B. Warenwirtschafts- oder Customer-Relationship-Management-Systeme
unterstützt (vgl. [Gurzki und Özcan 2003]). Diese sind im Falle des Vertriebs Teil des
Vertriebssystems und damit der Vertriebspolitik eines Unternehmens [Winkelmann 2002].
Eine Architektur legt als ein allgemeines Konzept einen grundlegenden Aufbau fest, der in
verschiedenen konkretisierenden Entwürfen und den hierauf basierenden Umsetzungen Verwendung
finden kann. Eine Architektur kann verschiedene Aspekte wie z. B. Prozesse oder Systeme
beschreiben. Sie besteht aus Mustern, einem Leitfaden oder einem formalen Modell. Architekturen
haben verschiedene Ausprägungsgrade, die sich insbesondere in den Attributen Fokussierung
(Teilsicht – Gesamtsicht), Abstrahierungsgrad (Detailsicht – Übersicht) und Spezialisierungsgrad
(generisch – spezifisch) niederschlagen [Britton 2001].
Der Begriff der Architektur tritt in dem betrachteten Umfeld in verschiedenen Formen auf. Eine
spezialisierte Form einer Architektur ist ein Architekturmodell. Dieses umfasst verschiedene
Teilsichten, die verschiedene Architekturaspekte einer Anwendung in Teilarchitekturen darstellen
[Scheer 1998a], [Krcmar 2003]. Der Begriff Architekturmodell wird in dieser Arbeit im Sinne des
Modells der ganzheitlichen Informationssystemarchitektur nach [Krcmar 2003] verstanden. Diese
enthält Elemente der Geschäftsstrategie, der Prozess-, Anwendungs-, Daten- und
22
Kommunikationsarchitektur sowie der Infrastruktur. Der Begriff des Architekturmodells wird in
Kapitel 3.8 detailliert. Eine weitere Form einer Architektur ist die Softwarearchitektur. Sie beschreibt
die Struktur eines Systems mit seinen Komponenten und deren Beziehungen untereinander [Balzert
2000]. Die Beschreibung der Komponenten und der Beziehungen kann durch eine Anwendungs-,
Daten- und Kommunikationsarchitektur erfolgen. Eine Softwarearchitektur ist somit ein Bestandteil
eines Architekturmodells.
Unter dem Begriff webbasierte Anwendungen werden Applikationen mit einer grafischen Oberfläche
verstanden, die auf World-Wide-Web-Technologien basieren [Theis 2003]. Eine derartige Anwendung
ist entsprechend einer Client/Server-Struktur organisiert, wobei der Client in dieser Spezialisierung
aus einem Web Browser besteht. Die Verbindungen, die der Client zum Server aufbaut, sind dabei in
der Regel temporär [Balzert 2000]. Als Protokoll für die Verbindungen wird das Hypertext Transfer
Protocol (HTTP) eingesetzt [Brown et al. 2001].
Unter dem Begriff Portale werden webbasierte Anwendungen zusammengefasst, die verschiedene
Informationsquellen und Anwendungen in einer homogenen Benutzungsoberfläche integrieren
[Gloor 2000], [Rütschlin 2001]. Hierbei kommt dem Aspekt der Personalisierung eine besondere
Bedeutung zu [Österle 2002]. Eine Charakterisierung der Eigenschaften von Portalen erfolgt in
Kapitel 3.2.
2.3 Vorgehensweise und Aufbau der Arbeit
Einleitend wird in Kapitel 2 zunächst die Motivation der Arbeit erläutert, der Betrachtungsrahmen
definiert und ein Überblick über die Vorgehensweise gegeben. Kapitel 3 untersucht den Stand der
Wissenschaft und Technik in den Bereichen Portale und Technischer Vertrieb. Als Grundlage werden
die Eigenschaften von Portalen sowie die Leistung und Organisation des Technischen Vertriebs
eingehender betrachtet. Eine Untersuchung des Softwareeinsatzes im Technischen Vertrieb ergänzt
diesen Bereich.
Aus technischer Perspektive werden die Bereiche Softwarearchitekturen für webbasierte
Anwendungen, Integrationsarchitekturen und Portalsoftwarearchitekturen behandelt. Aufbauend
hierauf erfolgt eine Bewertung von Standards im Bereich Portale und Portalarchitekturmodelle. Den
Abschluss des Kapitels bildet die Identifikation der resultierenden Grundanforderungen an ein Portal
und der Defizite des Stands der Wissenschaft und Technik.
In Kapitel 4 wird ein Architekturmodell für Portale entwickelt. Hierzu werden zunächst ein
Lösungsansatz definiert, die Detailziele festgelegt und das Vorgehen und die Methodik zum Aufbau
des Architekturmodells beschrieben.
Die Prozessarchitektur des Modells wird in Kapitel 5 und die Anwendungsarchitektur in Kapitel 6
entwickelt. Aufbauend auf die Anwendungsarchitektur leitet Kapitel 7 die Datenarchitektur ab. Kapitel
8 und 9 definieren die Infrastruktur- bzw. Kommunikationsarchitektur. Die Anwendbarkeit des
Modells wird durch eine in Kapitel 10 beschriebene Methodik zur Anwendung des Architekturmodells
sichergestellt.
Die Evaluierung des Architekturmodells erfolgt in Kapitel 11 anhand einer ausführlich dargestellten
praktischen Anwendung der Portalarchitektur für den Vertrieb von Elektrowerkzeugen sowie weiteren
zusammengefassten ausgewählten Szenarien.
Kapitel 12 fasst die Arbeit zusammen und gibt einen Ausblick auf weitere Entwicklungen.
23
Abbildung 1: Aufbau und Vorgehen der Arbeit
3 Stand der Wissenschaft und Technik
3.1 Relevante Themenfelder
Aus der Festlegung des Betrachtungsraums mit der Fachebene, die die Leistungen und Organisation
des Technischen Vertriebs umfasst, sowie mit der Architekturebene, die eine Betrachtung bestehender
Architekturen für die Erstellung integrativer Anwendungen durchführt, leitet sich der
Untersuchungsbereich des Stands der Wissenschaft und Technik ab. Der Untersuchungsbereich mit
den relevanten Themenfeldern und deren Abhängigkeiten wird in Abbildung 2 dargestellt.
definiert fachliche
Anforderungen
Eigenschaften von
Portalen
Standards im Bereich
Portale
Architekturmodelle
für Portale
Integrations-
architekturen
Ansätze für die
Erstellung
webbasierter
Anwendungen
Ansätze zur
softwaretechnischen
Unterstützung des
Technischen
Vertriebs
Leistung und
Organisation des
Technischen
Vertriebs
implementiert
verwendet
verwendet
verwendet
benötigt definiert
Eigenschaften
stellt integriert
bereit
verwendet
basiert auf
verwendet
Portalsoftware-
architekturen
Abbildung 2: Untersuchungsbereich des Stands der Wissenschaft und Technik
Die Eigenschaften von Portalen bilden die Grundlage für die Betrachtung des Stands der Wissenschaft
und Technik und stellen einen wesentlichen Teil der Kriterien für die Bewertung, insbesondere für die
Architekturmodelle für Portale, bereit. Die Leistung und Organisation des Technischen Vertriebs
definiert die fachlichen Anforderungen an Architekturmodelle für Portale. Gleichzeitig ist der
Technische Vertrieb auf eine softwaretechnische Unterstützung bei seiner Leistungserbringung
angewiesen. Teile der dort eingesetzten Systeme verwenden zur Realisierung Ansätze für die
Erstellung webbasierter Anwendungen. Portalsoftwarearchitekturen basieren auf diesen Ansätzen und
erweitern diese um portalspezifische Funktionen. Dabei implementieren sie wesentliche Standards im
Bereich Portale. Integrationsarchitekturen werden von Portalsoftwarearchitekturen und für die
Erstellung webbasierter Anwendungen verwendet. Architekturmodelle für Portale stellen die in der
softwaretechnischen Unterstützung des Technischen Vertriebs enthaltenen Anwendungen integriert
bereit. Sie verwenden die Ansätze für die Erstellung webbasierter Anwendungen und
Portalsoftwarearchitekturen. In den folgenden Kapiteln werden die einzelnen Themenfelder in Bezug
auf den Untersuchungsraum eingeordnet und anhand von abgeleiteten Kriterien bewertet.
3.2 Eigenschaften von Portalen
Klassische Extranet/Internet-Konzepte beruhen auf statischen HTML-Seiten bzw. auf Content-
Management-Systemen und binden bestehende Anwendungen inhomogen ein. Portale sind eine
Weiterentwicklung dieser Konzepte und stellen umfangreichere funktionale Anforderungen, die in
25
einem Architekturmodell zu berücksichtigen sind. Ein Portal ist der zentrale Einstiegspunkt in die
öffentlichen Seiten bzw. zu den nicht öffentlichen Angeboten einer Organisation [Bauer 2001]. In
Portalen werden Informationen und Anwendungen integriert [Gloor 2000]. Die Integration der
heterogenen Quellen erfolgt derart, dass sie in einer homogenen Oberfläche dargestellt werden können
[Rütschlin 2001]. Durch die Integration verschiedener Informationsquellen und Applikationen in
einem Portal lässt sich der Integrationscharakter über die reinen Inhalte und Applikationen hinaus auf
die Ebene der Geschäftsprozesse erweitern [SAP 2002]. Portale besitzen eine starke
Prozessorientierung und fassen alle für einen Kundenprozess erforderlichen Services zusammen
[Österle 2002]. Die vorliegende Arbeit versteht den Begriff Portal, aufbauend auf der grundlegenden
Definition aus Kapitel 2.2 und den in Tabelle 1 zusammengefassten Anwendungseigenschaften, als
internetbasierte Anwendung mit den Eigenschaften Personalisierung und Rollenorientierung,
Benutzermanagement, Prozessorientierung, Integration und Homogenität.
Anforderung Beschreibung
Internetbasiert - Ein Portal basiert auf Internet- und World-Wide-Web-Technologien
[Collins 2001], [Bauer 2001].
Personalisierung und
Rollenorientierung
- Portale ermöglichen eine Personalisierung der angebotenen
Informationen und Applikationen entsprechend der Aufgaben und
Präferenzen des Nutzers [Rütschlin 2001].
- Portale basieren auf Rollen [Dias 2001].
Benutzermanagement - Portale enthalten ein strukturiertes Benutzermanagement
[Lixenfeld 2003].
Prozessorientierung - Portale ermöglichen den Zugriff auf Geschäftsprozesse [SAP 2002]
- Portale fassen alle für einen Kundenprozess erforderlichen Services
zusammen [Österle 2002].
- Ein Portal ermöglicht die Unterstützung zwischenbetrieblicher
Geschäftsprozesse [Hinderer und Gurzki 2003].
Integration - Ein Portal ist eine Integrationsplattform für Informationen und
Applikationen [Gloor 2000], [Davydov 2001].
Homogenität - Darstellung von Informationen und Anwendungen in einer homogenen
Benutzungsoberfläche [Rütschlin 2001].
Tabelle 1: Beschreibung der Anwendungseigenschaften von Portalen
Portale lassen sich anhand ihrer thematischen Ausrichtung klassifizieren. Horizontale Portale decken
größere thematische Bereiche ab und sprechen breite Nutzergruppen an. Sie bieten Suchfunktionen für
Web-Inhalte, Katalogisierungen von allgemeinen Web-Inhalten und weitere Funktionen, wie
z. B. Diskussionsforen, an [Gloor 2000]. Die Inhalte vertikaler Portale konzentrieren sich auf ein
einzelnes Segment des Informationsraums [Rütschlin 2001]. Hierzu gehört insbesondere der Bereich
Unternehmensportale, der sich entsprechend einer Zielgruppenorientierung in die Bereiche
Geschäftskunden-, Mitarbeiter- und Lieferantenportale untergliedert (grafische Darstellung in
Anhang A) [Bullinger 2002]. Im Fokus der Unternehmensportale steht der zentrale,
zielgruppenspezifische, personalisierte Zugang zu relevanten Informationen, Applikationen und
Geschäftsprozessen eines Unternehmens [Schneider und Zwerger 2002]. Die vorliegende Arbeit ist
entsprechend im Kontext der vertikalen Portale den Geschäftskundenportalen zuzuordnen.
Die Portaleigenschaften beziehen sich nicht ausschließlich auf die Ebene der
Anwendungseigenschaften (AE) eines Portals, die für den Benutzer sichtbar sind. Die in Tabelle 1
26
aufgeführten Teileigenschaften stellen auch technische Eigenschaften dar, die durch Funktionen
realisiert werden. Unter einer technischen Funktionalität (TF) lassen sich alle von einer Software
bereitgestellten Funktionen zusammenfassen, die unmittelbar zur technischen Realisierung der
zugehörigen Portalanwendungseigenschaft beitragen. Die Erstellung von Portalen und der
Teileigenschaften wird durch verschiedene Technologien vereinfacht. Die technologische
Unterstützung (TU), die Grundlage für die Realisierung von Funktionen ist, bildet eine dritte Ebene
der Portaleigenschaften. Die Ebenen werden in ihrem Zusammenhang in Abbildung 3 dargestellt.
Anwendungs-
eigenschaften
eines Portals (AE)
Technologische
Unterstützung
(TU)
Technische
Funktionalität
(TF)
Internetbasiert
Benutzermanagement
Personalisierung und
Rollenorientierung
Prozessorientierung
Integration
Homogenität
Internetbasiert
Benutzermanagement
Personalisierung und
Rollenorientierung
Prozessorientierung
Integration
Homogenität
Internetbasiert
Benutzermanagement
Personalisierung und
Rollenorientierung
Prozessorientierung
Integration
Homogenität
basiert auf basiert auf
Abbildung 3: Ebenen der Portaleigenschaften
3.3 Leistungen und Organisation des Technischen Vertriebs
3.3.1 Allgemeine Aufgabenstellung des Vertriebs
Die Hauptaufgabe des Vertriebs ist die effiziente Abbildung der einzelnen Teilprozesse des
Vertriebsprozesses. Zum Kern des Vertriebs gehören die Teilprozesse Werbung, Information,
Beratung, Verkaufsabschluss (Transaktion) und der nachgelagerte Service (After Sales Support)
[Brandstetter und Fries 2002]. Abbildung 4 stellt die zu unterstützenden Phasen des
Vertriebsprozesses in ihrem zeitlichen Zusammenhang dar. Die einzelnen Phasen des
Vertriebsprozesses enthalten aus Sicht des Verkäufers Unterprozesse aus den Klassen werbliche
Prozesse (Phase Werbung), Informationsprozesse (Phase Information), Transaktionsprozesse mit
Angebot und ggf. Verhandlung (Phase Verkaufsabschluss/Transaktion) und After-Sales-Prozesse
(Phase After Sales Support). Bestandteil der allgemeinen Aufgabenstellung des Vertriebs ist die
zielgruppengerechte Ansprache verschiedener Kundengruppen. Zu den Zielgruppen gehören
insbesondere gewerbliche Endkunden und Absatzmittler [Brandstetter und Fries 2002]. In dem in der
Arbeit fokussierten Bereich der zwischenbetrieblichen Abwicklung ist der hohe Interaktionsgrad der
Teilprozesse zwischen Anbieter und Nachfrager zu beachten (vgl. [Jacob 1998]), der durch ein
marktnahes Informations- und Kommunikationssystem unterstützt werden muss [Muschalla 1987].
Werbung Information Beratung
Verkaufs-
abschluss/
Transaktion
After Sales
Support
Abbildung 4: Der Vertriebsprozess nach [Brandstetter und Fries 2002]
3.3.2 Leistungen des Technischen Vertriebs
Es lassen sich drei Grundanforderungen verschiedener Kundengruppen an den technischen Vertrieb
identifizieren (vgl. [Reichmayr 2003], [Rackham 1999]): Transaktionsorientierung, Zusatznutzen-
27
orientierung und Zusammenarbeit (Collaboration). Diese bilden die Grundlage für die weitere
detaillierte Betrachtung. Technische Produkte lassen sich auf Basis der zu vermarktenden Leistungen
in die fünf Hauptklassen Produktionsgüter (gewerbliche Verbrauchsgüter), Investitionsgüter
(gewerbliche Gebrauchsgüter), Systeme, Hilfsstoffe und investive Dienstleistungen bzw. industrielle
Kundendienste untergliedern [Kleinaltenkamp 2000], [Kotler 1997]. Innerhalb der Hauptklassen
lassen sich technische Produkte weiterhin nach ihrem Anwendungsgebiet und ihrer Beschaffenheit in
erklärungsbedürftige Produkte (Spezialitäten) und in standardisierte, geringfügig bzw. nicht erklär-
ungsbedürftige Produkte (Commodities) unterteilen (in Anlehnung an [Bonart 1999]). Komplexe,
erklärungsbedürftige Produkte werden mit Abstimmungsphasen zwischen Hersteller und Abnehmer,
die der Findung der geeigneten Lösung dienen, vertrieben. Die Abstimmung mündet in einem
individuellen Angebot [VDI 1999], [Godefroid 1998]. Commodities werden von anbietenden
Unternehmen katalogbasiert vertrieben. Das wesentliche Charakteristikum dieser Produkte ist die
einheitliche technische Klassifizierbarkeit und Beschreibbarkeit über definierte Merkmale [Mucha und
Ulrich 2000]. Neben Funktions-, Mengen-, Zeit- und Treuerabatten [Warnecke 1995] ist die Erstellung
individueller Kundenpreise auf Basis der kundenbezogenen Gesamtabsatzmenge, Wichtigkeit und
branchenspezifischen Konkurrenzsituation notwendig [Gurzki und Özcan 2003]. Entsprechend ergibt
sich ein vielschichtiges Preisgefüge, das eine Angebotserstellung notwendig werden lässt und durch
Rahmenverträge mit Kunden oder Intermediären in der Komplexität erhöht wird. Die individuelle
Preisfindung führt hierbei zu individuellen Katalogen oder einem angebotsbasierten Verkauf
(Transaktion). Unter der Randbedingung einer möglichst kurzfristigen Preisfindungsphase ist der
Einsatz automatisierter Systeme notwendig, um einen Zusatznutzen für den Kunden zu schaffen.
Tabelle 2 fasst die Leistungen des Technischen Vertriebs in einer Übersicht zusammen.
Leistung Beschreibung
Unterstützung von
angebotsorientiertem
Vertrieb
- Erstellung individueller Angebote bezogen auf das Kundenproblem
[VDI 1999], [Godefroid 1998].
- Verkauf hochwertiger und komplexer Güter (A-Güter) [Gurzki und
Özcan 2003].
Unterstützung von
katalogbasiertem
Vertrieb
- Verkauf standardisierter Produkte mit Sicherheit des Kunden über
Anwendung und Beschaffenheit [Bonart 1999].
- Möglichkeit der Klassifizierung und standardisierten
Merkmalsbeschreibung von Produkten [Mucha und Ulrich 2000].
Unterstützung der
Produktwahl
- Vertrieb erklärungsbedürftiger Produkte [Bonart 1999].
- Detaillierte technische Information, Unterstützung bei der Produktsuche
[Gurzki und Özcan 2003].
Unterstützung der
Produktkonfiguration
- Built-to-Order-Konzepte [Tseng und Piller 2003], [Dangelmaier 2001].
- Verbreitete Produktindividualisierung [Pepels 1998].
Unterstützung des Ver-
kaufs von Zubehör und
Komplementärprodukten
- Komplementäreffekte [Pepels 1998].
- Verkauf von Ersatzteilen und Zubehör [Harms 1999].
Bereitstellung Service
- Bereitstellung von Information und Beratung [Harms 1999].
- Reklamations- und Beschwerdemanagement [Vasen 2003].
Unterstützung verschied-
ener Zielgruppen
- Internationalität des Geschäfts [Pepels 1998].
- Zielgruppentypisierung nach Marktkriterien [Kelkar 2003].
Tabelle 2: Zusammenfassung: Beschreibung der Leistungen des Technischen Vertriebs
28
3.3.3 Organisation des Technischen Vertriebs
In produzierenden Unternehmen ist der Vertrieb in drei Hauptbereiche gegliedert, die den
Vertriebsprozess unterstützen und abbilden:
Vertriebsaußendienst (VAD): Die Aufgabe des Vertriebsaußendiensts ist die Betreuung
deckungsbeitragsintensiver A-Kunden (hochwertige Kunden) entsprechend der individuellen
Definition eines Unternehmens. In diesen Bereich fallen Verkaufsabschlüsse und der Vertrieb
ergänzender Produkte und Dienstleistungen (Cross-Selling). Zum Aufgabenfeld des VAD gehört die
Gewinnung von Neukunden durch persönlichen Kontakt [Biesel 2002].
Vertriebsinnendienst (VID): Der Innendienst nimmt Bestellungen für standardisierte Produkte an
und bearbeitet diese. Der Anfrage- und Angebotsprozess bei kundenwunschorientierter Fertigung bzw.
im Anlagengeschäft sowie die zugehörige Kommunikation mit dem Kunden wird vom Innendienst
abgewickelt [Mertens 1997].
Auftragsabwicklung (AAW): Die Auftragsabwicklung umfasst alle notwendigen auftragsbezogenen
Prozessschritte, die dem Produktionssektor unmittelbar vor- oder nachgelagert sind. Hierzu gehört
unter anderem die Zusammenfassung von Aufträgen zur Optimierung der Losgrößen im Verhältnis zur
Rüstzeit und damit die Terminierung von Aufträgen [Mertens 1997]. Im Anlagengeschäft umfasst die
Auftragsabwicklung alle notwendigen Projektphasen von der Auftragserteilung bis zur Übergabe an
den Auftraggeber [VDI 1991].
Der Service ist durch seine Ausrichtung auf Kleingeräte (leichte Transportierbarkeit,
Werkstattservice), Großgeräte (Transport nicht möglich, Vor-Ort-Service) und Anlagen- und System-
Service (Transport nicht möglich, Vor-Ort-Service) gekennzeichnet [Harms 1999]. Der Technische
Vertrieb und Service erfolgt in der Regel international. Um einen markt- und kundengerechten Zugang
zu erhalten, setzen Unternehmen zu einem hohen Grad auf Vertriebsniederlassungen oder Büros in
den Zielmärkten [Gurzki und Özcan 2003]. Auslandsniederlassungen weisen speziell in technischen
Branchen eine hohe Autonomie auf, die sich in eigenen marktspezifischen Serviceleistungen
widerspiegeln [Wieselhuber 2002].
3.3.4 Der internetbasierte Vertrieb
Der internetbasierte Vertrieb lässt sich aus Sicht von Unternehmen in drei Evolutionsstufen einteilen.
Sie unterscheiden sich entsprechend des realisierten Prozessumfangs in Informationsbereitstellung,
Verkauf über das Internet bis zur Produktion auf Bestellung als Endstufe [Ackerschott 2001]. Für
Unternehmen, die über die reine Informationsbereitstellung hinaus gehen, liegen die wesentlichen
Ziele des internetbasierten Vertriebs in der Kostenreduzierung bei der Auftragsannahme, der
Verbesserung der Kundenbindung durch Zusatzleistungen, der Verbesserung der Kenntnisse über
Kunden sowie der Schaffung eines zusätzlichen Vertriebskanals [Renner und Schwengels 2000]. Ziel
ist die direkte Interaktion mit dem Kunden, die eine Individualisierung der Kunden-Anbieter-
Beziehung (One-to-One-Marketing) und die Individualisierung von Produkten und Dienstleistungen
bei gleichzeitiger 24-Stunden-Verfügbarkeit ermöglicht [Muther 2002].
Als Konsequenz aus diesen Zielen ergibt sich die Forderung nach einem breiten und vollständigen
Angebot an vertriebsbezogenen Prozessen für den Kunden. Der internetbasierte Vertrieb stellt dabei
keinen Ersatz für andere Vertriebskanäle dar, sondern ergänzt diese und eröffnet neue Potenziale für
die Erreichung neuer Kunden und Zielgruppen [Ackerschott 2001]. Die über eine Plattform
29
ausgeführten Prozesse sind daher wechselseitig abhängig von den Prozessen anderer Kanäle.
Informationen über ausgeführte Prozesse und die damit verbundenen Daten müssen allen Kanälen mit
einem hohen Integrationsgrad zur Verfügung stehen.
3.4 Ansätze zur softwaretechnischen Unterstützung des Technischen
Vertriebs
Die im Vertrieb eingesetzten Softwaresysteme lassen sich in die Hauptklassen vertriebsunterstützende
Systeme und Systeme mit externer Kundenschnittstelle einteilen. Vertriebsunterstützende Systeme
stellen der Vertriebsorganisation Funktionen und Informationen zur Abwicklung von
Vertriebsvorgängen bereit. Sie werden ausschließlich unternehmensintern genutzt. Wesentliche
bereitgestellte Informationsarten sind (basierend auf [Watterott 1987]):
− Kundeninformationen (Kundenstammdaten, kundenbezogene Absatzinformationen, Angebots-
und Auftragsdaten, Reklamationen, Einkaufskonditionen, Ausrüstung des Kunden),
− Produktinformationen (Artikelstammdaten, Produktinformation, Lieferfähigkeit, technischer
Änderungsdienst),
− Lieferbedingungen,
− Kundenbetreuung.
Extern genutzte Systeme dienen der direkten Kundeninteraktion. Ein beispielhafter Vertreter dieser
Klasse sind Shop-Systeme, die Prozesse von der Produktwahl bis zur Transaktion unterstützen. Zu
dieser Klasse gehören interaktive Werkzeuge, die der Kommunikation mit dem Kunden dienen (vgl.
[Kempf 2003]). Die Systeme werden weiterhin nach ihrem Einsatzbereich untergliedert. Dieser kann
sich auf die innerbetriebliche Anwendung bzw. die rein externe Verwendung beschränken oder sich
auf beide Bereiche erstrecken.
Für die Bewertung der Reichweite der Systeme im Kundenprozess ist als Primärkriterium ihr Beitrag
zu den einzelnen Phasen des in Kapitel 3.3.1 vorgestellten Vertriebsprozesses zu betrachten. Hierbei
ist zu unterscheiden, ob die Systeme eine direkte Kundeninteraktion durchführen oder rein intern
angewendet werden.
Die in Tabelle 3 dargestellten Systemklassen weisen in Bezug auf den Vertriebsprozess überlappende
Funktionalitäten auf (vgl. auch [META Group 2002]). Die Klassen sind durch eine sich
unterscheidende Verwendungshäufigkeit im praktischen Einsatz charakterisiert (vgl. [Gurzki und
Özcan 2003]), die erkennen lässt, dass Unternehmen eine Mischung verschiedener Systeme einsetzen.
Die Systemklassen unterstützen spezialisiert einzelne oder ggf. mehrere Prozessphasen des Vertriebs.
Keine der untersuchten Systemklassen deckt den gesamten Prozesszyklus des Technischen Vertriebs
vollständig ab. Für die Realisierung eines durchgehenden kundenorientierten Vertriebsprozesses ist
die Kombination der Teilprozesse aus verschiedenen Klassen notwendig. Die Instanzen dieser
Systemklassen sind im Rahmen einer technischen Integration miteinander zu verbinden.
30
Phase Vertriebsprozess
E
in
sa
tz
-
be
re
ic
h
Systemklasse W
er
bu
ng
In
fo
rm
at
io
n
B
er
at
un
g
T
ra
ns
ak
tio
n
A
fte
r
Sa
le
s
Su
pp
or
t
In
te
rn
e
A
bl
äu
fe
Funktion der Systemklasse im
Kontext des Technischen Vertriebs
In
te
rn
E
xt
er
n
Groupware – * + * + + Interne und externe E-Mail-
Kommunikation,
Ressourcenverwaltung
● ○
ERP-System – – – – – + Warenwirtschaft ● ○
Produktionsplanungs-
und Steuerungssystem
– – – – – + Planung und Steuerung von
Produktionsvorgängen
● ○
Produktdatenbank – – – – – + Verwaltung von Produktdaten und
Erzeugung von Katalogen
● ○
Web-Content-
Management-System
+ + – – * * Bereitstellung und Verwaltung von
Webinhalten
○ ●
Dokumenten-
managementsystem
* * * – * + Dokumentenverwaltung ● ●
Kundenpreisdatenbank – – – – – + Verwaltung von kundenindividuellen
Preisen für Artikel
● ○
Customer-Relationship-
Management-System
* * * * – + Verwaltung von kundenbezogenen
Informationen
● ○
Engineering-Data-
Management-System
– – – – – + Verwaltung von
entwicklungsbezogenen Daten und
Dokumenten
● ○
Produktkonfigurator – – + + * + Werkzeug für die Konfiguration von
Varianten
● ●
Shop-System * + * + – * Bereitstellung Einkaufsumgebung mit
Katalog und Warenkorb
○ ●
Workflow-Management-
System
– – * – + + Verwaltung und Ausführung von
Workflows
● ●
Echtzeitkommunikation – * + – + * Abbildung synchroner
Kommunikation
● ●
Computer-Aided-Sales
System
– – – – – + Unterstützung des Vertriebsinnen und
-außendiensts, Kunden- und
Vertriebsdaten
● ○
Community Software * * + * + * Unterstützung asynchroner Kunde-
Kunde- bzw. Kunde-Mitarbeiter-
Kommunikation
● ●
Collaborative-
Engineering-Werkzeuge
* * + – + + Unterstützung asynchroner und
synchroner Kommunikation in der
Produktentwicklung
● ●
Legende: Möglichkeit des internen bzw. externen Einsatzes ● Einsatz möglich, ○ Einsatz nicht möglich;
Eignung für den Einsatz in den Prozessphasen: + gute Eignung, * bedingte Eignung, – keine Eignung.
Tabelle 3: Funktion und Bewertung vertriebsunterstützender Systeme
31
3.5 Softwarearchitekturen für die Erstellung webbasierter Anwendungen
3.5.1 Allgemeine Definition der Softwarearchitektur
Die Erstellung von Anwendungen erfolgt auf Basis der Grundlagen des Software Engineering. Für
eine Entwicklungstätigkeit bei einer Portalanwendungserstellung ist eine formale Beschreibung der zu
programmierenden Software notwendig, die im Rahmen der Konzeption erstellt wird. Diese
Beschreibung wird als Softwarearchitektur bezeichnet. In der Literatur finden sich verschiedene,
jedoch inhaltlich sehr ähnliche Definitionen für den Begriff der Softwarearchitektur. Tabelle 4 zeigt
zwei exemplarisch ausgewählte, verbreitete Definitionen.
Quelle Definition
[Balzert 2000] „Eine Software-Architektur ist eine strukturierte oder hierarchische
Anordnung der Systemkomponenten sowie Beschreibung ihrer
Komponenten.“
[Bass et al. 2003] „The software architecture of a program or computing system is the
structure or structures of the system, which comprise software
components, the externally visible properties of those components, and
the relationship among them.”
Tabelle 4: Definitionen des Begriffs Softwarearchitektur
Im Kontext dieser Arbeit wird basierend auf diesen Definitionen der Begriff der Softwarearchitektur
als die Beschreibung einer Software mit einer Anordnungsstruktur der enthaltenen Komponenten, eine
Beschreibung der extern verwendbaren Funktionen und Eigenschaften der Komponenten sowie die
internen Beziehungen zwischen den enthaltenen Komponenten verstanden.
3.5.2 Übersicht der Ansätze zur Realisierung webbasierter Anwendungen
Webbasierte Anwendungen werden mit verschiedenen Softwaretechnologien und den damit
verbundenen jeweiligen Softwarearchitekturen realisiert. In den folgenden Abschnitten werden die
Technologien und Architekturen eingehend betrachtet. Hierzu wird zunächst der grundlegende Aufbau
von webbasierten Anwendungen dargestellt und der Begriff der Komponente definiert. Es wird die
Architektur des Common Gateway Interface (CGI) untersucht, auf die die weiteren Ansätze optional
zurückgreifen können.
Eine Erweiterung der einfachen Form der Anwendung macht sich die Funktionalität eines Application
Servers zunutze. Dieser stellt eine Ausführungsumgebung für Anwendungen sowie Funktionen zur
Nutzung in Anwendungen bereit. Application Server finden im Umfeld von Komponentenmodellen
und serverseitigen Skriptsprachen Verwendung [Altenhofen et al. 2003a]. Diesem Bereich zuzuordnen
sind die Plattformkonzepte, wie z. B. J2EE oder .NET für die Erstellung webbasierter Anwendungen.
Portalsoftwarebasierte Architekturen lassen sich als spezialisierte Form identifizieren.
Portalsoftware benötigt für ihre Funktion einen Application Server und greift in der Regel auf
Plattformkonzepte zurück [Bullinger 2002]. Der Bereich der Integration findet sich als Teilaspekt in
allen Architekturmodellen wieder und wird im Rahmen von Integrationsarchitekturen in Kapitel 3.7
betrachtet. Abbildung 5 zeigt einen Überblick über den Betrachtungsraum für Ansätze zur
Realisierung webbasierter Anwendungen.
32
Abbildung 5: Betrachtungsraum für Ansätze zur Realisierung webbasierter Anwendungen
3.5.3 Aufbau webbasierter Architekturen
Zur Strukturierung einer komplexen Softwarearchitektur ist der Einsatz von Schichten erforderlich
[Balzert 2000]. Für webbasierte Anwendungen sind primär drei- und vierschichtige Architekturen
relevant. Die 3-Schicht-Architektur strukturiert die Anwendung in Präsentationslogik,
Anwendungslogik und Datenhaltung [Thurau 1999]. Die Präsentationslogik ist im Web Browser des
Clients enthalten (Thin Client). Die Anwendungslogik befindet sich auf der Serverseite und erzeugt
den HTML-Code, der vom Client dargestellt wird (vgl. Abbildung 6). In ihrem programmatischen
Ablauf greift sie auf den Datenbestand der Datenhaltung zurück. Die Schicht der Datenhaltung wird in
der neueren Literatur um allgemeine betriebliche Informationssysteme (BIS) erweitert, die neben der
Datenhaltung eigene umfangreiche Anwendungslogik beinhalten [Singh et al. 2002]. Die
vierschichtige Architektur ist grundlegend ähnlich aufgebaut, führt jedoch eine Trennung der
Erzeugung des HTML-Codes in eine serverseitige Präsentationsschicht und in die Anwendungslogik
durch [Altenhofen et al. 2003a]. In der Präsentationsschicht werden eingebettete Skriptsprachen
verwendet, die bei der serverseitigen Generierung der Präsentation auf die Schicht der
Anwendungslogik zurückgreift. Die clientseitige Präsentation erfolgt durch einen Browser und
umfasst die tatsächliche Darstellung auf dem Endgerät. Der Ansatz der Skriptsprachen wird in Kapitel
3.5.5 vorgestellt. Die Trennung der Präsentationsgenerierung und der Anwendungslogik führt zu einer
besseren Wartbarkeit der Gesamtanwendung [Colyer et al. 2000]. Dies wird in den in Kapitel 3.5.6.1
und 3.5.6.2 vorgestellten Technologieplattformen J2EE und .NET mittels Komponententechnologien
erreicht.
HTML/
HTTP
JDBC
ODBC
Thin-Clients ServerseitigePräsentation
Anwendungs-
logik
HTML/
HTTP
JDBC
ODBC
Datenhaltung
Daten
AnwendungslogikThin-Clients
3-
Sc
hi
ch
t
4-
Sc
hi
ch
t
Thin-Clients ServerseitigePräsentation
Anwendungs-
logik
HTML/
HTTP
EAI
Middle-
ware
4-
Sc
hi
ch
t
Betriebliche
Informations-
systeme
Abbildung 6: Aufbau von 3-Schicht-Architekturen (oben) und 4-Schicht-Architekturen (Mitte) basierend
auf [Altenhofen et al. 2003a] und [Thurau 1999], 4-Schicht-Architekturen mit EAI/Middleware (unten)
33
3.5.3.1 Der Komponentenbegriff
Für die Strukturierung von Softwaresystemen werden abgegrenzte Systemkomponenten als Bausteine
festgelegt, die in einer Architektur im Zusammenspiel die Funktionalität einer Anwendung realisieren
[Balzert 2000]. In der Literatur wird der Komponentenbegriff auf verschiedene Arten definiert. Die
Definitionen umfassen kleine Softwarebausteine in der Granularität von Objekten bis hin zu
eigenständigen Softwaresystemen, die im Kontext einer Architektur als Komponenten eingesetzt
werden [Griffel 1998]. Relevante Begriffsbestimmungen werden in einer Übersicht in Tabelle 5
dargestellt.
Nach Quelle Definition
[Balzert 2000] Eine Systemkomponente ist ein abgegrenzter Teil eines Softwaresystems. Sie
dient als Baustein für die physikalische Struktur einer Anwendung.
[Orfali et al. 1996]
zitiert in: [Griffel 1998]
Eine Komponente ist ein Stück Software, das klein genug ist, um es in einem
Stück zu erzeugen und pflegen zu können, groß genug, um eine sinnvoll
einsetzbare Funktionalität zu bieten und eine individuelle Unterstützung zu
rechtfertigen sowie mit standardisierten Schnittstellen ausgestattet ist, um mit
anderen Komponenten zusammenzuarbeiten.
[Turowski und
Krammer 2003]
Eine Komponente besteht aus verschiedenartigen (Software-) Artefakten.
Sie ist wiederverwendbar, abgeschlossen und vermarktbar, stellt
Dienste über wohldefinierte Schnittstellen zur Verfügung, verbirgt ihre
Realisierung und kann in Kombination mit anderen Komponenten eingesetzt
werden, die zur Zeit der Entwicklung nicht unbedingt vorhersehbar
ist.
[Weisbecker 2002] Komponenten sind unabhängig auslieferbare funktionale Teile, die über
Schnittstellen den Zugriff auf ihre Dienste bereitstellen.
Tabelle 5: Definitionen des Begriffs Komponente
Anhand der Definitionen lassen sich die abstrakte Kapselung von Funktionen und die damit
verbundene kontextbezogene Wiederverwendung als die wesentlichen Haupteigenschaften von
Komponenten zusammenfassen. Komponenten sind nach dem Grad ihrer Kopplung einteilbar. Zu
unterscheiden sind enge Kopplungen, wie z. B. mittels Funktionsaufrufe in Bibliotheken und lose
Kopplungen über Middleware bzw. EAI. Lose Kopplungen erlauben eine Verteilung der
Komponenten. Darüber hinaus kann Komponentensoftware im betrieblichen Bereich nach ihrer
Granularität klassifiziert werden (basierend auf [Fähnrich et al. 2000]):
− Feine Granularität: Komponentenplattformen (Bibliotheken/Sammlungen, Komponenten-
modelle).
− Mittlere Granularität: Anwendungsorientierte Diensteplattformen (Bürokommunikation, Daten-
bank).
− Grobe Granularität: Diensteplattform einer Standardsoftware (ERP-Software, CAD-CAM,
Customer Care Software).
Somit lässt sich der Komponentenbegriff auch auf aktive und übergreifende Architektureinheiten
anwenden, die für sich betrachtet Systemcharakter besitzen (vgl. auch [Griffel 1998]).
Im Kontext der Arbeit wird der Komponentenbegriff in Anlehnung an [Weisbecker 2002]
verallgemeinert und damit der Komponentenbegriff von [Turowski und Krammer 2003] entsprechend
der folgenden Kriterien übernommen bzw. modifiziert:
34
− Wiederverwendbarkeit: Eine Komponente kann in verschiedenen Kontexten in verschiedenen
Softwaresystemen ohne Modifikation der zugehörigen (Software-) Artefakte mit geringem
Integrationsaufwand eingesetzt werden. Sie wird optional hierfür im Rahmen einer vom
Entwickler vorgesehenen Parametrisierung konfiguriert.
− Abgeschlossenheit: Einer Komponente können ihre Bestandteile eindeutig zugeordnet werden
und sie kann als Komponente klar von den anderen Systemteilen abgegrenzt werden.
− Schnittstellen: Eine Komponente stellt ihre Dienste über definierte Schnittstellen nach außen
bereit. Für den Nutzer ist die Realisierung der Funktionalität der Komponente transparent.
Als Komponenten können hiernach sowohl wiederverwendbare Softwarekomponenten nach
Komponentenmodellen als auch in verschiedenen Kontexten nutzbare, in sich geschlossene,
Softwareanwendungen, wie z. B. ERP- oder Shop-Systeme, bezeichnet werden. Die Eigenschaft der
Vermarktbarkeit spielt im Rahmen der vorliegenden Arbeit eine untergeordnete Rolle und wird daher
nicht als Bestandteil der Definition gesehen (vgl. auch [Sametinger 1997]).
3.5.4 Common Gateway Interface
Das Common Gateway Interface (CGI) war das erste Verfahren zur dynamischen Generierung von
Web-Inhalten. Externe Programme können vom Web-Server mittels CGI aufgerufen werden. Bei dem
Aufruf werden die Aufrufparameter, wie z. B. die Daten eines ausgefüllten HTML-Formulars, als
Startparameter an das Programm übergeben. Die Ausgabe des Programms wird über die
Standardausgabe an den Web-Server zurückgeführt und ausgegeben. Nachteilig an diesem Verfahren
ist die aufwändige und damit langsame Bildung einer Instanz des Programms in einem eigenen
Prozess ([Rossbach und Schreiber 1999]) sowie das fehlende Sitzungsmodell. Die Weiterentwicklung
FastCGI startet für jede Anwendung einen Prozess, der erst mit der Beendigung des Web-Servers
terminiert. Eine Methodik für die Einbindung der CGI-Anwendung an unternehmensinterne
Anwendungen wird durch die CGI-Architektur nicht vorgegeben. Die CGI-Anwendung kann aus einer
compilierten Anwendung von Hochsprachen (C, C++ etc.) oder aus interpretierten Skriptsprachen wie
Perl, Phyton oder Ruby (vgl. [Weigend 2004], [Guelich et al. 2001], [Röhrl et al. 2002]) bestehen.
Abbildung 7: CGI-Anwendungsarchitektur basierend auf [Weigend 2004]
3.5.5 Eingebettete serverseitige Skriptsprachen
Architekturen eingebetteter serverseitiger Skriptsprachen sind nach dem dreischichtigen Modell
aufgebaut. Die Anfragen der Clients werden vom Web-Server an den Application-Server der
jeweiligen Skriptsprache weitergeleitet und dort verarbeitet. Die Programmlogik wird in Form von
Tag-basierten Skriptfragmenten in gestaltete HTML-Seiten eingefügt. Der Application-Server stellt
35
eine Ausführungsumgebung für die eingebetteten Skripte bereit, die unter anderem das
Sitzungsmanagement und die Sicherheit verwaltet. Er kann vom Web Server durch CGI aufgerufen
werden. Für die Erreichung eines schnellen Starts der Anwendung ist die Einbindung als Modul in den
Web-Server gängig. Typische Vertreter der eingebetteten Skriptsprachen sind Macromedia
Coldfusion, Java Server Pages (JSP) und Microsoft Active Server Pages (ASP). JSP und ASP finden
in den jeweiligen Plattformkonzepten J2EE und .NET Verwendung, können jedoch auch als
eingebettete Skriptsprachen unabhängig betrieben werden. Der Application-Server der Skriptsprache
kann dabei über das CGI-Verfahren an den Web-Server angebunden oder ein Modul des Servers sein
(Abbildung 8). Eingebettete Skriptsprachen können auf fein granulare Komponenten, wie z. B. eigene
Komponenten auf Basis von Bibliotheken, oder auf Komponenten externer Komponentenmodelle, wie
z. B. CORBA oder EJB, zurückgreifen. Über Middleware können betriebliche Informationssysteme
angebunden werden. Anhang B gibt einen Überblick der gängigen eingebetteten Skriptsprachen.
Anwendungslogik-SchichtClient-Schicht
Client HTTP-Server
Skriptsprachen-
Application-
Server
HTML-
Dokumente
CGI
BIS-Schicht
Betriebliche
Informations-
systeme
Seite mit
eingebetteten
Skripten
Internet Middleware
Abbildung 8: Architektur mit eingebettetem Skriptsprachen-Application-Server
3.5.6 Plattformen zur Erstellung webbasierter Anwendungen
Aus den Skriptsprachen heraus haben sich Plattformkonzepte verschiedener Hersteller entwickelt, die
für webbasierte Anwendungen umfassende Entwicklungs- und Ausführungsumgebungen bereitstellen.
Die zugrunde liegenden Initiativen gehen zum Teil weit über die Kernfunktionen hinaus und umfassen
ein breites Spektrum bis hin zur abgestimmten Hardware. Im Folgenden werden die beiden Vertreter
dieser Plattforminitiativen Sun ONE und Microsoft .Net auf ihre Architektur und ihre Eignung für die
Erstellung von Portalen untersucht.
3.5.6.1 Sun ONE Architektur
Sun ONE ist eine Initiative von Sun Microsystems, die Vision, Architektur, Plattform und
Unternehmensexpertise für die Bereitstellung von „Services on Demand“ umfasst [Sun 2002]. Zu der
Initiative gehören insbesondere [Grasl 2003]:
− Sun ONE Server: Betriebssysteme und Middleware.
− Sun ONE Development Tools: Unterstützung für die Entwicklung von Anwendungen und
„Services On Demand“.
− J2EE: Entwicklungsplattform und Framework für Unternehmensanwendungen.
Anwendungen basieren auf der Programmiersprache Java. Der Java Code wird in eine binäre Form
compiliert, der von einer virtuellen Maschine, der Java Virtual Machine (JVM), ausgeführt wird. Die
JVM stellt die für die Ausführung notwendige Laufzeitumgebung zur Verfügung und führt je nach
36
Produkt eine Just-in-Time-Compilierung auf den Maschinencode des ausführenden Rechners aus. Aus
der Verfügbarkeit von JVM für gängige Systemplattformen resultiert ein hoher Grad an
Plattformunabhängigkeit für Java-basierte Anwendungen.
Von zentraler Bedeutung für den Bereich Portale ist der Baustein J2EE, der gleichzeitig den Kern von
Sun ONE bildet. Die J2EE-Architektur besteht aus einem Application-Server, der jeweils einen
Container für Web-Anwendungen und einen für Enterprise Java Beans enthält [Armstrong et al.
2003]. Die Architektur wird in Abbildung 9 dargestellt. Web-Anwendungen werden in dem dafür
vorgesehenen Container ausgeführt und mittels der Servlet- oder JSP-Technologie erstellt. Als
Servlets werden auf Basis der Servlet-API entwickelte webbasierte Java-Anwendungen bezeichnet, die
in einem Servlet Container ausgeführt werden.
Der Web Container stellt den enthaltenen Servlets Funktionen für das Sitzungsmanagement und den
Abruf von Informationen über den Client zur Verfügung und verwaltet den Lebenszyklus eines
Servlets [Sun 2002]. Die Java Server Pages (JSP), die bereits in Kapitel 3.5.5 eingeführt wurden,
stellen eine Ergänzung der Servlet-Technologie um eine eingebettete Skriptsprache dar. JSP werden
vor der Ausführung durch die Laufzeitumgebung in ein Servlet übersetzt.
Der EJB Container enthält Enterprise Java Beans, die wiederverwendbare Softwarekomponenten
darstellen. Ein J2EE-Application-Server hält den ausgeführten Anwendungen eine Vielzahl von
Programmierschnittstellen zur Integration und Kommunikation wie z. B. JavaMail API (Framework
für Mail und Messaging Anwendungen), JNDI API (Zugriff auf Directory Services) und JDBC API
(Zugriff auf Datenbanken), bereit.
BIS-SchichtAnwendungslogik-SchichtClient-Schicht
Client
Client
EJB Container
Enterprise
Bean
Enterprise
Bean
Enterprise
Bean
Web Container
Servlets
Java Server
Pages
HTML
XML
JNDI
JMS
JavaMail
Betriebliche
Informations-
systeme
(Enterprise
Informations
Systems)
RDBMS
ERP
Legacy
Anwendungen
Abbildung 9: Architektur von J2EE basierend auf [Singh et al. 2002]
J2EE ist öffentlich zugänglich spezifiziert. Aus diesem Grund sind verschiedene J2EE-Application-
Server am Markt erhältlich. Die Kombination der Technologien EJB, JSP und Servlet erlaubt in Java-
basierten Web-Anwendungen die Erstellung von Model-View-Controller-Mustern [Singh et al. 2002].
Die Integration von Anwendungen in eine J2EE-Anwendung wird durch die J2EE Connector
Architecture (JCA) unterstützt. JCA ermöglicht den Herstellern von Systemen die Erstellung eines
Resource-Adapters als einheitliche Schnittstellenkomponente. Dieser kann mit allen Application-
Server-Produkten, die J2EE-konform ausgelegt sind, verwendet werden [Sun 2003]. Die einheitliche
Schnittstellenarchitektur garantiert gemeinsame Eigenschaften der Adapter, wie
z. B. Transaktionssicherheit, Verbindungsverwaltung und Datensicherheit.
37
3.5.6.2 Microsoft .NET Architektur
Die .NET Initiative von Microsoft setzt sich zum Ziel, ein integriertes Plattformkonzept für die
Entwicklung von Anwendungen bereitzustellen. Der Ansatz von Microsoft besteht aus einer Mischung
verschiedener Technologien und konkreter Softwareprodukte und umfasst [Richter 2002]:
− Windows-Betriebssysteme: Die Betriebssysteme enthalten eine Unterstützung zum Laden und
Ausführen von Anwendungen, die auf dem .NET Framework basieren.
− .NET Enterprise Server: Die Enterprise Server bestehen aus verschiedenen Serveranwendungen,
wie z. B. dem Groupware-Server Exchange oder der EAI-Plattform BizTalk, die mit Funktionen
und Schnittstellen für das .NET Framework ausgestattet sind.
− .NET My Services: Die von Microsoft bereitgestellten Web Services, die verschiedene
Dienstleistungen implementieren, sind unter My Services zusammengefasst.
− .NET Framework: Das Framework besteht aus der Ausführungsumgebung Common Language
Runtime (CLR) und der Klassenbibliothek Framework Class Library (FCL).
− Entwicklungsplattformen: Entwicklungsumgebungen, wie z. B. Visual Studio .NET.
Anwendungen für die .NET-Plattform können in Programmiersprachen entwickelt werden, die das
Typsystem des Common Type System (CTS) unterstützen. Die Compiler der einzelnen
Programmiersprachen erzeugen mit der Microsoft Intermediate Language (MSIL, IL) einen
prozessorunabhängigen Zwischencode. Im Gegensatz zum Bytecode von Java ist die IL direkt lesbar
und weist die Strukturen einer Hochsprache auf [Westphal 2003]. Die Ausführung von Programmen in
der IL erfolgt durch die Common Language Runtime (CLR), die Bestandteil einer
Ausführungsplattform ist. Die CLR enthält einen Just-in-Time-Compiler, der den Code in den
Maschinencode der jeweiligen Maschine übersetzt [Grimes 2002]. Die Erstellung webbasierter
Anwendungen erfolgt in der .NET-Plattform mittels einer Weiterentwicklung der Active Server Pages
(ASP), den ASP.NET. In dem von Microsoft gewählten vollständig objektorientierten Paradigma
werden Web-Anwendungen auf Basis von Objekten entwickelt. Zur Unterstützung der Anwendungs-
entwicklung beinhaltet ASP.NET ein Ereignissystem. Die Webcontrols enthalten die gesamte
Programmlogik. Im Gegensatz zur Objekteinbettung in JSP erzeugen die Webcontrols den benötigten
HTML-Code für die Ausgabe automatisch. Der Entwickler kann sich somit auf die Programmlogik
konzentrieren. Webcontrols werden in der ASP.NET-Seite als Tag repräsentiert. Die Erstellung
formularbasierter Anwendungen wird durch Webforms unterstützt, die eine ereignisgesteuerte
Entwicklung von Formularen gestattet [Schwichtenberg 2003]. Die Anwendungsintegration in .NET
kann mittels verschiedener Technologien erfolgen: Web Services, Middleware COM+, Datenbank-
Schnittstelle ADO.NET, Microsoft Message Queue (MSMQ), Host-Integration CICS und anderen. Es
existieren verschiedene Frameworks, welche die Erstellung webbasierter Anwendungen vereinfachen
(vgl. [Wang 2004]).
3.5.6.3 Gegenüberstellung und Bewertung
Die vorgestellten Ansätze zur Realisierung webbasierter Anwendungen in Form der CGI-Technologie,
der eingebetteten Skriptsprachen und der Plattformkonzepte werden abschließend in Bezug auf ihren
Beitrag für die Architekturen von Portalen bewertet. Tabelle 6 stellt eine Übersicht der verschiedenen
Ansätze aus den Kapiteln 3.5.4 bis 3.5.6.2 dar. Es werden Beispiele für konkrete Ausprägungen der
Ansätze und mögliche Programmiersprachen sowie die zugehörigen Präsentationstechniken und die
38
hieraus resultierende Art der Präsentationserstellung aufgeführt. Kriterien für die folgende Bewertung
stellen die Erfüllung der in Kapitel 3.2 eingeführten Ebenen (TU, TF, AE) der Portaleigenschaften
sowie die Architektureigenschaften dar. Diese Eigenschaften müssen von geeigneten Architekturen
unterstützt werden. Darüber hinaus ist entsprechend der Definition der Softwarearchitekturen aus
Kapitel 3.5.1 zu bewerten, welche Vorgaben für die Gestaltung der Anwendungsarchitektur eines
Portals gemacht werden. Hierzu gehört die Strukturierung der aus der Verwendung der Ansätze
resultierenden Anwendungsarchitekturen. Weiterhin ist die Granularität der Komponentenmodelle
relevant, die sowohl interne Komponenten als auch externe Systeme abbilden muss.
Ansätze zur Realisierung webbasierter Anwendungen
Kriterium
CGI Eingebettete
Skriptsprachen
Sun ONE/
J2EE
.NET
Übersicht
Beispiele Perl, Phyton,
Ruby, C, C++
Coldfusion MX,
PHP, ASP
Sun ONE/J2EE .NET, MONO
Programmiersprachen s. o. Vgl. Kap. 3.5.5 Java C#, VB.NET
Präsentationstechnik offen1 identisch mit
Skriptsprache
JSP, Servlets ASP.NET
Präsentations-
erstellung
offen1 weitgehend Ver-
mischung von
Präsentation/Logik
Trennung von
Präsentation/Logik
Trennung von
Präsentation/Logik
Portaleigenschaften
Ebene TU TF AE TU TF AE TU TF AE TU TF AE
Internetbasiert ● ◐ ○ ● ● ○ ● ● ○ ● ● ○
Personalisierung und
Rollenorientierung
~1 ~1 ~1 ◐ ○ ○ ● ◐ ○ ● ◐ ○
Benutzermanagement ~1 ~1 ~1 ◐ ○ ○ ◐ ○ ○ ◐ ◐ ○
Prozessorientierung ~1 ~1 ~1 ◐ ○ ○ ● ○ ○ ● ○ ○
Integration ~1 ~1 ~1 ◐ ◐ ○ ● ◐ ○ ● ◐ ○
Homogenität ~1 ~1 ~1 ◐ ○ ○ ● ◐ ○ ● ◐ ○
Architektur
Strukturierungs-
vorgaben
offen1 Aufbau nach 2-
Schicht, 3-Schicht
Aufbau nach 3-
Schicht, 4-Schicht
Aufbau nach 3-
Schicht, 4-Schicht
Granularität des
Komponentenmodells
(intern/extern)
nicht zutreffend fein/
fein, mittel, grob
fein/
fein, mittel, grob
fein/
fein, mittel, grob
Fachebene
Abbildung Prozesse
des Techn. Vertriebs
○ ○ ○ ○
Gesamtbewertung
Beitrag zu einer
Portalarchitektur
Definition
Schnittstelle zu
Web-Server
Vorgabe der
grundlegenden
Anwendungs-
struktur, Schichten
Vorgabe der
grundlegenden
Anwendungs-
struktur, Schichten
Vorgabe der
grundlegenden
Anwendungs-
struktur, Schichten
Legende: Eigenschaft ● voll erfüllt, ◐ teilweise erfüllt, ○ nicht erfüllt, ~ nicht bewertbar;
1 abhängig von eingesetzter Technologie.
Tabelle 6 Gegenüberstellung und Bewertung der Ansätze zur Realisierung webbasierter Anwendungen
39
Die betrachteten Ansätze erfüllen die grundlegenden Portaleigenschaften primär auf der Ebene der
technologischen Unterstützung und in geringerem Maße auf der Ebene der technischen Funktionen.
Als wesentliche Defizite sind festzustellen, dass die Ebene der Anwendungseigenschaften nicht
abgedeckt wird und die Strukturierungsvorgaben mit einfachen Schichtenmodellen die Komplexität
einer Infrastruktur im Vertrieb mit der Notwendigkeit der Einbindung von Systemen nicht
berücksichtigen. Die fachlichen Anforderungen des Technischen Vertriebs werden nicht unterstützt.
Die Ansätze können als technologische Grundlage für die Realisierung eines Portals verwendet
werden. Die vorhandenen Funktionen sind für die Integration von Komponenten verschiedener
Granularität einsetzbar.
3.6 Portalsoftwarearchitekturen
3.6.1 Übersicht und Anwendungsgebiete
Für die Erstellung von Unternehmensportalen werden am Markt Softwarelösungen unter der
Bezeichnung Portalsoftware angeboten. Portalsoftware stellt grundlegende Funktionen für die
Realisierung von Portalen bereit und gibt damit eine Anwendungsstruktur vor. Software mit diesen
Eigenschaften wird auch als Framework bezeichnet (vgl. [Balzert 2000]). Dies manifestiert sich auch
in der englischen Bezeichnung Corporate Portal Frameworks (CPF) [Davydov 2001], [Gurzki 2002].
In [Bullinger 2002] wurden im Rahmen einer Marktübersicht der Aufbau und die Funktionalität von
Portalsoftware untersucht. Aus dem Vergleich der Systeme in Bezug auf ihren technischen Aufbau,
ihre Grundfunktionalität und die enthaltenen funktionalen Zusatzmodule kann aufgrund der
strukturellen Ähnlichkeiten der Systeme eine Referenzarchitektur für Portalsoftware abgeleitet werden
[Bullinger 2002].
3.6.2 Grundlegende Funktion
Eine wesentliche Kernfunktion der Software ist die Erstellung einer integrierten Darstellung
verschiedener dynamischer Informationsquellen und Anwendungen auf den einzelnen Seiten des
Portals (Aggregation). Die Darstellung der Inhalte eines Portals erfolgt durch die Portalsoftware auf
Basis von HTML-basierten Seiten. Hierfür werden Portalvisualisierungskomponenten (PVK)
eingesetzt, die als wiederverwendbare Komponenten auf verschiedenen Seiten des Portals genutzt
werden. PVK stellen die Präsentation (Ausgabe) von Portalanwendungen dar, die im Portal selbst
realisiert sind oder als externe Anwendungen in das Portal eingebunden werden. Im Sprachgebrauch
hat sich für diese Komponenten die Bezeichnung Portlet durchgesetzt, wobei Portlets im eigentlichen
Sinn eine spezielle Java-Technologie für PVK sind. Eine visuelle Abgrenzung zwischen den einzelnen
PVK erfolgt durch die Darstellung von im HTML-Code nachgebildeten Fenstern. Technologiebedingt
sind diese Fenster nicht mit der Funktionalität von Fenstern grafischer Betriebssystemoberflächen
gleichzusetzen. Ihnen fehlt zunächst die Eigenschaft der direkten Manipulierbarkeit mittels
Mausbewegungen. Proprietäre Implementierungen einzelner Portalsoftwarehersteller ermöglichen
jedoch eine Manipulation (vgl. [Goebel und Ritthaler 2004]).
PVK werden durch die Portalsoftware auf der vorgegebenen Portalseite entsprechend der
Konfiguration durch den Systemadministrator für einzelne Nutzer bzw. Nutzergruppen oder durch den
Nutzer selbst platziert. Sie tragen damit grundlegend zur Personalisierbarkeit des Portals bei (vgl.
[Kuhn 2003]). Weitere Aufgaben einer PVK sind neben der Aggregation und Präsentation die
40
Konfiguration des Erscheinungsbildes, das Management des Zustandes des virtuellen Fensters (z. B.
minimiert, maximiert) und die Verwaltung des Zustands (z. B. Hilfe-Modus, Modus: Editieren des
Inhalts) [BEA 2003]. Die Portalsoftware enthält einen Container, der die PVK mit einer
Laufzeitumgebung versorgt und den Lebenszyklus verwaltet. Die Aktivierung einer
Portalseitenerstellung wird durch die Portalsoftware ausgelöst. Mit der Portalseite sind die
zugehörigen PVK assoziiert. Entsprechend dieser Informationen fordert die Portalsoftware die Inhalte
der PVK durch den Container an.
Portalseite
Portalseite
Portlet
C
Portlet
BPortlet
A
Po
rt
le
t C
on
ta
in
er
Po
rt
al
so
ftw
ar
e
Portlet A
Portlet B
Portlet C System 1
System 2
System 3
Abbildung 10: Aggregation mit PVK am Beispiel Portlets nach [Abdelnur und Hepper 2003]
Die PVK akquirieren die darzustellenden Informationen aus einer Anwendung bzw. kombinieren die
Informationen verschiedener Anwendungen zu einem Informationsfragment. Hierzu greifen die PVK
über eine Schnittstelle auf die Anwendung zu und passen ggf. die darzustellende Information an. Die
Inhalte werden über den Container an die Portalsoftware übergeben, die die Inhalte aller PVK zu einer
homogenen Darstellung verarbeitet. Abbildung 10 zeigt diesen Vorgang am Beispiel von Portlets.
Portalsoftware bietet Methoden zur Kommunikation zwischen den PVK an (Interportlet
Communication) [Davydov 2001].
3.6.3 Softwaretechnischer Aufbau und Module
Portalsoftware benötigt für die Ausführung einen Application-Server. Sie ist daher entsprechend dem
Ansatz von Application-Servern in einer 4-Schicht-Architektur aufgebaut. Der clientseitige Teil der
Präsentationsschicht umfasst die Endgeräte der Portalnutzer, wie z. B. Web Browser und mobile
Endgeräte. Die Schicht der Anwendungslogik besteht aus den Bereitstellungsdiensten, die einen Web-
Server umfassen und der eigentlichen Portalsoftware. Portalsoftware lässt sich in funktionale Module
aufteilen, deren Vorhandensein und Ausprägung je nach Produkt variieren kann (basierend auf [Gurzki
und Hinderer 2003]):
Strukturmanagement: Das Strukturmanagement definiert den strukturellen Aufbau und die
Navigierbarkeit des Portals, wie es dem Nutzer personalisiert präsentiert wird. In der Struktur wird die
Anordnung der Portalseiten im Navigationsbaum und die Verlinkung der einzelnen Seiten
untereinander beschrieben. Um der Personalisierbarkeit Rechnung zu tragen, wird im Struktur-
Management vom Betreiber festgelegt, welche Portalseiten für den jeweiligen Nutzer zugänglich sind
bzw. welches seine persönliche Startseite ist. Diesem Basisdienst sind auch die Personalisierungs-
Engines bzw. Classifier (vgl. [Bauer 2001]), die regelbasiert Anwendungen und Inhalte
zielgruppenspezifisch anbieten, zuzuordnen.
41
Layout-Management: Die Aufgabe des Layout-Managements ist die Zusammenstellung der vom
Nutzer angefragten Portalseiten aus den einzelnen Anwendungen und die Erzeugung der dem
Endgerät des Nutzers entsprechenden spezifischen Ausgabe [Gurzki und Hinderer 2003].
Content-Management: Das Content-Management verwaltet alle statischen Inhalte, die nicht aus
externen Quellen aggregiert werden [Davydov 2001]. Zu der Verwaltung des Contents gehören auch
Dokumentenverwaltungsfunktionen [Grimm 2003].
Suche: Die Aufgabe der Suche ist, das gesamte Portal für den Benutzer suchbar zu machen. Die
Suchfunktion steht hierbei vor der Herausforderung, mit verschiedenen Datenquellen umgehen zu
müssen, die neben völlig verschiedener Strukturierung auch völlig verschiedene Semantik besitzen
[Sullivan 2003].
Rechte- und Benutzerverwaltung: Die Verwaltung der Benutzerrechte erfolgt intern in der
Portalsoftware. Die Verwaltung der Benutzer kann sowohl in der Portalsoftware als auch extern, z. B.
in einem Verzeichnisdienst (Directory Service), erfolgen [Gurzki 2004].
Single Sign On: Eng verbunden mit der Rechte- und Benutzerverwaltung ist der Single-Sign-On-
Dienst. Er meldet authentifizierte Portalnutzer an die in das Portal integrierten Anwendungen und
Systeme an. Die integrierten Systeme können über eigene Benutzerverwaltungen und
Authentifizierungsmechanismen verfügen. Die Einzelanmeldungen entfallen für den Nutzer damit
vollständig [Schneider und Zwerger 2002].
Prozessunterstützung: Die Unterstützung von Prozessen gestattet eine visuelle Modellierung des
Prozesses, der im Portal abgebildet werden soll. Hierbei wird die Portalanwendung mit Hilfe eines
Modellierungswerkzeugs und (visueller) Programmierung aus Portalseiten, auf Grundlage der Daten,
der im Portal integrierten Systeme und anwendungsspezifischer Logik entwickelt [Grimm 2003].
Transaktions- und Integrationsdienste: Transaktionsdienste gewährleisten die Transaktions-
sicherheit über die verschiedenen angebundenen Systeme hinweg. Die Integrationsdienste, die gängige
Middleware-Technologien und Web Services unterstützen, gestatten eine Anbindung bestehender
Systeme in das Portal. Sie sind ein integraler Bestandteil von Portalsoftware [Davydov 2001].
Die Schnittstelle zu den betrieblichen Informationssystemen bilden die Integrationsdienste, welche die
Datenaggregation ausführen. Die Bandbreite der Schnittstellenfunktionalität reicht von einfachen
Datenbankschnittstellen (z. B. Java Database Connectivity JDBC, Open Database Connectivity
ODBC) bis hin zu umfangreicher Enterprise-Application- Integration-Funktionalität. Bei einigen
J2EE-basierten Softwareprodukten sind die Integrationsdienste Bestandteil des Application-Servers.
Die Transaktionsdienste gewährleisten die Transaktionssicherheit über die verschiedenen integrierten
Systeme hinweg. Aus den beschriebenen Komponenten leitet [Gurzki und Hinderer 2003] eine
Referenzarchitektur ab, die in Abbildung 11 dargestellt ist. Bei der Standardisierung von
Portaltechnologien nimmt die Portlet-Spezifikation (JSR 168) eine zentrale Rolle ein. JSR 168
beschreibt die Integration bestehender Anwendungen über Portalanwendungskomponenten,
insbesondere die Interaktion mit der Portalsoftware [Abdelnur und Hepper 2003]. Der Portlet-
Spezifikation fehlen derzeit wichtige Elemente, wie z. B. die Inter-Portlet Communication (vgl.
[Kerpen 2004]). Einen ähnlichen, jedoch technologieunabhängigen Ansatz verfolgen die Web Services
for Remote Portlets [Reynolds 2003], [Kropp et al. 2003]. Die Rules Engine API bietet eine
Schnittstelle für regelbasierte Anwendungen an [JSR 94]. Mit der Content Repository API ist im Juni
2005 ein neuer Standard für die Integration von Content-Quellen in Portale verabschiedet worden, der
42
zukünftig den Zugriff auf Content-Repositories wie z. B. von Content-Management-Systemen
produkttransparent gestatten soll [JSR 170]. Anhang C stellt die relevanten Standards für die
Erstellung von Portalen in einer Übersicht dar.
Application Server
Portal-Software
Integrationsdienste
Backend-
System
externe
Datenquelle
Bereitstellungsdienste
HTTP-Server
Portalanwendungen
individ. Anwendung
individ. Anwendung
individ. Anwendung
individ. Anwendung
Portalbasisdienste
Strukturmanagement
Content-Management
Rechte- und Benutzer-
verwaltung
Suche
Prozessunterstützung
Po
rt
al
-A
PI
Layout-Management
Erweiterte Portal-Module
externe
Benutzer-
verwaltung
Endgeräte
Präsentation
A
nw
endungslogik
B
IS
Web-Browser WAP-Browser andere
andere
Single Sign On
Transaktionsdienste
Abbildung 11: Referenzarchitektur für Portalsoftware nach [Gurzki und Hinderer 2003]
3.6.4 Gegenüberstellung und Bewertung
Die beschriebenen Module und der Aufbau der Referenzarchitektur basieren auf einer
Verallgemeinerung des Aufbaus kommerziell verfügbarer Portalsoftware. Tabelle 7 zeigt basierend
auf [Bullinger 2002] den technischen Rahmen und die optionalen Module exemplarisch ausgewählter
Systeme und deren Erfüllungsgrad gegen wesentliche Elemente des Referenzmodells aus Kapitel
3.6.3. Diese umfassen aus technischer Sicht die Verwendung von Portalanwendungen (Portlets, I-Lets
etc.), eines Application-Servers sowie das Vorhandensein von Struktur- und Layout-Management
sowie Integrations- bzw. Transaktionsdiensten. Analog zu den vorangegangenen Abschnitten werden
auch hier wiederum die Erfüllung der Portaleigenschaften, die Strukturierungsvorgaben und die
Granularität des eigenen internen Komponentenmodells sowie die Granularität der extern anbindbaren
43
Komponentenmodelle bewertet. Eine Bewertung der Eigenschaften auf Fachebene führt zur
abschließenden Bewertung von Portalsoftware.
Systeme
Eigenschaften
IBM
Websphere
Oracle
Portal
Plumtree
Corporate
Portal
SAP
Enterprise
Portal
AbaXX
Portal
Technischer Rahmen
Portalanwendungen
(Portlets, I-Lets etc.)
+ + + + +
Verwendung eines
Application-Servers
+ + + + +
Struktur- und Layout-
Management
+ + + + +
Integrationsdienste/
Transaktionsdienste
+ + + + +
Module
Content Management + – – + –
Rechte- und
Benutzerverwaltung
+ + + + +
Prozessunterstützung + – – + +
Erweiterte
Portalmodule
+ + + + +
Portaleigenschaften
TU TF AE TU TF AE TU TF AE TU TF AE TU TF AE
Erstellung internet-
basierter Anwendungen ● ● ○ ● ● ○ ● ● ○ ● ● ○ ● ● ○
Personalisierung und
Rollen ● ◐ ○ ● ◐ ○ ● ◐ ○ ● ◐ ○ ● ◐ ○
Benutzermanagement ● ● ○ ● ● ○ ● ● ○ ● ● ○ ● ● ○
Prozessunterstützung ● ◐ ○ ● ◐ ○ ● ◐ ○ ● ◐ ○ ● ● ○
Integration ● ◐ ○ ● ◐ ○ ● ◐ ○ ● ◐ ○ ● ◐ ○
Homogenität ● ● ○ ● ● ○ ● ● ○ ● ● ○ ● ● ○
Architektur
Strukturierungs-
vorgaben
Definition
Integrations-
API, Grund-
struktur Portal
Definition
Integrations-
API, Grund-
struktur Portal
Definition
Integrations-
API, Grund-
struktur Portal
Definition
Integrations-
API, Grund-
struktur Portal
Definition
Integrations-
API, Grund-
struktur Portal
Granularität des
Komponentenmodells
(intern/extern)
fein, mittel,
grob/fein,
mittel, grob
fein, mittel,
grob/fein,
mittel, grob
fein, mittel,
grob/fein,
mittel, grob
fein, mittel,
grob/fein,
mittel, grob
fein, mittel,
grob/fein,
mittel, grob
Fachebene
Abbildung Prozesse
des Techn. Vertriebs
○ ○ ○ ○ ○
Bewertung
Beitrag zu einer
Portalarchitektur
Framework
mit Basisfunk-
tionalität
Framework
mit Basisfunk-
tionalität
Framework
mit Basisfunk-
tionalität
Framework
mit Basisfunk-
tionalität
Framework
mit Basisfunk-
tionalität
Legende: Umfang + enthalten, – nicht enthalten; Erfüllungsgrad ● voll erfüllt, ◐ teilweise erfüllt, ○ nicht erfüllt.
Tabelle 7: Darstellung und Bewertung von Portalsoftware (in Teilen basierend auf [Bullinger 2002])
44
Die Portalsoftwarearchitekturen geben im Sinne eines Frameworks mit portalspezifischen APIs eine
grobe Grundstruktur eines Portals mit Client, Portalsoftware und den zu integrierenden Systemen auf
abstrakter Ebene vor. Als Hauptdefizite sind festzustellen, dass die Struktur nicht vorgibt, welche
Anwendungen konkret integriert werden müssen und mit welchen Methoden des Frameworks dies
erfolgt. Ein konkreter logischer oder technischer Zusammenhang zwischen Anwendungen im Portal
und extern eingebundenen Systemen wird nicht dargestellt. Eine Unterstützung der Entwicklung von
Portalen erfolgt auf der Ebene TU und durch die portalspezifische API weitgehend auch auf der
Ebene TF. Als weitere Defizite sind die fehlenden Beschreibungen der Anwendungseigenschaften von
Portalen und der Fachebene des Technischen Vertriebs festzustellen. Portalsoftware eignet sich als
technisches Framework für die Implementierung von Portalen. Zu einer Portalarchitektur trägt sie eine
definierte Basisfunktionalität und Portalinfrastruktur auf hoher funktionaler Abstraktionsebene bei.
3.7 Integrationsarchitekturen
Die Integration von Anwendungen erfordert eine Betrachtung der Schnittstellen und des Transports
der Daten zwischen den Anwendungen. Unter dem Begriff Enterprise Application Integration (EAI)
werden verschiedene Technologien und Architekturen zur Integration zusammengefasst, welche die
automatisierte Kommunikation und Interoperabilität unterschiedlicher Anwendungen und
Geschäftsprozesse innerhalb und zwischen Organisationen ermöglichen [Winkeler et al. 2001]. Es
lassen sich grundlegend vier EAI-Typen nach Abstraktionsgrad der Integration unterscheiden
[Linthicum 2000]:
− Data Level: Integration durch die Bewegung von Daten zwischen zwei Informationsspeichern,
typischerweise Datenbanktabellen, ggf. mit Transformation der Daten.
− Application Interface Level: Integration durch die Nutzung öffentlich bereitgestellter
Programmierschnittstellen. Zu diesem Typ gehören insbesondere APIs, Remote Procedure Calls,
Message Oriented Middleware. In diese Ebene lassen sich auch Web Services einordnen.
− Method Level: Integration auf Basis bereitgestellter Geschäftslogik, die im zu integrierenden
System enthalten ist. Die Integration erfolgt über die bereitgestellten Methoden. Zu diesem Typ
gehören verteilte Objekttechnologien (CORBA, DCOM) und EAI-Toolsets.
− User Interface Level: Integration über die Benutzungsoberfläche einer Software und Nutzung der
dort angebotenen Funktionen.
Die Abstraktionsgrade werden mit den zugeordneten Technologien und Produktbeispielen in Tabelle 8
dargestellt. Der Begriff EAI steht in enger Verbindung mit dem Begriff Middleware. Middleware, wie
z. B. CORBA, DCOM und RPC, unterstützt die verteilte Kommunikation zwischen Schnittstellen,
führt jedoch keine Konvertierung zwischen verschiedenen Anwendungsdatenmodellen durch. EAI-
Toolsets/Integration-Server unterstützen die Abbildung verschiedener Datenmodelle und die damit
einhergehende Konvertierung sowie die Abbildung von Prozessen [Schott und Mäurer 2001]. EAI-
Werkzeuge verwenden zur Realisierung der Schnittstellen die Mechanismen von Middleware. Die
vorliegende Arbeit sieht Middleware aufgrund der Überschneidungen als eine Teilmenge von EAI
(vgl. auch [Linthicum 2000], [Quantz und Wichmann 2003]). Die untersuchten Integrations-
architekturen umfassen Modelle und Verfahren für die Integration von Anwendungen auf
verschiedenen Abstraktionsebenen. Tabelle 8 stellt diese einander gegenüber. Jedem Abstraktionsgrad
werden konkrete Technologien zugewiesen. Hierbei ergeben sich Überlappungen zwischen den
Abstraktionsgraden und Technologien, die in der Tabelle durch die Überlappung der Tabellenspalten
45
verdeutlicht werden. Für die Technologien werden Produktbeispiele aufgeführt. Für die Bewertung der
Integrationsarchitekturen werden wiederum die Ebenen der Portaleigenschaften herangezogen, wobei
der Betrachtungsschwerpunkt auf den Portaleigenschaften Prozessorientierung, Integration und
Homogenität liegt. Die Teileigenschaften internetbasierte Anwendung, Benutzermanagement,
Personalisierung und Rollenorientierung liegen außerhalb der Ansätze von Integrationsarchitekturen
und werden daher nicht betrachtet. Analog zu dem vorangegangenen Kapitel werden die
Strukturierungsvorgaben und die Granularität des Komponentenmodells untersucht. Die Betrachtung
des Komponentenmodells beschränkt sich auf den Umgang mit den zu integrierenden Komponenten.
Abschließend werden die Teilbewertungen zu einer Gesamtbewertung des jeweiligen Beitrags des
Ansatzes zu einer Portalarchitektur zusammengefasst.
Abstraktionsgrad
Eigenschaften
Data Level Application
Interface Level
Method Level User Inter-
face Level
Technologien Datenbank,
Transaction
Server
API, RPC,
Message
Oriented
Middleware
Verteilte
Objekt-
technologien,
Web Services
EAI-
Toolsets/
Integration
Server
/
Produktbeispiele
(Hersteller, Produkt-
bezeichnung)
Microsoft
MTS, BEA
Tuxedo
Sun Java-RPC,
DCE-RPC,
Microsoft
MSMQ
OMG
CORBA,
Microsoft
DCOM
Microsoft
BizTalk,
webmethods
inc.
webmethods
/
Portaleigenschaften
TU TF AE TU TF AE TU TF AE TU TF AE TU TF AE
Integration ● ○ ● ○ ○ ● ◐ ○ ● ◐ ○ ● ○ ○
Homogenität ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ● ○ ○
Prozessorientierung ○ ○ ○ ○ ○ ○ ● ◐ ○ ● ◐ ○ ○ ○ ○
Architektur
Strukturierungs-
vorgaben
Schnittstellen
Aufbau
Schnittstellen
Aufbau
Dienste
Schnittstellen
Objekte
Aufbau
Dienste
Schnittstellen
Aufbau
Bereit-
stellung
Präsentation
Aufbau
Granularität des
Komponenten-
modells (extern)
mittel fein fein fein bis grob grob
Fachebene
Abbildung Prozesse
des Techn. Vertriebs
○ ○ ○ ○ ○
Gesamtbewertung
Beitrag zu einer
Portalarchitektur
Integrations-
technologie,
Teil-
architektur
Integrations-
technologie,
Teil-
architektur
Integrations-
technologie,
Teil-
architektur
Integrations-
technologie,
Teil-
architektur
Integrations-
technologie,
Teil-
architektur
Legende: Erfüllungsgrad ● voll erfüllt, ◐ teilweise erfüllt, ○ nicht erfüllt, / nicht zutreffend.
Tabelle 8: Darstellung und Bewertung von Integrationsarchitekturen
46
Die betrachteten Architekturen definieren den Aufbau der Integration für verschiedene Szenarien und
sind auf die Einbindung von Komponenten verschiedener Granularität spezialisiert.
Portaleigenschaften werden vorwiegend im Bereich Integration auf der Ebene der technologischen
Unterstützung erfüllt. Die Strukturierungsvorgaben erfolgen eingeschränkt durch die Definierbarkeit
von Schnittstellen, Diensten, Objekten oder Präsentationen. Als weiteres Defizit ist anzuführen, dass
keine Aussagen über die eingebundenen Systeme und die Fachebene des Technischen Vertriebs
getroffen werden. Die untersuchten Architekturen können als Technologie bzw. als Teilarchitekturen
für die Integration im Rahmen einer Portalarchitektur eingesetzt werden.
3.8 Architekturmodelle für Portale
3.8.1 Übersicht und Anwendungsgebiete
Architekturmodelle für Portale gehen über die reine Architektur von Portalsoftware hinaus und
beschreiben den Gesamtaufbau des Portals mit seinen integrierten Systemen [Sullivan 2003]. Sie
stellen eine Spezialisierung allgemeiner Architekturmodelle dar. Als Spezialform beschreiben sie
neben technischen Aspekten auch die Fachebene eines Portals. Diese umfasst die im Portal zu
realisierenden Prozesse. Architekturmodelle bestehen aus verschiedenen Repräsentationen des
Systems, die verschiedene Betrachtungswinkel auf Objekte der Architektur, z. B. auf Organisation
oder Datenobjekte, darstellen (vgl. [Zachman 1987]). Die Repräsentationen werden als Sichten
bezeichnet. Einen wichtigen Aspekt von Architekturmodellen stellt die Reproduzierbarkeit des
Modells dar [Zachman 1987]. Sichtenbasierte Architekturmodelle existieren in verschiedenen Formen.
Als wichtige Vertreter von Architekturmodellen sind hierbei ARIS (vgl. [Scheer 1998]) und das
Modell der ganzheitlichen Informationssystemarchitektur (ISA) (vgl. [Krcmar 1990]) zu nennen. Die
Arbeit lehnt sich an den Ansatz der ISA als Basis für die weiteren Betrachtungen an, da diese die
einzelnen Sichten im Gegensatz zur Architektur integrierter Informationssysteme (ARIS) unabhängig
voneinander hält (vgl. [Krcmar 2003]). Im Rahmen der Arbeit wird die ISA als unternehmensweite
Architektur und als allgemeines Modell auf die integrative Architektur von Portalen angewendet. Dies
erleichtert insbesondere die Bewertung von Architekturen, die nicht unmittelbar entsprechend dieser
Systematik aufgebaut wurden. Die ISA umfasst verschiedene Teilsichten, die verschiedene Aspekte
abdecken. Diese Sichten sind die Strategie, die Aufbauorganisations-, Prozess-, Anwendungs-, Daten-
und Kommunikationsarchitektur sowie die Infrastruktur. Die Strategie zieht sich durch das gesamte
Modell. Der Aufbau der ISA ist in Abbildung 12 dargestellt.
Abbildung 12: Aufbau von Architekturmodellen am Beispiel der ISA (nach [Krcmar 1990])
47
Die Teilmodelle Strategie und Aufbauorganisation werden im Rahmen dieser Arbeit durch die
Vorgabe des Anwendungsfalls Technischer Vertrieb entsprechend den Ausführungen des Kapitels 3.3
als gegeben vorausgesetzt.
Im Folgenden werden bedeutende Architekturansätze für Portale aus Wissenschaft und Praxis
vorgestellt. Gemeinsames Merkmal der Ansätze ist, dass diese über den rein technologisch-
funktionalen Ansatz der bereits untersuchten Technologien, Plattformen und Frameworks hinaus
gehen und auch die Ebene der Portalanwendungseigenschaften gemäß Kapitel 3.2 einbeziehen. Nach
der Vorstellung der Ansätze werden diese in einem zweiten Schritt gegen die Eigenschaften von
Architekturmodellen bewertet. Im Einzelnen werden folgende Architekturmodelle als relevant
identifiziert:
Portal Composite Pattern [Galic et al. 2003]: Das Portal Composite Pattern identifiziert
portalrelevante Muster für Geschäftsprozesse und Anwendungsintegration, auf deren Basis mit Hilfe
des musterorientierten Ansatzes eine individuelle Portalarchitektur abgeleitet werden kann. Der Ansatz
ist somit einem Vorgehensmodell zuzuordnen. Die Ableitbarkeit einer Gesamtarchitektur wird für die
IBM Websphere Plattform gewährleistet.
Referenzarchitektur für Portale [Merz 2002]: Die Referenzarchitektur für Portale beschreibt eine
Softwarearchitektur für Portale auf Basis von J2EE. Im Modell wird der grundlegende
softwaretechnische Aufbau eines Portals mit verschiedenen Java-basierten Integrationsmethoden
dargestellt.
Corporate Portal Framework [Davydov 2001]: Die Referenzarchitektur des Corporate Portal
Framework wurde aus einer Betrachtung bestehender Portale abgeleitet. Die Architektur beschreibt
den strukturellen Aufbau eines Portals mit seinen Softwarebestandteilen. Die Bestandteile werden
funktional dargestellt. Die Architektur beschränkt sich auf eine allgemeine Beschreibung der
Gesamtanwendung.
Architektur für Collaboration-Portale [Puschmann 2003]: Die Architektur für Collaboration-
Portale ist eine umfassende Informationssystemarchitektur mit den Bestandteilen Applikations- und
Integrationsarchitektur. Das Grundmodell wird anhand von Ausprägungen detailliert. Anhand dieser
Ausprägungen werden die enthaltenen Prozessmodelle abgeleitet, die damit nicht generisch sind.
Architektur für CRM- und Prozess-Portale in Banken [Schmid 2001]: Die Architektur beschreibt
eine Informationssystemarchitektur mit Prozess- und Applikationsarchitektur. Der Schwerpunkt der
Arbeit liegt auf der Prozessarchitektur und dem Zusammenspiel mit einem zentralen CRM-System.
Integrationsarchitektur für komponentenbasierte E-Business-Anwendungen [Weisbecker et al.
2001], [Weisbecker 2001]: Die Architektur beschreibt den Aufbau von E-Business-Anwendungen auf
Basis von Komponenten, die sich in Basis- und Anwendungskomponenten aufteilen. Mit Hilfe dieser
Komponenten werden einzelne Anwendungen realisiert. Ergänzt wird die Architektur durch einen
Komponentenkatalog, der auf dem Markt erhältliche Software umfasst.
Customer-Self-Service-System im Technischen Kundendienst [Hermes 1999]: Die Arbeit
entwickelt ein technisches und organisatorisches Konzept für die webbasierte Abwicklung der mit
dem Technischen Kundendienst verbundenen Prozesse. Sie definiert im Rahmen eines Gesamtmodells
die Prozesse und leitet hieraus eine Architektur ab.
48
Architektur Electronic Commerce Portal [Bauer 2001]: Die Architektur beschreibt den Aufbau der
Präsentationsschicht eines Portals, den grundlegenden softwaretechnischen Aufbau eines Portals sowie
anhand von Fallbeispielen den exemplarischen Aufbau von Unternehmensportalen.
3.8.2 Gegenüberstellung und Bewertung
Im Vergleich der Architekturen wird bewertet, inwieweit sie den Anforderungen an
Architekturmodelle gerecht werden. Hierfür werden die Bestandteile der ISA spezifisch für den
Bereich Portale detailliert. Die Prozessarchitektur muss den allgemeinen Vertriebsprozess abbilden
und damit die Leistungen des Technischen Vertriebs unterstützen (vgl. Kapitel 3.3.2). Über die
allgemeinen Prozesse hinaus wird der Grad der Abbildung der Prozesse des Technischen Vertriebs
bewertet.
Die Anwendungsarchitektur muss zur Beschreibung einer integrativen Architektur die Anforderungen
an die zu integrierenden Systeme (vgl. Kapitel 3.4) beschreiben und eine Anordnungsstruktur für
definierte Komponenten eines Komponentenmodells enthalten (vgl. Kapitel 3.5.1 und 3.5.3.1). Zur
Verknüpfung der Prozess- und Anwendungssicht ist eine Abbildung von Geschäftsprozessen auf
Systeme erforderlich.
Als weiteres Kriterium für die Datenarchitektur ist ein statisches Datenmodell zu sehen. Im Rahmen
der Kommunikationsarchitektur ist das Vorhandensein eines Modells für die Integration von Systemen
notwendig. Hierbei können die in Kapitel 3.7 untersuchten Methoden eingesetzt werden. Für den
Austausch von Daten und Dokumenten sollten nach Möglichkeit Standards (z. B. BMEcat für
Kataloge) eingesetzt werden. Für Portale kann die Portalsoftware als unterste Infrastrukturebene
definiert werden. Innerhalb dieser Ebene muss jeweils ein Modell für die Suche und für die
Personalisierung im Portal vorhanden sein.
Über diese Kriterien hinausgehend werden die Architekturen gegen die in Kapitel 3.2 eingeführten
Ebenen der Portaleigenschaften bewertet. Hierbei wird auf eine Betrachtung der technologischen
Unterstützung verzichtet, da diese eine Voraussetzung für Architekturmodelle darstellt. Die
zusammenfassende Bewertung zeigt den Erfüllungsgrad der Architekturen in Bezug auf den Ansatz
eines Architekturmodells. Die Gegenüberstellung der untersuchten Architekturen in Tabelle 9 (siehe
folgende Seite) zeigt, dass keine den geforderten Umfang für ein Architekturmodell für Portale im
Technischen Vertrieb abbildet. Alle fünf Architekturelemente, die für die Beschreibung einer
Portalarchitektur relevant sind, werden nicht hinreichend definiert. Die Portaleigenschaften werden
von den Modellen weitgehend oder voll erfüllt. Die besonderen Prozessanforderungen des
Technischen Vertriebs und die bestehende Systemlandschaft werden nur in geringem Umfang
berücksichtigt. Keines der untersuchten Modelle stellt ein vollständiges Architekturmodell für Portale
im Technischen Vertrieb dar.
49
Architekturmodell
Erfüllungsgrad P
or
ta
l C
om
po
sit
e
Pa
tte
rn
R
ef
er
en
za
rc
hi
te
kt
ur
fü
r
Po
rt
al
e
C
or
po
ra
te
P
or
ta
l
Fr
am
ew
or
k
A
rc
hi
te
kt
ur
C
ol
la
bo
ra
tio
n
Po
rt
al
e
A
rc
hi
te
kt
ur
fü
r
C
R
M
u
nd
P
ro
ze
ss
-
Po
rt
al
e
In
te
gr
at
io
ns
ar
ch
i-
te
kt
ur
E
-B
us
in
es
s
A
nw
en
du
ng
en
C
us
t.
Se
lf
Se
rv
ic
e
Sy
st
em
im
T
ec
hn
.
K
un
de
nd
ie
ns
t
A
rc
hi
te
kt
ur
E
le
ct
ro
ni
c
C
om
m
er
ce
P
or
ta
l
Quelle (siehe Legende) [1] [2] [3] [4] [5] [6] [7] [8]
Prozessarchitektur
Werbliche Prozesse ◐ ○ ○ ◐1 ● ◐ ○ ◐
Informationsprozesse ◐ ○ ○ ◐1 ● ◐ ○ ◐
Beratungsprozesse ◐ ○ ○ ◐1 ● ◐ ○ ◐
Transaktionsprozesse ◐ ○ ○ ◐1 ● ◐ ○ ◐
After-Sales-Prozesse ◐ ○ ○ ◐1 ● ◐ ● ◐
Abbildung der Prozesse des
Technischen Vertriebs ○ ○ ○ ◐1 ◐ ○ ◐ ○
Anwendungsarchitektur
Anforderungsbeschreibung für
integrierte Bestandssysteme ◐ ○ ○ ◐ ○ ○ ◐ ○
Strukturierungsvorgaben ◐ ◐ ◐ ◐ ◐ ◐ ◐ ◐
Komponentenmodell ◐ ◐ ● ◐ ◐ ● ○ ○
Abbildung von
Geschäftsprozessen auf Systeme ◐ ◐ ○ ◐ ◐ ○ ● ◐
Datenarchitektur
Datenmodell ○ ○ ○ ○ ○ ○ ● ○
Kommunikationsarchitektur
Modell für Integration ● ○ ○ ◐ ◐ ◐ ○ ○
Berücksichtigung von Standards ◐ ◐ ○ ◐ ○ ◐ ○ ○
Infrastruktur
Modell für Suche ● ○ ○ ● ○ ○ ○ ○
Modell für Personalisierung ● ○ ○ ● ○ ○ ○ ○
Portaleigenschaften TF AE TF AE TF AE TF AE TF AE TF AE TF AE TF AE
Internetbasiert ● ● ● ● ◐ ◐ ● ● ● ● ● ◐ ● ● ◐ ●
Personalisierung und Rollen-
orientierung ● ◐ ◐ ● ◐ ◐ ● ● ● ● ◐ ◐ ◐ ◐ ◐ ◐
Benutzermanagement ● ● ● ● ● ● ● ● ● ● ● ● ◐ ◐ ● ●
Prozessorientierung ● ● ◐ ● ◐ ◐ ● ● ● ● ◐ ◐ ● ◐ ◐ ◐
Integration und Homogenität ● ● ◐ ● ◐ ◐ ● ● ● ● ◐ ◐ ◐ ◐ ◐ ◐
Zusammenfassende Bewertung
Erfüllung Eigenschaften eines
Architekturmodells für Portale im
techn. Vertrieb
* – – * – * * –
Legende: Erfüllungsgrad ● voll erfüllt, ◐ teilweise erfüllt, ○ nicht erfüllt; 1 nicht-generisch an Fallbeispielen
aufgezeigt. Bewertung + gut geeignet, * bedingt geeignet, – nicht geeignet;
Quellen: [1]: [Galic et al. 2003], [2]: [Merz 2002], [3]: [Davydov 2001], [4]: [Puschmann 2003],
[5]: [Schmid 2001], [6]: [Weisbecker et al. 2001], [Weisbecker 2001], [7]: [Hermes 1999], [8]: [Bauer 2001].
Tabelle 9: Vergleich und Bewertung der Architekturmodelle für Portale
50
3.9 Zusammenfassung der Grundanforderungen und Defizite
In den vorangegangenen Abschnitten wurde der aktuelle Stand der Wissenschaft, Technik und
Anwendung in den Themenfeldern Architekturen und Technischer Vertrieb untersucht. Aus den
Ergebnissen der Untersuchung der einzelnen Bereiche folgen zwei Grundanforderungen an den
Entwurf integrativer Portalarchitekturen für das spezielle Anwendungsfeld des Technischen Vertriebs:
Grundanforderung G1: Erfüllung aller Ebenen der Portaleigenschaften. Zur Erfüllung der
geforderten Portaleigenschaften durch eine Portalarchitektur müssen die Eigenschaften auf den
Ebenen Anwendungseigenschaften, technische Funktionalität und technische Unterstützung,
entsprechend Kapitel 3.2, gewährleistet werden.
Grundanforderung G2: Unterstützung der Erstellung der Leistungen im Technischen Vertrieb.
Um die fachlichen Anforderungen des Anwendungsfelds gemäß Kapitel 3.3 zu erfüllen, muss die
Erstellung der Leistungen des Technischen Vertriebs im Rahmen des gesamten Vertriebsprozesses
unterstützt werden.
Neben den Grundanforderungen wurden unterschiedlich stark ausgeprägte bereichsspezifische
Kerndefizite identifiziert, die den Aufbau von Portalen für den Technischen Vertrieb erschweren:
Defizit D1: Fehlende kundenorientierte Integration der Softwaresysteme des Technischen
Vertriebs. Die untersuchten Systeme decken lediglich Teilfunktionen des Prozesszyklus des
Technischen Vertriebs ab (vgl. Kapitel 3.4). Die Systeme überlappen sich dabei in ihrer Funktionalität.
Für die Realisierung eines durchgehenden Vertriebsprozesses sind jedoch eine nicht überlappende
Kombination der von vertrieblichen Systemen realisierten Teilfunktionen und eine softwaretechnische
Integration erforderlich. Die in Kapitel 3.7 betrachteten Integrationsarchitekturen beschränken sich
lediglich auf die Bereitstellung einer technischen Funktionalität. Eine Integration der Prozesse und
Systeme des Technischen Vertriebs erfordert aber eine Beschreibung der erforderlichen Integration zu
einer kundenorientierten Anwendung und der technischen Ausführung.
Defizit D2: Ungenügende softwaretechnische Strukturierung für Portale. Die in Kapitel 3.5
untersuchten Ansätze für die Realisierung von webbasierten Anwendungen beschränken sich
weitgehend auf die technologische Unterstützung bei der Erstellung von Portalanwendungen. Die
softwaretechnischen Strukturierungsvorgaben sind insbesondere unter dem Aspekt der einzubindenden
Systeme des Technischen Vertriebs ungenügend. Die in Kapitel 3.6 betrachteten
Portalsoftwarearchitekturen beschränken sich als Frameworks auf die Vorgabe einer grundlegenden
Struktur und einer API auf der Ebene TU und weitgehend auf der Ebene TF. Ein konkreter logischer
oder technischer Zusammenhang zwischen Anwendungen im Portal und extern eingebundenen
Systemen wird nicht dargestellt. Ein softwaretechnischer Entwurf erfordert jedoch eine Strukturierung
des gesamten Portals mit den eingebundenen Systemen unter Berücksichtigung der wechselseitigen
Abhängigkeiten.
Defizit D3: Fehlendes Architekturmodell für Portale für den Technischen Vertrieb. Die in
Kapitel 3.8 untersuchten Architekturmodelle für Portale enthalten die für eine reproduzierbare
Beschreibung erforderlichen Sichten für den Aufbau eines Portals für den Technischen Vertrieb nicht
oder nur teilweise. Der softwaretechnische Entwurf eines solchen Portals erfordert jedoch zur
Beschreibung ein Architekturmodell mit einer Prozess-, Anwendungs-, Daten- und
Kommunikationsarchitektur und einer Beschreibung der erforderlichen Infrastruktur. Für den Entwurf
eines Portals ist somit eine Neuentwicklung eines Architekturmodells erforderlich.
4 Entwicklung eines Architekturmodells für Portale im
Technischen Vertrieb
4.1 Definition des Lösungsansatzes der Arbeit
Die im vorangegangenen Kapitel durchgeführte Untersuchung des Stands der Wissenschaft und
Technik stellt das Fehlen geeigneter architektonischer Ansätze für die Entwicklung von Portalen für
den Technischen Vertrieb fest. Die vorliegende Arbeit entwickelt zur Behebung dieser Defizite ein
Architekturmodell für Portale im Technischen Vertrieb. Mit der Entwicklung des Architekturmodells
werden die in Tabelle 10 aufgeführten Detailziele verfolgt, welche direkt die Grundanforderungen und
Defizite aus Kapitel 3 adressieren und damit einen Ansatz für die Lösung der aufgezeigten
Problematik darstellen.
Nr. Detailziel D1 D2 D3 G1 G2
1 Integration der überlappenden Teilfunktionen der Systeme des
Technischen Vertriebs zu einer kundenorientierten Anwendung. ╳ ╳
2 Entwicklung einer softwaretechnischen Struktur für Portale mit
den darin integrierten Anwendungen. ╳ ╳
3 Entwicklung einer portalspezifischen Prozessarchitektur zur
Realisierung des Vertriebsprozesses des Technischen Vertriebs. ╳ ╳ ╳
4 Entwicklung einer portalspezifischen Anwendungsarchitektur. ╳ ╳
5 Entwicklung einer portalspezifischen Datenarchitektur. ╳ ╳
6 Entwicklung einer portalspezifischen Kommunikations-
architektur. ╳ ╳
7 Entwicklung einer portalspezifischen Infrastrukturarchitektur. ╳ ╳
8 Unterstützung von Personalisierung und Rollenorientierung zur
Erfüllung der Portaleigenschaften auf den Ebenen AE und TF. ╳
9 Unterstützung von Benutzermanagement zur Erfüllung der
Portaleigenschaft auf den Ebenen AE und TF. ╳
10 Unterstützung von Prozessorientierung zur Erfüllung der
Portaleigenschaft auf den Ebenen AE und TF. ╳
11 Unterstützung von Integration und Homogenität zur Erfüllung
der Portaleigenschaften auf den Ebenen AE und TF. ╳
Legende: D… Defizit; G… Grundanforderung; ╳ Zuordnung.
Tabelle 10: Definition der Detailziele der Arbeit
Die Detailziele der Arbeit decken die im Stand der Wissenschaft identifizierten Defizite und
Grundanforderungen thematisch ab. Hieraus kann geschlossen werden, dass es sich bei dem gewählten
Lösungsansatz mit den aufgeführten Unterzielen um eine valide Möglichkeit zur Lösung bestehender
Defizite bzw. Verbesserung der Ist-Situation handelt. Die Detailziele werden daher als Kriterien bei
der Evaluation des Architekturmodells in Kapitel 11.4 eingesetzt. Die spezifischen Eigenschaften der
Detailziele 1 bis 7 werden in Kapitel 5 bis 9 bei der Entwicklung der Teilmodelle beschrieben. Die
Detailziele 8 bis 11 leiten sich aus den spezifischen Grundanforderungen an Portale ab und sind damit
Querschnittsziele, die in den Ansätzen der weiteren Kapitel der vorliegenden Arbeit berücksichtigt
werden müssen. Diese Eigenschaften wurden bereits im Rahmen der Betrachtung der Eigenschaften
von Portalen in Kapitel 3.2 eingehend erläutert.
52
4.2 Vorgehen und Methodik zum Aufbau des Architekturmodells
Die Einteilung in Sichten vereinfacht die Modellierung von Unternehmensportalen [Amberg et al.
2003]. Aus diesem Grund erweitert das Architekturmodell für Portale das Modell der ganzheitlichen
Informationssystemarchitektur (ISA) nach [Krcmar 1990] und [Krcmar 2003] um die erforderlichen
Spezifika für Portale im Technischen Vertrieb in Form von architektonischen Elementen. Das
Architekturmodell für Portale im Technischen Vertrieb teilt sich entsprechend des Grundmodells der
ISA in sieben Teilarchitekturen auf, die verschiedene Sichten auf die Gesamtarchitektur darstellen und
diese vollständig beschreiben. Die Teilarchitekturen Strategie und Aufbauorganisation werden im
vorliegenden Fall durch das Anwendungsfeld des Technischen Vertriebs, beschrieben in Kapitel 3.3.3,
fixiert und daher im Folgenden nicht mehr näher betrachtet. Die Erweiterung umfasst die Einführung
von portalspezifischen Elementen für die Beschreibung der einzelnen Teilarchitekturen der ISA. Die
im Rahmen der Arbeit zu entwickelnden portalspezifischen Elemente sind als Erweiterung der ISA in
den jeweiligen Feldern für die Teilarchitekturen in Abbildung 13 dargestellt. Die Strategie und damit
der Anwendungsfall des Technischen Vertriebs ist im gesamten Modell zu berücksichtigen. Dies wird
entsprechend der ISA zu durch den durchgehenden dunkelgrauen Bereich verdeutlicht.
Abbildung 13: Elemente und Aufbau des erweiterten Portalarchitekturmodells auf Basis der ISA
53
Die fünf portalspezifischen Teilarchitekturen sind im Einzelnen:
− Prozessarchitektur für Portale: Die Prozessarchitektur leitet die portalrelevanten
Geschäftsprozesse, die im Weiteren als Portalprozesse bezeichnet werden, aus dem
Anwendungsfeld des Technischen Vertriebs ab. Die Ableitung erfolgt auf der Basis einer
Befragung von Unternehmen mit Technischem Vertrieb. Als zusammengehörig identifizierte
Portalprozesse werden zu Prozessbündeln zusammengefasst. Ergebnis dieser Bündelung ist eine
resultierende Übersicht, die als Portalprozesslandkarte bezeichnet wird. Diese stellt die Grundlage
für die Ableitung von Komponenten dar und bildet damit den Kern der Prozessarchitektur.
(Kapitel 5).
− Anwendungsarchitektur für Portale: Die Anwendungsarchitektur beschreibt den strukturellen
softwaretechnischen Aufbau des Architekturmodells auf Basis von Komponenten. Die
Komponentenarchitektur definiert die aus der Prozessarchitektur abgeleiteten Komponenten auf
Funktionsebene. Zur Adressierung der funktionalen Überlappung der Systeme werden für die
Modellbeschreibung abstrakte Komponenten verwendet, die auf verschiedene reale Systeme
abbildbar sind. Das im Rahmen der Anwendungsarchitektur zu entwickelnde Schichtenmodell
beschreibt eine logische Struktur anhand einer Gruppierung der Komponenten unter
Berücksichtigung der Erfordernisse des Datenflusses und der funktionalen Abhängigkeit
(Kapitel 6).
− Datenarchitektur für Portale: Aus der Anwendungs- und Prozessarchitektur wird die
Datenarchitektur abgeleitet. Sie stellt statische Datenzusammenhänge zwischen den verwendeten
Daten dar. Die Architektur ist in Grunddatenmodelle eingeteilt, die ausgehend von dem
Komponentenmodell die wesentlichen Daten von Portalanwendungen aufzeigen.
(Kapitel 7).
− Infrastrukturarchitektur für Portale: In einem gegenüber [Krcmar 2003] erweiterten
abstrakteren Verständnis der Infrastruktur beschreibt diese Sicht die softwaretechnische Basis
eines Portals als unterste Infrastrukturebene. Die Sicht der Infrastruktur wird zu einer
Infrastrukturarchitektur erweitert. Hierzu gehören insbesondere die Eigenschaften der
Portalumgebung, die durch ein Modell für die Suche im Portal, ein Authentifizierungs- und
Rollenmodell, ein Personalisierungs- und Individualisierungsmodell sowie einer Beschreibung der
softwaretechnischen Portalinfrastruktur definiert wird. Darüber hinaus wird ein Modell für die
Abbildung der abstrakten Komponenten der Anwendungsarchitektur auf betriebliche
Informationssysteme beschrieben (Kapitel 8).
− Kommunikationsarchitektur für Portale: Die Kommunikationsarchitektur charakterisiert die
Kommunikation im Architekturmodell und zeigt im Schnittstellenmodell den Zusammenhang der
Komponenten und ihre Abhängigkeiten auf. Sie entwickelt Integrationsmuster für Komponenten,
die wiederverwendbare Integrationstechniken für Software im Portalumfeld beschreiben. Das
Datenformatmodell stellt Datenformate für die interne Kommunikation dar und bewertet diese
hinsichtlich ihrer Eignung. Die Kommunikationsarchitektur stellt Methoden zur Adaption und
Transformation von ausgetauschten Daten bereit (Kapitel 9).
In den folgenden Abschnitten werden die Teilsichten bzw. Architekturen des Architekturmodells
ausgehend von den Prozessen dargestellt.
5 Prozessarchitektur für Portale
5.1 Übersicht und Eigenschaften
Die Aufgabe der Prozessarchitektur ist die Festlegung der erforderlichen Portalprozesse. Die
wesentlichen Eigenschaften, die eine Prozessarchitektur für Portale im Technischen Vertrieb erfüllen
muss, liegen in der Definition der durch den Kunden über das Portal ausführbaren Prozesse des
Technischen Vertriebs entlang des gesamten Vertriebsprozesses und der Zusammenfassung von
Prozessen. Die Zusammenfassung muss eine Abbildung der Prozesse auf Komponenten im Rahmen
des Komponentenmodells erlauben. Die Prozessarchitektur wird im Sinne des generischen Ansatzes
der Arbeit mit mittlerer Granularität im Kontext des Technischen Vertriebs erstellt.
5.2 Ableitung der vertriebsrelevanten Portalprozesse
Für die Erstellung der Prozessarchitektur ist eine systematische Übersicht über die relevanten
kundenbezogenen Prozesse erforderlich. Hierbei grenzt sich die Arbeit von detailliert ausgeprägten
Prozessmodellen für die unternehmensinterne Vertriebsabwicklung, wie z. B. [Scheer 1998a], ab.
Als Basis für diese Arbeit wurden die Prozesse für den Technischen Vertrieb in den Branchen
Elektrotechnik, Maschinen- und Anlagenbau und EDV im Rahmen einer Unternehmensbefragung
erhoben (vgl. [Gurzki und Özcan 2003]). Ergebnis dieser Untersuchung ist eine priorisierte Übersicht
der relevanten Prozesse für Branchen mit Technischem Vertrieb, die in Anhang D wiedergegeben ist.
Die Beschreibung der Prozesse ist gemeinsam mit weiteren Informationen zu den einzelnen Prozessen
in Anhang E dargestellt. Aus dieser Übersicht der Prozesse leitet sich im Folgenden die
Prozessarchitektur des Architekturmodells ab.
Die Prozessarchitektur für das Architekturmodell deckt den Vertriebsgesamtprozess nach [Brandstetter
und Fries 2002] von der Werbung bis zum After-Sales-Support ab. Die Zuordnung der Prozesse zu
Phasen stellt ein Unterscheidungskriterium dar und bildet somit die Grundlage für eine
Zusammenfassung der Prozesse. Bei der Zuordnung von Prozessen zu Phasen ist zu berücksichtigen,
dass einzelne Prozesse in verschiedenen Phasen des Vertriebsgesamtprozesses mehrfach auftreten
können. So ist z. B. die Bereitstellung technischer Produktinformationen in den Phasen Werbung,
Information und Beratung relevant. Die Relevanz von Prozessen kann für jede Zuordnung
unterschiedlich sein. Im Folgenden wird sie mit den Attributen „Schwerpunkt“ bzw. „Sekundär“
bewertet. Die abzubildenden Prozesse teilen sich darüber hinaus in Prozesse mit
maschinenunterstützter Kunde-Mitarbeiter-Interaktion sowie Prozesse mit Kunde-Maschine-
Interaktion auf (vgl. [Weisbecker und Otto 2002]). Prozesse mit Kunde-Maschine-Interaktion
bedürfen aus Sicht des portalbetreibenden Unternehmens keines manuellen Eingriffs während ihrer
Ausführung. Als Beispiel für einen automatisierbaren Prozess kann die Preisanfrage angeführt werden,
die durch eine Shop-Komponente beantwortet wird. Prozesse mit manueller Teilausführung erfordern
eine partielle Ausführung durch einen Sachbearbeiter im VID bzw. Kundendienst. Die manuelle
Bearbeitung erfolgt dabei maschinenunterstützt. Diese Prozesse besitzen Kommunikationscharakter.
Ein Beispiel für einen Prozess mit manueller Teilausführung ist eine textbasierte Anfrage an den
Service.
Als weiteres Zuordnungskriterium wird die Eigenschaft des unterstützenden Prozesses aufgenommen.
Unterstützende Prozesse sind nicht direkt einer Phase zuordenbar sondern stellen, wie z. B. die
Suchfunktion, einen vereinfachten Zugang zu den Prozessen der Phasen dar. Eine Zusammenfassung
55
schwerpunktmäßig übereinstimmender Prozesse wird Prozessbündel genannt. Diese werden mit
lateinischen Großbuchstaben bezeichnet. Gemeinsam mit der Art der Interaktion ergibt sich in der
Tabelle eine Gesamtübersicht über die Prozesse, die als Portalprozesslandkarte bezeichnet wird.
Tabelle 11 stellt die Prozessbündel dar, die aus der Zuordnung der Prozesse zu den Phasen des
Vertriebsprozesses, der Einordnung als unterstützender Prozess und der Interaktion des Prozesses
resultieren.
Phase
Vertriebsprozess
Inter-
aktion
Zuordnung
Prozess W
er
bu
ng
In
fo
rm
at
io
n
B
er
at
un
g
V
er
ka
uf
sa
bs
ch
lu
ss
A
fte
r
Sa
le
s S
up
po
rt
U
nt
er
st
üt
ze
nd
er
P
ro
ze
ss
K
un
de
-M
as
ch
in
e
K
un
de
-M
ita
rb
ei
te
r
R
es
ul
tie
re
nd
e
Z
uo
rd
nu
ng
zu
P
ro
ze
ss
bü
nd
el
Bereitstellung von technischer Information über Produkte ● ● ● ● A
Bereitstellung von Datenblättern ● ● ● ◐ ● A
Anzeige eines kundenindividuellen Produktkatalogs ● ● ● ● A
Bestellung von Zubehör ● ● ● ● A
Bereitstellung von technischen Zeichnungen ● ● ◐ ● A
Elektronische Bereitstellung von Produkten ● ● ● A
Kundenindividuelle Preisgestaltung ● ◐ ● A
Bestellvorgang durch Kunden/Transaktion ● ● B
Einsehen der eigenen Bestellhistorie/Auftragsstatus ● ● ● B
Preisanfrage/Angebotsanforderung ◐ ● ● B
Elektronische Auftrags- und Bestellbestätigung ● ● B
Elektronische Rechnung ● ● B
Verfügbarkeitsprüfung ● ● B
Vorlage für Bestellungen ● ● B
Konfiguration von Produkten ◐ ● ● ● C
Suche nach Produkten ◐ ◐ ◐ ● ● D
Suche nach Inhalten ◐ ◐ ◐ ● ● D
Applikationsbeschreibungen, Anleitungen, Handbücher ◐ ● ● ● E
Produktvergleich/Beratung bei Produktwahl ● ◐ ● E
Kommunikation mit Technischem Kundendienst/Support ◐ ◐ ● ● F
Reklamation ● ● F
Rückfrage zu Bestellungen ● ● ● F
Allgemeine Unternehmensinformation ● ● G
Führen von gemeinsamen Projektbüchern ● ● ● ● ● H
Legende: Zuordnung ● Schwerpunkt, ◐ Sekundär; A..H Bezeichnung der Prozessbündel.
Tabelle 11: Prozessarchitektur in Form der Portalprozesslandkarte
56
Die aus Tabelle 11 resultierenden Prozessbündel weisen verschiedene Schwerpunkte in den dort
dargestellten Phasen auf. Tabelle 12 stellt die Prozessbündel mit den Phasenschwerpunkten, der Art
der Interaktion und einer Beschreibung der thematischen Orientierung dar. In einem weiteren Schritt
erhalten dort die Prozessbündel über die Identifizierung mit Buchstaben hinaus eine Bezeichnung für
die weitere Verwendung bei der Abbildung auf Komponenten des Komponentenmodells im Rahmen
der Prozess- und Anwendungsarchitektur.
Prozess-
Bündel
Bezeichnung Phasenschwerpunkt Interaktion Thematische Orientierung
A Produktbezogene
Informationsprozesse
Werbung,
Information, Beratung
Kunde-
Maschine
Bereitstellung von
Produktinformationen
B Transaktionsbezogene
Prozesse
Verkaufsabschluss Kunde-
Maschine
Vorbereitung und
Durchführung von
Transaktionen sowie
Verarbeitung von Daten
durchgeführter Transaktionen
C Konfigurationsprozesse Beratung,
Verkaufsabschluss
Kunde-
Maschine
Beitrag zur Konfiguration von
Produkten
D Suchprozesse Unterstützende
Prozesse für Werbung,
Information, Beratung
Kunde-
Maschine
Bereitstellung von
Suchfunktionalität in den
Datenbeständen einzelner
oder aller Bereiche des
Portals
E Auswahl- und
serviceunterstützende
Prozesse
Beratung, After Sales
Support
Kunde-
Maschine
Unterstützung der Auswahl
von Produkten mit
Informationen, die nicht in
den Produktdaten enthalten
sind, und Bereitstellung von
Serviceinformationen
F Kommunikations-
prozesse
After Sales Support Kunde-
Mitarbeiter
Unterstützung der
Kommunikation zwischen
Kunden und Unternehmen,
die nicht über ein anderes
Bündel strukturiert
abwickelbar ist
G Allgemeine
unternehmensbezogene
Informationsprozesse
Information Kunde-
Maschine
Bereitstellung von
Informationen ohne
Produktbezug
H Kooperative projekt-
bezogene Prozesse
Information,
Beratung,
Verkaufsabschluss,
After Sales Service
Kunde-
Mitarbeiter
Unterstützung definierter
projektbezogener Kooperation
zwischen Unternehmen
Tabelle 12: Übersicht der Prozessbündel
6 Anwendungsarchitektur für Portale
6.1 Übersicht und Eigenschaften
Die Anwendungsarchitektur beschreibt den strukturellen softwaretechnischen Aufbau des
Architekturmodells. Zu den Eigenschaften einer portalspezifischen Anwendungsarchitektur gehört die
Vorgabe einer Struktur für das gesamte Portal mit den zu integrierenden Systemen und die
Berücksichtigung der überschneidenden Funktionalitäten der Systeme des Technischen Vertriebs.
Hierbei ist insbesondere die Funktion der Systeme im Kontext des Portals festzulegen.
Zur Entwicklung der Anwendungsarchitektur wird zunächst der Komponentenansatz auf
Portalarchitekturen übertragen. Davon ausgehend werden Abstraktionskriterien für ein
Schichtenmodell erarbeitet und das Modell abgeleitet. Im Anschluss werden in einer
Komponentenarchitektur die Komponenten des Architekturmodells definiert und ihre Funktionalität
bestimmt. Hierbei wird entsprechend des Aufbaus der Schichtung vorgegangen.
6.2 Definition abstrakter Komponenten
Die Untersuchung der typischen Bestandssysteme in Unternehmen in Kapitel 3.4 zeigt bei den in einer
Portalarchitektur zu berücksichtigenden Systemen zum Teil große funktionale Überschneidungen, die
eine verallgemeinerte systemorientierte Architekturgestaltung nicht zulassen. Die Problematik lässt
sich am Beispiel der Funktion Katalogmanagement aufzeigen: Diese Funktion ist Bestandteil
konkreter Produkte im Bereich ERP-Systeme, CRM-Systeme und Katalogdatenmanagementsysteme
wie z. B. SAP R/3, Siebel und jCatalog. Infolge dieser funktionalen Überschneidungen sind bei einer
systemorientierten Modellierung eines Architekturmodells Abbildungen von Systemen in der
Architektur auf reale Systeme nicht eineindeutig. Darüber hinaus ist eine Einbindung konfigurierbarer
Softwarekomponenten ohne definierten Systemcharakter, die zunehmend als Bestandteil von
Application-Servern oder als Einzelprodukt ausgeliefert werden, ebenfalls zu berücksichtigen. Aus
diesem Grund identifiziert die Anwendungsarchitektur des Architekturmodells für Portale abstrakte
Komponenten als kleinste abgrenzbare Teile. Diese werden im Rahmen einer Instanzbildung für ein
Portal durch das Infrastrukturmodell auf bestehende Systeme abgebildet (vgl. Kapitel 8.6). Die
abstrakten Komponenten verfügen analog der Komponentendefinition über Schnittstellen für den
Zugriff auf ihre Dienste und sind unabhängig verwendbar (vgl. [Weisbecker 2002]). Die
Komponenteneigenschaften werden damit auf die Verwendung in verschiedenen Kontexten und auf
das Vorhandensein von Schnittstellen reduziert. Zu den Schnittstellentypen im Sinne dieser Definition
gehören neben einer API u. a. explizit auch visuelle Benutzungsschnittstellen. Die Architektur des
Gesamtsystems kann auf der Basis von Komponenten beschrieben werden (vgl. [Balzert 2000]). Die
Menge der abstrakten Komponenten setzt sich im Portalkontext aus den folgenden Teilmengen
zusammen:
− Softwarekomponenten: Komponenten im Sinne eines Komponentenmodells, wie z. B. J2EE,
COM.
− Betriebliche Informationssysteme: Anwendungen, welche betriebliche Kernprozesse abbilden.
− Abgrenzbare Teilfunktionen eines betrieblichen Informationssystems: Teilfunktionen eines
Informationssystems, die mit einem in sich abgeschlossenen Funktionsrahmen als ein System
angesehen werden können, wie z B. die Materialwirtschaft eines ERP-Systems.
58
Die Komponenten verfügen über eine abgrenzbare Funktionalität, die im Komponentenmodell
dargestellt wird.
6.3 Schichtenmodell für Portale
Zur Strukturierung komplexer Softwarearchitekturen, die aus einer großen Anzahl von Komponenten
bestehen, ist eine Schichtenarchitektur notwendig [Balzert 2000]. Ihre Erstellung erfordert im ersten
Schritt die Definition von Abstraktionskriterien für die Bildung der Schichten. In einem zweiten
Schritt werden in diesem Abschnitt aus den Kriterien Portalkomponentenklassen abgeleitet und das
allgemeine Schichtenmodell erstellt.
6.3.1 Definition der Abstraktionskriterien
Die in diesem Architekturmodell definierten abstrakten Softwarekomponenten können entsprechend
des erweiterten Komponentenbegriffs als Softwareanwendung selbst nach einem Schichtenmodell, wie
z. B. ein 3-Schicht-Modell, aufgebaut sein. Die für die Portalarchitektur zu erstellende Schichtung
abstrahiert die interne Architektur der Komponenten im Sinne des Komponentengedankens und bildet
eine Metastruktur über der Menge der verwendeten Komponenten.
Der Ansatz des Schichtenmodells gestattet es, die Komponenten in funktionale Ebenen einzuteilen,
um sie unter Berücksichtigung der Erfordernisse des Datenflusses und der funktionalen Abhängigkeit
über Systemgrenzen hinweg logisch zu gruppieren. Zielsetzung ist die Erstellung eines
Schichtenmodells mit strikter Ordnung. Für die durchgängige Definition der Schichtung werden im
Kontext der Portalerstellung die folgenden Abstraktionskriterien definiert:
− Kriterium 1: Funktionale Abhängigkeit: Eine funktionale Abhängigkeit zwischen zwei
Komponenten A und B besteht, wenn zur Funktion der Komponente A die Funktionalität der
Komponente B benötigt wird. In diesem Fall ist die Komponente A in der gleichen oder einer
höheren Schicht als die Komponente B einzuordnen.
− Kriterium 2: Abstraktionsniveau: Das Abstraktionsniveau wird aus Sicht der Interaktion des
Kunden mit den Komponenten definiert. Hierfür ergeben sich drei Merkmalsklassen:
o Klasse I: Nutzung ausschließlich für den Portalbetrieb; direkte Kundeninteraktion.
o Klasse II: Nutzung ausschließlich für den Portalbetrieb; keine oder ggf. eine indirekte
Kundeninteraktion über die Belieferung einer anderen Komponente mit Daten.
o Klasse III: Ausführung von Kernprozessen des Unternehmens; keine oder ggf. eine
indirekte Kundeninteraktion über die Belieferung einer anderen Komponente mit Daten;
Nutzung von Teilfunktionalitäten für den Betrieb des Portals.
Jede Komponente ist einer Merkmalklasse zugeordnet. Komponenten gleicher Merkmalklassen sind in
die gleiche Schicht einzuordnen.
Kriterium 1 stellt dabei allein kein hinreichendes Abstraktionskriterium dar, da es lediglich eine
„benutzt“-Relation fordert (vgl. [Balzert 2000]). In Verbindung mit Kriterium 2 wird eine eindeutige
Schichtenbildung mit drei Metaschichten erreicht.
6.3.2 Ableitung des Schichtenmodells
Die definierten Kriterien ergeben ein Schichtenmodell mit strikter Ordnung für die
Systemkomponenten. Es gliedert sich in die drei Ebenen Portalanwendungskomponenten (Klasse I),
59
Portalsystemkomponenten (Klasse II) und Betriebliche Informationskomponenten (Klasse III).
Zwischen den Komponenten der einzelnen Schichten, wie auch zwischen den Komponenten einer
Schicht, befinden sich Schnittstellen. Die Kommunikation wird im Rahmen der
Kommunikationsarchitektur (vgl. Kapitel 6.4) eingehender betrachtet. Abbildung 14 zeigt das
Schichtenmodell des Architekturmodells.
Betriebliche
Informations-
komponenten
Kundenorientierte Anwendungen
Portal-
anwendungs-
komponenten
Portal-
system-
komponenten
Betriebliche Anwendungen
Portal-
anwendungs-
komponente
Portal-
anwendungs-
komponente
Portal-
anwendungs-
komponente
Portalsystem-
komponente
Portalsystem-
komponente
Portalsystem-
komponente
Betriebliche
Informations-
komponente
Betriebliche
Informations-
komponente
Betriebliche
Informations-
komponente
Po
rt
al
ar
ch
ite
kt
ur
Po
rt
al
ar
ch
ite
kt
ur
Abbildung 14: Schichtenmodell des Architekturmodells
Die einzelnen Schichten besitzen folgende Aufgaben:
− Schicht Portalanwendungskomponenten (PAK): Die Komponenten dieser Schicht sind für den
Benutzer sichtbare Anwendungen, die über eine Benutzungsschnittstelle bedient werden können.
Diese Benutzungsschnittstelle in Form einer PVK (siehe Kapitel 3.6) ist Bestandteil der PAK. Die
Wiederverwendbarkeit in den Kontexten verschiedener Portalseiten ist durch den
Komponentencharakter gewährleistet. Die Anwendungen werden auf Basis von enthaltener
Anwendungslogik und der Funktionalität von Komponenten aus den niedrigeren Schichten
realisiert.
− Schicht Portalsystemkomponenten (PSK): Die Komponenten in der Schicht PSK stellen
Funktionen für die Nutzung durch eine oder mehrere Portalanwendungs- oder
Portalsystemkomponenten bereit. Im Gegensatz zur Schicht Betriebliche
Informationskomponenten werden Portalsystemkomponenten ausschließlich für den Betrieb des
Portals eingesetzt. Die PSK können über die Einbettung in eine PAK indirekt von außen
zugänglich sein.
− Schicht Betriebliche Informationskomponenten (BIK): Die Komponenten in dieser Schicht
führen für das Unternehmen betriebsrelevante Kernprozesse aus. Bei Bedarf stellen sie Teile ihrer
Funktionalität kontextbezogen für die Funktionen des Portals bereit. Dies sind Funktionen zum
Einschleusen von Daten und Informationen in die unternehmerischen Kernprozesse bzw. in der
Umkehrung das Ausschleusen von Daten und Informationen. Für Portalnutzer sind die BIK im
Zusammenhang mit dem Portal nicht unmittelbar von außen zugänglich. Der Zugriff erfolgt
60
ausschließlich mittelbar über Komponenten der beiden höheren Schichten. Komponenten dieser
Schicht sind in der Regel eigenständige Einzelsysteme.
Das Schichtenmodell (siehe Abbildung 14) weist die Eigenschaft einer von unten nach oben
zunehmenden Prozessintegration und Informationsaggregation auf. Komponenten realisieren die
eigenen Prozesse autark bzw. auf Basis der Prozesse und Daten der darunter liegenden Schichten und
nebengeordneten Systemkomponenten. Hierdurch ergibt sich eine entlang der Schichten aufwärts
steigende Prozessintegration durch das Schichtenmodell. Analog werden durch Systemkomponenten
Daten der unteren Schichten bzw. nebengeordneter Systemkomponenten aggregiert.
Die Kernprozesse des Vertriebs und die damit verbundenen Daten verbleiben in dem gewählten
Ansatz in den BIK. Sie werden lediglich durch die höheren Schichten für den Einsatz im Portal
erweitert. Dies gewährleistet bei einem Einsatz des Portals als Kanal im Rahmen eines Multichannel-
Marketings gemäß [Bachem 2004] die Verfügbarkeit der wesentlichen kundenbezogenen
Informationen für alle Kanäle.
6.3.3 Schichtenmodell im Kontext von Portalsoftware
Beim Einsatz von Portalsoftware können die Schichten des Architekturmodells auf verschiedene Arten
auf die Softwarebestandteile abgebildet werden. Die Schicht der BIK existiert unabhängig vom Portal
und befindet sich damit außerhalb der Portalsoftware. Die Komponenten in der Schicht PAK werden
in der Portalsoftware ausgeführt, da sie direkt mit den PVK assoziiert sind.
Die Schicht PSK kann sowohl innerhalb der Portalsoftware als auch außerhalb durch eigenständige
Anwendungen ausgeführt werden. Portalsoftwareprodukte verwenden als Ausführungsumgebung
einen Application-Server [Gurzki und Hinderer 2003]. Hierdurch ist eine Realisierung von PSK im
Rahmen des Komponentenmodells des Application-Servers möglich. Daraus ergeben sich für die
Abbildung des Schichtenmodells auf Portalsoftware drei mögliche Szenarien:
− Szenario A – Verwendung eigenständiger Systeme für Portalsystemkomponenten: Werden
die PAK in einer Portalsoftware ausgeführt, sind die Komponenten in der Schicht PSK
ausschließlich eigenständige Softwaresysteme.
− Szenario B – Verwendung von Portalsystemkomponenten in einem Application-Server:
Werden die Komponenten beider Schichten in einem Application-Server einer Portalsoftware
ausgeführt, so entsprechen sie den Komponenten des zugrunde liegenden Komponentenmodells.
− Szenario C – Mischform: In diesem Fall werden einige PSK gemäß Szenario A durch
eigenständige Systeme sowie weitere nach Szenario B abgebildet. Die weiteren PSK werden in
einem Application-Server einer Portalsoftware ausgeführt.
Damit wird eine mittlere bis grobe Granularität der Komponenten ermöglicht. Abbildung 15 stellt die
Szenarien für den Kontext der Portalsoftware dar. Die Abbildung von Komponenten auf Systeme wird
eingehend in Kapitel 8.6 betrachtet. Die von den Komponenten in den einzelnen Schichten
bereitgestellten Funktionen werden in der Komponentenarchitektur im Folgenden weiter detailliert.
61
Abbildung 15: Schichtenmodell im Kontext von Portalsoftware
6.4 Komponentenarchitektur für Portale
6.4.1 Identifikation der Komponenten
Für die Identifikation der Komponenten im Architekturmodell werden zwei bis fünf Buchstaben
enthaltende, abkürzende Signaturen eingeführt. Diese können zur Beschreibung von Funktionen bzw.
Datenobjekten der jeweiligen Komponenten durch ein Anhängen der Funktionsnummer (-Fx) bzw.
Datenobjektnummer (-Dy) ergänzt werden, wobei x,y ganzzahlige fortlaufende Nummern darstellen.
6.4.2 Komponenten der Schicht Portalanwendungskomponenten (PAK)
Die Komponenten der Schicht PAK interagieren direkt mit den Portalnutzern. Sie realisieren
Anwendungen und damit verbundene Portalprozesse, die der Kunde nutzen kann. Im Folgenden wird
zunächst der softwaretechnische Aufbau von PAK betrachtet. Im Anschluss hieran wird die
Funktionalität der einzelnen Komponenten definiert.
6.4.2.1 Softwaretechnischer Aufbau
PAK werden in der Portalsoftware ausgeführt. Sie sind vollständige Anwendungen, die über eine
eigene Präsentation, Geschäftslogik und einen Datenbestand verfügen. Zusätzlich stellen sie eine
Integrationsfunktionalität bereit. Für die Einbindung in ein Portal verfügen sie über eine definierte
Schnittstelle, die von der Portalsoftware angesprochen werden kann. Über diese Schnittstelle werden
Ereignisse von der Portalsoftware, wie z. B. Benutzereingaben, entgegengenommen und die
Darstellung der Ausgabe übergeben (siehe Kapitel 8.2.1). Der Einsatz in einer personalisierbaren
Umgebung und die Wiederverwendbarkeit als Komponente erfordern eine Konfigurierbarkeit. Für die
Erfüllung dieser Anforderungen bietet sich eine portalspezifische Erweiterung des Model-View-
62
Controller-Schemas (MVC-Schema) zur Beschreibung von PAK an. Ein klassisches MVC-Schema
teilt sich in die folgenden Elemente auf: Der Controller ist für das Verhalten der Gesamtanwendung,
die Navigationserzeugung und die Umwandlung von Ereignissen, wie z. B. eine Benutzereingabe in
fachliche Operationen, verantwortlich. Die fachlichen Operationen sind in einem Model hinterlegt.
Dieses hält den Anwendungszustand und die Daten der Anwendung. Die Darstellung des Models
erfolgt durch Views, welche die Ergebnisse der fachlichen Operationen in geeigneter Weise darstellen.
Die Selektion der auszuführenden View erfolgt dabei durch den Controller. Dieser bestimmt damit
Statusänderungen im Model [Starke 2002]. Abbildung 16 (a) zeigt das Zusammenspiel der einzelnen
Elemente in einem MVC-Schema. Das MVC-Schema gestattet die Entkopplung von Model und View
(vgl. [Gamma et al 1995]) und ist damit für die Trennung der Darstellung einer PAK von den
Komponenten der anderen Schichten im besonderen Maße geeignet. In der Erweiterung des MVC-
Schemas werden den einzelnen Elementen portalspezifische Softwarebestandteile zugeordnet
(Abbildung 16 (b)). Der Controller wird durch eine PVK realisiert. Die PAK verfügen über einen
Event-Mechanismus, der eine Kommunikation zwischen zwei oder mehreren PVK sowie zwischen
Portalumgebung und den PVK ermöglicht. Für verschiedene Anwendungskontexte erfolgt die
Konfiguration der PAK über die Schnittstelle PVK-Portalsoftware. Die PVK bestimmt als Controller
mittels der Konfiguration den Grundzustand der PAK. Sie bestimmt den Status des Models und die
jeweils zu aktivierende View. Die View ist eine Menge von präsentationserzeugenden Elementen
(z. B. ASP-, JSP-Seiten, Servlets).
(a) (b)
Abbildung 16: Model-View-Controller-Schema im Kontext des Portals: (a) klassisches MVC nach [Starke
2002], (b) erweitertes Portal-MVC
Abweichend vom klassischen MVC-Schema ist bei webbasierten Architekturen keine autonome
Mitteilung einer Statusänderung des Models an die View möglich. Die View muss das Model aktiv auf
63
eine Änderung hin abfragen. Das Model kann im Rahmen der Erweiterung des MVC-Schemas zwei
Ausprägungen aufweisen:
− Internes Model: Das interne Model entspricht dem Model der klassischen MVC-Architektur. In
diesem Fall besteht die PAK aus einer abgeschlossenen Anwendung, die nicht auf externe
Komponenten zugreift.
− Externes Model: Das externe Model erweitert die klassische Sichtweise um die Funktion der
Integration von Komponenten. Es umfasst Integrationsmuster für die Integration von
Komponenten, welche Datenstrukturen, Dokumente oder eine Präsentation bereitstellen (visuelle
Integration).
In beiden Fällen werden die gelieferten Daten als das zu verarbeitende Model interpretiert und durch
den Controller einer View zur Präsentation zugeleitet. Vor der Verarbeitung kann bei Erfordernis eine
Transformation oder Adaption der Daten in die Darstellung des internen Models erfolgen (vgl.
Kapitel 9.6). Das nahe liegende Modell einer Kaskadierung von Controllern [Starke 2002] ist im
Portalzusammenhang wegen fehlender Unterstützung durch die Portalsoftware und der heterogenen
Architektur der zu integrierenden Komponenten nicht möglich. Durch die Spezialisierung auf den
Aspekt der Integration sind die PAK für den jeweiligen Anwendungsfall individuell zu entwickeln.
6.4.2.2 Darstellung von PAK auf Portalseiten
Im Portal erfolgt die Darstellung von PVK auf untereinander verlinkten Portalseiten. Eine PAK kann
dabei mehrere PVK umfassen, die verschiedene Views der PAK repräsentieren. Die Konfiguration der
PVK als Controller eines Portal-MVC-Schemas selektiert die notwendige Funktionsmenge der PAK
über Views. Auf diese Weise können verschiedene Funktionen einer PAK in mehreren, verschieden
konfigurierten Darstellungen einer PVK auf einer Portalseite genutzt werden. Dies bietet den Vorteil,
den notwendigen Code für zusammenhängende Funktionsbereiche bzw. Prozessbündel in einer PAK
anzulegen und die Einzelfunktionen unter Verwendung einer gemeinsamen Codebasis als
verschiedene PVK ausprägen zu können. Abbildung 17 zeigt die Mehrfachverwendung der PAK 1 mit
den PVK A und B.
Abbildung 17: Darstellung von PAK mit verschiedenen PVK
64
Als Beispiel für die Funktionsselektion kann eine PAK angeführt werden, die einen Katalog und einen
Warenkorb implementiert. Auf einer Portalseite können zwei PVK der PAK existieren, die zum einen
als Controller die Menge der Warenkorb-Views und zum anderen die Menge der Katalog-Views
selektieren.
6.4.2.3 Ableitung der Portalanwendungskomponenten
Eine wesentliche Aufgabe bei der Erstellung einer Portalarchitektur ist die Konzeption der
Portalanwendungen. Dies geschieht bisher durch die unternehmensspezifische Erfassung der
erforderlichen Portalprozesse und deren individuelle Abbildung auf Portalanwendungen. Die
vorliegende Arbeit verkürzt diesen Schritt durch die folgende Methode:
1. Ableitung der PAK aus Prozessbündeln: Die in Kapitel 5 gebildeten Prozessbündel enthalten
verwandte Prozesse, die aus softwaretechnischer Sicht eine gleiche Codebasis nutzen. Aus den
Prozessbündeln werden mit den aufgeführten Prozessen die PAK Katalog, Transaktion,
Konfiguration, Suche, Produktwahlunterstützung und Beratung, Kommunikation,
Unternehmensinformation und Kooperation gebildet.
2. Definition der Bedeutung der Prozesse für ein Portal: Die einzelnen Prozesse weisen in ihrer
Bedeutung für die Realisierung des Vertriebsprozesses eine unterschiedliche Wichtigkeit auf.
Muss-Prozesse bilden die Grundlage für die Abbildung des gesamten Vertriebsprozesses. Kann-
Prozesse sind diesbezüglich optional.
3. Ableitung der Realisierung der Prozesse: Die Realisierung der Prozesse erfolgt mit Hilfe der
Funktionen der Systeme des Technischen Vertriebs, die an dieser Stelle entsprechend des in
Kapitel 6.2 gewählten Ansatzes durch abstrakte Komponenten vertreten werden. Die Prozesse für
die benötigten Funktionen leiten sich aus der in der Prozessübersicht geforderten Funktionalität
(vgl. Anhang E) ab. Die Funktionen werden durch Komponenten der Schichten PSK und BIK
bereitgestellt.
Tabelle 13 stellt mit der Portalanwendungslandkarte eine Übersicht der PAK dar, die aus den
Prozessbündeln gebildet wurden. Die Prozesse werden in der Tabelle als Muss- bzw. Kann-Prozesse
klassifiziert und die vom Prozess verwendeten Funktionen von Komponenten der Schichten PSK und
BIK werden in der in Kapitel 6.4.1 festgelegten Form zugeordnet. Die Einzelprozesse einer PAK
können entsprechend Kapitel 6.4.2.2 in einer einzelnen PVK pro Prozess oder zusammengefasst mit
zwei oder mehreren Prozessen der gleichen PAK angezeigt werden.
Zu den in der Portalanwendungslandkarte definierten Prozessen der PAK werden die zur Realisierung
erforderlichen Komponenten und Funktionen in den Kapiteln 6.4.3 und 6.4.4. identifiziert. Eine
Übersichtsdarstellung der PAK, PSK und BIK sowie deren funktionale Abhängigkeit erfolgt im
Rahmen der Kommunikationsarchitektur in Kapitel 9 in Abbildung 27.
65
Prozess PAK
Signatur
Abbildung Prozesse
Muss Kann
Realisierung mit
Funktionen
KAT Katalog Prozesse des Prozessbündels A
Katalog/Bereitstellung von technischer
Information über Produkte ● ○
SHOP-F1, -F4, CM-F4,
-F5, -F6, -F7, -F10
Kundenindividuelle Preisgestaltung ○ ● SHOP-F3, -F2
Bereitstellung von Datenblättern ● ○ CM-F2
Anzeige eines kundenindividuellen
Produktkatalogs ○ ●
SHOP-F2, CM-F4, -F5,
-F6, -F7, -F10
Bestellung von Zubehör ○ ● SHOP-F2, CM-F4, -F5,
-F6, -F7, -F10
Bereitstellung von technischen Zeichnungen ○ ● CM-F3
TRANS Transaktion Prozesse des Prozessbündels B
Bestellvorgang durch Kunden/Transaktion ● ○ SHOP-F7
Einsehen der eigenen
Bestellhistorie/Auftragsstatus
○ ● CRK-F7
Preisanfrage/Angebotsanforderung ● ○ SHOP-F8
Elektronische Auftragsbestätigung,
Bestellbestätigung (gesetzl. vorgeschrieben)
● ○ ERP (intern), SHOP
(intern)
Verfügbarkeitsprüfung ○ ● SHOP-F6
Vorlage für Bestellungen ○ ● SHOP-F9
Bereitstellung Warenkorb ● ○ SHOP-F4, -F5
Elektronische Rechnung ○ ● CRK-F9
Elektronische Bereitstellung von Produkten ○ ● SHOP-F10
KNF Konfiguration Prozesse des Prozessbündels C
Konfiguration von Produkten ○ ● KONF-F1, -F2
SUCHE Suche Prozesse des Prozessbündels D
Suche nach Produkten ● ○ KAT
Suche nach Inhalten 1 ○ ● PWB, UINF
PWB Produktwahlunterstützung und Beratung Prozesse des Prozessbündels E
Applikationsbeschreibungen, Anleitungen,
Handbücher, redaktionelle Artikel
● ○ CM-F8, CM-F9
Produktvergleich/Beratung bei Produktwahl ○ ● BER-F1, -F2
KOMM Kommunikation Prozesse des Prozessbündels F
Kommunikation mit Technischem
Kundendienst/Support
● ○ WFM-F1, -F2, CMK-F1,
-F2
Reklamation ○ ● WFM-F1, -F2
Rückfrage zu Bestellungen ○ ● WFM-F1, -F2
UINF Unternehmensinformation Prozesse des Prozessbündels G
Allgemeine Unternehmensinformation ● ○ CM-F1
KOOP Kooperation Prozesse des Prozessbündels H
Führen von gemeinsamen Projektbüchern ● ○ GPW-F1, -F2, -F3
Legende: Anforderung ● Bestandteil, ○ kein Bestandteil; 1 ergibt sich aus Prozessen d. PAK PWB und UINF.
Tabelle 13: Portalanwendungslandkarte
66
6.4.3 Komponenten in der Schicht Portalsystemkomponenten (PSK)
Die Komponenten der Schicht Portalsystemkomponenten (PSK) stellen Funktionen für die
Realisierung der PAK bereit. Sie sind damit für die Nutzer des Portals nicht direkt sichtbar. Die
Bereitstellung der Funktionalität durch PSK kann durch zwei grundlegend verschiedene Ansätze
erfolgen:
− Bereitstellung von Schnittstellen für eine Datenintegration.
− Integration auf Präsentationsebene (visuelle Integration) über die Einbindung einer durch die PSK
erzeugten Präsentation bzw. von Teilen hiervon.
Im Folgenden wird zunächst der softwaretechnische Aufbau der PSK betrachtet. Im Anschluss wird
die für den Portalaufbau erforderliche Funktionalität der einzelnen PSK definiert, die von den PAK
der höheren Schichten oder von nebengeordneten PSK verwendet werden. In Anhang F werden
Funktionskarten für die einzelnen PSK aufgeführt. Die Funktionskarten umfassen auch die von den
Funktionen konsumierten und erzeugten Informationen in Form von Informationsklassen.
6.4.3.1 Softwaretechnischer Aufbau
In Kapitel 6.2 wurden verschiedene mögliche Formen der abstrakten Komponenten beschrieben. Die
beiden Verfahren zur Bereitstellung der Funktionalität spiegeln die möglichen Ausprägungen der PSK
wieder. PSK können die folgenden Softwaretypen abstrahieren (vgl. auch Kapitel 6.3.3):
− Softwarekomponente eines Komponentenmodells: Die Funktion der vorgefertigten
Komponente kann über ihre definierten Schnittstellen genutzt und ggf. durch ihre Konfiguration
beeinflusst werden. Softwarekomponenten sind insbesondere als Produkte für Application-Server
erhältlich.
− Eigenständige Softwareanwendung: Die Softwareanwendung verfügt über eine eigene
Präsentation, Geschäftslogik und einen Datenbestand. Eigenständige Anwendungen sind im
Einzelfall nicht für die Integration in Portalumgebungen vorgesehen und weisen aus diesem Grund
keine unmittelbar nutzbare Schnittstelle auf. In diesem Fall kann eine Integration auf der Ebene
der Präsentationsschicht in Frage kommen.
Die Unterschiede im softwaretechnischen Aufbau bedingen verschiedene Ansätze zur Integration, die
in Kapitel 9.3 ausführlich dargestellt sind. Auf die Beschreibung der portalrelevanten Funktionalität
der PSK haben diese Unterschiede jedoch keinen Einfluss. Die Komponenten haben in einer Portal-
architektur eine andere Funktion als in einem allein stehenden System bzw. als Komponente. Die
Menge der in den Systemen enthaltenen Funktionen stellt im Regelfall ein Subset der erforderlichen
Funktionen der PSK dar und muss aus diesem Grund für das Architekturmodell definiert werden.
6.4.3.2 Shop-Komponente (SHOP)
Allgemeine Funktion und Aufbau
Shop-Komponenten sind in der Praxis als eigenständige Softwaresysteme (z. B. Intershop Enfinity,
OpenShop) sowie als Komponenten für Komponentenmodelle erhältlich. Zu den Kernfunktionen von
Shop-Komponenten gehören die Bereitstellung eines Kataloges mit Produktdaten, das Waren-
korbmanagement, die Abwicklung der Kundenregistrierung und verschiedener Zahlungsverfahren
[KPMG 2000]. Weitere Funktionen sind die Produktsuche und bei einzelnen Systemen auch die
Verwaltung von redaktionellen Inhalten in einem Content-Management-Subsystem. Shop-
67
Komponenten bestehen primär aus einer oder mehreren Datenbanken, einem Präsentationssystem und
Verwaltungswerkzeugen. Die Datenbanken enthalten die relevanten Daten, wie z. B. Produktdaten,
Kundendaten und Bestellungen. Das Präsentationssystem enthält die Shop-Logik und dient zur
Anzeige der hinterlegten Informationen (vgl. [Merz 2002], [Intershop 1999]). Shop-Komponenten
basieren auf den in Kapitel 3.5 vorgestellten Technologien für webbasierte Anwendungen. In nahezu
allen Shop-Komponenten ist die Trennung von Layout und Logik vollzogen, so dass in den Templates
jeweils nur Funktionsaufrufe Shop-interner Komponenten enthalten sind. Durch Vorlagen (Templates)
lässt sich die Präsentation eines Shops anpassen.
Funktion im Architekturmodell
Die SHOP-Komponente bildet die Katalogfunktionalität des Portals ab. Sie hält alle notwendigen
Daten in einem Katalog-Repository. Die Transaktion wird durch die Bereitstellung der
Warenkorbfunktion und die Erzeugung einer Bestellung unterstützt. Eine komponentenindividuell
vorhandene Content-Management-Funktionalität wird im Komponentenmodell nicht gesondert
behandelt. Genügt die Funktionalität den Anforderungen gemäß der CM-Komponente (vgl. Kapitel
6.4.3.4), so ist sie dieser gleichzusetzen. Andernfalls ist eine dritte Komponente zu verwenden. Die
SHOP-Komponente verfügt über eine Authentifizierung, um den Nutzer identifizieren zu können.
Diese ist notwendig, um Transaktionen zuzuordnen und den Katalog kundenspezifisch entsprechend
seines Profils anzubieten. Die von der SHOP-Komponente abzubildenden Funktionen sind im
Einzelnen:
Darstellung Standardkatalog (SHOP-F1): Die SHOP-Komponente erzeugt eine visuelle Darstellung
des Standardkatalogs für das Portal. Der Katalog erfüllt dabei die Funktion der Bereitstellung der
grundlegenden technischen Informationen und des Standardpreises bzw. fester Preisstaffeln zu
Artikeln. Die Darstellung der Artikelklassen bzw. der einzelnen Artikel im Katalog muss von anderen
Portalanwendungen aus referenzierbar sein.
Darstellung kundenindividueller Katalog (SHOP-F2): Aus den Anforderungen der Internationali-
sierung und Personalisierung, sowie den damit einhergehenden kunden- bzw. zielgruppenindividuellen
Katalogen, ist eine entsprechende Multikatalogfähigkeit des Shops abzuleiten. Die Kataloge sind
jeweils einer Kundengruppe, einer Sprachregion und/oder einer Vertriebszielgruppe zugeordnet. Die
Darstellung der Artikelklassen bzw. der einzelnen Artikel in dem für den Kunden selektierten Katalog
muss von anderen Portalanwendungen aus referenzierbar sein.
Kundenindividuelle Preisgestaltung (SHOP-F3): Während Standardpreise im Katalog hinterlegt
sind, werden individuelle Preise produkt- und mengenbezogen durch eine Anfrage an die Customer-
Relationship-Management-Komponente (CRK) ermittelt. Alternativ können Informationen über
mengenbezogene Preise im Katalog hinterlegt werden. Kundenindividuelle Preise können in Form von
kundenindividuellen Katalogen hinterlegt werden. Die Funktion bildet den Vorgang der Preisanfrage
ab.
Warenkorb aus Katalog und externer Anwendung füllen (SHOP-F4): Der Warenkorb wird für das
gesamte Portal von der SHOP-Komponente bereitgestellt. Die Warenkorbfunktionalität umfasst das
Hinzufügen von Artikeln zum Warenkorb, das Löschen von Artikeln und die Änderung von Mengen.
Analog zu der Anzeige von Produkten muss der Warenkorb durch Portalanwendungen mit Produkten
68
befüllbar sein. Er muss mit außerhalb der SHOP-Komponente konfigurierten Produkten über die
Übernahme einer Stückliste oder einer Referenznummer der Konfiguration gefüllt werden können.
Warenkorb verwalten (SHOP-F5): Die SHOP-Komponente stellt eine Darstellung für die
Verwaltung des Warenkorbs bereit. Hierzu gehören das Verändern der Mengen, das Löschen von
Artikeln und das Auslösen der Transaktion bzw. Angebotsanforderung.
Verfügbarkeitsprüfung (SHOP-F6): Die SHOP-Komponente ermöglicht es dem Kunden, die
Verfügbarkeit von Artikeln anzuzeigen. Dies kann über eine Prüfung gegen die Enterprise-Resource-
Planning-Komponente (ERK) durchgeführt werden, welche die Verfügbarkeit liefert. Alternativ ist die
Verfügbarkeitsaussage auf Basis von im Katalog hinterlegten Informationen möglich. Der
Aktualitätsgrad der Information hängt hierbei von der Vorhersagbarkeit des Verlaufs des
Lagerbestands und der Aktualisierungshäufigkeit des Kataloges ab.
Transaktion/Bestellung (SHOP-F7): Die Transaktion umfasst alle Funktionen, die zur Umwandlung
eines Warenkorbes in eine gebuchte Bestellung notwendig sind. Die Art der Funktion richtet sich nach
den geschäftlichen Randbedingungen des vertreibenden Unternehmens. Sie wird auf die Komponenten
SHOP und CRK verteilt. Der SHOP-Komponente kommt dabei eine vorbereitende Funktion zu.
Der Shop muss den Inhalt eines Warenkorbs mit Nutzerinteraktion um eine Liefer- und
Rechnungsadresse ergänzen und mit einem Kunden assoziieren. Die Gesamtbestellung wird der CRK
übergeben.
Preisanfrage/Angebotsanforderung (SHOP-F8): Der Warenkorb wird durch diese Funktion in eine
Angebotsanfrage umgewandelt. Die Funktion folgt analog der Transaktion (SHOP-F7). In der CRK
wird jedoch abweichend ein Angebot erzeugt und vom Shop dargestellt. Alternativ, bei manueller
Erstellung des Angebots, wird dieses dem Kunden auf einem anderen Medium zugeleitet.
Vorlage für Bestellungen (SHOP-F9): Warenkörbe sind mit ihren jeweiligen Inhalten speicherbar
und werden von den Kunden in einer Verwaltungsumgebung verwaltet. Sie können als Vorlagen für
Bestellungen in den aktuellen Warenkorb übernommen werden.
Bereitstellung Produktdownload (SHOP-F10): Die Funktion extrahiert aus einer Bestellung die als
Download verfügbaren Produkte und stellt eine Downloadliste dar.
Suche nach Produkten (SHOP-SUCHE): Die SHOP-Komponente stellt eine Suchmöglichkeit für
die in allgemeinen und individuellen Katalogen gehaltenen Produkte bereit. Hierbei sind die
verschiedenen Datenfelder eines Produktdatensatzes zu durchsuchen. Ergebnis der Funktion ist eine
Trefferliste mit den gefundenen Artikeln, die eine Referenz auf deren Darstellung in der Komponente
enthält.
6.4.3.3 Konfigurationskomponente (KONF)
Allgemeine Funktion und Aufbau
Die Konfiguration unterstützt als Werkzeug die Gestaltung von Varianten, d.h. von Gegenständen
ähnlicher Form und Funktion mit einem in der Regel hohen Anteil identischer Baugruppen oder Teile
(vgl. [DIN 199-1]). Varianten entstehen durch die Modifikation von Standardprodukten oder die
individuelle Ausprägung von Bauteilen [Frech et al. 2000]. Produktkonfiguratoren unterstützen die
Gestaltung des Produkts in einem Konfigurationsprozess durch die Dokumentation der
Kundenwünsche und die Prüfung von Abhängigkeiten und Plausibilitäten der Angaben [Dangelmaier
2001]. Der Konfigurationsprozess umfasst die Auswahl aus möglichen Optionen [Rogoll und Piller
69
2003]. Konfiguratoren finden Einsatz im Außendienst mit dem Vertriebsmitarbeiter als Bediener bzw.
für die direkte Konfiguration durch den Kunden, z. B. über eine Web-Oberfläche [Dangelmaier 2001].
Sie bestehen aus einer Benutzungsschnittstelle zur Ausführung der Konfiguration und einer
Regeldatenbank, die Regeln mit Konfigurationseinschränkungen enthält.
Funktion im Architekturmodell
Die Konfigurationskomponente im Architekturmodell fokussiert primär den Kunden als Nutzer. Sie
ergänzt den Vertrieb standardisierter Katalogprodukte durch die Konfiguration kundenindividueller
Varianten. Die Komponente stellt die notwendigen Funktionen für die Erstellung und Verwaltung
bzw. den Import von Konfigurationsregeln bereit. Die von der KONF-Komponente abzubildenden
Funktionen sind im Einzelnen:
Konfiguration Produkt (KONF-F1): Die Funktion Konfiguration bildet den anwendungsfall-
spezifischen Konfigurationsprozess für Produkte auf Basis der Stücklisten bzw. Konfigurationsregeln
ab. Die Konfiguration kann auf Grundlage eines im Shop angezeigten Produkts durchgeführt werden,
sofern dieses konfigurierbar ist. Ergebnis des Vorgangs ist eine Konfiguration, auf deren Basis die
Komponente den Preis kalkuliert. Die notwendige Stückliste für die Konfiguration wird der CRK
entnommen.
Konfiguration bereitstellen (KONF-F2): Die Funktion überführt die erstellte Konfiguration in eine
extern verwendbare Darstellung. Diese Darstellung wird verwendet, um über die PVK KNF den
Warenkorb des Portals (SHOP-F4) zu füllen. Die Konfiguration muss als String codiert bzw. in Form
eines Produktsurrogats repräsentiert werden, damit eine spätere Rekonstruktion der Konfiguration zur
Ausführung in der Produktion möglich ist.
6.4.3.4 Content-Management-Komponente (CM)
Allgemeine Funktion und Aufbau
Content-Management-Systeme (CMS) sind sowohl als eigenständige Softwaresysteme als auch
Komponenten für Application-Server erhältlich. Zu den Kernfunktionen von CMS gehören die
Verwaltung und Bereitstellung schwach strukturiertem Content sowie die Abwicklung der
Redaktionsprozesse für die Verwaltung des Content [Rothfuss 2001]. CMS verfolgen das Prinzip der
Trennung von Inhalt, Struktur und Darstellung [Jablonski und Meiler 2002]. Zu unterscheiden sind
statisch und dynamisch arbeitende CMS. Statisch arbeitende Systeme verwalten Inhalte und erzeugen
statische HTML-Seiten für die Publikation. Im Gegensatz hierzu erzeugen dynamisch arbeitende CMS
bei Aufruf der jeweiligen Informationsseite die Darstellung der Seite. Dies erfolgt mittels Templates,
die den Aufbau der Seiten vorgeben und beim Aufruf dynamisch mit Inhalten gefüllt werden
[Bullinger 2001]. Zentrale Elemente von CMS sind das Content-Repository für die Haltung des
Content und die Workflow-Engine [Boiko2002].
Funktion im Architekturmodell
Die Funktion von CM-Komponenten im Architekturmodell ist die Verwaltung und Bereitstellung von
Content für das Portal, der nicht anderweitig (z. B. im Katalog) hinterlegt werden kann. Hierzu
gehören insbesondere Fachartikel, allgemeine Unternehmensnachrichten, technische Zeichnungen
(2D- und 3D-CAD-Zeichnungen) und erweiterte Produktdarstellungen (z. B. Detailbilder,
70
Animationen). Die Content-Management-Komponente stellt drei Möglichkeiten zum Abruf von
Content bereit:
− Contentobjekte: Einzelne, extern über Metadaten referenzierbare Content-Objekte. Beispiele:
Multimediale Animation zu einem Produkt, Fachartikel.
− Contentbereiche: Bereiche, die einer Navigation unterliegen. Beispiele: Anwendungsdatenbank
mit navigierbaren Anwendungsbeispielen, Unternehmensnachrichten mit zeitlicher Navigation.
− Referenzen: Referenzen auf Content-Objekte, die in andere Präsentationen eingebunden werden
können. Der Aufruf der Referenz führt zu dem Content-Objekt und veranlasst die Auslieferung
des Objekts durch die Komponente.
Die Navigationserzeugung der CM-Komponente wird nur im letzteren Fall für die Navigation
innerhalb einer begrenzten Content-Struktur bzw. eines Themenbereichs benötigt, der einer konkreten
PAK bzw. PVK zugeordnet ist. Content-Objekte werden in Content-Bereichen verwendet und sind
damit eine Teilmenge dieser Bereiche. Ihnen sind beschreibende Metadaten zuzuordnen, um die
Objekte wiederverwendbar zu gestalten [Christ 2003]. Für den Einsatz in der Portalarchitektur ist eine
dynamisch erzeugende CM-Komponente erforderlich. Sie muss über Funktionen zum Import von
Content in verschiedenen Formen verfügen. Die von der CM-Komponente abzubildenden Funktionen
sind im Einzelnen:
Bereitstellung Content-Bereich Allgemeine Unternehmensinformation (CM-F1): Die CM-
Komponente stellt eine Präsentation der allgemeinen Unternehmensnachrichten dar. Hierzu gehört die
Erzeugung der Navigation für diesen Bereich. Die Informationen werden in der Komponente gepflegt.
Bereitstellung einer Referenz auf ein Datenblatt (CM-F2): Referenzen auf Datenblätter werden für
die Einbindung in den Katalog und für redaktionelle Artikel bereitgestellt. Der Zugang zu den
Referenzen erfolgt über die Metadaten der zugehörigen Content-Objekte. Hierzu gehören u. a.
Artikelnummer und Artikelklasse. Die Datenblätter werden aus der Komponente DM importiert.
Bereitstellung einer Referenz auf eine technische Zeichnung (CM-F3): Die Bereitstellung einer
Referenz auf eine technische Zeichnung erfolgt analog zu CM-F2.
Bereitstellung einer Referenz auf eine erweiterte Produktdarstellung (CM-F4): Der Bereich der
erweiterten Produktdarstellungen umfasst Animationen und Bilder, die das Produkt eingehender
beschreiben. Die Bereitstellung einer Referenz auf eine erweiterte Produktdarstellung erfolgt analog
zu CM-F2.
Bereitstellung einer Referenz auf eine Applikationsbeschreibung (CM-F5): Die Bereitstellung
einer Referenz auf eine Applikationsbeschreibung erfolgt analog zu CM-F2.
Bereitstellung einer Referenz auf eine Anleitung (CM-F6): Die Bereitstellung einer Referenz auf
eine Anleitung erfolgt analog zu CM-F2.
Bereitstellung einer Referenz auf ein Handbuch (CM-F7): Die Bereitstellung einer Referenz auf
ein Handbuch erfolgt analog CM-F2.
Bereitstellung Content-Bereich für technische Dokumente (CM-F8): Die Bereitstellung der in CM
-F2 bis -F7 beschriebenen Daten erfolgt bei dieser Funktion in einer Darstellung mit eigener
Navigation. Der Content-Bereich gestattet einen Zugang zu den Applikationsbeschreibungen, Anlei-
tungen, Handbüchern und anderen technischen Informationen ohne den Zugriff auf den Katalog.
71
Bereitstellung Content-Bereich für redaktionelle Beiträge (CM-F9): Der Content-Bereich enthält
redaktionelle Beiträge mit optionalem Bezug zu den Artikeln. Die Beiträge referenzieren bei Bedarf
Artikel.
Bereitstellung von Referenzen auf redaktionelle Beiträge (CM-F10): Die Funktion stellt zu
vorgegebenen Artikeln bzw. weiteren Metadaten Referenzen auf die zugehörigen redaktionellen
Beiträge bereit.
Bereitstellung Portalgrafiken (CM-F11): Die Bereitstellung der Grafiken für das Portal, wie z. B.
Logos und Navigationsgrafiken, erfolgt durch diese Funktion.
Suche nach Inhalten (CM-SUCHE): Die Funktion stellt eine Suchmöglichkeit nach Content zur
Verfügung und liefert als Ergebnis eine Trefferliste zurück.
6.4.3.5 Produktberatungskomponente (BER)
Allgemeine Funktion und Aufbau
Die Produktberatung führt den Kunden auf Basis eines Dialogs von einer kundenspezifischen
Problemstellung zu einem konkreten Artikel bzw. einer Systemlösung. Im Gegensatz zur
Produktkonfiguration, bei der das Prozessziel die Erstellung eines individuell zusammengestellten
Produktes ist, steht hier die Selektion eines im Katalog befindlichen Artikels im Fokus. Die Software
greift hierbei auf intern repräsentiertes Wissen über die Artikel (Spezifikation, Anwendung etc.),
Kunden (Erfahrung, gekaufte Produkte etc.) und Verkaufsstrategien (Cross-Sales, bevorzugte
Produkte etc.) zurück [Bergmann et al. 2003]. Der Dialog kann über anklickbare Optionen oder
natürlichsprachlich textbasiert geführt werden. Das Wissen ist im Sinne von „Chatterbots“ eng mit den
Dialogregeln verknüpft [L’Abbate und Thiel 2001] oder unabhängig von der Dialogstrategie über ein
Domänenwissen modelliert [García-Serrano et al. 2001]. Die Software setzt für die Präsentation der
Lösung einen existierenden Katalog voraus [Gurzki et al. 2003]. Ihre Hauptbestandteile sind die
Präsentationskomponente, die Wissensbasis, die das Produktwissen in Form von Regeln enthält, eine
eingabenverarbeitende Komponente, welche die Interaktion mit dem Benutzer führt
(visuell/textbasiert) und eine Inferenzkomponente [Gurzki 2001]. Die Software bildet darüber hinaus
die notwendigen Prozesse zur Pflege der Wissensbasis ab. Hierzu gehört insbesondere die Erstellung,
die Änderung und das Löschen von Regeln im Rahmen einer Verbesserung der Beratung und der
Einführung bzw. dem Wegfall von Produkten und Produktkategorien.
Funktion im Architekturmodell
Die Produktberatungskomponente erfüllt die Funktion eines automatisierten Beraters. Sie führt den
Kunden über einen Dialog zum gewünschten Artikel und stellt Produktvergleiche bereit. Sie verfügt
über Funktionen zur Wartung der Wissensbasis. Die von der BER-Komponente abzubildenden
Funktionen sind im Einzelnen:
Bereitstellung eines Produktberatungsdialoges (BER-F1): Die Komponente stellt eine Oberfläche
für die Produktberatung bereit. Die Oberfläche besteht dabei aus einem Ausgabefeld, das die
Empfehlungen der Komponente wiedergibt, und einem Eingabefeld, das eine Interaktionsmöglichkeit
für den Nutzer bietet. Die Interaktion erfolgt hierbei textbasiert natürlichsprachlich oder mit einem
Wizard-Dialog. Die Komponente stellt Referenzen zu den in der SHOP-Komponente anzuzeigenden
Produktkategorien und Produkten zur Verfügung.
72
Bereitstellung Produktvergleich (BER-F2): Zu einer Auswahl zweier oder mehrerer Produkte im
Warenkorb vergleicht die Komponente die Produkteigenschaften und stellt ein Vergleichsergebnis dar.
Suche nach Produktempfehlungen (BER-SUCHE): Die Funktion stellt eine Suchmöglichkeit nach
Produktempfehlungen zu einem Thema zur Verfügung und liefert als Ergebnis eine Trefferliste
zurück.
6.4.3.6 Community-Komponente (CMK)
Allgemeine Funktion und Aufbau
Der Begriff Community reicht vom einfachen „Kunde-hilft-Kunde“-Ansatz mit Foren bis zu der
Ausgestaltung einer Business Community [Bullinger et al. 2002a], die nach heutigem Verständnis
Teilaspekte von Unternehmensportalen beinhaltet. Im Architekturmodell umfasst der Bereich der
Communitysoftware die notwendigen Softwarebausteine für die Bildung einer gemischten Kunden-
Unternehmensmitarbeiter-Community. Die Communitysoftware unterstützt dabei die Kommunikation
unter Produktanwendern (Kunden) und Mitarbeitern.
Funktion im Architekturmodell
Die Community-Komponente bildet die öffentliche und anfragenbezogene Kommunikation und damit
Teilfunktionen des Service ab. Die öffentliche Kommunikation umfasst die Diskussion und Lösung
allgemeiner Kundenprobleme. Die persönliche Kommunikation fokussiert Einzelprobleme. Die von
der CMK abzubildenden Funktionen sind im Einzelnen:
Asynchrone öffentliche Kommunikation mit Technischem Kundendienst/Support (CMK-F1):
Die asynchrone öffentliche Kommunikation wird durch die Bereitstellung eines öffentlichen
Diskussionsforums realisiert. Die Funktionalität umfasst dabei das Lesen und das Anlegen von
Beiträgen sowie das Editieren eigener Beiträge. Das Erstellen neuer Diskussionsfäden wird durch die
Funktion unterstützt. Es wird eine Moderatorenfunktion bereitgestellt, die das manuelle Editieren und
Löschen bestehender Diskussionsfäden ermöglicht.
Synchrone öffentliche Kommunikation mit Technischem Kundendienst/Support (CMK-F2): Der
Chat stellt eine Möglichkeit zur synchronen Echtzeitkommunikation dar. Die Chat-Funktion gestattet
die Auswahl verschiedener Kanäle mit Kommunikationsvorgängen zu verschiedenen Themenfeldern.
Es wird eine Moderatorenfunktion bereitgestellt, die einen Eingriff in die Kommunikation gestattet.
Suche nach Beiträgen (CMK-SUCHE): Die Funktion stellt eine Suchmöglichkeit nach Beiträgen
zur Verfügung und liefert als Ergebnis eine Trefferliste zurück.
6.4.4 Komponenten in der Schicht Betriebliche Informationskomponenten (BIK)
6.4.4.1 Softwaretechnischer Aufbau
Die Komponenten dieser Schicht werden durch komplexe Softwaresysteme realisiert, die über eine
eigene Präsentation, Geschäftslogik und einen Datenbestand verfügen. Sie sind damit ebenfalls intern
entsprechend einer Mehrschichtarchitektur aufgebaut. Die Betrieblichen Informationskomponenten
bilden verschiedene Kernprozesse des Unternehmens ab, die über den Betrachtungsrahmen eines
Portals hinaus für die Aufrechterhaltung des Tagesgeschäfts eines Unternehmens notwendig sind. Die
Funktionalität der Komponenten des Architekturmodells umfasst daher in der Regel nur eine
73
Untermenge des Funktionsumfangs der Systeme. Die Systeme, die durch die Komponenten abstrahiert
werden, bieten wegen ihrer zentralen Rolle im Unternehmen in der Regel umfangreiche Schnittstellen
an, die von den Komponenten der Portalarchitektur genutzt werden können.
6.4.4.2 Customer-Relationship-Management-Komponente (CRK)
Allgemeine Funktion
CRM-Software lässt sich in integrierte Globallösungen und funktionale Best-of-Breed-Lösungen
einteilen. Die Klasse der integrierten Globallösungen besteht aus autonomen CRM-Anwendungen mit
umfassender Funktionalität und aus ERP-Systemen mit CRM-Erweiterungen. Best-of-Breed-
Lösungen fokussieren auf Teilbereiche des operativen CRM (Marketing-, Sales-, Service-Automation,
Customer Interaction) und des analytischen CRM (Data Warehouse, Data Mining und OLAP)
[Hippner und Wilde 2001]. CRM-Anwendungen können stand-alone, in einer grundlegenden Form als
Teil eines ERP-Systems oder in einer engen Integration mit einem ERP-System betrieben werden. Die
Variante der Integration vermeidet doppelte Datenhaltung in Bezug auf eine große Bandbreite an
Stamm- und Bewegungsdaten [Buck-Emden und Zencke 2004].
Funktion im Architekturmodell
Die Funktion der CRK im Architekturmodell geht von einem Zusammenspiel mit einer ERP-
Komponente aus. Damit ist die CRK als alleinige Komponente für die Datenbereitstellung der
Stammdaten verantwortlich. Bewegungsdaten in Bezug auf Transaktionen werden über die CRK
verarbeitet. Sie nutzt die in der ERK hinterlegten Daten und legt dort die Kundenaufträge an. Damit
werden die Schnittstellen ERK-F1 bis ERK-F4 ausschließlich durch die CRK genutzt. Die von der
CRK abzubildenden Funktionen sind im Einzelnen:
Kundenpreisermittlung (CRK-F1): Die Kundenpreisermittlung errechnet für einen Artikel oder eine
Bestellung den individuellen Preis gemäß der im CRK hinterlegten Konditionen und den für den
Kunden gültigen Steuern. Bei Bestellungen werden die Frachtkosten berücksichtigt.
Verfügbarkeitsprüfung Artikel (CRK-F2): Die Funktion ermittelt zu einem Artikel die derzeitige
Verfügbarkeit auf Basis des aktuellen Lagerbestands des ERP-Systems und der
Wiederbeschaffungszeit.
Erstellung Angebot (CRK-F3): Die Funktion erstellt ein Angebot mit kundenindividuellen Preisen,
Frachtkosten und Steuern auf Basis der angefragten Artikel.
Einbuchung Kundenauftrag (CRK-F4): Die Einbuchung umfasst die Übernahme einer Bestellung
und das interne Anlegen eines Kundenauftrages. Dem Anlegen kann zur Vermeidung von
Fehlbestellungen ein automatischer und/oder manueller Prüfvorgang vorausgehen. Nach Abschluss
des Anlegens ist eine Auftragsbestätigung an den Kunden zu senden.
Bereitstellung Kundenstamm (CRK-F5): Die Bereitstellung des Kundenstamms umfasst den
gesamten Datenbestand pro Kunde bzw. einzelne Teile daraus. Der Kundenstamm kann über diese
Funktion nicht geändert werden, womit die Konsistenz der Daten mit anderen Systemen und
Komponenten gewährleistet wird.
Bereitstellung Materialstamm (CRK-F6): Die Funktion stellt den Materialstamm ausgewählter
Artikel für die weitere Datenveredelung zu Katalogen bereit.
74
Bereitstellung Auftragshistorie mit Kundenauftragsstatus (CRK-F7): Die Bereitstellung von
Informationen über aktive und abgeschlossene Aufträge aus einem bestimmten Zeitraum mit den
jeweiligen Auftragsdetails sowie des Auftragsstatus erfolgt durch diese Funktion der CRK.
Bereitstellung Stückliste (CRK-F8): Die Funktion stellt die Stückliste eines Artikels bereit. Die
Informationen der Stückliste ermöglichen die Konfiguration eines Artikels.
Bereitstellung Rechnungen (CRK-F9): Die Funktion stellt die Rechnungen eines angegebenen
Zeitraums zu einem Kunden bzw. zu einer Kundennummer bereit.
Suche nach Auftrag (CRK-SUCHE): Die Funktion stellt eine Suchmöglichkeit nach offenen und
abgeschlossenen Aufträgen zur Verfügung und liefert als Ergebnis eine Trefferliste zurück.
6.4.4.3 Enterprise-Resource-Planning-Komponente (ERK)
Allgemeine Funktion
ERP-Software bildet die innerbetrieblichen Prozesse eines Unternehmens ab und schafft eine
gemeinsame, abteilungsübergreifende Datenbasis [Otto 2003]. Sie unterstützt damit die Prozesse als
betriebswirtschaftliche Anwendung [Hufgard 1996]. ERP-Software besteht aus verschiedenen
aufgabenspezifischen Anwendungen bzw. funktionalen Modulen für Finanzen, Logistik,
Personalwesen sowie aus branchenspezifischen Erweiterungen [Williams 2000]. Diese Module
werden produktspezifisch in feinere Unterstrukturen gegliedert. ERP-Software dient der Planung und
Steuerung betrieblicher Vorgänge [Ritter 2003].
Funktion im Architekturmodell
Die ERK bildet damit eine Hauptschnittstelle der Portalarchitektur zu den innerbetrieblichen
Prozessen wie Auftragsabwicklung/Produktion, Entwicklung und Materialwirtschaft. Über diese
Schnittstelle werden Kundenaufträge angelegt und Informationen über bestehende Aufträge und
Artikelverfügbarkeit extrahiert. Die für die Einbindung in das Architekturmodell notwendigen
Funktionen sind bei größeren ERK in der Anwendung bzw. in dem Modul für Vertrieb und
Distribution lokalisiert [Williams 2000]. Die von der ERK abzubildenden Funktionen sind im
Einzelnen:
Bereitstellung Materialstamm (ERK-F1): Die ERK stellt den Materialstamm mit den darin
enthaltenen Informationen wie z. B. Sachmerkmale, Qualitätsmerkmale, Dispositionsdaten und
Stückliste (vgl. [Fink et al. 2001]) bereit.
Bereitstellung Verfügbarkeit zu Artikel (ERK-F2): Die Verfügbarkeit eines Artikels wird auf Basis
der artikelspezifischen Berechnung (z. B. Lagerbestand, ggf. Fertigungsdauer bei auftragsorientierter
Fertigung) bereitgestellt. Die Information kann qualitativer Art (verfügbar/nicht verfügbar) oder
spezifisch (verfügbar: Stück, Zeitraum) ausgeprägt sein.
Einbuchung Kundenauftrag (ERK-F3): Die ERK nimmt Kundenaufträge aus der CRK entgegen
und bucht diese als Belege ein. Die Kundenaufträge müssen alle relevanten Informationen zu den
bestellten Artikeln und dem Kunden enthalten.
Bereitstellung Kundenauftragsstatus und Historie (ERK-F4): Die ERK stellt Informationen über
aktive und abgeschlossene Aufträge aus einem bestimmten Zeitraum mit den jeweiligen
Auftragsdetails und dem Auftragsstatus inklusive des Versandstatus (Track und Trace) bereit.
75
6.4.4.4 Katalogdatenmanagementkomponente (KDM)
Allgemeine Funktion und Aufbau
Katalogdatenmanagementsysteme (KDMS) sind auf die Verwaltung von Produktdaten und die
Erzeugung elektronischer Kataloge spezialisierte Anwendungen. Mit Hilfe der Systeme können
Kataloge für verschiedene Zwecke, wie z. B. die Nutzung in E-Commerce-Anwendungen, E-
Procurement-Systemen und die Weiterverarbeitung in Satzsystemen für Printpublikationen, erzeugt
werden [Hentrich 2001]. Entsprechend verfügen sie über die notwendigen Schnittstellen für den
Import von Produktdaten und den Export von Katalogen. Die Software bildet die für die Erstellung
und Freigabe notwendigen Workflows ab.
Funktion im Architekturmodell
Hauptaufgabe für die Katalogdatenmanagementkomponente im Architekturmodell ist die Übernahme
des Basiskatalogs aus der CRK, die Erweiterung der Artikelinformation und die Bereitstellung von
Katalogen für die Portalsystemkomponenten. Basierend auf [Erdogan et al 2002] und [Hümpel und
Schmitz 2001] lassen sich als zu verarbeitende Kerninformationen für einen Katalog die
Katalogstruktur sowie für jedes Produkt Produktkategorie, Klassifikation, Produktkurzbezeichnung,
Staffelpreise, Preis, Anbieter/Hersteller (bei Drittprodukten), detaillierte Produktbeschreibung,
Produktnummern, Maßeinheiten, Bilder, Referenzen (z. B. Zubehör), Verweis auf erweiterte
Produktinformationen und Verweise/Referenzen im Katalog identifizieren. Der Redaktions- und
Pflegeprozess umfasst die Erweiterung der Basisinformationen aus dem Basiskatalog. Hierfür sind in
der Komponente die unternehmensspezifischen Redaktions- und Pflegeprozesse hinterlegt. In der
Komponente erfolgt die Definition von Katalogen für die verschiedenen Zwecke und Zielgruppen auf
Basis der hinterlegten Artikel. Die von der KDM-Komponente abzubildenden Funktionen sind im
Einzelnen:
Export Standardkatalog (KDM-F1): Die Funktion ermöglicht den Export von Gesamtkatalogen in
definierten Katalogformaten.
Export kundenindividueller/zielgruppenspezifischer Katalog (KDM-F2): Die Funktion ermöglicht
den Export kundenindividueller bzw. zielgruppenspezifischer Kataloge in definierten
Katalogformaten.
6.4.4.5 Dokumentenmanagementkomponente (DM)
Allgemeine Funktion und Aufbau
Der Begriff des Dokumentenmanagementsystems (DMS) ist weiträumig definiert. Unter die
Begriffswelt der DMS fallen unter anderem Document Related Technologies (DRT), Enterprise-
Content-Management (ECM), Document-Lifecycle-Management (DLM) und Knowledge-
Management (KM) [Kampffmeyer 2004]. Darüber hinaus ist auch der Bereich Engineering-Data-
Management dazu zu zählen [Berndt et al. 2003]. Kernfunktionen von DMS sind die Verwaltung
(Erzeugung, Versionierung, Archivierung) und Bereitstellung von Dokumenten. Diese können in
Gruppen (Container) bzw. als selbstbeschreibende Dokumentobjekte (Self-Contained) verwaltet
werden [Altenhofen et al. 2003]. Zur inhaltlichen Beschreibung werden den Dokumenten Metadaten
zugeordnet. Auf den Dokumenten werden durch integrierte oder externe Workflow-Funktionalität
Arbeits- und Freigabeschritte ausgeführt [Limper 2000]. Zu der Klasse der Dokumentenmanagement-
76
systeme gehören Engineering-Data-Management (EDM) Systeme bzw. Product-Data-Management
(PDM) Systeme. Diese unterstützen die Verwaltung und Bereitstellung von Informationen über
Produkte und deren Entstehungsprozesse. Sie integrieren im Produktentwicklungsprozess die
verschiedenen erzeugenden Systeme, wie z. B. CAx-Systeme [VDI 2002]. Zu den verwalteten Daten
gehören u. a. CAD-Modelle bzw. -Zeichnungen, beliebige Dokumente, Bilddateien, Projekt- und
Arbeitspläne [Bullinger et al. 1999].
Funktion im Architekturmodell
Im Architekturmodell wird von einer allgemeinen DM-Komponente ausgegangen, die sowohl
allgemeine Dokumente als auch Dokumente aus dem Produktentwicklungsprozess verwaltet. Bei
Bedarf kann die Komponente unter Funktionserhalt in zwei separate Komponenten aufgespalten
werden. Die DM-Komponente verwaltet als führendes System die produktbezogenen Dokumente. Die
Verwaltung in dieser Komponente stellt sicher, dass ausschließlich als inhaltlich richtig, korrekt
versioniert und freigegeben ausgezeichnete Dokumente veröffentlicht werden. Die DM-Komponente
beliefert im Architekturmodell andere Komponenten mit Informationen. Ein umgekehrter Weg ist
nicht vorgesehen. Die von der DM-Komponente abzubildenden Funktionen sind im Einzelnen:
Bereitstellung Dokument der Unternehmensinformation (DM-F1): Die Funktion stellt die vor-
handenen Dokumente der Unternehmensinformation bereit. Die Dokumente werden
anwendungsspezifisch über die Metadaten referenziert.
Bereitstellung Datenblatt (DM-F2): Das Datenblatt wird als das zentrale Informationselement für
technische Produkte von der DM-Komponente bereitgestellt. Es wird über die Zuordnung zu einem
Artikel in den Metadaten referenziert.
Bereitstellung technische Zeichnungen und Modelle (DM-F3): Die Funktion umfasst die
Bereitstellung von Zeichnungen in Bild- und 2D-Zeichnungsformaten sowie in 3D-CAD-Modellen.
Zu den 2D-Zeichnungen gehören insbesondere die Beschaltung von Geräten und Maschinen,
Bemaßungen und Schaltpläne. Die Zeichnungen und Modelle werden über die Zuordnung zu einem
Artikel in den Metadaten referenziert.
Bereitstellung Applikationsbeschreibung (DM-F4): Die Applikationsbeschreibungen stellen
praktische Anwendungen von Produkten dar. Die Funktion stellt das freigegebene Handbuch analog
zu DM-F3 bereit.
Bereitstellung Anleitung (DM-F5): Zu Produkten bzw. Produktgruppen existieren weiterführende
Anleitungen, wie z. B. für die Montage. Die Funktion stellt die freigegebene Anleitung analog zu DM-
F3 bereit.
Bereitstellung Handbuch (DM-F6): Das Produkthandbuch ist die technische Dokumentation, die mit
dem Produkt ausgeliefert wird. Die Funktion stellt das freigegebene Handbuch analog zu DM-F3
bereit.
Bereitstellung erweiterte Produktdarstellung (DM-F7): Die erweiterte Produktdarstellung umfasst
die Bereitstellung multimedialer Objekte und zusätzlicher Bilder und Texte. Die Funktion stellt die
freigegebenen erweiterten Produktdarstellungen analog zu DM-F3 bereit.
Bereitstellung elektronische Produkte (DM-F8): Die Funktion Produktdarstellung umfasst die
Bereitstellung von Software, Software-Updates, Schulungsunterlagen und anderen elektronisch
vertreibbaren Produkten. Die Produkte werden anhand der Artikelnummer selektiert und exportiert.
77
6.4.4.6 Workflow-Management-Komponente (WFM)
Allgemeine Funktion und Aufbau
Workflow-Management-Systeme (WFMS) dienen der Entwicklung von Workflow-Anwendungen und
damit der Steuerung betrieblicher Vorgänge [Scheer und Galler 1995]. Die Funktionalität von WFMS
umfasst unter anderem die Modellierung, Ausführung und Überwachung von Workflows [Gehring
und Gadatsch 1999]. Kern eines WFMS ist die Workflow Engine, welche die Laufzeitumgebung für
die Instanzen einer Prozessdefinition bereitstellt. Workflow Engines werden innerhalb eines Workflow
Enactment Service ausgeführt, der die Bildung, Verwaltung und Ausführung von Workflow-Instanzen
steuert. Der Service stellt die von der Workflow Management Coalition standardisierte Schnittstelle
WAPI (Workflow APIs and Interchange Formats) bereit. Diese deckt den Bereich der Kommunikation
zwischen Workflow Engines und Anwendungen ab [WFMC 1999].
Funktion im Architekturmodell
Die WFM-Komponente wird im Architekturmodell für die Abbildung zielgerichteter Kommunikation
zwischen Kunden und Unternehmen eingesetzt. Sie nimmt die Anfrage des Kunden entgegen und
leitet diese entsprechend der definierten Workflows an eine technische oder kaufmännische Rolle
weiter. Dabei werden im System entsprechende Benutzer und Rollen sowie zur Sicherstellung der
Bearbeitung Vertretungsregeln hinterlegt. Über die dargestellten Funktionen hinaus können mit Hilfe
der WFM-Komponente unternehmensindividuelle Interaktionen abgebildet werden. Zur Information
des Außendienstes ist eine Notifikation über die Anfrage in der Kundenhistorie des CRM-Systems
bzw. der CRK notwendig. Die WFM-Komponente stellt eine Oberfläche zum Abruf und zur
Bearbeitung der gemäß der Workflow-Definition für die jeweiligen Nutzer bestimmten Anfragen
bereit. Die von der WFM-Komponente abzubildenden Funktionen sind im Einzelnen:
Eingabe technische bzw. kaufmännische Anfrage (WFM-1): Die Anfrage des Kunden wird in einer
Web-Oberfläche erfasst. Nach einer Vorklassifizierung der Kundenanfrage wird der Workflow mit der
Information über die Identität des Kunden (Kundennummer) gestartet. Die Vorklassifizierung erfolgt
über ein Auswahlfeld, z. B. technisch, kaufmännisch, ggf. mit weiterer unternehmensspezifischer
Unterteilung. Die Anfrage wird selektiv gemäß der Vorklassifizierung weitergeleitet. Der Kunde erhält
nach Start eine numerische Referenz auf die Anfrage in Form eines „Tickets“. Die Beantwortung der
Anfrage erfolgt über E-Mail. Die Antworten werden dem Kunden optional unter der Ticket-Nummer
in einer personalisierten Darstellung bereitgestellt.
Abruf technische bzw. kaufmännische Anfrage (WFM-2): Der Abruf der Antworten ist über eine
Darstellung aller verfügbaren Antworten mit der Ticket-Nummer als Referenz möglich. Alte Anfragen
können im Rahmen des Abrufs durch den Kunden gelöscht werden.
Suche nach Anfragen (WFM-SUCHE): Die Funktion stellt eine Suchmöglichkeit nach Anfragen zur
Verfügung und liefert als Ergebnis eine Trefferliste zurück.
6.4.4.7 Groupware-Komponente (GPW)
Allgemeine Funktion und Aufbau
Zu dem Bereich der Groupware gehören Systeme, die Anwender bei einer gemeinsamen Aufgabe
unterstützen und den Beteiligten eine gemeinsame Arbeitsumgebung bereitstellen [Borghoff und
78
Schlichter 2000]. Die Unterstützung wird dabei in räumliche (Orte) und zeitliche Trennung
(synchrone/asynchrone Kommunikation) klassifiziert [Grudin 1994]. Entsprechend sind dem Bereich
Groupware verschiedene Systeme unterschiedlicher Art zuzuordnen, wie z. B. Konferenzsysteme, E-
Mail oder Dokumentenverwaltung.
Funktion im Architekturmodell
Im Rahmen des Architekturmodells steht die asynchrone Unterstützung projektbezogener
Kommunikation für den Vertrieb im Rahmen von Projekten mit mittlerem Komplexitätsgrad im
Vordergrund. Die Projektbücher (auch Projekträume genannt) stellen für die Teilnehmer eines
Projekts geschlossene Projektbereiche bereit. Sie beinhalten die Verwaltung der zugehörigen
Dokumente, Ressourcen und Termine sowie eine asynchrone Diskussionsunterstützung (Forum).
Durch einen Administrator können Berechtigungen für Projekte und Dokumente vergeben, Strukturen
angelegt sowie Teams definiert werden. Die von der GPW-Komponente abzubildenden Funktionen
sind im Einzelnen:
Bereitstellung Dokumentenverwaltung (GPW-F1): Die Verwaltung von Dokumenten umfasst alle
Arten von projektbezogenen Dokumenten. Hierzu gehören Textdokumente in verschiedenen
Formaten, Bilder, CAD-Zeichnungen und Source Code. Für das Management der Dokumente existiert
eine Möglichkeit zur Strukturierung der Dokumentenablage und zur Versionsverwaltung.
Bereitstellung Termin- und Ressourcenverwaltung (GPW-F2): Die Verwaltung stellt allen
Teammitgliedern eine Übersicht der projektbezogenen Termine und Ressourcen zur Verfügung. Die
Funktion ermöglicht das Anlegen neuer Termine bzw. Ressourcenbelegungen und deren Verwaltung.
Bereitstellung asynchroner Diskussionsunterstützung (GPW-F3): Die projektbezogenen Foren
stellen eine zu den öffentlichen Foren identische Funktionalität bereit. Der Unterschied liegt in der
Beschränkung des Zugangs auf die definierten Mitglieder des Projektteams. Entsprechend ist die
administrative Moderatorenfunktion um die Verwaltung der Berechtigungen erweitert.
Suche nach Dokumenten und Ressourcen (GPW-SUCHE): Die Funktion stellt eine
Suchmöglichkeit nach Dokumenten, Diskussionen und Ressourcen zur Verfügung und liefert als
Ergebnis eine Trefferliste zurück.
6.4.4.8 Autorisierungs- und Authentifizierungskomponente (AUTH)
Allgemeine Funktion und Aufbau
Die Authentifizierung umfasst die Prüfung der Identität eines Benutzers. Die Autorisierung ermittelt
die Berechtigungen, die zu einer Identität zugehörig sind [Cheswick et al. 2003]. Die hierfür
benötigten Informationen werden von Verzeichnisdiensten verwaltet. Diese verwalten Objekte einer
IT-Infrastruktur in einem Verzeichnisbaum, der die Objekte logisch nach Zusammenhang gruppiert
[Klünter und Laser 2003]. Bei Verzeichnissen sind zwei Ebenen der Authentifizierung notwendig.
Eine Ebene besteht aus der Authentifizierung zur Abfrage des Verzeichnisses selbst, z. B. durch eine
Softwarekomponente. Die zweite Ebene besteht aus der Authentifizierung von Nutzern mittels des
Verzeichnisdienstes. Der Verzeichnisdienst stellt Werkzeuge zur Pflege des Verzeichnisses bereit
[Schneider und Zwerger 2002].
79
Funktion im Architekturmodell
Die Autorisierungs- und Authentifizierungskomponente verwaltet die Nutzer und Berechtigungen des
Portals. Die Verwaltung umfasst auch alle Komponenten, die einer Authentifizierung und
Autorisierung bedürfen. Für die in der CRK hinterlegten Kunden werden jeweils Portalnutzer mit den
entsprechenden Eigenschaften (Sprache, Kundengruppe, Berechtigungen) angelegt. Dies geschieht
durch einen Datenabgleich mit der Komponente. Die von der AUTH-Komponente abzubildenden
Funktionen sind im Einzelnen:
Authentifizierung von Nutzern (AUTH-F1): Die Funktion authentifiziert einen Nutzer auf Basis
einer Anmeldeinformation. Die Funktion meldet als Ergebnis eine erfolgreiche Authentifizierung bzw.
einen Fehlschlag. Im Erfolgsfall wird die Nutzeridentifikation zurückgegeben, die den Nutzer
portalintern identifiziert. Optional sind weitere Informationen, z.B. Tickets, möglich (vgl.Kapitel 8.4).
Autorisierung von Nutzern (AUTH-F2): Zu einem authentifizierten Nutzer werden anhand der
Nutzeridentifikation die Berechtigung und die zugewiesenen Rollen zurückgegeben.
7 Datenarchitektur für Portale
7.1 Übersicht und Eigenschaften
Die Datenarchitektur stellt den statischen Zusammenhang der Daten des Architekturmodells für
Portale als Grundlage für die Kommunikationsarchitektur dar. Eigenschaften einer portalspezifischen
Datenarchitektur sind die statische Darstellung der relevanten Daten des Portals bzw. seiner
integrierten Komponenten und die direkte Zuordenbarkeit der Datenklassen zu Komponenten. Die
Zuordnung stellt ein wichtiges Merkmal zur Verknüpfung von Komponenten- und
Kommunikationsmodell dar.
Für die Beschreibung der Portalarchitektur wird die Grunddarstellung durch eine Identifizierung der
führenden Komponente erweitert. Die statische Struktur wird um eine portalspezifische Semantik für
die Beziehungen zwischen den Datenklassen ergänzt, die im nachfolgenden Abschnitt erarbeitet wird.
Die Datenmodelle werden ausgehend von den in Kapitel 6.4.2 definierten
Portalanwendungskomponenten aufgebaut. Die Modelle werden in der Notation der Unified Modeling
Language (UML) in der Version 1.5 dargestellt (vgl. [OMG 2003]).
7.2 Charakterisierung der Daten und Ableitung des statischen
Datenmodells
Die Daten in systemübergreifenden Architekturmodellen für die Abwicklung von Vertriebsprozessen
lassen sich in die Kategorien Stamm- und Bewegungsdaten einteilen. Nach [Harms und Luckhardt
2004] weisen diese die folgenden Grundeigenschaften auf:
− Bewegungsdaten besitzen eine zeitlich begrenzte Speicherdauer. Sie werden nur in diesem
Zeitraum aktualisiert. Beispiele: Aufträge, Bestellungen etc. Sie werden in den nachfolgenden
Datenmodellen mit dem klassenbildenden UML Stereotyp «Bewegungsdatum» versehen.
− Stammdaten besitzen keine zeitliche Begrenzung der Speicherdauer. Sie werden unbegrenzt
gehalten und aktualisiert. Beispiele: Artikeldaten, Kundendaten etc. Sie werden in den
nachfolgenden Datenmodellen mit dem klassenbildenden UML Stereotyp «Stammdatum»
versehen.
Darüber hinaus ergibt sich als Besonderheit aus dem integrativen Charakter von Portalarchitekturen
die weitere Datenart:
− Präsentationen sind Darstellungen von Inhalten im HTML-Format. Diese werden wiederum
selbst als Datum angesehen. Sie werden in nachfolgenden Datenmodellen mit dem
klassenbildenden Stereotyp «Präsentation» versehen.
Für die Modellierung des Portaldatenmodells werden die in UML definierten Beziehungen Vererbung,
Aggregation und Abhängigkeit (vgl. [Oestereich 2001]) verwendet. Dabei bilden die Beziehungen die
folgenden portalspezifischen Eigenschaften ab:
− «verwendet»: Die Verwendung beschreibt einen lesenden oder schreibenden Zugriff auf die
Instanzen der Datenklasse.
− «referenziert»: Die Referenzierung bezeichnet einen Verweis auf ein Objekt der Datenklasse. Die
Referenz muss gültig sein. Das Objekt der referenzierten Datenklasse muss jedoch nicht direkt
81
zugänglich sein. Die Referenz wird in späteren Verarbeitungsschritten für den Zugriff auf das
Datenobjekt genutzt.
− «erweitert»: Die Erweiterung einer Datenklasse beschreibt die weitergehende Spezialisierung
durch eine weitere Datenklasse. Hierbei handelt es sich im statischen Modell um eine
Spezialisierung in Form einer Anreicherung der ursprünglichen Klasse um weitere Attribute und
Methoden.
− «erbt»: Die Vererbung einer Datenklasse beschreibt die Spezialisierung im Sinne einer
klassischen 1:1-Vererbung oder eine Vererbung mit Einschränkungen, wie z. B. die Ableitung
eines Teilkataloges aus einem Gesamtkatalog. Hierbei werden Attribute und Methoden redefiniert.
Eine Semantik der Erweiterung und Vererbung liegt in dem Export eines Objekts dieser Klasse in ein
anderes System. Durch den Import und den damit verbundenen Transformationen in
komponenteninterne Darstellungen entsteht eine abgeleitete Klasse.
7.3 Darstellung und Erweiterung der Notation
Das Datenmodell wird mit seinen Teilmodellen auf der Ebene von Datenklassen auf Basis von
Klassendiagrammen erstellt. Für die Schaffung eines Gesamtzusammenhangs mit den anderen
Teilmodellen, insbesondere mit dem Komponentenmodell und den dort beschriebenen Zuordnungen
von Datenklassen zu Komponenten, ist eine Darstellung der Komponentenzugehörigkeit der Klassen
erforderlich. UML bietet als immanente Methoden zur Erweiterung die Verwendung von Stereotypen,
Constraints und Tagged Values an (vgl. [Hitz und Kappel 1999]. Stereotypen können für eine
weitergehende Klassifizierung der dargestellten Klassen verwendet werden. Die Klassifikation erlaubt
eine Zuordnung einer Klasse zu einer Komponente. Die Zuordnung zu einer Komponente und einem
Datum führt zu einelementigen Kategorien, die nicht dem Sinn der Stereotype entsprechen. Die UML-
Nomenklatur wird daher durch eine Zuordnung der Klassen zu Systemen und den im
Komponentenmodell beschriebenen Datenobjekten erweitert. Diese erfolgt durch das Hinzufügen der
im Komponentenmodell eingeführten Komponentensignatur. Die Darstellung der erweiterten Signatur
beginnt mit einem vorgestellten Zeichen „>“. So beschreibt „>CRK-D2“ das Datenobjekt D2 der CRK
entsprechend des Komponentenmodells. Für Daten, die ausschließlich komponentenintern verwendet
und nicht von außen genutzt werden, wird keine fortlaufende Nummer vergeben. In diesem Sonderfall
beschränkt sich die Signatur auf die Zuordnung zu einer Komponente (z. B. „>SHOP“).
7.4 Grunddatenmodell Konfiguration
Die Portalanwendungskomponente Konfiguration (PAK KNF) übernimmt die Darstellung der
Konfigurationskomponente (KONF) und adaptiert diese. Die Konfigurationskomponente nutzt zur
Konfiguration von Artikeln deren Stückliste (CRK-D8) und die intern in der Komponente hinterlegten
Konfigurationsregeln. Der konfigurierte Artikel wird als Konfiguration in den Warenkorb der SHOP-
Komponente übernommen. Die Übernahme der Konfiguration erfordert ein geeignetes Format, das
von der SHOP-Komponente im Warenkorb verwaltet und bei der Ausführung der Bestellung in die
Konfiguration zurückgeführt werden kann. Das Grunddatenmodell Konfiguration ist in Abbildung 18
dargestellt.
82
Abbildung 18: Grunddatenmodell Konfiguration
7.5 Grunddatenmodell Katalog
Die Portalanwendungskomponente Katalog (PAK KAT) verwendet zur personalisierten Präsentation
des Kataloges für den Kunden die Präsentationen der SHOP-Komponente (PSK SHOP). Die Daten
werden im Katalog-Repository verwaltet. Zu den Daten gehören die Darstellungen des
Standardkataloges (KDM-D1) bzw., sofern hinterlegt, des kundenindividuellen Kataloges (KDM-D2).
Die Kataloge sind eine Ausprägung des Basiskataloges des Unternehmens (CRK-D5) und werden von
der Katalogdatenmanagementkomponente (KDM) verwaltet und dort mit Informationen angereichert.
Der kundenindividuelle Preis wird aus dem Katalog oder alternativ aus der CRK entnommen. Die
PAK KAT erweitert die Katalogdarstellung um Referenzen auf Dokumente der Produktpräsentation
und -repräsentation (vgl. STEP, [Anderl und Trippner 2000]). Dies umfasst Datenblatt, technische
Zeichnungen, Modelle und weitere zusätzliche produktbezogene Informationen. Zwischen
Standardkatalog und redaktionellen Beiträgen besteht eine wechselseitige Referenzierung. Diese
ermöglicht einen Zugriff auf die Artikel, die in redaktionellen Beiträgen beschrieben sind, bzw. den
Aufruf redaktioneller Beiträge zu einem Artikel aus der PAK KAT heraus. Über den authentifizierten
Portalnutzer (PORT-D1) wird eine Verbindung zum Kundenstamm (CRK-D4) hergestellt. Das
Grunddatenmodell Katalog ist in Abbildung 19 dargestellt.
83
Abbildung 19: Grunddatenmodell Katalog
7.6 Grunddatenmodell Kommunikation, Kooperation und
Unternehmensinformation
Die Portalanwendungskomponente Kommunikation (PAK KOMM) aggregiert die Darstellungen des
Forums der Community-Komponente (CMK-D1), des Chat (CMK-D2), der Anfrageerfassung (WFM-
D1) und der Darstellung der Antworten (WFM-D3). Für die Navigation der Antworten wird die
Ticket-Nummer der Anfrage (WFM-D2) verwendet. Die PAK Kooperation (PAK KOOP) verwendet
die Darstellungen der Dokumentenverwaltung (GPW-D1), der Termin- und Ressourcenverwaltung
(GPW-D2) und der Diskussionsverwaltung (GPW-D3) der Groupware-Komponente. Die PAK
Unternehmensinformation (PAK UINF) übernimmt die Darstellung der Content-Management-
Komponente (CM-D1) direkt. Das Grunddatenmodell Kooperation ist in Abbildung 20 dargestellt.
84
Abbildung 20: Grunddatenmodell Kooperation, Kommunikation, Unternehmensinformation
7.7 Grunddatenmodell Transaktion
Das Grunddatenmodell Transaktion verwendet Teilausschnitte der „Datenstruktur für die
Vertriebsabwicklung“ nach [Scheer 1998a]. Hierbei werden die für das Portal relevanten Teile
identifiziert, weitere Elemente ergänzt und die entwickelte Notation angewandt. Die
Portalanwendungskomponente Transaktion (PAK TRANS) nutzt für die Durchführung von
Transaktionen und die Darstellung Daten der SHOP-Komponente und der CRK. Die Darstellung des
Warenkorbs für den Einkauf durch den Kunden wird von der PAK TRANS auf Basis der Darstellung
der Komponente SHOP (SHOP-D4) übernommen. Für den Inhalt des Warenkorbs wird der
individuelle Kundenpreis ermittelt. Der Warenkorb kann bestellt (Erzeugung einer Bestellung, SHOP-
D5) bzw. es kann auf dessen Basis ein Angebot durch den Kunden angefordert werden
(Angebotsanforderung, SHOP-D6). Die Darstellung des Angebots wird von SHOP (SHOP-D10) auf
Basis eines in der CRK erzeugten Angebots (CRK-D3) erstellt. Die SHOP-Komponente kann intern
gespeicherte Warenkörbe als Bestellvorlagen verwalten. Diese können in einer Darstellung der
Vorlagen angezeigt und als Warenkorb übernommen werden (SHOP-D7). Die Auftragshistorie wird
auf Basis der in der CRK hinterlegten Historie angezeigt (CRK-D6). Das Grunddatenmodell
Transaktion ist in Abbildung 21 dargestellt.
85
Abbildung 21: Grunddatenmodell Transaktion, auf Grundlage von [Scheer 1998a]
7.8 Weitere Grunddatenmodelle
Das Grunddatenmodell Produktwahlunterstützung und Beratung sowie die Modelle für die
Autorisierung und die Verwaltung von Dokumenten und Content wird in Anhang G dargestellt.
8 Infrastrukturarchitektur für Portale
8.1 Übersicht und Eigenschaften
Aufgabe der Infrastrukturarchitektur ist die Beschreibung der softwaretechnischen Infrastruktur,
welche die Grundlage des Portals bildet. Eine portalspezifische Infrastrukturbeschreibung muss als
Grundlage des Portals eine Beschreibung der softwaretechnischen Portalinfrastruktur zur Einbindung
von PAK in Portalsoftware sowie bezogen auf die Komponenten des Architekturmodells die Aspekte
Suche, Authentifizierung, Rollen, Personalisierung und Individualisierung umfassen. Zur Infrastruktur
eines Portals gehört die Zuordnung von Funktionen auf die Systeme des Technischen Vertriebs.
Im Rahmen der Infrastrukturarchitektur werden daher ein Modell für die Suche im Portal, ein
Authentifizierungsmodell und ein Rollenmodell entwickelt. Als weitere Bestandteile der Infrastruktur
werden das Personalisierungs- und Individualisierungsmodell sowie ein Modell für die Abbildung der
abstrakten Komponenten auf reale Systeme erstellt.
8.2 Beschreibung der softwaretechnischen Portalinfrastruktur
Portalsoftware stellt den technischen Rahmen für die Realisierung eines Portals bereit und bildet damit
aus Sicht des Architekturmodells die unterste Ebene der Infrastruktur. Die Software kann
entsprechend der folgenden drei Arten ausgeprägt sein:
1. Verwendung einer Portalsoftware mit standardisierter PAK-Schnittstelle.
2. Erstellung einer individuellen projektspezifischen Portalsoftware mit eigendefinierter PAK-
Schnittstelle.
3. Verwendung einer Portalsoftware mit proprietärer PAK-Schnittstelle.
Der in allen Fällen notwendige funktionale Umfang wurde bereits in Kapitel 3.6 dargestellt. Eine
projektspezifische Eigenentwicklung lässt sich mit den dort vorgestellten Technologien realisieren. Im
Folgenden wird daher das Vorhandensein einer Portalsoftware mit den definierten Grundfunktionen
vorausgesetzt. Die Verwendung einer Portalsoftware mit standardisierten PAK-Schnittstellen bietet
gegenüber den beiden anderen Ansätzen den Vorteil einer Wiederverwendung von PAK in anderen
Portalinstallationen sowie der Zukaufmöglichkeit von fertigen Komponenten auf Basis des Standards.
8.2.1 Schnittstellen zwischen Portalsoftware und PAK
Die Kommunikation zwischen den PAK und der Portalumgebung erfolgt über eine definierte PAK-
Schnittstelle. Für alle drei vorgestellten Realisierungsvarianten von Portalsoftware ergibt sich im
Rahmen eines Architekturmodells die Notwendigkeit der Definition erforderlicher Schnittstellen-
grundfunktionen. Diese spiegeln die Grundfunktionen von Portalsoftware wieder (vgl. Kapitel 3.6):
− Übergabe von Ein- und Ausgabe: Die Portalsoftware stellt die von der PVK über eine
Schnittstelle bereitgestellte Ausgabe im Seitenkontext dar. Bei einem Aufruf der Seite fordert die
Portalsoftware die Ausgabe der PVK an. Zur Ausgabe der PVK werden ggf. Dekorationen wie
Titelleiste, Rahmen und Steuerelemente für die Darstellung hinzugefügt. Eingaben werden an die
betroffene PVK weitergeleitet.
87
− Konfiguration PAK: Eine PAK wird über eine oder mehrere PVK mit der jeweiligen
Konfiguration bei der Portalsoftware angemeldet. Die Konfiguration der PAK erfolgt in den in der
Portalsoftware gebildeten PVK-Instanzen durch Selektion der View.
− Übernahme und Weiterleitung von Nachrichten: Die Portalsoftware bietet einen Mechanismus
für das Versenden von Nachrichten zwischen den PVK an. Über diesen Mechanismus können
Daten zwischen den PVK ausgetauscht werden.
− Autorisierung und Zugriff auf Benutzerdaten: Die Portalsoftware stellt den PVK vorhandene
Benutzerdaten zur Verfügung.
Der derzeit einzige Industriestandard für PAK-Schnittstellen ist die Portlet-API, die durch eine
Standardisierung im Java Community Process definiert wurde (vgl. [Abdelnur und Hepper 2003]).
Damit beschränken sich interoperable Anwendungen zwischen Produkten verschiedener Hersteller auf
Java-basierte Portale. Für die Realisierung mit anderen Technologien ist der Rückgriff auf proprietäre
Schnittstellen und Konzepte notwendig.
8.3 Modell für die Suche im Portal
Die Suchfunktion des Portals bietet dem Nutzer eine zentrale Suche im Datenbestand an. Der Zugang
über hierarchische Verfahren wird über die Navigation des Portals bzw. die komponenteninterne
Navigation der im Portal eingebundenen PAK abgedeckt. Im Vordergrund steht daher die
Freitextsuche im Datenbestand der integrierten Komponenten. Die portalweite Suche über
verschiedene Komponenten steht vor den folgenden Herausforderungen:
− Die Informationen sind in den Komponenten verschieden strukturiert.
− Die Informationen weisen zwischen den Komponenten eine differierende Semantik auf.
− Die Suchfunktionen und -algorithmen der Komponenten sind bereits für die jeweiligen
Informationsstrukturen konzipiert und weisen entsprechende Unterstützung durch Taxonomien
und Thesauri auf (vgl. [Schmalz 2004]).
Zur Lösung dieses Problems wird im Folgenden der Suchraum für das Vertriebsportal definiert und
eine Methode zur Erlangung einer konsolidierten Darstellung der Ergebnisse entwickelt.
8.3.1 Definition des Suchraums und Einbindung der Suche
Der primäre Informationsraum, der von einer Suche in einem Vertriebsportal abgedeckt werden muss,
umfasst alle vertriebsrelevanten Informationen, die für einen Kunden bei der Auswahl eines Produkts
und für die Kaufentscheidung wesentlich sind. Dies sind insbesondere redaktionelle Inhalte
(Unternehmensdarstellung, redaktionelle Beiträge etc.) sowie Produkt- und Applikations-
informationen. Die Menge aller übrigen Informationen ist Bestandteil sekundärer Informationsräume.
Die Einteilung in zwei Klassen gestattet eine Differenzierung des Suchangebots:
− PAK-spezifische Einzelsuche für sekundäre Informationsräume: Die PAK können über eigene
Suchfunktionen verfügen, die unabhängig von der portalweiten Suche fokussiert den Datenbestand
dieser PAK bzw. Teile davon durchsuchen. Hierbei wird direkt auf die vorhandenen
Suchfunktionen der eingebundenen Komponenten zurückgegriffen. Die PAK-spezifische
dezentrale Suche nutzt den jeweiligen Suchmechanismus der PAK. Die Suche wird von der PAK
dargestellt und ist nur in deren Informationsraum möglich. Hierzu gehören die PAK KOMM,
PWB, KAT, TRANS und KOOP.
88
− Portalweite Suche für primäre Informationsräume: Die von der Portalsoftware oder alternativ
über eine eigene PAK angebotene zentrale Suchfunktion konsolidiert die Suchergebnisse
ausgewählter PAK (föderierte Suche). Die portalweite Suche baut auf der PAK-spezifischen
Einzelsuche auf. Die von dieser Suche behandelten PAK müssen eine Schnittstelle für die Suche
bzw. eine View zur Anzeige von Suchergebnissen aufweisen. Hierzu gehören die PAK KAT,
PWB und UINF.
(a) (b)
Abbildung 22: (a) PAK-spezifische Einzelsuche (b) Integrierte Portalsuche. Darstellung an Beispielen.
Das Suchergebnis ist pro Fundstelle der Titel des Dokuments bzw. der Seite, ein Link zu der
Fundstelle in der PAK und optional eine Kurzbeschreibung. Die Einbindung der Suchergebnisse
nachgeordneter Komponenten in eine PAK erfolgt durch die in Kapitel 9.3 definierten
Integrationsmuster M1, M2, M6 und M7. Als Datenformat kommen anwendungsspezifische
Datenstrukturen und allgemeine Formate in Frage. Es besteht die Option die Suche über eine visuelle
Benutzungsschnittstelle (Präsentationsebene) durchzuführen und die Ergebnisse mit den in Kapitel 9.6
dargestellten Adaptions- und Transformationsverfahren zu extrahieren. Für die Integration eignet sich
im besonderen Maße die in Kapitel 3.6.3 vorgestellte Content Repository API.
8.3.2 Konsolidierung und Darstellung der Ergebnisse
Die durch die suchende PAK aus den nachgeordneten Komponenten akquirierten Suchergebnisse
werden von dieser konsolidiert und in eine integrierte Darstellung überführt. Der Vorgang erfolgt bei
einer PAK-spezifischen Einzelsuche mit einer Konsolidierung der Teilergebnisse der nachgeordneten
Komponenten (Abbildung 22 (a)). Bei der integrierten Portalsuche finden entsprechend
kaskadenförmig PAK-spezifische Einzelsuchen mit einem nachfolgenden zweiten Konsolidierungs-
schritt in der PAK SUCHE statt (Abbildung 22 (b)). Die Konsolidierung umfasst die folgenden
Schritte:
89
1. Rewriting: Umschreibung des gelieferten Links auf die Fundstelle bzw. Generierung einer
Referenz auf ein Model/View-Tupel der PAK. Der umgeschriebene Link muss auf eine View
einer PVK der PAK zeigen, die die Fundstelle visuell darstellt.
2. Zusammenführung: Aggregation der Fundstellen verschiedener nachgeordneter Komponenten
zu einem konsolidierten Suchergebnis in einer Darstellung.
Für die Zusammenführung der Fundstellen zu einem Suchergebnis sind die in Tabelle 14
beschriebenen und bewerteten Verfahren einzusetzen.
Methode der
Darstellung
Beschreibung Bewertung
Treffer als Übersicht Eine Übersicht zeigt die Anzahl der
Fundstellen nach PVK/PAK mit dem
Namen der PVK/PAK an. Die Namen der
PVK/PAK verlinken auf die Darstellung
der Suchergebnisse der einzelnen PAK.
(+) Keine Konsolidierung
notwendig.
(–) Fehlende Übersicht für
den Kunden über die Quali-
tät der einzelnen Treffer.
Gemischte
Detaildarstellung
Die Darstellung der Suchergebnisse der
einzelnen PVK/PAK werden beliebig
gemischt in einer detaillierten Übersicht
dargestellt.
(+) Einfache Konsolidierung.
(–) Keine erhöhte Priorisierung
relevanter Treffer.
Detaildarstellung in
getrennten
Bereichen
Die Darstellung der Suchergebnisse erfolgt
in nach PAK getrennten und mit den
Namen der PVK/PAK ausgezeichneten
Bereichen der Ergebnisdarstellung in einer
detaillierten Übersicht.
(+) Einfache Konsolidierung,
besonders geeignet für
inhomogene Treffer-
darstellungen der PAK.
(–) Hoher Platzbedarf für
Darstellung.
Gewichtete
Mischung der
Treffer
Die Suchergebnisse der einzelnen
PVK/PAK werden durch ein
Bewertungsverfahren in ihrer Relevanz
bezüglich der Suchanfrage bewertet und
entsprechend priorisiert dargestellt.
(+) Hoher Nutzwert für den
Kunden.
(–) Notwendigkeit eines auf die
Semantik der Treffer
abgestimmten Bewertungs-
verfahrens.
Legende: Bewertung + positiv, – negativ.
Tabelle 14: Bewertung von Darstellungsmethoden für Suchergebnisse
8.4 Authentifizierungs- und Rollenmodell
8.4.1 Verwaltung von Nutzern, Rechten und Rollen
Die Nutzer des Portals müssen mit den zugehörigen Rechten und Rollen verwaltet werden. Hierbei
werden die Nutzer mit den zugeordneten Rechten und Rollen im Portal (Portalnutzer) und die Nutzer
der in das Portal eingebundenen Komponenten der Schichten PSK und BIK mit den jeweils dort
vorhandenen Rechten und Rollen unterschieden. Portalnutzer sind dabei nicht zwingend identisch mit
den Nutzern in den nachgeordneten Schichten. Sie können in diesem Fall nicht unmittelbar mit den
dort hinterlegten Rechten und Rollen in Verbindung gebracht werden.
Die Verwaltung der Portalnutzer umfasst das Anlegen, Speichern, Löschen und Modifizieren der
Nutzereinträge sowie die Authentifizierung und Autorisierung. Diese werden im Architekturmodell
von der Komponente AUTH übernommen (vgl. Kapitel 6.4.4.8). Die abstrakte Komponente kann
Bestandteil der Portalsoftware sein oder als externer Verzeichnisdienst realisiert werden. In beiden
90
Fällen wird die Autorisierung für den Zugriff auf Portalseiten und die enthaltenen PVK auf Basis der
von AUTH gelieferten Nutzerdaten durch die Portalsoftware (PORT) durchgeführt. Die hierfür
notwendige Funktion ist in der Funktionskarte PORT in Anhang F definiert.
8.4.2 Authentifizierungsebenen und Single-Sign-On-Verfahren
Die verschiedenen Ebenen mit ihrer individuellen funktionalen Charakterisierung entsprechend des
Schichtenmodells weisen verschiedene Voraussetzungen für die Authentifizierung auf. Abbildung 23
verdeutlicht den Bedarf der Authentifizierung im Architekturmodell.
1
2 3
4
Portalumgebung
PAK
PSK
BIK
4 5
2
Client
9
7
6
8
(1) Authentifizierung Client → Portalumgebung; (2) Authentifizierung Portalumgebung → PSK, ausgeführt
außerhalb der Portalumgebung; (3) Authentifizierung PAK → PSK, ausgeführt in der Portalumgebung;
(4) Authentifizierung PSK →BIK; (5) Authentifizierung Portalumgebung →BIK; (6) Authentifizierung PAK → PAK;
(7) Authentifizierung PSK → PSK, ausgeführt außerhalb der Portalumgebung; (8) Authentifizierung PSK → PSK,
ausgeführt in der Portalumgebung; (9) Authentifizierung BIK → BIK.
Abbildung 23: Authentifizierungsebenen der Portalarchitektur
Die Ebene (1) authentifiziert den Client und damit den Portalnutzer gegenüber der Portalsoftware. Die
Authentifizierung erfolgt über ein Login/Passwort-Schema oder Client-Zertifikat ausgestellt von
einem Trust-Center bzw. über eine Tokencard/Authentifizierungsserver-Kombination. Die bei
Zugriffen auf integrierte Komponenten notwendige Authentifizierung zwischen der Portalsoftware
bzw. den darin enthaltenen PAK und den zugegriffenen Komponenten (Ebene (2) und (5)) wird als
Single Sign On bezeichnet (SSO, vgl. Kapitel 3.6.3). Die notwendigen Mechanismen sind sowohl in
der Portalumgebung als auch in der PAK realisierbar. Grundsätzlich sollte die Funktionalität aus
Gründen der Wiederverwendung und Sicherheit durch die Portalsoftware behandelt werden. Dies ist
jedoch nur möglich, wenn eine externe Anwendung über eine eigene PAK/PVK verfügt. Wird eine
PAK/PVK individuell entwickelt, so ist diese selbst für die Anmeldung an extern genutzte
Komponenten verantwortlich. Das Single Sign On wird mit den folgenden Verfahren umgesetzt:
− Personifizierung: Bei der Personifizierung verwendet die Portalumgebung nach erfolgreicher
Authentifizierung die Anmeldedaten zur Anmeldung an weitere Systeme. Anstelle der
91
Klartextinformation kann alternativ ein von einem Authentifizierungsserver ausgestelltes Ticket
für die weiteren Anmeldungen verwendet werden (vgl. [Schneider und Zwerger 2002]).
− Erweiterte Personifizierung: Bei der erweiterten Personifizierung bietet die Portalumgebung
einen geschützten Speicher an, der für jeden Portalnutzer die individuellen Zugangsdaten für alle
Komponenten enthält (vgl. [Novell 2004]). Die Zugangsdaten können hierbei zwischen den
Komponenten verschieden sein.
− Definition eines Komponentennutzers: Bei der Definition eines allgemeinen
Komponentennutzers wird in der Komponente ein spezieller Nutzer für den Zugriff durch andere
Komponenten angelegt. Es wird eine Vertrauensstellung gegenüber der nutzenden Komponente
vorausgesetzt. So umfasst die Vertrauensstellung z. B. die Tatsache, dass eine nutzende
Komponente ausschließlich auf den Daten des aktuellen Portalnutzers bzw. in dessen Kontext
operiert.
− Gleiche Zugangsdaten: Die Verwendung gleicher Zugangsdaten erfordert eine gemeinsame
Benutzerverwaltung beider involvierter Komponenten. Als Alternative zu der gemeinsamen
Verwaltung ist eine Replikation der Zugangsdaten möglich. Hierzu sind jedoch identische
Berechtigungskonzepte der Komponenten notwendig.
Für die Anwendung des SSO bei der Komponentenintegration müssen die Verfahren über das
gewählte Integrationsmuster (vgl. Kapitel 9.3) abgewickelt werden. Der interne Zugriff von PAK auf
die im Application-Server der Portalumgebung residierende PSK (Ebene (3)) wird auf Basis der für
SSO genannten Mechanismen durchgeführt. Die Authentifizierung kann alternativ über den
Application-Server oder interne, anwendungsspezifische Mechanismen erfolgen.
Bei Zugriffen zwischen den anderen Komponenten (Ebenen (4), (6), (7), (8), (9)) muss zwischen der
Personifizierung, der Definition eines Komponentennutzers und gleichen Zugangsdaten gewählt
werden. Das Grundprinzip der Verfahren ist identisch zu den unter Single Sign On genannten, jedoch
tritt an Stelle der Portalsoftware bzw. PAK die PSK oder BIK. Hierbei sind die Nutzer interne Nutzer
der Komponenten.
8.5 Personalisierungs- und Individualisierungsmodell
Der Bereich der dynamischen Anpassung der Inhalte differenziert sich in die Teilbereiche
Personalisierung und Individualisierung (Abbildung 24 (a)). Die Personalisierung umfasst dabei eine
Anpassung der Inhalte an die Interessen und Bedürfnisse einer Personen- bzw. Kundengruppe. Die
Individualisierung passt die Inhalte an die Interessen und Bedürfnisse einer einzelnen Person bzw.
eines Kunden an [Leimstoll und Schubert 2002]. Die Aufgaben und Zielsetzungen der
Personalisierung und Individualisierung in einem Portal für den Technischen Vertrieb lassen sich in
die folgenden Bereiche zusammenfassen:
− Zielgruppenspezifische Eingrenzung des Informationsraumes: Kundengruppenindividuelle
Darstellung zielgruppenspezifischer Informationen.
− Beschränkung: Beschränkung des Angebots auf zulässige Applikationen und Informationen.
− Zugriff auf kundenindividuelle Daten: Zugriff auf die dem Kunden zugeordneten Daten, wie
z. B. offene Bestellungen, Rechnungen, Artikel.
Die Personalisierung und Individualisierung des Portals erfolgt in einer portalspezifischen Ausprägung
des Modells von Leimstoll und Schubert (Abbildung 24 (b)).
92
(a) (b)
Abbildung 24: Gegenüberstellung: (a) Personalisierung von Websites nach [Leimstoll und Schubert 2002]
(b) Abgeleitete Personalisierung von Portalen für den Technischen Vertrieb
Die Darstellung zeigt, dass zur Personalisierung bzw. Individualisierung mehrere Elemente
(Portalseiten, PVK, PAK und damit auch PSK, BIK) beitragen. Die Gestaltung stellt sich somit
erheblich komplexer dar als bei anderen Anwendungen für den elektronischen Handel mit geringerem
Integrationspotenzial. Die personalisierbaren bzw. individualisierbaren Elemente der Portalarchitektur
weisen folgende Eigenschaften auf:
− Portalseiten: Die Seiten des Portals sind zur Personalisierung einer Kundengruppe bzw. zur
Individualisierung einem Kunden zugeordnet. Die Gestaltung der Seiten umfasst die Einbindung
und die visuelle Anordnung von PVK. Durch die Einbindung einer PVK ist diese mit ihrer
konfigurierten Funktionalität für den Kunden zugänglich.
− PVK/PAK: Die von der PVK dargestellten Inhalte und Funktionen werden auf Basis ihrer
Konfiguration bzw. in dem Kontext des Benutzers personalisiert bzw. individualisiert.
Konfiguration und Kontext liefern die notwendigen Informationen zur kundengruppen- bzw.
kundenspezifischen Auswahl der View bzw. des Models. Über die im Portal gebildete Instanz
einer PVK wird die PAK personalisiert. Eine PAK kann gleichzeitig öffentliche, nicht
personalisierte PVK und personalisierte bzw. individualisierte PVK enthalten.
− PSK/BIK: Für die Personalisierung und Individualisierung in den Komponenten der Ebenen PSK
und BIK existieren zwei verschiedene Möglichkeiten. Im Rahmen eines SSO mit
Kundenauthentifizierung werden für den identifizierten Portalnutzer individualisierte Daten bzw.
Funktionen bereitgestellt. Bei einer Komponentenauthentifizierung werden auf Basis der von der
anfragenden Komponente gelieferten Kundenanmeldeinformation oder aufgrund der Art der
Anfrage (z. B. offene Aufträge eines Kunden) kundengruppenspezifische bzw. kundenindividuelle
Daten bzw. Funktionen bereitgestellt.
Entsprechend der Ebenen „alle Kunden“, „Kundengruppe“, „ein spezieller Kunde“ lässt sich eine
Hierarchie der personalisierten Portalelemente entwickeln. Öffentliche Portalseiten werden
ausschließlich auf Basis öffentlicher, nicht personalisierter PVK erstellt. Jeder identifizierten
Kundengruppe ist als Grundlage für eine automatisierte Personalisierung eine Rolle zuzuordnen.
Gruppenindividuelle Portalseiten setzen sich aus rollenindividuell personalisierten PVK und öffentlich
zugänglichen PVK zusammen. Kundenindividuelle Portalseiten setzen sich aus den beiden
vorgenannten PVK zusammen. Entsprechend werden die Funktionen einer kundenindividuellen PAK
93
auf Basis kundenindividueller, rollenindividueller oder öffentlicher Funktionen von PSK oder BIK
erstellt. Dies gilt analog für rollenindividuelle und öffentliche PAK. Abbildung 25 zeigt die
entstehende Hierarchie für die Personalisierung und Individualisierung. Die Relation „enthält“ ergibt
sich dabei aus der Komposition von Portalseiten auf der Basis von PVK. Die Relation „nutzt“
bezeichnet die Verwendung von Funktionen der jeweils anderen Komponente. Die Personalisierung
kann durch regelbasierte Mechanismen (siehe auch Kapitel 3.6) umgesetzt werden.
Abbildung 25: Ausprägung der Personalisierung und Individualisierung auf Komponentenebenen
8.5.1 Definition von Prozesszielgruppen
Die Analyse der geforderten Prozesse für ein Vertriebsportal zeigt die Notwendigkeit der
Personalisierung. Die Kombination von Portalsoftware und den integrierten Anwendungen führt zu
drei Ebenen der Portalpersonalisierung, die sich wie folgt darstellen:
− Anwendungsverfügbarkeit: Die Personalisierung nimmt Einfluss auf die Verfügbarkeit von
Anwendungen und damit von Prozessen. Diese werden entsprechend dem Profil des Nutzers durch
die Portalsoftware ein- bzw. ausgeblendet.
− Anwendungen: Die Personalisierung der Anwendung auf Basis einer Rolle beeinflusst das
Verhalten der verfügbaren Anwendungen in Bezug auf die Art der Ausführung von Prozessen und
der Verfügbarkeit von (kundenindividuellen) Informationen. Die Beeinflussung erfolgt in der
Anwendung.
− Gestalt der Portaloberfläche: Die Gestalt der Oberfläche ist auf Basis von vordefinierten bzw.
optional durch den Nutzer änderbaren Parametern, wie z. B. Farben, Gestaltungsschemata,
94
Anordnung von Anwendungen auf der Oberfläche, personalisierbar. Die Beeinflussung erfolgt
durch die Portalsoftware.
Mit Hilfe der drei Personalisierungsebenen können Rollenprofile für Nutzer erstellt werden, die auf
den Ebenen der Personalisierung verschiedene Ausprägungen besitzen. Relevante Rollengattungen im
Portalkontext sind in Tabelle 15 dargestellt. Sie können unternehmensindividuell ausgestaltet werden.
Der Authentifizierungsstatus mit den verbundenen Rollen „authentifizierter Nutzer“ und „anonymer
Nutzer“ stellt die Basis für die Personalisierung bereit. Im Zusammenhang mit Vertriebsprozessen ist
nur authentifizierten Nutzern ein Zugriff auf Transaktionsdienste, wie z. B. Bestellung, Preisangabe
und kundenindividuellen Informationen, möglich. Eine Zuordnung erforderlicher
Authentifizierungsstati für die Prozesse der Prozessarchitektur erfolgt in Anhang H. Die erforderliche
zielgruppenspezifische Ansprache wird durch die Rollengattung „Vertriebszielgruppe“ erreicht.
Hierüber können zielgruppenspezifische Inhalte, wie z. B. Anwendungsbeispiele, bereitgestellt
werden. Die Personalisierung auf Basis der Rollengattung „Herkunftsland/Region“ gestattet die
regionale Ansprache der Kunden mit spezifischen Informationen und ggf. der jeweiligen
Landessprache. Für alle drei Gattungen ist die Anzeige individueller Kataloge ein Hauptmerkmal.
Rollengattung Beispiele für
Rollen-
ausprägungen
Mögliche
Zuordnungs-
kriterien
Auswirkungen
Authentifi-
zierungsstatus
Auth. Nutzer
Anonym. Nutzer
authentifiziert,
anonym
− Statusbezogene Einschränkung des Zugriffs
auf Anwendungen bzw. Prozesse.
− Zugriff auf Transaktionsdienste.
− Verfügbarkeit kundenbezogener
Informationen, kundenindividueller
Katalog und individuelle Konditionen.
Vertriebs-
zielgruppe
Schreinereien
Maler
Distributor
A-Kunde
Unternehmensgrö
ße, Umsatzstatus
(A-, B-, C-
Kunde), Tätig-
keitsfeld, u. a.
− Bereitstellung zielgruppenspezifischer
Anwendungen und Prozesse.
− Zielgruppenspezifische Anpassung der
redaktionellen Inhalte, des Katalogs und der
Konditionen.
Herkunfts-
land/Region
Kunde
Deutschland
Kunde Japan
Kunde Bayern
Kunde Hamburg
Angabe Region,
Angabe Land
− Bereitstellung regionaler Anwendungen
und Prozesse.
− Sprachanpassung des Portals und der
redaktionellen Inhalte, Länder- bzw.
regionale Kataloge und Konditionen.
Tabelle 15: Rollengattungen im Portalkontext
8.6 Modell für die Abbildung von Komponenten
Die in der Anwendungsarchitektur als abstrakt behandelten Komponenten der Schichten PSK und BIK
sind im Rahmen der Bildung einer Architekturinstanz auf Softwaresysteme abzubilden. Die
Funktionalität einer abstrakten Komponente ist in ihrem Umfang durch ein reales System abzubilden.
Eine Abbildbarkeit auf ein Softwaresystem ist möglich, wenn die in der Anwendungsarchitektur
definierten Funktionen durch das System realisierbar sind. Die Abbildbarkeit auf Bestandssysteme
bzw. neu einzuführende Systeme ist im konkreten Fall zu prüfen. Tabelle 16 stellt potenzielle
Varianten der Abbildung der abstrakten Komponenten auf Systemklassen sowie den Grad der Eignung
95
dar. Die in der Tabelle verwendeten Systemklassen entsprechen der im Kapitel 3.4 beschriebenen
softwaretechnischen Unterstützung des Technischen Vertriebs. Als weitere Systemklasse wurde die in
Kapitel 6.4.3.5 beschriebene Produktwahlunterstützungs- und Beratungssoftware in die Tabelle
aufgenommen, die sich zur Zeit an der Übergangsphase zwischen Anwendung und Forschung befindet
(vgl. [Graf 2003]). Portalsoftware kann als System hinzugekauft oder als Eigenentwicklung realisiert
werden. Für die meisten abstrakten Komponenten kommt potenziell die Abbildung auf mehrere
Systemklassen in Frage, die verschiedene Eignungsgrade besitzen. Der Eignungsgrad bestimmt sich
aus den für die Systemklasse typischen Funktionen und dem erforderlichen Anpassungsaufwand. Die
Abbildbarkeit von Komponenten lässt sich am Beispiel der CRK verdeutlichen. Eine maximale
Funktionalität ist durch die Verwendung eines spezialisierten CRM-Systems gegeben. Möglich ist
jedoch die Verwendung der Funktionen eines ERP-Systems, sofern diese die in der
Anforderungsbeschreibung bzw. der Funktionskarte der Komponente definierten Funktionen
unterstützen. Werden nicht alle Funktionen unterstützt, so sind die zu implementierenden Funktionen
der Funktionskarte zu entnehmen.
Abbildung auf reales System/Software
Abstrakte
Komponente
E
ig
en
en
tw
ic
kl
un
g
C
R
M
-S
ys
te
m
E
R
P-
Sy
st
em
D
M
S
B
er
at
er
so
ftw
ar
e
G
ro
up
w
ar
e
Pr
od
uk
td
at
en
ba
nk
Pr
od
uk
tk
on
fig
ur
at
or
Sh
op
-S
ys
te
m
W
eb
-C
M
S
C
om
m
un
ity
-S
of
tw
ar
e
Po
rt
al
so
ft
w
ar
e
V
er
ze
ic
hn
isd
ie
ns
t
W
FM
-S
ys
te
m
E
D
M
S
K
un
de
np
re
is
da
te
nb
an
k
E
ch
tz
ei
tk
om
m
un
ik
at
io
n
C
om
pu
te
r
A
id
ed
S
al
es
S
ys
te
m
C
ol
la
bo
ra
tiv
e-
E
ng
in
ee
ri
ng
W
zg
.
Pr
od
uk
tio
ns
pl
an
un
gs
- u
. S
te
ue
ru
ng
ss
ys
t.
SHOP + – – – ○ – ○ ○ + ○ – – – – – – – – – –
BER + ○ – – + – – ○ ○ ○ – – – – – – – – – –
DM ○ ○ ○ + – ○ – – – – – – – – + – – – – –
WFM ○ ○ ○ – – ○ – – – – – – – + – – – – – –
KDM – + + – – – + – ○ – – – – – – – – – – –
GPW – – – ○ – + – – – – ○ – – – ○ – – – ○ –
CRK – + + – – – – – – – – – – – – ○ – ○ – –
KONF ○ – – – ○ – – + – – – – – – – – – – – –
CM ○ – – ○ – – – – – + – – – – – – – – – –
CMK ○ ○ – – – – – – – – + – – – – – ○ – – –
AUTH ○ – – – – – – – – – – + + – – – – – – –
Portalsoftware + – – – – – – – – – – + – – – – – – – –
ERK ○ – + – – – – – – – – – – – – – – – – ○
Legende: Eignung: + gut, ○ bedingt, – gering bzw. Eignung im Einzelfall;
Abkürzungen: Syst. System, Wzg. Werkzeug.
Tabelle 16: Komponentenabbildungsmatrix mit Bewertung der Abbildung auf Systemklassen
9 Kommunikationsarchitektur für Portale
9.1 Eigenschaften und Übersicht
Zwischen den Komponenten in den verschiedenen Ebenen des Schichtenmodells entsteht während des
Betriebs einer Instanz des Architekturmodells ein Kommunikationsbedarf. Zu den Eigenschaften einer
portalspezifischen Kommunikationsarchitektur gehört die Beschreibung der Kommunikation der
Komponenten der Anwendungsarchitektur mit ihren Schnittstellen und den Daten aus der
Datenarchitektur. Dabei sind die für eine heterogene Systemlandschaft in Frage kommenden
Datenformate und Transportmöglichkeiten sowie wie die ggf. notwendigen Transformationen der
Daten zu beschreiben. Die auszutauschenden Daten (Stamm- und Bewegungsdaten, Präsentationen)
ergeben sich aus der Komponenten- und Datenarchitektur. Bei diesem Austausch sind die
Transporteinheit des Datums und die Strukturierung des Inhalts zu unterscheiden [Kelkar 2003]. Für
die Beschreibung der Kommunikationsarchitektur wird zunächst das Schnittstellenmodell mit den
Kommunikationspfaden in einer Übersicht dargestellt und hieraus die Komponentenintegrationsmuster
für Portale als Beschreibung der Transportmöglichkeiten abgeleitet. Im Anschluss werden für die
Strukturierung der ausgetauschten Daten anwendungsunabhängige und anwendungsbezogene
Datenformate untersucht. Die Komponentenintegrationsmuster und Datenformate werden in Bezug
auf ihre Eignung bewertet. Abschließend werden die für den Datenaustausch im Portal erforderlichen
Methoden zur Transformation der Daten betrachtet. Abbildung 26 stellt die Bestandteile der
Kommunikationsarchitektur zusammengefasst dar.
Integrationsmuster
Datenformat
DatumTransformation Transformation
Komponente
K1
Komponente
K2
Bestandteile der Kommunikationsarchitektur
Schnittstelle
Abbildung 26: Bestandteile der Kommunikationsarchitektur
9.2 Schnittstellenmodell für Portale
Abgeleitet aus der impliziten Darstellung der Kommunikation in der Daten- und
Anwendungsarchitektur zeigt Abbildung 27 eine Gesamtsicht in Form eines UML-
Komponentendiagramms auf die Schnittstellen und die Kommunikation zwischen den Komponenten
des Architekturmodells. Die Komponenten sind entsprechend des Schichtenmodells in den drei
Ebenen PAK, PSK und BIK angeordnet. Die Schnittstellen der Komponenten sind entsprechend des
Komponentenmodells dargestellt. Die Verwendung von Schnittstellen einer Komponente durch eine
weitere Komponente ist als solche in der Abbildung notiert. Neben der Verwendung der Schnittstellen
wird als weitere Assoziation die Referenzierung zwischen den PAK durch den Stereotyp
«referenziert» dargestellt. Die Abfragen der Autorisierung der Portalnutzer für die jeweilige PAK sind
durch den Stereotyp «Autorisierung» abgebildet. Der Aufruf der Portalumgebung zur Erzeugung der
Darstellung (Rendering) der PAK ist durch Assoziationen mit dem Stereotyp «Rendering» versehen.
Die Schnittstellen werden in Anhang F – Funktionskarten für Komponenten formal beschrieben.
97
Abbildung 27: Schnittstellenmodell mit Kommunikationspfaden
98
9.3 Entwicklung von Komponentenintegrationsmustern für Portale
Muster (Patterns) erlauben unabhängig von ihrer konkreten technologischen oder produktspezifischen
Ausprägung ein definiertes Verständnis der abgebildeten Funktionalität. Sie beschreiben ein
wiederkehrendes Kernproblem und die zugehörige Lösung [Alexander et al. 1977]. Auf dieser Basis
kann bei der Bildung einer Instanz anhand der Kommunikationsanforderungen das Integrationsmuster
und in einem zweiten Schritt die konkrete Technologie gewählt werden. Dabei ergeben sich die
Anforderungen an die Kommunikation aus der Funktion der Komponenten im Gesamtmodell und der
Zugehörigkeit zu einer Schicht. Entsprechend der Anforderungen wird das Integrationsmuster aus den
einsetzbaren Mustern ausgewählt. Hierfür werden zunächst Muster definiert, ihre Eigenschaften
beschrieben und die Eignung auf der Ebene der Integration von Schichten bewertet. Eine bewertete
Zuordnung zu den auszutauschenden Daten im Architekturmodell erfolgt in Kapitel 9.5.
Für die Integration von Portalkomponenten werden die folgenden Muster definiert:
Muster M1: HTTP-Integration: Das Muster nutzt die Mechanismen des HTTP-Protokolls zur
Integration zweier Komponenten. Dabei tritt eine Komponente als HTTP-Server auf, die weitere
Komponente als Client. Datentransfers können entsprechend des Client/Server-Schemas
ausschließlich von dem Client initiiert werden. Über dieses Verfahren können Daten bidirektional
ausgetauscht werden. Der Server liefert Daten im Body der HTTP-Nachricht. Der Client übermittelt
über GET- und POST-Methoden Daten an den Server. Die Übermittlung erfordert die Definition eines
Formats, in dem die Daten übertragen werden [Ciber 2004]. Die Methodik eignet sich im besonderen
Maße für die Integration von Komponenten, die eine HTML-Darstellung erzeugen oder Dokumente
bereitstellen. Bei der Nutzung der HTML-Darstellung wird von der Client-Komponente ein
interaktiver Web-Nutzer vorgetäuscht.
Muster M2: Synchrone Middleware: Die Integration über synchrone Middleware stellt eine
verteilungstransparente Verbindung zwischen den involvierten Komponenten zur Verfügung und ist
damit für Komponenten geeignet, die auf dem gleichen System residieren. Die Verwendung einer
Server-Komponente erfolgt durch den Aufruf eines lokalen Stellvertreters der Server-Komponente
(Stub). Der Stub enthält alle notwendigen Mechanismen zur Codierung des Aufrufs, zum Finden des
Servers und zur Kommunikation mit dem Server. Die Daten werden dabei in eine
plattformunabhängige Zwischenrepräsentation überführt (Marshalling). Serverseitig wird ein
Unmarshalling zur Transformation in die plattformspezifische Darstellung der Daten durchgeführt.
Eventuell notwendige semantische Transformationen der Daten, die für eine Integration notwendig
sind, müssen durch die Komponenten selbst realisiert werden. Die Middleware-Technologien sind
prozedural (Remote Procedure Call) bzw. objektorientiert (Remote Object) angelegt.
Charakterisierend ist die Verwendung einer plattformunabhängigen Beschreibungssprache für die
Schnittstellen, welche die Grundlage für eine automatisierte Erzeugung der Stubs ist. Das Muster
erfordert für seinen Einsatz zwei Komponenten, von der mindestens eine eine öffentliche Schnittstelle
anbietet, sowie ein gemeinsames semantisches Verständnis der Daten. Das Muster kann u. a. mit den
Technologien Java-RMI [Wutka 2001], CORBA [Slama et al. 1999], DCE-RPC [Shirley et al. 1994],
RFC/CPI-C [Angeli 2003], Web Services [Hauser und Löwer 2003] bzw. WSRP und JSR 170 (siehe
Kapitel 3.7) realisiert werden.
Muster M3: Asynchrone Middleware: Die Integration über asynchrone Middleware (MOM –
Message Oriented Middleware) basiert auf dem Austausch von Nachrichten. Die Kopplung erfolgt
dabei lose über Nachrichten, die über Nachrichtenwarteschlangen (Queues) ausgeliefert werden.
99
MOM ist als eine Erweiterung des RPC-Paradigmas zu sehen, die eine asynchrone Verarbeitung der
Nachrichten erlaubt und damit ein nicht blockierendes Verhalten der zu koppelnden Komponenten
ermöglicht. Die Nachrichten können zudem an mehrere Empfänger adressiert werden [Linthicum
2000]. Asynchrone Middleware umfasst in der Regel Persistenzverfahren als Schutz vor
Nachrichtenverlust [Keller 2002]. Dieses Muster kann mit Produkten wie z. B. IBM WebSphere MQ,
Microsoft MSMQ, Java JMS realisiert werden.
Muster M4: Message Broker: Message Broker tauschen Nachrichten zwischen zwei Komponenten
aus. Sie werden über eine API oder Middleware an Komponenten angebunden. Bei einem Aufruf der
Schnittstelle werden die übergebenen Daten in eine Nachricht transformiert, die vom Message Broker
weitergeleitet wird. Dieser besitzt die Möglichkeit, Nachrichten zu transformieren und Regeln bei der
Verarbeitung bzw. in Bezug auf die Weiterleitung anzuwenden [Linthicum 2000]. Der Fluss der
Nachrichten ist somit steuerbar und die Inhalte der Nachrichten können bereits während der
Weiterleitung verändert werden. Hierdurch kann eine ggf. zur Verarbeitung notwendige
Transformation der Daten durch die Komponenten entfallen. Message Broker können mit den
Komponenten über einen Bus kommunizieren oder einen zentralen Knotenpunkt bilden (Hub-and-
Spoke-Architektur). Das Muster erfordert für seinen Einsatz zwei Komponenten, von der mindestens
eine eine öffentliche Schnittstelle anbietet, Schnittstellen oder Adapter zum Message Broker sowie
Transformationsregeln für die Nachrichten [Xin 2002]. Im Bereich der Message Broker existieren
keine übergreifenden Standards für Nachrichten [Hildebrand 2003]. Dieses Muster kann mit
Produkten wie z. B. Microsoft BizTalk oder Webmethods realisiert werden.
Muster M5: Datenaustausch über persistenten Speicher: Das Muster realisiert einen
Datenaustausch über ein auf einem persistenten Speicher abgelegtes Dokument. Es erfordert eine
exportierende Komponente, die ein Dokument in einem definierten Format ablegt, einen Speicher und
eine importierende Komponente, die das Dokument einliest. Für die Erzeugung des Dokuments und
die Überführung in eine interne Darstellung sind während des Imports Transformationen notwendig.
Die Definition des Dokuments legt dabei die Semantik der Daten fest. Der Austausch erfordert ein
Wissen über den Austauschzeitpunkt oder alternativ eine Benachrichtigung der importierenden
Komponente.
Muster M6: Integration über DBMS: Die Integration erfolgt über die Nutzung einer gemeinsamen
Datenbank durch zwei Komponenten. Der Zugriff auf die Datenbanken kann dabei nativ oder
mittelbar durch abstrahierende Verteilungsdienste, wie z. B. ODBC, erfolgen. Der konkurrierende
Zugriff auf die gemeinsame Ressource Datenbank erfordert die Sicherstellung der ACID-
Eigenschaften durch das DBMS [Gray und Reuter 1993]. Das Muster setzt den Zugriff auf ein DBMS
und ein gemeinsames Verständnis des Schemas der betroffenen Datenbanken voraus. Es gestattet eine
Echtzeitintegration der Komponenten. Die Definition einer dezidierten Client- oder Server-
Komponente ist durch die Möglichkeit des konkurrierenden Zugriffs nicht erforderlich.
Muster M7: PVK-Notifikation: Die Notifikation ist ein von der Portalsoftware angebotener
Nachrichtenmechanismus. Die PVK der aktuellen Portalseite können Nachrichten an andere Portlets
senden. Die Nachrichten bestehen aus einem Name/Wert-Paar. Beim Neuaufbau der Portalseite durch
die Portalsoftware werden alle eingebetteten PVK, welche Nachrichten über den Namen abonniert
haben, über den Wert informiert (vgl. [Highmoor et al. 2003]). Auf diese Weise können einzelne
Daten oder einfache Datenstrukturen auf der Ebene der PVK und damit zwischen den zugehörigen
PAK ausgetauscht werden. Das Muster erfordert die Elemente nachrichtenerzeugende PVK,
100
nachrichtenvermittelnde Portalsoftware und nachrichtenkonsumierende PVK (Abonnenten). Für die
Anwendung des Musters ist die Definition eines gemeinsamen Datenformats notwendig. Das Muster
eignet sich in besonderer Weise für die Herstellung von Kontexten zwischen unabhängigen PVK. So
kann eine PAK, die ein Produkt darstellt, die Artikelnummer als Nachricht an andere PVK senden.
Diese können auf Basis dieser Information ihren Inhalt oder ihre Funktionen in Bezug zu diesem
Artikel anpassen.
9.4 Datenformatmodell für den Datenaustausch in Portalen
Haupterfordernis des Datenaustauschs ist die Definition eines gemeinsamen Datenformats, das die
beteiligten Komponenten verarbeiten können. Ein Datenformat definiert die Struktur und die
Eigenschaften der Datenelemente [Linthicum 2000]. Für die Verarbeitung ist ein Wissen über den
Aufbau und die Semantik des Formats notwendig. Es ist ein Format zu verwenden, das die
Erfordernisse beider Komponenten abdeckt. Im Folgenden werden die im Kontext des
Architekturmodells einsetzbaren Datenformate untersucht und in Bezug auf ihre Eignung für den
Einsatz für den Datenaustausch bewertet.
9.4.1 Interne und externe Datenstrukturen
Die Datenstrukturen von Programmiersprachen weisen sprachabhängige Paradigmen sowie
Unterschiede in der Anwendung und in der Syntax auf. So unterscheiden sich objektorientierte
Sprachen sowohl untereinander als auch gegenüber prozeduralen Sprachen erheblich. Interne
Datenstrukturen sind daher nur zwischen Implementierungen mit der gleichen Programmiersprache
auszutauschen. Der Einsatz von Middleware gestattet einen sprachübergreifenden Austausch. Dies
geschieht jedoch auf Basis einer Schnittstellendefinition, welche die gemeinsamen Fähigkeiten der
einsetzbaren Programmiersprachen berücksichtigt. Gemeinsame Mindestkonstrukte werden z. B. in
der CORBA Interface Definition Language (IDL) oder dem Common Type System (CTS) definiert.
Die Organisationsform einer Datenstruktur orientiert sich primär an den Operationen, die auf den
enthaltenen Daten auszuführen sind. Die Datenstruktur ist so gewählt, dass diese Operationen effizient
ausgeführt werden [Ottmann und Widmayer 1993]. Ist die zu transferierende Datenstruktur einer
einzubindenden Portalkomponente nicht in der Schnittstellendefinition der Middleware abbildbar, so
muss diese in eine externe Datenstruktur transformiert werden. Wird eine Datenstruktur ausschließlich
für den Datentransfer verwendet, so muss sie auf der Senderseite in eine Zwischenstruktur abgebildet
bzw. auf Empfängerseite in die interne Datenstruktur der Komponente zurücktransformiert werden.
Die Standardisierung einer Datenstruktur für den Austausch über eine Middleware gestattet eine
Wiederverwendung. Eine Standardisierung von Strukturen bzw. Objekten über den innerbetrieblichen
Rahmen hinaus, wie z. B. die Business Objects der OMG (vgl. [Eeles und Sims 1998]), war bisher
nicht erfolgreich. Der Austausch von Datenstrukturen erfolgt bei den Portalintegrationsmustern M2,
M3 und M4.
9.4.2 Allgemeine Dokumentenformate
Allgemeine Dokumentenformate müssen für die Realisierung eines Datenaustauschs instanziert
werden. Das hieraus entstehende Dokumentenformat ist auf den Einsatzzweck der Instanz beschränkt.
Der Austausch von Dokumenten in allgemeinen Dokumentenformaten kann über eine Datei oder über
101
eine entsprechende Datenstruktur, die einen String trägt, erfolgen. Die Formate sind damit nicht auf
den Austausch über Dateien beschränkt.
CSV (Comma Separated Values, Character Separated Values): CSV verwendet eine ASCII-
Textdatei als Träger der Daten. Das Format ist auf die Übermittlung mehrerer, gleich strukturierter
Datensätze ausgelegt. Die einzelnen Werte eines Datensatzes in der Datei werden durch Marker
(Komma, Semikolon, Tab etc.) getrennt. Die Datensätze untereinander werden durch ein Carriage
Return bzw. Line Feed abgegrenzt. Der erste Datensatz der Datei kann optional die Namen der
Datenfelder enthalten. Die Einfachheit des Formats ist ein Grund für seine weite Verbreitung für den
Austausch von Datenbanken. CSV ist für die Portalintegrationsmuster M1 bis M5 und M7 geeignet.
Extensible Markup Language (XML): XML legt als ein Anwendungsprofil von SGML ([ISO
8879]) eine Klasse von Datenobjekten (XML-Dokumente) fest. Durch den Standard wird darüber
hinaus teilweise auch das Verhalten von Softwareanwendungen zur Verarbeitung von XML definiert
[W3C-XML 2004]. XML basiert auf einer strukturellen Auszeichnung der in den Dokumenten
enthaltenen Daten durch attributierbare Tags. Entsprechend der Definition von XML können die
Strukturen geschachtelt werden. Wohlgeformte Dokumente entsprechen der XML-Syntax. Auf Basis
von XML lassen sich eigene XML-Anwendungen definieren. Diese weisen eine für den
Anwendungszweck festgelegte Dokumentenstruktur auf, die mittels der Document Type Definition
(DTD) festgelegt wird. Dokumente, die gegen die DTD der Anwendung validiert werden können und
wohlgeformt sind, werden als gültig bezeichnet. Als Weiterentwicklung der DTD beschreibt ein
XML-Schema (XSD) eine Anwendung nicht nur strukturell, sondern erlaubt als wesentliche
Erweiterungen auch eine Definition der zu verwendenden Datentypen und eine Vererbung. Um die
eigentliche Spezifikation von XML formieren sich weitere unterstützende Standards für die
Verlinkung (XLINK), Transformation (XSLT), die seitenbasierte Ausgabe (XSL-FO) und andere
spezialisierte Standards. XML-Anwendungen sind als Datenformat für alle Portalintegrationsmuster
(M1 bis M7) geeignet.
9.4.3 Standards für den Austausch von Katalogen und Geschäftsdokumenten
Standards für Geschäftsdokumente stammen aus den Erfordernissen des zwischenbetrieblichen
Informationsaustausches. Zu den für das Architekturmodell zu betrachtenden Geschäftsdokumenten
gehören insbesondere Kataloge und transaktionsbezogene Dokumente, wie z. B. Angebot und
Bestellung. Im Folgenden werden die für Portale relevanten Standards dargestellt.
BMEcat ([Schmitz et al. 2001]): Ziel der Entwicklung des BMEcat-Formats ist die Schaffung eines
offenen Standards für den Austausch von Produktkatalogen. Fokus der Entwicklung waren der
Austausch von Katalogen zwischen Lieferanten und beschaffenden Organisationen sowie der Transfer
von Katalogen in Shop-Systeme. BMEcat verwendet als zugrunde liegendes Format XML, das bei
Bedarf erweitert werden kann. Das Format ist als XML-Schema mit einer zugehörigen semantischen
Spezifikation definiert. Die Einbindung zusätzlicher produktbezogener Medien, wie Bilder,
Zeichnungen und Dokumente, ist vorgesehen. BMEcat definiert Dokumente für den Transfer von
ganzen Katalogen, Artikel-Updates und Preis-Updates. Der Einsatz von Update-Formaten vermindert
den Aktualisierungsaufwand für große Kataloge. Durch den mit der Implementierung in zahlreichen
Softwareprodukten hohen Verbreitungsgrad eignet sich BMEcat im besonderen Maße für die
Verwendung als Format für den Austausch von Produktdaten in Form von Katalogen im
Architekturmodell.
102
openTRANS ([Kelkar et al. 2001]): openTRANS definiert einen Standard für den Austausch
standardisierter Geschäftsdokumente auf Basis von XML. Es ist eine Ergänzung von BMEcat und
verwendet identische Felder sowie Strukturen mit gleichen Bedeutungen und Regeln. openTrans stellt
Formate für die folgenden Geschäftsdokumente bereit: Lieferavis, Rechnung, Auftrag,
Auftragsänderung, Auftragsbestätigung, Angebot, Wareneingangsbestätigung und
Angebotsanforderung.
UN/EDIFACT ([ISO 9735], [DIN 16557-3], [Grigo 2003]): United Nations Directories for Eletronic
Data Interchange for Administration, Commerce and Transport (UN/EDIFACT) ist ein durch ISO und
DIN normierter Standard für den Austausch von Geschäftsdokumenten. UN/EDIFACT ist auf den
zwischenbetrieblichen Austausch von Geschäftsdokumenten fokussiert. Aus dem Standard heraus
haben sich branchen- und anwendungsspezifische Untermengen (Subsets) entwickelt. Das Format
verwendet Nachrichten für den Austausch von Dokumenten. Der Einsatz ist über eine
nachrichtenvermittelnde Infrastruktur, über Datei (asynchroner Batch) und über Internet möglich.
UN/EDIFACT enthält neben Nachrichten für Geschäftsdokumente, wie z. B. Angebot, Bestellung,
Lieferschein, Rechnung, Zahlungsavis auch eine Nachricht für die Übermittlung einer Preisliste bzw.
eines Katalogs (price/sales catalogue, PRICAT).
xCBL ([xCBL 2004]): xCBL basiert auf der Semantik von EDI und bildet einen Migrationspfad für
EDI-Anwender zu XML-basierten Technologien. xCBL unterstützt eine Vielzahl von
Geschäftsdokumenten wie Angebot, Bestellung, Lieferschein und Rechnung bis zu Forecast-
Dokumenten. Im Bereich Katalogdatenaustausch unterstützt xCBL auch den Content-
Erstellungsprozess.
cXML ([cXML 2003]): cXML ist eine von Ariba initiierte Spezifikation des Austauschs von
Geschäftsdokumenten. Wesentliche Dokumententypen sind Kataloge, Punch-Outs (interaktive
Einbindung externer Informationen bzw. eines Warenkorbs in ein Procurement-System) und
Bestellungen. Dokumente verwenden je nach Typ eine Ein-Weg-Kommunikation oder ein
Request/Response-Schema.
Die Initiativen RosettaNet [RosettaNet 2004] und ebXML [Eisenberg und Duane 2001] fokussieren
den zwischenbetrieblichen Bereich. Aufgrund der mit diesen Initiativen verbundenen Merkmale, wie
z. B. eigene Kommunikationsschemata, eignen sie sich nur sehr eingeschränkt für die innerbetriebliche
Kopplung von Portalkomponenten und werden daher nicht näher betrachtet.
9.5 Bewertung der Einsatzmöglichkeit im Architekturmodell
Im Folgenden werden die Einsatzmöglichkeiten der Integrationsmuster auf Schichtenebene sowie die
Eignung der Kombinationen von Integrationsmustern und Datenformaten für wesentliche
Datenklassen des Datenmodells bewertet.
Die Integrationsmuster weisen verschiedene Eigenschaften auf, die ihre Eignung für die Integration
von Komponenten beschränken. Hierbei spielt insbesondere die Fähigkeit zur Integration entlang der
definierten Schichten eine große Rolle. In Tabelle 17 wird für die Gegenüberstellung der Muster das
jeweilige Funktionsprinzip zunächst grafisch dargestellt. Eine grundlegende Eigenschaft bildet die
Synchronisierung zwischen Initiator und Empfänger. Im Falle einer synchronen Integration werden die
Programmabläufe des Initiators und des Empfängers während des Aufrufs synchronisiert. Der Initiator
erhält für seinen Aufruf eine direkte Rückmeldung vom Empfänger. Erfolgt der Aufruf asynchron, so
103
übergibt der Initiator die Anfrage an den Kommunikationsmechanismus des Integrationsmusters, von
dem der Empfänger die Daten unabhängig vom Initiator erhält.
Ferner wird die Eignung für die Integration von Komponenten innerhalb der gleichen bzw. zwischen
Schichten in einer Untertabelle pro Integrationsmuster bewertet und abschließend die besonderen
Eigenschaften der jeweiligen Muster untersucht.
Die Tabelle zeigt, dass die Muster jeweils für spezielle Kombinationen der zu integrierenden
Schichten geeignet sind. Die spezifischen Eigenschaften der Muster sind bei der Bildung einer Instanz
im Rahmen einer Implementierung zu berücksichtigen.
Grafische Darstellung Name und Eignung Bewertung
PAK
PSK/BIK
HTTP
Muster M1: HTTP-Integration
Eigenschaft: synchron
Von Eignung
Integration PAK PSK BIK
PAK ○ / /
PSK ● ○ ○ Na
ch
BIK ● ○ ○
(+) Integration darstellungserzeugender
Komponenten.
(+) Einfachheit: Kein oder geringer Eingriff in
die zu integrierende Komponente.
(–) Anpassung für den Portalkontext
notwendig. Aufwändige Anpassung der
Darstellung. (vgl. Kap. 9.6.2).
(–) Fehlende Stabilität gegenüber
Änderungen an der Darstellung der
integrierten Komponente.
Muster M2: Synchrone Middleware
Eigenschaft: synchron
Von Eignung
Integration PAK PSK BIK
PAK ● / /
PSK ● ● ●Na
ch
BIK ● ● ●
(+) Verteilungstransparenz für die involvierten
Komponenten.
(+) Anpassungen der Datenformate zwischen
Komponenten auf verschiedenen
Plattformen.
(+) Hoher Wiederverwendungsgrad be-
stehender Schnittstellen.
(–) Geringe Eignung für große Datenmengen
und Übertragung von Dokumenten.
(–) Geringe Fehlertoleranz.
PAK
PSK/BIK
asynchr. Middleware
Q U E U E
Muster M3: Asynchrone
Middleware (Message Queues)
Eigenschaft: asynchron
Von Eignung
Integration PAK PSK BIK
PAK ○ / /
PSK ● ○ ●Na
ch
BIK ● ● ●
(+) Verteilungstransparenz für die involvierten
Komponenten, Möglichkeit zur Last-
balancierung.
(+) Anpassungen der Datenformate zwischen
Komponenten auf verschiedenen
Plattformen.
(+) Fehlertoleranz im Fall der Nicht-
verfügbarkeit.
(–) Geringe Eignung für große Datenmengen
und Übertragung von Dokumenten.
PSK/BIK
Message
Broker
PAK/PSK/BIK
Muster M4: Message Broker
Eigenschaft: asynchron
Von Eignung
Integration PAK PSK BIK
PAK ○ / /
PSK ○ ● ●Na
ch
BIK ○ ● ●
(+) Hoher Wiederverwendungsgrad
bestehender Schnittstellen zum Broker.
(+) Verteilungstransparenz für die involvierten
Komponenten, Möglichkeit zur Last-
balancierung.
(+) Anpassungen auf Datenebene zwischen
Komponenten möglich.
(–) Geringe Eignung für kleine IT-Umge-
bungen mit geringem Wiederver-
wendungsgrad der Schnittstellen.
104
Grafische Darstellung Name und Eignung Bewertung
PSK/BIK
gem.
Speicher
PAK/PSK/BIK
Muster M5: Datenaustausch über
persistenten Speicher
Eigenschaft: asynchron
Von Eignung
Integration PAK PSK BIK
PAK ○ / /
PSK ● ○ ●Na
ch
BIK ● ● ●
(+) Austausch großer Datenmengen und
Dokumenten mit geringer Änderungs-
häufigkeit.
(+) Einfachheit der Anbindung (Schreib-/
Leseoperation auf gemeinsamen Speicher).
(–) Neue Daten stehen nur zu definierten
Zeitpunkten zur Verfügung bzw.
Benachrichtigung erforderlich.
(–) Aufbereitung eines Austauschdokuments
notwendig.
PAK/PSK/BIK
PSK/BIK
DB
Muster M6: Datenintegration über
DBMS
Eigenschaft: synchron
Von Eignung
Integration PAK PSK BIK
PAK ● / /
PSK ○ ● ●Na
ch
BIK ○ ● ●
(+) Enge Integration der Komponenten.
(+) Datenbankschema entspricht der
Schnittstelle.
(+) Eignung für große Datenmengen mit
hoher Änderungshäufigkeit.
(–) Aufwändige Fehlerbehandlung.
(–) Gemeinsamer Zugriff auf ein DBMS
notwendig.
(–) Entkopplung der Systeme wird nur im Fall
der Duplizierung der Daten erreicht.
Muster M7: PVK-Notifikation
Eigenschaft: asynchron
Von Eignung
Integration PAK PSK BIK
PAK ● / /
PSK ○ ○ ○Na
ch
BIK ○ ○ ○
(+) Eignung für kleine Datenmengen.
(+) Einfache Nutzung über Abonnement der
Nachrichten.
(–) Anwendungsbeschränkung auf Kom-
munikation zwischen PVK-PVK und
Portalsoftware-PVK.
(–) Nur Austausch einfacher String-Elemente.
Legende: Eignung für die Kopplung ● geeignet, ○ nicht geeignet, / nicht zutreffend;
Bewertung + positiv, – negativ.
Tabelle 17: Integrationsmuster für Portale
Nachdem die grundlegende Eignung für die Integration entlang des Schichtenmodells bewertet wurde,
müssen davon ausgehend die Einsatzmöglichkeiten im Kontext der auszutauschenden Daten und deren
Formate betrachtet werden.
Die vorgestellten Integrationsmuster, Daten- und Dokumentenformate eignen sich in verschiedenem
Maße für die Kommunikation zwischen den Komponenten des Architekturmodells. Der Einsatz ist
abhängig von der konkreten Projektumgebung und -strategie. Tabelle 18 fasst die Muster und Formate
in einer Übersichtstabelle zusammen und bewertet ihre Verwendung für wesentliche Datenklassen des
Architekturmodells. Einige Dokumente, wie z. B. Dokumente der Unternehmensinformation, werden
in den jeweiligen spezialisierten Formaten, wie z. B. PDF, zwischen den Komponenten transferiert.
Diese werden in der Darstellung nicht berücksichtigt, da im Portal keine Verarbeitung der in den
Dokumenten enthaltenen Daten stattfindet. Der Zugriff auf die Komponente AUTH kann
grundsätzlich mit verschiedenen Methoden (insbesondere M2, M3, M4, M6) erfolgen. Als Standard
hat sich jedoch das Lightweight Directory Access Protocol (LDAP) etabliert [Klünter und Laser
2003].
105
Daten Bewertung der Eignung
Datenformat
Bewertung der
Eignung der
Integrationsmuster
Datenklasse
Datum
D
at
en
st
ru
kt
ur
H
T
M
L
-D
ar
st
.
C
SV
X
M
L
B
M
E
ca
t
O
pe
nT
ra
ns
U
N
/E
D
IF
A
C
T
X
C
BL
cX
M
L
1 2 3 4 5 6
Darstellung SHOP-D1-5,-D7,
KONF-D1, BER-
D1, CMK-D1,-D2
WFM-D1-3, CM-
D1,-D8,-D9, GPW-
D1-3
/ + / ○ / / / / / + + + / / /
Kataloge KDM-D1, -D2 ○ / ○ ○ + / ○ – – – ○ ○ + + –
Angebotsanforderung SHOP-D6, CRK-
D1 + / ○ ○ / + ○ ○ ○ – + + – ○ –
Kundenpreis CRK-D1 + – – ○ - + ○ ○ ○ – + + – ○ –
Verfügbarkeit CRK-D2, ERP-D2 + / – ○ - + ○ ○ ○ – + + ○ + –
Angebot CRK-D3 ○ / – + / + ○ ○ ○ ○ + + - + –
Materialstamm ERP-D1 + + / ○ / ○ ○ ○ – + + ○ + +
Kundenstamm CRK-D4 + / – + / / / / / – + + ○ + –
Kundenauftragsstatus
Auftragshistorie
CRK-D6, ERP-D3
+ / – + / – ○ ○ ○ ○ + + – –
Stückliste CRK-D8 ○ / + + / / / / / ○ + + + + –
Konfiguration KONF-D2 + / + + ○ ○ ○ ○ ○ ○ + + – + +
Referenz CM-D2-7, CM-D10 + + – + / / / / / + + – – – +
Legende: + sehr gute Eignung, ○ gute Eignung, – geringe Eignung, / keine Eignung.
Tabelle 18: Bewertung der Eignung von Datenformaten und Integrationsmuster für wesentliche
Datenklassen
9.6 Entwicklung von Adaptions- und Transformationsmethoden
Die Anwendungsarchitektur des Architekturmodells für Portale verbindet verschiedenartige
Komponenten, die partiell nicht für einen Austausch von Stamm- und Bewegungsdaten oder
Präsentationen entworfen wurden. Die Repräsentation der auszutauschenden Daten bzw. Dokumente
kann in dem intern verwendeten Format der Quell- und/oder Zielkomponente oder in einem
Drittformat erfolgen. Das Drittformat muss senderseitig generiert bzw. beim Empfänger transformiert
werden. Eine Sicherstellung der gemeinsamen Interpretierbarkeit der Datendarstellung (z.B. Little
Endian, Big Endian) muss bereits über die Mechanismen der Integrationsmuster erfolgen. Die
Transformationen beschränken sich aus diesem Grund auf die Veränderung der Struktur der Daten.
Die Adaption selektiert benötigte Daten aus den übermittelten strukturierten Daten und passt die
Informationen gegebenenfalls an. In [Lindwood und Minter 2004] und [Puschmann 2004] werden
grundlegende Adaptions- und Transformationsansätze beschrieben. Die nachfolgend dargestellten
Verfahren berücksichtigen die Komponentenarchitektur und den Kontext des Architekturmodells.
106
9.6.1 Verfahren zur Transformation von Datenstrukturen
Bei der Verwendung von Integrationsmustern, die die übermittelten Datenstrukturen für Hochsprachen
direkt zugänglich machen, ist eine Transformation in die jeweilige interne Datendarstellung der
Zielkomponente zu gewährleisten. Eine Transformation kann potenziell durch Programmcode in der
Quellkomponente durchgeführt werden. Es ist jedoch davon auszugehen, dass eine Zielkomponente in
Bezug auf den Zugriff auf eine gekapselte Schnittstelle einer Quellkomponente leichter angepasst
werden kann.
9.6.2 Verfahren zur Adaption von HTML auf Präsentationsebene
Die Integration auf der Präsentationsebene geht von Systemkomponenten aus, die über eine
eigenständige HTML-Präsentationsgenerierung verfügen. Dies entspricht dem Integrationsmuster M1.
Die Integration in ein Portal erfordert eine Anpassung der Präsentation. Die Anpassung kann dabei auf
der Seite der Quell- oder der Zielkomponente bzw. verteilt auf beide erfolgen. Erforderlich für die
Darstellung in einer PVK ist ein HTML-konformes Fragment, das nur für den HTML-Body gültige
Tags enthalten darf. Ein ggf. vorhandenes komponentenspezifisches Style Sheet muss entfernt werden
bzw. durch Styles des Portals ersetzt werden.
Die visuelle Integration mehrerer Komponenten aus den Ebenen PSK und BIK erfordert eine
Zusammensetzung von HTML-Fragmenten zu neuen Präsentationen, ggf. auch unter Weglassung von
Fragmenten. Bei Quellkomponenten, die über Template-Mechanismen verfügen, kann dies durch die
Anpassung der Templates erreicht werden. Dieses Vorgehen ist jedoch nur möglich, wenn die
Präsentation der Quellkomponente nicht anderweitig genutzt wird.
Im Folgenden werden die für die Adaption notwendigen Verfahren vorgestellt. Die Verfahren
Maskierung, Selektion und Aggregation sind nur für Komponenten geeignet, die über einen Template-
Mechanismus zur Generierung der Präsentation verfügen. Bei monolithischen Systemen ist ein
Eingriff auf dieser Ebene nicht möglich. Ein Beispielvorgang für den Ablauf einer Adaption mit den
nachfolgenden Verfahren wird in Anhang I dargestellt.
9.6.2.1 Adaptionsmethodik: Maskierung
Die Maskierung von Informationen ist bei jeder Integration auf Präsentationsebene zur Entfernung
aller Informationen außerhalb des -Tags notwendig. Das -Tag selber muss
ebenfalls entfernt werden. Hierzu sind die störenden Informationen über Zeichenkettenoperationen in
der PAK zu entfernen. Darüber hinaus kann es erforderlich sein, bestimmte Bereiche der Darstellung
des zu integrierenden Systems auszublenden. In die Templates der integrierten PSK oder BIK wird
eine Maskierungsinformation eingefügt, die gegen die HTML-Syntax eine Kommentarfunktion
darstellt. Die Verwendung eines HTML-Kommentars gestattet eine Maskierung von Passagen für die
Portalanwendung. Hierdurch wird die ursprüngliche Darstellung des Systems bei direktem Aufruf
ohne Portal nicht verändert. Mit dieser Methodik lassen sich beliebige Bereiche, die von der PAK vor
der Darstellung über Zeichenkettenoperationen entfernt werden müssen, auszeichnen. Der Marker für
die Auszeichnung ist dabei, mit Ausnahme eines gültigen HTML-Tags, beliebig zu wählen
(Abbildung 28).
107
Maskierter Text.
Abbildung 28: Maskierung mit Tags
9.6.2.2 Adaptionsmethodik: Selektion
Analog zum Verfahren der Maskierung lässt sich eine inverse Operation definieren, welche die
ausgezeichneten Bereiche für die Verarbeitung durch die PAK selektiert. Entsprechend wird in den
Templates des Systems eine Selektionsinformation eingefügt, die gegen die HTML-Syntax eine
Kommentarfunktion darstellt. Der Beginn- und Endmarker für die Auszeichnung ist dabei, mit
Ausnahme eines gültigen HTML-Tags, beliebig zu wählen (Abbildung 29).
Anzuzeigender Text.
Abbildung 29: Selektion mit Tags
9.6.2.3 Adaptionsmethodik: Aggregation
Bei der Aggregation werden Informationen aus einer oder mehreren Komponenten der Darstellung
einer Komponente hinzugefügt. Die Position der Einfügeoperation wird durch einen Marker bestimmt,
der gegen die HTML-Syntax eine Kommentarfunktion darstellt (Abbildung 30). Der einzufügende
Wert kann durch die Portalanwendung generiert und durch eine Selektionsoperation einer anderen
Darstellung oder durch eine Datenintegration gewonnen werden.
Abbildung:
Preis:
Abbildung 30: Aggregation mit Tags
Die Komposition stellt eine spezielle Form der Aggregation dar. Bei ihr werden verschiedene
Einzeldarstellungen zu einer neuen Darstellung zusammengesetzt. Dabei existiert im Gegensatz zur
Aggregation kein führendes System, in dessen Darstellung die Information eingefügt wird.
9.6.2.4 Adaptionsmethodik: URL-Rewriting
Webbasierte Anwendungen bestehen aus mehreren Seiten, die untereinander verlinkt sind. Die Links
beziehen sich bei zu integrierenden Systemen absolut oder relativ auf deren jeweiligen Server. Wird
ein solcher Link innerhalb einer aggregierten Portalseite in einer PVK durch einen Client aktiviert, so
wird statt der Portalseite die Zielseite des Links des integrierten Systems geladen und angezeigt.
Analog gilt dies auch für Formulare einer integrierten Anwendung.
108
Erforderlich ist die Ersetzung des Orginal-Links der in der PVK integrierten Anwendung durch einen
Link auf die Portalseite und die Notifikation der PVK über den als nächsten in der integrierten
Anwendung zu aktivierenden Link. Auf die gleiche Weise muss mit Formularen verfahren werden.
Für dieses URL-Rewriting genannte Verfahren muss die Portalsoftware eine entsprechende
Unterstützung anbieten (z. B. URL-Rewriting als Bestandteil der Java Portlet-API, vgl. [Abdelnur und
Heppner 2003]). Für die Ersetzung des Original-Links in der Präsentation der Anwendung durch die
PVK wird die URL der PVK im Portalkontext benötigt. Diese Information wird durch einen API-
Aufruf der Portalsoftware erlangt. Die PVK kann mit dem Link Parameter verbinden und über einen
weiteren API-Aufruf eine gültige URL für die Präsentation im Portal erzeugen. Die Parameter werden
bei einer Aktivierung des Links beim Neuaufbau der Portalseite von der Portalsoftware an die
auslösende PVK weitergeleitet. Die PVK kann dann mit dieser Information das integrierte System
erkennen und die ursprüngliche URL in diesem System aktivieren. Das URL-Rewriting ist vom Portlet
für alle in der Präsentation des zu integrierenden Systems enthaltenen Links durchzuführen. Durch das
URL-Rewriting kann eine ggf. vorhandene Sitzungsinformation in der URL der integrierten
Komponente erhalten bleiben.
9.6.3 Verfahren zur Transformation von XML-Dokumenten
Die Auszeichnung von Daten in XML auf struktureller Ebene gestattet eine einfache Transformation
in andere Darstellungen. Die Extensible Stylesheet Language Family (XSL) besteht aus drei
Technologien zur Verarbeitung von XML-Dokumenten [W3C-XSL 2004]:
− Extensible Stylesheet Language Transformation (XSLT): XSLT ist die Metasprache zur
Beschreibung von Transformationen einer Klasse von XML-Dokumenten in eine dritte
Darstellung.
− XML Path Language (XPath): XPath erlaubt eine Adressierung von Teilen eines XML-
Dokuments und die Manipulation von Daten. XPath ist eine Hilfstechnologie für XSLT.
− XSL Formatting Objects (XSL-FO): XSL-FO dient der Hinterlegung von
Formatierungssemantik für die Erstellung von Dokumenten wie z. B. PDF.
Zur Transformation eines XML-Dokuments in ein Zielformat werden das Dokument selbst, ein XSL-
Stylesheet, das eine Beschreibung der Transformation enthält, und ein XSLT-Prozessor benötigt. Die
Transformation kann von der Quellkomponente in den Schichten BIK und PAK in das benötigte
Format der Zielkomponente vorgenommen werden. Die Quellkomponente kann jedoch auch durch die
Transformation ein vorgegebenes Austauschformat (vgl. Kapitel 9.4.3) erzeugen. Analog kann die
Zielkomponente die Transformation auch auf der Empfängerseite durchführen.
Ist die Zielkomponente eine PAK, so kann aus dem XML-Dokument der BIK oder PSK eine
portalkonforme Darstellung (HTML-Fragment) für die PVK direkt erzeugt werden (Abbildung 31).
Eine weitere Möglichkeit besteht in der Übertragung des XML-Dokuments zum Client und dem
Einsatz von Cascading Stylesheets (CSS) zur Formatierung der enthaltenen Daten (vgl. [W3C-CSS
2004], [Seeboerger-Weichselbaum 2001]). Dafür benötigt der Client die Fähigkeit zur Verarbeitung
von XML und CSS. Diese kann jedoch in einem Vertriebsszenario clientseitig nicht vorausgesetzt
werden.
109
XSLT-
Prozessor
XSL-
Stylesheet
XML-
Dokument
Dokument als
HTML-Fragment
PSK/BIK
PAK
Abbildung 31: XSLT-Transformation in einer PAK zur Darstellung von HTML
10 Methodik zur Anwendung des Architekturmodells
10.1.1 Übersicht und Vorgehen
Das entwickelte Architekturmodell erfordert eine Vorgehensmethodik zur Bildung einer Instanz. In
diesem Abschnitt werden die Hauptphasen gängiger Modelle dargestellt und die Anwendung des
Architekturmodells für Portale in den einzelnen Phasen beschrieben.
10.1.2 Architekturanwendung im Wasserfallmodell
Prozessmodelle beschreiben die Aktivitäten, Methoden und Verfahren zur Entwicklung von Software
(vgl. [Bullinger und Fähnrich 1997]). Modelle wie z. B. das Wasserfallmodell ([Royce 1970], [Boehm
1981]), das V-Modell (vgl. [Dröschel et al. 1998]) oder das Spiralmodell (vgl. [Boehm 1988])
unterscheiden einzelne Projektphasen, denen verschiedene Aktivitäten und Methodenmengen
zugeordnet sind. Viele Prozessmodelle erweitern das grundlegende Vorgehen des Wasserfallmodells
und bilden komplexere Formen [Balzert 1998]. Aus dieser Tatsache heraus ist das Modell als eine
allgemeine Form anzusehen. Für die Anwendung des Architekturmodells für Portale im Technischen
Vertrieb wird daher das Wasserfallmodell als Softwareprozessmodell gewählt. Die Wahl des
Wasserfallmodells ist mit der Einfachheit des Modells begründet, die eine gute Darstellbarkeit des
Beitrags des Architekturmodells gestattet. Komplexere Modelle wie das V-Modell sind ohne geeignete
Softwareunterstützung nicht darstellbar (vgl. [Balzert 1998]). Die Phasen des Wasserfallmodells sind
in Abbildung 32 dargestellt. Das Vorgehen ist dokumentengetrieben, so dass der Abschluss jeder
Phase durch ein Dokument gebildet wird [Balzert 1998]. Dieses ist jeweils die Ausgangsinformation
für den nachfolgenden Schritt. Der Anwendungsbereich des Architekturmodells fokussiert die Phasen
von der Erfassung und Dokumentation der Systemanforderungen bis zum Abschluss des
Softwareentwurfs. In den einzelnen Phasen werden die verschiedenen Architekturen und deren
Elemente angewandt. Entsprechend des Prozesses des Wasserfallmodells ergibt sich die nachfolgend
dargestellte Anwendung.
Abbildung 32: Anwendungsbereich des Architekturmodells im Kontext des Wasserfallmodells
System- und Softwareanforderungen: Durch die System- und Softwareanforderungen werden die
Kundenanforderungen an das zu erstellende System erfasst. Dies beinhaltet im Fall eines
Vertriebsportals die funktionalen Anforderungen, die zu integrierenden Bestandssysteme sowie die
abzubildenden vertrieblichen Portalprozesse. Diese Phase wird durch die Bereitstellung der
111
Portalprozesslandkarte, deren Prozesse als Instanz ausgeprägt werden, unterstützt. Die Identifikation
der zu integrierenden Bestandsysteme erfolgt auf Basis des Schichten- und Komponentenmodells.
Analyse: Die Analyse steht zwischen den Anforderungen und dem Entwurf. In dieser Phase werden
die Anforderungen vorbereitend analysiert. Das Architekturmodell unterstützt mit der
Portalanwendungslandkarte die Ableitung der für den späteren Entwurf benötigten PAK, PSK und
BIK. Aus der Komponentenlandkarte lassen sich im Rahmen der Analyse die erforderlichen
Komponenten der Schichten PAK, PSK und BIK identifizieren.
Entwurf: Der Entwurf erarbeitet eine Spezifikation der Portalarchitektur. Als Teil des Entwurfs
werden die einzusetzenden Personalisierungsverfahren, die Suche sowie das Rechte- und
Rollenkonzept und die Benutzerverwaltung spezifiziert. Hierzu wird das definierte Authentifizierungs-
und Benutzerverwaltungsmodell eingesetzt. Anhand der Funktionskarten für die Komponenten und
unter Einbeziehung der Portalanwendungslandkarte werden die erforderlichen Funktionen der
Komponenten der Schichten PSK und BIK ermittelt. Basierend auf den Funktionen und dem
Grunddatenmodell wird ein anwendungsspezifisches Datenmodell erstellt. Im nächsten Prozessschritt
werden die Kommunikationsbedarfe unter Zuhilfenahme des Kommunikationsmodells identifiziert
und eine Instanz des Modells gebildet. Aufbauend auf dem Kommunikationsmodell werden die
Datenformate für den Austausch und die Kopplung der Komponenten spezifiziert. Hierzu werden die
Integrationsmuster, das Datenformatmodell und die Adaptionsverfahren eingesetzt. Die Abbildung der
bisher noch abstrakt behandelten Komponenten auf Systeme erfolgt auf Basis der
Komponentenabbildungsmatrix. Hierbei sind die Differenzen in der Funktionalität zwischen abstrakter
Komponente und den Softwarekomponenten bzw. Softwaresystemen zu identifizieren und
Maßnahmen zur Anpassung vorzusehen. Abschließend werden die Ergebnisse der einzelnen Phasen zu
einer Gesamtspezifikation zusammengefasst. Der Vorgehensprozess ist in Abbildung 33 als UML-
Aktivitätendiagramm (vgl. [Hitz und Kappel 1999]) dargestellt.
112
Identifikation relevanter
Portalprozesse
Aufnahme der
Bestandssysteme
Portalprozess-
landkarte
Komponentenmodell
Ableitung und Spezifikation
der erforderlichen PAK
Ableitung und Spezifikation
der erforderlichen PSK, BIK
aus PAK
Ableitung und Spezifikation
der erforderlichen Funktionen
der Komponenten
Spezifikation Rechte, Rollen,
BenutzerverwaltungSpezifikation der
Personalisierungsverfahren
Spezifikation der Suche
Instanz
Funktionskarten
Ableitung und Spezifikation
der Datenformate und
Integrationsmuster
Abbildung der abstrakten
Komponenten auf Systeme
Identifizierung von
Differenzen zwischen abstr.
Komponenten und Systemen
Zusammenfassung des
Entwurfs
Grunddatenmodell
Integrationsmuster
Kommunikations-
modell
Adaptionsverfahren
Datenformatmodell
Modell für die Suche
Authentifizierungs-
und Benutzer-
verwaltungsmodell
Komponenten-
abbildungsmatrix
Schichtenmodell
Portalanwendungs-
landkarte
Ableitung und Spezifikation
der Kommunikation zwischen
Komponenten
Instanz
Kommunikations-
modell
Spezifikation
Integrationsmuster-
verwendung
Spezifikation
Adaption
Spezifikation
Datenformate
Komponenten-
abbildung
Funktionskarten
Spezifikation des
Datenmodells Instanz Datenmodell
Spezifikation Suche
Spezifikation
Personalisierungs-
verfahren
Spezifikation Rechte,
Rollen, Benutzer-
verwaltung
Zusammfassung
erforderliche PSK,
BIK
Zusammfassung
erforderliche PAK
Bestandssysteme
Spezifikation
Portalprozesse
Elemente des
Architekturmodells Anwendungsprozess
Instanz
Portalarchitektur
Elemente des
Architekturmodells Anwendungsprozess
Instanz
Portalarchitektur
Phase: System -und Softwareanforderungen
Phase: Analyse
Phase: Entwurf
Beitrag
Architekturmodell
Ergebnis des
Anwendungsprozesses
Abbildung 33: UML-Aktivitätendiagramm für den Vorgehensprozess zur Anwendung des
Architekturmodells
11 Einsatz und Evaluation des Architekturmodells
11.1 Bedeutung und Kriterien
Der Einsatz des Architekturmodells für Portale im Technischen Vertrieb erfolgte in verschiedenen
Beratungs- und Entwicklungsprojekten. In diesem Rahmen wurden auf Basis des Modells
verschiedene Portalarchitekturen erstellt. Ziel dieses Kapitels ist die Bewertung des
Architekturmodells gegen die in Kapitel 4.1 dargestellten Anforderungen anhand des praktischen
Einsatzes des Architekturmodells und dessen Ergebnissen. Der Einsatz erfolgte jeweils unter den
projektspezifischen Randbedingungen, welche zu verschiedenen Detaillierungsstufen der
Architekturelemente führten. Aus diesem Grund wird für die Bewertung des Architekturmodells ein
Anwendungsfall herangezogen, der alle Softwareerstellungsphasen von der Anforderungsanalyse über
den Feinentwurf bis zur Realisierung mit einem hohen Detaillierungsgrad durchlaufen hat. Dieser wird
im folgenden Abschnitt dargestellt. Als Ergänzung werden weitere Anwendungszenarien
zusammengefasst aufgezeigt. Damit ergibt sich für die Bewertung des Architekturmodells die
folgende Vorgehensweise:
− Darstellung des Anwendungsfalls „Portalarchitektur für den Vertrieb von Elektro-
werkzeugen“:
• Ausgangssituation des Technischen Vertriebs,
• Zielsetzung,
• Projektvorgehen,
• Teilarchitekturen der resultierenden Portalarchitektur: Prozessarchitektur, Anwendungs-
architektur, Datenarchitektur, Kommunikationsarchitektur und Infrastrukturarchitektur.
− Kurzzusammenfassungen weiterer Anwendungsszenarien:
• Partieller Einsatz für die Weiterentwicklung eines bestehenden Portals,
• Partieller Einsatz für die Erstellung einer Grobarchitektur.
− Evaluation des Architekturmodells:
• Bewertung des Architekturmodells in Bezug auf die gesetzten Detailziele.
11.2 Portalarchitektur für den Vertrieb von Elektrowerkzeugen
11.2.1 Ausgangssituation des Technischen Vertriebs
Das Unternehmen, für welches das Architekturmodell erstellt wurde, befasst sich als Marktführer mit
der Herstellung und dem Vertrieb hoch qualitativer Elektrowerkzeuge und dem entsprechenden
Zubehörmaterial für professionelle Anwender aus dem Handwerk, wie z. B. Maler, Schreiner,
Werkstätten. Das Produktspektrum ist in Einzelgeräte, Zubehör und Systemlösungen gegliedert. Der
Vertrieb an Endkunden und den Fachhandel ist in diesem Umfeld im besonderen Maße
beratungsintensiv. Die Betreuung bei der Produktwahl und die intensive Unterstützung der
Anwendung der Produkte stellen für das Unternehmen ein Alleinstellungsmerkmal dar. Aus diesem
Grund erfolgt der Vertrieb über ein international ausgerichtetes Fachhandelsnetz. Die
Unternehmensgröße der Fachhändler reicht von kleinen Einzelunternehmen mit einem Mitarbeiter bis
zu großen Unternehmen mit ausgeprägtem eigenem Netz von Ladenlokalen.
114
11.2.2 Zielsetzung
Die Zielsetzung der Anwendung des Architekturmodells ist die Erstellung einer Portalarchitektur für
die Abbildung der Prozesse des Technischen Vertriebs. Aus vertrieblicher Sicht ist das Ziel des zu
erstellenden Unternehmensportals die Abbildung der Hauptprozesse der Verkaufsphasen Werbung,
Information, Beratung, Verkaufsabschluss und Service für die Zielgruppen Fachhändler und
Endkunden. Hierbei ist einschränkend zu beachten, dass Artikel und Verkaufspreise ausschließlich an
das Fachhandelsnetz abgegeben werden sollen, während Endkunden lediglich Informations-,
Beratungs- und Serviceleistungen in Anspruch nehmen dürfen. Die erforderliche Personalisierung und
Individualisierung richtet sich damit primär an die Fachhändler, für die eine Einkaufs- und
Serviceumgebung bereitgestellt werden muss. Die Internationalisierung soll in einem ersten Schritt nur
für angemeldete Fachhändler verfügbar sein (Abbildung 34). In einem späteren Schritt sollen alle
Prozesse und Informationen internationalisiert verfügbar sein. Das softwaretechnische Ziel ist die
Erstellung eines Portalarchitekturmodells, das die vertrieblichen Prozessanforderungen in vollem
Umfang realisiert.
Abbildung 34: Kundenszenario des Anwendungsfalls
11.2.3 Projektvorgehen
Das Projekt wurde entsprechend dem Wasserfallmodell mit Iterationen einzelner Abschnitte
durchgeführt. Das Architekturmodell wurde in den Phasen System- und Softwareanforderungen,
Analyse und Entwurf eingesetzt. Die aus diesen Schritten resultierende Spezifikation wurde im
Anschluss in den Phasen Codierung, Testen und Betrieb umgesetzt. Das Vorgehen entspricht damit
der in Kapitel 10 vorgestellten Methode zur Anwendung des Architekturmodells. Die weitere
Darstellung des Anwendungsfalls erfolgt in den nächsten Abschnitten geordnet nach den im
Architekturmodell enthaltenen Teilarchitekturen und damit nicht chronologisch.
11.2.4 Prozessarchitektur
Die Prozessarchitektur des Vertriebsportals wurde auf Grundlage der Portalprozesslandkarte des
Architekturmodells für Portale definiert. Die während der Analyse erfassten Portalprozesse sind in der
Rastervorgabe der Portalanwendungslandkarte in Anhang J dargestellt. Die Prozesse wurden aus der
115
Gesamtheit der Prozesse der Portalprozesslandkarte fallspezifisch ausgewählt. Aus diesen
unternehmensindividuellen Portalprozessen resultieren die folgenden Prozessbündel:
− Produktbezogene Informationsprozesse,
− Transaktionsbezogene Prozesse,
− Konfigurationsprozesse
− Suchprozesse,
− Auswahl- und serviceunterstützende Prozesse,
− Kommunikationsprozesse,
− Allgemeine unternehmensbezogene Informationsprozesse.
Das Prozessbündel „Kooperative projektbezogene Prozesse“ findet keine Anwendung, da in Bezug auf
die Durchführung von Projekten keine kooperativen Prozesse identifiziert wurden. Die Prozessbündel
bilden die Ausgangsbasis für die weitere Erstellung der Architektur in diesem Anwendungsfall.
Po
rt
al
ar
ch
ite
kt
ur
Po
rt
al
ar
ch
ite
kt
ur
Abbildung 35 Unternehmensspezifische Ausprägung des Schichtenmodells für das Vertriebsportal
11.2.5 Anwendungsarchitektur
Für die Erstellung der Anwendungsarchitektur wurden die PAK des Vertriebsportals aus den
identifizierten Prozessbündeln abgleitet. Die Ableitung erfolgte auf Basis der Portal-
anwendungslandkarte des Architekturmodells (vgl. Anhang J).
Zur Realisierung der Funktionalität der PAK wurden weitere Komponenten mit ihren jeweiligen
Funktionen benötigt. Sie waren aus der „Komponentenlandkarte PAK“ abzulesen. Ausgehend von
diesen, den PAK nachgeschalteten, Komponenten wurden die weiteren für den Aufbau der Architektur
benötigten Komponenten aus dem Komponentenmodell, insbesondere aus den Funktionskarten,
bestimmt. Die Anordnung der Komponenten erfolgte entsprechend dem Schichtenmodell, so dass sich
das in Abbildung 35 dargestellte Schichtenmodell für das Vertriebsportal ergibt. Während die
Komponenten der Ebenen PSK und BIK im konkreten Anwendungsfall in der Regel auf Systeme
zurückzuführen waren (vgl. Kapitel 8.6), besaß die PAK einen besonderen Aufbau entsprechend des
116
eingeführten Portal-MVC-Schemas. Der Aufbau einer PAK wird am Beispiel der
produktwahlunterstützenden PAK PWB erläutert.
Die PAK PWB beinhaltet entsprechend der erfassten Prozesse und des Architekturmodells u. a. die
Funktion der Bereitstellung eines Content-Bereichs für Anwendungsbeispiele und eines
Produktberaters, der in der vorliegenden Anwendung durch eine 3D-Figur mit natürlichsprachlicher
textbasierter Dialogmöglichkeit realisiert wurde. Beide Funktionen werden von der PAK PWB in
verschiedenen PVK dargestellt. Dazu werden zwei Instanzen der zur PAK gehörenden PVK gebildet,
die entsprechend der in der Portalumgebung hinterlegten Konfigurationsinformation verschiedene
Funktionen bereitstellen.
Abbildung 36: Portal-MVC am Beispiel der Portalanwendungskomponente PWB
Die Konfiguration der PVK veranlasst die Selektion der für diese Portalfunktion verantwortlichen
View der PAK. Es stehen je eine View zur Anzeige des Content-Bereichs und des Beraters zur
Verfügung (Abbildung 36). Das Model bildet eine Abstraktion der Komponenten CM und BER und
deren Anbindung. Es greift auf die Funktionen der Komponenten gemäß der
„Portalanwendungslandkarte“, der Funktionskarten und des Kommunikationsmodells, einschließlich
der darin definierten Integrationsmuster, zu. Abbildung 37 zeigt eine Portalseite
„Anwendungsbeispiele“. Diese enthält drei PVK, die von zwei PAK gespeist werden: PVK
„Anwendungsbeispiele“ der PAK PWB, PVK „Produktberater“ der PAK PWB und PVK
„Unternehmensnachrichten“ der PAK UINF. Die Seite dient der Beratung gewerblicher und privater
Endkunden bzgl. des Einsatzes der Werkzeuge. Die Realisierung der PVK erfolgt mittels der Java-
Portlet-Technologie (vgl. Kapitel 3.7). Die Views wurden jeweils mit JSP-Technologie umgesetzt und
nutzen das Java-Beans-basierte Model. Das Model der PVK greift auf die Inhalte der Komponente
CM zurück. Die Funktionen hierfür sind in der Funktionskarte der Komponente spezifiziert. Neben
der Bereitstellung des Content-Bereichs werden in der Komponente CM die Daten nach dem Import
der Stammdaten aus der Komponente DM für die Nutzung im Portal aufbereitet und optimiert. Die
117
Pflege der Inhalte erfolgt in einer für diesen Zweck spezialisierten Oberfläche. Abbildung 38 zeigt die
Verwaltungsumgebung des CMS, auf das die abstrakte Komponente CM abgebildet wurde.
Hinsichtlich der Anordnung der PVK, sowohl innerhalb als auch auf den Portalseiten, bestehen für den
Betreiber alle Freiheitsgrade, welche die Portalumgebung vorsieht. Die PVK „Produktberater“ kann
somit auch zusätzlich auf anderen Portalseiten dargestellt werden. Für den Kunden bzw. Fachhändler
bestehen keine Konfigurationsmöglichkeiten für die Anordnung der PVK auf den Seiten.
PVK der PAK
PWB
mit Darstellung
des Content-
Bereichs für
Anwendungs-
beispiele
PVK der PAK
PWB
mit kontext-
sensitiver
Darstellung
eines Produkt-
beraters
PVK der PAK
UINF
mit Darstellung
der Unter-
nehmens-
nachrichten
Abbildung 37: Ansicht einer Portalseite mit zwei Portalvisualisierungskomponenten (PVK) der
Portalanwendungskomponente (PAK) PWB und einer Portalvisualisierungskomponente (PVK) der
Portalanwendungskomponente (PAK) UINF
Navigation
des CMS
Baumdar-
stellung der
Portalinhalte:
Content-Objekte
und Content-
Bereiche
Arbeitsbereich
des CMS
beim Editieren
eines Bildes für
ein Anwen-
dungsbeispiel
Abbildung 38: Ansicht der Bearbeitung von Content in der Portalsystemkomponente (PSK) CM
118
11.2.6 Datenarchitektur
Für den Entwurf der statischen Datenarchitektur des Vertriebsportals werden die Grunddatenmodelle
des Architekturmodells herangezogen. Sie werden durch eine weitere Detaillierung der dort
enthaltenen Klassen individuell ausgeprägt. Die Erweiterung erfolgt durch die Auszeichnung mit
Attributen in der UML-Notation. Die Attribute beschreiben den detaillierten datentechnischen Aufbau
der einzelnen Klassen und sind die Grundlage für die Umsetzung in eine Software. Die Verwendung
der Datenarchitektur wird im Folgenden an einem Ausschnitt des Grunddatenmodells Transaktion
aufgezeigt.
Der durch die PAK TRANS dargestellte Warenkorb bildet den Ausgangspunkt für eine Transaktion.
Er wird von der PSK SHOP für die PAK bereitgestellt und vom Portalnutzer mit Artikeln aus dem
Katalog gefüllt. Der Warenkorb enthält eine Liste mit (Artikel, Stückzahl)-Tupel. Ist die Befüllung
beendet, wird eine Bestellung auf Basis des Warenkorbs erzeugt und ein Kundenauftrag in der BIK
CRK angelegt. Hierfür werden die Daten des Warenkorbs zunächst in eine erweiterte Datenstruktur
überführt, welche die Bestellung repräsentiert, um anschließend als Kundenauftrag geführt zu werden.
Diese Strukturen enthalten die Tupel des Warenkorbs, erweitert um die folgenden zusätzlichen
Informationen:
Kundendaten: Die Daten des angemeldeten Portalnutzers mit Kundennummer und Kontaktdaten. Die
Kontaktdaten sind grundsätzlich nicht erforderlich, lassen jedoch im Fehlerfall eine manuelle
Nachbearbeitung der Bestellung zu.
Bestellerdaten: Name und Kontaktdaten des Bestellers.
Lieferdaten: Daten zur Lieferung der bestellten Artikel mit Lieferadresse (falls abweichend von
Kontaktadresse), Terminwunsch, Versandinformationen für den Empfänger (z.B. Bestellungsnummer
des Kunden).
Identifizierungsdaten: Diese Daten umfassen die in der SHOP-Komponente generierte Referenz-
nummer, Datum und Uhrzeit der Bestellung.
Die Bestellung ist gemäß der Vorgaben des Kommunikationsmodells und der Funktionskarten an die
CRK weiterzuleiten. In dieser Komponente wird auf Basis der Bestellung ein Kundenauftrag angelegt.
Dieser basiert direkt auf den Daten der Bestellung und trägt eine Reihe zusätzlicher Daten, die für die
gesamte Durchführung der Bestellung im Unternehmen notwendig sind. Das sind im vorliegenden Fall
unter anderem:
Status: Der Status gibt den aktuellen Bearbeitungsstatus der Bestellung wieder, der sich in der
Auftragshistorie vom Kunden einsehen lässt. Bestellungen über einem definierten Bestellwert werden
zunächst im System gesperrt und müssen manuell von einem Mitarbeiter freigegeben werden, um
kostenintensive Fehlbestellungen zu vermeiden.
Bestellweg: Der Bestellweg wird bei Bestellungen über das Portal auf „Internet“ gesetzt, um diesen
Weg gesondert auswerten und den Kunden ggf. Bonussysteme anbieten zu können.
In Abbildung 39 werden die durchgeführten anwendungsbezogenen Erweiterungen in einem UML-
Teilmodell dargestellt.
Die an diesem Beispiel gezeigten Erweiterungen bilden die Grundlage für die Beurteilung und die
Auswahl der zu verwendenden Datenformate für den Datenaustausch und der damit verbundenen
Integrationsmuster. Für Datenklassen, die zwischen Komponenten ausgetauscht werden, muss ein
119
geeignetes Datenformat gewählt werden, das eine Abbildung aller Attribute der Klasse gestattet.
Darüber hinaus sind die allgemeinen Anforderungen des Kommunikationsmodells zu beachten.
Abbildung 39: Ausprägung des Grunddatenmodells am Beispiel Transaktion (Teilmodell)
11.2.7 Kommunikationsarchitektur
Die aus der Prozess- und Anwendungsarchitektur als relevant abgeleiteten Komponenten wurden in
der Sicht der Kommunikationsarchitektur miteinander verbunden. Die im vorhergehenden Abschnitt
beschriebenen Anforderungen an die Wahl der Integrationsmuster und der Datenformate wurden
entsprechend berücksichtigt.
Die Betrachtung der Kommunikation wurde in enger Verbindung mit der Infrastrukturarchitektur und
der dort enthaltenen Abbildung der abstrakten Komponenten auf Systeme und Komponenten
durchgeführt. Die hierbei vorliegende Interdependenz lässt eine separate Betrachtung von
Kommunikation und Realisierung nicht sinnvoll erscheinen. Die Kommunikationsarchitektur enthält
eine Bewertung der Eignung der Datenformate und Integrationsmuster. Auf Basis dieser Bewertung
wurden die im Datenmodell als erforderlich identifizierten Datenklassen mit einem jeweils geeigneten
Datenformat und Integrationsmuster versehen. In einem weiteren Schritt wurden unter
Berücksichtigung der gewählten Systeme die notwendigen Adaptionsverfahren für die Schnittstellen
gewählt. Ein Beispiel für eine Adaption wird in Kapitel 11.2.8.5 am Beispiel KAT und SHOP im
Kontext der Anpassung der Systeme an die Anforderungen der Spezifikation des Vertriebsportals
dargestellt. Es wurde eine Instanz des Schnittstellenmodells zur Beschreibung der Kommunikation im
Vertriebsportal gebildet (Abbildung 40).
Die PAK KAT und TRANS nutzen Präsentationen der nachgeordneten PSK SHOP. Analog gilt dies
für die PAK KNF und die PSK KONF. Für die Integration auf der Darstellungsebene bietet sich das
Integrationsmuster M1 (Integration über HTTP) und das Datenformat HTML an. Die Anwendung der
Kommunikationsarchitektur bei dem Entwurf des Vertriebsportals soll am Beispiel der Integration der
Komponenten KAT, TRANS, KNF, SHOP und KONF veranschaulicht werden.
120
Abbildung 40: Übersicht der Anwendungs- und Kommunikationsarchitektur im Anwendungsfall
Die PVK der PAK KNF wird von der PVK der PAK KAT über das angezeigte Produkt informiert. Die
parallele Darstellung der PAK KAT und PAK KNF in ihren jeweiligen PVK erfordert eine
Kommunikation zwischen diesen Komponenten entsprechend dem Architekturmodell.
Die in der PVK der PAK KNF erstellten Konfigurationen werden über die PVK in den Warenkorb der
PAK TRANS transferiert. Durch die Verwendung der Darstellung des Warenkorbs der PSK SHOP in
der PAK TRANS wird der Warenkorb des Shops direkt gefüllt (Abbildung 41). Für die
Benachrichtigung wird als ein allgemeines Datenformat ein String gewählt, der die Artikelnummer des
angezeigten Artikels trägt. Das geeignete Integrationsmuster für die Umsetzung ist das Muster M7.
Dieses muss von der eingesetzten Portalsoftware in Form eines Event-Mechanismus für Portlets
implementiert werden. Die Übertragung der Konfiguration von der PAK KNF zur PAK TRANS
erfolgt ebenfalls über das Muster M7. Die Konfigurationsinformation wird in Form eines
eigendefinierten XML-Dokuments über M7 übermittelt und im Warenkorb abgelegt. Die Auflösung
der Konfiguration erfolgt in der BIK CRK oder ERK.
Die PSK SHOP greift für die Prüfung der Verfügbarkeit und des Bestellstatus sowie für die
Einbuchung von Bestellungen auf die BIK CRK zurück. Die BIK CRK wird in der
Infrastrukturarchitektur auf SAP R/3 abgebildet und bietet damit in Form der BAPI eine eigene API
für den Zugriff auf die Daten und Prozesse an. Als Integrationsmuster wurde M2 (synchrone
Middleware) mit der technologischen Ausprägung Web Services gewählt. Die PSK SHOP (System:
Intershop Enfinity) wurde um einen Web Service Client erweitert und kommuniziert die erforderlichen
Datenklassen über die in der BAPI definierten Datenstrukturen.
121
Abbildung 41: Kommunikation am Beispiel der Portalanwendungskomponenten (PAK) SHOP und KNF
Abbildung 42: Ansicht einer Portalseite mit Portalvisualisierungskomponenten (PVK) der Portalanwen-
dungskomponenten (PAK) KAT, KNF und UINF
Die PSK KONF wurde in analoger Weise angebunden. Abbildung 42 zeigt die aus der
Kommunikation resultierende integrierte Informationsdarstellung. Die PVK der PAK KAT stellt einen
Artikel dar. Die Verfügbarkeit des Artikels wird aus der BIK CRK akquiriert. Die PVK der PAK KNF
122
(„Toolkonfigurator“) stellt kontextsensitiv die Konfigurationsmöglichkeiten des in der benachbarten
PVK angezeigten Artikels dar. Die möglichen Varianten entstammen der BIK CRK in Form einer
Stückliste mit Varianteninformation. Ist der Artikel nicht konfigurierbar, zeigt die PVK diese
Information entsprechend an.
11.2.8 Infrastrukturarchitektur
Die Infrastrukturarchitektur spezifiziert grundlegende Elemente für die Erstellung von Portalen. Dazu
gehören neben der Abbildung der abstrakten Komponenten auf Systeme die Bereiche Personalisierung
und Individualisierung, die Suche und die notwendigen Maßnahmen zur Anpassung der
Bestandssysteme.
11.2.8.1 Personalisierung und Individualisierung
Die Personalisierung basiert auf den zu Beginn vorgestellten Zielgruppen. Dabei sind die privaten und
gewerblichen Endkunden gleichzusetzen. Es ergibt sich die Rolle „Endkunde“. Den Fachhändlern
sollten personalisierte Funktionen im größeren Umfang zur Verfügung stehen. Diese werden der Rolle
„Fachhändler“ zugeordnet. Die Personalisierung beeinflusst die Anwendungsverfügbarkeit und den
Inhalt der Komponenten. Da ausschließlich Fachhändler berechtigt sind, die Fachhandelspreise
einzusehen, Bestellungen zu tätigen und den Kundenservice zu kontaktieren, werden die
entsprechenden PVK nur diesem Kreis zugänglich gemacht. Der Katalog wird in einer PVK ohne
Preisangaben und Ersatzteile auch für die Rolle Endkunde angeboten. Die Transaktionsumgebung
wird für den jeweils angemeldeten Händler individualisiert und stellt die Auftragshistorie bzw. den
Status der Aufträge dar. Die Darstellung der PAK KOMM erfolgt ebenfalls individualisiert. Felder,
die Auskunft über die Identität des Anfragers geben, sind bereits unveränderlich mit den Daten des
angemeldeten Nutzers vorbelegt. Die Information stammt aus der BIK AUTH.
11.2.8.2 Authentifizierung und Umsetzung Single Sign On
Die Authentifizierung wurde entsprechend des Architekturmodells für Portale in Ebenen gegliedert.
Im Folgenden werden ausgewählte Beispiele für die Authentifizierung im entwickelten Vertriebsportal
vorgestellt.
Eine Authentifizierung an der Portalumgebung ist nur für Fachhändler möglich, da nur diese die
geschützte Einkaufsumgebung nutzen dürfen. Der Händler authentifiziert sich im Rahmen des Single
Sign On mittels eines HTML-basierten Dialoges in der Portaloberfläche. Die Portalsoftware prüft die
Daten gegen einen Verzeichnisdienst, der Bestandteil des Oracle-Portalpakets ist. Die Möglichkeit, die
berechtigten Händler aus der BIK CRK zu übernehmen, ist derzeit nicht vorgesehen. Sie müssen
manuell angelegt werden. Eine Authentifizierung erfolgt auf der Ebene PAK/PSK zwischen der PAK
KAT und der PSK SHOP sowie der PAK TRANS und der PSK SHOP. Für die Anmeldung des
Händlers verwenden die PAK den auf HTML-Formularen basierenden Anmeldeprozess von Intershop
Enfinity. Anstelle einer manuellen Eingabe erfolgt eine HTTP-Post-Operation, welche die
notwendigen Anmeldedaten des Händlers überträgt. Die Antwortseite des Formulars wird von den
PAK auf den Erfolg der Anmeldung ausgewertet. Ist der Benutzer noch nicht im Shop-System
angelegt, werden die im Portal erfassten Daten über eine zweite HTTP-Post-Operation in das System
übertragen. Die Anmeldung am Shop erfolgt ohne Passwort, da das System nur über das Portal
kommunizieren kann und somit durch die Sicherheitsmechanismen des Portals ausreichend geschützt
123
ist. Der Anmeldeprozess läuft ausschließlich zwischen der PAK und dem Shop ab und ist für den
Benutzer nicht sichtbar.
Die Einbuchung von Bestellungen in die von SAP R/3 repräsentierte BIK CRK erfolgt entsprechend
des Architekturmodells auf Basis eines Komponentennutzers, der eine Vertrauensstellung zwischen
SHOP und CRK voraussetzt.
11.2.8.3 Suche
Als relevante Bereiche für die Suche wurden in der Analyse der Produktkatalog (PAK KAT) und der
Bereich Anwendungsbeispiele (PAK PWB) identifiziert. Der Bereich Anwendungsbeispiele ist wegen
der besonderen Komplexität bzw. der damit verbundenen Erklärungsbedürftigkeit ein häufig zu
durchsuchender Bereich. Für die Gewinnung der Suchergebnisse greift die PAK SUCHE auf die PSK
SHOP (Funktion „SHOP-Suche“) und CM (Funktion „CM-Suche“) zu. Die Suchergebnisse werden
auf einer Seite in zwei optisch getrennten Bereichen („Treffer in Produkte“ und „Treffer in
Anwendungen“) dargestellt.
11.2.8.4 Abbildung der Komponenten auf Systeme
Bei der Abbildung der abstrakten Komponenten des Architekturmodells für Portale können sich die
folgenden Konstellationen ergeben:
1. Abbildung einer abstrakten Komponente auf eine Softwarekomponente,
2. Abbildung zweier oder mehrerer abstrakter Komponenten auf eine Softwarekomponente,
3. Abbildung einer abstrakten Komponente auf ein Softwaresystem,
4. Abbildung zweier oder mehrerer abstrakter Komponenten auf ein Softwaresystem.
Beim Entwurf des Vertriebsportals werden die Abbildungsvarianten 1., 3. und 4. verwendet.
Komponenten verhalten sich in Bezug auf ihre Abbildung entsprechend ihrer Definition im Modell
atomar. Als Portalumgebung findet die Portal-Suite Oracle Portal Verwendung. Die SHOP-
Komponente wird direkt auf das Shop-System Intershop Enfinity abgebildet. Als Workflow-
Management-System wird InTempo eingesetzt, das die Funktion der Komponente WFM übernimmt.
Im vorliegenden Fall besteht bei der Abbildung von Systemen eine Union zwischen der BIK ERK und
der BIK CRK, die beide durch das ERP-System SAP R/3 abgebildet werden. Für den Bereich der
Komponente KDM, dem Katalogdatenmanagement, wird als System CAContent verwendet. Die
Aufgaben der Authentifizierungskomponente AUTH werden von einem in Oracle Portal enthaltenen
LDAP-fähigen Directory-System übernommen. Lotus Notes wird für das Dokumentenmanagement
(DM) und damit für die Erstellung und Verwaltung der Dokumente verwendet. Die Funktionalität der
Komponente KONF wird von einer komponentenbasierten projektinternen Eigenentwicklung
bereitgestellt. Die Beratungsfunktion (BER) basiert auf dem textbasiert natürlichsprachlich
arbeitenden Beratungssystem ADVICE. Die Content-Management-Funktionalität (CM) wird von dem
Open-Source-System ZOPE mit dem Content Management Framework (CMF) übernommen. Bei der
Abbildung der abstrakten Komponenten des Architekturmodells auf die Systeme und Komponenten
mussten sowohl die Bestandssysteme berücksichtigt als auch die Anforderungen an neue Systeme
bzw. Komponenten definiert werden. Eine Zusammenfassung der Systeme und Komponenten ist in
Tabelle 19 dargestellt.
124
Schicht Abstrakte
Komponente
Abbildung auf System Status des Systems
BIK SHOP Intershop Enfinity Shop-System Neu
BIK WFM InTempo Workflow-Management-System Neu
BIK CRK SAP R/3 (Modul Sales & Distribution, SD) Bestandssystem
BIK ERK SAP R/3 Basis Bestandssystem
BIK KDM CA Content Bestandssystem
BIK AUTH Portalsoftware Oracle Portal
(Integrierter Verzeichnisdienst)
Neu
BIK DM Lotus Notes Bestandssystem
PSK KONF Eigenentwicklung Neu
PSK BER ADVICE Beratersystem Neu
PSK CM ZOPE CMF Content-Management-System Neu
-- PORT Portalsoftware Oracle Portal Neu
Tabelle 19: Abbildung der Komponenten auf Systeme
11.2.8.5 Maßnahmen zur Anpassung der Systeme
Zwischen den abstrakten Komponenten und realen Systemen lassen sich Differenzen zwischen den
bereitgestellten Funktionen und den im Architekturmodell definierten Funktionsanforderungen
identifizieren. Diese werden durch Anpassung der Software beseitigt. Auch beim Entwurf des
Vertriebsportals wurden derartige Differenzen bei den Komponenten der Ebenen PSK und BIK
festgestellt und entsprechende Anpassungs- und Entwicklungsmaßnahmen spezifiziert. Die Arbeiten
bezogen sich unter anderem auf die Komponenten SHOP, CM und WFM. Beispielhaft werden
ausgewählte Arbeiten an der Komponente SHOP betrachtet. Die Integration in die PAK erfolgt bei
dieser Komponente auf visueller Ebene mit dem Integrationsmuster M1 und dem Datenformat HTML.
Portalseitig ist die Verwendung von HTML-Fragmenten ohne die umgebenden HTML- und BODY-
Tags sowie ohne Header-Informationen notwendig. Zur Reduktion des Rechenaufwands bei der
Adaption in der PAK TRANS und PAK KAT wurde diese Information aus den Templates des Shop-
Systems entfernt und das visuelle Erscheinungsbild angepasst. In der PAK KAT werden die
generierten Seiten der PSK SHOP als Grundlage für die Präsentationserstellung verwendet. Ein
weiterer Bestandteil der Veränderungen an den Templates war daher das Einfügen von Aggregations-
Tags (vgl. Kapitel 9.6.2.3, Adaptionsmethodik „Aggregation“) für Multimediadaten. An den mit den
Tags definierten Stellen werden in der PAK KAT zusätzliche Bilder und ggf. produktspezifisch
vorhandene Referenzen auf Dokumente und multimediale Objekte eingefügt. Das Produktbild wird im
vorliegenden Fall aus Pflegegründen nicht vom Shop-System bereitgestellt, sondern dynamisch von
der PAK KAT aus der PSK CM aggregiert. Die Realisierung des mit Preisen und Verfügbarkeit
personalisierten Katalogs für die Zielgruppe der Fachhändler basiert auf der Adaptionsmethodik
„Maskierung“. In den Templates des Shops sind Preis und Verfügbarkeit mit Maskierungs-Tags zu
versehen. Das Maskierungsverfahren wird selektiv in Abhängigkeit von der Rolle angewendet. Ist der
Nutzer des Portals ein Fachhändler, so wird die Maskierung von der PAK KAT ignoriert. Ist der
Nutzer des Portals Mitglied von „Endkunde“ und damit den anderen Gruppen zuzuordnen, so werden
Preis und Verfügbarkeit maskiert. Hierfür werden abhängig von der Zugehörigkeit zwei verschiedene
PVK instanziert, die jeweils eine eigene View nutzen. Der Warenkorb des verwendeten Intershop
125
Enfinity war derart anzupassen, dass dieser neben den Artikeln aus dem Katalog auch die von dem
Konfigurator (KONF) erzeugten Konfigurationen übernehmen kann. Für die Einbuchung von
Bestellungen mit konfigurierten Produkten in das verwendete SAP R/3 war der interne
Verarbeitungsprozess des Shop-Systems individuell anzupassen.
11.3 Weitere Anwendungsszenarien
Neben der beschriebenen Anwendung wurde das Architekturmodell für Portale in verschiedenen
weiteren Szenarien eingesetzt. Dabei erfolgte zum Teil eine Verwendung in ausgewählten Phasen,
z. B. Erfassung der Anforderungen, Analyse, Entwurf. Das Architekturmodell wurde auch zur
Optimierung bestehender Entwürfe und Spezifikationen eingesetzt. Stellvertretend für Projekte mit
partieller Anwendung der Architekturelemente werden im Folgenden die Szenarien und Ergebnisse
zweier Einsätze beschrieben.
Partieller Einsatz für die Erstellung einer Grobarchitektur: Der Einsatz des Architekturmodells
erfolgte bei einer Unternehmensgruppe, die als Zulieferer technischer Produkte für den Finanzbereich
auf die Abwicklung des Vertriebsprozesses in einem Portal setzt. Typische Produkte sind in diesem
Anwendungsfall z. B. EDV-Ausstattung und EDV-Zubehör, Kartenlesegeräte sowie standardisierte
bzw. individualisierte Printpublikationen. Sie stellen zu einem Teil Investitionsgüter dar.
Ausgangspunkt des Einsatzes des Architekturmodells waren die bestehenden System- und
Softwareanforderungen. Zur Sicherstellung der Vollständigkeit der Prozesse und für die Auswahl
eines Dienstleisters war die Erstellung einer Grobarchitektur notwendig.
Die durch das Portal bereitzustellenden Prozesse waren bereits durch das Unternehmen definiert und
wurden auf die Prozessarchitektur des Modells zurückgeführt. Dieser Vorgang war durch die nahezu
vollständige Überschneidung der Prozesse in kurzer Zeit möglich. Ausgehend hiervon wurde eine
Grobarchitektur abgeleitet, die eine Instanz des Architekturmodells in einer niedrigen
Detaillierungsstufe bildet. Die Grobarchitektur identifizierte fehlende, aber notwendige Prozesse,
definierte die notwendigen Komponenten und lieferte eine Entscheidungsgrundlage für die Auswahl
des Dienstleisters.
Partieller Einsatz für die Weiterentwicklung eines bestehenden Portals: Die Weiterentwicklung
erfolgte für einen Marktführer im Bereich Sensorik. Die Elemente des Architekturmodells wurden
eingesetzt, um das bestehende Vertriebsportal zu untersuchen und Erweiterungen sowie funktionale
Verbesserungen bei der Abbildung des Vertriebsgesamtprozesses abzuleiten. Die Prozessarchitektur
wurde für einen Ist/Soll-Vergleich herangezogen und neu abzubildende Prozesse im Bereich
Transaktion wurden abgeleitet. Die Prozesse bzw. Prozessbündel bildeten die Grundlage für die
Spezifikation der benötigten Komponenten.
Bei der Abbildung der abstrakten Komponenten auf Bestandssysteme wurden erforderliche
Anpassungen bzw. Systemwechsel untersucht und Maßnahmen abgeleitet. Ein Teilaspekt der Arbeiten
war die Internationalisierung des Angebots. Das Portal sollte zentral betrieben werden, wobei ein
Zugriff auf die Daten der betrieblichen Informationssysteme in den jeweiligen Ländern in
Abhängigkeit von dem Land des Nutzers erfolgen sollte. Zur Lösung dieses Problems wurden die
Integrationsmuster so gewählt, dass eine Kommunikation zwischen dem zentralen Portal und den
verteilten BIK über ein gesichertes Netzwerk ermöglicht wurde.
126
11.4 Evaluation des Architekturmodells
Die Anwendung bei dem Entwurf einer Portalarchitektur für den Vertrieb von Elektrowerkzeugen
zeigte den Einsatz des Architekturmodells für Portale über alle Entwurfsphasen. Darüber hinaus wurde
in diesem Anwendungsfall die erstellte Architektur softwaretechnisch realisiert. Die Anwendung der
Architektur erfolgte mit allen Teilsichten entlang des gesamten Vorgehensprozesses. Die weiteren
partiellen Anwendungen stellen die Möglichkeiten des Einsatzes ausgewählter Elemente und der
Variation des Detaillierungsgrades der Architektur in der praktischen Anwendung dar. Im Folgenden
wird das Architekturmodell für Portale im Technischen Vertrieb in Bezug auf das in Kapitel 4.1
definierte Ziel mit seinen Detailzielen und den Ergebnissen aus den Kapiteln 11.2 und 11.3 verglichen
und der Zielerreichungsgrad bewertet.
Detailziel 1: Integration der überlappenden Teilfunktionen der Systeme des Technischen
Vertriebs zu einer kundenorientierten Anwendung.
Eine Integration der Systeme des Technischen Vertriebs wird durch das Architekturmodell mit den
Elementen Anwendungs-, Infrastruktur- Kommunikations- und Datenarchitektur gewährleistet. Basis
der Entwicklung bildet die kundenorientierte Portalprozesslandkarte. Die Anwendungsarchitektur
verwendet abstrakte Komponenten für den Aufbau des Portals und definiert dabei die benötigten
Funktionen. Die Infrastrukturarchitektur beschreibt Abbildungsvarianten der abstrakten Komponenten
auf Systeme des Technischen Vertriebs und berücksichtigt damit die überlappenden Teilfunktionen
der Systeme. Kommunikations- und Datenarchitektur beschreiben die Schnittstellen und den
Datenaustausch zwischen den Komponenten. Im gezeigten Einsatzfall wurde eine kundenorientierte
Integration von ERP, CRM, KDM, Dokumentenmanagementsystem, Workflow-Management-System
und LDAP-System mit Hilfe des Architekturmodells erreicht. Das Detailziel wurde im vollen Umfang
erfüllt.
Detailziel 2: Entwicklung einer softwaretechnischen Struktur für Portale mit den darin
integrierten Anwendungen
Das Architekturmodell beinhaltet ein Schichtenmodell für die softwaretechnische Strukturierung von
Portalen. Mit ihrem direkten Bezug zu typischen Ausprägungen von Komponenten im Portalkontext
geht sie über den Ansatz bestehender Schichtenmodelle hinaus. Das Schichtenmodell unterstützt
Softwarekomponenten im Sinne eines Komponentenmodells und eigenständige Systeme, die
wiederum selbst nach beliebigen Schichtenmodellen aufgebaut sein können. Der praktische Einsatz
des Modells zeigt, dass diese softwaretechnische Strukturierung sowohl den Softwareentwurf als auch
die Diskussion in frühen Phasen unterstützt und als Ergebnis eine eindeutige Struktur für das Portal
liefert. Sie ist daher im besonderen Maße für die Ableitung der Struktur geeignet und erfüllt die
geforderten Eigenschaften an eine softwaretechnische Struktur für Portale.
Detailziel 3: Entwicklung einer portalspezifischen Prozessarchitektur zur kundenorientierten
Realisierung des Vertriebsprozesses des Technischen Vertriebs.
Die Arbeit entwickelt ausgehend von einer Unternehmensbefragung von Unternehmen mit
Technischen Vertrieb eine Prozessarchitektur, welche die durch den Kunden im Portal ausführbaren
Prozesse festlegt. Die Prozessarchitektur unterstützt im Gesamtumfang die Phasen des
Vertriebsprozesses mit Werbung, Information, Beratung, Verkaufsabschluss und vertriebsbezogenem
Service und berücksichtigt Leistungen wie den angebots- und katalogbasierten Vertrieb. Die
127
entwickelte Portalprozesslandkarte fasst in Bezug auf die Phasen des Vertriebs ähnliche Prozesse zu
Prozessbündeln zusammen und erlaubt eine Abbildung der Prozesse auf die Komponenten der
Anwendungsarchitektur und damit auf die nachgelagerten Komponenten des Komponentenmodells.
Die Einsatzfälle zeigen, dass der mit der Prozessarchitektur verfolgte Ansatz in der Praxis erfolgreich
zu einer Definition der durch Kunden im Portal ausführbaren Prozesse des Technischen Vertriebs
entlang des gesamten Vertriebsprozesses führt. Die Prozesse werden wie gefordert zu Prozessbündeln
zusammengefasst. Eine Verbesserungsmöglichkeit für die Prozessarchitektur ergibt sich lediglich
durch eine Ausweitung der Anzahl der in der Prozessarchitektur berücksichtigten Prozesse um seltener
geforderte Prozesse.
Detailziel 4: Entwicklung einer portalspezifischen Anwendungsarchitektur
Die Anwendungsarchitektur überträgt den Ansatz komponentenorientierter Architekturen auf Portale.
Ausgehend von der Strukturierungsvorgabe des portalspezifischen Schichtenmodells beschreibt die
Anwendungsarchitektur mit dem enthaltenen Komponentenmodell kontextbezogen die Aufgabe der
Komponenten und deren benötigte Funktionen. Hierbei werden abstrakte Komponenten verwendet,
die mittels der Infrastrukturarchitektur auf reale Systeme abgebildet werden. Der Einsatz des
Architekturmodells in der Praxis zeigt, dass die Verwendung von abstrakten Komponenten einen
geeigneten Lösungsansatz darstellt. Die Komponenten wurden im gezeigten Fall entsprechend der
Architektur funktional definiert und auf geeignete Systeme abgebildet. Die portalspezifische
Anwendungsarchitektur erfüllt das gesetzte Detailziel.
Detailziel 5: Entwicklung einer portalspezifischen Datenarchitektur
Die entwickelte Datenarchitektur stellt den statischen Zusammenhang der Daten des
Architekturmodells dar. Die portalspezifische Erweiterung der Darstellung um eine Zuordnung zu
Komponenten und die Festlegung von Stamm- und Bewegungsdaten erlaubte im praktischen Einsatz
eine einfache Verknüpfung von Komponenten- und Kommunikationsmodell. Die geforderten Eigen-
schaften der Datenarchitektur werden durch das Modell erfüllt und das Detailziel wird erreicht.
Detailziel 6: Entwicklung einer portalspezifischen Kommunikationsarchitektur
Die portalspezifische Kommunikationsarchitektur beinhaltet ein Schnittstellenmodell für die
Komponenten der Anwendungsarchitektur. Sie berücksichtigt die für ein Portal typische Vielfalt von
Datenformaten und verwendet bei der Beschreibung die Datenklassen der Datenarchitektur. Der
Aspekt der Integration wird durch die Entwicklung von Integrationsmustern und die Transformation
von Daten adressiert. Der Einsatzfall zeigt, dass die Kommunikationsarchitektur den
Kommunikations- und Integrationsanforderungen genügt und das das Detailziel erreicht wird.
Detailziel 7: Entwicklung einer portalspezifischen Infrastrukturarchitektur
Die entwickelte Infrastrukturarchitektur beschreibt mit dem Modell für die Suche im Portal, dem
Personalisierungs- und Individualisierungsmodell, dem Authentifizierungs- und Rollenmodell die
Funktion wesentlicher Basisdienste einer Portalinfrastruktur. Die Einbindung von PAK in die
Portalumgebung bzw. Portalsoftware wird definiert. Darüber hinaus werden im Rahmen dieser Sicht
die abstrakten Komponenten auf die bestehende Systeminfrastruktur des Technischen Vertriebs
abgebildet. Im praktischen Einsatz konnten die Elemente Suche, Authentifizierung, Rollen,
Personalisierung und Individualisierung auf Basis der Architektur direkt umgesetzt werden. Dies gilt
auch für die Abbildung der abstrakten Komponenten auf Systeme. Die geforderten Eigenschaften und
das Detailziel werden damit erfüllt.
128
Detailziel 8: Unterstützung von Personalisierung und Rollenorientierung zur Erfüllung der
Portaleigenschaften auf den Ebenen AE und TF
Die Unterstützung von Personalisierung und Rollenorientierung als grundlegende Portaleigenschaft
wird primär durch die Infrastrukturarchitektur erfüllt. Die enthaltenen Modelle erfüllen die
Portaleigenschaften auf den Ebenen AE und TF.
Detailziel 9: Unterstützung von Benutzermanagement zur Erfüllung der Portaleigenschaft auf
den Ebenen AE und TF
Das Benutzermanagement als Portaleigenschaft wird in der Architektur durch die Komponente AUTH
sowie durch die benutzer- bzw. kundenbezogenen Datenklassen auf den Ebenen AE und TF
berücksichtigt. Die Eigenschaft des Benutzermanagements ist damit auf diesen Ebenen erfüllt.
Detailziel 10: Unterstützung von Prozessorientierung zur Erfüllung der Portaleigenschaft auf
den Ebenen AE und TF
Die Prozessorientierung wird als Querschnittsziel von allen Teilarchitekturen adressiert. Im
besonderen Maße wird die Prozessorientierung durch die Existenz und die Gestaltung der
Prozessarchitektur erreicht. Die Portaleigenschaft Prozessorientierung wird auf den Ebenen AE und
TF in vollem Umfang von dem entwickelten Architekturmodell erfüllt.
Detailziel 11: Unterstützung von Integration und Homogenität zur Erfüllung der Portaleigen-
schaften auf den Ebenen AE und TF
Die Portaleigenschaft der Integration wird durch nahezu alle Teilarchitekturen adressiert. Als
Schwerpunkt wird die Eigenschaft in der Anwendungs-, Infrastruktur- und
Kommunikationsarchitektur mit der Beschreibung der Integration der Komponenten bzw. Systeme
adressiert. Die Homogenität wird im Rahmen der Kommunikationsarchitektur durch die Beschreibung
der Adaptionsverfahren sichergestellt. Das Architekturmodell erfüllt die Eigenschaften auf den Ebenen
AE und TF in vollem Umfang.
Das Architekturmodell erfüllt mit den Detailzielen 8 bis 11 die allgemeinen Anforderungen an Portale
und zeigt damit, dass mit Hilfe des Ansatzes Portale entsprechend der Portaldefinition erstellt werden
können. Dies wird durch die in den Kapiteln 11.2 und 11.3 beschriebenen Anwendungsszenarien
bestätigt. Durch die Erreichung der Detailziele 1 bis 7 wird gezeigt, dass das Architekturmodell die in
Kapitel 3.9 zusammengefassten Defizite des Technischen Vertriebs und die Defizite bestehender
Ansätze adressiert und in geeigneter Weise eine verbesserte Lösung für die Problemstellung eines
Architekturmodells für den Technischen Vertrieb darstellt. Diese Feststellung wurde über den Fokus
der Evaluierung hinaus durch die positiven Reaktionen der Nutzer bestätigt. In den dargestellten
Szenarien konnten für definierte Zielgruppen (Schwerpunkt in B- und C-Kundensegmenten)
bestehende Kommunikationskanäle wie z. B. Telefon und Fax weitgehend durch das Portal substituiert
werden, da die Nutzer die integrierten Prozesse über das Portal bevorzugten.
Die Evaluation des Architekturmodells gegen die definierten Detailziele zeigt, dass der Grad der
Zielerreichung hoch ist. Das Primärziel der Erstellung eines Architekturmodells für Portale für den
Einsatz im Technischen Vertrieb wurde damit auch im Gesamtumfang vollständig erreicht.
12 Zusammenfassung
12.1 Zusammenfassung der Ergebnisse
Die vorliegende Arbeit befasst sich mit den Themenbereichen Technischer Vertrieb und Architekturen
für Portale. Im Rahmen der Ausarbeitung wird ein integratives Architekturmodell für Portale
entwickelt, welches unter Berücksichtigung von Neu- und Bestandssystemen die Prozesse des
Technischen Vertriebs abbildet.
Hintergrund ist die zunehmende Notwendigkeit für Unternehmen, die sich mit dem Vertrieb
technischer Produkte befassen, eine herausragende Position in Käufermärkten zu erreichen. Hierfür ist
die Kundenbindung und Kundenansprache durch individuell an die Bedürfnisse der Kunden
angepasste Prozesse zu intensivieren. Gleichzeitig besteht die Erfordernis, die Effizienz in Bezug auf
Zeit und Kosten im Vertrieb zu optimieren. Portale bieten eine technische Lösung für die
Bereitstellung einer homogenen Benutzungsoberfläche mit dem Zugriff auf integrierte und
personalisierte Prozesse. Die Integration von Prozessen in einem Portal erfordert eine umfassende
Architektur, die auch die Einbindung der betrieblichen Informationssysteminfrastruktur beschreibt.
Davon ausgehend identifiziert die Arbeit zunächst die grundlegenden Portaleigenschaften:
internetbasierend, Personalisierung und Rollenorientierung, Benutzermanagement, Prozess-
orientierung, Integration und Homogenität. Parallel hierzu werden die Leistungen und die
Organisation des Technischen Vertriebs untersucht. Es wird festgestellt, dass eine wesentliche
Anforderung die Abdeckung der vertrieblichen Prozesse Werbung, Information, Beratung,
Verkaufsabschluss und After Sales Support darstellt. Die Untersuchung der Systemlandschaft des
Technischen Vertriebs ergibt den Einsatz einer Vielzahl unterschiedlicher Systeme mit zum Teil
erheblich überlappender Funktionalität.
Die Untersuchung aus Sicht des Software-Engineerings umfasst Softwarearchitekturen für die
Erstellung webbasierter Anwendungen, wie z. B. eingebettete Skriptsprachen und die Plattform-
konzepte Java und .NET, Integrationsarchitekturen, Portalsoftware und Architekturmodelle für
Portale. Ziel der Betrachtung ist eine Bewertung der Ansätze auf ihren Beitrag zu einer Architektur für
Portale im Technischen Vertrieb. Kernkriterien sind unter anderem die Strukturierungsvorgaben und
die Granularität des Komponentenmodells, die eine Aussage über die Fähigkeit zur Integration von
Bestandsanwendungen zulassen.
Es wird in den Betrachtungen das Fehlen eines vollständig ausgeprägten Architekturmodells mit den
Bestandteilen Strategie, Prozess-, Anwendungs-, Daten- und Kommunikationsarchitektur sowie eine
Beschreibung der Infrastruktur festgestellt. Weitere Defizite stellen die mangelnde Definition funk-
tionaler Anforderungen an die Anwendungen des Technischen Vertriebs im Kontext von Portalen und
die ungenügende softwaretechnische Strukturierung von Portalen dar. Auf Basis der identifizierten
Defizite werden Kriterien für die spätere Bewertung des Architekturmodells erarbeitet.
Grundlage des Architekturmodells für Portale im Technischen Vertrieb ist die portalspezifische
Erweiterung eines allgemeinen Architekturmodells. Als vollständiges Architekturmodell wird die
ganzheitliche Informationssystemarchitektur (ISA) herangezogen, die die Bestandteile Strategie,
Aufbauorganisations-, Prozess-, Anwendungs-, Daten- und Kommunikationsarchitektur sowie
Infrastruktur umfasst. Die Teilmodelle Strategie und Aufbauorganisation werden im Rahmen der
Arbeit durch die Vorgabe des Anwendungsfalls Technischer Vertrieb als gegeben vorausgesetzt.
130
Die Entwicklung der Prozessarchitektur erfolgt auf Basis einer Befragung von Unternehmen mit
Technischem Vertrieb. Die Portalprozesslandkarte ist ein Hauptbestandteil der Prozessarchitektur. Sie
identifiziert die im Portal abzubildenden kundennahen Prozesse und fasst sie in Prozessbündeln
zusammen.
Die Anwendungsarchitektur beschreibt den Aufbau des Portals. Hierfür wird ein portalspezifisches 3-
Schicht-Modell mit den Schichten Portalanwendungskomponenten, Portalsystemkomponenten und
Betriebliche Informationskomponenten abgeleitet. Es unterstützt Softwarekomponenten im Sinne
eines Komponentenmodells und eigenständige Systeme, die wiederum selbst nach beliebigen
Schichtenmodellen aufgebaut sein können. Den einzelnen Schichten werden die abstrakten
Komponenten der Komponentenarchitektur zugeordnet. Die Verwendung abstrakter Komponenten
gewährleistet eine Unabhängigkeit der Architektur während des Entwurfs und stellt bei der Abbildung
auf reale Systeme die Berücksichtigung individueller Gegebenheiten der Infrastruktur sicher. Die
Ableitung der Komponenten der Schicht Portalanwendungskomponenten erfolgt direkt aus den
Prozessen des Technischen Vertriebs. Die Funktionalität dieser Komponenten wird aus Funktionen der
Komponenten der beiden anderen Schichten zusammengesetzt. Die Architektur definiert die
notwendigen Funktionen der Komponenten im Kontext eines Portals.
Die Datenarchitektur stellt die Stamm- und Bewegungsdaten, die während der Laufzeit der
Komponenten verwendet werden, in einer statischen Sicht in acht Grunddatenmodellen dar.
Im Rahmen der Infrastrukturbeschreibung, die als Infrastrukturarchitektur ausgeprägt wird, werden die
für den Betrieb des Portals notwendigen Funktionen beschrieben. Hierzu gehören insbesondere die
Suche, das Authentifizierungs- und Rollenmodell, Single Sign On und das Personalisierungs- und
Individualisierungsmodell. Enthalten ist ein Modell für die Abbildung der abstrakten Komponenten
auf reale Systeme.
Für die Kommunikationsarchitektur wurde ein Schnittstellen- und Datenformatmodell entwickelt. Die
Integration der einzelnen Komponenten wird mittels speziell auf die Anwendung in Portalen
abgestimmten Integrationsmustern beschrieben. Diese Teilsicht des Modells beinhaltet eine
Beschreibung von Adaptions- und Transformationsmethoden für Daten. Den Abschluss des
Architekturmodells bildet eine in UML beschriebene Methodik für die Anwendung des Architektur-
modells.
Die Arbeit beinhaltet drei Einsatzfälle des Architekturmodells, wobei die Portalarchitektur für den
Vertrieb von Elektrowerkzeugen ausführlich dargestellt wird. Die abschließende Bewertung des
praktischen Einsatzes zeigt, dass das Architekturmodell für Portale im Technischen Vertrieb den
gestellten Anforderungen gerecht wird.
12.2 Ausblick und weitere Entwicklungen
Das entwickelte Architekturmodell für Portale im Technischen Vertrieb beschreibt die Architektur mit
einer mittleren Granularität, die einen weiten Raum für individuelle Varianten zulässt.
Eine sinnvolle Erweiterung des Modells ist die Vorgabe von Referenzprozessen für den Technischen
Vertrieb. Ausgehend von den Referenzprozessen können die enthaltenen Teilarchitekturen entlang
dieser Prozesse feiner ausgestaltet und damit der Arbeitsaufwand für eine Instanzbildung reduziert
werden. Durch die Vorgabe von Prozessen wird jedoch auch die Einsatzfähigkeit des Modells
eingeschränkt. Das Modell deckt aus Sicht des Software-Engineering die Bereiche
131
Systemanforderung, Softwareanforderung, Analyse und Entwurf ab. Die enthaltenen Teilmodelle
bilden eine Grundlage für die in diesen Projektphasen notwendigen Arbeiten. Um einen
durchgängigen Informationsfluss durch alle Projektphasen während eines gesamten Portalprojekts zu
erreichen, ist eine Einbindung in ein Vorgehensmodell für die Konzeption, Entwicklung und
Einführung von Portalen, wie z. B. der Fraunhofer Portal Analyse und Design Methode (PADEM)1,
erforderlich. Das Architekturmodell für Portale im Technischen Vertrieb kann in diesem Kontext in
einem Softwarewerkzeug für die Erfassung der bestehenden betrieblichen Informationssysteme und
die Modellierung der Teilsichten des Portals abgebildet werden. Eine Einbindung in portalspezifische
Softwarewerkzeuge ist möglich und wünschenswert.
1 Portal Analyse und Design Methode PADEM®, vgl. [Gurzki et al. 2004]
13 Summary
The thesis develops an integrated architectural model for business portals with a special focus on
reproducing the processes of technical sales and distribution while taking into account both new and
legacy systems.
Companies involved in selling and distributing technical products are increasingly facing the need to
achieve a paramount position in the marketplace. To be able to do so, companies need to intensify
customer contact and customer loyalty by means of processes adapted to individual customer
requirements, while at the same time increasing efficiency and realizing cost savings in technical sales
and distribution departments. Portals offer a technical solution for providing a homogeneous user
interface and access to integrated and personalized processes. Portal based process integration requires
a comprehensive architecture which takes into account also a company’s information systems
infrastructure.
Based on these assumptions, the thesis starts with identifying the basic characteristics of Web based
portals. This comprises aspects such as personalization, role based interaction, user management,
process orientation, integration and homogeneity. In parallel, the specific characteristics and tasks of
technical sales departments are analyzed. Main aspects here are marketing and advertisement,
provision of information, consulting, sales conclusion and after-sales support. When examining the
system landscape of technical sales and distribution departments, it becomes apparent that there are a
lot of different systems which - to a considerable extent - provide the same functionality.
Following the Software Engineering approach, the thesis investigates software architectures for
creating Web based applications, such as, for example, embedded script languages, platform concepts
like Java and .NET, integration architectures, portal software and portal architecture models. The aim
of the analysis is to evaluate these approaches in terms of their contribution to constitute an
architecture for portals that can be used for technical sales and distribution. Core criteria are, among
others, the structural requirements and granularity of the component model, which determine the
capability to integrate legacy systems.
Shortcomings of the current situation can be identified in various respects. First of all, there is no fully
elaborated architectural model for portals for technical sales and distribution available which includes
components such as strategy, structural organization architecture, process architecture, application
architecture, data architecture, communication architecture and infrastructure. Furthermore, there is a
lack in the definition of functional requirements concerning portal related applications used by
technical sales and distribution departments. And finally, portals are generally not characterized by a
consistent structure in terms of software engineering. Based on these shortcomings, criteria for a later
evaluation of the architectural model are developed.
The basis of an architectural model for portals for technical sales and distribution is an application
specific extension of a generic architectural model. So the thesis draws upon an existing approach,
named Information Systems Architecture (ISA), which comprises a number of components: strategy,
structural organization architecture, process architecture, application architecture, data architecture,
communication architecture and infrastructure.
The sub models strategy and structural organization are taken for granted, as they are implied by the
concentration on the specific application field of technical sales and distribution. The process
133
architecture is developed on the basis of a survey among companies that have technical sales and
distribution departments. A main element of the process architecture is the portal process map, which
identifies close-to-the-customer processes that need to be reproduced in the portal and concentrates
these processes in process bundles.
The application architecture describes the portal’s structure. To do so, a three-layer model consisting
of portal application components, portal system components and enterprise information components is
developed. This model supports both software components and independent systems which themselves
can be structured according to specific layer models. The abstract components of the component
architecture are assigned to these individual layers. Using abstract components guarantees the
architecture’s independence during the design phase and ensures that individual infrastructural
conditions are taken into account when the model is applied in connection with real systems. The
portal application components are developed directly from the specific processes occurring in
technical sales and distribution. The functionality of these components is composed from the functions
of the components of the other two layers. The architecture defines the necessary functions of the
components in the specific context of a portal.
The data and communication architecture contains the master data and transaction data used during the
components’ runtime in a static perspective in eight basic-data models. The infrastructural architecture
describes the functions necessary for the portal’s operation, among them product search,
authentication and roles model, single sign-on and the personalization and individualization model.
The infrastructural architecture comprises also a model for applying the abstract components to real
systems. For the communication architecture, an interface and data format model is developed. The
integration of the components is described by means of integration patterns specifically designed for
being used in connection with portals. This part of the model contains a description of data adaptation
and transformation techniques. The work closes with an UML based methodology for applying the
architectural model.
The thesis comprises three usage scenarios of the architectural model, with a particularly extensive
description of the portal architecture for sales and distribution of electrical tools. The final evaluation
of the applicability of the architectural model shows that the architectural model clearly meets the
requirements for being used for portals in the field of technical sales and distribution.
14 Literatur und Quellen
[Abdelnur und Hepper 2003]
Abdelnur, A.; Hepper, S. (Hrsg.) (2003): Portlet Specification Version 1.0. Santa Clara: Java
Community Process.
[Achour et al 2005]
Achour, M.; Betz, F.; Dovgal, A.; Lopes, N. ; Olson, P.; Richter G. u. a. (2005): PHP Handbuch.
Hojtsy, Gabor (Hrsg.). http://www.php.net/manual/de/. Aufgerufen am 01.02.2005.
[Ackerschott 2001]
Ackerschott, H. (2001): Strategische Vertriebssteuerung. Verlag Dr. Th. Gabler.
[Alexander et al. 1977]
Alexander, C.; Ishikawa, S.; Silverstein, M.; Jacobson, M.; Fiksdahl-King, I.; Angel, S. (1977): A
Pattern Language. Oxford: Oxford University Press.
[Alt et al. 2004]
Alt, R.; Cäsar, M.; Leser, F.; Österle, H.; Puschmann, T.; Reichmayr, C. (2004): Architektur des
Echtzeit-Unternehmens. In: Alt, R.; Österle, H.: Real-time Business. Berlin, Heidelberg u. a.:
Springer-Verlag. Seite 20-51.
[Altenhofen et al. 2003]
Altenhofen, C.; Stanisić-Petrović, M.; Junker, M.; Kieninger, T.; Hofmann, H. (2003): Empirische
Studie zum Werkzeugeinsatz im Umfeld der Dokumentenverwaltung. Stuttgart: Fraunhofer IRB
Verlag.
[Altenhofen et al. 2003a]
Altenhofen, C.; Drawehn, J.; Höß, O.; Stanisić-Petrović, M.; Weisbecker, A. (2003):
Komponentenbasierte Softwareentwicklung – Adaptive Read Band 1. Stuttgart: Fraunhofer IRB
Verlag.
[Amberg et al. 2003]
Amberg, M.; Holzner, J.; Remus, U. (2003): Portal-Engineeering – Anforderungen an die
Entwicklung komplexer Unternehmensportale. In: Uhr, W.; Esswein, W. (Hrsg.):
Wirtschaftsinformatik 2003. Medien – Märkte – Mobilität. Heidelberg: Physica-Verlag. Seite 795-
818.
[Angeli 2003]
Angeli, A. (2003): Technische Integration von SAP-Systemen Webservices, EAI, Business
Collaboration. Bonn: Galileo Press.
[Armstrong et al. 2003]
Armstrong, E.; Bodoff, S.; Carson, D.; Evans, I.; Fisher, M.; Green, D., Haase, K.; Jendrock, E.;
Pawlan, M.; Stearns, B. (2003): J2EE 1.4 Tutorial. Santa Clara: Sun Microsystems.
135
[Bachem 2004]
Bachem, C. (2004): Die Rolle von Portalen im Multichannel-Marketing. In: Gentsch, P.; Lee, S.
(Hrsg.): Praxishandbuch Portalmanagement. Wiesbaden: Verlag Dr. Th. Gabler. Seite 137-155.
[Backhaus 2003]
Backhaus, K. (2003): Industriegütermarketing. 7. Auflage. München: Verlag Franz Vahlen.
[Balzert 1998]
Balzert, H. (1998): Lehrbuch der Software-Technik Band 2. Software-Management, Software
Qualitätssicherung, Unternehmensmodellierung. Heidelberg, Berlin: Spektrum Akademischer
Verlag.
[Balzert 2000]
Balzert, H. (2000): Lehrbuch der Software-Technik Band 1. Software-Entwicklung. 2. Auflage.
Heidelberg, Berlin: Spektrum Akademischer Verlag.
[Bamberger 2004]
Bamberger, R. (2004): Service-Portale im Maschinenbau. In: Gentsch, P.; Lee, S. (Hrsg.):
Praxishandbuch Portalmanagement. Wiesbaden: Verlag Dr. Th. Gabler. Seite 189-201.
[Bass et al. 2003]
Bass, L.; Pauls, C.; Kazman, R. (2003): Software Architecture in Practice. Second Edition. SEI
Series in Software Engineering. 2. Auflage. Boston: Pearson Education.
[Bauer 2001]
Bauer, H. (2001): Unternehmensportale, Geschäftsmodelle, Design, Technologie. Bonn: Galileo
Press.
[BEA 2003]
BEA Systems Inc. (2003): Portlet Basics http://e-docs.bea.com/workshop/docs81
/doc/en/portal/overview/conPortletBasics.html. Aufgerufen am 20. 10.2003.
[Bergmann et al. 2003]
Bergmann, R.; Traphöner, R.; Schmitt, S.; Cunningham, P.; Smyth, B. (2003): Knowledge-Intensive
Produkt Search and Customization in Electronic Commerce. In: Gásos, J.; Thoben, K.-D. (Hrsg.): E-
Business Applications. Berlin, Heidelberg u. a.: Springer-Verlag. Seite 87-101.
[Berndt et al. 2003]
Berndt, O.; Biffar, J.; Weiß, D. (2003): Dokumentenmanagement in Deutschland. Bonn: Verband
Organisations- und Informationssysteme e.V.
[Biesel 2002]
Biesel H. H. (2002): Kundenmanagement im Multi-Channel-Vertrieb. Strategien und Werkzeuge für
die konsequente Kundenorientierung. Wiesbaden: Verlag Dr. Th. Gabler.
136
[Boehm 1981]
Boehm, B. W. (1981): Software Engineering Economics. Upper Saddle River (New Jersey): Prentice
Hall.
[Boehm 1988]
Boehm, B. W. (1988): A Spiral Model of Software Development an Enhancement. In: IEEE
Computer, Vol. 21, Ausgabe 5, Mai 1988. Washington: IEEE Computer Society. Seite 61-72.
[Boiko 2002]
Boiko, B. (2002): Content Management Bible. New York : Hungry Minds.
[Bonart 1999]
Bonart, T. (1999): Industrieller Vertrieb. Wiesbaden: Verlag Dr. Th. Gabler.
[Borghoff und Schlichter 2000]
Borghoff, U. M.; Schlichter, J. H. (2000): Computer-Supported Cooperative Work. Berlin,
Heidelberg u. a.: Springer-Verlag.
[Brandstetter und Fries 2002]
Brandstetter, C.; Fries, M. (2002): E-Business im Vertrieb, Potenziale erkennen – Chancen nutzen –
Von der Strategie zur Umsetzung. München, Wien: Carl Hanser Verlag.
[Britton 2001]
Britton, C. (2001): IT Architectures and Middleware: Strategies for Building Large, Integrated
Systems. München, Boston u. a.: Addison-Wesley.
[Brown et al. 2001]
Brown, S.; Burdick R.; Falkner, J.; Galbraith, Ben; Johnson, Rod u. a. (2001): Professional JSP 2nd
Edition. Birmingham: Wrox Press.
[Buck-Emden und Zencke 2004]
Buck-Emden, R.; Zencke, P. (2004): mySAP CRM. Bonn: Galileo Press.
[Bullinger 1995]
Bullinger, H.-J. (1995): Vertrieb. In: Warnecke, H.-J.: Der Produktionsbetrieb 3: Betriebswirtschaft,
Vertrieb, Recycling. 3. Auflage. Berlin, Heidelberg u. a.: Springer-Verlag.
[Bullinger 2001]
Bullinger, H.-J. (Hrsg.); Schuster, E.; Wilhelm, S. (2001): Content Management Systeme –
Auswahlstrategien, Architekturen und Produkte. Stuttgart: Fraunhofer IRB Verlag.
[Bullinger 2002]
Bullinger, H.-J. (Hrsg.); Gurzki, T.; Hinderer, H.; Eberhardt, C.-T. (2002): Marktübersicht Portal
Software. Media Vision Expert. Stuttgart: Fraunhofer IRB Verlag.
137
[Bullinger et al. 1999]
Bullinger, H.-J.; Frielingsdorf, H.; Roth, N.; Wagner, F.; Zeichen, G.; Fürst, K.; Brandstätter, T.
(1999): Marktstudie Engineering Data Management Systeme. Stuttgart: Fraunhofer IAO.
[Bullinger et al. 2002a]
Bullinger, H.-J.; Baumann, T.; Fröschle, N.; Mack, O.; Trunzer, T.; Waltert, J. (2002): Business
Communities – Professionelles Beziehungsmanagement von Kunden, Mitarbeitern und B2B-
Partnern im Internet. Bonn: Galileo Press.
[Bullinger und Fähnrich 1997]
Bullinger, H.-J.; Fähnrich, K.-P. (1997): Betriebliche Informationssysteme. Grundlagen und
Werkzeuge der methodischen Softwareentwicklung. Berlin, Heidelberg u. a.: Springer-Verlag.
[Cheswick et al. 2003]
Cheswick, W. R.; Bellovin, S. M.; Rubin, A. D. (2003): Firewalls and Internet Security. München,
Boston u. a.: Addison-Wesley.
[Christ 2003]
Christ, O. (2003): Content Management in der Praxis. Berlin, Heidelberg u. a.: Springer-Verlag.
[Ciber 2004]
Ciber Deutschland GmbH, ohne Verfasser (2004): Alternativen der unterschiedlichen Anbindung
elektronischer Kataloge an SAP Systeme. www.ciber-germany.com/ger/pdf/Alternative_Konzepte
_einer_Content%20Anbindung_OCI_Anbindu.pdf. Aufgerufen am 15.04.2004.
[Collins 2001]
Collins, H. (2001): Corporate Portals – Revolutionizing Information Access to Increase Productivity
and Drive the BottomLine. New York: Amacom.
[Colyer et al. 2000]
Colyer, A. M.; Clement, A.; Longhurst, S. (2000): Applying Enterprise JavaBeans – Architecure &
Design. In: Net.ObjectDays2000 Tagungsband. Illmenau: Net.ObjectDays-Forum/tranSIT.
[cXML 2003]
cXML.org, ohne Verfasser (2003): cXML User’s Guide. Sunnyvale: Ariba.
[Dangelmaier 2001]
Dangelmaier, W. (Hrsg.); Holthöfer, N.; Szilàgyi, S. (2001): Marktstudie: Softwaresysteme zur
Produktkonfiguration. Paderborn: ALB/HNI-Verlagsschriftenreihe.
[Davydov 2001]
Davydov, M. (2001): Corporate Portals and E-Business Integration. New York, Chicago, San
Francisco: McGraw-Hill.
138
[Dias 2001]
Dias, C. (2001): Corporate portals: a literature review of a new concept in Information Management.
In: International Journal of Information Management 21 (2001) 4, Seite 269–287.
[DIN 16557-3]
Deutsches Institut für Normung DIN (Hrsg.), ohne Verfasser (1994): Elektronischer Datenaustausch
für Verwaltung, Wirtschaft und Transport (EDIFACT). Allgemeine Einführung für Einheitliche
Nachrichtentypen (UNSMs). DIN 16557-3. Berlin u. a.: Beuth Verlag.
[DIN 199-1]
Deutsches Institut für Normung (Hrsg.), ohne Verfasser (2002): DIN 199-1 Technische
Produktdokumentation - CAD-Modelle, Zeichnungen und Stücklisten - Teil 1: Begriffe. Ausgabe
2002-03. Berlin u. a.: Beuth Verlag.
[Dröschel et al. 1998]
Dröschel, W.; Heuser, W.; Midderhoff, R. (1998): Inkrementelle und objektorientierte
Vorgehensweisen mit dem V-Modell 97. München, Wien: Oldenbourg.
[Eeles und Sims 1998]
Eeles, P.; Sims, O. J. (1998): Building Business Objects. New York u. a.: Wiley & Sons.
[Eisenberg und Duane 2001]
Eisenberg, B.; Nickull, D. (Hrsg.) (2001): ebXML Technical Architecture Specification. Ohne
Ortsangabe: UN/CEFACT, OASIS.
[Erdogan et al 2002]
Erdogan, N.; Lüning, U.; Passenberg, I.; Schomberg, V.; Thiemann, R.; Waldmann, R. (2002):
Wegweiser Katalogmanagement. Wesentliche Erfolgsfaktoren für E-Procurement-Projekte.
Frankfurt: PricewaterhouseCoopers.
[Fähnrich et al. 2000]
Fähnrich, K.-P.; Weisbecker, A.; Höß, O.; Kunsmann J. (2000): Componentware – Vom Trend zum
industriellen Einsatz. In: Bullinger, H.-J. (Hrsg.): Komponentenbasierte Software für Produkte und
Dienstleistungen – Erfahrungen und Projektberichte. Stuttgart: Fraunhofer IRB Verlag.
[Fink et al. 2001]
Fink, H.-J.; Hosie, P.; Huning, J.; Ladewig, T. (2001): SAP R/3. Reinbek bei Hamburg: Rowohlt
Taschenbuch Verlag.
[Frech et al. 2000]
Frech, J.; Schwarz, J.; Wagner, F. (2000): Marktstudie Computer Aided Selling Systeme zur
Produktkonfiguration. Stuttgart: Fraunhofer IRB Verlag.
[Galic et al. 2003]
Galic, M.; Cramer, L.; Rao, R.; Wolfe, M. (2003): A Portal Composite Pattern Using WebSphere
V4.1. New York: IBM Redbooks.
139
[Gamma et al 1995]
Gamma, E.; Helm, R.; Johnsin, R.; Vlissides, J. (1997): Design Patterns. Elements of Reusable
Object-Oriented Software. München, Boston u. a.: Addison-Wesley.
[García-Serrano et al. 2001]
García-Serrano, A.; Hernández, J. Z.; Martínez, P. (2001): Intelligent Assistance to E-Commerce. In:
Stanford-Smith, B.; Chiozza, E. (Hrsg.): E-Work and E-Commerce, Volume I. Amsterdam, Berlin:
IOS Press. Seite 312-318.
[Gehring und Gadatsch 1999]
Gehring, H.; Gadatsch A. (1999): Eine Rahmenarchitektur für Workflow-Management-Systeme.
Fachbereichsbericht Nr. 275. Hagen: FernUniversität Hagen.
[Gloor 2000]
Gloor, P. (2000): Making the E-Business Transformation. Berlin, Heidelberg u. a.: Springer-Verlag.
[Godefroid 1998]
Godefroid, P. (1998): Der Direktvetrieb auf Business-to-Business-Märkten. In: Pepels, W. (Hrsg.):
Absatzpolitik. München: Verlag Franz Vahlen. Seite 80-102.
[Goebel und Ritthaler 2004]
Goebel, A.; Ritthaler, D. (2004): SAP Enterprise Portal. Technologie und Programmierung. Bonn:
Galileo Press.
[Graf 2003]
Graf, F. (2003): Virtuelle Vertreter in der Welt des E-Commerce. In: Meyer, H. (Hrsg.): Netzwoche.
Nr. 19, Mai 2003. Basel: Netzmedien. Seite 11.
[Grasl 2003]
Grasl, O., (2003): J2EE und .NET: Kein Vergleich?. In: Mörike, M. (Hrsg.):
Entwicklungsplattformen Java versus .NET. HMD Praxis der Wirtschaftsinformatik, Ausgabe 230.
Heidelberg: dpunkt.verlag. Seite 7-14.
[Gray und Reuter 1993]
Gray, J.; Reuter, A. (1993): Transaction Processing – Concepts and Technologies. San Mateo:
Morgan Kaufmann Publishers.
[Griffel 1998]
Griffel, F. (1998): Componentware: Konzepte und Techniken eines Softwareparadigmas. Heidelberg:
dpunkt.verlag.
[Grigo 2003]
Grigo, W. (2003): Elektronische Zusammenarbeit zwischen dem Reifenhandel und der
Reifenindustrie. Block 3 – Standards + EDIWheel. RVS - Workshop am 25. März 2003.
www.swisspneu.ch/edi/EDI_Standards.pdf. Aufgerufen am 28.04.2004.
140
[Grimes 2002]
Grimes, F. (2002): Microsoft .NET for Programmers. Greenwich: Manning Publications.
[Grimm 2003]
Grimm, S. (2003): Der Portalmarkt im Wandel: Portale als ein Instrument zur Kostensenkung.
Funktionen, Architektur, Vorgehen. Version 4, Mai 2003. Stuttgart: AbaXX Technology AG.
[Grimm 2004]
Grimm, S. (2004): Die Entwicklung des Portalmarktes. In: Gentsch, Peter; Lee, Sue (Hrsg.):
Praxishandbuch Portalmanagement. Wiesbaden: Verlag Dr. Th. Gabler. Seite 277-295.
[Grudin 1994]
Grudin, J. (1994): CSCW: History and Focus. In:. Carver, Doris L. (Hrsg.): IEEE Computer Ausgabe
5/1994, 27. Jahrgang. Washington, Los Alamitos: IEEE. Seite 19-26.
[Guelich et al. 2001]
Guelich, S.; Gundavaram, S.; Birznieks, G. (2001): CGI Programmierung mit Perl. Sebastopol, Köln
u. a.: O’Reilly.
[Gurzki 2001]
Gurzki, T. (2001): An Architecture for Integrating Virtual Sales Assistant Technology into E-
Business Environments. In: Stanford-Smith, B.; Chiozza, E. (Hrsg.): E-Work and E-Commerce.
Novel solutions and practices for a global networked economy. Volume 1. Amsterdam
u. a.: IOS Press. Seite 305-311.
[Gurzki 2002]
Gurzki, T. (2002): Einfach, schwierig – einfach schwierig: Die Wahl der richtigen Portal-Software.
In: IS.report. Magazin für betriebliche Informationssysteme, Ausgabe März 2002. München: Oxygon
Verlag. Seite 34-36.
[Gurzki 2004]
Gurzki, T. (2004): Portaltechnologie. In: Gentsch, P.; Lee, S. (Hrsg.): Praxishandbuch
Portalmanagement. Wiesbaden: Verlag Dr. Th. Gabler. Seite 27-42.
[Gurzki et al. 2003]
Gurzki, T.; Schweizer, P.; Eberhardt, C.-T. (2003): A Virtual Sales Assistant Architecture for E-
Business Environments. In: Gasós, J.; Thoben, K.-D. (Hrsg.): E-Business Applications. Technologies
for Tomorrow’s Solutions. Berlin, Heidelberg u. a.: Springer-Verlag. Seite 77-86.
[Gurzki et al. 2004]
Gurzki, T.; Hinderer, H.; Kirchhof, A.; Vlachakis, J. (2004): Die Fraunhofer Portal Analyse und
Design Methode (PADEM) – Der effiziente Weg vom Prozess zum Portal. Stuttgart: Fraunhofer
IAO.
141
[Gurzki und Hinderer 2003]
Gurzki, T.; Hinderer, H. (2003): Eine Referenzarchitektur für Software zur Realisierung von
Unternehmensportalen. In: Reimer, U.; Abecker, A.; Staab, S.; Stumme, G. (Hrsg.): WM 2003:
Professionelles Wissensmanagement - Erfahrungen und Visionen; GI-Edition - Lecture Notes in
Informatics (LNI). Bonn: Gesellschaft für Informatik e.V. Seite 157-160.
[Gurzki und Özcan 2003]
Gurzki, T.; Özcan, N. (2003): Unternehmensportale: Kunden-, Lieferanten- und Mitarbeiterportale in
der betrieblichen Praxis. Stuttgart: Fraunhofer IRB Verlag.
[Harms 1999]
Harms, V. (1999): Kundendienstmanagement: Dienstleistung, Kundendienst, Servicestrukturen und
Serviceprodukte; Aufgabenbereiche und Organisation des Kundendienstes. Herne, Berlin: Verlag
Neue Wirtschaftsbriefe.
[Harms und Luckhardt 2004]
Harms, I.; Luckhardt, H.-D. (2004): Virtuelles Handbuch Informationswissenschaft. Universität des
Saarlandes, Fachbereich Informationswissenschaft.
http://is.unisb.de/studium/handbuch/scheer.erw.php. Aufgerufen am 01.05.2004.
[Hauser und Löwer 2003]
Hauser, T.; Löwer, U. M. (2003): Web Services - Die Standards. Bonn: Galileo Press.
[Hentrich 2001]
Hentrich, J. (2001): B2B-Katalog-Management, E-Procurement und Sales im Collaborative
Business. Bonn: Galileo Press.
[Hermes 1999]
Hermes, P. (1999): Entwicklung eines Customer Self-Service-Systems im Technischen
Kundendienst des Maschinenbaus. Heimsheim: Jost-Jetter Verlag.
[Highmoor et al. 2003]
Highmoor, S.; Caccamo, M.; Carter, J.; Harvey, R. (2003): Oracle Application Server Portal User’s
Guide10g. Redwood City: Oracle.
[Hildebrand 2003]
Hildebrand, U. (2003): Wer Edifact kann, ist für XML gerüstet. In: Computerwoche Nr. 1/2 vom
10.01.2003. München: IDG Business Verlag.
[Hinderer und Gurzki 2003]
Hinderer, H.; Gurzki, T. (2003): Prozessorientierte Wirtschaftlichkeitsbetrachtung von
Unternehmensportalen. In: Reimer, U.; Abecker, A.; Staab, S.; Stumme, G. (Hrsg.): WM 2003:
Professionelles Wissensmanagement - Erfahrungen und Visionen; GI-Edition - Lecture Notes in
Informatics (LNI). Bonn: Gesellschaft für Informatik e.V. Seite 161-164.
142
[Hippner und Wilde 2001]
Hippner, H.; Wilde, K. D. (2002): CRM- Ein Überblick. In: Helmke, S.; Übel, M.; Dangelmaier, W.
(Hrsg.): Effektives Customer Relationship Management. 2. Auflage. Wiesbaden: Verlag Dr. Th.
Gabler. Seite 3-37.
[Hitz und Kappel 1999]
Hitz, M.; Kappel, G. (1999): UML@Work: von der Analyse zur Realisierung. Heidelberg:
dpunkt.verlag.
[Hufgard 1996]
Hufgard A. (1996) Betriebswirtschaftliche Softwarebibliotheken und Adaption. München: Verlag
Franz Vahlen.
[Hümpel und Schmitz 2001]
Hümpel, C.; Schmitz, V. (2001): BMEcat - Produktkataloge austauschen per XML. In: Turowski, K.;
Fellner, K. (Hrsg.): XML in der betrieblichen Praxis: Standards, Möglichkeiten, Praxisbeispiele.
Heidelberg: dpunkt.verlag. Seite 205-217.
[Intershop 1999]
Intershop, ohne Verfasser (1999): Intershop Enfinity. Design: Using Templates and ISML. Jena:
Intershop Communications.
[ISO 8879]
ISO (Hrsg.), ohne Verfasser (1986): ISO 8879:1986. Standard Generalized Markup Language
(SGML). Genf: International Organization for Standardization (ISO).
[ISO 9735]
International Organization für Standardization ISO (Hrsg.), ohne Verfasser (1988): Directories for
Electronic Data Interchange for Administration, Commerce and Transport ISO 9735. Genf:
International Organization für Standardization.
[Jablonski und Meiler 2002]
Jablonski, S.; Meiler, C. (2002): Web-Content-Managementsysteme. In: Informatik Spektrum,
Ausgabe 18, April 2002. Berlin, Heidelberg u. a.: Springer-Verlag. Seite 101-119.
[Jacob 1998]
Jacob, F. (1998): Auftragsmanagement. In: Kleinaltenkamp, M.; Plinke, W. (Hrsg.): Auftrags- und
Projektmanagement – Projektbearbeitung für den technischen Vertrieb. Berlin, Heidelberg u. a.:
Springer-Verlag. Seite 1-66.
[JSR 170]
JCP (Hrsg.), ohne Verfasser (2004): JSR-000170 Content Repository for Java TM Technology API.
http://jcp.org/aboutJava/communityprocess/review/jsr170/index.html. Aufgerufen am 01.05.2004.
[JSR 94]
JCP (Hrsg.), ohne Verfasser (2004): JSR-000094 Java TM Rule Engine API (Proposed Final Draft).
http://jcp.org/aboutJava/communityprocess/first/jsr094/index.html. Aufgerufen am 01.05.2004.
143
[Kampffmeyer 2004]
Kampffmeyer, U. (2004): Konsolidierung des DRT-Marktes.
http://www.contentmanager.de/magazin/artikel_404_konsolidierung_drt_markt.html. Aufgerufen am
01.04.2004.
[Kelkar 2003]
Kelkar, O. (2003): Ein Referenzmodell für elektronische Geschäftstransaktionen im
zwischenbetrieblichen Geschäftsverkehr. Heimsheim: Jost-Jetter Verlag.
[Kelkar et al. 2001]
Kelkar, O.; Otto, B.; Schmitz, V. (2001) : Spezifikation OpenTrans Version 1.0. Stuttgart, Essen:
Fraunhofer IAO, Universität Essen.
[Kelkar et al. 2003]
Kelkar, O.; Renner, T.; Lebender, M.; Lorenz, O.; Dannecker, S. (2003): eBusiness-Konjunktur-
barometer. Berlin: Wegweiser.
[Keller 2002]
Keller, W. (2002): Enterprise Application Integration – Erfahrungen aus der Praxis. Heidelberg:
dpunkt.verlag.
[Kempf 2003]
Kempf, F. (2003): Referenzmodell zur integrierten Kommunikationsunterstützung von
kooperierenden, örtlich verteilten Akteuren. Heimsheim: Jost-Jetter Verlag.
[Kerpen 2004]
Kerpen, C. (2004): Mach auf das Tor! JSR 168, die Portlet-Spezifikation. In: Javamagazin, Ausgabe
10/2004. Frankfurt/Main: Software & Support Verlag. Seite 34-37.
[Kleinaltenkamp 2000]
Kleinaltenkamp, M. (2000): Einführung in das Business-to-Business Marketing. In: Kleinaltenkamp,
M.; Plinke, W. (Hrsg.): Technischer Vertrieb. 2. Auflage. Berlin, Heidelberg u. a.: Springer-Verlag.
[Klünter und Laser 2003]
Klünter, D.; Laser, J. (2003): LDAP verstehen, OpenLDAP einsetzen. Heidelberg: dpunkt.verlag.
[Kotler 1997]
Kotler, P. (1997): Marketing Management. Upper Saddle River (New Jersey): Prentice Hall.
[KPMG 2000]
KPMG (Hrsg.), ohne Verfasser (2000): Electronic Sales – Standardsoftware für integrierte
Shopsysteme. München: KPMG Consulting.
[Krause 2002]
Krause, J. (2002): Active Server Pages. Programmierung dynamischer, datenbankgestützter
Webseiten. 3. Auflage. München, Boston u. a.: Addison-Wesley.
144
[Krcmar 1990]
Krcmar, H. (1990): Bedeutung und Ziele von Informationssystem-Architekturen. In:
Wirtschaftsinformatik, Heft 5/1990. Braunschweig, Wiesbaden: Vieweg. Seite 395-402.
[Krcmar 2003]
Krcmar, H. (2003): Informationsmanagement. 3. Auflage. Berlin, Heidelberg u. a.: Springer-Verlag.
[Kropp et al. 2003]
Kropp, A.; Leue, C.; Thompson, R. (Hrsg.) (2003): Web Services for Remote Portlets Specification.
Billerica: OASIS.
[Kuhn 2003]
Kuhn, S. (2003): Portale. In: Theis, F. (Hrsg.): Portale und Webapplikationen mit Apache
Frameworks. Frankfurt/Main: Software & Support Verlag. Seite 215-223.
[L’Abbate und Thiel 2001]
L’Abbate, M.; Thiel, U. (2001): Intelligent Product Information Search in E-Commerce. Retrieval
Strategies for Virtual Shop Assistants. In: Stanford-Smith, B.; Chiozza, E. (Hrsg.): E-Work and E-
Commerce, Volume I. Amsterdam, Berlin: IOS Press. Seite 347-353.
[Leimstoll und Schubert 2002]
Leimstoll, U.; Schubert, P. (2002): Personalisierung von E-Commerce-Applikationen in KMU:
Schlussfolgerungen aus einer empirischen Untersuchung. In: Weinhardt, C.; Holtmann, C. (Hrsg.),
E-Commerce: Netze, Märkte, Technologien. Heidelberg: Physica-Verlag. Seite 143-158.
[Leser et al. 2004]
Leser, F. ; Alt, R. ; Sänger, E.; Sobek, W. (2004) : Systeme für Echtzeit-Portale – ein Überblick am
Beispiel Banking. In: Alt, R.; Österle, H. (Hrsg.): Real-Time Business. Berlin, Heidelberg u. a.:
Springer-Verlag. Seite 116-132.
[Limper 2000]
Limper, W. (2000): Dokumentenmanagement. München: Deutscher Taschenbuch Verlag.
[Lindwood und Minter 2004]
Linwood, J.; Minter, D. (2004): Building Portals with the Java Portlet API. Berkeley: Apress.
[Linthicum 2000]
Linthicum, D. S. (2000): Enterprise Application Integration. München, Boston u. a.: Addison-
Wesley.
[Lixenfeld 2003]
Lixenfeld, C. (2003): Portale gegen das Informationschaos. In: Computerwoche Fokus Mittelstand
01.09.2003. München: IDG Business Verlag.
145
[Macromedia 2005]
Macromedia (Hrsg.) (2005): Coldfusion MX 7 Livedocs.
http://livedocs.macromedia.com/coldfusion/. Aufgerufen am 01.02.2005.
[Mertens 1997]
Mertens, P. (1997): Integrierte Informationsverarbeitung. Wiesbaden: Verlag Dr. Th. Gabler.
[Merz 2002]
Merz, M. (2002) : E-Commerce und E-Business: Marktmodelle, Anwendungen und Technologien.
Heidelberg: dpunkt.verlag.
[META Group 2002]
META Group (2002): E-Environments – Der Aufbau von Portal Frameworks. Ismaning: META
Group.
[Mucha und Ulrich 2000]
Mucha, M.; Ulrich, A. (2000): Clearing Center für Produktdatenmanagement. In: VEG
ElektroWirtschaft, Nr 7/2000. Dortmund: Fachverlag Dr. H. Arnold. Seite 27-29.
[Muschalla 1987]
Muschalla, H. (1987): Information als Erfolgsfaktor im Vertrieb. In: Tagungsband VDI:
Vertriebsorganisation im Wandel. Düsseldorf: VDI-Verlag.
[Muther 2002]
Muther, A. (2002): Customer Relationship Management. Berlin, Heidelberg u. a.: Springer-Verlag.
[Novell 2004]
Novell (Hrsg.), ohne Verfasser (2004): Novell Nsure Identity Manager 2 Administration Guide.
Waltham: Novell.
[Oestereich 2001]
Oestereich, B. (2001): Objektorientierte Softwareentwicklung. München, Wien: Oldenbourg.
[OMG 2003]
Object Management Group, ohne Verfasser (2003): OMG Unified Modeling Language Specification
Version 1.5. Needham: Object Management Group.
[Orfali et al. 1996]
Orfali, R.; Harkey, D., Edwards, J. (1996): The Essential Distributed Objects Survival Guide. New
York u. a.: Wiley and Sons.
[Österle 2002]
Österle, H. (2002): Business Networking in der Unternehmenspraxis. Berlin, Heidelberg u. a.:
Springer-Verlag.
146
[Ottmann und Widmayer 1993]
Ottmann, T.; Widmayer, P. (1993): Algorithmen und Datenstrukturen. 2. Auflage. Mannheim,
Leipzig, Wien, Zürich: BI Wissenschaftsverlag.
[Otto 2003]
Otto, B. (2003): Referenzmodell zur Automatisierung zwischenbetrieblicher Beschaffungsprozesse.
Heimsheim: Jost-Jetter Verlag.
[Pepels 1998]
Pepels, W. (1998): Technischer Vertrieb. Berlin: Cornelsen.
[Picot et al.. 2003]
Picot, A.; Reichwald, R. ; Wigand, R. T. (2003): Die grenzenlose Unternehmung. Information,
Organisation und Management. 4. Auflage. Wiesbaden: Verlag Dr. Th. Gabler.
[Puschmann 2003]
Puschmann, T. (2003): Collaboration Portale: Architektur, Integration, Umsetzung und Beispiele.
Bamberg: Difo-Druck.
[Puschmann 2004]
Puschmann, T. (2004): Prozessportale. Berlin, Heidelberg u. a.: Springer-Verlag.
[Puschmann und Alt 2004]
Puschmann, T.; Alt, R. (2004): Echtzeit-Integration für Prozessportale in der Automobilindustrie. In:
Alt, R.; Österle, H. (Hrsg.): Real-Time Business. Berlin, Heidelberg u. a.: Springer-Verlag. Seite
172-190.
[Quantz und Wichmann 2003]
Quantz, J.; Wichmann, T. (2003): Basisreport Integration mit Web Services. Konzept, Fallstudien
und Bewertung. Berlin: Berlecon Research.
[Rackham 1999]
Rackham, N. (1999): Rethinking the Sales Force. Redefining Selling to Create and Capture Customer
Value. New York, Chicago, San Francisco: McGraw-Hill.
[Reichmayr 2003]
Reichmayr, C. (2003): Collaboration und WebServices. Architekturen, Portale, Techniken und
Beispiele. Berlin, Heidelberg u. a.: Springer-Verlag.
[Renner und Schwengels 2000]
Renner, T.; Schwengels, C. (2000): Electronic Commerce in Vertrieb und Beschaffung. Fallstudien
zum Einsatz von internetbasierten Technologien für Vertrieb und Beschaffung. Arbeitsbericht Nr.
179 der Akademie für Technikfolgenabschätzung in Baden-Württemberg. Stuttgart: Akademie für
Technikfolgenabschätzung.
147
[Reynolds 2003]
Reynolds, H. (2003): Portlet Standards. In: Portals Magazine, Ausgabe April 2003. Los Angeles,
New York: Line56 Media. Seite 39-41.
[Richter 2002]
Richter, J. (2002): Microsoft .NET Framework Programming. Unterschleißheim: Microsoft Press.
[Ritter 2003]
Ritter, B. (2003): Das ERP-Pflichtenheft. Bonn: verlag moderne industrie Buch.
[Rogoll und Piller 2003]
Rogoll, T. A.; Piller, F. (2003): Konfigurationssysteme für Mass Customization und
Variantenproduktion. Marktstudie 2003. München: ThinkConsult.
[Röhrl et al. 2002]
Röhrl, A.; Schmiedl, S.; Wyss, C. (2002): Programmieren mit Ruby. Eine praxisorientierte
Einführung. Heidelberg: dpunkt.verlag.
[RosettaNet 2004]
RosettaNet (Hrsg.), ohne Verfasser (2004): Standards and Specifications.
http://www.rosettanet.org/standards. Aufgerufen am 01.03.2005.
[Rossbach und Schreiber 1999]
Rossbach, P.; Schreiber, H. (1999): Java-Server und Servlets. Bonn, Reading: Addison-Wesley-
Longman.
[Rothfuss 2001]
Rothfuss, G.; Ried, C. (2001): Content Management mit XML. Berlin, Heidelberg u. a.: Springer-
Verlag.
[Royce 1970]
Royce, W. W. (1970): Managing the development of large software systems. In: Proceedings of the
9th International Conference of Software Engineering. Nachdruck des Artikels aus IEEE WESCON,
1970 Seite 1-9. Monterey: Computer Society Press. Seite 328-338.
[Rütschlin 2001]
Rütschlin, J. (2001): Ein Portal- Was ist das eigentlich? In: Bauknecht, K.; Brauer, W.; Mück, T.
(Hrsg.): Informatik 2001: Wirtschaft und Wissenschaft in der Network Economy – Visionen und
Wirklichkeit. Tagungsband der GI/OCG-Jahrestagung, 25.-28. September 2001. Wien: Universität
Wien. Seite 691-696.
[Sametinger 1997]
Sametinger, J. (1997): Software Engineering with Reusable Components. Berlin, Heidelberg u. a.:
Springer-Verlag.
148
[SAP 2002]
SAP AG (Hrsg.), ohne Verfasser (2002): mySAP Technology Portal Infrastruktur:
Benutzerorientierte Integration und Zusammenarbeit; Whitepaper Version 1.1. Walldorf: SAP AG.
[Scheer 1998]
Scheer, A.-W. (1998): ARIS. Vom Geschäftsprozeß zum Anwendungssystem. 3. Auflage. Berlin,
Heidelberg u. a.: Springer-Verlag.
[Scheer 1998a]
Scheer, A.-W. (1998): Wirtschaftsinformatik – Referenzmodelle für industrielle Geschäftsprozesse.
Berlin, Heidelberg u. a.: Springer-Verlag.
[Scheer und Galler 1995].
Scheer, A.-W.; Galler, J.; Peter, S. (1995): Workflow-Projekte: Erfahrungen aus Fallstudien und
Vorgehensmodell. Forschungsberichte des Instituts für Wirtschaftsinformatik. Saarbrücken:
Universität des Saarlandes.
[Schelp und Winter 2002]
Schelp, J.; Winter, R. (2002): Enterprise Portals und Enterprise Application Integration.
Begriffsbestimmung und Integrationskonzeptionen. In: Meinhardt, S.; Popp, K. (Hrsg.): HMD –
Praxis der Wirtschaftsinformatik, Band 150: Enterprise Portale & Enterprise Application Integration.
Heidelberg: dpunkt.verlag. Seite 6-20.
[Schmalz 2004]
Schmalz, R. (2004): Semantic Web Technologien für das Wissensmanagement. Schumann, Matthias
(Hrsg.): Arbeitsbericht 1/2004, Institut für Wirtschaftsinformatik, Georg-August-Universität
Göttingen. Göttingen: Georg-August-Universität.
[Schmid 2001]
Schmid, R. (2001): Architektur für CRM und Prozess-Portale in Banken. Dissertation Universität St.
Gallen. St. Gallen: Universität St. Gallen.
[Schmitz et al. 2001]
Schmitz, V.; Kelkar, O.; Pastoors, T. (2001): Spezifikation BMEcat 1.2. Stuttgart: Fraunhofer IAO,
Essen: Universität Essen.
[Schneck 1998]
Schneck, O. (Hrsg); Hahn, K.; Schramm, U.; Stelzer, M. (1998): Lexikon der Betriebswirtschaft.
München: Deutscher Taschenbuch Verlag.
[Schneider und Zwerger 2002]
Schneider, G.; Zwerger, F. (2002): Sichere Unternehmensportale mit SAP. Bonn: Galileo Press.
[Schott und Mäurer 2001]
Schott, K.; Mäurer, R. (2001): Auswirkungen von EAI auf die IT-Architektur in Unternehmen. In:
Information Management & Consulting. Ausgabe März 2001, 16. Jahrgang. Saarbrücken: mc
information multimedia Communication. Seite 39-42.
149
[Schwichtenberg 2003]
Schwichtenberg, H. (2003): Arbeitsteilung – Komponentenbasierte Websiteentwicklung mit
ASP.NET. In: iX Special – Programmieren mit .NET. Ausgabe 01/2003. München: Heise
Zeitschriften Verlag.
[Seeboerger-Weichselbaum 2001]
Seeboerger-Weichselbaum, M. (2001): Das Einsteigerseminar XML. Bonn: verlag moderne industrie
Buch.
[Shirley et al. 1994]
Shirley, J.; Hu, W.; Magid, D. (1994): Guide to Writing DCE Applications. Sebastopol, Köln u. a.:
O’Reilly.
[Singh et al. 2002]
Singh, I.; Stearns, B.; Johnson, M. (2002): Designing Enterprise Applications with the J2EE
Platform, Second Edition. New York, London, München: Eddison-Wesley.
[Slama et al. 1999]
Slama, D.; Garbis, J.; Russell, P. (1999): Enterprise Corba. Upper Saddle River (New Jersey):
Prentice Hall.
[Sommerville 2001]
Sommerville, Ian (2001): Software Engineering. München, Boston: Addison-Wesley.
[Spath 2003]
Spath, D. (Hrsg.); Wilhelm, S. (2003): Information und Kommunikation in der Produktion.
Ergebnisse einer Unternehmensbefragung. Stuttgart: Fraunhofer IRB Verlag.
[Starke 2002]
Starke, G. (2002): Effektive Software-Architekturen. München, Wien: Carl Hanser Verlag.
[Sullivan 2003]
Sullivan, D. (2003): Proven Portals – Best Practices for Planning, Designing and Developing
Enterprise Portals. München, Boston u. a.: Addison-Wesley.
[Sun 2002]
Sun Microsystems (Hrsg.), ohne Verfasser (2002): Sun ONE Architecture Guide – Delivering
Services on Demand. Palo Alto: Sun Microsystems.
[Sun 2003]
Sun Microsystems (Hrsg.), ohne Verfasser (2003): J2EE Connector Architecture Specification. Santa
Clara: Sun Microsystems.
[Sun 2003a]
Sun Microsystems (Hrsg.); Roth, M.; Pelegrí-Llopart , E. (2003): Java Server Pages Specification
Version 2.0. Palo Alto: Sun Microsystems.
150
[Theis 2003]
Theis, F. (2003): Webapplikationen: Architekturen und Frameworks. In: Theis, F. (Hrsg.): Portale
und Webapplikationen mit Apache Frameworks. Seite 23-43.
[Thurau 1999]
Thurau, Volker (1999): Techniken zur Realisierung Web-basierter Anwendungen. In: Informatik-
Spektrum 22. Berlin, Heidelberg u. a.: Springer-Verlag.
[Tseng und Piller 2003]
Tseng, M. M.; Piller, F. (2003): The Customer Centric Enterprise. In: Tseng, M. M.; Piller, F.
(Hrsg.): The Customer Centric Enterprise. Advances in Mass Customization and Personalization.
Berlin, Heidelberg u. a.: Springer-Verlag. Seite 3-16.
[Turowski und Krammer 2003]
Turowski, K.; Krammer, A. (2003): Vorschlag für einen methodischen Standard zu durchgängigen
Spezifikationen von Fachkomponenten. In: ObjektSpektrum, Ausgabe 04/2003. Troisdorf: Sigs-
Datacom. Seite 65-68.
[Vasen 2003]
Vasen, J. (2003): Einsatzplanung für den technischen Kundendienst im Maschinenbau mit Bildung
von Auftragsreihenfolgen durch ein kombiniertes Prioritätsregelverfahren. Aachen: Shaker Verlag.
[VDI 1991]
VDI (Hrsg.), Grosch, E. W., Hogrefe, F.; Hohwalter, I.; Kohnen, K. H.; Menche, H. u. a. (1991):
Auftragsabwicklung im Maschinen- und Anlagenbau. Düsseldorf: VDI-Verlag, Stuttgart: Schäffer
Verlag.
[VDI 1999]
VDI-Gesellschaft Entwicklung Konstruktion Vertrieb (Hrsg.), ohne Verfasser (1999):
Angebotsbearbeitung, Schnittstelle zwischen Kunden und Lieferanten. Berlin, Heidelberg u. a.:
Springer-Verlag.
[VDI 2002]
VDI (Hrsg.), ohne Verfasser (2002): VDI-Richtlinie 2219. Informationsverarbeitung in der
Produktentwicklung - Einführung und Wirtschaftlichkeit von EDM/PDM-Systemen. VDI-
Gesellschaft Entwicklung Konstruktion Vertrieb. Berlin u.a .: Beuth Verlag.
[W3C-CSS 2004]
World Wide Web Consortium (Hrsg.); Lie, H. W.; Bos, B. (2004): Cascading Style Sheets, Level 1
W3C Recommendation 17 Dec 1996, revised 11 Jan 1999. http://www.w3.org/TR/REC-CSS1.
Aufgerufen am 24.04.2004.
[W3C-XML 2004]
World Wide Web Consortium (Hrsg.), Bray, T.; Paoli, J.; Sperberg-McQueen, C. M.; Maler,
E.;Yergeau, F.; Cowan, J. (2004): Extensible Markup Language (XML) 1.1- W3C Recommendation
04 February 2004. http://www.w3.org/TR/2004/REC-xml11-20040204/. Aufgerufen am 24.04.2004.
151
[W3C-XSL 2004]
World Wide Web Consortium (Hrsg.), Quin, L. (2004): The Extensible Stylesheet Language Family
(XSL). http://www.w3.org/Style/XSL/. Aufgerufen am 14.07.2004.
[Wang 2004]
Wang, D. (2004): Bunte Rahmen – Überblick über Web-Frameworks. In: Javamagazin, Ausgabe
09/2004. Frankfurt/Main: Software & Support Verlag. Seite 36-44.
[Warnecke 1995]
Warnecke, H.-J. (1995): Der Produktionsbetrieb 3: Betriebswirtschaft, Vertrieb, Recycling. Berlin,
Heidelberg u. a.: Springer-Verlag.
[Watterott 1987]
Watterott, R. (1987): Modell zur Informationsverarbeitung in einer dynamischen Vertriebsstruktur.
In: Vertriebsorganisation im Wandel. Tagung, Düsseldorf 18. September 1987. VDI-Gesellschaft
Entwicklung, Konstruktion, Vertrieb, VDI Berichte Nr. 646. Düsseldorf: VDI-Verlag. Seite 59-78.
[Weigend 2004]
Weigend, M. (2004): Objektorientierte Programmierung mit Python. Bonn: verlag moderne industrie
Buch.
[Weisbecker 2001]
Weisbecker, A. (2001): Komponentenbasierte Entwicklung von Electronic Business Anwendungen.
In: Scheibl H. J. (Hrsg.): Softwareentwicklung für Internet und Intranet. 9. Kolloquium Technische
Akademie Esslingen (TAE), Gesellschaft für Informatik (GI). Esslingen: Technische Akademie
Esslingen. Seite 181-191.
[Weisbecker 2002]
Weisbecker, A. (2002): Software-Management für komponentenbasierte Software-Entwicklung.
Heimsheim: Jost-Jetter Verlag.
[Weisbecker et al. 2001]
Weisbecker, A.; Lebender, M.; Heinrich, G. (2001): Ein Integrationsmodell für komponentenbasierte
Electronic Business Anwendungen. Stuttgart: Fraunhofer IAO, Stuttgart u. a.: Fraunhofer Electronic
Business Innovationszentrum.
[Weisbecker und Otto 2002]
Weisbecker, A.; Otto, B. (2002): Optimierung unternehmensübergreifender Geschäftsprozesse durch
E-Collaboration. In: IM - die Fachzeitschrift für Information Management. Nr 4. 2002. Saarbrücken:
mc information multimedia communication. Seite 33-38.
[Westkämper 2001]
Westkämper, E. (2001): Wissens- und Informationsmanagement in der Produktion. Vorlesungsskript
Teil 11. Stuttgart: Universität Stuttgart, Institut für Industrielle Fertigung und Fabrikbetrieb.
152
[Westkämper und Warnecke 2004]
Westkämper, E.; Warnecke, H.-J. (2004): Einführung in die Fertigungstechnik. 6. Auflage.
Wiesbaden: B. G. Teubner Verlag, GWV Fachverlage.
[Westphal 2003]
Westphal, R. (2003): Polyglott - Das .NET Framework als Plattform für mehrsprachige
Programmierung. In: iX Special - Programmieren mit .NET. Ausgabe 01/2003. München: Heise
Zeitschriften Verlag.
[WFMC 1999]
Workflow Management Coalition (1999): Workflow Management Coalition Terminology &
Glossary. Winchester: Workflow Management Coalition.
[Wieselhuber 2002]
Dr. Wiesenhuber & Partner GmbH, ohne Verfasser (2002): eBusiness Strategien und Organisation
im Maschinenbau. Bericht. München: Dr. Wieselhuber & Partner GmbH.
[Williams 2000]
Williams, G. C. (2000): Implementing SAP R/3 Sales and Distribution. New York, Chicago, San
Francisco: McGraw-Hill.
[Winkeler et al. 2001]
Winkeler, T.; Raupach, E.; Westphal, L. (2001): Enterprise Application Integration als Pflicht vor
der Business-Kür. In: Information Management & Consulting Nr. 16. Saarbrücken: mc information
multimedia communication.
[Winkelmann 2002]
Winkelmann, P. (2002): Marketing und Vertrieb. München, Wien: Oldenbourg.
[Wutka 2001]
Wutka, M. (2001): J2EE Developer's Guide. München: Markt+Technik.
[xCBL 2004]
xCBL.org, ohne Verfasser (2004) : xCBL 4.0 XML Document Descriptions
http://www.xcbl.org/xcbl40/documentation/listofdocuments.html. Aufgerufen am 25.04.2004.
[Xin 2002]
Chen X. (2002): BizTalk Server 2002 Design and Implementation. Berkeley: Apress.
[Zachman 1987]
Zachman, J. A. (1987): A Framework for Information Systems Architecture. In: IBM Systems
Journal, Vol 26, No 3, 1987. Yorktown Heights: IBM. Seite 276-292.
Anhang A – Portalarten im Unternehmenskontext
Kunde
Partner
Lieferant
Unternehmensprozesse
Unternehmen
Unternehmensprozesse
HR
Engineering
Sales und
Distribution
Marketing
CRMProduktion
Materials und
LogistikFinance
...Training undLearning
Mitarbeiter-Portal
Li
ef
er
an
te
n-
Po
rt
al
G
es
ch
äf
ts
ku
nd
en
-
Po
rt
al
Unternehmensprozesse
Unternehmens-
übergreifender Prozess
Prozess-
Integration
Erweiterung
der
Prozesse
Prozess-
Integration
Prozess-
Integration
Erweiterung
der
Prozesse
Prozess-
Integration
Unternehmens-
übergreifender Prozess
Prozess-
Integration
Prozess-
Integration
Erweiterung der
Prozesse
Unternehmensportal
Abbildung 43: Portalarten im Unternehmenskontext
154
Anhang B – Überblick über eingebettete Skriptsprachen
Skriptsprache
Eigenschaften
Coldfusion
MX
PHP JSP ASP
Quelle [Macromedia
2005]
[Achour et al
2005]
[Sun 2003a] [Krause 2002]
Hersteller Macromedia PHP Group Sun Microsoft
Strukturierung 3-Schicht 3-Schicht 3-Schicht 3-Schicht
Primäres
Programmierparadigma
prozedural,
objektorientiert
prozedural,
objektorientiert
objektorientiert objektorientiert
Ausführungsmodell JIT Interpreter,
compiliert
optional
JIT Interpreter
Komponentenmodell J2EE, CORBA Eigen, J2EE,
CORBA
J2EE, CORBA SOAP
Lizenzmodell kommerziell Open
Source/PHP
License
kommerziell kommerziell
Tabelle 20: Überblick über gängige eingebettete Skriptsprachen
155
Anhang C – Standards im Bereich Portale
Standard
Eigen-
schaften
Rules Engine
API
(JSR 94)
Portlet
Specification
(JSR 168)
Content
Repository API
(JSR 170)
Web Services for
Remote Portlets
(WSRP)
Allgemeine Beschreibung
Quelle [JSR 94] [Abdelnur und
Hepper 2003]
[JSR 170] [Kropp et al. 2003]
Art der
Standardisierung
Industrie: JCP Industrie: JCP Industrie: JCP Industrie: OASIS
Umfang Definition einer
Java-basierten
API für Rule
Engines.
Definition von
APIs für
Portalsoftware
aus den
Bereichen
Aggregation,
Personalisierung,
Präsentation und
Sicherheit.
Standard für
transaktions-
orientierten Zugriff,
Volltextsuche,
Filterung,
Versionierung von
hoch und gering
strukturiertem
Content.
XML-basierter
Web-Services-
Standard für die
einfache
Einbindung von
Portalanwendungen
mit Web Services.
Portaleigenschaften
TU TF AE TU TF AE TU TF AE TU TF AE
Internetbasiert ○ ○ ○ ○ ● ○ ○ ○ ○ ○ ● ○
Personalisierung und
Rollen ○ ● ○ ○ ◐ ○ ○ ○ ○ ○ ◐ ○
Benutzermanagement ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○
Prozessunterstützung ○ ◐ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○
Integration ○ ◐ ○ ○ ● ○ ○ ● ○ ○ ● ○
Homogenität ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ◐ ○
Architektur
Strukturierungs-
vorgaben
Schnittstelle Portlet/Container
-Schnittstelle
Schnittstelle Schnittstelle,
Integration
Granularität des
Komponenten-
modells (extern)
fein, grob fein, mittel, grob fein, grob mittel, grob
Fachebene
Abbildung Prozesse
des Techn. Vertriebs
○ ○ ○ ○
Bewertung
Beitrag zu einer
Portalarchitektur
Standard für
Regelverarbeitung
Teilarchitektur für
die Einbindung
von Portal-
anwendungen
Standard für die
Einbindung von
Content
Teilarchitektur für die
Einbindung von
Portalanwendungen
Legende: Erfüllungsgrad ● voll erfüllt, ◐ teilweise erfüllt, ○ nicht erfüllt;
Abkürzungen JCP: Java Community Process, JSR: Java Specification Requests.
Tabelle 21: Darstellung, Gegenüberstellung und Bewertung der Standards im Bereich Portale
156
Anhang D – Ergebnisse der Unternehmensbefragung
Der Anhang gibt einen Ausschnitt der Ergebnisse der in [Gurzki und Özcan 2003] durchgeführten
Unternehmensbefragung in technischen Branchen wieder. Abbildung 44 visualisiert die Ergebnisse in
einer Übersichtsgrafik und Tabelle 22 stellt die Einzelergebnisse der Branchen dar.
„Welche der genannten Prozesse bzw. Anwendungen würden Sie gerne in einem
Geschäftskundenportal anbieten?“
Priorisierung nach Notenpunkten (1: hohe Priorität, 6: nicht erforderlich), N=56, n=53.
Abbildung 44: Priorisierung von Prozessen/Anwendungen [Gurzki und Özcan 2003]
157
Kategorie Bewertung der Wichtigkeit (Noten 1-6, Mittelwert)
Maschinen-
und
Anlagenbau
Elektro-
technik
Durchschnitt
zwei Branchen
Durchschnitt
Gesamtheit
Bereitstellung von
Datenblättern
2,6 1,3 1,95 2,1
Bereitstellung von technischer
Information über Produkte
2,3 1,4 1,85 2,0
Suche von Produkten 3,0 1,3 2,15 2,4
Allgemeine
Unternehmensinformationen
2,7 1,9 2,3 2,4
Applikationsbeschreibungen,
Anleitungen, Handbücher
2,8 1,8 2,3 2,8
Kommunikation mit
Technischem Kundendienst/
Support
2,2 2,4 2,5
Angebotsanforderung/
Preisanfrage
3,4 2,0 2,7 2,7
Bestellvorgang durch Kunden/
Transaktion
3,5 2,0 2,75 2,8
Reklamationen 3,0 2,8 2,9 2,9
Bereitstellung von technischen
Zeichnungen
3,2 2,2 2,7 3,0
Bestellung von Zubehör 3,4 2,5 2,95 3,0
Vorlage für Bestellungen (z. B.
oft bestellte Artikel)
3,6 2,5 3,05 3,0
Einsehen der eigenen
Bestellhistorie
3,4 2,5 2,95 3,0
Elektronische
Auftragsbestätigung
3,2 2,5 2,85 3,0
Verfügbarkeitsprüfung 3,7 2,1 2,9 3,1
Rückfrage zu Bestellungen 3,5 2,7 3,1 3,1
Konfiguration von Produkten 3,7 2,7 3,2 3,3
Elektronische Rechnung 3,6 3,1 3,35 3,3
Anzeige eines
kundenindividuellen
Produktkatalogs
4,1 2,6 3,35 3,4
Produktvergleich/Beratung bei
Produktwahl
4,2 2,44 3,3 3,5
Kundenindividuelle
Preisgestaltung
4,6 2,1 3,35 3,5
Bereitstellung von Produkten
(z. B. Software Downloads)
3,9 3,1 3,5 3,7
Führen von gemeinsamen
Projektbüchern
4,6 3,7 4,15 4,3
Tabelle 22: Priorisierung von Prozessen/Anwendungen, nach Notenpunkten von 1 (hohe Priorität) bis 6
(nicht erforderlich), N=56, n=53, [Gurzki und Özcan 2003].
158
Anhang E – Prozessübersicht
Die Prozessübersicht basiert auf den in der Befragung von [Gurzki und Özcan 2003] erhobenen
Prozessen, die von Unternehmen mit Technischem Vertrieb als relevant bewertet werden. Die
Prozessbeschreibung erfolgt auf struktureller Ebene um eine unternehmensspezifische Ausprägung zu
ermöglichen.
Bereitstellung von technischen Informationen über Produkte
Technische Informationen über Produkte geben den Kunden eine wesentliche Entscheidungshilfe. Sie
sind auf der Webseite dargestellt und enthalten Informationen, die einen Ausschnitt des Datenblatts
darstellen. Darüber hinaus enthalten sie werbliche Informationen, die den Mehrwert des Produkts bzw.
eine Differenzierung zu den Wettbewerbern darstellen. Technische Informationen sind damit ein
unverzichtbarer Bestandteil eines Geschäftskundenportals. Der Kunde ruft die technischen
Informationen zu einem Produkt ab, indem er das Produkt aus einem Katalog auswählt. Für den Abruf
von Informationen zu kundenindividuellen Produkten muss sich der Kunde anmelden. Die technischen
Informationen werden direkt bei dem Produkt aufgeführt und können dort abgelesen werden.
Bereitstellung von Datenblättern
Datenblätter stellen für Kunden die wichtigste Informationsquelle für technische Produkte dar. Sie
enthalten alle relevanten Daten in einem Dokument. Für den Anbieter entfällt mit der Online-
Bereitstellung der Datenblätter das aufwändige Versenden auf Anfrage per Post bzw. per Fax. Bei
Bedarf kann für eine individuelle Entwicklung das Datenblatt dem jeweiligen Kunden personalisiet
bereitgestellt werden. Der Kunde muss sich für den Abruf von Datenblättern zu kundenindividuellen
Produkten anmelden. Der Abruf eines Datenblatts erfolgt durch die Auswahl eines Produkts aus dem
Katalog. Das Datenblatt ist über einen Link bei den Produktinformationen erreichbar. Es wird über
diesen Link als Dokumenten-Download bereitgestellt.
Suche von Produkten
Die Suche von Produkten stellt ein wesentliches Element eines Geschäftskundenportals dar. Die
Aufgabe der Suchfunktion besteht darin, dem Kunden, der keine Kenntnis der Katalog- und
Produktstruktur hat, einen Zugang zu Produkten und Dienstleistungen des Unternehmens zu
ermöglichen. Die Suchfunktion besteht aus den Teilen Suche nach Inhalten und Produkten und
Produktberatung. Die Suche nach Inhalten und Produkten ermöglicht dem Kunden die Suche über die
im Portal integrierten Systeme. Insbesondere kann der Katalog nach Attributen wie
Produktbeschreibung oder nach Eigenschaften wie technische Daten und Anwendungsgebiet eines
Produkts durchsucht werden. Darüber hinaus werden redaktionelle Inhalte durchsucht. Die Treffer
werden in einer Übersichtsseite dargestellt. Der Kunde kann von der Übersichtsseite zu den
Trefferseiten navigieren. Die Produktberatung zur Auswahl eines geeigneten Produkts erfolgt durch
einen virtuellen Produkt- und Anwendungsberater, der den Kunden durch intelligente Verfahren beim
Finden eines geeigneten Produkts unterstützen. Der Kunde ruft den Berater auf und der Berater erfragt
in einem Dialog die zur Empfehlung eines Produkts erforderlichen Anwendungsgebiete,
Anforderungen und/oder Eigenschaften. Der Berater stellt die in Frage kommenden Produkte bzw.
159
Produktkategorien im Katalog dar. Er kann bei Bedarf auch Produkte im Warenkorb in Bezug auf ihre
Eigenschaften vergleichen.
Bereitstellung von allgemeinen Unternehmensinformationen
Allgemeine Unternehmensinformationen dienen der Information der Öffentlichkeit, der Kunden und
ggf. der Aktionäre. Sie werden damit aus Sicht des Unternehmens zu einem der wichtigsten Aspekte
eines Geschäftskundenportals. Zu den Kerninformationen gehören der Unternehmenszweck, das
Leistungsangebot, Kompetenzen und die Kontaktinformation. Der Kunde ruft die in Rubriken
eingeteilten Informationen über eine geeignete Navigation auf.
Kommunikation mit Technischem Kundendienst/Support
Die Kommunikation mit dem Technischen Kundendienst über ein Portal besitzt im technischen
Bereich eine hohe Wichtigkeit. Die Abwicklung der Anfragen über das Portal ermöglicht eine
asynchrone Bearbeitung und aus Kundensicht eine Erreichbarkeit rund um die Uhr. Die strukturierte
Erfassung der Anfragen reduziert Fehler bei der Zuordnung der Anfragen und senkt damit die Kosten
des Service. Der Kunde meldet sich an und erhält Zugriff auf eine Umgebung, die ihm die Erstellung
von Anfragen, das Lesen von Antworten und das Löschen von gelesenen Antworten ermöglicht. Für
die Kommunikation mit dem Technischen Kundendienst ruft er ein Formular auf, das die notwendigen
Daten der Anfrage als Eingabe entgegennimmt. Der Kunde klassifiziert seine Anfrage nach der Art (z.
B. kaufmännisch, technisch). Das Formular wird dem Technischen Kundendienst weitergeleitet. Nach
der Bearbeitung steht die Antwort in der Umgebung des Kunden zur Verfügung.
Angebotsanforderung, Preisanfrage
Die Angebotsanforderung basiert auf einem zusammengestellten Warenkorb. Die Angebotserstellung
kann entweder automatisiert erfolgen oder bei Bedarf manuell durchgeführt werden. Zur Anforderung
des Angebots meldet sich der Kunde an und fordert mit seinem gefüllten Warenkorb ein Angebot an.
Das Angebot wird dem Kunden per E-Mail, Post oder einem anderen Kommunikationsweg
zugesendet.
Bestellvorgang durch Kunden/Transaktion
Die Durchführung des eigentlichen Bestellvorgangs reiht sich in die Auswahl der Produkte im
elektronischen Katalog ein. Eine direkte Bestellung entlastet den Vertriebsinnendienst durch die
direkte elektronische Erfassung des Auftrags mit den Bestellpositionen und Kundendaten. Die
elektronische Erfassung beseitigt darüber hinaus die klassischen Medienbrüche bei der Bearbeitung
der Aufträge, wie zum Beispiel die manuelle Erfassung von Faxbestellungen. Zur Auslösung der
Transaktion durch den Kunden benötigt dieser einen gefüllten Warenkorb. Die Transaktion erfordert
eine Identifikation des Kunden durch eine Anmeldung. Sie wandelt den Warenkorb in eine Bestellung
um und löst die weiteren zur Belieferung notwendigen Vorgänge aus. Im Rahmen der Transaktion
erhält der Kunden auf separatem Weg eine Bestell- und Auftragsbestätigung.
160
Bereitstellung von Handbüchern, Applikationsbeschreibungen
Die Bereitstellung von elektronischen Varianten der Produkthandbücher ist aus verschiedenen
Gründen interessant. Handbücher geben Auskunft über die Anwendung und über die Eigenschaften
des Produkts und sind damit zur Vermittlung der Produktbesonderheiten geeignet. Im Fall von
Zulieferprodukten werden die Handbücher bei der Montage oft versehentlich von den Produkten
getrennt. Hier ergibt sich für die Kunden ein kurzfristiger Informationsbedarf in einer kritischen Phase.
Eine direkte Bereitstellung erhöht den Komfort für den Kunden und reduziert die Anfragen im
Service. Applikationsbeschreibungen unterstützen den Kunden bei der Entwicklung eigener Lösungen
auf Basis der beschriebenen Produkte.
Reklamationen
Die strukturierte Erfassung von Reklamationen und die teilautomatisierte Bearbeitung reduzieren die
Kosten für Reklamationsfälle. Es wird eine durchgehende Erreichbarkeit rund um die Uhr erzielt. Die
strukturierte Erfassung reduziert Fehler bei der Zuordnung der Anfragen und senkt damit die Kosten
für Reklamationen. Der Kunde meldet sich an und erhält Zugriff auf eine Umgebung, die ihm die
Erstellung von Reklamationen, das Lesen von Antworten und das Löschen von gelesenen Antworten
ermöglicht. Für die Durchführung ruft er ein Formular auf, das die notwendigen Daten der
Reklamation als Eingabe entgegennimmt. Das Formular wird an das Unternehmen weitergeleitet.
Nach der Bearbeitung steht die Antwort in der Umgebung des Kunden zur Verfügung.
Bereitstellung von technischen Zeichnungen
Technische Zeichnungen können im Portal als 2D-Zeichnungen oder als 3D-CAD-Zeichnungen
bereitgestellt werden. 2D-Zeichnungen dienen der Verdeutlichung des Aufbaus des Produkts oder der
Beschaltung. 3D-Zeichnungen sind für Produkte wichtig, die als Bauteil in anderen Geräten und
Maschinen eingesetzt werden sollen. Mit der Zeichnung wird dem Kunden die Möglichkeit gegeben,
das Produkt direkt in seine Konstruktion einzubeziehen. Zeichnungen können dem jeweiligen Kunden
bei Bedarf für individuelle Entwicklungen exklusiv bereitgestellt werden. Für den Abruf von
Zeichnungen zu kundenindividuellen Produkten muss sich der Kunde anmelden. Der Abruf einer
Zeichnung erfolgt durch die Auswahl eines Produkts aus dem Katalog. Die Zeichnung ist über einen
Link bei den Produktinformationen erreichbar. Sie wird über diesen Link als Dokumenten-Download
bereitgestellt.
Bestellung von Zubehör
Die Bestellung von Zubehör ist ein Nebeneffekt des Produktkatalogs. Dem Kunden kann im Portal
Zubehör zu den bereits gekauften Produkten angeboten werden. Bei Systemprodukten hat die
Zubehörfunktion eine große Bedeutung. Zu einem Hauptprodukt können direkt die für den Betrieb
erforderlichen Zubehörteile angezeigt werden. Der Nutzer kann die Anzeige der Produktdetails von
Zubehör analog zu dem der Hauptprodukte aufrufen.
161
Vorlage für Bestellungen
Eine Vorlage für häufig wiederkehrende Bestellungen erleichtert insbesondere Stammkunden den
wiederholten Bestellvorgang. Der Kunde meldet sich an und erhält Zugriff auf die von ihm
gespeicherten Warenkörbe. Die gespeicherten Warenkörbe können aus einer Übersichtsdarstellung in
den aktuellen Warenkorb übernommen werden.
Einsehen der eigenen Bestellhistorie
Die Bestellhistorie ermöglicht dem Kunden nach einer Anmeldung das Verfolgen von offenen und
abgeschlossenen Aufträgen. Die Historie zeigt eine Übersicht der bisherigen Bestellungen und erlaubt
den Kunden die Auswahl einzelner Bestellungen. Die Details der ausgewählten Bestellungen werden
dargestellt. Die Bestellhistorie entlastet den Vertrieb von Kundenanfragen und ermöglicht dem
Kunden einen direkten Zugang zu Informationen über den aktuellen Bearbeitungsstand einer
Bestellung bzw. dem aktuellen Versandstatus (Track und Trace).
Elektronische Auftragsbestätigung
Die Auftragsbestätigung mit einer Zusammenfassung des Inhalts der Bestellung wird dem Kunden per
E-Mail , Post oder Fax zugestellt.
Verfügbarkeitsprüfung
Die Prüfung der Verfügbarkeit von Waren ist vor allem bei Handelsware von hoher Wichtigkeit. Die
Funktion stellt einen hohen Mehrwert für den Kunden dar. Für Unternehmen mit auftragsbezogener
Fertigung ist diese Funktion für Ersatzteilbestellungen relevant. Die Verfügbarkeit wird dem Kunden
in der Darstellung eines Produkts im Katalog angezeigt.
Rückfrage zu Bestellungen
Der Kunde meldet sich an und erhält Zugriff auf eine Umgebung, die ihm die Erstellung von
Rückfragen, das Lesen von Antworten und das Löschen von gelesenen Antworten ermöglicht. Zur
Durchführung ruft er ein Formular auf, das die notwendigen Daten der Reklamation als Eingabe
entgegennimmt. Die Anfragen werden direkt dem zuständigen Vertriebsmitarbeiter zur Bearbeitung
zugeleitet und entsprechend über ein geeignetes Medium beantwortet oder in der Umgebung des
Kunden bereitgestellt.
Elektronische Rechnung
Zu einer ausgeführten Bestellung wird dem Kunden eine signierte elektronische Rechnung per E-Mail
zugesandt. Unsicherheit bezüglich der rechtlichen Rahmenbedingungen lässt viele Unternehmen auf
diesen Weg der Rechnungsstellung verzichten. Die Funktion kann optional zusätzlich zur schriftlichen
Rechnung angeboten werden.
162
Konfiguration von Produkten
Eine Konfiguration ist für komplexe und zusammengesetzte Produkte erforderlich. Der Kunde ruft im
Katalog ein konfigurierbares Produkt auf. In der Bedienungsoberfläche des Produktkonfigurators kann
der Kunde das Produkt in einem Dialog unter Berücksichtigung von Regeln zu möglichen
Konfigurationen konfigurieren. Die fertig gestellte Konfiguration kann in den Warenkorb
übernommen werden.
Anzeige eines kundenindividuellen Produktkatalogs
Ein kundenindividueller Produktkatalog stellt die für den Kunden vorgesehenen Produkte in
personalisierter Form dar. Zum Aufruf des Kataloges muss der Kunde angemeldet sein. Der Katalog
wird ausgewählt und stellt die für den Kunden verfügbaren Produkte mit einer geeigneten
Navigationsstruktur dar. Der Katalog kann kundenindividuell entwickelte Produkte enthalten, die nur
für diesen Kunden sichtbar sind.
Kundenindividuelle Preisgestaltung
Die Preisanfrage ermöglicht einem angemeldeten Kunden individuelle bzw. mengenbezogene Preise
zu einem Produkt zu ermitteln. Hierfür ruft der Kunde das Produkt auf und erhält bei der
Produktdarstellung individuelle, ggf. mengenbezogene (Staffeln), Preisangaben. Die Preisanfrage stellt
eine Alternative zur Angebotsanforderung dar.
Bereitstellung von Produkten
Die Bereitstellung von Produkten kommt im industriellen Bereich insbesondere für kostenpflichtige
Software, Software Updates, Dokumentationen und Schulungsunterlagen in Betracht. Typische
Produkte sind in diesem Zusammenhang Bediensoftware und Entwicklungsumgebungen. Der Kunde
führt eine Bestellung für dieses Produkt durch. Nach der Bestellung erhält er eine Übersicht über die
erworbenen Produkte, die heruntergeladen werden können. Die Produkte sind als Links auf die
jeweilige Datei hinterlegt.
Führen von gemeinsamen Projektbüchern
Das Führen von gemeinsamen Projektbüchern mit Kunden ist bei komplexen und längeren Projekten
sowie bei kundenindividuellen Entwicklungen erforderlich. Der Kunde kann nach der Anmeldung auf
eine Verwaltungsumgebung für Dokumente sowie für Termine- und Ressourcen zugreifen. Sowohl
der Kunde als auch der Anbieter können projektrelevante Dokumente einstellen und abrufen. Die
Dokumente werden strukturiert und versioniert abgelegt. Die Termin- und Ressourcenverwaltung
gestattet eine gemeinsame Verwaltung und Planung der Termine und des Zugriffs auf Ressourcen, wie
z. B. Maschinen oder Räume. Der Kunde kann gemeinsam mit dem Anbieter ein Forum für den
Austausch von Informationen nutzen.
163
Anhang F – Funktionskarten für Komponenten
Angabe der Signatur nach Datum und der zugehörigen Funktion. Periodische bzw. einmalige
Datenübernahmen sind durch „Import“ gekennzeichnet.
Funktionskarten der Schicht PSK
Funktionskarte PSK SHOP
Id Einzelfunktion Informationsobjekte Benötigt extern Erzeugt extern
F1 Darstellung
Standardkatalog
Standardkatalog Import: Katalog
KDM-D1/-F1
Optional: Referenz auf
Artikel oder
Artikelklasse
Darstellung
Standardkatalog
SHOP-D1
F2 Darstellung
kunden-
individueller
Katalog
Kundenindividueller
Katalog
Import: Katalog
KDM-D2/-F2
Optional: Referenz auf
Artikel oder
Artikelklasse
Darstellung
kundenindividueller
Katalog SHOP-D2
F3 Kunden-
individuelle
Preisgestaltung
Artikelnummer
Kundenpreis
Artikelnummer
Kundenpreis
CRK-D1/F1
Darstellung
kundenindividueller
Preis SHOP-D3
F4 Warenkorb aus
Katalog und
externer
Anwendung füllen
Warenkorb
Artikelnummer
Menge
Optional:
Konfiguration
Artikelnummer
Menge
Optional:
Konfiguration
Darstellung Warenkorb
SHOP-D4
F5 Warenkorb
verwalten
Warenkorb - Darstellung Warenkorb
SHOP-D4
F6 Verfügbar-
keitsprüfung
Warenkorb
Artikelnummer
Mengenangabe
Verfügbarkeit
CRK-D2/-F2
Darstellung Warenkorb
SHOP-D4
F7 Transaktion/
Bestellung
Warenkorb
Bestellung
- Darstellung
Warenkorb SHOP-D4
Bestellung SHOP-D5
F8 Preisanfrage/
Angebots-
anforderung
Warenkorb
Bestellung
Angebot CRK-D3/-F3 Darstellung
Warenkorb SHOP-D4
Angebotsanforderung
SHOP-D6
F9 Vorlage für
Bestellung
Bestellvorlagen
Warenkorb
- Darstellung
Bestellvorlagen
SHOP-D7
F10 Bereitstellung
Produktdownload
Bestellung Import: Elektronische
Produkte DM-D8/-F8
Download Produkte
SHOP-F10
SU-
CHE
Suche nach
Produkten
Kataloge Suchanfrage
Trefferliste
164
Funktionskarte PSK KONF
Id Einzelfunktion Informationsobjekte Benötigt extern Erzeugt extern
F1 Konfiguration
Produkt
Stückliste Produkt,
Konfigurationsregeln
Stückliste CRK-D4/-F4
Preiskalkulation
CRK-D1/-F1
Darstellung Prozess
KONF-D1
F2 Konfiguration
bereitstellen
Konfiguration - Konfiguration
KONF-D2
Funktionskarte PSK CM
Id Einzelfunktion Informationsobjekte Benötigt extern Erzeugt extern
F1 Bereitstellung
Contentbereich
„Allgemeine
Unternehmens-
information“
Unternehmens-
information,
Unternehmens-
nachrichten,
Dokumente
Metadaten
Import: Dokumente der
Unternehmensinfor-
mation DM-D1/-F1
Darstellung
Contentbereich
Unternehmens-
information CM-D1
F2 Bereitstellung
einer Referenz
auf ein
Datenblatt
Referenz
Artikelnummer
Datenblatt
Metadaten
Artikelnummer,
Import: Datenblätter
DM-D2/-F2
Referenz auf
Datenblatt CM-D2
F3 Bereitstellung
einer Referenz
auf eine
technische
Zeichnung
Referenz
Artikelnummer
Technische Zeichnung
Metadaten
Artikelnummer,
Import: Technische
Zeichnungen
DM-D3/-F3
Referenz auf
technische Zeichnung
CM-D3
F4 Bereitstellung
einer Referenz
auf eine
erweiterte
Produkt-
darstellung
erweiterte
Produktdarstellung
Referenz
Artikelnummer
Metadaten
Artikelnummer,
Import: Erweiterte
Produktdarstellung
DM-D7/-F5
Referenz auf
erweiterte
Produktdarstellung
CM-D4
F5 Bereitstellung
einer Referenz
auf eine
Applikations-
beschreibung
Referenz
Artikelnummer
Applikations-
beschreibung
Metadaten
Artikelnummer,
Import: Applikations-
beschreibungen
DM-D4/-F4
Referenz auf
Applikations-
beschreibung CM-D5
F6 Bereitstellung
einer Referenz
auf eine
Anleitung
Referenz
Artikelnummer
Anleitung
Metadaten
Artikelnummer, Import:
Anleitungen
DM-D5/-F5
Referenz auf
Anleitung CM-D6
F7 Bereitstellung
einer Referenz
auf ein
Handbuch
Referenz
Artikelnummer
Handbuch
Metadaten
Artikelnummer,
Import: Handbücher
DM-D6/-F6
Referenz auf
Handbuch CM-D7
165
Id Einzelfunktion Informationsobjekte Benötigt extern Erzeugt extern
F8 Bereitstellung
Contentbereich
für technische
Dokumente
Applikations-
beschreibungen,
Anleitungen,
Handbücher,
Datenblätter,
erweiterte
Produktdarstellungen
Import: Applikations-
beschreibungen,
Anleitungen,
Handbücher,
Datenblätter,
erweiterte
Produktdarstellungen
DM-D2, -D3, -D4, -D5,
-D6
Darstellung
Contentbereich für
technische Dokumente
CM-D8
F9 Bereitstellung
Contentbereich
für redaktionelle
Beiträge
Beiträge
Metadaten
- Darstellung
Contentbereich für
redaktionelle Beiträge
CM-D9
F10 Bereitstellung
von Referenzen
auf redaktion-
elle Beiträge zu
Artikel
Liste mit Referenzen
auf redaktionelle
Beiträge,
Artikelnummer/Meta-
daten
Artikelnummer/
Metadaten
Liste mit Referenzen
auf redaktionelle
Beiträge CM-D10
F11 Bereitstellung
Portalgrafiken
Portalgrafiken Referenz Portalgrafik
SU-
CHE
Suche nach
Inhalten
Content Suchanfrage
Trefferliste
Funktionskarte PSK BER
Id Einzelfunktion Informationsobjekte Benötigt extern Erzeugt extern
F1 Bereitstellung
Produktbera-
tungsdialog
Wissensbasis
Katalog
Katalog (einmalig)
KDM-D1/-F1
Auftragshistorie
CRK-D6
HTML-Darstellung
Beratungsdialog
BER-D1
F2 Bereitstellung
Produktver-
gleich
Wissensbasis
Katalog
Katalog (einmalig)
KDM-D1/-F1
Referenz Datenblatt
CM-D2
F3 Suche nach
Produkt-
empfehlungen
Wissensbasis
Suchanfrage Trefferliste
166
Funktionskarte PSK CMK
Id Einzelfunktion Informationsobjekte Benötigt extern Erzeugt extern
F1 Asynchrone
öffentliche
Kommunikation
mit Technisch-
em Kunden-
dienst/Support
Forum
Beiträge
- Darstellung Forum
CMK-D1
F2 Synchrone
öffentliche
Kommunikation
mit Technisch-
em Kunden-
dienst/Support
Chatumgebung
Kanäle
- Darstellung Chat
CMK-D2
SU-
CHE
Suche nach
Beiträgen
Beiträge Suchanfrage
Trefferliste
Funktionskarten der Schicht BIK
Funktionskarte BIK CRK
Id Einzelfunktion Informationsobjekte Benötigt extern Erzeugt extern
F1 Kundenpreis-
ermittlung
Artikelnummer,
Kundennummer,
Angebot
Artikelnummer bzw.
Bestellung
Kundennummer
Kundenpreis CRK-D1
F2 Verfügbarkeits-
prüfung
Artikelnummer bzw.
Bestellung
Artikelnummer bzw.
Bestellung
Verfügbarkeit ERK-D1
Verfügbarkeit
CRK D-2
F3 Erstellung
Angebot
Warenkorb,
Angebot
Warenkorb Angebot CRK-D3
F4 Einbuchung
Kundenauftrag
Kundenauftrag
Bestellung
Bestellung Auftragsbestätigung
CRK-D7
Kundenauftrag
CRK-D9
F5 Bereitstellung
Kundenstamm
Kundenstamm Kundennummer Kundenstamm
CRK-D4
F6 Bereitstellung
Basiskatalog
Materialstamm - Basiskatalog CRK-D5
F7 Bereitstellung
Auftragshistorie
mit Kunden-
auftragsstatus
Auftragshistorie
Kundennummer
Zeitraum
Auftragshistorie mit
Kundenauftragsstatus
ERK-D3
Auftragshistorie mit
Kundenauftragsstatus
CRK-D6
167
Funktionskarte BIK ERK
Id Einzelfunktion Informationsobjekte Benötigt extern Erzeugt extern
F1 Bereitstellung
Materialstamm
Materialstamm - Materialstamm ERK-
D1
F2 Bereitstellung
Verfügbarkeit
zu Artikel
Verfügbarkeit
Artikelnummer
Artikelnummer Verfügbarkeit Artikel
ERK-D2
F3 Einbuchung
Kundenauftrag
Kundenauftrag Kundenauftrag -
F4 Bereitstellung
Kundenauftrags-
status und
Historie
Historie
Status
Kundennummer
Kundennummer
Zeitraum
Kundenauftragsstatus
und Historie ERK-D3
F5 Bereitstellung
Rechnungen
Rechnungen
Kundennummer
Kundennummer
Zeitraum
Rechnungen ERK-D4
Funktionskarte BIK KDM
Id Einzelfunktion Informationsobjekte Benötigt extern Erzeugt extern
F1 Export
Standardkatalog
Basiskatalog,
Standardkatalog
Basiskatalog CRK-D5
(Import)
Standardkatalog
KDM-D1
F2 Export
kundenindivi-
dueller/ziel-
gruppenspezi-
fischer Katalog
Basiskatalog,
Standardkatalog,
Individueller Katalog
- Kundenindivdueller/
zielgruppenspezi-
fischer Katalog
KDM-D2
Funktionskarte BIK DM
Id Einzelfunktion Informationsobjekte Benötigt extern Erzeugt extern
F1 Bereitstellung
Dokument der
Unternehmens-
information
Dokument der
Unternehmens-
information,
Metadaten
Referenz Metadaten Dokument der
Unternehmens-
information mit
Metadaten DM-D1
F2 Bereitstellung
Datenblatt
Datenblatt,
Metadaten
Artikelnummer,
Referenz Metadaten
Datenblatt mit
Metadaten DM-D2
F3 Bereitstellung
technische
Zeichnungen
und Modelle
Technische Zeichnung
bzw. 2D/3D Modell,
Metadaten
Artikelnummer oder
Referenz Metadaten
Technische Zeichnung
bzw. Modell mit
Metadaten DM-D3
F4 Bereitstellung
Applikations-
beschreibung
Applikations-
beschreibung,
Metadaten
Artikelnummer,
Referenz Metadaten
Applikations-
beschreibung mit
Metadaten DM-D4
168
Id Einzelfunktion Informationsobjekte Benötigt extern Erzeugt extern
F5 Bereitstellung
Anleitung
Anleitung,
Metadaten
Artikelnummer,
Referenz Metadaten
Anleitung mit
Metadaten DM-D5
F6 Bereitstellung
Handbuch
Handbuch,
Metadaten
Artikelnummer,
Referenz Metadaten
Handbuch mit
Metadaten DM-D6
F7 Bereitstellung
erweiterte
Produkt-
darstellung
Erweiterte
Produktdarstellung
Artikelnummer,
Referenz Metadaten
Erweiterte
Produktdarstellung
mit Metadaten
DM-D7
F8 Bereitstellung
elektronische
Produkte
Elektronische
Produkte
Artikelnummer,
Referenz Metadaten
Elektronische
Produkte
DM-D8
Funktionskarte BIK WFM
Id Einzelfunktion Informationsobjekte Benötigt extern Erzeugt extern
F1 Eingabe
technische bzw.
kaufmännische
Anfrage
Anfrage,
Klassifizierung,
Ticket-Nummer,
Kundennummer,
Workflow-Instanz,
Anfrage Darstellung
Anfrageerfassung
WFM-D1
Ticket-Nummer
WFM-D2
F2 Abruf
technische bzw.
kaufmännische
Antworten
Workflow-Instanz,
Verfügbare
Antworten,
Ticket-Nummer
- Darstellung
Antwortübersicht und
Einzelantworten
WFM-D3
SU-
CHE
Suche nach
Anfragen
Anfragen Suchanfrage
Trefferliste
169
Funktionskarte BIK GPW
Id Einzelfunktion Informationsobjekte Benötigt extern Erzeugt extern
F1 Bereitstellung
Dokumenten-
verwaltung
Projektdokumente - Darstellung Doku-
mentenverwaltung
GPW-D1
F2 Bereitstellung
Termin- und
Ressourcen-
verwaltung
Termine
Ressourcen
- Darstellung Termin-
und
Ressourcenverwaltung
GPW-D2
F3 Bereitstellung
asynchroner
Diskussions-
unterstützung
Diskussionsforum
Diskussionen
- Darstellung
Diskussionsverwaltung
GPW-D3
SU-
CHE
Suche nach
Dokumenten
und Ressourcen
Projektdokumente
Termine
Ressourcen
Diskussionen
- Trefferliste
Funktionskarte BIK AUTH
Id Einzelfunktion Informationsobjekte Benötigt extern Erzeugt extern
F1 Authentifi-
zierung von
Nutzern
Anmeldeinformation,
Authentifizierungs-
status
Nutzeridentifikation
Anmeldeinformation Authentifizierungs-
status AUTH-D1
Nutzeridentifikation
AUTH-D2
F2 Autorisierung
von Nutzern
Nutzeridentifikation
Nutzeridentifikation
Berechtigungs- und
Rolleninformation
AUTH-D3
Funktionskarte Portalumgebung
Funktionskarte PORT
Id Einzelfunktion Informationsobjekte Benötigt extern Erzeugt extern
F1 Bereitstellung
der
Informationen
über den Nutzer
Anmeldeinformation,
Authentifizierungs-
status
Nutzeridentifikation
Berechtigungs- und
Rolleninformation
AUTH-D3
Authentifizierungs-
status AUTH-D1
Nutzeridentifikation
AUTH-D2
Berechtigungs- und
Rolleninformation
AUTH-D3
Portalnutzer PORT-D1
170
Anhang G – Weitere Datenmodelle
Abbildung 45: Grunddatenmodell PAK Produktwahlunterstützung und Beratung
171
Abbildung 46: Grunddatenmodell Dokumente und Contentverwaltung
172
«verwendet»
«Stammdatum»
Portalnutzer
>PORT-D1
«Stammdatum»
Kundenstamm
>CRK-D4
«referenziert»
«Stammdatum»
Authentifizierungsstatus
1 1
>AUTH-D1
«Stammdatum»
Nutzeridentifikation
>AUTH-D2
«Stammdatum»
Berechtigungs- und Rolleninformation
1
1
>AUTH-D3
«referenziert»
«referenziert»
Abbildung 47: Grunddatenmodell Autorisierung
173
Anhang H – Authentifizierungsstati für die Prozesse des
Architekturmodells
Authentifizierungsstatus
Prozess
Anonymer
Kunde
Authentifizierter
Kunde
Bereitstellung von technischer Information über Produkte ● ●
Bereitstellung von Datenblättern ● ●
Anzeige eines kundenindividuellen Produktkatalogs ●
Bestellung von Zubehör ●
Bereitstellung von technischen Zeichnungen ● ●
Elektronische Bereitstellung von Produkten ●
Kundenindividuelle Preisgestaltung ●
Bestellvorgang durch Kunden/Transaktion ●
Einsehen der eigenen Bestellhistorie/Auftragsstatus ●
Preisanfrage/Angebotsanforderung ●
Elektronische Auftrags- und Bestellbestätigung ●
Elektronische Rechnung ●
Verfügbarkeitsprüfung ●
Vorlage für Bestellungen ●
Konfiguration von Produkten ● ●
Suche nach Produkten ● ●
Suche nach Inhalten ● ●
Applikationsbeschreibungen, Anleitungen, Handbücher ● ●
Produktvergleich/Beratung bei Produktwahl ● ●
Kommunikation mit Technischem Kundendienst/Support ●
Reklamation ●
Rückfrage zu Bestellungen ●
Allgemeine Unternehmensinformation ● ●
Führen von gemeinsamen Projektbüchern ●
Legende: ● Zuordnung zu Status
Tabelle 23: Authentifizierungsstati für die Prozesse des Architekturmodells
174
Anhang I – Beispielvorgang Adaption
Entfernung umgebende
HTML-Tags aus dem Template
Name:<#WERT1#>
Vorname: <#WERT2#>
weiter
Name:<#WERT1#>
Vorname:<#WERT2#>
weiter
Ausführung des Templates
(füllen durch Anwendung)
D
es
ig
nz
ei
t
HTML-Template
einer Portalkomponente
La
uf
ze
it
K
om
po
ne
nt
e
Anpassung der Verlinkung durch
Portalanwendung
Name: Mustermann
Vorname: Max
weiter
La
uf
ze
it
Po
rt
al
-
an
w
en
du
ng
sk
om
po
ne
nt
e
Name: Mustermann
Vorname: Max
weiter
Übergabe der Präsentation an
Portalsoftware
Schritte Ergebnisbeispiel
Abbildung 48: Beispielvorgang Adaption
175
Anhang J – Anwendungsfall Komponentenlandkarte PAK
PAK
Signatur
Abbildung Prozesse Realisierung mit
Funktionen
KAT Katalog Prozesse des Prozessbündels A
Katalog/Bereitstellung von technischer Information über
Produkte
SHOP-F1, -F4, CM-F4,
-F5, -F6, -F7, -F10
Kundenindividuelle Preisgestaltung SHOP-F3, -F2
Bereitstellung von Datenblättern CM-F2
Anzeige eines kundenindividuellen Produktkatalogs SHOP-F2, CM-F4, -F5,
-F6, -F7, -F10
Bestellung von Zubehör SHOP-F2, CM-F4, -F5,
-F6, -F7, -F10
Bereitstellung von technischen Zeichnungen CM-F3
TRANS Transaktion Prozesse des Prozessbündels B
Bestellvorgang durch Kunden/Transaktion SHOP-F7
Einsehen der eigenen Bestellhistorie/Auftragsstatus CRK-F7
Preisanfrage/Angebotsanforderung SHOP-F8
Elektronische Auftragsbestätigung, Bestellbestätigung ERK (intern), SHOP
(intern)
Verfügbarkeitsprüfung SHOP-F6
Vorlage für Bestellungen SHOP-F9
Bereitstellung Warenkorb SHOP-F4, -F5
Elektronische Rechnung CRK-F9
KNF Konfiguration Prozesse des Prozessbündels C
Konfiguration von Produkten KONF-F1, -F2
SUCHE Suche Prozesse des Prozessbündels D
Suche nach Produkten KAT
Suche nach Inhalten PWB, UINF
PWB Produktwahlunterstützung und Beratung Prozesse des Prozessbündels E
Applikationsbeschreibungen, Anleitungen, Handbücher,
redaktionelle Artikel
CM-F8, CM-F9
Produktvergleich/Beratung bei Produktwahl BER-F1, -F2
KOMM Kommunikation Prozesse des Prozessbündels F
Kommunikation mit Technischem Kundendienst/Support WFM-F1, -F2, CMK-F1,
-F2
Reklamation WFM-F1, -F2
Rückfrage zu Bestellungen WFM-F1, -F2
UINF Unternehmensinformation Prozesse des Prozessbündels G
Allgemeine Unternehmensinformation CM-F1
Tabelle 24: Anwendungsfall Komponentenlandkarte PAK