Vorgehensmodell zur Gestaltung internetbasierter Mehrwertdienste

Transcrição

Vorgehensmodell zur Gestaltung
internetbasierter Mehrwertdienste
für den Maschinen- und Anlagenbau
Von der Fakultät für Konstruktions-, Produktions- und Fahrzeugtechnik
der Universität Stuttgart zur Erlangung der Würde eines
Doktor-Ingenieurs (Dr.-Ing.) genehmigte Abhandlung
Vorgelegt von
Dipl.-Ing. Tom-David Graupner
aus Pforzheim
Hauptberichter:
Univ.-Prof. Dr.-Ing. Prof. e. h. Dr.-Ing. e. h. Dr. h. c. mult.
Engelbert Westkämper
Mitberichter:
Univ.-Prof. Dr.-Ing. Dr.-Ing. E.h. Dieter Spath
Tag der mündlichen Prüfung:
09. Dezember 2009
Institut für Industrielle Fertigung und Fabrikbetrieb der Universität Stuttgart
2010
IPA-IAO Forschung und Praxis
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
Institut für Industrielle
Fertigung und Fabrikbetrieb
Tom-David Graupner
Vorgehensmodell zur
Gestaltung internetbasierter
Mehrwertdienste für den
Maschinen- und Anlagenbau
Nr. 493
Fachverlag · 71296 Heimsheim
Dr.-Ing. Tom-David Graupner
Fraunhofer-Institut für Produktionstechnik und Automatisierung (IPA), Stuttgart
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
Univ.-Prof. Dr.-Ing. habil. Prof. E.h. mult. Dr. h.c. mult. Hans-Jörg Bullinger
Präsident der Fraunhofer-Gesellschaft, München
Fraunhofer-Institut für Arbeitswirtschaft und Organisation (IAO), Stuttgart
D 93
ISBN (10) 3-939890-55-3, ISBN (13) 978-3-939890-55-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 Urheberrechtsgesetzes 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 2010.
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, gegebenenfalls für die eigenen Arbeiten die vollständigen Vorschriften oder Richtlinien in der
jeweils gültigen Fassung hinzuzuziehen.
Druck: printsystem GmbH, Heimsheim
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änderungen signalisieren und begleiten dabei einen Wertewandel, der auch in unseren Industriebetrieben deutlichen Niederschlag findet.
Die Aufgaben des Produktionsmanagements sind vielfältiger und anspruchsvoller geworden. 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 Wirtschaft ihren Beitrag leisten muss, erfordern von den Führungskräften erweiterte Perspektiven und Antworten, die über den Fokus traditionellen Produktionsmanagements deutlich
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 kennzeichnen. 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. Qualifizierungsprogramme, Training und andere Formen der Mitarbeiterentwicklung gewinnen als Differenzierungsmerkmal 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 unterstützt
werden. Die Ingenieure sind hier gefordert, in enger Zusammenarbeit mit anderen
Disziplinen, z. B. der Informatik, der Wirtschaftswissenschaften und der Arbeitswissenschaft, 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 aufgezeigten 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 Schriftenreihe „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 des Autors
Die vorliegende Arbeit entstand während meiner Tätigkeit am Fraunhofer-Institut für Produktionstechnik und Automatisierung (IPA) in Stuttgart. Insbesondere das Verbundforschungsprojekt
E-Industrial Services und die assoziierten Projekte mit Industriepartnern haben wesentliche
Impulse für die Arbeit geliefert. Durch diese marktorientierte, strategische Vorlaufforschung konnte
der industrielle Bedarf identifiziert, Lösungsansätze erarbeitet und praktisch evaluiert werden.
Mein besonderer Dank gilt meinem Doktorvater Herrn Professor Engelbert Westkämper für die
Unterstützung und Förderung, die zum erfolgreichen Gelingen der Arbeit beigetragen haben. Herrn
Professor Dieter Spath danke ich für die wohlwollende Unterstützung sowie für die Übernahme des
Mitberichts.
Ein herzlicher Dank geht an meine ehemaligen Kollegen, für die zahlreichen inspirierenden Diskussionen und die gemeinsam durchgeführten Projekte. Besonders herausheben möchte ich dabei
meinen langjährigen Weggefährten Herrn Dr. Thomas Rist für die methodische Begleitung und
fortwährende Unterstützung. Weiterhin gilt mein Dank allen Studenten und studentischen Hilfskräfte, die bei der Implementierung der Anwendungsbeispiele tatkräftig mitgewirkt haben.
Mein ganz besonderer Dank geht an meine Eltern, die mir dies alles ermöglicht haben. Meiner
Frau Sonja und meinen Kindern, Sophia, Lea und Maximilian, danke ich für ihre Geduld, ihr Verständnis und ihre Unterstützung, mit der ich jederzeit rechnen konnte. Meiner Frau und meinen
Kindern widme ich diese Arbeit.
Stuttgart, im Januar 2010
Tom-David Graupner
Inhaltsverzeichnis
1
2
3
4
5
Einleitung......................................................................................................................... 17
1.1
Problemstellung ........................................................................................................................................17
1.2
Zielsetzung ...............................................................................................................................................18
1.3
Vorgehensweise .......................................................................................................................................19
Festlegung des Untersuchungsbereichs .......................................................................... 21
2.1
Der deutsche Maschinen- und Anlagenbau ..............................................................................................21
2.2
Industrielle Dienstleistungen .....................................................................................................................24
2.3
Fernerbrachte industrielle Dienstleistungen..............................................................................................28
2.4
Gestaltung internetbasierter Mehrwertdienste ..........................................................................................32
2.5
Defizite heutiger internetbasierter Mehrwertdienste..................................................................................34
Anforderungen an die Gestaltung internetbasierter Mehrwertdienste............................... 37
3.1
Anforderungen aus Sicht des Projektmanagements.................................................................................37
3.2
Anforderungen aus Sicht der Dienstleistungsgestaltung ..........................................................................38
3.3
Anforderungen aus Sicht der Informationstechnik ....................................................................................40
Stand der Technik............................................................................................................ 45
4.1
Methoden zur Prozessmodellierung .........................................................................................................45
4.2
Beschreibungs- und Ausführungssprachen zur Prozessmodellierung......................................................50
4.3
Konventionelle Vorgehensmodelle ...........................................................................................................54
4.4
Vorgehensmodelle des Service Engineerings ..........................................................................................58
4.5
Vorgehensmodelle des Software Engineerings ........................................................................................64
4.6
Parallele Gestaltung von Software und Dienstleistungen .........................................................................71
4.7
Zusammenfassende Bewertung der Vorgehensmodelle zur Gestaltung von Mehrwertdiensten ..............72
Zielsetzung, Lösungsansatz und Methodik ...................................................................... 74
5.1
Zielsetzung ...............................................................................................................................................74
5.2
Lösungsansatz..........................................................................................................................................75
5.3
Methodik ...................................................................................................................................................77
6 Informationsund
Kommunikationstechnologien
zur
Erbringung
internetbasierter
Mehrwertdienste ..................................................................................................................... 80
7
6.1
Infrastruktur...............................................................................................................................................80
6.2
Hardware-Architekturen............................................................................................................................86
6.3
Komponentenbasierte Software................................................................................................................89
6.4
Software-Architekturen .............................................................................................................................97
6.5
Softwaretechnologien .............................................................................................................................101
6.6
Automation aus Sicht der IT ...................................................................................................................112
Vorgehensmodell zur Gestaltung internetbasierter Mehrwertdienste ............................. 117
7.1
Methoden und Werkzeuge zur Gestaltung internetbasierter Mehrwertdienste .......................................118
7.2
E-Service-Strategie.................................................................................................................................121
7.3
E-Service-Design....................................................................................................................................123
7.4
E-Service-Infrastruktur............................................................................................................................135
7.5
E-Service-Prozessarchitektur .................................................................................................................138
7.6
E-Service-Integrationsarchitektur............................................................................................................141
7.7
E-Service-Anwendungsarchitektur..........................................................................................................144
7.8
E-Service-Datenarchitektur.....................................................................................................................147
Einleitung
8
9
- 10 -
7.9
E-Service-Rollenmodell ..........................................................................................................................150
7.10
Auswahl einer anforderungsgerechten Internetservice-Plattform ...........................................................151
7.11
E-Service-Komponentenkatalog .............................................................................................................156
7.12
E-Service-Kommunikationsarchitektur....................................................................................................166
7.13
E-Service-Komposition und -Konfiguration .............................................................................................169
7.14
IT-Service-Management .........................................................................................................................170
7.15
E-Service-Pilotierung und -Markteinführung ...........................................................................................173
Anwendung und Bewertung des Vorgehensmodells ...................................................... 174
8.1
Internetservice-Plattform von E-Industrial Services ................................................................................175
8.2
Anwendungsbeispiel: virtuelle Anlagenprojektierung..............................................................................177
8.3
Anwendungsbeispiel: internetbasierte Logistikanalyse...........................................................................187
8.4
Bewertung der Anwendungsbeispiele.....................................................................................................194
Zusammenfassung, Grenzen und Ausblick.................................................................... 195
9.1
Zusammenfassung .................................................................................................................................195
9.2
Grenzen..................................................................................................................................................197
9.3
Ausblick ..................................................................................................................................................198
10 Summary, Constraints and Outlook ............................................................................... 200
10.1
Summary ................................................................................................................................................200
10.2
Constraints..............................................................................................................................................201
10.3
Outlook ...................................................................................................................................................202
11 Literaturverzeichnis........................................................................................................ 204
Das Verbundforschungsprojekt E-Industrial Services............................................................ 227
Lebenslauf ............................................................................................................................ 228
Einleitung
- 11 -
Abbildungsverzeichnis
Abbildung 1-1: Mehrwertdienstleistungen im Produktlebenszyklus................................................................................... 17
Abbildung 1-2: Prinzipdarstellung des Themenfelds internetbasierter Mehrwertdienste ................................................... 19
Abbildung 1-3: Aufbau der Arbeit ...................................................................................................................................... 20
Abbildung 2-1: Anteil der Erwerbstätigen in den unterschiedlichen Sektoren ................................................................... 23
Abbildung 2-2: Umsätze und Renditen im deutschen Maschinen- und Anlagenbau ......................................................... 26
Abbildung 2-3: Anteil von Dienstleistungen in verschiedenen Kooperationsformen.......................................................... 27
Abbildung 2-4: Virtuelle Maschine beim Hersteller und virtueller Experte beim Betreiber................................................. 29
Abbildung 2-5: Beispiele fernerbrachte Dienstleistungen .................................................................................................. 30
Abbildung 2-6: Einordnung von Mehrwertdiensten im Lebenszyklus von Maschinen und Anlagen .................................. 31
Abbildung 2-7: Gestaltung fernerbrachter Dienstleistungen .............................................................................................. 33
Abbildung 3-1: Zykluszeit von Anwendungs- und Systemsoftware sowie von Hardware .................................................. 42
Abbildung 4-1: Service-Blueprinting-Beispiel .................................................................................................................... 46
Abbildung 4-2: Erweiterte Ereignisgesteuerte Prozesskette (eEPK) ................................................................................. 47
Abbildung 4-3: Use-Case-Diagramm ................................................................................................................................ 48
Abbildung 4-4: Workflow Reference Model der Workflow Management Coalition............................................................. 50
Abbildung 4-5: Vorgehensmodell des Methodischen Konstruierens ................................................................................. 55
Abbildung 4-6: Phasengliederung des Systems Engineerings .......................................................................................... 57
Abbildung 4-7: Phasenmodell zur Entwicklung von Dienstleistungen ............................................................................... 59
Abbildung 4-8: Strategiechart zur Positionierung produktbegleitender Dienstleistungen .................................................. 60
Abbildung 4-9: Strategiechart zur monetären Klassifikation produktbegleitender Dienstleistungen .................................. 60
Abbildung 4-10: Möglichkeiten der Kundeneinbindung ..................................................................................................... 61
Abbildung 4-11: Spiralmodell zur Softwareentwicklung..................................................................................................... 65
Abbildung 4-12: Horizontaler und vertikaler Prototyp ........................................................................................................ 68
Abbildung 4-13: Co-Design von Software und Services.................................................................................................... 71
Abbildung 5-1: Zielsetzung der Arbeit ............................................................................................................................... 74
Abbildung 5-2: Die fünf Sichten des Reference Model of Open Distributed Processing ................................................... 77
Abbildung 6-1: Aufbau und Inhalt des 6. Kapitels.............................................................................................................. 80
Abbildung 6-2: Zeitliche Entwicklung der Architekturen .................................................................................................... 86
Abbildung 6-3: Komponentenbasierte Systeme ................................................................................................................ 90
Abbildung 6-4: Metaschema eines Komponentenmodells................................................................................................. 90
Abbildung 6-5: Beschreibungsebenen und zu spezifizierende Sachverhalte von Komponenten ...................................... 94
Abbildung 6-6: Ablauf der modellgetriebenen Architektur ................................................................................................. 95
Abbildung 6-7: Kommunikation in verteilten Systemen unter Nutzung der IDL ............................................................... 107
Abbildung 6-8: Protokoll-Stack von Web-Services .......................................................................................................... 108
Abbildung 6-9: Proprietäre Kommunikation..................................................................................................................... 113
Abbildung 6-10: Bushierarchie ........................................................................................................................................ 113
Abbildung 6-11: Industrieautomation mit systemweiter Middleware ................................................................................ 115
Abbildung 7-1: Vorgehensweise zur Gestaltung internetbasierter Mehrwertdienste ....................................................... 117
Einleitung
- 12 -
Abbildung 7-2: Methodenbeispiel aus der Methodensammlung von E-Industrial Services ............................................. 119
Abbildung 7-3: Anforderungsmanagementprozess ......................................................................................................... 127
Abbildung 7-4: ASP-Wertschöpfungskette ...................................................................................................................... 128
Abbildung 7-5: Aufwand-Nutzen-Relation für IT-Sicherheit ............................................................................................. 133
Abbildung 7-6: Spezifikation einer physikalischen Infrastruktur sowie eines Zonenkonzepts.......................................... 137
Abbildung 7-7: Exemplarische E-Service-Prozessarchitektur ......................................................................................... 140
Abbildung 7-8: Integrationsmöglichkeiten zwischen IT-Systemen................................................................................... 141
Abbildung 7-9: Kooperationskomponenten ..................................................................................................................... 159
Abbildung 7-10: Vorgehensweise zur Spezifikation neuer Softwarekomponenten.......................................................... 163
Abbildung 7-11: Methodik des Service-Managements nach ISO 20000 ......................................................................... 171
Abbildung 8-1: Anwendungsarchitektur des Projekts E-Industrial Services .................................................................... 175
Abbildung 8-2: Konventioneller Prozess zur Anlagenprojektierung................................................................................. 177
Abbildung 8-3: Linie zur Prüfung von elektronischen Leiterplatten.................................................................................. 178
Abbildung 8-4: Anlage zur Isolierglasscheibenherstellung .............................................................................................. 179
Abbildung 8-5: Virtuelles Anlagenmodell zur Isolierglasscheibenherstellung .................................................................. 179
Abbildung 8-6: E-Service-Prozessarchitektur des Dienstes virtuelle Anlagenprojektierung ............................................ 180
Abbildung 8-7: Benutzeroberfläche des Anlagenkonfigurators zur Prüfung von Leiterplatten......................................... 183
Abbildung 8-8: Benutzeroberfläche des Konfigurators zur Anlagenprojektierung von Isolierglasscheiben ..................... 184
Abbildung 8-9: Ergebnis der E-Anlagenkonfigurationauf der geschützten Webseite ...................................................... 185
Abbildung 8-10: Immersive Visualisierung einer konfigurierten Anlage in einer 3-Seiten-CAVE..................................... 186
Abbildung 8-11: Benutzeroberfläche der internetbasierten Logistikanalyse .................................................................... 192
Abbildung 8-12: Auswertungsmöglichkeiten am Beispiel der Durchlaufzeit .................................................................... 193
Abbildung 11-1: Projektpartner der strategischen Innovationsinitiative E-Industrial Services ......................................... 227
Einleitung
- 13 -
Tabellenverzeichnis
Tabelle 2-1: Umfang und Bedeutung von Dienstleistungen .............................................................................................. 25
Tabelle 3-1: Allgemeine Anforderungen an IT-Systeme.................................................................................................... 41
Tabelle 3-2: Anforderungen an Netzwerke........................................................................................................................ 44
Tabelle 3-3: Anforderungen an die IT-Sicherheit............................................................................................................... 44
Tabelle 4-1: Prozessschritte des Problemlösungsprozesses ............................................................................................ 54
Tabelle 4-2: Softwareentwicklungsphasen des Unified Process ....................................................................................... 66
Tabelle 4-3: Vergleichende Gegenüberstellung der Eigenschaften von Vorgehensmodellen ........................................... 69
Tabelle 4-4: Vergleichende Bewertung von Vorgehensmodellen für das Software Engineering....................................... 70
Tabelle 4-5: Gesamtbeurteilung der vorgestellten Vorgehensmodelle.............................................................................. 72
Tabelle 6-1: Netzwerkeigenschaften von Intranet, Extranet, Internet, VPN und PN.......................................................... 83
Tabelle 6-2: Bewertung verschiedener Netzwerke............................................................................................................ 83
Tabelle 6-3: Bandbreiten verschiedener Netzwerke.......................................................................................................... 83
Tabelle 6-4: Beschreibung verschiedener Infrastrukturen ................................................................................................. 85
Tabelle 6-5: Gegenüberstellung der Vor- und Nachteile von Mainframe-Architekturen .................................................... 86
Tabelle 6-6: Gegenüberstellung der Vor- und Nachteile von Filesharing-Architekturen.................................................... 87
Tabelle 6-7: Gegenüberstellung der Vor- und Nachteile von Client-Server-Architekturen ................................................ 87
Tabelle 6-8: Gegenüberstellung der Vor- und Nachteile von Terminalserver-Architekturen.............................................. 88
Tabelle 6-9: Vorgehensweisen zur komponentenbasierten Softwareentwicklung............................................................. 91
Tabelle 6-10: Eigenschaften von Softwarekomponenten .................................................................................................. 92
Tabelle 6-11: Vor- und Nachteile von JavaBeans zur Erstellung von Java-Applets ........................................................ 101
Tabelle 6-12: Vor- und Nachteile von ActiveX................................................................................................................. 102
Tabelle 6-13: PHP, ASP und Java-Servlets .................................................................................................................... 104
Tabelle 6-14: Komponententechnologien im Überblick ................................................................................................... 111
Tabelle 7-1: Methodensammlung zur Gestaltung internetbasierter Mehrwertdienste ..................................................... 120
Tabelle 7-2: Ansatzpunkte zur Verbesserung existierender Dienstleistungen................................................................. 125
Tabelle 7-3: Anforderungsanalyse aus Sicht der beteiligten Partner............................................................................... 128
Tabelle 7-4: Anforderungstypen ...................................................................................................................................... 129
Tabelle 7-5: Anforderungsarten....................................................................................................................................... 129
Tabelle 7-6: Vorgehensweise zur Erstellung eines IT-Sicherheitskonzeptes (1. Teil) ..................................................... 131
Tabelle 7-7: Vorgehensweise zur Erstellung eines IT-Sicherheitskonzeptes (2. Teil) ..................................................... 132
Tabelle 7-8: Gegenüberstellende Bewertung verschiedener Hardware-Architekturen.................................................... 135
Tabelle 7-9: Teilschritte, Aktionen und Rollen in der Dienstanbahnung und -vorbereitung ............................................. 138
Tabelle 7-10: Teilschritte, Aktionen und Rollen in der Dienstverhandlung und –vereinbarung ....................................... 139
Tabelle 7-11: Teilschritte, Aktionen und Rollen in der Dienstnutzung ............................................................................. 139
Tabelle 7-12: Teilschritte, Aktionen und Rollen in der Beendigung der Dienstnutzung ................................................... 140
Tabelle 7-13: Teilschritte, Aktionen und Rollen in der Beendigung des Dienstzugangs.................................................. 140
Tabelle 7-14: Integrationsarten von Diensten.................................................................................................................. 141
Tabelle 7-15: Beschreibung der Integrationsmöglichkeiten zwischen IT-Systemen........................................................ 142
Einleitung
- 14 -
Tabelle 7-16: Architektonische Prinzipien zur Gestaltung von E-Service-Anwendungsarchitekturen ............................. 145
Tabelle 7-17: Merkmale zur Interoperabilität von Anwendungen, Komponenten und Diensten ...................................... 148
Tabelle 7-18: Vorgehensweise zur Standardisierung von Datenmodellen ...................................................................... 149
Tabelle 7-19: Technische Anforderungen zur Auswahl einer anforderungsgerechten Internetservice-Plattform ............ 152
Tabelle 7-20: Rahmenbedingungen zur Auswahl einer anforderungsgerechten Internetservice-Plattform..................... 153
Tabelle 7-21: Checkliste mit Hinweisen zur Auswahl einer anforderungsgerechten Internetservice-Plattform (1. Teil) .. 153
Tabelle 7-22: Checkliste mit Hinweisen zur Auswahl einer anforderungsgerechten Internetservice-Plattform (2. Teil) .. 154
Tabelle 7-23: Transportkomponenten beziehungsweise Internet-Basisdienste .............................................................. 157
Tabelle 7-24: Verzeichnisdienste .................................................................................................................................... 158
Tabelle 7-25: Sicherheitstechnologien für verschiedene Anwendungsfälle..................................................................... 160
Tabelle 7-26: Anwendungskomponenten........................................................................................................................ 161
Tabelle 7-27: Administrationskomponenten .................................................................................................................... 162
Tabelle 7-28: Integrationskomponenten .......................................................................................................................... 167
Tabelle 7-29: Bewertung der Einsatzmöglichkeit im Architekturmodell ........................................................................... 168
Tabelle 7-30: IT-Grundschutz-Standards des BSI........................................................................................................... 172
Tabelle 7-31: Typische Pilotierungsprobleme ................................................................................................................. 173
Tabelle 8-1: Fachübergreifende Komponenten der Internetservice-Plattform von E-Industrial Services ........................ 176
Tabelle 8-2: Elemente der E-Service-Anwendungsarchitektur ........................................................................................ 181
Tabelle 8-3: Benötigte Daten zu Ressourcen (RES) ....................................................................................................... 188
Tabelle 8-4: Benötigte Daten zu Fertigungsaufträgen (FAT)........................................................................................... 189
Tabelle 8-5: Benötigte Daten zu Arbeitsgängen (AVG) ................................................................................................... 189
Tabelle 8-6: Nutzbare Daten zu Arbeitsgangtexten (AGT) .............................................................................................. 189
Tabelle 8-7: Benötigte Daten zu Rückmeldungen (RMG) ............................................................................................... 189
Tabelle 8-8: Berechnete logistische Kenngrößen............................................................................................................ 191
Einleitung
- 15 -
Abkürzungen
Abkürzung
Bedeutung
API
Application Programming Interface
ASP
Application Service Provider oder Active Server Pages
BDE
Betriebsdatenerfassung
BPM
Business Process Management
CGI
Common Gateway Interface
COM / COM+
Component Object Model
CORBA
Common Object Request Broker Architecture
DBMS
Datenbankmanagementsystem
DCOM
Distributed Component Object Model
DIN
Deutsches Institut für Normung
DTD
Document Type Definition
EAI
Enterprise Application Integration
EDM
Engineering Data Management
EJB
Enterprise JavaBeans
ERP
Enterprise Resource Planning
FTP
File Transfer Protocol
HTML
Hypertext Markup Language
HTTP
Hypertext Transfer Protocol
HTTPS
Hypertext Transfer Protocol Secure
IDL
Interface Definition Language oder Interface Description Language
IMAP
Internet Message Access Protocol
IP
Internet Protocol
ISO
International Organization for Standardization
ISP
Internet Service Provider
ITIL
Information Technology Infrastructure Library
ITSM
IT-Service-Management
Java EE
Java Platform, Enterprise Edition
JVM
Java Virtual Machine
JSP
Java Server Pages
LAN
Local Area Network
LDAP
Lightweight Directory Access Protocol
OASIS
Organization for the Advancement of Structured Information Standards
OMG
Object Management Group
ORB
Object Request Broker
PDA
Personal Digital Assistent
PDM
Product Data Management
PLM
Product Lifecycle Management
RMI
Remote Method Invocation
RM-ODP
Reference Model of Open Distributed Processing
RUP
Rational Unified Process
Einleitung
- 16 -
RPC
Remote Procedure Call
SOA
Service Oriented Architecture
TCP
Transmission Control Protocol
UDDI
Universal Description, Discovery and Integration
UML
Unified Modeling Language
URL
Unified Resource Locator
VDMA
Verband Deutscher Maschinen- und Anlagenbauer e. V.
VPN
Virtual Private Network
W3C
World Wide Web Consortium
WAN
Wide Area Network
WSDL
Web Service Description Language
XML
Extensible Markup Language
1 Einleitung
Der beste Weg, die Zukunft vorauszusagen, besteht darin, sie zu erfinden.
John Sculley
Präsident und CEO
Apple, Inc.
1.1 Problemstellung
Die Produktivität und Flexibilität produzierender Unternehmen sowie die Qualität ihrer Produkte
und Dienstleistungen hängt heute bereits zum größten Teil von Software ab. Software ist infolgedessen zu einem bedeutenden Wirtschaftsfaktor geworden1. Sie ist eigenständiges Marktprodukt,
integraler Bestandteil von Produkten und liefert die Grundlage für die Abwicklung von Geschäftsprozessen.
Auch bei Investitionsgütern werden mechanische Komponenten zunehmend durch Software
substituiert. Investitionsgüter mit einem hohen Softwareanteil bieten prinzipbedingt eine gute Plattform für die Erbringung elektronischer Dienstleistungen, die auch über große Distanzen hinweg in
die Zielmärkte deutscher Maschinen- und Anlagenbauer exportiert werden können. Wenn es den
Investitionsgüterherstellern gelingt, Nutzen steigernde Dienste in ihre Maschinen und Anlagen zu
integrieren, kann dem Systembetreiber hieraus ein über das gängige Leistungsangebot hinausgehender Zusatznutzen – ein Mehrwert – entstehen.
Mehrwertdienstleistungen unterstützen den Systembetreiber bei der Systementstehung, bei einer
schnellen Inbetriebnahme, im reibungslosen Systembetrieb sowie in der unkomplizierten Systemveränderung. Die Mehrwertdienstleistungen erstrecken sich demnach über den gesamten Produktlebenszyklus. Beispiele für etablierte Dienstleistungen sind in Abbildung 1-1 aufgeführt.
Systementstehung
Mehrwertdienst
- Spezifikations-, Zertifizierungsdienste
- Animation, Visualisierung
- Planung, Simulation
Mehrwert
- Senken Entwicklungs- und Herstellkosten
- Verkürzen der Produktentstehungszeit
- Verbessern der Produktqualität
Systemveränderung
Systeminbetriebnahme
Mehrwertdienst
- Montage, Anschluss
- Einfahren, Serienanlauf
- Schulung, Training
Produktlebenszyklus
Mehrwertdienst
- Rekonfiguration
- Gebrauchtkomponentenmanagement
- Demontage, Re-Use
Mehrwert
- Verkürzen der Rekonfigurationszeiten
- Verlängern der Nutzungsdauer
- Verringern des Investitionsbedarfs
Abbildung 1-1: Mehrwertdienstleistungen im Produktlebenszyklus
1
Vgl. /Mert-2004 (S. 21)/Weis-2002 (S. 21)/.
Mehrwert
- Verkürzen der Inbetriebnahmezeit
- Vorziehen und Beschleunigen des Lernens
- Sichern der Prozessfähigkeit
Systembetrieb
Mehrwertdienst
- Telebetrieb, -consulting
- Optimierung, Tuning
- Logistikdienste
Mehrwert
- Verbessern der Prozessbeherrschung
- Verkürzen nicht produktiver Zeiten
- Senken der Betriebskosten
Einleitung
- 18 -
Die Ausrichtung künftiger internetbasierter Mehrwertdienste wird eine verstärkte Bündelung von
Dienstleistungsangeboten berücksichtigen müssen, die sowohl das Zusammenspiel mit Kunden,
Zulieferern und Service-Technikern als auch ein innerbetriebliches Verschmelzen der Service- und
IT-Prozesse erforderlich machen. Dabei gehen die Grenzen zwischen klassischem Service und
internetbasierten Angeboten fließend ineinander über1.
In zunehmendem Maße versuchen Maschinen- und Anlagenbauer durch die Bündelung von Investitionsgütern und Mehrwertdienstleistungen kombinierte Angebote, sogenannte hybride
Servicedienstleistungen2, anzubieten. Hybride Servicedienstleistungen haben inzwischen eine
hohe Bedeutung erlangt und sind ein Differenzierungsmerkmal gegenüber Wettbewerbern. Eine
Voraussetzung zur Bündelung von Dienstleistungsangeboten, und damit zur Schöpfung von
Synergiepotenzialen, ist deren Interoperabilität. Interoperable internetbasierte Dienstleistungen für
Maschinen und Anlagen stehen allerdings erst am Anfang ihrer Entwicklung. Bisher wurden Mehrwertdienste vorwiegend in Einzelprojekten konzipiert und realisiert. Kundenspezifische Lösungen
führten zu einer hohen Variantenvielfalt. Eine gezielte Wiederverwendung oder eine projektübergreifende Zusammenarbeit fand bisher selten statt. Produktfamilien oder Plattformkonzepte lassen
sich bei der Dienstleistungsgestaltung bestenfalls in Ansätzen finden3.
Die Folge: hoher Aufwand in der Entwicklung und Wartung von Mehrwertdiensten, zu lange Umsetzungszeiträume zwischen Ideenfindung und Inbetriebnahme sowie qualitativ und technisch
nicht ausgereifte Gesamtsysteme. Untersuchungen von Mertins et al.4 zufolge sind Flopraten von
50 bis 80 Prozent bei der Markteinführung neuer IT-Dienstleistungen zu beobachten5.
1.2 Zielsetzung
Um Mehrwertdienste erfolgreich entwickeln und betreiben zu können, müssen diese sorgfältig und
methodisch geplant, konzipiert und implementiert werden. Bei der Suche nach geeigneten
Methoden muss man jedoch feststellen, dass diese fehlen beziehungsweise gerade erst entwickelt
werden6. Vorhandene Ansätze des Service Engineerings und des Software Engineerings berücksichtigen bisher die spezifischen Randbedingungen industrieller Dienstleistungen nur ungenügend7. Erschwerend kommt hinzu, dass die Entwicklung internetbasierter Mehrwertdienste
gegenüber manuell erbrachten Dienstleistungen schwieriger ist. Neben der Dienstleistungskonzeption müssen auch Fragestellungen der Diensterbringung und IT-Sicherheit beantwortet werden.
Die vorliegende Arbeit beschäftigt sich mit der Erstellung eines generischen Vorgehensmodells zur
Gestaltung internetbasierter Mehrwertdienste. Die Arbeit soll Unternehmen aus dem Maschinenund Anlagenbau dazu befähigen, internetbasierte Mehrwertdienste schneller und qualitativ hochwertiger zu konzipieren, zu implementieren und am Markt zu platzieren. Das dabei verfolgte Ziel
ist, den Aufwand und das Risiko solcher Vorhaben deutlich zu reduzieren. Das zu schaffende
Vorgehensmodell muss dabei den Entwicklungsprozess sowohl für die Informationstechnik als
auch für die zu realisierenden Dienste definieren.
1
2
3
4
5
6
7
Vgl. /Meie-2004b (S. 7)/.
Unter hybriden Servicedienstleistungen werden Kombinationen aus gemeinsam angebotenen Dienstleistungen und
Sachgütern verstanden. Vgl. Kapitel 2.2.2.
Vgl. /Spec-2005 (S. 21)/.
Vgl. /Mert-2004 (S. 9)/.
Zu vergleichbaren Ergebnissen kommen auch die sogenannten Chaos-Studien von Standish. Lediglich 25 Prozent
der analysierten IT-Projekte sind demnach erfolgreich. Vgl. /Stan-2006/Stan-1994/.
Vgl. /Bull-2006/Fähn-2006/Huse-2005/Spat-2005a/Spec-2005/Fähn-2004b/Fähn-2004a/.
Vgl. /Mert-2004/VDI-2001/.
Einleitung
- 19 -
Hierzu werden Verfahren zum Aufbau von Anwendungssystemen aus Komponenten vorgestellt,
verschiedene Software-Architekturen und Infrastrukturen erläutert sowie Ansätze zur Errichtung
eines IT-Sicherheitskonzepts erarbeitet. Diese technischen und organisatorischen Aspekte sollen
in ein Vorgehensmodell eingebettet werden, das damit eine ganzheitliche Orientierungshilfe für
das Themenfeld der internetbasierten Mehrwertdienstleistungen bieten soll (siehe Abbildung 1-2).
Maschine
Industrielle
Industrielle
Dienstleistungen
Dienstleistungen
Software
Software
Plattform
Plattform
Architektur
Architektur
Infrastruktur
Infrastruktur
IT-Sicherheit
IT-Sicherheit
Internetbasierte
Mehrwertdienste
Software
Planung
Planung
Inbetriebnahme
Inbetriebnahme
Wartung/Instandhaltung
Wartung/Instandhaltung
Dienstleistung
IT-Dienstleistungen
IT-Dienstleistungen
Konzeption
Konzeption
Softwareentwicklung
Softwareentwicklung
Application
Application Service
Service
Providing
Providing
Abbildung 1-2: Prinzipdarstellung des Themenfelds internetbasierter Mehrwertdienste
1.3 Vorgehensweise
Die Arbeit gliedert sich, wie folgt (siehe Abbildung 1-3):

Das Kapitel 2 widmet sich den veränderten Rahmenbedingungen im Maschinen- und Anlagenbau und belegt diese anhand von Studien. Im Anschluss erfolgt die Beschreibung konventionell- und fernerbrachter industrieller Dienstleistungen. Der Schluss des Kapitels widmet
sich den Defiziten heutiger internetbasierter Mehrwertdienste.

In Kapitel 3 erfolgt die Definition der Anforderungen an die Gestaltung internetbasierter Mehrwertdienste.

Die in der Forschung und der betrieblichen Praxis angewandten Vorgehensmodelle zur Gestaltung internetbasierter Mehrwertdienste sind im Kapitel 4 zusammengefasst, soweit diese
für die vorliegende Arbeit relevant sind.

Die Beschreibung des prinzipiellen Lösungsansatzes dieser Arbeit erfolgt in Kapitel 5.

Das Kapitel 6 behandelt die softwaretechnischen Grundlagen für die Entwicklung und Erbringung elektronischer Dienste. Hierfür werden Komponententechnologien, SoftwareArchitekturen, Infrastrukturen etc. zur Erbringung von Diensten vorgestellt.

In Kapitel 7 erfolgt die ausführliche Beschreibung des Vorgehensmodells zur Gestaltung internetbasierter Mehrwertdienste für den Maschinen- und Anlagenbau.

Die Evaluation des Vorgehensmodells anhand von zwei Anwendungsfällen ist Gegenstand des
8. Kapitels.

Die Arbeit endet im Kapitel 9 mit einer Zusammenfassung und einem Ausblick.
d
h
i
Stand der Technik
Ziel,
Lösung,
Methodik
g
IT zur Erbringung
internetbasierter
Mehrwertdienste
f
e
Anforderungen
c
Einleitung
- 20 -
Festlegung des
Untersuchungsbereichs
Einleitung
Problemstellung
Zielsetzung
Der deutsche Maschinenund Anlagenbau
Industrielle
Dienstleistungen
Vorgehensweise
Fernerbrachte industrielle
Dienstleistungen
Gestaltung fernerbrachter
Dienstleistungen
Problemfelder heutiger internetbasierter Mehrwertdienste
Projektmanagement
Methoden
zur
Prozessmodellierung
Dienstleistungskonzeption
Beschreibungs- u.
Ausführungs
-sprachen
Konventionelle
Vorgehensmodelle
Informationstechnologie
Service
Engineering
Parallele
Gestaltung
von Software
und Dienstleistungen
Software
Engineering
Zusammenfassende Bewertung der Vorgehensmodelle zur Gestaltung internetbasierter Mehrwertdienste
Zielsetzung
Lösungsansatz
Methodik
Infrastruktur
HardwareArchitektur
Komponentenbasierte
Software
SoftwareArchitekturen
Softwaretechnologien
Methoden
und
Werkzeuge
E-ServiceStrategie
E-ServiceDesign
E-ServiceInfrastruktur
E-ServiceProzessarchitektur
E-ServiceIntegrationsarchitektur
E-ServiceAnwendungsarchitektur
E-ServiceKomponentenkatalog
E-ServiceDatenarchitektur
E-ServiceKommunikationsarchitektur
E-ServiceRollenmodell
E-ServiceKomposition
und Konfiguration
Automation
aus Sicht der
IT
Auswahl
InternetservicePlattform
IT-ServiceManagement
E-ServicePilotierung
und
Einführung
j
Anwendung und
Bewertung
Internetservice-Plattform von E-Industrial Services
Anwendungsbeispiel: virtuelle Anlagenprojektierung
Anwendungsbeispiel: internetbasierte Logistikanalyse
k
Zusammenfassung
Bewertung der Anwendungsbeispiele
Abbildung 1-3: Aufbau der Arbeit
Zusammenfassung und Ausblick
2 Festlegung des Untersuchungsbereichs
Intelligente Web-Services sind für das Informationszeitalter das,
was austauschbare Komponenten für das Industriezeitalter waren.
Scott McNealy
Chairman of the Board of Directors
Sun Microsystems, Inc
Das Kapitel 2 dient zur Einordnung der Arbeit und zur Festlegung des Untersuchungsbereichs.
Ausgehend von den veränderten Rahmenbedingungen im Maschinen- und Anlagenbau wird die
Bedeutung industrieller Dienstleistungen hergeleitet und durch Studien belegt. Am Schluss des
Kapitels erfolgt die Zusammenfassung der Problemfelder und des Handlungsbedarfs.
2.1 Der deutsche Maschinen- und Anlagenbau
2.1.1
Kennzahlen des deutschen Maschinen- und Anlagenbaus
Der deutsche Maschinen- und Anlagenbau zählt neben der Automobil-, elektrotechnischen und
chemischen Industrie zu den bedeutendsten Industriebranchen Deutschlands. Mehr als 862.000
Mitarbeiter erwirtschaften im Jahr 2005 in knapp 6.000 Unternehmen einen Umsatz von 151 Mrd.
Euro. Die Branche ist in 21 von 31 Fachzweigen weltweit führend im Export. Auch in den übrigen
Fachzweigen belegt der deutsche Maschinen- und Anlagenbau die vorderen Plätze. Die im Jahr
2005 erzielte Exportquote von 74 Prozent unterstreicht die große Bedeutung der Auslandsmärkte.
Der deutsche Maschinen- und Anlagenbau ist überwiegend mittelständisch strukturiert. Über 90
Prozent der Unternehmen bestehen aus kleinen und mittleren Betrieben mit bis zu 500 Mitarbeitern; lediglich 2 Prozent beschäftigen mehr als 1.000 Mitarbeiter1.
2.1.2
Veränderungen in den Absatzmärkten
Die Stärke des deutschen Maschinen- und Anlagenbaus liegt traditionell in dem hohen Technologie- und Innovationsgehalt seiner Produkte, in hoher Qualität sowie in der Fähigkeit, die Produkte
individuell auf Kundenwünsche zuzuschneiden. Über diese Wettbewerbsfaktoren gelang es bisher,
die kostengünstigere Konkurrenz abzuwehren2.
Die Produktionsunternehmen werden jedoch am Anfang des 21. Jahrhunderts mit sich verschärfenden Marktbedingungen konfrontiert. Der zunehmende Kosten- und Preisdruck sowie die
Individualisierung der Kundenwünsche kennzeichnen heute die Wettbewerbssituation der Unternehmen. Damit einher gehen weiterhin kürzer werdende Innovationszyklen in der Produktionstechnologie, die kürzere Produktzyklen erfordern. Da der globale Wettbewerb in diesen Feldern
jedoch aufgeholt hat, steht der deutsche Maschinen- und Anlagenbau vor weitreichenden Aufgaben, um auch in Zukunft wettbewerbsfähig zu bleiben3.
1
2
3
Vgl. /VDMA-2006a (S. 7)/VDMA-2006c (S. 14)/DIHK-2006 (S. 26)/.
Vgl. /Merc-2006 (S. 13)/Lay-2001 (S. 19)/.
Vgl. /Merc-2006 (S. 16)/.
Festlegung des Untersuchungsbereichs
- 22 -
Die in der Vergangenheit erzielten Exporterfolge dürfen nicht darüber hinwegtäuschen, dass die
reine Belieferung der Auslandsmärkte mit Maschinen und Anlagen aus Deutschland unter den veränderten Bedingungen oft nicht mehr ausreicht. Internationale Kunden wollen zunehmend die
Präsenz des Maschinenherstellers am Einsatzort, um z. B. bei einem Anlagen- oder Prozessproblem schnelle Hilfe zu bekommen. Hinzu kommt, dass die Wettbewerbsfähigkeit des deutschen
Maschinenbaus in entscheidendem Maße von der Erschließung der Wachstumsmärkte des fernen,
außereuropäischen Auslands abhängt1.
Die Veränderungen in den Absatzmärkten stellen die Investitionsgüterhersteller vor besondere
Herausforderungen in Bezug auf ihre technologische, organisatorische und kommunikative Innovationsfähigkeit. Nicht zuletzt deshalb, weil die Globalisierung auch den Warenabsatz von internationalen Mitbewerbern auf heimischen Märkten ermöglicht hat.
2.1.3
Zunehmende Komplexität der Maschinen und Anlagen
Die Ursache für die steigende Komplexität der Maschinen und Anlagen steht im direkten Zusammenhang mit dem Wunsch nach größtmöglicher Produktivität, die durch das Vordringen in die
technischen Grenzbereiche ermöglicht wird. Zugleich steigen die Forderungen der Betreiber nach
Zuverlässigkeit, Verfügbarkeit und Prozessfähigkeit. Neue Maschinen und Anlagen können häufig
nur noch mit unterstützenden Dienstleistungen des Herstellers in Betrieb genommen werden2. Bei
Funktionsstörungen ist eine kompetente Herstellerunterstützung notwendig. Durch die starke Verbreitung technologisch anspruchsvoller Investitionsgüter steigt die Nachfrage nach Wartungs-,
Reparatur- und Beratungsleistungen seit Jahren an3.
2.1.4
Informations- und Kommunikationstechnologien
Von den modernen Informations- und Kommunikationstechnologien gehen nachhaltige Impulse
aus. Die ortsunabhängige und unmittelbare Verfügbarkeit von Informationen und die Fähigkeit zum
raschen Austausch von Daten haben existenzielle Bedeutung in der Industrie erlangt4. Software ist
infolgedessen zu einem bedeutenden Wirtschaftsfaktor geworden. Sie ist ein eigenständiges
Marktprodukt, ein integraler Bestandteil von Produkten und die Grundlage für die Unternehmensinfrastruktur bei der Unterstützung von Geschäftsprozessen. Die Produktivität und Flexibilität von
Unternehmen sowie die Qualität ihrer Produkte und Dienstleistungen hängt heute bereits zum
größten Teil von leistungsfähiger Software ab. Der schnellen und effizienten Entwicklung von
Software kommt somit eine immer größer werdende Bedeutung zu5. Seit Jahren ist eine zunehmende Integration informationstechnischer Komponenten in Maschinen und Anlagen zu beobachten. Solche eingebetteten Systeme6 bestehen aus einer Software- und Hardware-Einheit,
1
2
3
4
5
6
Die positive Entwicklung des Maschinen- und Anlagenbaus in den Jahren 2004-2006 basierte zu großen Teilen auf
seinen Exporterfolgen. Impulse aus dem Inlandsmarkt blieben weitgehend aus. Vgl. /VDMA-2006a (S. 7)/.
Als Maschinenhersteller bzw. Hersteller werden Lieferanten von Anlagen oder Maschinen betrachtet. Als Systembetreiber bzw. Betreiber werden die Nutzer bzw. Anwender der gelieferten Maschinen und Anlagen bezeichnet.
Industrielle Dienstleistungen können sowohl von Maschinenherstellern als auch von Service-Providern bzw. Systemdienstleistern durchgeführt werden. Um die Lesbarkeit zu verbessern, findet in der Arbeit keine Rollentrennung statt.
Es wird angenommen, dass der Maschinenhersteller alle Dienstleistungen erbringt. Vgl. /VDMA-2006b (S. 8)/.
Vgl. /Kräm-2006 (S. 374)/Herm-2000 (S. 18)/DIN-75 (S. 15).
TNS Infratest berichtet regelmäßig über den Entwicklungsstand der deutschen Informations- und Kommunikationswirtschaft und Deutschlands Positionierung im europäischen und internationalen Vergleich. Vgl. /BMWi-2007/.
Vgl. /Wild-2006b (S. 22)/Weis-2002 (S. 27)/.
Embedded Systems, englisch für eingebettete Systeme. Als Embedded Systems werden Elektronik-Systeme bezeichnet, welche in größere Umgebungen integriert sind. Sie werden für spezielle Anwendungen entworfen und
führen dezidierte Funktionen innerhalb eines Gesamtsystems aus. Vgl. /VDMA-2000b/.
- 23 -
die über Sensoren und Aktoren mit dem Gesamtsystem verbunden sind. Bereits im Jahr 2000 betrug der Kostenanteil der Elektronik und Software im Maschinen- und Anlagenbau zwischen 20
und 30 Prozent. Bei Unikaten erreichen die Softwarekosten sogar Anteile von 75 Prozent bis 80
Prozent der Herstellungskosten1. Erzeugnisse mit einem hohen Softwareanteil bieten prinzipbedingt eine gute Plattform für die Ausweitung der Geschäftstätigkeit in Richtung zusätzlicher
Dienstleistungen.
2.1.5
Strukturwandel
Seit Jahren vollziehen sich in Deutschland – wie auch in anderen Industrienationen – weitreichende Strukturveränderungen, die durch einen zunehmenden Anteil des tertiären Sektors am
Bruttoinlandsprodukt gekennzeichnet sind. Dienstleistungen machen mittlerweile circa 70 Prozent
der Bruttowertschöpfung in Deutschland aus, 67 Prozent der Erwerbstätigen arbeiten im Dienstleistungssektor (siehe Abbildung 2-1).
Abbildung 2-1: Anteil der Erwerbstätigen in den unterschiedlichen Sektoren2
2.1.6
Zusammenfassende Bewertung
Die Investitionsgüterindustrie erfährt im Übergang von der national orientierten Industriegesellschaft in die global operierende Informations- und Wissensgesellschaft einen grundlegenden
Wandel, der ein Überdenken bisheriger Konzepte und grundsätzlicher Gesetzmäßigkeiten notwendig macht. Dabei wird sich der am physischen Produkt und dessen Funktionen orientierte
Wettbewerb im globalen Markt des 21. Jahrhunderts in einen Wettbewerb, der sich am Kundenmehrwert orientiert, verlagern3. Die alleinige Fokussierung auf Produktqualität und -preis genügt
den Marktanforderungen nicht mehr. Die Anbieter von Investitionsgütern sind aufgefordert, in
Kundennutzenkategorien4 statt in Taktzeiten5 zu denken. Die veränderten Rahmenbedingungen
verlangen neue technische und organisatorische Lösungen, um auch in Zukunft noch am
Produktionsstandort Deutschland konkurrenzfähig zu sein.
1
2
3
4
5
Vgl. /VDMA-2000b (S. 1)/.
Vgl. /VDMA-2006c (S. 14)/.
Vgl. /Merc-2006 (S. 18)/Lucz-2004 (S. 105)/ADL-2004 (S. 8)/Meie-2004b (S. 7)/Lay-2002 (S. 69)/.
Vgl. /Back-2006 (S. 305)/.
Vgl. /Grau-2006a/Grau-2004c/Dani-2005/Kuhn-2005/Sihn-2003a/.
- 24 -
2.2 Industrielle Dienstleistungen
2.2.1
Begriffsbestimmung und Abgrenzung
Eine einheitliche wissenschaftliche Definition des Begriffs Dienstleistung existiert aufgrund der
Heterogenität und Vielfältigkeit des Dienstleistungssektors nicht1. Als charakteristische Merkmale
von Dienstleistungen werden häufig deren Immaterialität und Nichtlagerfähigkeit, die Simultanität
von Produktion und Konsumption sowie die Integration des externen Faktors – Mensch oder
Objekt – in den Prozess der Leistungserstellung aufgeführt. In der Literatur existieren verschiedene Ansätze zur Typologisierung von Dienstleistungen und der Abgrenzung zu materiellen
Produkten, die jedoch hier nicht weiter vertieft werden2.
In der vorliegenden Arbeit wird daher keine neue Definition des Dienstleistungsbegriffs erarbeitet,
sondern der Begriff der industriellen Dienstleistung in Anlehnung an Meyer3 verwendet. Meyer
definiert industrielle Dienstleistungen, wie folgt: Industrielle Dienstleistungen sind die von einem
Dienstleister angebotenen Leistungsangebote (Leistungsfähigkeiten), die in einem direkten
und/oder indirekten Zusammenhang mit [...] der investiven Sachleistung stehen und mit dem Ziel
erbracht werden, Austauschbeziehungen zu den Marktpartnern aufzubauen, zu erhalten und zu
verbessern. Mit dieser Definition soll aufgezeigt werden, dass Dienstleistungen als eigenständige
Leistungsangebote zu betrachten sind.
2.2.2
Bedeutung industrieller Dienstleistungen aus Herstellersicht
Angesichts der schnellen Verbreitung von technischem Know-how sehen sich Unternehmen im
Maschinen- und Anlagenbau mit der Situation konfrontiert, dass Produkte zunehmend austauschbar werden. Technologisch überlegene Produkte und Komponenten verschaffen nur noch einen
kurzfristigen Vorteil. Damit steigt die Bedeutung nicht-technischer Differenzierungspotenziale.
Eine besondere Rolle kommt hierbei industriellen Dienstleistungen zu, die sich immer mehr zu
einem wettbewerbspolitischen Instrument entwickeln und eine dauerhafte Differenzierung gegenüber Mitbewerbern ermöglichen. Die Dienstleistungen werden dazu eingesetzt, um den Kunden
einen auf die Investitionsgüter abgestimmten Zusatznutzen – Mehrwert – zu bieten4. In zunehmendem Maße versuchen Unternehmen, durch die Bündelung von Dienstleistungen und Investitionsgütern, kombinierte Angebote – sogenannte hybride Dienstleistungen – anzubieten. Anforderungsgerechte, am Kundennutzen orientierte, hybride Dienstleistungspakete können produktbezogene Preisvorteile von Billiganbietern in den Hintergrund drängen5. Darüber hinaus können
hybride Servicedienstleistungen von Produkt- und Markenpiraten schwieriger imitiert werden6.
1
2
3
4
5
6
Hinzu kommt, dass der Begriff Produkt zunehmend auch im Dienstleistungssektor verwendet wird. Dort versteht man
unter einem Produkt meist eine standardisierte Dienstleistung.
Vgl. /DIN-75 (S. 16)/Pill-2001 (S. 15) /Herm-2000 (S. 14)/.
Vgl. /Meye-1990 (S. 198)/.
Sihn und Graupner beschreiben den Paradigmenwechsel als „Wandel vom Maschinenhersteller zum ServiceProvider“. Vgl. /Sihn-2003a (S. 205)/Sihn-2001a/Sihn-2001b/Sihn-2001c/Sihn-2001d/.
Vgl. /Meie-2006a (S. 431)/Meie-2006b (S. 557)/Meie-2005 (S. 528)/Meie-2004b (S. 7)/Lay-2005 (S. 1).
Zwei Drittel aller deutschen Maschinen- und Anlagenbauer sind von der Produkt- und Markenpiraterie betroffen. Vgl.
/VDMA-2006d/.
- 25 -
Dienstleistungen haben in der Investitionsgüterindustrie laut einer VDI-Studie1 seit Jahren einen
hohen Stellenwert. Als besonders wichtig sehen die 302 befragten Unternehmen die in Tabelle 2-1
aufgeführten Bereiche an. Davon zielen die meisten Dienstleistungen auf eine bessere Nutzung
der Anlagen und weniger auf die Beseitigung technischer Störungen ab.
Dienstleistung
angeboten
geplant
Beratung
87 %
10 %
Bedeutung
96 %
Schulung, Training
79 %
13 %
89 %
76 %
Modernisierung
74 %
15 %
Vermarktung von Ersatzteilen
70 %
17 %
76 %
Generalüberholung
69 %
13 %
63 %
Vorsorgliche Wartung
67 %
18 %
72 %
Service-Hotline
63 %
28 %
87 %
Ferndiagnose
47 %
33 %
72 %
Leihmaschinen, Mietservice
31 %
15 %
26 %
Gebrauchtteile- und Maschinenhandel
29 %
12 %
26 %
1
Tabelle 2-1: Umfang und Bedeutung von Dienstleistungen
Die Wichtigkeit industrieller Dienstleistungen in der Investitionsgüterindustrie bestätigen auch
Studien des Fraunhofer ISI2 aus dem Jahr 2000. Studien des Forschungsinstituts für
Rationalisierung (FIR) aus dem Jahr 20033 und aus dem Jahr 20044 kommen zu vergleichbaren
Schlüssen. Seit Jahren dominieren die klassischen Dienstleistungen, wobei der Instandhaltung,
Ersatzteilversorgung, Störfallbeseitigung und Schulung ein besonders hoher Stellenwert zukommt.
Neben den Differenzierungspotenzialen gibt es auch betriebswirtschaftliche Aspekte, die für
Dienstleistungen sprechen. Mit dem Verkauf von Maschinen und Anlagen sind im Durchschnitt nur
geringe Gewinnmargen möglich. Obwohl die Branche den Umsatz in den letzten zehn Jahren um
ca. 40 Prozent steigern konnte, blieb die Umsatzrendite mit 3,4 Prozent sehr niedrig5. Deshalb
sehen viele Hersteller in der Veränderung der Wertschöpfungsstrukturen in Richtung der
industriellen Dienstleistung ihre Zukunft6. Im Durchschnitt erwirtschaften deutsche Maschinen- und
Anlagenbauer ca. 20 Prozent ihres Umsatzes mit Dienstleistungen; bei einigen Unternehmen beträgt der Dienstleistungsanteil sogar bis zu 40 Prozent. Die Umsatzrendite von Dienstleistungen
liegt bei ca. 10 bis 20 Prozent und ist damit der gewinnträchtigste Bereich im Maschinenbau (siehe
Abbildung 2-2). Allerdings realisieren die Maschinen- und Anlagenbauer oft nur 20 bis 30 Prozent
der Geschäftspotenziale; vom Rest profitieren spezialisierte Systemdienstleister7.
1
2
3
4
5
6
7
Vgl. /VDI-1999 (S. 22)/.
Vgl. /Lay-2000/.
Vgl. /Haus-2003/.
Vgl. /Hoec-2004 (S. 56)/.
Vgl. /Merc-2005 (S. 3)/.
Vgl. /ADL-2004 (S. 8)/Lay-2002 (S. 69)/Lucz-2004 (S. 175)/.
Vgl. /Merc-2003 (S. 9)/. Vergleichbare Analysen und Ergebnisse auch bei /ADL-2001 (S. 13)/
- 26 -
EBIT vom Umsatz [%]
Abbildung 2-2: Umsätze und Renditen im deutschen Maschinen- und Anlagenbau1
2.2.3
Bedeutung industrieller Dienstleistungen aus Betreibersicht
Industrielle Dienstleistungen wie Montage, Inbetriebnahme, Instandsetzung, Wartung sowie die
Ersatzteilversorgung gehörten schon immer zum Leistungsumfang der Hersteller. Diese Dienstleistungen sind notwendig, um die Verfügbarkeit und Leistungsfähigkeit der Maschinen und Anlagen sicherzustellen. Sie tragen somit zur Sicherung der Wertschöpfung des Betreibers bei und
werden in vereinbarter Qualität und Schnelligkeit erwartet2.
Die Betreiber stellen an die Hersteller und Lieferanten immer umfassendere Anforderungen. Heute
existiert in der Praxis eine große Vielfalt an nachgefragten Dienstleistungsangeboten. Eine Einordnung der Dienstleistungsnutzung zeigt Abbildung 2-3: beginnend beim integrierten Unternehmen über das Liefer- und Partizipationsmodell bis hin zum Betreibermodell3.
Betreibermodelle führen zu einer grundlegend veränderten Kunden-Lieferanten-Beziehung. Beim
Betreibermodell geht es für den Anlagenbauer nicht darum, eine möglichst komplexe und/oder
teuere Anlage mit vielen – evtl. nicht benötigten – Zusatzfunktionen und -komponenten zu verkaufen. Die Zielsetzung des Anlagenbauers ist, ein möglichst wirtschaftliches System zu entwickeln, zu bauen und zu betreiben. Je höher die Effektivität und Effizienz ist, desto höher ist der
Profit4.
Bei Betreibermodellen besteht über den gesamten Lebenszyklus einer Anlage ein hoher
Kommunikationsbedarf zwischen dem Betreiber vor Ort und dem Hersteller. Um den Betrieb der
Systeme wirtschaftlich anbieten zu können, muss der Betreiber ständig Einblick und Zugriff auf die
1
2
3
4
Vgl. /Merc-2003 (S. 2)/.
Vgl. /Haus-2003 (S. 74)/Bürk-2001 (S. 2)/Gerh-2000a (S. 8)/.
Die Zielsetzung eines Betreibermodells ist, den Teile- oder Komponentenlieferanten in den Wertschöpfungsprozess
des Maschinenanwenders stärker zu integrieren. Das bedeutet, dass die Lieferanten dazu aufgefordert werden, ein
vollständig integriertes Produkt- und Dienstleistungsbündel einer Leistung pro Einheit anzubieten. Dies kann z. B. die
Personalbereitstellung für den Betrieb, die Anlagenfinanzierung und -rücknahme nach Ende der Nutzung einschließen. Der Begriff Betreibermodell wird auch Pay on Production (englisch für Bezahlen pro Einheit) genannt.
Vgl. /Meie-2006a (S. 431)/Meie-2006b (S. 557)/Meie-2005 (S. 530)/Meie-2004b (S. 175)/Spat-2004b (S. 319)/Wild2004 (S. 39)/Wild-2003 (S. 102)/.
- 27 -
Prozesse und Zustände seiner Maschinen haben. Hierfür sind Informations- und Kommunikationstechnologien notwendig. Die Online-Überwachung der Maschinen und ihre präventive Wartung
sind bei Betreibermodellen von besonderer Bedeutung, da dadurch die Anzahl notwendiger
Inspektionen vor Ort verringert werden kann. Die Technik unterstützt den Betreiber unter anderem
darin, einen Servicetechniker zu entsenden, bevor eine Maschine oder Anlage ausfällt.
Abbildung 2-3: Anteil von Dienstleistungen in verschiedenen Kooperationsformen1
2.2.4
Problemfelder vor Ort erbrachter industrieller Dienstleistungen
Industrielle Dienstleistungen werden bisher überwiegend vor Ort erbracht. Die Betreiber fordern,
dass diese Dienstleistungen mit garantierten Reaktionszeiten weltweit angeboten und erbracht
werden müssen. Der Anteil der Unternehmen, die sich zu einer Einhaltung kurzer Reaktionszeiten
verpflichten, lag bereits im Jahr 2000 bei 83 Prozent2.
Die wenigsten Unternehmen können sich allerdings ein weltumspannendes Servicenetz leisten,
das diesen hohen Anforderungen gerecht wird. Die Präsenz vor Ort stellt vor allem für die überwiegend mittelständisch geprägten, deutschen Maschinen- und Anlagenbauer eine finanzielle und
personelle Herausforderung dar. Es gibt wenige Unternehmen, die groß genug sind, um den
Weltmarkt mit einer eigenen Serviceorganisation zu erschließen oder durch Übernahme anderer
Unternehmen zu wachsen. Da die Wachstumsmärkte des deutschen Maschinen- und Anlagenbaus außerhalb des näheren europäischen Umfelds liegen, wird sich diese Situation in Zukunft
noch verschärfen3.
1
2
3
Vgl. /Spat-2004b (S. 319)/.
Vgl. /Gerh-2000a/Gerh-2000b/.
Die Situation entspricht einem Market-pull. Market-pull heißt, dass technologische Lösungen entstehen, die sich
primär an den Bedürfnissen potentieller Abnehmer ausrichten. Vgl. /Fähn-2004a (S. 18)/Bull-2006 (S. 275)/.
- 28 -
2.3 Fernerbrachte industrielle Dienstleistungen
2.3.1
Begriffsbestimmung und Abgrenzung
2.3.1.1 Teleservice
Bis vor wenigen Jahren lag die Anwendung fernerbrachter industrieller Dienstleistungen ausschließlich im Teleservice1. Der Teleservice lässt sich in anzeigende, bewertende und aktive
Funktionen untergliedern. Am verbreitetsten sind die anzeigenden Funktionen, wie z. B. die Betriebsdatenvisualisierung. Bewertende Funktionen erleichtern dem Servicedienstleister die Beurteilung des Maschinenzustands und die Fehlersuche. Aktive Funktionen greifen in die Maschinen
ein2.
Das Hauptziel des konventionellen Teleservice besteht darin, die Kosten zur Behebung von
Störungen zu minimieren, wobei die Einsparungen dadurch erreicht werden, dass das Servicepersonal nicht anreisen muss, sondern sofort virtuell vor Ort gehen kann. Der Hauptvorteil für den
Betreiber liegt in der Reduzierung von Maschinenstillstandszeiten.
Beim konventionellen Teleservice mit dem Schwerpunkt auf Telediagnose und Telewartung findet
die Kommunikation zwischen Hersteller und Betreiber nur in Störfällen statt. Die Betreiber profitieren selten vom Know-how des Herstellers und Informationen aus dem Feld können vom Hersteller nicht zur kontinuierlichen Produktverbesserung genutzt werden. Die Potenziale des konventionellen Teleservice sind daher begrenzt.
In der Vergangenheit konnten fernerbrachte industrielle Dienstleistungen nur über Modem- und
ISDN-Verbindungen erbracht werden. Die geringen Datenübertragungsraten und die u. U. hohen
Telefonkosten bei Serviceeinsätzen ließen fernerbrachte industrielle Dienstleistungen nur in begrenztem Maße zu. Die fortschreitende Entwicklung der Informations- und Kommunikationstechnologie – insbesondere des Internets – bietet heute zunehmend bessere Möglichkeiten, den
Betreiber über den gesamten Produktlebenszyklus ganzheitlich aus der Ferne zu unterstützen3.
2.3.1.2 Internetbasierte Mehrwertdienste
In Anlehnung an Westkämper4, Kuhn5, Kreidler6 und Bandow7 werden internetbasierte Mehrwertdienste wie folgt definiert: Internetbasierte Mehrwertdienste sind automatisch fernerbrachte
produktbegleitende industrielle Dienstleistungen, die der Hersteller den Betreibern unter Nutzung
von Informations- und Kommunikations-Technologien (IuK-Technologien) anbietet. Die Begriffe
internetbasierter Mehrwertdienst, Web-basierter Dienst und fernerbrachter Dienst werden im
Kontext dieser Arbeit synonym verwendet.
1
2
3
4
5
6
7
Der Begriff Teleservice ist nur im deutschsprachigen Raum eingeführt. Im englischen Sprachraum wird zwischen
remote service, remote monitoring, remote diagnostic und remote control unterschieden. Vgl. /VDMA-2006b (S. 7)/.
Teleservice wurde u. a. in den Forschungsvorhaben TesMA /Venn-2000/ und TELec /Maßb-2000/ intensiv erforscht.
Diese Situation entspricht dem Technology-Push (englisch für Technologiedruck). Der Technology-Push lässt
technologische Lösungen aufgrund weitgehend autonomer naturwissenschaftlich-technischer Erkenntnisse entstehen. Vgl. /Fähn-2004a (S. 18)/Bull-2006 (S. 275)/.
Vgl. /West-1997 (S. 20)/ West-2002a (S. 12)/.
Vgl. /Kuhn-2005 (S. 1)/.
Vgl. /Krei-2004 (S. 6)/.
Vgl. /Band-2001 (S. 27)/.
- 29 -
Internetbasierte Mehrwertdienste lassen sich damit dem E-Business1 zuordnen. Durch die Bereitstellung und Nutzung fernerbrachter industrieller Dienstleistungen kann zukünftig eine völlig neue
Art von Produktionssystemen2 entstehen. Ein derartiges Produktionssystem ist dadurch gekennzeichnet, dass dem Betreiber alle zur Durchführung seiner Aufgaben erforderlichen Informationen
und Funktionen unmittelbar zur Verfügung gestellt werden. Der Zusatznutzen resultiert aus einer
veränderten, an den Kernkompetenzen der Beteiligten orientierten, Arbeitsteilung und aus der Anwendung modernster Technologien3. Ein solcher Zusatznutzen wird als Mehrwert bezeichnet. Ein
Mehrwertdienst hat das Generieren eines Mehrwerts zum Ziel (siehe Abbildung 2-4).
Echtzeit-Kommunikation von
Video
Sensor-/ Steuerungsdaten
Belastungsdaten
Produkt- und ProzessKnow -how
M aschinendokumentation
FAQ
Teleservice
Telepräsenz
Teleoperation
Virtuelle M aschine
beim Hersteller
Virtueller Experte
beim Betreiber
M aschine
Experte
Abbildung 2-4: Virtuelle Maschine beim Hersteller und virtueller Experte beim Betreiber 4
Um zu einer umfassenden Steigerung des Nutzens zu gelangen, ist über die Informationsbereitstellung hinaus eine intelligente Aufbereitung der verfügbaren Daten erforderlich. Eine derartige
Informationsaufbereitung kann beispielsweise in der realitätsnahen Simulation des Produktionsprozesses zum Auffinden optimaler Betriebsparameter, in der automatischen Bestimmung
optimaler Wartungs- und Instandhaltungspläne oder in der intelligenten Diagnose von Störzuständen bestehen5. Abbildung 2-5 gibt einen Überblick über heute angebotene fernerbrachte
Dienstleistungen. Weitere Dienstleistungen sind in der VDI-Studie E-Services in der Investitionsgüterindustrie6 aufgeführt.
1
2
3
4
5
6
Der Begriff Electronic Business wurde in den 1990er Jahren durch die Firma IBM erstmalig erwähnt und geprägt. IBM
definiert Electronic Business als: „Neugestaltung strategischer Unternehmensprozesse zur Bewältigung der Herausforderungen eines neuen Marktes, der sich zunehmend durch Globalisierung auszeichnet und auf Wissen basiert".
Modernere Definitionen beschreiben E-Business als einen Oberbegriff für alle elektronischen Geschäftsaktivitäten.
Unter einem Produktionssystem werden hier gleichermaßen Fertigungs-, Montage- und Logistiksysteme verstanden.
Vgl. /Grau-2001b/.
Vgl. /West-1997 (S. 20)/.
Vgl. /West-2002b (S. 12)/West-2001b (S. 18)/.
Die VDI Nachrichten und die European Management Consultancy (EBC) befragten in einer Studie 141 Unternehmen
der Investitionsgüterindustrie - 93 Anbieter von E-Services und 48 Anwender. Die Unternehmen bewerteten internetbasierte Services im Jahr 2001 skeptisch. Zwar wurden die Potenziale erkannt, doch nur wenige wagen große Investitionen. Andererseits hatte für 29 % der Unternehmen E-Services eine sehr hohe beziehungsweise hohe Bedeutung im Hinblick auf die Erzielung positiver Deckungsbeiträge. Vgl. /VDI-2001 (S. 9)/.
- 30 -
Abbildung 2-5: Beispiele fernerbrachte Dienstleistungen
2.3.1.3 IT-basierte Dienstleistungen
Fähnrich1 definiert IT-basierte Dienstleistungen, wie folgt: IT-basierte Dienstleistungen sind Dienstleistungen, deren Nutzen für den Kunden zu einem maßgeblichen Teil durch den Einsatz von
Informations- und Kommunikations-Technologien (IuK-Technologien) entsteht. Sie treten auf in
Form von Dienstleistungen, deren effiziente Gesamterbringung nur durch den Einsatz von IuKTechnologien gewährleistet werden kann, als begleitende Dienstleistungen zu Produkten der IuKTechnologie sowie als Bestandteil von Leistungsbündeln zusammen mit IuK-Produkten.
Der Unterschied zwischen IT-basierten Dienstleistungen und internetbasierten Mehrwertdiensten
liegt demnach vor allem im Bezug zum Basisprodukt. Während IT-basierte Dienstleistungen in
allen Branchen Anwendung finden, liegt der Fokus internetbasierter Mehrwertdienste auf der
Unterstützung des Lebenszyklus einer Maschine oder Anlage.
2.3.1.4 E-Service
Der Begriff E-Service wird in der Literatur sehr häufig verwendet, hat jedoch je nach Herkunft der
Autoren eine jeweils unterschiedliche Bedeutung. Während Service im englischen Sprachraum für
sehr viele unterschiedliche Arten von Dienstleistungen steht, versteht man im deutschen Sprachraum darunter i. d. R. die Wartungs- und Instandhaltungsorganisationseinheit. Autoren aus diesem
Umfeld verstehen unter dem Begriff E-Services die elektronische Erbringung des After-SalesService. Autoren aus dem IT-Umfeld verstehen unter E-Services IT-Dienste, wie z. B. das Hosting
eines Web- oder E-Mail-Servers.
1
Vgl. /Fähn-2004b (S. 3)/.
- 31 -
2.3.1.5 Web-Services
Der Begriff Web-Services bezeichnet Softwareanwendungen, die auf der Dokumentenbeschreibungssprache XML1 basieren und über das Internet oder Intranet mit anderen Softwareanwendungen kommunizieren. Die Schnittstellen zwischen den Softwareanwendungen werden
durch das Format WSDL2 beschrieben und die Nachrichten mittels SOAP3 ausgetauscht. Die Verzeichnisstruktur UDDI4 macht die Suche sowie die Publikation von Web-Services möglich.
Da Web-Services definitionsgemäß nur unter Verwendung oben genannter Protokolle als solche
bezeichnet werden dürfen, wird der Begriff im Rahmen dieser Arbeit nicht synonym für internetbasierte Mehrwertdienste verwendet. Viele Mehrwertdienste würden nach dieser Definition nicht
unter den Begriff der Web-Services fallen. Eine ausführlichere Behandlung von Web-Services
erfolgt im Kapitel 6.5.4 und soll hier nicht vertieft, sondern nur abgegrenzt werden.
2.3.2
Klassifizierung fernerbrachter industrieller Dienstleistungen
2.3.2.1 Einordnung in den Lebenszyklus
Fernerbrachte industrielle Dienstleistungen finden im gesamten Lebenszyklus eines Produktionssystems Anwendung: beginnend bei vertrieblichen Aktivitäten über die Projektierung, die Beschaffung, Inbetriebnahme und letztendlich im After-Sales5. Mehrwertdienste unterstützen
Maschinen und/oder Menschen in der Bewältigung von Aufgaben. Deshalb ist es sinnvoll, Mehrwertdienste entsprechend ihrer Aufgabenerfüllung zu klassifizieren (siehe Abbildung 2-6).
Abbildung 2-6: Einordnung von Mehrwertdiensten im Lebenszyklus von Maschinen und Anlagen
1
2
3
4
5
XML (englisch für Extensible Markup Language) ist eine Metasprache für das Definieren von Dokumenttypen.
WSDL (englisch für Web Service Description Language) dient der Spezifikation von Netzwerkdiensten.
SOAP ist ein Protokoll, mit dessen Hilfe Daten auf XML-Basis ausgetauscht werden können.
UDDI (englisch für Uniform Description, Discovery and Integration) ist ein Verzeichnisdienst für Web-Services.
Vgl. /Herm-2000 (S. 27)/.
- 32 -
2.3.2.2 Einordnung nach Interaktionsstufen der Dienste
Internetbasierte Mehrwertdienste können auch nach dem Kommunikationsgrad in folgende Interaktionsstufen eingeordnet werden: Information, Kommunikation und Transaktion1. Das Interaktionsniveau vieler Internet-Dienstleistungen ist in den letzten Jahren erheblich gestiegen. Sie
haben sich von reinen Informationsseiten zu komplexen Anwendungen gewandelt, wobei sich die
folgenden drei Entwicklungsstufen identifizieren lassen:

Bei Informationsdiensten nimmt der Anwender lediglich die Rolle eines Informationsempfängers ein. Dieser Bereich ist am weitesten entwickelt. Nahezu alle Unternehmen
präsentieren sich heute mit ihren Produkten und Dienstleistungen im Internet und statten ihre
Produktionssysteme zumindest mit anzeigenden Teleservice-Systemen aus.

Diese Informationssysteme lassen sich unter Nutzung von Dialog- und Interaktionsmöglichkeiten zu Kommunikationsdiensten ausbauen2. Durch die Menüauswahl, Dateneingabe in
Formulare etc. ist der Kunde maßgeblich an der Ausführung des Dienstes beteiligt. Zu dieser
Kategorie zählen auch Dienste, die eine gezielte Suche in Datenbeständen ermöglichen, um
z. B. aktuelle Lagerstände von Ersatzteilen beim Lieferanten online zu prüfen.

Transaktionsdienste haben das höchste Interaktionsniveau. Die bekanntesten Vertreter hiervon sind Shopsysteme. Während zu Beginn die Transaktionssysteme lediglich die Automatisierung diskreter Funktionen in einem Unternehmen im Fokus hatten, steht heute die
unternehmensübergreifende Integration im Vordergrund.
2.4 Gestaltung internetbasierter Mehrwertdienste
Mit der steigenden Bedeutung von Dienstleistungen rückt die Frage der effizienten Gestaltung von
Entwicklungsprozessen in den Vordergrund. Unternehmen, die regelmäßig neue Dienstleistungen
entwickeln, suchen nach Möglichkeiten, Doppelarbeit zu vermeiden, die Wiederholung bereits gemachter Fehler auszuschließen und vorhandenes Wissen und Software wieder zu verwenden. Um
dies zu erreichen, wird oft damit begonnen, Entwicklungsprozesse zu beschreiben und zu
standardisieren.
2.4.1
Vorgehensmodelle
Die Basis für die Formalisierung von Entwicklungsprozessen bilden sogenannte Vorgehensmodelle. Vorgehensmodelle legen die Aktivitäten fest, die für die Entwicklung notwendig sind, bestimmen deren wechselseitige Beziehung und geben Reihenfolgen der Bearbeitung an. Vorgehensmodelle unterstützen damit die Planung, Steuerung und Überwachung von Projekten3.
Aus der Definition allgemeiner Dienstleistungen sind drei Dimensionen ableitbar, nämlich die
Leistungsbereitstellung, die Leistungserstellung und das Leistungsergebnis. Für alle drei
Dimensionen müssen Konzepte und Modelle4 erarbeitet werden. Als Ergebnis der Dienstleistungsgestaltung müssen demnach Produktmodelle, Prozessmodelle sowie Ressourcenkonzepte entstehen. Parallel dazu ist es sinnvoll, ein Marketingkonzept zu entwickeln (Abbildung 2-7).
1
2
3
4
Vgl. /KBSt-2006 (S. 42)/.
z. B. Diskussionsforen, Videokonferenzsysteme, Telediagnosesysteme etc.
Vgl. /DIN-75 (S. 33)/Meir-2001 (S. 29)/.
Um die Komplexität der Realität zu reduzieren, erfolgt dabei die Betrachtung aus verschiedenen singulären Blickrichtungen heraus. Hierzu bedient man sich an Modellen. Ein Modell ist eine formale Beschreibung eines Ausschnitts
der realen Welt. Vgl. /VDI-3633/.
- 33 -
Abbildung 2-7: Gestaltung fernerbrachter Dienstleistungen1
2.4.2
Produktmodelle
Produktmodelle beschreiben die zu entwickelnde Dienstleistung. Hierbei werden alle Leistungsinhalte und die zugrunde liegenden Strukturen festgelegt. Bei umfangreichen Dienstleistungen
sollte ein modularer Aufbau der Teildienstleistungen angestrebt werden, um so die Produktstruktur
möglichst einfach und übersichtlich zu halten. So können auch spezifische Kundenwünsche durch
die Kombination von unterschiedlichen Modulen mit anschließendem Customizing erfüllt werden.
2.4.3
Prozessmodelle
Prozessmodelle beschreiben, wie eine Dienstleistung erbracht wird. Es ist darauf zu achten, dass
alle Prozessschritte festgelegt und die dazugehörigen Schnittstellen definiert werden. Dabei ist
wichtig, dass die Prozesse transparent und übersichtlich dargestellt werden, sodass sie für alle Beteiligten verständlich sind. Von Anfang an sollte eine möglichst optimale Ausgestaltung der
Prozesse im Vordergrund stehen. Nicht-wertschöpfende Prozessschritte und unnötige Medienbrüche sind zu eliminieren. Die parallele und damit zeitsparende Bearbeitung von Teilprozessen ist
anzustreben.
2.4.4
Ressourcenkonzepte
Ressourcenkonzepte beschreiben die Gesamtheit aller für den Erbringungsprozess benötigten
Ressourcen. Ressourcenkonzepte dienen damit der Planung des Ressourceneinsatzes, der für die
Erbringung der Dienstleistung erforderlich ist. Darunter fällt sowohl die Planung des Personalbedarfs als auch die des Betriebsmitteleinsatzes sowie die erforderliche Informations- und
Kommunikationstechnik. Naturgemäß spielt bei internetbasierten Diensten vor allem die Planung
der IT-Ressourcen eine wichtige Rolle. Wenngleich der Schluss, dass diese Dienste vollständig
autonom ablaufen, falsch ist. Für die Wartung, Überwachung der Systeme etc. wird ebenfalls
Personal benötigt, das bei der Gestaltung des Ressourcenkonzepts beachtet werden muss.
1
Vgl. /Meir-2002 (S. 35)/.
2.4.5
- 34 -
Marketingkonzepte
Die Aufgabe des Marketingkonzepts ist, dem Kunden zu vermitteln, welcher Wert aus der Inanspruchnahme der Dienstleistung resultiert. Die grundsätzlichen Marketingregeln1 gelten dabei auch
für fernerbrachte Dienstleistungen. Das Marketingkonzept enthält die Festlegung einer Marketingstrategie und die Ausgestaltung des Marketing-Mix. In der Marketingstrategie sollten die Zielgruppen definiert und die neue Dienstleistung strategisch innerhalb des Gesamtportfolios
positioniert werden. Im Marketing-Mix sind alle Maßnahmen und Instrumente zur Unterstützung
des Absatzes festzulegen und untereinander abzustimmen.
Marketingkonzepte bilden nicht den Gegenstand der Arbeit und werden deshalb nicht weiter vertieft. Die Akzeptanz von Diensten beim Dienstleistungsempfänger wird ebenfalls nicht erörtert. Zu
solchen Fragestellungen existiert bereits Literatur2.
2.5 Defizite heutiger internetbasierter Mehrwertdienste
2.5.1
Verbreitungsgrad internetbasierter Mehrwertdienste
Obwohl die Bedeutung internetbasierter Mehrwertdienste als Umsatzträger, Differenzierungsmerkmal etc. seit Jahren intensiv erforscht, kommuniziert und diskutiert wird, sind in den Unternehmen nur geringe Fortschritte erzielt worden. Den Maschinen- und Anlagenbauern ist zwar bekannt, dass die IT-basierten Dienstleistungen zur „Produktionstechnik des 21. Jahrhunderts“
werden, aber sie greifen nur zögerlich auf die Internettechnologie zurück, um ihre Kunden,
Lieferanten oder Servicemitarbeiter mit Informationen zu versorgen.
Vergleicht man die Studien des VDI aus dem Jahr 20013, des Fraunhofer IAO aus dem Jahr 20034
und aus dem Jahr 20055, des FIR aus dem Jahr 20036 und 20047, des Fraunhofer IPK aus dem
Jahr 20048 und 20059, der Universität Leipzig aus dem Jahr 200410, der VDI-Konferenzreihe EServices im Maschinen- und Anlagenbau aus den Jahren 2001 bis 200611 kommt man zu einem
einheitlichen Schluss: In der industriellen Praxis sind kaum Fortschritte erzielt worden. Es
dominieren vergleichsweise triviale Dienste zur Identifikation und zur Online-Bestellung von Ersatzteilen. So titelten die VDI-Nachrichten im Jahr 2003 treffend: großer Nutzen, kleine Verbreitung.
1
2
3
4
5
6
7
8
9
10
11
Die American Marketing Association (AMA) definiert Marketing, wie folgt: „Der Planungsprozess der Konzeption,
Preispolitik, Promotion und Distribution von Produkten und Dienstleistungen, um Austauschprozesse zu erreichen,
die individuelle und organisationale Ziele erfüllen.“ Zur Vermarktung von Industriegütern vgl. /Back-2006/.
Vgl. /Homb-2006/Meye-2004/Back-2006/Back-2003/VDMA-2000a/VDI-1999/.
Vgl. /VDI-2001/.
Vgl. /Guds-2003/.
Vgl. /Huse-2005/.
Vgl. /Haus-2003/.
Vgl. /Hoec-2004/.
Vgl. /Mert-2004.
Vgl. /Berg-2005/.
Vgl. /Fähn-2004a/.
Vgl. /West-2001a/West-2002d/West-2003/West-2004/West-2005/West-2006/.
- 35 -
Studien von Hauser et al.1 zeigen eine Diskrepanz zwischen der Nachfrage aus Betreibersicht und
dem Angebot aus Herstellersicht auf. Im Rahmen einer Marktstudie kommt Gudszend2 zu einem
ähnlichen Schluss: Hersteller und Betreiber könnten es sich sehr gut vorstellen, zu kooperieren,
allerdings stehen dem Medienbrüche in der Kommunikation und im Informationsmanagement
sowie ein Mangel an internetfähiger Spezialsoftware entgegen. Berger3 führt dies vor allem auf
den Mangel an sicheren IT-Infrastrukturen zurück. Fähnrich4 sieht eine Ursache darin, dass aufgrund der Unkenntnis technologischer Möglichkeiten einerseits nicht realisierbare Wünsche geäußert und andererseits jedoch auch die Potenziale nicht erkannt werden.
Es klafft demnach eine große Lücke zwischen den technischen Möglichkeiten, wie sie z. B. in Abbildung 2-5 dargestellt sind, und der Umsetzung in den Unternehmen.
2.5.2
Fehlende Vorgehensmodelle zur Entwicklung fernerbrachter Dienstleistungen
Internetbasierte Mehrwertdienste wurden bisher vorwiegend innerhalb von Einzelprojekten
konzipiert und realisiert. Kundenspezifische Lösungen führen zu einer hohen Variantenvielfalt, die
nur durch einen modularen Aufbau aus Standardkomponenten in den Griff zu bekommen ist. Die
aus der Automobilindustrie, dem Maschinen- und Anlagenbau sowie in der Chemie und Verfahrenstechnik längst üblichen Produktfamilien oder Plattformkonzepte lassen sich bei der Dienstleistungsgestaltung bestenfalls in Ansätzen finden5.
Die Folge: hoher Aufwand in der Entwicklung und Wartung von Diensten, zu lange Umsetzungszeiträume zwischen Ideenfindung und Inbetriebnahme sowie qualitativ und technisch nicht ausgereifte Gesamtsysteme. Untersuchungen von Mertins et al.6 zufolge sind Flopraten von 50 - 80
Prozent bei der Markteinführung neuer IT-Dienstleistungen zu beobachten7.
2.5.3
Mangelnde Integrationsfähigkeit
Viele fernerbrachten Dienstleistungen benötigen Schnittstellen zu vorhandenen IT-Systemen. Das
gilt sowohl für die Empfänger- als auch für die Erbringerseite. Die meisten Unternehmen verfügen
allerdings über gewachsene IT-Landschaften, die häufig auf unterschiedlichen Technologien8 und
Kommunikationsmodellen9 basieren. Eine Vielzahl von Applikationen mit einer Vielzahl von
Schnittstellen wirkt sich negativ auf die Integrationsfähigkeit von Softwaresystemen aus.
Die Folge hiervon sind komplexe Systeme, die hohe Entwicklungs- und Integrationskosten sowie
lange Entwicklungszeiten zur Folge haben. Unternehmen müssen daher einen Weg finden, der
von der unkontrollierten Vernetzung von Applikationen zu dezidierten Integrationsplattformen führt.
1
2
3
4
5
6
7
8
9
Vgl. /Haus-2003 (S. 77)/.
Vgl. /Guds-2003 (S. 64)/.
Vgl. /Berg-2005 (S. 34)/.
Vgl. /Fähn-2004a (S. 18)/.
Vgl. /Spec-2005 (S. 21)/.
Vgl. /Mert-2004 (S. 9)/.
Zu vergleichbaren Ergebnissen kommen auch die sogenannten Chaos-Studien von Standish. Lediglich 25 Prozent
der analysierten IT-Projekte sind nach Angaben der Verantwortlichen erfolgreich. Vgl. /Stan-2006/Stan-1994/.
Z. B. Dateibasiert, RPC, Messaging, Datenbank.
Z. B. Synchron, asynchron, unidirektional und bidirektional.
2.5.4
- 36 -
Fehlende Interoperabilität
Fernerbrachte Mehrwertdienste erfordern interoperable1 Informations- und Kommunikationssysteme. In der industriellen Praxis sind allerdings solche Systeme zur Erbringung von Mehrwertdiensten nicht vorhanden. Die angebotenen Lösungen beschränken sich meist auf eine
Summierung unterschiedlicher Einzelprodukte ohne datentechnische und funktionale Integration.
Neben Servicemanagementsoftware finden sich proprietäre Systeme der Steuerungshersteller,
Videokonferenz-Systeme, unterschiedliche Application-Sharing-Anwendungen etc. Oftmals ist
sogar das Dienstleistungsangebot eines Herstellers nicht über einen einheitlichen Zugang erreichbar. Dies hemmt Synergieeffekte, verursacht für den Anwender Probleme in Bezug auf unterschiedliche Benutzerführungen und uneinheitlichem Datenmanagement.
Durch die Nutzung einheitlicher Standards und Spezifikationen kann eine höhere Interoperabilität
zwischen den Mehrwertdiensten erreicht werden.
2.5.5
Fehlendes Vertrauen in die Sicherheit elektronischer Dienste
Die Akzeptanz elektronischer Dienste hängt entscheidend davon ab, dass die Sicherheit informationstechnischer Systeme einschließlich der darin gespeicherten oder verarbeiteten Daten gewährleistet ist2. Informationstechnische Systeme müssen genügend Sicherheit gegen Computerversagen und -missbrauch sowie gegen gezielte Ausspähung und Computerkriminalität bieten. Die
Berücksichtigung der IT-Sicherheit muss deshalb zu einem eigenständigen Thema im Bereich der
Gestaltung fernerbrachter Dienste werden.
1
2
Vgl. Als Interoperabilität bezeichnet man die Fähigkeit zur Zusammenarbeit von verschiedenen Systemen. Wenn
Systeme miteinander vereinbar sind, nennt man sie auch kompatibel.
Vgl. /BSI-2005b (S. 68)/Berg-2005 (S. 35)/.
3 Anforderungen an die Gestaltung internetbasierter Mehrwertdienste
Damit das Mögliche entsteht,
muss immer wieder das Unmögliche versucht werden.
Hermann Hesse
Dichter, Schriftsteller und Maler
Das Kapitel 3 dient der Analyse der Anforderungen an die Gestaltung internetbasierter Mehrwertdienste. Die Anforderungen sollen aus Sicht des Projektmanagements, aus Sicht der Dienstleistungskonzeption sowie aus Sicht der Informationstechnologie dargestellt werden.
Die Mehrzahl der im Folgenden genannten Anforderungen basieren auf den Erfahrungen des Verbundforschungsprojekts E-Industrial Services. Die Erkenntnisse, die im Zuge der Konzeption und
Realisierung von zwölf internetbasierten Mehrwertdiensten gewonnen wurden, bilden die Grundlage für die Formulierung von Anforderungen1.
Nicht alle Anforderungen sind für alle Typen von Diensten gleichermaßen relevant. Einerseits
existieren Pilotprojekte, die das Ziel haben, neue Funktionalitäten oder innovative Technologien zu
evaluieren. Solche Pilotprojekte haben häufig den Charakter von Machbarkeitsstudien, in denen es
darum geht, die prinzipielle Umsetzbarkeit eines Ansatzes nachzuweisen. Am anderen Ende des
Spektrums sind unternehmensübergreifende Integrationsprojekte zu nennen, in denen unter
anderem hohe Anforderungen an die Skalierbarkeit, Interoperabilität und Sicherheit gestellt
werden. Bei solchen Projekten müssen in der Regel mehr Anforderungen berücksichtigt werden.
Die Auswahl und Gewichtung von Anforderungen ist deshalb immer im Rahmen konkreter Entwicklungsprojekte zu erarbeiten und zu bewerten2.
3.1 Anforderungen aus Sicht des Projektmanagements
Das Projektmanagement umfasst alle Aufgaben, welche die Aktivitäten des Projektteams planen,
kontrollieren und steuern, damit das Projektziel sicher erreicht werden kann beziehungsweise
Probleme frühzeitig erkannt und beseitigt werden können. Die Zielsetzung des Projektmanagements liegt demnach in der effizienten und effektiven Projektplanung und -durchführung.
Geeignete Vorgehensmodelle können das Projektmanagement unterstützen. Durch die Vorgabe
konkreter Methoden, standardisierter Vorgehensweisen, erwarteter Ergebnisse und verantwortlicher Rollen erhöhen Vorgehensmodelle die Projekttransparenz, erleichtern das Management von
Projekten und erhöhen die Erfolgswahrscheinlichkeit.
1
2
Vgl. /eIS-2007/.
Vgl. /Quan-2003 (S. 21)/.
Anforderungen an die Gestaltung internetbasierter Mehrwertdienste
- 38 -
3.2 Anforderungen aus Sicht der Dienstleistungsgestaltung
3.2.1
Anforderungen an Vorgehensmodelle zur Entwicklung von Mehrwertdiensten
In Wissenschaft und Praxis hat sich die Erkenntnis durchgesetzt, dass der Erfolg eines Dienstleistungsangebots entscheidend von dessen systematischer Entwicklung abhängt1. Bei der Suche
nach geeigneten Methoden, Vorgehensweisen und Werkzeugen zur Konzeption und Entwicklung
internetbasierter Mehrwertdienste muss man allerdings feststellen, dass solche fehlen beziehungsweise gerade in Entwicklung sind.
Zur Gestaltung konventionell erbrachter Dienstleistungen existieren bewährte Vorgehensmodelle
aus dem Service Engineering2. Die Entwicklung internetbasierter Mehrwertdienste stellt jedoch
weitere Anforderungen, die dem Software Engineering3 zuzuordnen sind. Traditionelle, d. h.
sequenzielle, iterative oder evolutionäre Vorgehensmodelle des Software Engineerings beschreiben produktbezogene Aktivitäten, wie Analyse, Entwurf, Implementierung, Test und
Wartung, deren Ergebnisse unmittelbar in das Softwareprodukt eingehen. Demgegenüber werden
prozessbezogene Aktivitäten, wie z. B. die Koordination eines Projektes oder die Kooperation
zwischen den beteiligten Akteuren, in den traditionellen Vorgehensmodellen des Software
Engineerings oft nicht in hinreichendem Maße berücksichtigt4.
Daraus leitet sich die Notwendigkeit ab, eine integrierte Vorgehensweise für die Entwicklung internetbasierter Mehrwertdienste zu erarbeiten, bei der die Anforderungen des Projektmanagements,
des Service Engineerings und des Software Engineerings integriert betrachtet werden5.
3.2.2
Anforderungen an die Produktmodelle
Neben unternehmensstrategischen Aspekten, dem Markt- und Wettbewerbsumfeld, vorhanden
Kundenbedürfnissen, der Zahlungsbereitschaft und dem eigenen Umsetzungspotenzial müssen
internetbasierte Mehrwertdienste vor allem einen klaren Kundennutzen haben, der sich wirtschaftlich sowohl für den Dienstanbieter als auch für den Dienstempfänger lohnt.
Daneben existieren auch technische Anforderungen. Eine simple, aber wichtige Voraussetzung für
die Fernerbringung internetbasierter Mehrwertdienste ist deren Digitalisierbarkeit.
Die Kommunikationsfähigkeit der Maschinen und Anlagen ist eine weitere Voraussetzung zur
Nutzung maschinennaher Dienste. So kann eine industrielle Dienstleistung nur an Objekten erbracht werden, die über eine entsprechende technische Ausrüstung verfügen. Zur optimalen Ausrüstung gehören unter anderem Komponenten der Kommunikationstechnik, Sensoren zur Erfassung von Zuständen, Aktoren, die angesteuert werden können sowie Komponenten zur Datenverarbeitung, -speicherung und -visualisierung.
1
2
3
4
5
Studien von van Husen et al. zu Folge lässt sich sogar ein direkter Zusammenhang zwischen dem Formalisierungsgrad von Dienstleistungen und dem wirtschaftlichen Erfolg eines Unternehmens ableiten. Vgl. /Huse-2005 (S. 48)/.
Eine tiefergehende Betrachtung der Konzepte erfolgt im Kapitel 4.4.
Eine tiefergehende Betrachtung der Konzepte erfolgt im Kapitel 4.5.
Vgl. /Fähn-2004a (S. 15)/.
Einer Studie von van Husen et al. zu Folge gehen 80 Prozent der befragten Personen davon aus, dass die Bedeutung der systematischen Gestaltung von IT-Dienstleistungen zunehmen wird. 65 Prozent der Befragten sehen
einen Bedarf an geeigneten Vorgehensmodellen; 62 Prozent sehen einen Bedarf an geeigneten Methoden.
Geringere Bedeutung haben Organisationskonzepte, Fallstudien sowie die Aus- und Weiterbildung. Vgl. /Huse-2005
(S. 70)/. Vergleichbare Aussagen auch unter /Sche-2004 (S. 13)/.
- 39 -
Die Basis hierfür bildet die fortschreitende Ausstattung der Ausrüstung von Maschinen mit
intelligenten, kommunikativen Rechensystemen in Form von IPCs1 oder Embedded Systems. In
der Industrielandschaft findet man heute eine große Bandbreite unterschiedlicher IT-Systeme in
der Automation vor. Diese reichen von der einzelnen evtl. webfähigen SPS2 über Bussysteme bis
hin zur systemweiten Middleware3. Durch den zunehmend größer werdenden Anteil von Software
in Maschinen und Anlagen entstehen zunehmend neue Dienstleistungspotenziale.
3.2.3
Anforderungen an die Prozessmodelle
Die Erbringung internetbasierter Mehrwertdienste darf nicht zu einer proportionalen oder gar überproportionalen Zunahme des Aufwands führen. Eine Anforderung ist daher die Standardisierung
der leistungserbringenden Prozessmodelle. Die Prozessmodelle sollten über einen modularen
Aufbau verfügen und kundenspezifisch konfigurierbar sein, um den individuellen Anforderungen
der Kunden nachzukommen.
Heutige internetbasierte Mehrwertdienste bieten vor allem spezifische Leistungen an und passen
sich selten der jeweiligen Situation an. Die heutigen Dienste sind statisch und für jeden Anwender
gleich. Zukünftige Mehrwertdienste werden sich aufgrund des bekannten Kontextes dem jeweiligen
Anwender flexibel anpassen. Basierend darauf, wer, womit, wann und wie auf die Dienste zugreift,
erscheinen diese in einer veränderten Form. Diese Profilierung hat zum Ziel, dem Nutzer aus der
Vielfalt verfügbarer Informationen genau diejenigen anzubieten, die mit seinen aktuellen Interessen
möglichst gut übereinstimmen4. Um eine Kontext-Sensitivität zu erreichen, ist es notwendig, dass
der Kontext zwischen verschiedenen Services gemeinsam verwendet werden kann5. Der gewünschten Interoperabilität kann durch die Verwendung von standardisierten Prozessmodulen
Rechnung getragen werden6.
Zur Unterstützung der Kontext-Sensitivität sowie zur Vereinheitlichung der Benutzerführungen und
Datenhaltung sollten die Dienste unter Nutzung von Portalen7 in einer homogenen Benutzeroberfläche gebündelt werden.
1
2
3
4
5
6
7
IPC für Industrie-PC.
SPS für Speicherprogrammierbare Steuerung, englisch PLC für Programmable Logic Controller.
Eine Middleware ist eine Verbindungssoftware, die Dienste beinhaltet, um eine Interaktion auf einem oder mehreren
Rechnern über ein Netzwerk zu erlauben. Im Gegensatz zu untergeordneten Netzwerkdiensten, welche die einfache
Kommunikation zwischen Rechnern handhaben, unterstützt Middleware die Kommunikation zwischen Prozessen.
Ein gutes Beispiel hierfür sind Fluggesellschaften, die ihre Tickets über das Internet vertreiben. Neben dem Flug wird
dem Interessenten ein passender Mietwagen sowie ein Hotel samt Versicherung angeboten. Der Kontext – in diesem
Fall der Termin, Ort, Anzahl und Alter der Personen etc. – wird von einem Dienst zum anderen ausgetauscht.
Vgl. /Lay-2005 (S. 108)/VDMA-2005 (S. 19)/.
Graupner und Hohwieler beschreiben in /Grau-2002c/ einen Mehrwertdienst, der eine belastungsorientierte Zustandsüberwachung, ein Maschinen-Servicecheckheft, eine multimediale Bedienungsanleitung, Ersatzteilbestellung
und Maschinenhistorie für den Maschinenanwender unter einer Benutzeroberfläche integrieren. Vergleichbare
maschinennahe internetbasierte Dienste beschreibt Uhlmann et al. in /Uhlm-2006 (S. 455)/Uhlm-2004 (S. 314)/Uhlm2003 (S. 385)/.
Unter dem Begriff Portal werden internetbasierte Anwendungen zusammengefasst, die verschiedene Informationsquellen und Anwendungen in einer Benutzeroberfläche integrieren und rollenorientiert sowie personalisiert zur Verfügung stellen. Durch die Integration von Daten und Diensten lässt sich der Integrationscharakter auch auf die Ebene
der Geschäftsprozesse erweitern. Portale bündeln demnach die zur Abwicklung von Geschäftsprozessen erforderlichen Dienste unter einer Benutzeroberfläche. Vgl. /Gurz-2006 (S. 24)/Baue-2001 (S. 19)/.
3.2.4
- 40 -
Anforderungen an die organisatorischen Ressourcenkonzepte
Neben den Anforderungen der Informationstechnik, die Gegenstand des Kapitels 3.3 sind, wird ein
kritischer Erfolgsfaktor zur Gestaltung internetbasierter Dienste durch personelle und
organisatorische Aspekte markiert. Häufig stellt die Verfügbarkeit von geeignetem Personal für die
Entwicklung ein Problem dar, da die Gestaltung von IT-Dienstleistungen erst seit wenigen Jahren
gelehrt wird und entsprechende Literatur ebenfalls erst seit wenigen Jahren verfügbar ist.
Die Folge ist, dass Entwicklungsprojekte häufig in IT-Abteilungen positioniert werden. Dort werden
die Verantwortlichen mit der Umsetzung des Dienstleistungsgedankens vor neue Aufgaben gestellt: Wurde dort bisher nur in IT-Projekten gedacht und gehandelt, gilt es einen Zusammenhang
zwischen einem IT-Projekt und einer für externe Kunden erbrachten Dienstleistung herzustellen1.
Einen Ausweg bietet die kooperative Entwicklung, d. h. die Aufspaltung des Wertschöpfungsprozesses und die Verlagerung von Teilaufgaben an Dritte. Dies bietet mehrere Vorteile: Zum
einen beschleunigt dies durch die mögliche Parallelisierung den Entwicklungsprozess, zum
anderen lassen sich dadurch Spezialisten einsetzen, die aufgrund von Wiederholeffekten Entwicklungen schneller und kostengünstiger umsetzen können. Dies setzt allerdings voraus, dass
sich die Gesamtaufgabe in Unteraufgaben zerlegen lässt.
3.3 Anforderungen aus Sicht der Informationstechnik
Die Aufgabe von IT-Systemen ist, Funktionen im Diensterbringungsprozess zu unterstützen, weshalb die Informationstechnik2 auch den Prozessmodellen zugeordnet werden kann. Andererseits
ist durch die Informationstechnologie3 die Erbringung von Dienstleistungen überhaupt erst möglich.
Dies spricht dafür, die Informationstechnik den Ressourcenkonzepten zuzuordnen. Nicht zuletzt ist
die Information selbst das eigentliche Produkt, das dem Kunden offeriert wird, was dafür spricht,
die Informationstechnik als Produkt zu betrachten.
Aus diesen Gründen und aufgrund ihrer großen Bedeutung für die Arbeit werden die Anforderungen an die Informationstechnologie separat betrachtet. Allerdings ist anzumerken, dass
die Dienstleistungskonzeption und die Informationstechnologie nicht unabhängig voneinander behandelt werden können, da sich diese inhaltlich überlagern und gegenseitig beeinflussen.
3.3.1
Allgemeine Anforderungen an Softwaresysteme
Die in Tabelle 3-1 genannten allgemeinen Anforderungen an zu entwickelnde IT-Systeme haben
eine hohe Bedeutung, jedoch keinen spezifischen Bezug zu internetbasierten Mehrwertdiensten,
weshalb auf entsprechende Fachliteratur verwiesen wird4. Auf die spezifischen Anforderungen wird
in den folgenden Abschnitten eingegangen.
1
2
3
4
Vgl. /KBSt-2006 (S. 37)/Mert-2004 (S. 67)/.
Der Begriff Technik bezeichnet die Anwendung einer Methode oder eines Prinzips, mit der eine bestimmte ergebnisorientierte Wirkung erzielt wird.
Mit dem Begriff Technologie werden alle Verfahren zur Produktion und Distribution von Waren und Dienstleistungen
zusammengefasst. Eine Technologie macht demnach Aussagen über die Anwendung der verfügbaren Techniken.
Vgl. /KBSt-2006/Weis-2002/Balz-2001/.
Anforderung
- 41 -
Erläuterung
Fehlertoleranz
Das System muss auch mit unvorhergesehenen beziehungsweise unzulässigen Systemzuständen umgehen können. Fehler oder unvorhergesehene Ereignisse dürfen nicht zum Absturz führen.
Performanz
Die Performanz einer Anwendung wird darüber definiert, wie schnell ihre
Funktionalität zur Verfügung gestellt werden kann.
Skalierbarkeit
Skalierbarkeit beschreibt die Fähigkeit, die gewünschte Effizienz und Performanz beim Betrieb zu gewährleisten.
Verfügbarkeit
Verfügbarkeit1 ist ein Maß dafür, wie ausfallsicher eine Anwendung Dienste
oder Ressourcen zur Verfügung stellen kann.
Wartbarkeit
Wartbare Anwendungen zeichnen sich dadurch aus, dass Betrieb und Pflege
wirtschaftlich erfolgen. Eine effiziente Wartung muss für Personen, die nicht
an der Entwicklung beteiligt waren, ohne größere Einarbeitung möglich sein.
Zuverlässigkeit
Zuverlässigkeit (auch Verlässlichkeit) ist der Umfang, in dem von einem
System erwartet werden kann, dass es die beabsichtigte Funktion mit der erforderlichen Genauigkeit über den Einsatzzeitraum ausführt.
Tabelle 3-1: Allgemeine Anforderungen an IT-Systeme
3.3.2
Anforderungen an die Wiederverwendbarkeit
Mit steigender Bedeutung und vermehrter Entwicklung internetbasierter Mehrwertdienste rückt die
Frage der effizienten und effektiven Dienstgestaltung in den Vordergrund. Dabei nimmt die
Wiederverwendung eine Schlüsselrolle ein.
Eine Wiederverwendung kann auf verschiedenen Abstraktionsebenen erfolgen, z. B. durch
Nutzung gemeinsamer Entwurfsmuster, Software-Architekturen, Klassenbibliotheken oder Softwarekomponenten. Die Wiederverwendbarkeit unterstützt die aufwandsarme und schnelle Entwicklung von Diensten. Ferner wird durch die Wiederverwendung die Systemstabilität erhöht beziehungsweise die Fehleranfälligkeit reduziert.
3.3.3
Anforderungen an die Erweiterbarkeit und Anpassbarkeit
Vor dem Hintergrund der kontinuierlich fortschreitenden Entwicklung der Informationstechnologie
sowie der wechselnden Marktbedürfnisse ergeben sich Forderungen nach einer leichten Erweiterbarkeit und Anpassbarkeit. Dies betrifft sowohl die Client2- als auch die Server3-Seite. Um dieser
Herausforderung zu begegnen, benötigen Unternehmen eine erweiterbare und anpassbare Hardund Softwareumgebung, die ihre IT-Landschaften mit lokalen Anwendungen, Client-ServerUmgebungen einschließlich der Integration von Bestandssystemen4 unterstützt.
1
2
3
4
Der Begriff der Verfügbarkeit wird in der DIN 40042 als „Wahrscheinlichkeit, ein System zu einem vorgegebenen
Zeitpunkt in einem funktionsfähigen Zustand vorzufinden“ beschrieben.
Ein Client ist eine Anwendung, die in einem Netzwerk den Dienst eines Servers in Anspruch nimmt.
Begriff für einen Rechner im Netzwerk, der anderen Computern Dienste anbietet (z. B. für FTP oder E-Mail).
Auch legacy system (englisch für Vermächtnis Hinterlassenschaft, Erbschaft oder Altlast) bezeichnet. Bestandssysteme sind etablierte, historisch gewachsene Anwendungen.
- 42 -
Dies ist auch vor dem Hintergrund zu betrachten, dass die Technologiezyklen im Maschinen- und
Anlagenbau zwischen 8 und 15 Jahren liegen, und damit die IT-Zykluszeiten der Systemsoftware
und IT-Hardware überdauern1. Abbildung 3-1 zeigt die Zykluszeit von Anwendungs- und Systemsoftware sowie von Hardware im Vergleich.
Abbildung 3-1: Zykluszeit von Anwendungs- und Systemsoftware sowie von Hardware2
3.3.4
Anforderungen an die Integrationsfähigkeit
Um die Vorteile einer elektronischen Geschäftsabwicklung zu nutzen, ist eine Integration der Mehrwertdienste mit bestehenden PLM-Systemen3 notwendig. Vereinfacht ausgedrückt besteht die Aufgabe der Integration darin, zwei oder mehr IT-Systeme miteinander zu verbinden. Dazu sind zwei
Grundvoraussetzungen zu erfüllen: Zum einen muss ein Datenformat festgelegt werden, das die
zu integrierenden Systeme zum Datenaustausch verwenden. Zum anderen muss Übereinstimmung beim Protokoll zum Datenaustausch herrschen. Die Gestaltung der Schnittstellen4 ist in
der Praxis viel komplexer, sodass die spezifischen Anforderungen, wie z. B. Datendurchsatz, Firewall-Verträglichkeit etc., über diese Grundvoraussetzungen in der Regel deutlich hinausgehen.
Unternehmen müssen sich daher von der unkontrollierten Vernetzung von Applikationen abwenden und dezidierte Integrationsplattformen schaffen. Bei den genannten Integrationsaufgaben
spielen serviceorientierte Architekturen eine wesentliche Rolle. Die Grundidee ist dabei, anstelle
von monolithischen Systemen5 oder solchen mit unklaren Schnittstellenstrukturen Systeme beziehungsweise Systemlandschaften zu konzipieren, die ihre Services über klar definierte Schnittstellen und standardisierte Technologien zur Verfügung stellen6.
1
2
3
4
5
6
So führte z. B. das Auslaufen des Supports für das Betriebssystem Windows-NT für viele Hersteller zu Problemen,
da die Systemsoftware noch im Feld bei Kunden in Betrieb war beziehungsweise heute noch ist.
Vgl. /Aldi-2006 (S. 110)/Fähn-2006/.
Unter Product Lifecycle Management (PLM), englisch für Produktlebenszyklusmanagement, versteht man die unternehmerische Aufgabe sowie die hierzu notwendigen IT-Systeme, mit dessen Unterstützung alle Daten, die bei der
Planung, Entstehung, Lagerhaltung und dem Vertrieb eines Produkts anfallen, einheitlich gespeichert, verwaltet und
abgerufen werden. Im Idealfall greifen alle IT-Systeme auf eine gemeinsame Datenbasis zu: von der Konstruktion
(CAD), Berechnung (CAE), Planung (ERP), Fertigung (CAM) bis zum Controlling, Vertrieb und Service (CRM).
Schnittstellen (genauer: Softwareschnittstellen oder Datenschnittstellen) sind logische Berührungspunkte in einem
Softwaresystem. Sie definieren, wie Kommandos und Daten zwischen verschiedenen Prozessen und Komponenten
ausgetauscht werden. Dabei unterscheidet man Schnittstellen zum Zugriff auf Betriebssystemroutinen, zur
Kommunikation mit anderen Prozessen und zum Verbinden von Softwarekomponenten.
Monolithische Systeme zeichnen sich dadurch aus, dass die Applikationslogik mit der Darstellung und der Datenhaltung eng verwoben sind.
Vgl. /Spat-2005a (S. 12)/.
3.3.5
- 43 -
Anforderungen an die Offenheit und Interoperabilität
Die Anforderungen an die Offenheit1 und Interoperabilität2 internetbasierter Mehrwertdienste
rühren vor allem von der Anwendungs- und Datenintegration zu PLM-Systemen her. Die Basis
hierfür bilden die inzwischen ausgereiften Internet-Standards und -Protokolle, die seit einigen
Jahren durch Standards und Protokolle für Web-Services ergänzt werden. Wenngleich noch nicht
alle Web-Service-Technologien und -Protokolle vollständig definiert sind, ist deren Nutzung zu bevorzugen.
Dienste, die auf proprietären Technologien oder unzureichender Unterstützung anerkannter
Standards beruhen, werden sich nicht am Markt behaupten können. Viele Anwender haben Bedenken, sich dadurch in die Abhängigkeit eines einzelnen Herstellers zu begeben3.
Für die Verbreitung und Akzeptanz internetbasierter Dienste ist es deshalb notwendig, dass sie auf
offenen Standards basieren. Die zu schaffenden IT-Systeme sollten daher offen sein und unterschiedliche Datenformate und Protokolle unterstützen. Folglich ist die Offenheit von Systemen zugleich eine Anforderung zur Sicherstellung der Interoperabilität.
3.3.6
Anforderungen an die Netzwerke
Zur Fernerbringung industrieller Dienstleistungen sind Netzwerke erforderlich. Die
Kommunikationsverbindung zwischen Dienstleistungserbringer und -empfänger ist ein kritischer
Erfolgsfaktor, da der Transport häufig über Dritte erbracht wird und die Qualität der Verbindung4 –
zumindest im öffentlichen Internet – nicht garantiert werden kann.
Die konkreten Anforderungen an das Netzwerk hängen von den spezifischen Anforderungen der
Dienste und von den zu übertragenden Informationen ab. Standbilder, Videobilder, Sprache,
Sensordaten, Steuerungsdaten, Konfigurationsdaten, technische Dokumentation etc. verlangen
entsprechende Bandbreiten sowie Verfügbarkeiten und daraus abgeleitet entsprechende Netzwerke.
Es gibt zunehmend mehr Anwendungen, die auf verlässliche Netzwerkeigenschaften angewiesen
sind. Beispiele hierfür sind die Internettelefonie, Video- und Multimediaanwendungen5. In Tabelle
3-2 sind die Anforderungen an die Eigenschaften von Netzwerken aufgeführt:
1
2
3
4
5
Unter Offenheit versteht man in der IT eine offengelegte Beschreibung der Formate und Dienste inklusive des
Datenmodells und dessen Dokumentation. Der offene Standard unterliegt keinen Lizenzgebühren, Patenten oder
anderen Einschränkungen und ist öffentlich für jeden kostenlos oder zu moderaten Preisen verfügbar.
Unter Interoperabilität versteht man die Fähigkeit unabhängiger, heterogener Systeme, möglichst nahtlos zusammen
zu arbeiten, ohne dass dazu gesonderte Absprachen zwischen den Systemen notwendig sind.
Vgl. /Quan-2003 (S. 53)/.
Quality of Service (QoS), englisch für die Dienstgüte in Kommunikationsnetzen.
Ein hoher Datendurchsatz ist z. B. bei Echtzeitvideos notwendig, da sonst die Bilder anfangen zu springen, und somit
die Dienstgüte nicht gewährleistet ist. Hohe Anforderungen an die Latenz sind z. B. bei Anwendungen, die kurze Reaktionszeiten erfordern, notwendig.
Anforderung
- 44 -
Erläuterung
Leistungsfähigkeit
Netzwerkdurchsatz, Schwankung, Paketverlustrate und Verzögerung.
Reichweite
Verfügbarkeit beim Dienstleistungserbringer und -empfänger.
Standardisierung
Verzicht auf proprietäre Protokolle, deren langfristige Wiederverwertbarkeit
nicht gewährleistet ist.
Verfügbarkeit
Wahrscheinlichkeit, dass ein System die gestellten Anforderungen innerhalb
eines vereinbarten Zeitrahmens erfüllt.
Kosten
Die Kosten zum Transport von Daten
Sicherheit
Die Netzwerke sollten über Sicherheitsmechanismen verfügen.
Tabelle 3-2: Anforderungen an Netzwerke1
3.3.7
Anforderungen an die IT-Sicherheit
Sicherheit in der Informationstechnik2 steht für eine große Bandbreite von Anforderungen und Aufgaben. IT-Systeme müssen genügend Sicherheit gegen gezielte Ausspähung, zufällige oder
absichtliche Manipulation oder Zerstörung von Daten, Programmen und Ressourcen bieten.
Anforderung
Erläuterung
Vertraulichkeit
Vertraulichkeit besteht dann, wenn eine Information nur für Autorisierte zugänglich ist, Unbefugte dagegen keinen Zugang zu der Information haben.
(Daten-)Integrität
Die Integrität von Daten ist gewährleistet, wenn diese vom angegebenen
Absender stammen und vollständig sowie unverändert an den Empfänger
übertragen worden sind.
Autorisierung
In der Informationstechnologie bezeichnet Autorisierung die Zuweisung und
Überprüfung von Zugriffsrechten auf Daten und Dienste an Systemnutzer.
Authentizität
Authentizität bedeutet, Gewissheit über die Identität eines Kommunikationspartners zu haben.
Verbindlichkeit
Die Verbindlichkeit setzt sich zusammen aus der Identität des Verfassers
und der Integrität der Nachricht.
Tabelle 3-3: Anforderungen an die IT-Sicherheit
IT-Sicherheit reicht demnach vom Schutz vor illegalem physikalischem Zugriff auf Hard- und Softwaresysteme über den Schutz von Daten während des Transportes über Netzwerke bis hin zum
Einsatz von adäquater Verschlüsselungstechnik. Die Akzeptanz internetbasierter Mehrwertdienste
hängt entscheidend davon ab, dass die Sicherheit der Systeme gewährleistet ist3. Die Berücksichtigung der IT-Sicherheit muss deshalb ein integraler Bestandteil der Gestaltung fernerbrachter
Dienste sein. In Tabelle 3-3 sind die wichtigsten Anforderungen der IT-Sicherheit aufgeführt4:
1
2
3
4
Vgl. /ENX-2007a/Furr-2003 (S. 44)/Göhr-2001 (S. 30)/.
Anders als im angloamerikanischen Sprachraum wird im Deutschen nicht zwischen den beiden Themen Security und
Safety unterschieden, beide Begriffe werden stattdessen allgemein unter Sicherheit zusammengefasst. Während
Safety den Schutz der Umgebung vor einem Objekt, also eine Art Isolation beschreibt, handelt es sich bei Security
um den Schutz des Objektes vor der Umgebung, d. h. die Immunität.
Vgl. /BSI-2005b (S. 68)/Berg-2005 (S. 35)/.
Vgl. /BSI-2006 (Unterkapitel IV B)/Berg-2005 (S. 39)/.
4 Stand der Technik
Ich denke, es gibt einen Weltmarkt für vielleicht fünf Computer.
Thomas Watson
CEO IBM, 1943
Die nachfolgende Diskussion des Standes der Technik betrachtet die in der Forschung und betrieblichen Praxis angewandten Vorgehensmodelle. Da dem Autor keine Vorgehensmodelle bekannt sind, die sich der Gestaltung internetbasierter Mehrwertdienste für den Maschinen- und Anlagenbau widmen, erfolgt die Analyse von Vorgehensmodellen aus verwandten Bereichen. Hierbei
gilt es herauszuarbeiten, welche der existierenden Ansätze sich als Grundlage für die formulierte
Problematik eignen.
Allen Vorgehensmodellen liegen Methoden1 zugrunde. Da die Vorgehensmodelle teilweise
Methoden aus anderen Wissensgebieten nutzen, ist eine eindeutige Zuordnung von Methoden zu
Vorgehensmodellen nicht immer möglich. So ist beispielsweise die UML-Notation2 im Bereich Software Engineering entstanden, aber heute auch im Service Engineering gebräuchlich. Zur Verbesserung der Übersichtlichkeit erfolgt deshalb in Kapitel 4.1 zunächst die Nennung der
wichtigsten Methoden zur Prozessmodellierung. Das Kapitel 4.2 behandelt Beschreibungssprachen zur Prozessmodellierung. Im Anschluss werden in den Kapiteln 4.3 bis 4.5 bekannte
Vorgehensmodelle aus dem Service Engineering und Software Engineering vorgestellt. Die Darstellung von Ansätzen zur parallelen Gestaltung von Software und Dienstleistungen für allgemeine
IT-Services erfolgt in Kapitel 4.6. Das Kapitel endet mit einer zusammenfassenden Bewertung in
Abschnitt 4.7.
4.1 Methoden zur Prozessmodellierung
Die Betrachtung von Dienstleistungen kann auf der Basis von Modellen erfolgen. Modelle können
mithilfe von Sprachen als gedankliche Konstruktionen verstanden werden, die einem definierten
Verwendungszweck dienen. Jeder Modellierungsmethode liegt eine Betrachtungsperspektive zugrunde, die bestimmte Objekte und Aspekte der Realität betrachtet und abbildet, während andere
Objekte und Aspekte ausgeblendet werden. Eine vollständige Beschreibung aller Zusammenhänge eines Prozesses würde das Modell sonst unübersichtlich machen. Durch die Modellbildung,
d. h. die Beschreibung des Systems auf einer abstrakten Ebene, werden handhabbare Systeme
geschaffen, mit denen eine Beherrschung der Systemkomplexität erleichtert wird3. Eine
Modellierungsmethode gibt damit ein Beschreibungsraster vor, das definiert, welche Informationen
aus dem Realitätsausschnitt beziehungsweise der Betrachtungsperspektive zu erheben sind4.
1
2
3
4
Eine Methode ist eine planmäßig angewandte, begründete Vorgehensweise zur Erreichung festgelegter Ziele.
Vgl. Kapitel 4.1.3.
Vgl. /DIN-75 (S. 47)/VDI-3633 (S. 9)/.
Vgl. /Lang-1997 (S. 16)/.
Stand der Technik
- 46 -
Die Vorteile einer modellbasierten Prozessmodellierung liegen zum einen in der detaillierten und
transparenten Dokumentation der Arbeitsabläufe zur Erbringung der Dienstleistung. Zum anderen
können Fehlerquellen, Problemstellen und Schwachpunkte identifiziert und Verbesserungsansätze
innerhalb der Geschäftsprozesse und darauf aufbauend in der Aufbauorganisation konzipiert
werden. Die Modellierung von Geschäftsprozessen ist damit ein Instrument zur Erhöhung der
Prozesseffizienz, -qualität und dient ferner dazu, Rollenklarheit zu gewährleisten.
In der Literatur findet sich eine Vielzahl unterschiedlicher Modellierungsmethoden. Sie unterscheiden sich in den Modellierungsintentionen (z. B. Prozessgestaltung, Programmierung), im Anwender (z. B. Fachabteilung, Management) und im abgebildeten Realitätsausschnitt (z. B.
Prozessablauf, Datenfluss). Entsprechend der eingesetzten Modellierungsmethode lassen sich in
Anlehnung an Lang1, Fahrwinkel2 und Rosemann3 die Prozessmodellierungsverfahren in drei
Klassen einteilen: aktivitätsorientierte, ereignisorientierte und objektorientierte Ansätze.
4.1.1
Aktivitätsorientierte Ansätze
Hauptvertreter des aktivitätsorientierten Ansatzes sind Programmablaufpläne. Diese gehören wie
Datenflusspläne4 zur Gruppe der Blockdiagramme. Sie dienen der Darstellung der Art sowie der
zeitlichen Reihenfolge von Verarbeitungsschritten und deren möglichen Verzweigungen, in Abhängigkeit von Entweder-oder-Bedingungen. Die Beschreibung ist jedoch auf eine sequenzielle
Reihenfolgebildung beschränkt; parallele Abläufe lassen sich nicht abbilden. Der reduzierte
Sprachumfang lässt nur eine eingeschränkte Modellierung betrieblicher Geschäftsprozesse zu5.
Das Service Blueprinting6 ist ein Vertreter des aktivitätsorientierten Ansatzes und findet vor allem
im Service Engineering zur Prozessdarstellung von Dienstleistungen Anwendung (siehe Abbildung
4-1). Die Betrachtung einer Dienstleistung erfolgt dabei immer aus Kundensicht. Das Modell unterscheidet kunden- und dienstleisterinterne Prozesse sowie Prozesse, die für beide Parteien sichtbar
sind. Mittels einer Sichtbarkeitslinie und zwei Interaktionslinien werden die Prozesse getrennt, und
damit mehr Übersichtlichkeit und Transparenz geschaffen7.
kundeninterne
Prozesse
Was
Was der
der Kunde
Kunde
möchte.
möchte.
Was
Was der
der Kunde
Kunde
empfindet.
empfindet.
Externe Interaktionslinie
Was
Was der
der Kunde
Kunde
vorträgt.
vorträgt.
Was
Was der
der Kunde
Kunde
wahrnimmt.
wahrnimmt.
sichtbare
Prozesse
Sichtbarkeitslinie
Was
Was der
der DienstDienstleister
leister aufnimmt.
aufnimmt.
Was
Was der
leister antwortet.
antwortet.
Interne Interaktionslinie
dienstleisterinterne Prozesse
Was
Was der
leister veranlasst.
veranlasst.
Abbildung 4-1: Service-Blueprinting-Beispiel
1
2
3
4
5
6
7
Vgl. /Lang-1997 (S. 16)/.
Vgl. /Fahr-1995 (S. 19)/.
Vgl. /Rose-1996 (S. 48)/.
Vgl. /DIN-66001/.
Vgl. /Lang-1997 (S. 17)/.
Service Blueprinting, englisch für Blaupause.
Vgl. /King-1989 (S. 30)/.
Stand der Technik
4.1.2
- 47 -
Ereignisorientierte Ansätze
Als erster Vertreter der ereignisorientierten Modellansätze gilt das Beschreibungsmittel Structured
Analysis and Design Technique (SADT), das zur Gestaltung betrieblicher Informationssysteme eingesetzt wird. SADT unterstützt die Systembeschreibung aus Sicht der Aktivitäten und der Daten,
indem es ein Aktivitäten- und Datenmodell zur Verfügung stellt. Dagegen wird der Aufbau von
Modellen betrieblicher Prozesse angesichts der wenigen zur Verfügung gestellten Konstrukte und
der bedingten Wiedergabe von zeitlichen Abhängigkeiten nur unzureichend unterstützt.
Die Ereignisgesteuerten Prozessketten (EPK) wurden entwickelt, um betriebswirtschaftliche Vorgangskettenmodelle zur Beschreibung von Unternehmensprozessen, die durch Informationssysteme unterstützt werden sollen, darzustellen1. Die EPK ist ein wesentliches Element des ARISKonzepts2. EPK setzen sich aus den Basiskonstrukten Funktion, Ereignis und Verknüpfungsoperator3 zusammen. Das Ereignis ist als Auslöser von Funktionen das zentrale Steuerungselement. Es charakterisiert einen Zustand, der eine oder mehrere Funktionen auslöst. Durch die
Zuordnung von Ereignissen zu Funktionen, die wiederum ein oder mehrere Ereignisse erzeugen,
erhält man einen zusammengehörigen Geschäftsprozess. Da Ereignisse die Funktionen steuern,
wird diese Prozessnotationsform als Ereignisgesteuerte Prozesskette bezeichnet. Die erweiterte
Form der EPK, die erweiterte Ereignisgesteuerte Prozesskette (eEPK), beinhaltet zusätzliche
Konstrukte zur Darstellung von Informationsobjekten, Informationsträgern, Anwendungssystemen,
Hardwarekomponenten und Organisationseinheiten (siehe Abbildung 4-2).
Ereignisgesteuerte Prozessketten bieten den Vorteil, dass sie eine genaue Abbildung der zeitlichlogischen Abhängigkeiten zwischen den Funktionen mithilfe von Ereignissen und Verknüpfungsoperatoren ermöglichen. Bei der Erstellung größerer Prozessmodelle machen sich jedoch fehlende
Navigationsmechanismen bemerkbar, sodass der Modellierungsaufwand stark ansteigt. Gleichzeitig reduziert sich die Prozesstransparenz.
Abbildung 4-2: Erweiterte Ereignisgesteuerte Prozesskette (eEPK)
1
2
3
Vgl. /Sche-1991 (S. 3)/.
ARIS, Abkürzung für Architektur integrierter Informationssysteme. Vgl. /Sche-2002/.
Auch Konnektoren genannt; mithilfe derer lassen sich alternative und/oder parallele Abläufe beschreiben.
Stand der Technik
4.1.3
- 48 -
Objektorientierte Ansätze
Die Objektorientierung1 entwickelt sich seit den 90er Jahren zu einem anerkannten Paradigma.
Modellierungsgegenstand objektorientierter Ansätze sind Objekte, die gegenseitig Nachrichten
austauschen. Haupteinsatzgebiet ist der Entwurf von Programmen und Datenbanken sowie der
Aufbau von Dokumentationssystemen.
In den Anfängen des objektorientierten Paradigmas entwickelten sich mehrere Methoden und
Notationen zur Modellierung objektorientierter Systeme2. Drei der wichtigsten Methoden waren:

Object Oriented Software Engineering (OOSE) von Jacobson

Object Oriented Design (OOD) von Booch

Object Modeling Technique (OMT) von Rumbaugh
Diese drei Urväter der objektorientierten Modellierung begründeten eine Initiative zur Schaffung
einer vereinheitlichten Modellierungssprache, der Unified Modeling Language3 (UML). UML ist
heute in der Forschung und der Industrie weit verbreitet.
Die Unified Modeling Language ist eine grafische Modellierungssprache mit zwölf verschiedenen
Diagrammtypen. Diese lassen sich aufteilen in Beschreibung statischer Struktur (Klassendiagramme) und dynamischen Verhaltens (Zustands- und Aktionsdiagramme) sowie in Diagramme
zur Verwaltung des Modells (Paketdiagramme). Zu den bekanntesten Elementen gehört das UseCase-Diagramm (siehe Abbildung 4-3). Zielsetzung der Methode ist die Erfassung und Darstellung
der aus Sicht von externen Bedienungseinheiten (Aktoren) an ein System gestellten funktionalen
Anforderungen. Die Anforderungen sind in Form von Anwendungsfällen, den Use Cases, zu beschreiben. Da es umfassende Literatur über die UML gibt, wird an dieser Stelle auf eine weitere
Beschreibung der einzelnen Elemente und deren Verwendung verzichtet4.
Abbildung 4-3: Use-Case-Diagramm
1
2
3
4
Unter Objektorientierung wird das Paradigma verstanden, das durch folgende Konzepte gekennzeichnet ist: Kapselung von Daten und Operationen zur ganzheitlichen Beschreibung von Objekten, Zusammenfassung von Objekten zu
Klassen, Organisation von Klassen in einer Hierarchie unter Nutzung der Generalisierung und Spezialisierung,
Vererbung und Aufbau von Assoziationen zwischen Klassen, Kommunikation zwischen Objekten über Nachrichten.
Vgl. /Weis-2000 (S. 28)/.
Seit 1999 unterliegt die UML der Standardisierung durch die Object Management Group (OMG). Die derzeit aktuelle
Version der UML ist die Version 2.1 vom April 2006. Vgl. /OMG-2006a/.
Vgl. /OMG-2006a/Zuse-2004/Chee-2001/Balz-2001/.
Stand der Technik
4.1.4
- 49 -
Zusammenfassende Bewertung der Methoden zur Prozessmodellierung
Zusammenfassend lässt sich feststellen, dass die vorgestellten Ansätze zur Abbildung und
Dokumentation von Geschäftsprozessen prinzipiell geeignet sind, um die Prozesse in der Erbringung von internetbasierten Mehrwertdiensten zu beschreiben. Insbesondere die Konzepte der
objektorientiert aufgebauten Ansätze haben gegenüber den aktivitäts- und ereignisorientierten Ansätzen den Vorteil, dass sie nicht nur den geringsten Modellierungsaufwand, sondern auch die
höchste Anpassungsfähigkeit und Modellierungsflexibilität aufweisen. Zu nennen sind hier insbesondere:

die grafische Modellierung und Darstellung von Geschäftsprozessen,

die leichte Änderbarkeit und Erweiterbarkeit von Prozessmodellen,

der aufgrund der angewandten Modellierungsmechanismen, wie z. B. Vererbung, reduzierte
Modellierungsaufwand,

die erleichterte Konsistenzsicherung sowie

die hohe Wiederverwendbarkeit der modellierten Objekte.
Der Nutzen der Methoden zur Prozessmodellierung wurde in den vergangenen Jahren jedoch
auch kritisch bewertet. Insbesondere wurde die fehlende Möglichkeit zur Weiternutzung der aufwendig erstellten Prozessmodelle bemängelt. Es lassen sich zwar Geschäftsprozesse z. B. mittels
UML analysieren und gestalten, aber die Umsetzung (Codierung) erfolgt in einer anderen Sprache
und über andere Verfahren. Eine Änderung in einem UML-Klassendiagramm zieht nicht automatisch eine Änderung der Codierung nach sich.
Die Folge hiervon ist, dass bei steigender Detaillierung der Abläufe im Rahmen der Codierung die
Prozessmodelle zunehmend vom spezifizierten System abweichen. Dies führt in der Praxis häufig
dazu, dass die Prozessbeschreibungen zunächst ihre Aktualität verlieren, dann aufgrund der Diskrepanz von Modell und Realität ihre Bedeutung verlieren und am Ende aus Aufwandsgründen
nicht mehr aktualisiert werden.
Stand der Technik
- 50 -
4.2 Beschreibungs- und Ausführungssprachen zur Prozessmodellierung
In jüngster Vergangenheit sind Beschreibungs- und Ausführungssprachen zur Prozessmodellierung in den Mittelpunkt des Interesses gerückt. Diese unterstützen sowohl die Modellierung als
auch die Ausführung von Geschäftsprozessen. Eine Voraussetzung hierfür ist, dass die Prozesse
formal beschrieben sind und von Computern interpretiert werden können1. Die Modellierung erfolgt
unter Nutzung von Business Process Management Systemen (BPM). Die Prozessausführung2
übernehmen Workflowengines3.
Die direkte Ausführbarkeit der Prozessmodelle ohne erneute Codierung in einer anderen Sprache
bietet einerseits alle Vorteile der konventionellen Prozessmodellierung und behebt andererseits
deren Problem bzgl. der fehlenden Weiternutzungsmöglichkeit.
4.2.1
Das Workflow Reference Model der Workflow Management Coalition
Eine der ersten Organisationen, die sich mit Beschreibungssprachen für Geschäftsprozesse beschäftigt hat, ist die Workflow Management Coalition (WfMC)4. Sie wurde im Jahr 1993 als Zusammenschluss von Herstellern von Workflowmanagementsystemen (WfMS), Anwendern von
WfMS sowie einigen Forschungsinstituten gegründet. Ihr Ziel ist es, die Verbreitung von WfMS zu
fördern, indem sie Standards für die Terminologie des Workflow Managements definiert und
Schnittstellen für WfMS entwickelt. Die WfMC kreierte bereits im Jahr 1995 ein nach wie vor
gültiges Rahmenmodell mit fünf Schnittstellen (siehe Abbildung 4-4). Inzwischen sind andere
Organisationen dem Ziel gefolgt, Beschreibungssprachen zu standardisieren.
Abbildung 4-4: Workflow Reference Model der Workflow Management Coalition5
1
2
3
4
5
Zur umfassenden Darstellung von reinen Prozessmodellierungswerkzeugen vgl. /Soda-2006/.
Prozessabläufe werden in Anlehnung an die englische Sprache auch als Workflow bezeichnet. Ein Workflow ist
dabei als eine Abfolge von Tätigkeiten zu verstehen, die zur Realisierung von Aufgaben ausgeführt werden.
Eine Workflowengine ist eine Softwareumgebung, in der sich Prozessabläufe (Workflows) ausführen lassen.
Vgl. /WfMC-2007/.
Vgl. /Holl-1995 (S. 20)/.
Stand der Technik
4.2.2
- 51 -
XML Process Definition Language (XPDL)
Die XML Process Definition Language (XPDL) ist eine XML basierte Sprache zur Beschreibung
von Geschäftsprozessen. Die XPDL wird seit dem Jahr 1993 von der Workflow Management
Coalition vorangetrieben und ist damit der Vorgänger aller u. g. Beschreibungssprachen.
Im Jahr 2002 veröffentlichte die WfMC die XPDL Version 1.0. Die aktuelle XPDL Version 1.14 ist
aus dem Jahr 20051 und unterstützt vollständig die grafische Business Process Modeling Notation
(BPMN), die im Kapitel 4.2.5 vorgestellt wird. XPDL stellt ein Grundgerüst einer Prozessdefinition
dar; es werden nicht alle Anforderungen und Entwicklungstools unterstützt.
4.2.3
Web Services Flow Language (WSFL)
Im Jahr 2001 veröffentlichte die IBM die Version 1.0 des Web Services Flow Language-Standards
(WSFL)2, die auf die Anforderungen von Web-Services ausgelegt ist. WSFL definiert per XML ein
Modell eines gerichteten Graphen, mit durch Kontrollflüsse und Datenflüsse verbundenen Aktivitäten, sich von Workflowengines abarbeiten lässt.
WSFL hat somit einen engeren Fokus als XPDL und ist auf mehrere parallel ablaufende Instanzen
ausgelegt. WSFL ist in einem Nutzungsverbund mit der Web Services Description Language
(WSDL) zu sehen, da WSFL auf die durch WSDL beschriebenen Web-Services zugreift, und daher
Synergieeffekte zwischen den beiden Sprachen zu erreichen sind. WSFL wird nicht mehr weiterentwickelt, da die beteiligten Unternehmen sich der WS-BPEL-Initiative (siehe Kapitel 4.2.4) angeschlossen haben. Viele Ideen von WSFL flossen in WS-BPEL ein.
4.2.4
Web Services Business Process Execution Language (WS-BPEL)
Wie die Vorgängersprache Business Process Execution Language (BPEL)3 ist die Web Services
Business Process Execution Language (WS-BPEL) eine XML-basierte Sprache zur Beschreibung
von Geschäftsprozessen, deren einzelne Aktivitäten durch Web-Services implementiert sind.
Im Mittelpunkt von WS-BPEL steht die Festlegung des Nachrichtenaustausches zwischen einem
Prozess und seinen Partnern. Mögliche Partner sind alle die Prozesse, die eine gemeinsame
Schnittstelle haben. Ist dies der Fall, kann unter Anwendung sogenannter WSDL-Dokumente eine
transport- und plattformunabhängige Vernetzung zwischen Diensten aufgebaut werden.
BPEL wurde ursprünglich von BEA, IBM und Microsoft entwickelt. Heute unterstützen große Infrastruktur- und Softwareanbieter wie Oracle (BPEL Process Manager Designer), Microsoft (BizTalk
Server), IBM (WebSphere), SAP (NetWeaver) und BEA (WebLogic Integration) die Spezifikation.
Darüber hinaus stehen auch Open Source Werkzeuge zur Verfügung4.
Die Entwicklung wird seit dem Jahr 2003 von OASIS5 vorangetrieben. Die OASIS hat kürzlich die
Version 2.06 vorgestellt, die teilweise inkompatibel zu den 1.x-Versionen ist. Wegen der durch die
Veränderungen und Erweiterungen nicht mehr gegebenen Kompatibilität hat die OASIS beschlossen, ab der Version 2.0 den bisherigen Namen BPEL in WS-BPEL zu ändern.
1
2
3
4
5
6
Vgl. /WfMC-2005/.
Vgl. /Leym-2001/.
zuvor Business Process Execution Language for Web Services, kurz BPEL4WS, genannt.
Vgl. </http://www.bpelsource.com/>, letzter Abruf am: 01.05.2008.
Die Organization for the Advancement of Structured Information Standards (OASIS) ist ein internationales
Konsortium. Deren Ziel ist die Einführung von Standards, um die Interoperabilität zu verbessern. Vgl. /OASI-2007b/.
Vgl. /OASI-2007a/.
Stand der Technik
4.2.5
- 52 -
Business Process Modeling Language (BPML)
Die Business Process Modeling Language (BPML) wurde im Jahr 2001 vom BPMI-Konsortium1 in
der Version 1.0 veröffentlicht. BPML basiert auf XML, ist direkt ausführbar und plattformunabhängig. Eine Besonderheit von BPML liegt in der Möglichkeit zur Definition von Unterprozessen
und Transaktionen. Dies wird z. B. bei BPEL nicht unterstützt. BPML hat jedoch auch Nachteile.
BPML setzt voraus, dass alle angebundenen Applikationen über XML angesprochen werden
können. Wie die Einbindung von Bestandssystemen erfolgen soll, ist demnach nicht spezifiziert.
Dies hat zur Folge, dass BPML auf Web-Service-Applikationen beschränkt ist. Derzeit gibt es auf
dem Markt nur wenige Anbieter, welche die BPML in voller Tiefe unterstützen2.
Da sich die BPML nicht gegen konkurrierende Sprachen wie WS-BPEL oder XPDL durchsetzen
konnte, gab die Business Process Management Initiative (BPMI) die Weiterentwicklung der BPML
auf. Im Jahr 2005 fusionierte das BPMI-Konsortium mit der OMG3 und beschäftigt sich seitdem mit
der Weiterentwickelung der Business Process Modeling Notation (BPMN).
4.2.6
Business Process Modeling Notation (BPMN)
Die Business Process Modeling Notation (BPMN) wurde erstmals im Jahr 2002 vom BPMIKonsortium veröffentlicht. Im Jahr 2006 erschien die Final Adopted Specification der Business
Process Modeling Notation Specification Version 1.04.
Der Schwerpunkt von BPMN liegt auf der Notation, d. h. auf der grafischen Darstellung von Geschäftsprozessen. Die BPMN definiert die Semantik der Symbole, legt jedoch keinen Wert auf
formale Definitionen. Über ein standardisiertes Format für die Speicherung und den Austausch der
sogenannten Business Process Diagrams (BPD) sagt die Spezifikation nichts aus. So einfach die
Diagramme durch Menschen gezeichnet oder interpretiert werden können, so schwerer fällt es
Computern, die grafische Notation für die Ausführung eines Geschäftsprozesses zu übernehmen.
Maschinell lesbare Prozessbeschreibungen sind deshalb meistens in anderen Ausführungssprachen für Geschäftsprozesse festgehalten, zum Beispiel in der Web Services Business Process
Execution Language (WS-BPEL) oder in der XML Process Definition Language (XPDL). BPMN,
WS-BPEL und XPDL ergänzen sich wechselseitig, indem WS-BPEL und XPDL dort eingesetzt
werden, wo BPMN Lücken aufweist. So definiert der BPMN-Standard, wie ein BPD-Diagramm in
WS-BPEL übersetzt wird, damit die beschriebenen Prozesse durch einen Computer ausgeführt
werden können. Eine analoge Übersetzung definiert die Workflow Management Coalition (WfMC)
für BPMN und XPDL.
1
2
3
4
BPMI, englische Abkürzung für Business Process Management Initiative.
Die Firma BEA Systems ist mit der Produktsuite WebLogic Communications Platform sehr nah an der Spezifikation,
die Firma Telelogic AB (ehem. Popkin) unterstützt den Standard mit dem Produkt System Architect vollständig.
Die Object Management Group (OMG) ist ein internationales Konsortium, das Standards für die objektorientierte
Programmierung entwickelt. Die OMG ist eines der größten Konsortien der Computer-Industrie. Vgl. /OMG-2007/.
Vgl. /OMG-2006b/.
Stand der Technik
4.2.7
- 53 -
Zusammenfassende Bewertung der Beschreibungs- und Ausführungssprachen
Zunächst muss festgestellt werden, dass alle Sprachen unterschiedliche Zielsetzungen verfolgen.
Während mit XPDL und BPMN beinahe alle Workflows implementiert werden können, sind dagegen WSFL und BPML nur auf die Nutzung innerhalb von Web-Services spezialisiert. Alle
Beschreibungs- und Ausführungssprachen haben ihre Vor- und Nachteile. Es ist eine situationsbedingte Entscheidung, welche Sprache zur Anwendung kommen sollte. Aus diesem Grund kann
keine allgemeingültige Bewertung erfolgen.
Keine der genannten Beschreibungs- und Ausführungssprachen hat sich bisher durchgesetzt, und
eine kurzfristige Standardisierung ist z. Z. nicht absehbar, wenngleich alle Interessensverbände
davon sprechen, selbst der Standard zu sein. In der Literatur überwiegen bisher vertriebsorientierte Publikationen von Softwareherstellern1 und Beratungsunternehmen sowie Veröffentlichungen aus Forschungsprojekten2. Erfahrungsberichte aus der industriellen Praxis fehlen bislang. Beschreibungs- und Ausführungssprachen zur Prozessmodellierung können daher mehr dem
Stand der Forschung als dem Stand der Technik zugeordnet werden.
Im Rahmen dieser Arbeit wird auf die Nutzung von Beschreibungssprachen zur Prozessmodellierung verzichtet. Es existieren keine etablierten Standards, auf die man bauen könnte. Die
Gefahr, die man eingeht, wenn man auf den falschen Standard setzt, ist zu groß – zumal die Investitionen in die Software und die Personalqualifizierung nicht unerheblich sind. Ein Beispiel hierfür ist die Inkompatibilität zwischen dem BizTalk Server 2004 mit dessen Vorgängerversionen
BizTalk Server 2002 und BizTalk Server 2000. Aus Gründen der IT-Sicherheit und Performanz
empfahl Microsoft den Wechsel auf den BizTalk Server 2004, was eine vollständige Neuimplementierung aller Prozessmodelle erforderte. Eine vergleichbare Situation zeichnet sich bei
der Weiterentwicklung von BPEL ab. Aufgrund der Inkompatibilität hat die OASIS beschlossen, ab
der Version 2.0 sogar den bisherigen Namen BPEL in WS-BPEL zu ändern.
Was die Zukunft angeht, muss abgewartet werden, in welche Richtung sich die Workflowtechnologie entwickeln wird. Da sich die Verwendung von XML in vielen Branchen bewährt hat, ist
zu vermuten, dass sich einer der vorgestellten XML-Standards durchsetzt. Nach Meinung des
Autors zeichnet sich bereits heute ab, dass Beschreibungssprachen zur Prozessmodellierung in
Zukunft zunehmend an Bedeutung gewinnen werden.
1
2
Vgl. /Spat-2006/Spat-2005a/Spat-2005b/.
Einen Einblick in die Diskussionen der Scientific Community unter: </http://www.workflow-research.de/Forums/>,
letzter Abruf am: 01.05.2008.
Stand der Technik
- 54 -
4.3 Konventionelle Vorgehensmodelle
Die im Folgenden vorgestellten Vorgehensmodelle des Methodischen Konstruierens sowie des
Systems Engineerings liefern die Grundlagen für die in Kapitel 4.4 erläuterten Vorgehensmodelle
des Service Engineerings sowie die in Kapitel 4.5 vorgestellten Vorgehensmodelle des Software
Engineerings.
4.3.1
Vorgehensmodell des Methodischen Konstruierens nach VDI 2221
Allen Vorgehensmodellen liegt ein Problemlösungsprozess zugrunde, der einen engen Zusammenhang zwischen Zielsetzung, Planung, Durchführung und Kontrolle beschreibt. Die
Prozessschritte sind durch Entscheidungen miteinander verbunden (siehe Tabelle 4-1).
Prozessschritt
Beschreibung
Problemanalyse
Jede Aufgabenstellung bewirkt zunächst eine Gegenüberstellung mit mehr
oder weniger unbekannten Faktoren hinsichtlich der Lösung des Problems.
Problemformulierung
Die Formulierung und Präzisierung des zu lösenden Problems erleichtert die
Lösungssuche, weil damit der Kern der Aufgabe und die Anforderungen ohne
Vorfixierung auf Lösungen definiert werden.
Systemsynthese
Beim Suchen nach Lösungen in dieser Phase werden Lösungsideen oder
schon konkrete Lösungen erarbeitet und kombiniert. Wesentliches Merkmal ist
das Entwickeln beziehungsweise Erkennen mehrerer Lösungen.
Systemanalyse
Dann werden die Lösungen hinsichtlich ihrer Eigenschaften analysiert, um die
für eine Lösungsauswahl erforderlichen Informationen zu gewinnen.
Beurteilung und
Entscheidung
Die Beurteilung der Lösungseigenschaften in Bezug auf die gestellten Anforderungen ist Grundlage für eine anschließende Entscheidung.
Tabelle 4-1: Prozessschritte des Problemlösungsprozesses
Das aus der Konstruktionslehre bekannte Vorgehensmodell des Methodischen Konstruierens ist in
der VDI-Richtlinie 2221 definiert1. Die VDI-Richtlinie behandelt allgemeingültige, branchenunabhängige Grundlagen methodischen Entwickelns und Konstruierens und definiert diejenigen
Arbeitsschritte und Arbeitsergebnisse, die wegen ihrer generellen Logik und Zweckmäßigkeit als
Leitlinien für ein Vorgehen gelten können. Wesentliche methodische Grundlagen sind hierbei die
Nomenklatur und das Instrumentarium der Systemtechnik als allgemeine Problemlösungsmethodik. Diese VDI-Richtlinie bildet die Grundlage für alle im Folgenden genannten Vorgehensmodelle (siehe Abbildung 4-5).
Bei komplexen Problemstellungen reicht die sequenzielle Abarbeitung der oben genannten
Schritte nicht aus. Wichtig und üblich sind dann Wiederholungszyklen, bei denen die Vorgehensschritte mehrmals durchlaufen werden. Dieses iterative Vorgehen führt zur Anhebung des
Informationsniveaus für einen erneut zu durchlaufenden Schritt entsprechend einem Lernprozess2.
1
2
Die /VDI-2221/ wird durch die Richtlinien /VDI-2222/ Methodisches Entwickeln von Lösungsprinzipien und die Richtlinien /VDI-2223/ Methodisches Gestalten erweitert und ergänzt.
Die VDI-Richtlinie /VDI-2221 (S.5)/ beschreibt, dass es keine streng linearen Ablaufpläne beim Problemlösen gibt,
sondern dass nur iteratives Vorgehen, das sich flexibel dem zu lösenden Problem, dem Kenntnis- und Erfahrungsstand, dem Lösungsfortschritt und den persönlichen Fähigkeiten des Bearbeiters anpasst, zum Erfolg führt.
Stand der Technik
- 55 -
Arbeitsschritte
Arbeitsergebnisse
Phasen
Klären
Aufgabe
Klärung und Präzisierung
der Aufgabenstellung
Anforderungsliste
Prinzipielle Lösungen
Gliedern in
realisierbare Module
Modulare Strukturen
Gestalten der
maßgebenden Module
Vorentwürfe
Gestalten des gesamten
Produktes
Konzipieren
Entwerfen
Funktionsstrukturen
Suche nach Lösungsprinzipien
und deren Strukturen
Erfüllen und Anpassen der Anforderungen
Iteratives Vor- und Zurückspringen
zu einem oder mehreren Arbeitsschritten
Ermitteln von Funktionen
und deren Strukturen
Ausarbeiten der Ausführungsund Nutzungsangaben
Produktdokumentation
Weitere Realisierung
Abbildung 4-5: Vorgehensmodell des Methodischen Konstruierens1
1
Vgl. /VDI-2221 (S. 9)/.
Ausarbeiten
Gesamtentwurf
Stand der Technik
4.3.2
- 56 -
Vorgehensmodelle des Systems Engineerings
Systems Engineering ist ein interdisziplinärer Ansatz, um Systeme zu entwickeln und zu
realisieren. Der Kerngedanke des Systems Engineerings ist, große beziehungsweise komplexe
Entwicklungsaufgaben in beherrschbare Systeme zu gliedern und sie somit handhabbar zu
machen. Dadurch können auf einfachere Weise Lösungen gefunden werden. Anschließend
werden diese Einzel- beziehungsweise Teillösungen zur Gesamtlösung verknüpft. Nicht unproblematisch ist dabei das Erkennen der Kombinierbarkeit von Einzellösungen zu Teillösungen
und Gesamtlösungen, d. h. der Verträglichkeit der Einzellösungen beziehungsweise der Teillösungen untereinander.
Im Mittelpunkt des Systems Engineerings stehen zum einen, die gewünschten Funktionalitäten
früh in den Entwicklungszyklus einfließen zu lassen und zum Anderen, nach jedem Schritt eine
Design-Synthese und System-Überprüfung durchzuführen. Um diesen Ansatz zur Verwaltung von
Konzeption, Design, Produktion, Betrieb und Wiederverwertung zu verwirklichen, ist es nötig, einen
interdisziplinären Ansatz von Management- und Engineering-Disziplinen zu nutzen.
Das Vorgehensmodell des Systems Engineerings gliedert sich in vier Leitlinien:

Vom Groben zum Feinen: Der Ansatz besteht darin, den Lösungsprozess in Phasen zunehmender Konkretisierung zu gliedern. So werden zunächst in einer prinzipiellen Lösung die
grundlegenden Zusammenhänge und erst in einem realisierbaren Entwurf die weiteren Einzelheiten festgelegt. In die gleiche Richtung geht die Strategie: vom Wesentlichen zum weniger
Wesentlichen beziehungsweise von den Hauptproblemen zu den Teilproblemen.

Variantenbildung: Die Variantenbildung unterstützt den Lösungsvergleich. Je mehr Varianten
gefunden werden, desto wahrscheinlicher ist es, dass die optimale Lösung dabei ist.

Phasengliederung: Die Phasengliederung im Systems Engineering besteht aus den Schritten:
Vorstudie, Hauptstudie, Detailstudien, Systembau, Systemeinführung und Abschluss (siehe
Abbildung 4-6). Die Ergebnisse lauten entsprechend: Rahmenkonzept oder Lösungsprinzip,
Gesamtkonzept, Detailpläne, einführungsbereites System und eingeführtes System. Nach
jeder Phase wird über die Projektfortführung entschieden, um das Projektrisiko zu reduzieren.

Problemlösungszyklus: In jeder Phase ist der Problemlösungszyklus (siehe Kapitel 4.3.1)
anzuwenden. Hierbei ist zu beachten, dass sich jedes Projekt bis zu seiner Wiederverwertung
weiterentwickelt und sich somit das System laufend verändert. Diese Situation beruht auf der
Wechselwirkung zwischen den Systemkomponenten und ist somit nicht vollständig deterministisch. Die möglichst genaue Definition und Charakterisierung der Zusammenhänge ist
das primäre Ziel des Systems Engineerings1.
1
Vgl. /Habe-2002/Balz-2001/.
Stand der Technik
- 57 -
Lebensphasen des
Systems / der Lösung
Zustände/
Ergebnisse
Anstoß
Projektphasen
Anstoß
Problem
Ideen
Vorstudie
Abbruch
Lösungsprinzip
System
in
Entw icklung
Hauptstudie
Gesamtkonzept
Masterplan
Detailstudien
Detailpläne
Detailpläne
Systembau
System
in
Realisierung
Einführungsbereites
System
Nutzung
Eingeführtes
(lebendes)
System
Systemeinführung
und Übergabe
Abschluss des
Projektes
Unbefriedigendes
überholtes
System
Umbau / Neubau
Außerdienststellung, Entsorgung
Abbildung 4-6: Phasengliederung des Systems Engineerings1
1
Vgl. /Habe-2002/.
Evtl. neues
Projekt
Stand der Technik
- 58 -
4.4 Vorgehensmodelle des Service Engineerings
4.4.1
Herkunft des Service Engineerings
Erste Publikationen zur Gestaltung von Dienstleistungen finden sich in den 80er Jahren vor allem
in der anglo-amerikanischen Literatur. Unter den Schlagworten New Service Development und
Service Design entstand eine Reihe von Beiträgen, die allerdings zumeist nur die Wichtigkeit der
Entwicklung von Dienstleistungen betonten, jedoch konkrete Hilfestellungen zur Einbettung in das
strategische und operative Management vermissen ließen1.
Mitte der 90er Jahre wurde der Begriff Service Engineering maßgeblich vom Stuttgarter Fraunhofer
Institut für Arbeitswirtschaft und Organisation IAO, dem Aachener Forschungsinstitut für Rationalisierung FIR sowie von der Universität Karlsruhe geprägt. Im Gegensatz zu den marketinggeprägten anglo-amerikanischen Ansätzen verfolgt Service Engineering einen methodisch orientierten Ansatz. Dabei wird versucht, ingenieurwissenschaftliches Know-how aus der klassischen
Produktentwicklung für die Gestaltung von Dienstleistungen nutzbar zu machen.
Die letzten Jahre waren durch eine Intensivierung der Forschungsaktivitäten auf diesem Gebiet
gekennzeichnet. Es entstanden zahlreiche neue Konzepte und Instrumentarien sowie entsprechende Monografien2, Studien3, Dissertationen4 und Konferenzen5 sowie eine DIN-Norm6.
4.4.2
Gestaltung von Dienstleistungen mit Vorgehensmodellen
Die /DIN-75/ definiert Service Engineering, wie folgt: Unter dem Begriff Service Engineering ist
eine Fachdisziplin zu verstehen, die sich mit der systematischen Entwicklung und Gestaltung von
Dienstleistungen unter Verwendung geeigneter ingenieurwissenschaftlicher Methoden, Vorgehensweisen und Werkzeuge beschäftigt7. Service Engineering umfasst damit insbesondere die
Entwicklungsphasen von Dienstleistungen, wobei von Beginn an der gesamte Lebenszyklus einer
Dienstleistung – von der Definitionsphase bis zur Markteinführung – in den Entwicklungsprozess
mit einbezogen wird.
Die Vorgehensmodelle im Service Engineering beschreiben die Aktivitäten, die für die Entwicklung
von Dienstleistungen notwendig sind, bestimmen deren wechselseitige Beziehung und geben
Reihenfolgen der Bearbeitung an. Vorgehensmodelle lassen sich in Phasenmodelle, iterative
Modelle und Prototyping-Modelle gliedern. In der industriellen Praxis finden Phasenmodelle die
häufigste Verwendung, da sie leicht anwendbar sind und eine hohe Prozesstransparenz bieten.
Abbildung 4-7 zeigt ein Phasenmodell zur Dienstleistungsentwicklung, das sich sowohl in der
Wissenschaft als auch in der Praxis bewährt hat. Die nächsten Kapitel beschreiben dessen einzelne Phasen.
1
2
3
4
5
6
7
Vgl. /Bull-2006 (S. 85)/.
Vgl. /Spat-2007/Bull-2006/Wild-2006a/Kink-2003/Spat-2003b/Lies-2001/.
Vgl. /Meir-2006/Meir-2006/Huse-2006/Hoec-2004/ADL-2004/Meir-2002/.
Vgl. /Hoec-2005/Herm-2000/Band-2001/Bürk-2001/.
Vgl. /Huse-2006/Spat-2004a/Spat-2003a/FIR-2007/FIR-2006/FIR-2005/BMBF-2006/BMBF-2004/.
Vgl. /DIN-75/.
Vgl. /DIN-75 (S.31)/.
Stand der Technik
- 59 -
Abbildung 4-7: Phasenmodell zur Entwicklung von Dienstleistungen1
4.4.3
Definitionsphase
Mit der Definitionsphase beginnt der Suchprozess nach neuen Dienstleistungsideen. Es gibt zahlreiche Ansatzpunkte, um neue Dienstleistungen zu definieren. Der Prozess der Ideenfindung kann
sowohl vom Kunden2 als auch im eigenen Unternehmen initiiert werden.
Zur systematischen Suche neuer Dienstleistungen eignet sich die zuvor beschriebene Methodik
des Methodischen Konstruierens nach VDI 2221 (siehe Kapitel 4.3.1) sowie die erläuterten Leitlinien des Systems Engineerings (siehe Kapitel 4.3.2). Eine weitere Möglichkeit systematisch neue
Dienstleistungen zu finden, besteht in der Bündelung bereits vorhandener Leistungen zu einem
umfassenden, auf die Kunden abgestimmten Problemlösungskonzept. Darüber hinaus bieten sich
Gespräche zur Ideenfindung unter Nutzung von Kreativitätstechniken an3.
Anschließend müssen die identifizierten Ideen selektiert und in eine kommunizierbare Form gebracht werden. Dies kann z. B. in Form einer definierten Dienstleistungsbeschreibung erfolgen.
4.4.4
Anforderungsanalyse
Die Anforderungsanalyse dient dazu, ein möglichst umfassendes Anforderungsprofil für eine
Dienstleistung zu erstellen. Dazu gilt es, die Bedürfnisse der Kunden zu ermitteln und mit den
eigenen Fähigkeiten und der Unternehmensstrategie in Einklang zu bringen. Durch die Erfassung
und Priorisierung interner und externer Anforderungen lässt sich klären, welche Eigenschaften die
Dienstleistung tatsächlich haben muss, um sowohl am Markt erfolgreich als auch im Unternehmen
1
2
3
Vgl. /Meir-2001 (S. 27)/.
Studien von Fähnrich /Fähn-2004a (S. 42)/ zufolge stammen ca. 30 Prozent der Dienstleistungsideen von Kunden.
Brainstorming, Mind-Maps, Kartenabfrage, morphologischer Kasten etc.
Stand der Technik
- 60 -
umsetzbar zu sein. Insbesondere sollen kritische Erfolgsfaktoren für die Dienstleistung rechtzeitig
erkannt und im weiteren Projektverlauf berücksichtigt werden. Zu den wichtigsten Aufgaben, die im
Rahmen der Anforderungsanalyse getätigt werden müssen, gehören die Folgenden:

Marktanalyse: Die Marktanalyse dient der Erfassung der Markt-, Unternehmens- und Umfeldsituation. Durch die Interpretation von Studien, Analysen, Veröffentlichungen etc. lassen sich
die Marktentwicklungen und -trends abschätzen. Hieraus können wirtschaftliche Marktchancen
und -risiken abgeleitet werden.

Wettbewerberanalyse: Jede neue Dienstleistung wird von potenziellen Anwendern mit konventionellen Lösungen verglichen. Ein Ansatz hierfür ist, Kriterien zur Beurteilung von Wettbewerbslösungen festzulegen und deren Eigenschaften zu gewichten, um nachfolgend die
eigene Dienstleistungsidee mit denen des Mitbewerbers zu vergleichen.

Strategische Positionierung: Das von Lay1 eingeführte Strategiechart zur Positionierung
produktbegleitender Dienstleistungen teilt die Marktbedingungen und die Kundenorientierung in
vier Quadranten ein. In jedem Quadranten sind andere Strategien zu verfolgen. Das Strategiechart ist sinnvoll, da manche Dienstleistungen gerne in Anspruch genommen werden, jedoch
hierfür Zahlungsbereitschaft besteht (siehe Abbildung 4-8).

Monetäre Klassifikationsmatrix: Die von Backhaus2 verwendete monetäre Klassifikationsmatrix zur strategischen Positionierung verfolgt ähnliche Ziele wie die von Lay. Backhaus
unterscheidet die Quadranten „Im Standardpreis enthalten“: ja oder nein und „Muss die Dienstleistung erbracht werden“: ja oder nein. Dabei kommt Backhaus zum Schluss, dass bei der
Konzeption von Dienstleistungen sehr genau überlegt werden muss, welche Dienstleistungen
man seinen Kunden anbieten möchte. Im Extremfall kann es passieren, dass durch das Anbieten und Durchführen von Dienstleistungen letztendlich Kosten verursacht werden, die sich
selbst bei einer nicht-monetären Betrachtung als nicht sinnvoll erweisen (siehe Abbildung 4-9).
preisorientiert
Feld
Feld IV
IV
Feld
Feld III
III
ProblemlösungsProblemlösungsverbilligende
verbilligende Strategie
Strategie
produktbegleitender
produktbegleitender
Dienstleistungen
Dienstleistungen
ProblemlösungsProblemlösungsoptimierende
optimierende Strategie
Strategie
produktbegleitender
produktbegleitender
Dienstleistungen
Dienstleistungen
Feld
Feld II
Feld
Feld IIII
Strategien
Strategien zum
zum Angebot
Angebot
produktbegleitender
produktbegleitender
Dienstleistungen
Dienstleistungen
greifen
greifen kaum
kaum
Sachgutverbessernde
Sachgutverbessernde
Strategie
Strategie
produktbegleitender
produktbegleitender
Dienstleistungen
Dienstleistungen
Abbildung 4-8: Strategiechart zur Positionierung produktbegleitender Dienstleistungen
1
2
Vgl. /Lay-2002 (S. 24)/Lay-1999 (S. 21)/.
Vgl. /Back-2003/VDMA-2000a (S. 24)/.
Nein
Nein
Ja
Ja
Ja
Ja
Der
Der Kunde
Kunde bekommt
bekommt
die
die Dienstleistung
Dienstleistung
heute
heute „umsonst“.
„umsonst“.
Wohl
Wohl geringe
geringe
Zahlungsbereitschaft.
Zahlungsbereitschaft.
Beispiele:
Beispiele:
-- Planung
Planung und
und
Beratung
Beratung
-- Telefonhotline
Telefonhotline
Kunde
Kunde ist
ist es
es gewohnt,
gewohnt,
separat
separat zu
zu zahlen.
zahlen.
Es
Es ist
ist zu
zu klären,
klären, wie
wie
hoch
hoch die
die ZahlungsZahlungsbereitschaft
bereitschaft ist.
ist.
Beispiele:
Beispiele:
-- 24
24 hh Ersatzteildienst
Ersatzteildienst
-- VerfügbarkeitsVerfügbarkeitsgarantie
garantie
Nein
Nein
sachgutorientiert
Im Standardpreis enthalten?
leistungsorientiert
Muss die Dienstleistung erbracht werden?
Kundenorientierung
problemlösungsorientiert
Marktbedingungen
Da
Da die
die DienstDienstleistungen
leistungen bisher
bisher
unentgeltlich
unentgeltlich erbracht
erbracht
wurden,
wurden, ist
ist unklar,
unklar, ob
ob
eine
eine ZahlungsZahlungsbereitschaft
bereitschaft besteht.
besteht.
Beispiel:
Beispiel:
-- KalkulationsKalkulationsunterstützung
unterstützung
Die
Die Zahlungs
Zahlungs
bereitschaft
bereitschaft kann
kann je
je
nach
nach Dienstleistungsart
Dienstleistungsart
unterschiedlich
unterschiedlich sein.
sein.
Beispiele:
Beispiele:
-- ProduktionsProduktionsoptimierung
optimierung
-- Recycling
Recycling
Abbildung 4-9: Strategiechart zur monetären Klassifikation
produktbegleitender Dienstleistungen
Stand der Technik
4.4.5
- 61 -
Aus der Definition allgemeiner Dienstleistungen sind drei Dimensionen ableitbar: die Leistungsbereitstellung, die Leistungserstellung und das Leistungsergebnis. Für alle drei Dimensionen sind
Konzepte und Modelle zu erarbeiten. Als Ergebnis der Dienstleistungskonzeption müssen demnach Produktmodelle, Prozessmodelle sowie Ressourcenkonzepte entstehen (siehe Abbildung
2-7).
Zur Definition der Produktmodelle eignen sich textuelle und grafische Beschreibungen sowie
Prototypen, die auch zur Kommunikation mit internen oder externen Kunden Anwendung finden
können. Zur Modellierung der Prozessmodelle eignen sich die in Kapitel 4.1 beschriebenen
Methoden zur Prozessmodellierung. Dabei sind vor allem das dort bereits beschriebene Service
Blueprinting sowie die UML-basierte Use-Case-Modellierung in der Praxis verbreitet. Unter Umständen können auch die in Kapitel 4.2 genannten Beschreibungs- und Ausführungssprachen zum
Einsatz kommen. Im Rahmen der Ausgestaltung der Ressourcenkonzepte wird der Frage nachgegangen, wie viele Personen mit welcher Qualifikation notwendig sind und welche technischen
Eigenschaften die Ressourcen benötigen.
Die meisten Literaturstellen weisen darauf hin, dass die Kundeneinbindung ein wesentlicher
Erfolgsfaktor der Dienstleistungskonzeption ist1. Der optimale Startzeitpunkt der Einbindung ist
jedoch vielschichtig und hängt von zahlreichen Kriterien ab: Bindet man den Kunden zu früh ein,
so wird er verunsichert, überfordert oder enttäuscht. Falls die Einbindung zu spät erfolgt, ist evtl.
ein Re-Design der Dienstleistung notwendig, was Zeit- und Kostennachteile mit sich bringt. Es gibt
eine Vielzahl von Methoden, wie Kunden in den Entwicklungsprozess eingebunden werden
können. In den meisten Fällen bietet sich ein Mix aus u. g. Methoden an (siehe Abbildung 4-10).
indirekt
Telefoninterview
Telefoninterview
mit
mit Experten
Experten
Kundenkontakt
Delphie-Studie
Delphie-Studie
Experteninterviews
Experteninterviews
Workshops
Workshops mit
mit
Schlüsselkunden
Schlüsselkunden //
User-Groups
User-Groups
Fragebogenaktion
Fragebogenaktion
mit
mit Anwendern
Anwendern
Interviews
Interviews mit
mit
Kunden
Kunden
Internet-KundenInternet-Kundenbefragung
befragung
Telefoninterview
Telefoninterview
mit
mit Kunden
Kunden
Fokusgruppen
Fokusgruppen
direkt
schriftlich
Intensität
Intensität des
des Kontakts
Kontakts
persönlich
2
Abbildung 4-10: Möglichkeiten der Kundeneinbindung
1
2
Vgl. /Bull-2006 (S. 141)/Huse-2005 (S. 44)/Fähn-2004a (S. 26 und S. 53)/Spat-2003b (S. 90)/Lay-2002 (S. 139)/Meir2002 (S. 40)/ Lies-2001 (S. 16)/
Vgl. /Reic-2000 (S. 37)/.
Stand der Technik
4.4.6
- 62 -
Dienstleistungsrealisierung
In der Realisierungsphase erfolgen die Umsetzung und der Test der in der Konzeptionsphase erarbeiteten Konzepte. Gegenstand der Realisierungsphase ist die Umsetzung des Dienstleistungsprodukts, der Konzeption des Dienstleistungsprozesses, der Ressourcenkonzepte sowie des
Marketingkonzepts.
4.4.7
Vorbereitung der Markteinführung
Dienstleistungsinformationen sind die Summe aller Maßnahmen und Medien, die den Käufer von
Dienstleistungen vor der Kaufentscheidung informieren. Wesentliche Leistungsbestandteile
müssen vor der Kaufentscheidung erkennbar sein, die Leistungen müssen in ihrer Qualität mit
anderen Angeboten vergleichbar und auch langfristige Konsequenzen abschätzbar sein1.
4.4.8
Markteinführung
Ein weiterer wichtiger Aspekt bei der Markteinführung ist das Controlling der Dienstleistungsqualität2. Die vom Kunden empfundene Qualität3 einer Dienstleistung besteht aus verschiedenen
Leistungsbestandteilen und äußert sich in seiner Zufriedenheit. Während beim produktbezogenen
Qualitätsbegriff die Betrachtung objektiver Kriterien, wie z. B. die Funktionsfähigkeit eines Produktes, zentral ist, wird die Qualität einer Dienstleistung von der subjektiven Wahrnehmung durch
den Kunden bestimmt.
Beim subjektiven Qualitätsbegriff steht somit der vom Kunden empfundene Grad der Ausprägung
einzelner Qualitätsmerkmale im Mittelpunkt. Die Kundenzufriedenheit ist als dabei als Ergebnis
von Vergleichsprozessen zu verstehen, bei denen Erwartungen und Ansprüche an bestimmte
Leistungen mit den aus Kundensicht wahrgenommenen tatsächlich erhaltenen Leistungen verglichen werden. Die Ursachen für mögliche Abweichung können vielfältig sein.
Zur Systematisierung möglicher Ursachen hat sich im Service Engineering das Gap-Modell4 von
Zeithaml, Berry und Parasuraman bewährt. Grundlegend für das Gap-Modell5 ist die Zweiteilung in
die Ebenen Dienstleister und Kunde. Damit lassen sich die Konfliktbereiche in der Interaktionsbeziehung zwischen Dienstleister und Kunde sowie innerhalb des Unternehmens darstellen.

Der Customer Gap bezeichnet dabei den Unterschied zwischen der Kundenerwartung und der
Kundenwahrnehmung.

Beim Information Gap besteht ein Defizit zwischen den Vorstellungen des Anbieters hinsichtlich einer optimal auf die Bedürfnisse zugeschnittenen Leistung und den tatsächlichen
Kundenwünschen.

Der Design Gap umfasst Funktionalitätsaspekte. Das Ausmaß des Information Gaps wirkt sich
maßgeblich auf das Entstehen des Design Gaps aus.
1
Vgl. /DIN-75 (S. 14)/.
Vgl. /Kink-2003/.
Qualität ist gemäß der Definition der Deutschen Gesellschaft für Qualität als die Gesamtheit von Merkmalen einer
Einheit bezüglich ihrer Eignung, festgelegte und vorausgesetzte Erfordernisse zu erfüllen, beziehungsweise als die
realisierte Beschaffenheit einer Einheit bezüglich der Qualitätsforderung, zu verstehen. Die Beschaffenheit einer Einheit kann sich auf materielle und immaterielle Objekte, d. h. Dienstleistungen, beziehen.
Vgl. /Para-1985 (S. 41)/.
Gap, englisch für Abstand, Spalte
2
3
4
5
Stand der Technik
- 63 -

Der Communication Gap rührt von einer Abweichung der im Rahmen von Marketingbotschaften o. ä. versprochenen Leistung und der real erbrachten Leistung her.

Der Fulfilment Gap stellt eine Kombination von Information-, Design- und Communication-Gap
dar, und ist als zentraler Treiber der wahrgenommenen Service-Qualität anzusehen. Werden
durch das Marketing zu hohe Erwartungen geweckt, ist der Fulfilment Gap auf den
Communication Gap zurückzuführen. Wenn jedoch der Dienstleistungserbringungsprozess
aufgrund fehlerhafter Funktionalitäten behindert oder gar abgebrochen wird, sind sowohl
Information- als auch Design Gap dafür verantwortlich.
4.4.9
Zusammenfassende Bewertung der Vorgehensmodelle des Service Engineerings
Gegenüber dem Software Engineering ist im Service Engineering die Verwendung von Vorgehensmodellen bei der Dienstleistungsentwicklung weniger verbreitet und auch weniger formalisiert.
Untersuchungen von Fähnrich1 zufolge verfügt lediglich die Hälfte der befragten Unternehmen
über ein definiertes Vorgehen. Stattdessen werden Dienstleistungen häufig ad hoc und intuitiv
unter Nutzung der Erfahrungen aus vergangenen Projekten entwickelt.
Dementsprechend sind das vorgestellte Vorgehensmodell sowie die genannten Methoden nicht als
verbindlich zu werten, sondern stellen eine mögliche Variante dar. Allerdings sind bei den bekannten Vorgehensmodellen zur Dienstleistungsentwicklung die durchzuführenden Aktivitäten
häufig vergleichbar2. Sie unterscheiden sich lediglich in deren Anordnung und Wiederholhäufigkeit.
Einen umfassenden Einblick in verschiedene Vorgehensmodelle des Service Engineerings und
eine vergleichende Bewertung geben Fähnrich3, van Husen4 oder Meiren5.
Einschränkend muss erwähnt werden, dass der vorgestellte Service-Engineering-Prozess selten
streng phasenorientiert abläuft und am Ende automatisch in eine Dienstleistung mündet, die erfolgreich am Markt platziert wird. Es kann vielmehr von einem Zusammenspiel vernetzter Zyklen ausgegangen werden. Die vorgestellten definierten Phasen greifen zeitlich und inhaltlich ineinander,
überschneiden sich und lösen sich gegenseitig aus.
1
2
3
4
5
Vgl. /Fähn-2004a (S. 39)/.
Vgl. /Bull-2006 (S. 113)/Herm-2000 (S. 30)/.
Vgl. /Fähn-2006 (Teil 4: Vorgehensmodelle, S. 12)/.
Vgl. /Huse-2006/.
Vgl. /Meir-2006/.
Stand der Technik
- 64 -
4.5 Vorgehensmodelle des Software Engineerings
4.5.1
Herkunft des Software Engineerings
Der Begriff Software Engineering wurde bei der NATO-Konferenz in Garmisch im Jahr 1968 geprägt und war als Provokation gedacht. Der Begriff sollte betonen, dass die Entwicklung von Software eine Ingenieur-Disziplin und nicht primär eine künstlerische Leistung ist. Softwareentwicklung
sollte sich als industrielle Fertigung verstehen. Fast 40 Jahre später hat das Software Engineering1
seine feste Stelle als Teilgebiet der Informatik gefunden. Allerdings sind die Definitionen von Software Engineering nicht einheitlich. In dieser Arbeit wird die Definition von Balzert2 verwendet, der
das Gebiet wie folgt definiert: Software Engineering beschreibt die zielorientierte Bereitstellung und
systematische Verwendung von Prinzipien, Methoden und Werkzeugen für die arbeitsteilige,
ingenieurmäßige Entwicklung und Anwendung von umfangreichen Softwaresystemen.
4.5.2
Gestaltung von Software mit Vorgehensmodellen
Der Entwicklungsprozess von systematisch entwickelter Software ist komplex und umfasst eine
Vielzahl von Teildisziplinen der Informatik sowie des Projektmanagements. Analyse, Entwurf,
Implementierung und Tests werden meist als Kernprozesse der Softwareentwicklung angesehen,
während hingegen Projektmanagement, Qualitätsmanagement und Konfigurationsmanagement als
Unterstützungsprozesse verstanden werden3. Die Disziplinen sind während des ganzen Entwicklungsprozesses eng miteinander verzahnt.
Im Software Engineering existieren vielfältige Vorgehensmodelle, angefangen beim Wasserfallmodell, bei dem alle Phasen streng sequenziell abgearbeitet werden, bis hin zu evolutionär
iterativen Ansätzen, bei denen die Phasen mehrfach durchlaufen werden, bis ein Ergebnis vorliegt,
das den Anforderungen entspricht. Die zeitliche Anordnung der Phasen wie auch die Phasenübergänge ist häufig abhängig von der eingesetzten Modellierungsmethode. Bei objektorientierten Vorgehensweisen ist eine scharfe Trennung zwischen den Phasen nicht immer möglich.
4.5.3
Wasserfallmodell
Das Wasserfallmodell stammt aus dem Jahr 1956 und ist eines der ältesten Prozessmodelle in der
Softwareerstellung. Es stammt von Benington und wurde im Jahr 1970 von Royce weiterentwickelt.
Die Charakteristika des Wasserfallmodells sind:

Aktivitäten sind in der richtigen Reihenfolge und in vollständigem Umfang durchzuführen.

Am Ende jeder Aktivität steht ein Dokument.

Der Entwicklungsablauf ist sequenziell; eine vorhergehende Aktivität muss beendet sein, bevor
die nächste beginnt.

Es orientiert sich am Top-Down-Vorgehen.

Es ist einfach, verständlich und erfordert wenig Managementaufwand.

Die Benutzerbeteiligung erfolgt nur in der Definitionsphase.
1
2
3
Software Engineering, englisch für Softwaretechnik
Vgl. /Balz-2001 (S. 36)/.
Vgl. /VMod-2006/Mang-2004/Balz-2001/.
Stand der Technik
- 65 -
Damit gehört das Wasserfallmodell den phasenorientierten Softwareentwicklungsprozessen an,
die eine strikte Reihenfolge für die einzelnen Phasen des Softwareentwicklungsprozesses
definieren. Erst wenn eine Phase vollständig abgearbeitet ist, wird die nächste Phase begonnen.
4.5.4
Spiralmodell
Das Spiralmodell ist ein Vorgehensmodell, das im Jahr 1988 von Boehm1 beschrieben wurde. Es
erlaubt die freie, problembezogene Kombination aller bereits existierenden Ansätze. Das Spiralmodell fasst den Entwicklungsprozess im Software Engineering als iterativen Prozess auf, wobei
jeder Zyklus folgende Aktivitäten enthält:

Phase 1: Festlegung von Zielen, Alternativen und Rahmenbedingungen.

Phase 2: Evaluierung der Alternativen, Erkennen und Reduzieren von Risiken.

Phase 3: Realisierung und Überprüfung des Zwischenprodukts.

Phase 4: Planung der Projektfortsetzung.
Am Ende jedes Spiralzykluses steht eine Risikoanalyse beziehungsweise ein Review2, in dem der
Projektfortschritt bewertet wird. Das Spiralmodell ist damit ein Modell, bei dem das oberste Ziel die
Minimierung des Risikos ist (siehe Abbildung 4-11).
Abbildung 4-11: Spiralmodell zur Softwareentwicklung
1
2
Vgl. /Boeh-1988 (S. 61)/.
Review, englisch für Überprüfung, Rückblick, Nachbereitung
Stand der Technik
4.5.5
- 66 -
Unified Process (UP) und Rational Unified Process (RUP)
Der Unified Process (UP) wurde parallel zur Unified Modeling Language (siehe Kapitel 4.1.3) von
Jacobson, Booch und Rumbaugh entwickelt und im Jahr 1999 vorgestellt1. Der Unified Process
und der um Softwaremanagementprozesse erweiterte Rational Unified Process (RUP)2 sind Use
Case getrieben, architekturzentriert, iterativ und inkrementell. Sowohl beim UP als auch beim RUP
dienen Use Cases als Grundlage für alle Entwicklungsschritte der Softwareentwicklung. Eine
weitere tragende Rolle spielt die Software-Architektur, die frühzeitig entworfen wird und aktuelle
und künftige Erweiterungen bereits berücksichtigt.
Der Entwicklungszyklus gliedert sich in vier Phasen (siehe Tabelle 4-2). Diese Phasen sind in
Iterationen unterteilt, weshalb der UP zu den iterativ/inkrementellen Softwareentwicklungsprozessen zählt. Resultate jeder Phase sind die sogenannten Meilensteine:
Phase
Inhalt
Einstieg
In der Einstiegsphase wird eine Vision des zu konzipierenden Softwaresystems
bezüglich seines Funktionsumfangs und der abzudeckenden Use Cases erstellt.
Ausarbeitung
Die Ausarbeitungsphase hat die schrittweise Verfeinerung und Implementierung
der Kernarchitektur zum Ziel. Komponenten mit hohem Risiko (in funktionaler
wie in technologischer Hinsicht) werden vorab realisiert. Die wesentlichen
funktionalen und technischen Anforderungen werden identifiziert und modelliert.
Konstruktion
In der Konstruktionsphase wird das vollständige Softwaresystem iterativ
implementiert und getestet. Ferner erfolgt die Vorbereitung für die Inbetriebnahme.
Überleitung
In der Überleitungsphase erfolgen Tests sowie die Übergabe an die Anwender.
1
Tabelle 4-2: Softwareentwicklungsphasen des Unified Process
Jede dieser vier Phasen enthält Elemente der fünf Kernprozesse: Vision und Anforderungen, Analyse, Design, Implementierung und Test. Dadurch steht der UP im Kontrast zu den phasenorientierten Modellen, die Anforderungsanalyse, Design, Implementierung und Test einmalig in
genau dieser Reihenfolge und strikt sequenziell abarbeiten3.
4.5.6
V-Modell XT
Das V-Modell XT4 wurde im Auftrag des Bundes entwickelt und im Jahr 2004 fertiggestellt. Das
V-Modell XT ist eine Weiterentwicklung des im Jahr 1997 veröffentlichten V-Modells 97.
Das wesentliche Prinzip des aktuellen V-Modells enthält die modularen, aufeinander aufbauenden
Vorgehensbausteine. Jeder Vorgehensbaustein ist eine eigenständige Einheit und einzeln änderbeziehungsweise erweiterbar. Jeder Vorgehensbaustein korrespondiert mit einer konkreten Aufgabenstellung. Ein Vorgehensbaustein kapselt dabei diejenigen Produkte, Aktivitäten und Rollen,
die für die Erfüllung dieser Aufgabenstellung relevant sind und damit inhaltlich zusammengehören.
1
2
3
4
Vgl. /Jaco-1999/.
Der Rational Unified Process (RUP) ist ein kommerzielles Produkt der Firma Rational Software, die seit dem Jahr
2002 Teil von IBM ist. Der RUP benutzt die Unified Modeling Language als Notationssprache.
Vgl. /Zuse-2004/.
Zurzeit aktuell ist das V-Modell XT in der Version 1.2 /VMod-2006/.
Stand der Technik
- 67 -
Als Produkte werden im V-Modell die zu erarbeitenden Ergebnisse und Zwischenergebnisse bezeichnet. Ein Vorgehensbaustein besteht aus folgenden Elementen:

Die Gesamtheit aller Produkte wird hierarchisch strukturiert, indem inhaltlich zusammengehörende Produkte zu Produktgruppen zusammengefasst werden. Darüber hinaus kann ein
komplexes Produkt in mehrere Themen gegliedert sein.

Jedes Produkt wird von genau einer Aktivität fertiggestellt. Die Art und Weise, wie die einzelnen Produkte zu bearbeiten sind, ist in den Aktivitäten festgelegt. Auch die Aktivitäten eines
Vorgehensbausteins sind hierarchisch strukturiert. Inhaltlich verwandte Aktivitäten, die zusammengehören, werden dabei zu Aktivitätsgruppen zusammengefasst.

Eine Rolle kapselt eine Menge von Aufgaben und Verantwortlichkeiten. Durch das Konzept der
Rolle bleibt das V-Modell unabhängig von organisatorischen Rahmenbedingungen. Erst zu
Beginn eines Projektes werden den einzelnen Rollen konkrete Personen oder Organisationseinheiten zugeordnet.
Ein Vorgehensbaustein gibt somit vor, was in einem konkreten Projekt zu tun ist, also welche
Produkte zu erstellen und welche Aktivitäten durchzuführen sind. Darüber hinaus legt der
Vorgehensbaustein fest, wer beziehungsweise welche Rolle für welches Produkt verantwortlich ist.
4.5.7
Prototypenmodell
Das Prototypenmodell wird in der Literatur auch Prototyping genannt und bezeichnet ein iteratives
Verfahren, bei dem die wesentlichen Schritte mehrfach durchlaufen werden, bis die gewünschte
Qualität erreicht ist. Man unterscheidet drei Prototypenarten:

Experimentelles Prototyping: Zur Beurteilung bestimmter Problemlösungen. Ziel ist es nachzuweisen, dass Spezifikationen oder Ideen tauglich sind.

Exploratives Prototyping: Zum Zweck der Forschung wird mit einem explorativen Prototyp
eine sehr umfangreiche Problemanalyse und Systemspezifikation durchgeführt.

Evolutionäres Prototyping: Hierbei wird die Funktionalität schrittweise, evolutionär erweitert,
wobei der nächste Schritt von der Rückkopplung z. B. der Nutzer abhängt. Dabei wird der
Prototyp lauffähig gehalten und stetig bis zur Produktreife weiterentwickelt.
Ein wesentlicher Grundsatz des Prototypenmodells ist die Einbeziehung der späteren Nutzer in die
Entwicklung eines Softwareprogramms. Beim evolutionären Prototyping testen die Nutzer immer
wieder die Zwischenstände der Programmentwicklung. Dies führt oft zu neuen oder geänderten
Anforderungen, die dann in der folgenden Implementierungsphase in ein verbessertes Programm
einfließen. Indem sich die Kommunikation auf ein gemeinsames und anschauliches Objekt, den
Prototypen, bezieht, lassen sich die Kommunikationsprobleme zwischen Softwareentwicklern und
späteren Programmnutzern reduzieren1.
Man unterscheidet horizontale und vertikale Prototypen. Beim vertikalen Prototyping werden nur
Teilbereiche einer Software implementiert, diese dafür jedoch vollständig. Beim horizontalen Prototyping hingegen wird die ganze Funktionalität dargestellt, z. B. in Form einer Benutzeroberfläche,
diese jedoch nur teilweise realisiert (siehe Abbildung 4-12).
Prototypen reduzieren das Entwicklungsrisiko und ermöglichen eine intensive Rückkopplung
zwischen dem Auftraggeber beziehungsweise Endbenutzer und dem Entwickler einer Software.
1
Vgl. /Fähn-2004a/.
Stand der Technik
- 68 -
Damit sinkt das Risiko einer Fehlentwicklung. Allerdings verleitet das Prototyping dazu, Anforderungen weder korrekt zu erheben noch zu dokumentieren. Der Entwicklungsprozess kann
sich dadurch u. U. erheblich verlangsamen.
Abbildung 4-12: Horizontaler und vertikaler Prototyp
4.5.8
Zusammenfassende Bewertung der Vorgehensmodelle des Software Engineerings
Alle beschriebenen Vorgehensmodelle des Software Engineerings haben ihre Vor- und Nachteile.
Die streng phasenorientierten Ansätze sind lediglich für Projekte mit fest definierten Anforderungen
geeignet, da nach Abschluss der Spezifikationsphase keine Spezifikationsänderungen erfolgen
dürfen. Dabei besteht die Gefahr, dass in späteren Projektphasen Hürden auftreten, welche die
Realisierung des Gesamtsystems in Frage stellen.
Das Spiralmodell hebt einige dieser Beschränkungen auf, ist jedoch an eine starre Abfolge der vier
Phasen innerhalb jedes Spiralzykluses gebunden.
Iterative Ansätze wie der Unified Process und das V-Modell XT ermöglichen durch die schrittweise
Analyse, Modellierung und Implementierung einzelner Komponenten und Subsysteme eine
größere Flexibilität bezüglich sich ändernder Anforderungen, der Ausschaltung technischer Risiken
und der frühzeitigen Fertigstellung von Teilprototypen. Allerdings handelt es sich hierbei um
schwergewichtige Entwicklungsprozesse. Zwei Beispiele: Die Dokumentation des V-Modell XT1
umfasst 643 Seiten, die Unified Modeling Language-Superstructure2 ist 772 Seiten stark. Unter
Praktikern gilt UML – spätestens seit Einführung der Version 2.0 – daher als zu umfangreich und
zu unhandlich3. Ohne entsprechende CASE-Tools sind diese Vorgehensmodelle nicht mehr zu
beherrschen4.
1
2
3
4
Vgl. /VMod-2006/.
Vgl. /OMG-2006a/.
Prof. Heinrich Mayr, der frühere Präsident der Gesellschaft für Informatik (GI), formulierte die heutige Situation auf
der OOP-Konferenz in München am 23.01.2007, wie folgt: „Bei der Methodenentwicklung ist es wie bei den Baustilen: Es beginnt bei der Klassik, klar und einfach, dann kommt man über Romanik und Gotik zur Renaissance und
schließlich zum verspielten Rokoko. Dann erkennt man, dass Einfachheit vorteilhafter wäre und kommt zum
Klassizismus – ein Kreislauf. Wir sind im Moment dabei, wieder einfacher zu werden.“
Computer-Aided Software Engineering (CASE), englisch für computergestützte Unterstützung des gesamten Softwareentwicklungsprozesses. CASE-Tools sind Werkzeuge, die den Softwareentwickler bei der Planung, dem Entwurf, der Implementierung und der Dokumentation unterstützen. Ein wichtiger Bestandteil der meisten CASE-Tools
ist die Unified Modeling Language.
Stand der Technik
- 69 -
Nicht unerwähnt bleiben sollte auch die Rolle der Softwareanbieter von Vorgehensmodellen. Nur
allzu gerne stellen Anbieter gerade ihr – selbstverständlich kostenpflichtiges Modell – als das Allheilmittel für alle Probleme dar. Allerdings ist selbst bei der exakten Anwendung der
Vorgehensmodelle und der korrekten Abarbeitung aller vorgegebenen Checklisten das Projektziel
keinesfalls sichergestellt. Im Gegenteil besteht bei der Anwendung die Gefahr, dass sich der
Fokus von den Kundenwünschen und Projektzielen auf die Einhaltung der vorgeschriebenen
formalen Anforderungen verlagert. In der Praxis werden deshalb vor allem eigenentwickelte
Vorgehensmodelle zur Softwareentwicklung genutzt, die sich an existierende Phasenmodelle anlehnen1. Tabelle 4-3 und Tabelle 4-4 zeigen eine vergleichende Bewertung der Vorgehensmodelle.
Hoffnungen, die Softwareentwicklungsprozesse nachhaltig zu steigern, wecken die in Kapitel 4.2
beschriebenen Beschreibungs- und Ausführungssprachen. Die Einführung einer höheren
Abstraktionsebene soll das Verständnis für ein Softwaresystem verbessern. Das Verfahren stößt
aber auch auf Kritik, da es meist höheren Aufwand bedeutet und nicht immer Effizienzgewinne
bringt. Mitunter wird auch bemängelt, dass sich nur Teile des Applikationscodes automatisch aus
Modellen generieren lassen. Für eine Vielzahl von Anwendungsfällen sind ohnehin manuelle
Implementierungsarbeiten notwendig, da selbst eine komplexe Sprache im Einzelfall nicht ausreicht, um zufriedenstellende Modelle zu entwerfen.
Eigenschaft
Wasserfallmodell
Spiralmodell
Unified
Process
V-Modell XT
Prototypenmodell
Typ
sequenziell
evolutionär /
iterativ
iterativ /
inkrementell
evolutionär /
iterativ
evolutionär /
iterativ
Komplexität
gering
mittel
hoch
hoch
gering
Vollständigkeit
mittel
mittel
hoch
hoch
gering
Modularität
gering
hoch
hoch
hoch
gering
Systematik
hoch
hoch
hoch
hoch
gering
Allgemeingültigkeit
gering
mittel
hoch
hoch
hoch
Anpassbarkeit
gering
mittel
hoch
hoch
hoch
Rechnerunterstützung
mittel
mittel
bei RUP hoch
hoch
gering
Benutzerpartizipation
gering
hoch
hoch
mittel
hoch
Verbreitung
mittel
gering
gering
gering
hoch
Tabelle 4-3: Vergleichende Gegenüberstellung der Eigenschaften von Vorgehensmodellen
1
2
2
Fähnrich berichtet, dass alle in der Studie /Fähn-2004a (S. 30)/ befragten Unternehmen Vorgehensmodelle zur Softwareentwicklung anwenden.
Vgl. /Spec-2005 (S. 52 und S. 58)/Huse-2005 (S. 64)/.
Stand der Technik
Bewertung
Nachteile
- 70 -
Wasserfallmodell
keine Berücksichtigung des
Risikos
vollständige
Durchführung aller
Schritte nicht
immer sinnvoll
Gefahr einer
falschen
Prioritätsverteilung
(Dokumenten getriebenes
System)
Vorteile
abgeschlossene
Einheiten
definierte
Ergebnisse
Spiralmodell
Risikoabschätzung
schwierig
komplexe
Projektsteuerung
komplexe
Risikoanalyse
hoher
Management
aufwand
ungeeignet
für kleine
und mittlere
Projekte
frühe Überprüfung der
Benutzeranforderungen
für Neuentwicklung und
Wartung anwendbar
Fehler und
ungeeignete
Alternativen
werden frühzeitig identifiziert
Unified
Process
schwergewichtig
formalisierter
Entwicklungsprozess
geringere
Flexibilität
und deutlich
längere
Wartezeiten
auf den
ersten Prototyp
V-Modell XT
sehr aufwendig
unrealistische
Rollendefinition
(außer für
Großprojekte)
ohne
CASE-Unterstützung
nicht handhabbar
hohe Beschreibungskomplexität
in der
Dokumentation fehlen
vollständige
Beispiele
durch die
Betonung
der Use
Cases und
das iterative
Vorgehen
berücksichtigt er die
Anforderungen
der späteren
Nutzer
generisches
Vorgehensm
odell mit
definierten
Möglichkeiten der
Anpassung
Toolunterstüt
zung ist gegeben
Vgl. /Spec-2005 (S. 52 und S. 58)/Huse-2005 (S. 64)/.
fehlende
Vorgaben für
strukturierten
Projektablauf
höherer Entwicklungsaufwand
schwierige
Zielkontrolle
Gefahr der
Integration
eines
WegwerfPrototyps im
Produkt
iterative
Programmentwicklung
unterstützt
Rollenkonzepte
unterstützt
Simultaneous beziehungsweise
Concurrent
Engineering
gut geeignet
für große
Projekte
frühzeitige
Benutzerpartizipation
Tabelle 4-4: Vergleichende Bewertung von Vorgehensmodellen für das Software Engineering1
1
Prototypenmodell
Stand der Technik
- 71 -
4.6 Parallele Gestaltung von Software und Dienstleistungen
4.6.1
Computer Aided Service Engineering
Im Rahmen des vom Bundesministerium für Bildung und Forschung (BMBF) geförderten Projekts
„CASET - Computer Aided Service Engineering Tool“1, das von 2001 bis 2004 andauerte, erarbeitete das Fraunhofer IAO zusammen mit dem Institut für Wirtschaftsinformatik am DFKI ein
integriertes Rahmenkonzept und eine Werkzeugumgebung für die systematische Entwicklung und
Gestaltung von Dienstleistungen für den Finanzsektor.
4.6.2
Computer Aided Service Engineering für IT-basierte Dienstleistungen
Im Rahmen des vom Bundesministerium für Bildung und Forschung (BMBF) geförderten Projekts
„ServCase – Computer Aided Engineering für IT-basierte Dienstleistungen“, das im Jahr 2003
startete und bis zum Jahr 2006 lief, forschten das Fraunhofer IAO gemeinsam mit dem Institut für
Informatik (IfI) der Universität Leipzig am „Co-Design von Software und Services“. Die Arbeiten
sind in den Jahren 2004 und 2005 publiziert worden2. Parallel dazu wird am IfI die Vorlesung
Engineering IT-basierter Dienstleistungen gehalten (siehe Abbildung 4-13)3.
Abbildung 4-13: Co-Design von Software und Services4
4.6.3
Zusammenfassende Bewertung der parallelen Gestaltung von Software und Dienstleistungen
In der Wissenschaft sowie in der Praxis hat man sich bislang nur rudimentär mit Vorgehensmodellen befasst, welche die parallele Entwicklung von Software und Dienstleistungen oder gar
internetbasierten Mehrwertdiensten für den Maschinen- und Anlagenbau zum Gegenstand haben.
Van Husen et al.5 sieht einen Grund hierfür darin, dass Personen, die sich mit der ingenieurmäßigen Softwareentwicklung befassen, nur in seltenen Fällen dienstleistungsbezogene Aspekte
betrachten. Und umgekehrt sehen Personen mit betriebswirtschaftlichem Hintergrund Dienstleistungen eher aus der Marketing- und Management- als aus der IT-Sicht. Ein weiterer Grund liegt
1
2
3
4
5
Vgl. /Sche-2004/.
Vgl. /Huse-2005/Fähn-2004a/Fähn-2004b/.
Vgl. /Fähn-2006/.
Vgl. /Fähn-2006 (Teil 1: Einführung, S. 8)/.
Vgl. /Huse-2005 (S. 25)/.
Stand der Technik
- 72 -
darin, dass erst vor wenigen Jahren die Industrieautomation damit begonnen hat, von proprietären
Busprotokollen auf offene ethernet-basierte Protokolle umzusteigen. Dieser Wandlungsprozess
wird als drittes Zeitalter der Industrieautomation bezeichnet und dient einerseits der Komplexitätsbewältigung durch Dezentralisierung sowie zur Unterstützung der Standardisierung und Wiederverwendbarkeit von Softwarekomponenten (siehe Kapitel 6.6).
Wenngleich alle o. g. Arbeiten und Konzepte interessant erscheinen, darf darauf hingewiesen
werden, dass es sich dabei um Projekte und nicht um bewährte Vorgehensmodelle handelt.
Darüber hinaus fokussiert keine der o. g. Arbeiten die spezifischen Randbedingungen produktbegleitender Dienste im Maschinenbau.
4.7 Zusammenfassende Bewertung der Vorgehensmodelle zur Gestaltung von
Mehrwertdiensten
In Tabelle 4-5 sind die in Kapitel 4 vorgestellten Vorgehensmodelle den in Kapitel 3 entwickelten
Anforderungen gegenübergestellt.
Wie der Tabelle zu entnehmen ist, deckt keines der in der Literatur beschriebenen
Vorgehensmodelle die Anforderungen zur Gestaltung internetbasierter Mehrwertdienste für den
Maschinen- und Anlagenbau vollständig ab.
Legende
Spiralmodell
Unified Process
V-Modell XT
Prototyping
Computer Aided Service Engineering
Computer Aided Engineering für
IT-basierte Dienstleistungen
Projekt
ServCase
Wasserfallmodell
Projekt
CASET
Service Engineering
Konzeption
Informationstechnik
Software
Engineering
Systems Engineering
Service
Engineering
Projektorganisation
Projektplanung und -steuerung
Qualitätssicherung
Konfigurationsmanagement
Problem- und Änderungsmgt.
–
–
–
–
–
–
–
–
–
–
Ø
Ø
Ø
Ø
Ø
Ø
Ø
Ø
Ø
Ø
Ø
+
+
Ø
Ø
Ø
+
+
+
Ø
+
+
+
+
+
–
–
–
Ø
Ø
Ø
Ø
Ø
Ø
Ø
Ø
Ø
Ø
Ø
Ø
Dienstleistungsdefinition
Anforderungsanalyse
Dienstleistungskonzept
Dienstleistungsrealisierung
Markteinführung
–
+
–
–
–
–
+
Ø
–
–
+
+
+
+
+
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
+
+
+
+
+
+
+
+
+
Ø
Internet-Infrastruktur
Hardware-Architektur
Software-Architektur
Softwaretechnologien
Komponenten-Prinzip
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
+
–
–
+
–
+
Ø
Ø
Ø
Ø
+
Ø
+
Ø
Ø
Ø
+
Ø
+
+
+
Ø
Ø
+
+
+
Anforderungskategorien
Projektmanagement
Konventionelle
Vorgehensmodelle
Methodisches Konstruieren VDI 2221
Vorgehensmodelle
+ erfüllt
Ø teilweise erfüllt
Tabelle 4-5: Gesamtbeurteilung der vorgestellten Vorgehensmodelle
- nicht erfüllt
Stand der Technik
- 73 -
Für konventionell erbrachte Dienstleistungen eignen sich die Vorgehensmodelle des Service
Engineerings. Diese Vorgehensmodelle sind sowohl in der Wissenschaft als auch in der Praxis
anerkannt und unter anderem in Publikationen von Bullinger1, Lay2, Luczak3, Meier4, Meiren5 und
Spat6 beschrieben. Es existieren Gemeinsamkeiten zwischen konventionell erbrachten und internetbasierten Dienstleistungen. Für die Definitionsphase und Teile der Anforderungsanalyse fernerbrachter Dienste eignen sich die Ansätze und Methoden des Service Engineerings. Die
Kundenwünsche und -anforderungen sind zunächst unabhängig von der Art und Weise, wie
Dienstleistungen technisch erbracht werden.
Bei der Konzeption und Realisierung internetbasierter Mehrwertdienste spielen die technischen
Prozess- und Ressourcenkonzepte naturgemäß eine wichtige Rolle. Hierzu gehören unter
anderem Hard- und Software, Architektur, Infrastruktur und Datenmodelle. Das konventionelle
Service Engineering enthält jedoch keine Ansätze zur technischen Konzeption, Realisierung und
Erbringung. Da die technische Gestaltung der Prozesse und Ressourcen jedoch für internetbasierte Mehrwertdienste ein besonders kritischer, komplexer und damit wichtiger Vorgang ist, bedarf das Service Engineering der Ergänzung.
Für die reine Softwareentwicklung stehen ebenfalls umfangreiche Vorgehensmodelle7 und
Literatur8 zur Verfügung. Software Engineering ist seit Jahrzehnten ein Teilgebiet der Informatik
und wird entsprechend in Hochschulen und in der Berufsausbildung gelehrt. Studien von Fähnrich9
zeigen, dass Software Engineering nicht nur in der Theorie existiert, sondern Eingang in die
industrielle Praxis gefunden hat. Nahezu alle Unternehmen nutzen heute Vorgehensmodelle für
die Softwareentwicklung.
Die Gestaltung von internetbasierter Software unterscheidet sich von der üblichen Client-ServerSoftware in Bezug auf die Infrastruktur des Netzwerks, den vorhandenen Protokollen und den erhöhten IT-Sicherheitsanforderungen etc. Das gesamte 6. Kapitel widmet sich der IT zur Erbringung
internetbasierter Mehrwertdienste, sodass auf eine tiefer gehende Erörterung hier verzichtet wird.
Die beschriebenen Projekte zur parallelen Gestaltung von Software und Dienstleistungen enthalten
interessante Aspekte. Es handelt sich jedoch dabei um Projekte und nicht um bewährte
Vorgehensmodelle. Darüber hinaus weisen die Projekte keinen Bezug zum Maschinen- und Anlagenbau auf.
Zusammenfassend lässt sich daher festhalten, dass Vorgehensmodelle zur systematischen Gestaltung internetbasierter Mehrwertdienste für den Maschinen- und Anlagenbau bisher weder in
der
Forschung
noch
in
der
Praxis
vorhanden
sind10.
1
2
3
4
5
6
7
8
9
10
Vgl. /Bull-2006/.
Vgl. /Lay-2005/Lay-2002/Lay-2001/Lay-2000/Lay-1999/.
Vgl. /Lucz-2004/Lucz-2000/.
Vgl. /Meie-2006a/Meie-2005/Meie-2004b/.
Vgl. /Meir-2006/Meir-2001/Meir-2002/.
Vgl. /Spat-2007/Spat-2004a/Spat-2004b/Spat-2003a/Spat-2003b/.
Vgl. /Boeh-1988/Jaco-1999/Zuse-2004/VMod-2006/.
Vgl. /Reus-2006/Mang-2004/Weis-2002/Balz-2001/Hein-2001/Weis-2000/.
Vgl. /Fähn-2004a/Fähn-2004b/.
Vgl. /Fähn-2004a (S. 21)/Meie-2004b/Mert-2004/VDI-2001/Herm-2000 (S. 45)/.
5 Zielsetzung, Lösungsansatz und Methodik
Es ist nicht gesagt, dass es besser wird, wenn es anders wird.
Aber wenn es besser werden soll, muss es anders werden.
Georg Christoph Lichtenberg
Naturgelehrter und Schriftsteller
Gegenstand dieses Kapitels ist die Beschreibung der Zielsetzung, des grundsätzlichen Lösungsansatzes sowie der Methodik, die dieser Arbeit zugrunde liegen.
5.1 Zielsetzung
Im Kapitel 2.3 wurde gezeigt, dass in der Investitionsgüterindustrie ein dringender Forschungsund Entwicklungsbedarf besteht, internetbasierte Mehrwertdienste kostenbewusst zu entwickeln,
qualitativ hochwertig herzustellen sowie schnell in Betrieb zu nehmen. Eine Folge des bisher nicht
gedeckten Bedarfs ist in Form von Defiziten heutiger internetbasierter Mehrwertdienste sichtbar.
Diese sind in Kapitel 2.5 aufgeführt.
Eine spezifische Problemstellung in der Gestaltung internetbasierter Dienste liegt in den Interdependenzen zwischen einer Dienstleistung, der hierfür notwendigen Software und dem zugehörigen Projektmanagement. Die Spezifikation einer Dienstleistung hat nicht nur Einfluss auf die
Spezifikation der Informationstechnik, sondern auch umgekehrt muss die Machbarkeit und Sicherheit einer Softwarelösung bei der Dienstleistungskonzeption Berücksichtigung finden.
Es bedarf demnach einer Synchronisierung des Service Engineerings und des Software
Engineerings. Je intensiver Dienstleistung und Software dabei inhaltlich miteinander verknüpft
sind, umso notwendiger ist ein integrierter Entwicklungsprozess für beide Komponenten (siehe
Abbildung 5-1).
E-Service Engineering
Projektmanagement
SoftwareEngineering
Abbildung 5-1: Zielsetzung der Arbeit
ServiceEngineering
Zielsetzung, Lösungsansatz und Methodik
- 75 -
Um internetbasierte Mehrwertdienste effektiv und effizient zu entwickeln sowie permanent an
Kundenanforderungen, Marktgegebenheiten und technologische Entwicklungen anpassen zu
können, eignen sich anforderungsgerechte Vorgehensmodelle. Diese unterstützen eine effiziente
und effektive Projektplanung und Gestaltung von Dienstleistungen über alle Entwicklungsphasen
hinweg. Wie die Erkenntnisse aus dem in Kapitel 4 dargestellten Stand der Technik zeigen, verfügt
bisher kein dem Autor bekanntes Vorgehensmodell über Ansätze zur Gestaltung internetbasierter
Mehrwertdienste. Bisher veröffentlichte Arbeiten beschäftigen sich entweder mit der Realisierung
von Einzelaspekten des Software Engineerings oder des Service Engineerings.
Das zu erarbeitende Vorgehensmodell soll die Gestaltung internetbasierter Dienste erleichtern, indem es ein integriertes Vorgehen in Bezug auf die Aspekte des Projektmanagements, des Service
Engineerings und des Software Engineerings aufweist und vor dem Hintergrund der technologischen Möglichkeiten und Internetstandards in ein gesamtes Vorgehensmodell überführt.
Service und Software Engineering sollen sich dabei ergänzen. Das zu schaffende
Vorgehensmodell soll dabei so allgemeingültig formuliert werden, dass es für eine möglichst große
Bandbreite internetbasierter Dienstleistungen angewendet werden kann.
Die integrierte Berücksichtigung der Aspekte des Service Engineerings, des Software
Engineerings und des Projektmanagements wird im Folgenden als E-Service Engineering bezeichnet. Der Begriff E-Service Engineering lehnt sich an den Begriff Service Engineering an, der
die systematische Entwicklung und Gestaltung von Dienstleistungen unter Verwendung geeigneter
ingenieurwissenschaftlicher Methoden, Vorgehensweisen und Werkzeuge zum Gegenstand hat.
Der Unterschied zwischen dem Service Engineering und dem E-Service Engineering liegt
demnach in der unterschiedlichen Form der Dienstleistungserbringung.
5.2 Lösungsansatz
5.2.1
Verwendung von Komponenten zum Aufbau von IT-Systemen
Die Erfahrung zeigt, dass die kundenindividuelle Softwareentwicklung auch bei Einsatz moderner
Entwicklungsmethoden und -werkzeuge in vielen Fällen die Anforderungen nur unzureichend erfüllt1. Die Hauptursachen für nicht termingerechte Fertigstellung, geringe Qualität, hohe Entwicklungs- und Wartungskosten von Softwaresystemen liegen in deren Komplexität.
Bei der klassischen Softwareentwicklung werden Softwaresysteme Top-Down so lange zerlegt, bis
man sie in Form von Kleinstbausteinen, d. h. in den Anweisungen einer Programmiersprache,
realisieren kann. Vergleicht man dazu die Vorgehensweise in anderen Ingenieurbereichen, stellt
man fest, dass dort die früher verwendeten Kleinstbausteine in sehr vielen Bereichen durch vorgefertigte Komponenten, Baugruppen oder Module ersetzt wurden, um die Komplexität der auch
dort vorhandenen großen Systeme zu reduzieren.
Wie auch in anderen Industriezweigen muss auch bei der Erstellung von Software auf vorgefertigte, wiederverwendbare Bausteine zurückgegriffen werden. Die aus den Ingenieurwissenschaften übernommene komponentenbasierte Gestaltung wird heute mit zunehmendem Erfolg
auch in der Softwareentwicklung eingesetzt. Ziel ist, Software nicht mehr kundenindividuell zeilenweise zu programmieren, sondern aus vorgefertigten, geprüften Bausteinen zu montieren. Die
Verwendung von Softwarekomponenten ist ein wichtiger Beitrag zur Gestaltung internetbasierter
Dienste.
1
Vgl. /Göhn-2004a/Göhn-2004b/Stan-2006/Stan-1994/.
- 76 -
Die Vorteile liegen in einer besseren Struktur des Gesamtsystems sowie in der gesteigerten
Wiederverwendung. Die verschiedenen Komponenten des Gesamtsystems können unabhängig
voneinander und damit parallel entwickelt werden. Durch den Einsatz vorhandener Komponenten
ergeben sich darüber hinaus Zeit- und Kostenvorteile. Unterstützt werden die Ansätze durch die
Verwendung von käuflichen Komponenten, die aufgrund von Mehrfachverwendung wirtschaftlich
entwickelt und vertrieben werden können. Die Mehrfachverwendung von Komponenten führt
darüber hinaus zu einer Erhöhung der Qualität, da evtl. vorhandene Fehler schneller erkannt
werden, und zugleich zur Reduzierung des Wartungsaufwandes, da Änderungen immer nur an
einer Stelle geändert werden müssen. Komponenten führen demnach zu Zeit-, Qualitäts- und
Kostenvorteilen bei der Softwareentwicklung und erleichtern darüber hinaus die Aufwandsabschätzungen.
5.2.2
Spezifikation einer anforderungsgerechten Internetservice-Plattform
In der Forschung und der Industrie vollzieht sich seit Jahren ein Trend von monolithischen
Systemen hin zu mehrschichtigen Architekturen. Monolithische Applikationen zeichnen sich
dadurch aus, dass die Applikationslogik mit Darstellung und Datenhaltung eng verwoben ist. Mehrschichtigen Architekturen verfügen z. B. über eine Client-, eine Präsentations-, eine Mittelschicht
und eine Persistenzschicht. Innerhalb dieser Schichten sind die Anwendungen in Komponenten
aufgeteilt und kommunizieren über definierte Schnittstellen.
Die Nutzung von Softwarekomponenten bezieht sich demnach nicht nur auf die Erstellung einzelner Anwendungen, sondern erstreckt sich auch auf die Erstellung solcher mehrschichtigen Internetservice-Plattformen. Grundlegendes Merkmal solcher Internetservice-Plattformen ist darüber
hinaus die Bereitstellung von Basisdiensten, die von allen Komponenten genutzt werden können
und somit nicht mehrfach implementiert werden müssen. Hierzu gehören unter anderem infrastrukturelle Dienste zum Transport, der Kommunikation, der Sicherung sowie der Datenhaltung1.
Zum anderen bieten diese Plattformen ein Rahmenwerk2 an aufgabenspezifischen Funktionalitäten, wie z. B. Modellierungs-, Entwicklungs- und Ausführungsumgebungen, an. In diese Plattformen lassen sich neben Komponenten – unter Nutzung von Adaptern oder Konnektoren – auch
Bestandssysteme integrieren. Aufgrund der Komplexität und Variantenvielfalt internetbasierter
Mehrwertdienste verspricht die Nutzung von Internetservice-Plattformen erhebliche Einsparpotenziale bei den Entwicklungskosten und der -dauer im Vergleich zu entsprechenden Individualprojekten.
Neben den technischen Aspekten werden bei der Spezifikation einer anforderungsgerechten Internetservice-Plattform auch die zu realisierenden Prozesse adressiert, weshalb diese auch Architekturmodelle genannt werden. Architekturmodelle gehen über die reine Software-Architektur
hinaus und beschreiben den Gesamtaufbau einer Internetservice-Plattform mit ihren integrierten
Systemen. Architekturmodelle bestehen aus verschiedenen Repräsentationen des Systems, die
verschiedene Betrachtungswinkel auf Objekte der Architektur, z. B. auf Organisation oder Daten,
darstellen. Die Repräsentationen werden als Sichten bezeichnet.
1
2
Vgl. /Weis-2002 (S. 19)/Weis-2000 (S. 53)/.
auch Framework genannt. Rahmenwerke bzw. Frameworks sind wiederverwendbare Softwaresysteme von interagierenden Klassen oder Komponenten, die einen Rahmen für eine Anwendung oder einen Anwendungsteil liefern.
- 77 -
5.3 Methodik
Um komplexe, verteilte Softwaresysteme zu modellieren beziehungsweise zu konzipieren, bietet
sich ein Vorgehen in Anlehnung an das Referenzmodell für offene, verteilte Datenverarbeitung,
das sogenannte Reference Model of Open Distributed Processing (RM-ODP)1, an. Bei diesem
ISO-Architekturstandard erfolgt die Betrachtung eines Systems aus fünf Sichten bzw. Blickwinkeln
– den Viewpoints –, um die Komplexität zu reduzieren (siehe Abbildung 5-2).
Mithilfe dieser Sichten können sowohl existierende Systeme als auch neue Systeme und Anwendungen modelliert werden. Die im RM-ODP-Modell definierten Sichten haben für die vorliegende Arbeit unterschiedliche Relevanz. Sie werden jedoch aus Gründen der Vollständigkeit alle
aufgeführt.
Das RM-ODP eignet sich grundsätzlich zur Beschreibung komponentenbasierter fernerbrachter
Dienstleistungen. Es deckt jedoch nicht alle Anforderungen aus Kapitel 3 ab. Im Folgenden wird
daher das RM-ODP-Modell zweigeteilt betrachtet: Einerseits in Hinblick auf die Grundlagen, die
zur Dienstkonzeption (siehe Kapitel 4: Stand der Technik) und Erbringung von Mehrwertdiensten
(siehe Kapitel 6: Informations- und Kommunikationstechnologien zur Erbringung internetbasierter
Mehrwertdienste) erforderlich sind. Andererseits ist das RM-ODP-Modell im Hinblick auf das EService Engineering Vorgehensmodell, das Gegenstand des 7. Kapitels ist, von Bedeutung.
Engineering
Viewpoint
Hardware und
Infrastruktur
Enterprise
Viewpoint
Information
Viewpoint
Prozessmodelle
und Rollen
Daten und
Datenmodellierung
Vorgehensmodell
Technology
Viewpoint
Computational
Viewpoint
Standards und
Techniken
Module und
Schnittstellen
Abbildung 5-2: Die fünf Sichten des Reference Model of Open Distributed Processing
1
Vgl. /ISO-10746-3/.
5.3.1
- 78 -
Definition, Anforderungsanalyse und Konzeption (Enterprise Viewpoint)
Der Enterprise Viewpoint spezifiziert Zielsetzung, Anwendungsbereich, Verfahren und Regeln
eines IT-Systems. Der Enterprise Viewpoint beschreibt demnach die Gesamtumgebung, in welche
die Mehrwertdienste einzubetten sind. Der Enterprise Viewpoint ist damit der Nicht-IT-Teil des
Vorgehensmodells.

Die existierenden Vorgehensmodelle des Service Engineerings decken die wesentlichen
Aspekte des Enterprise Viewpoints ab. Diese Vorgehensmodelle sind Gegenstand des Kapitels
4.4. Der Enterprise Viewpoint ist nicht Kern der Arbeit, da die kunden- beziehungsweise
projektspezifische Gesamtumgebung und Randbedingungen für das allgemeingültige
Vorgehensmodell zur Gestaltung von Mehrwertdiensten nicht von Bedeutung sind.

Bei der Erarbeitung von Dienstleistungskonzepten müssen die Besonderheiten der
elektronischen Diensterbringung für Maschinen und Anlagen betrachtet werden. Allgemeine
Anforderungen, die bei der Spezifikation zu beachten sind, wurden bereits in Kapitel 3.2 beschrieben. Diese Anforderungen müssen durch anwendungsspezifische Anforderungen
individueller Dienste ergänzt werden. Der Enterprise Viewpoint findet im Kapitel 7.3 als EService Design Eingang in das E-Service Engineering Vorgehensmodell.
5.3.2
Spezifikation der Infrastruktur (Engineering Viewpoint)
Der Engineering Viewpoint stellt die Verteilung der einzelnen Elemente des Systems auf
physikalische Ressourcen sowie deren Verbindung dar. Hierzu gehören die Hardware-Architektur
aller dienstleistungserbringenden und -empfangenden Einheiten sowie das Kommunikationsnetzwerk. Die Spezifikation soll so erfolgen, dass die Infrastruktur sicher vor Angriffen aus dem
Internet ist und zugleich die in Kapitel 3.3 gestellten Anforderungen in Bezug auf Leistungsfähigkeit, Verfügbarkeit etc. erfüllt.

Eine Betrachtung unterschiedlicher Infrastrukturen erfolgt im Kapitel 6.1. Das Kapitel 6.2
widmet sich den Hardware-Architekturen.

Im E-Service Engineering Vorgehensmodell erfolgt die Betrachtung des Engineering
Viewpoints in Kapitel 7.4.
5.3.3
Spezifikation von Komponenten (Computational Viewpoint Teil 1)
Der Computational Viewpoint hat zum Ziel, ein System in logische, funktionale Komponenten zu
zerlegen. Das Ergebnis sind Komponenten, die Schnittstellen besitzen, an denen sie Dienste anbieten beziehungsweise nutzen. Die Spezifikation, Komposition und Konfiguration von Komponenten bildet einen Schwerpunkt der Arbeit, weshalb sich dieses Thema an mehreren Stellen der
Arbeit wiederfindet.

Im Grundlagenteil erfolgt in Kapitel 6.3 zunächst ein Überblick über die Prinzipien der komponentenbasierten Softwareentwicklung. Im Weiteren werden dort die Eigenschaften von Softwarekomponenten und deren Beschreibung näher beleuchtet.

Im Rahmen des E-Service Engineering Vorgehensmodells wird in Kapitel 7.5 die E-ServiceProzessarchitektur beschrieben, welche zusammen mit der E-Service-Integrationsarchitektur in
Kapitel 7.6 schließlich in die E-Service-Anwendungsarchitektur aus Kapitel 7.7 mündet. Unter
Berücksichtigung der ausgewählten Internetservice-Plattform wird im Kapitel 7.11 mit dem Aufbau eines E-Service-Komponentenkatalogs begonnen.
5.3.4
- 79 -
Spezifikation der Software-Architektur (Computational Viewpoint Teil 2)
Eine Software-Architektur beschreibt den grundlegenden Aufbau des Softwaresystems und ist
ebenfalls Betrachtungsgegenstand des Computational Viewpoints. Die Trennung des Computational Viewpoints in Komponenten und Architektur wird aus Gründen der Übersichtlichkeit vorgenommen. Die zuvor in Kapitel 5.3.3 spezifizierten Komponenten finden Eingang in die konkrete
Software-Architektur einer Internetservice-Plattform.

Das Kapitel 6.4 vermittelt die Grundlagen über Mehrschicht-Architekturen und Frameworks.

Die Spezifikation einer Software-Architektur hat immer aus Sicht konkreter Dienste und Bedarfe zu erfolgen. Da das Vorgehensmodell den Anspruch hat allgemeingültig zu sein, um in
möglichst vielen Projektkonstellationen einen Nutzen zu stiften, kann keine allgemeine
Empfehlung gegeben werden. Stattdessen thematisiert das Kapitel 7.10 die Auswahl einer anforderungsgerechten Internetservice-Plattform.
5.3.5
Spezifikation von Schnittstellen und Datenformaten (Information Viewpoint)
Der Information Viewpoint beschreibt die Struktur und Semantik der Informationen eines ITSystems, also das Datenmodell1. Neben der Definition von Informationsquelle und -empfänger
werden die Datentransformationen durch das System spezifiziert. Der Entwurf von Schnittstellen
und Datenformaten wird geprägt durch die zu integrierenden IT-Systeme. Dies können sowohl
PLM-Bestandssysteme als auch IT-Systeme von Maschinen oder Anlagen sein.

Das Kapitel 6.6 behandelt die Automation aus Sicht der IT. Dort wird aufgezeigt, dass sich die
ursprünglich proprietären IT-Systeme in der Automatisierung schrittweise an die Technologien
der Consumer-IT annähern. Einige Internet-Technologien haben bereits heute einen festen
Platz in der Industrieautomation gefunden, und damit einen De-facto-Standardisierungseffekt
von Technologien, Schnittstellen und Datenformaten ausgelöst.

Das Kapitel 7.8 behandelt die statische E-Service-Datenarchitektur. Sie wird durch eine
dynamische Betrachtung der E-Service-Kommunikationsarchitektur in Kapitel 7.12 ergänzt.
5.3.6
Berücksichtigung aktueller Technologien und Standards (Technology Viewpoint)
Die Berücksichtigung aktueller Technologien und Standards ist Gegenstand des Technology Viewpoints.

Die Grundlagen hierzu behandelt das Kapitel 6.5. Dort werden Softwaretechnologien sowie
Internet-Standards vorgestellt, die zur Erbringung von Mehrwertdiensten notwendig sind. Dies
umfasst Komponententechnologien für Clients und Server sowie Technologien zur
Kommunikation zwischen Komponenten.

Aufgrund des Anspruchs ein allgemeingültiges Vorgehensmodell zu schaffen, erfolgt im
Rahmen der Arbeit keine Auswahl einer konkreten Technologie. Stattdessen behandelt das
Kapitel 7.10 die Auswahl einer anforderungsgerechten Internetservice-Plattform unter Berücksichtigung von Technologieaspekten.
1
Die für Prozessabläufe erforderlichen Informationen sind durch Daten in einem Datenmodell zu repräsentieren. Das
objektorientierte Datenmodell beinhaltet beispielsweise eine Objektstruktur, eine Beschreibung der Objekte, die Zuordnung von Attributen zu den Objekten und die Beschreibung der Attribute.
6 Informations- und Kommunikationstechnologien zur Erbringung
Ein Mann mit einer neuen Idee ist ein Narr so lange, bis die Idee sich durchgesetzt hat.
Mark Twain
Schriftsteller
Bei der Konzeption und Realisierung internetbasierter Mehrwertdienste spielen naturgemäß
technische Prozess- und Ressourcenkonzepte eine wichtige Rolle. Das Kapitel 6 behandelt die zur
Diensterbringung notwendigen Informations- und Kommunikationstechnologien. Abbildung 6-1
zeigt den Aufbau des 6. Kapitels.
Anbieter von Mehrwertdiensten
Nutzer von Mehrwertdiensten
6.5
6.5 Software-Technologien
Software-Technologien
6.4
6.4 Software-Architekturen
Software-Architekturen
6.3
6.3 Komponentenbasierte
Komponentenbasierte Software
Software
6.2
6.2 Hardware-Architekturen
Hardware-Architekturen
6.6
6.6 Automation
Automation aus
aus Sicht
Sicht der
der IT
IT
6.1
6.1 Infrastruktur
Infrastruktur
Internet-Service-Provider
Abbildung 6-1: Aufbau und Inhalt des 6. Kapitels
6.1 Infrastruktur
Eine stabile und sichere Infrastruktur – auch IT-Infrastruktur oder Netzwerkinfrastruktur genannt –
ist eine Voraussetzung für den hoch verfügbaren und zuverlässigen Betrieb von Mehrwertdiensten.
Die Modellierung der Infrastruktur erfolgt gemäß des Engineering Viewpoints nach RM-ODP.
Dieser Viewpoint beschreibt die Kapselung von Systemeinheiten und ihre Netzwerkverbindungen.
Die Systemeinheiten umfassen Ausführungseinheiten, wie zum Beispiel Clients, Server, Anwendungen und die Kommunikationsstruktur sowie alle Arten von Softwareplattformen. Die bei der
Infrastrukturmodellierung zu beachtenden Aspekte sind Gegenstand der nachfolgenden Unterkapitel.
Informations- und Kommunikationstechnologien zur Erbringung internetbasierter Mehrwertdienste
6.1.1
- 81 -
Netzwerke
Der Begriff Netzwerk hat im Verlauf der letzten Jahrzehnte seine Bedeutung verändert. Heute versteht man unter einem Netzwerk ein beliebiges Kommunikationssystem, welches zwischen einer
Anzahl von Kommunikationsteilnehmern den Austausch von Daten ermöglicht1.
Das weltweit größte Netzwerk ist das Internet, das in den frühen 70er Jahren in den USA vom
Department of Defense und der Advanced Research Project Agency (ARPA) im Rahmen mehrerer
Projekte spezifiziert wurde. Über verschiedene Zwischenstufen – unter anderem das ARPANET –
entstand die Protokollsuite Transmission Control Protocol (TCP) sowie das Internet Protocol (IP).
Dies wird als die Geburtsstunde des Internets angesehen2.
Das Internet wurde ursprünglich nur im wissenschaftlichen Bereich eingesetzt. Begründet war dies
unter anderem in der komplizierten Bedienung, die vorwiegend kommandozeilenorientiert erfolgte.
Der Zugang zu den Internet-Basisdiensten3 fand in jeweils eigenen Client-Programmen mit eigener
Oberfläche statt.
Mit der Einführung des World Wide Webs (WWW) zu Beginn der 90er Jahre wurde eine grafische,
intuitiv zu bedienende Oberfläche für das Internet zur Verfügung gestellt. Web-Browser vereinfachten den Zugriff auf entfernte Rechner, ermöglichten grafische und multimediale Benutzeroberflächen und integrierten die Internet-Basisdienste in einer einheitlichen Oberfläche.
Das World Wide Web basiert auf drei wesentlichen Konzepten4:

Die Hypertext Markup Language (HTML) ist eine plattformunabhängige Beschreibungs- und
Formatierungssprache für Dokumente. Ein wichtiges Konzept von HTML ist, dass von einem
HTML-Dokument ausgehend entsprechende Verweise, die Hyperlinks, auf andere Ressourcen
beziehungsweise Dokumente gesetzt werden können.

Das Hypertext Transfer Protocol (HTTP) ist der Verständigungsmechanismus zwischen dem
Server, der die Dokumente auf Anfrage bereitstellt, und dem Client, der diese Anfrage vornimmt und die Information darstellt. Der Kern des HTTP-Protokolls ist dieses Request
/Response-Schema5. HTTP ist ein statusloses Protokoll, d. h., nach jedem Request und
Response wird die Verbindung zwischen Client und Server wieder geschlossen.

Der Uniform Ressource Locator (URL) ist ein standardisierter Mechanismus für die eindeutige Adressierung der Ressourcen im World Wide Web sowie für die Angabe eines
Protokolls beziehungsweise Internet-Basisdiensts.
1
Vgl. /Furr-2003 (S. 33)/.
Vgl. /Furr-2003 (S. 78)/.
Aufgesetzt auf den Internetprotokollen werden in der Anwendungsschicht die Anwendungsprotokolle, die auch
Internet-Basisdienste genannt werden, bereitgestellt. Hierzu gehören u. a. E-Mail, der File-Transfer-Dienst (FTP) und
der Fernzugriff auf Rechner mittels Telnet. Zur Abgrenzung der unterschiedlichen Anwendungsprotokolle werden
Ports genutzt. Die Kombination aus IP-Adresse und Port wird auch als Socket bezeichnet. Vgl. /Göhr-2001 (S. 39)/.
Ein Netzwerkprotokoll legt die Regeln zum Datenaustausch zwischen Sender und Empfänger fest, in dem es das
Format der zu übertragenden Daten und die Mechanismen zum Auf- und Abbau einer Verbindung definiert.
Request/Response-Schema, englisch für Anfrage- und Antwort-Schema.
2
3
4
5
6.1.2
- 82 -
Netzwerkeigenschaften
Die Art des verwendeten Netzwerks hat Einfluss auf die IT-Sicherheit, die Bandbreite, die Verfügbarkeit, die Latenzen etc. Ein wichtiges Unterscheidungsmerkmal basiert auf den Besitzverhältnissen der Netzwerke1. Tabelle 6-1 fasst die Merkmale verschiedener Netzwerke zusammen und
stellt diese bewertend gegenüber.

Intranets: Alle Netzwerkkomponenten und Kommunikationsteilnehmer gehören dem gleichen
Besitzer. Intranets benutzen oftmals die vollständige Internet-Technologie, also Web-Server,
Web-Browser etc., stellen jedoch ihre Dienste2 nicht öffentlich zur Verfügung.

Extranets: Alle Netzwerkkomponenten und Kommunikationsteilnehmer gehören dem gleichen,
aber fremden Besitzer. Der Zugang zu einem Extranet kann für definierte Kommunikationsteilnehmer erlaubt werden, z. B. für eine firmenübergreifende Kooperation.

Internet: Das Internet ist ein offenes, weltweit zugängliches Netzwerk mit einer weltweit eindeutigen IP-Adressenstruktur. Der Zugang erfolgt über einen beliebigen Internet-ServiceProvider. Im Internet findet man eine Vielzahl von Diensten, z. B. E-Mail, Suchmaschinen etc.
Der Hauptvorteil des Internets liegt in der Möglichkeit, jeden angeschlossenen
Kommunikationsteilnehmer erreichen zu können. Hieraus ergibt sich aber auch das Hauptsicherheitsproblem: Alle Internetteilnehmer sind potenzielle Angreifer und alle haben Zugriff auf
jeden angeschlossenen Rechner.

Virtual Private Networks (VPNs): Das Ziel von VPNs ist, die kostengünstige und weltweit verfügbare, öffentliche Internet-Infrastruktur zu nutzen und Maßnahmen zu treffen, damit eine geschlossene Benutzergruppe genügend Sicherheit für ihre Daten, Programme, Ressourcen etc.
erreicht. Der Begriff virtual bezieht sich darauf, dass das private Netzwerk nicht physisch
existiert, sondern öffentliche Verbindungswege verwendet werden3.

Private Networks (PNs): In manchen Fällen können die Netzwerkanforderungen nur eingeschränkt von öffentlichen Netzwerken gewährleistet werden. Anders verhält es sich bei
Private Networks. Diese nutzen eigene physikalische Netzwerke und werden lediglich einer
geschlossenen Benutzergruppe zur Verfügung gestellt. Ein Beispiel hierfür ist ENX4.
Zur Fernerbringung und -nutzung industrieller Dienstleistungen sind Infrastrukturen zur Einwahl in
oben genannte Netzwerke erforderlich. Bei der Auswahl eines geeigneten Kommunikationsnetzes
ist zu beachten, dass das schwächste Glied in der Kette die Leistungsfähigkeit der Verbindung bestimmt. So erzielt z. B. eine leistungsfähige T3-Standleitung beim Dienstleistungserbringer nur
dann beim Empfänger seine Wirkung, wenn dieser über eine adäquate Verbindung ins Netzwerk
verfügt. In Tabelle 6-2 sind leitungsgebundene und drahtlose Verbindungsarten mit Bewertung
aufgeführt. Tabelle 6-3 listet die zugehörigen Bandbreiten auf.
1
2
3
4
Vgl. /Furr-2003 (S. 44)/.
Vgl. (IT-)Dienste sind Entitäten, die Funktionalität für Anwendungen bereitstellen.
Dadurch können allerdings Verfügbarkeits- und Quality-of-Services-Probleme entstehen.
Das European Network Exchange (ENX) repräsentiert einerseits das private Kommunikationsnetzwerk der europäischen Automobilindustrie und andererseits die Organisation ENX Association, vgl. /ENX-2007a/. Das ENXNetzwerk ist vollständig vom Internet getrennt und arbeitet unter Nutzung der VPN-Technik. Verbindungen kommen
nur zustande, wenn beide Kommunikationsteilnehmer dies beantragen. Die ENX Association garantiert Sicherheit bei
der Datenübertragung sowie definierte Bandbreiten und Verfügbarkeiten. Anwendungsbeispiele unter: /ENX-2007b/.
Merkmal
- 83 -
Intranet
Extranet
Internet
VPN
PN
Leistungsfähigkeit
++
+
+
+
++
Reichweite
--
Ø
++
++
Ø
Standardisierung
++
++
++
+
+
Verfügbarkeit
++
+
+
+
++
Betrieb
++
Ø
Ø
Ø
++
Kosten
++
+
++
Ø
-
Sicherheit
++
+
-
++
++
++
sehr gut
+
gut
Ø
durchschnitt
ausreichend
-mangelhaft
Legende
Tabelle 6-1: Netzwerkeigenschaften von Intranet, Extranet, Internet, VPN und PN
Kategorie
Merkmal
leitungsgebunden
drahtlos
Analog
ISDN
DSL
T1-T3
GSM
GPRS
EDGE
UMTS
Satellit
++
+
++
Ø
+
Ø
-1
Ø
+
Bandbreite
--
Ø
+
++
--
Ø
+
++
+
Kosten
Ø
+
+
-
Ø
Ø
Ø
-
--
Reichweite
Legende
++
sehr gut
+
gut
Ø
durchschnitt
ausreichend
-mangelhaft
Tabelle 6-2: Bewertung verschiedener Netzwerke 2
Datenrate pro Kanal
Kanäle
GSM
Merkmal
9,6 kBit/s
1
9,6 kBit/s
GPRS
21,4 kBit/s
8
171,2 kBit/s
EDGE
48 kBit/s
8
384 kBit/s
UMTS (mit HSDPA)
960 kBit/s
15
14,4 MBit/s
n. b.
n. b.
256 kBit/s - 2048 kBit
Satellit (2-Wege)
Analog Modem
ISDN
100-MBit-Ethernet
Datenrate
56 kBit/s
1
56 kBit/s
2x64 + 2x16 kBit/s
1
160 kBit/s
100 MBit/s
1
100 MBit/s
DSL, Upstream
4 kBit/s
32
1 MBit/s
DSL, Downstream
4 kBit/s
192
16 MBit/s
Tabelle 6-3: Bandbreiten verschiedener Netzwerke
1
2
EDGE ist eine Weiterentwicklung des GPRS-Standards und soll Ende 2007 in Deutschland zur Verfügung stehen.
Vgl. /Göhr-2001 (S. 30)/, </http://www.teltarif.de/>, letzter Abruf am: 01.05.2008.
6.1.3
- 84 -
Kommunikationsstruktur
Neben den o. g. Eigenschaften von Netzwerken ist die Richtung des Aufrufs von Bedeutung. Ein
Aufruf geht definitionsgemäß immer vom Client aus. Grundsätzlich gibt es zwei Möglichkeiten zur
Anbindung von IT-Systemen des Dienstleistungsempfängers mit denen des -erbringers.

Maschinen/Anlagen als Server1: Die Auslegung einer Maschinensteuerung als Web-Server
hat den gravierenden Nachteil, dass dessen IP-Adresse über das Internet ansprechbar sein
muss und damit beliebigen Angriffen aus dem Netz offen steht.

Maschinen/Anlagen als Client: Ist die Steuerung ein Web-Client, geht die Initiative von der
Steuerung aus. Der Vorteil liegt darin, dass die firmeneigene Firewall2 und sonstige Sicherheitsvorkehrungen diese Kommunikation kontrollieren können3.
Erstaunlicherweise bieten viele Steuerungs- und SPS4-Anbieter ihre Komponenten mit WebServerfunktionalität an und bedenken scheinbar nicht die damit verbundenen Risikopotenziale. Die
Gründe hierfür liegen wohl unter anderem darin, dass sich diese Komponenten mit geringem Aufwand in die IT-Landschaft des Betreibers integrieren lassen. Falls die Dienste nur innerhalb des
Intranets verwendet werden sollen, wiegt dieser Nachteil nicht so schwer, ist jedoch aus Gründen
eines sichern Designs dennoch problematisch. Kreidler5 beschreibt umfassend verschiedene Infrastrukturen zur Anbindung von Diensten an Werkzeugmaschinen (siehe Tabelle 6-4):
6.1.4
Ausführungsort und Datenhaltung
Der Ausführungsort der Dienstalgorithmen sowie die Datenhaltung liegen normalerweise in der
Domäne des Diensterbringers. In spezifischen Fällen kann es jedoch auch sinnvoll sein, in der
Domäne des Dienstnutzers einige Dienste zu betreiben. Hierzu gehören Anwendungsfälle, bei
denen keine Datenübertragung vom Dienstnutzer zum Diensterbringer erfolgen soll beziehungsweise kann. Die Gründe hierfür können vielschichtig sein, wie folgende Aufzählung zeigt:

Der Dienstnutzer stimmt aus psychologischen und/oder wettbewerbstaktischen Gründen einer
Übermittlung von u. U. sensiblen Daten an den Diensterbringer nicht zu.

Die Übermittlung großer Datenmengen beziehungsweise zeitkritischer Dateninhalte ist
wirtschaftlich nicht sinnvoll oder technisch nicht möglich.

Zur Erzielung einer hohen Benutzerfreundlichkeit – vor allem schneller Reaktionszeiten –
erfolgt die Berechnung und Visualisierung in der Domäne des Dienstnutzers.
Gegebenenfalls sind hybride Infrastrukturen zu gestalten, bei denen eine Verteilung von lokal- und
fernerbrachten Diensten möglich ist. Für diese Fälle kann es sinnvoll sein, den Dienstnutzern nicht
den Dienst anzubieten, sondern Teile der Dienstalgorithmen zur Verfügung zu stellen. Die Ausführung der Dienste erfolgt dann lokal in der Domäne des Dienstnutzers6.
1
2
3
4
5
6
Ein Web-Server ist ein Serverdienst, der Informationen nach dem HTTP-Protokoll zur Verfügung stellt.
Eine Firewall ist eine Software- und/oder Hardwarelösung, die ein Computernetzwerk oder einen einzelnen Computer
vor unerwünschten Zugriffen schützen soll.
Die von Meier /Meie-2004a/ und Heine /Hein-2003/ im Rahmen des Projekts EOS entwickelten Konzepte erfüllen
diese Anforderungen nicht. Dort wird die Philosophie „Steuerung als Web-Server“ verfolgt.
SPS für Speicherprogrammierbare Steuerung, engl. PLC für Programmable Logic Controller.
Vgl. /Krei-2004 (S. 81)/.
Hierzu eignet sich z. B. die JavaStart-Technolgie von SUN.
Dienstleistungsempfänger
als Server
Kategorie
Art
Vorteile
Nachteile
Die Steuerung als
Web-Server
Dienstleistungserbringer
als Client
Die Steuerung als Webund Applikationsserver
Zentrale Bereitstellung
von Diensten
Eine reine
Visualisierung von Zustandsdaten lässt sich
unter Verwendung von
XML-Standards relativ
einfach realisieren.
Daten- und rechenintensive Auswertungen
können direkt vor Ort
an der Maschine ausgeführt werden, ohne
große Datenmengen
übertragen zu müssen.
Geringe Belastung der
Steuerung, da dort nur
Daten visualisiert, aber
nicht berechnet werden.
Die IP-Adresse der
Steuerung muss
öffentlich bekannt sein
und lässt sich von
außen ansprechen
(Sicherheitslücke).
Die IP-Adresse der
Steuerung muss
öffentlich bekannt sein
und lässt sich von
außen ansprechen
(Sicherheitslücke).
Aufwendige Installation
und Betrieb beim
Service-Provider.
Begrenzte Funktionalität, da lediglich die
Daten der Steuerung
benutzt werden. Verwendung externer
Dienste ist nicht möglich.
Begrenzte Funktionalität, da begrenzte
Rechen- und Speicherkapazität auf normalen
Steuerungen.
Psychologische Bedenken der Betreiber,
da ein Zugriff auf alle
Daten der Steuerung
möglich ist.
Spezifische Software ist
auf den Clients erforderlich, um die Daten
des Web-Servers
intelligent auszuwerten.
Gefahr, dass die Echtzeitanforderung der
Steuerung durch Ausführung der Dienste gefährdet wird.
Hohe Betriebskosten
der Steuerung, da
Wartung und
Änderungen an allen
Steuerungen vorgenommen werden
müssen.
Tabelle 6-4: Beschreibung verschiedener Infrastrukturen1
1
- 85 -
Vgl. /Krei-2004 (S. 81)/.
Neue Dienste lassen
sich sofort nutzen, wenn
zentral vorhanden.
Versagt das zentrale
System, versagen alle
Dienste.
- 86 -
6.2 Hardware-Architekturen
Die Hardware-Architektur beschreibt gemäß des Engineering Viewpoints nach RM-ODP die erforderliche Systemunterstützung zur Realisierung von Diensten. In Abbildung 6-2 ist die zeitliche
Entwicklung der Architekturen der Informationsverfügbarkeit gegenübergestellt.
P2PFilesharing
Informationsverfügbarkeit
Terminalserver und
Internet
Filesharing und
Client-Server
Mainframe
Zeit
Prognose
1960
1980
2000
2020
Abbildung 6-2: Zeitliche Entwicklung der Architekturen1
6.2.1
Mainframe-Architektur
Die Mainframe- beziehungsweise Großrechner-Architektur stellt alle Daten und Anwendungen
zentral bereit. Mainframes bieten die Möglichkeit, eine große Anzahl von Bildschirmarbeitsplätzen
und sonstigen Peripheriegeräten parallel zu betreiben. Die Kommunikation mit dem Großrechner
erfolgt über Terminals, grafische User-Interfaces, wie z. B. das X-Windows-System, oder über
zeichenorientierte Terminalemulationen (VT100, 3270-Emulatoren) (siehe Tabelle 6-5).
Vorteile
Nachteile
hohe Verfügbarkeit
hohe Einstiegskosten
hohe Rechenleistung
Latenzzeiten, insbesondere bei grafischen Anwendungen
zentrale Wartung
Tabelle 6-5: Gegenüberstellung der Vor- und Nachteile von Mainframe-Architekturen
6.2.2
Filesharing-Architekturen
Mit dem Aufkommen der Personal Computer (PC) wurden Netzwerke auf der Basis von Filesharing-Architekturen aufgebaut. Auf Anfrage des Clients werden komplette Dateien vom zentralen
Rechner auf den Client geladen. Die Filesharing-Architektur erlaubt dabei den Zugriff mehrerer
Nutzer gleichzeitig und verfügt über Schutzmechanismen, wenn gleichzeitig Veränderungen an
Daten vorgenommen werden. Die Ausführung der Prozesse läuft auf den Clients (siehe Tabelle
6-6).
1
Das Internet hat maßgeblich zur Steigerung der Informationsverfügbarkeit beigetragen, wenngleich das Internet
streng genommen keine Architektur ist.
Vorteile
Diese Architektur arbeitet zufriedenstellend,
solange die Nutzeranzahl klein bleibt und die
zu übertragenden Datenmengen gering sind.
- 87 -
Nachteile
Filesharing-Architekturen ermöglichen lediglich den Austausch von Daten. Eine
Informationsverarbeitung ist nicht möglich.
Tabelle 6-6: Gegenüberstellung der Vor- und Nachteile von Filesharing-Architekturen
Einen Sonderfall stellt das Peer-to-Peer-Filesharing (P2P)1 dar. Im Unterschied zum konventionellen Filesharing sind beim P2P-Filesharing alle Computer gleichberechtigt. Um Dienste in
Anspruch zu nehmen, müssen gleichzeitig Dienste zur Verfügung gestellt werden. Die Peer-toPeer-Technologie erweist sich als ein sehr viel versprechendes neues Kommunikationsparadigma
zur Suche und zur Verknüpfung von Inhalten, Objekten und Kontexten nahezu beliebiger Art. Die
Peer-to-Peer-Technologie ist längst nicht mehr nur auf den Daten Download beschränkt. Es ergeben sich vielfältige neue Kommunikationsszenarien. Die Internetbildtelefonie oder das InternetTV sind zwei davon. Einige P2P-Filesharing-Architekturen werden dem Grid-Computing zugeordnet.
6.2.3
Client-Server-Architekturen
Client-Server-Architekturen wurden durch die Verbreitung des PCs in den 80er Jahren bekannt. Da
die Leistungsfähigkeit der Clients zugenommen hatte, wurde versucht, diese mithilfe von ClientServer-Architekturen zu nutzen. Solche Clients werden auch Rich- bzw. Fat-Clients genannt2. Den
Unterschied zwischen Filesharing- und Client-Server-Architekturen macht der Ersatz von Fileservern durch Datenbankserver3 aus. Bei der Client-Server-Architektur stellt der Client Anfragen
an die Datenbank und erhält das Ergebnis angezeigt. Bei der Nutzung von FilesharingArchitekturen erhält der Anwender stattdessen die gesamte Datenbank oder Datei. Da der Datenbankserver lediglich den Anfrageinhalt zurücksendet, lies sich die Antwortgeschwindigkeit steigern.
Client-Server-Architekturen sind heute Standard bei nahezu allen Internet-Anwendungen. Eine
Gegenüberstellung der Vor- und Nachteile von Client-Server-Architekturen zeigt Tabelle 6-7:
Vorteile
gleichbleibende Rechenleistung am Client
Die Daten und teilweise auch die
Applikationen liegen auf dem Server und
werden beim Start auf den Client geladen.
Nur der Server muss mit hochwertiger
Hardware ausgestattet sein, um leistungsfähige Dienste zur Verfügung zu stellen.
Nachteile
Client-Software muss auf dem Client installiert
sein, um die Anwendung nutzen zu können.
hohe Wartungskosten durch die parallele
Pflege von Server und Client
durch die Trennung in Server- und ClientSeite höhere Komplexität der Applikationen
Tabelle 6-7: Gegenüberstellung der Vor- und Nachteile von Client-Server-Architekturen
1
2
3
Peer, englisch für Gleichgestellter, Ebenbürtiger oder Altersgenosse
Vgl. Mit der zunehmenden Verbreitung des Internets geht der Trend vom Rich-Client wieder zurück zum Thin-Client.
Hier ist der Web-Browser der Thin-Client, die eigentliche Programmlogik liegt auf einem zentralen Applikationsserver.
Hier synonym für Transaktions-, Web- und Objekt-Server.
6.2.4
- 88 -
Terminalserver-Architekturen
Bei Terminalserver-Architekturen wird die Applikation vollständig auf dem Server ausgeführt. Der
Client zeigt nur die grafische Benutzeroberfläche der Anwendung an und überträgt Tastaturbefehle
sowie Mausklicks. Dabei findet bei jeder Eingabe des Anwenders eine inkrementelle Übertragung
des Bildschirminhalts der Serverapplikation zum Client statt. Als Endgeräte können Thin-Clients
genutzt werden. Diesen Thin-Clients verfügen lediglich über die Kernelemente eines Computers.
Ausfallgefährdete Komponenten werden vermieden, was z. B. in rauen Umgebungen vorteilhaft ist.
Bei grafischen Anwendungen, wie etwa Videos, Animationen oder CAD-Zeichnungen, muss der
Bildschirminhalt bei jeder Bildänderung bzw. Mausbewegung vollständig neu aufgebaut werden.
Hier ist der Einsatz von Terminalserver-Architekturen nur bedingt sinnvoll (siehe Tabelle 6-8).
Vorteile
Nachteile
Zentrales Management der Daten und
Applikationen möglich, da Daten- und
Programme auf zentralen Servern liegen.
teure High-End-Hardware zum performanten
Betrieb auf Server-Seite notwendig.
Höhere Ausfallsicherheit, da keine ausfallgefährdeten Komponenten genutzt werden.
Client-Software muss auf dem Client installiert
sein, um die Anwendung nutzen zu können.
nicht für Multimedia-Anwendungen geeignet
Schnelle Integration bereits existierender, evtl. Wirtschaftlich nicht sinnvoll, wenn die Clients
nicht webfähiger, Anwendungen
hohe Rechenleistung benötigen, da dann
Multi-Client-Unterstützung (UNIX, MAC, …)
große Server-Farmen benötigt werden.
Auch ältere Client-Hardware arbeitet i. d. R.
problemlos mit aktuellen Applikationen.
hoher RAM-Verbrauch pro Session auf der
Server-Seite
Tabelle 6-8: Gegenüberstellung der Vor- und Nachteile von Terminalserver-Architekturen
- 89 -
6.3 Komponentenbasierte Software
Der Begriff Softwarekomponente und damit die Idee, Software aus Bausteinen zusammenzusetzen, ist nicht neu. McIllroy verwendete den Begriff bereits im Jahr 1968 im Zusammenhang mit
der "industriellen Fertigung" von Software1. Softwarekomponenten sind bis heute in der Literatur
nicht eindeutig definiert. Eine Zusammenfassung verschiedener Sichtweisen und Definitionen gibt
Weisbecker2. Im Rahmen dieser Arbeit werden Softwarekomponenten als Einheiten definiert, die
unabhängig voneinander existieren und über formal spezifizierte Schnittstellen verfügen3.
Bei der komponentenbasierten Softwareentwicklung werden Prinzipien aus Industriezweigen, wie
dem Maschinenbau und der Automobilindustrie, auf die Softwareentwicklung übertragen. Diese
Branchen haben gelernt, durch die Verwendung von Komponenten die Komplexität zu reduzieren,
die Entwicklungsgeschwindigkeit zu steigern und Kosten durch Mehrfachverwendung zu senken4.
6.3.1
Objektorientierte Softwareentwicklung
Die Entstehung der komponentenbasierten Softwareentwicklung hängt stark mit der objektorientierten Softwareentwicklung zusammen. Obwohl Softwarekomponenten nicht zwingend auf
objektorientierter Technologie basieren müssen, ist diese oft die Grundlage für komponentenbasierte Systeme. Der Hauptgrund hierfür liegt in den zur Verfügung stehenden Entwicklungsumgebungen, die auf der Objektorientierung beruhen.
Die Idee der Aufteilung eines Systems in Makros, Unterprogramme, Module, Klassen, Komponenten etc. existiert schon lange. Zuerst wurde wiederkehrender Code in Makros gespeichert, um
Entwicklungsaufwand einzusparen. Hieraus entwickelte sich das Prinzip des Unterprogramms.
Wiederverwendbare Unterprogramme wurden dann zu Funktionsbibliotheken zusammengefasst.
Später wurde das Prinzip der Kapselung von Entwurfsentscheidungen und damit das Information
Hiding5 vorgestellt. Hieraus entstand die objektorientierte Softwareentwicklung.
Der Ansatz der objektorientierten Softwareentwicklung besteht darin, die Komplexität von Softwaresystemen zu reduzieren, indem man ein System in Objekte strukturiert. Objekte bestehen aus
Attributen und Funktionen. Gleichartige Objekte werden zu Klassen6 zusammengefasst, deren
Instanzen dann die Objekte bilden. Die Instanz einer Klasse ist ein Objekt. Die einzelnen Klassen
können dann in einer Generalisierungs- beziehungsweise Spezialisierungshierarchie angeordnet
werden, um Gemeinsamkeiten zwischen verschiedenen Klassen auszunutzen7. Eine strukturierte
Sammlung von Klassen nennt man Klassenbibliothek8.
1
2
3
4
5
6
7
8
Vgl. /McIl-1969 (S. 138)/.
Vgl. /Weis-2000 (S. 24)/.
Vgl. /Weis-2002 (S. 156)/.
Interessanterweise wurde das Komponentenprinzip zunächst für die Produktgestaltung der Computerindustrie angewendet. Beginnend mit dem ersten im Jahr 1964 von IBM entwickelten modularen Computer wurden alle nachfolgenden Computergenerationen in Teilsysteme aufgespalten.
Information Hiding, englisch für Verstecken von Implementierungsdetails.
Eine Klasse ist keine Komponente, da sie zum einen nicht generell in binärer Form und unabhängig von anderen
Klassen vorliegt. Zum anderen sind bei Klassen externe Abhängigkeiten in der Regel nicht explizit dokumentiert.
Klassen können jedoch als Basis für Komponenten verwendet werden.
Vgl. /Weis-2000 (S. 28)/.
Eine Klassenbibliothek ist eine Sammlung von Software inklusive Dokumentation, die bei der Entwicklung, Benutzung oder Wartung hilft. Ein System wird durch die Unterstützung von Bibliotheken gebaut, nicht aber aus ihnen
zusammengesetzt. Daher ist eine Bibliothek keine Komponente.
- 90 -
Es stellte sich jedoch heraus, dass eine Klasse nicht isoliert betrachtet und wiederverwendet
werden kann. Häufig arbeiten mehrere Klassen zusammen, um ihre jeweiligen Funktionen zu erfüllen. Um diese Zusammenarbeit zu dokumentieren und wiederverwendbar zu machen, wurden
Entwurfsmuster eingeführt. Diese sollten häufig auftretende oder sich wiederholende Strukturen
der Zusammenarbeit zwischen Klassen dokumentieren. Entwurfsmuster sind jedoch nur wiederverwendbare Strukturen, auf die im Entwurf zurückgegriffen werden kann, um sich wiederholende
Probleme zu lösen. Die eigentliche Implementierung muss für jeden Fall neu geschrieben werden
und ist in der Regel auch nicht wiederverwendbar.
6.3.2
Komponentenbasierte Softwareentwicklung
Die Idee der komponentenbasierten Softwareentwicklung hat zum Ziel, die Funktionalität, die
durch die Zusammenarbeit mehrerer Klassen realisiert wird, auf Implementierungsebene wiederverwendbar zu machen. Eine Komponente kapselt mehrere Klassen, deren Struktur und deren Zusammenarbeit. Im Vordergrund steht bei der komponentenbasierten Softwareentwicklung – im
Gegensatz zu den Entwurfsmustern – die Funktionalität.
Komponenten bieten über Exportschnittstellen ihre Funktionalität an und verwenden gegebenenfalls die Funktionalität anderer Komponenten. Eine Komponente kann demnach als Modul beziehungsweise Container für weitere Komponenten fungieren. Die Begriffe Modul und Komponente
spiegeln somit mögliche Rollen einer Komponente wider (siehe Abbildung 6-3)1. Abbildung 6-4
zeigt das Schema eines Komponentenmodells. Ein Dienst ist über einen oder mehrere Schnittstellendienste mit einer oder mehreren Komponenten verbunden. Eine Komponente kann eine
unterschiedliche Anzahl von Verbindungen zu anderen Komponenten nutzen. Damit eine Softwarekomponente sinnvoll verwendet werden kann, muss sie bestimmte Voraussetzungen erfüllen.
Zum einen müssen die Exportschnittstellen genau spezifiziert sein, zum anderen müssen Abhängigkeiten von anderen Komponenten bzw. Anforderungen an die Umgebung dokumentiert
sein.
Abbildung 6-3: Komponentenbasierte Systeme
1
2
Vgl. /Weis-2000 (S. 24)/.
Vgl. /Turo-2002 (S. 2)/.
Abbildung 6-4: Metaschema eines Komponentenmodells2
- 91 -
Zwei Komponenten, die nach außen hin die gleiche Funktionalität bieten, können als äquivalent
betrachtet werden, auch wenn sich das Datenmodell oder die Programmiersprache der
Komponenten voneinander unterscheiden. Da die angebotenen und benötigten Funktionalitäten
von der technischen Umsetzung entkoppelt sind, können Komponenten für die Nutzer unbemerkt
ausgetauscht werden. Dies bietet vielfältige Möglichkeiten für die Weiterentwicklung.
Eine weitere wesentliche Verbesserung im Vergleich zu objektorientierten Konzepten bieten
standardisierte Ausführungsumgebungen für Komponenten in Form von Frameworks. Damit die
Komponenten die angebotene Plattformfunktionalität nutzen können, müssen diese allerdings mit
dem spezifischen Framework zusammenpassen (siehe Kapitel 6.4.2).
Zur Umsetzung der komponentenbasierten Softwareentwicklung entwickelte Weisbecker1 verschiedene Vorgehensweisen. Dabei werden komponentenbasierte Softwaresysteme zum einen
aus Herstellersicht und zum anderen aus Anwendersicht betrachtet (siehe Tabelle 6-9).
Methode
Beschreibung
Design for
Component2
Als wesentliches Ziel des Designs for Component kann die Bereitstellung von Softwarekomponenten verstanden werden, welche später in eine neue Anwendung
integriert werden können. Um eine – über einen konkreten Anwendungsfall hinaus
– interessante Komponente zu gestalten, müssen die erkannten Funktionalitäten
vom konkreten Einsatzzweck abstrahiert und generalisiert werden.
Design from
Component3
Als wesentliches Ziel des Designs from Component kann die schnelle Erstellung
neuer Anwendungen und der einfachere Aufbau komplexer, problemspezifischer
Anwendungssysteme gesehen werden. Im Design-from-Component-Prozesses
werden die geeigneten Komponenten ausgewählt, konfiguriert und integriert.
Design to
Component4
Das Design to Component befasst sich mit der Migration monolithischer Bestandssysteme zu komponentenbasierten Softwarelösungen. Unter Nutzung von ReEngineering-Methoden wird bestehende Software auf ihre Modularisierungsmöglichkeiten hin untersucht. Anschließend können die Bausteine nach den
Regeln des Designs for Component neu entwickelt werden.
Tabelle 6-9: Vorgehensweisen zur komponentenbasierten Softwareentwicklung
6.3.3
Eigenschaften von Softwarekomponenten
Eine Softwarekomponente muss eine in sich abgeschlossene funktionale Einheit mit vollständig
spezifizierten Schnittstellen bilden, sie muss gut dokumentiert, qualitativ hochwertig und unverändert mehrfach verwendbar sein. Zusätzlich soll eine Softwarekomponente möglichst unabhängig
von anderen Softwarekomponenten sein, an eine Aufgabenstellung anpassbar und bezüglich bestimmter Eigenschaften konfigurierbar sein. Tabelle 6-10 listet die Eigenschaften im Detail auf.
1
2
3
4
Vgl. /Weis-2000 (S. 20)/.
Design for Component, englisch für Entwicklung von Komponenten.
Design from Component, englisch für Entwicklung mit Komponenten.
Design to Component, englisch für Umwandlung in Komponenten.
Eigenschaft
- 92 -
Beschreibung
Granularität von
Komponenten
Die Granularität einer Komponente ist eine grundlegende Eigenschaft und
spielt eine wichtige Rolle für deren Einordnung. Die Spanne reicht von
grafischen Bedienelementen1 bis hin zu vollständigen Anwendungen.
Verbergen von
Komplexität
Die auf Komponenten basierende Softwareentwicklung wird häufig als
logische Fortsetzung der objektorientierten Softwareentwicklung gesehen.
Für große Systeme ist die Bildung von Klassen jedoch zu feingranular. Die
Einführung von Komponenten als weitere Abstraktionsstufe verringert
deren Anzahl.
Austauschbarkeit
und Änderbarkeit
Um die Austauschbarkeit von Teilen einer Software zu unterstützen, sind
Programmteile, die sich mit hoher Wahrscheinlichkeit ändern, in eigene
Komponenten zu kapseln.
Austauschbare Komponenten werden verwendet, um technische Abhängigkeiten zu kapseln. Änderungen müssen gegebenenfalls nur an einer
Komponente vorgenommen werden2.
Erweiterbarkeit und Erweiterungskomponenten werden auch als Add-ons3 oder Plug-ins4 beAnpassbarkeit
zeichnet. Ein Anwendungsgebiet ist die Nachrüstung von Funktionalität im
laufenden Betrieb, wie dies bei z. B. Web-Browsern der Fall ist.
Wartbarkeit
Durch die vereinbarten Schnittstellen haben Änderungen in einer
Komponente keine Auswirkungen auf andere Teile des Systems5.
Größere Änderungen, bei denen Schnittstellen verändert werden müssen,
sind oft schwieriger als bei Systemen ohne Komponenten. Jedoch sind die
Änderungen leichter zu dokumentieren, und daher ist die Gefahr der
wachsenden Inkonsistenz zwischen Dokumentation und System geringer.
Wiederverwendbarkeit
Die Wiederverwendbarkeit von Softwarekomponenten liefert einen
wichtigen Beitrag zur Softwareentwicklung. Mehrfach verwendete
Komponenten führen zu Zeit- und Kosteneinsparungen und erleichtern die
Aufwandsabschätzung im Vorfeld. Darüber hinaus verspricht man sich aufgrund der Komplexitätsreduzierung auch geringere Wartungs- und Pflegekosten.
Robustheit und
Effizienz
Oft geht es den Softwareentwicklern nicht primär um die Wiederverwendbarkeit oder Wartbarkeit, sondern um die Ausfallsicherheit und Robustheit.
Durch die Wiederverwendung von Komponenten können Fehler schneller
erkannt werden und bedingt dadurch, dass weniger Software manuell erstellt wird, sinkt die Wahrscheinlichkeit von Defekten.
Tabelle 6-10: Eigenschaften von Softwarekomponenten
1
2
3
4
5
Vgl. Kapitel 6.5.1.1, JavaBeans und JavaSwing
An dieser Stelle soll nicht unerwähnt bleiben, dass ein heutiges Problem die fehlende vollständige Kompatibilität von
Komponenten ist. Idealerweise sollte eine Komponente auf- und abwärts-kompatibel sein.
to add on, englisch für aufstocken, hinzufügen.
to plug in, englisch für einstecken.
Die Voraussetzung ist, dass die Komponenten keine Seiteneffekte (unerwünschte Nebenerscheinungen) haben.
6.3.4
- 93 -
Standardisierung von Komponentenmodellen
Traditionelle Ingenieurdisziplinen zeichnen sich dadurch aus, dass verbindliche Standards für
Notation1, Benennung, Bemaßung usw. vorgegeben sind, die deren (Wieder-)Verwendung vereinfachen. So ist beispielsweise jeder Ingenieur in der Lage, aus einer Konstruktionszeichnung die für
ihn relevanten Informationen über Abmessung, Oberflächengüte etc. zu entnehmen und in seine
jeweilige Aufgabenstellung zu übernehmen. Um Softwaresysteme aus Softwarekomponenten aufbauen zu können, bedarf es vergleichbare Standards, die Komponentenmodelle.
Nach Heinemann2 beschreibt ein Komponentenmodell die Rahmenbedingungen einer
Realisierung von Komponenten. Zum einen wird die Struktur jeder Komponente festgelegt, die zu
dem Komponentenmodell konform ist. Dies kann beispielsweise Implementierungssprachen,
obligatorische Schnittstellen oder andere Einschränkungen umfassen. Zum anderen legt das
Komponentenmodell die Verknüpfungen von Komponenten fest. Dies umfasst die Deklaration von
Abhängigkeiten zwischen Komponenten, das Auffinden von Diensten oder Komponenten, die
Referenzierung und den Aufruf sowie das Zusammenstellen einer Anwendung aus Komponenten3.
Die Spezifikation einer Komponente muss demnach eine vollständige, widerspruchsfreie und eindeutige Beschreibung ihrer Außensicht umfassen4.
Um Softwarekomponenten zu standardisieren, bedarf es neben der technisch-technologischen
Standardisierung auch der Etablierung inhaltlich-funktionaler Standards.

Zur technisch-technologischen Standardisierung wurden formale Interfacedefinitionssprachen, sogenannte Interface Definition Languages (IDL)5, eingeführt, mit deren Hilfe sich
Schnittstellen formal exakt definieren und beschreiben lassen.

Die technisch-technologischen Standards sagen nichts über die Funktionalität einer
Komponente aus. Zunehmend wichtiger sind daher anwendungsbezogene Standards.
Einen Lösungsvorschlag für die Standardisierung von Komponentenmodellen bietet Turowski6 an.
Als primäre standardisierte Spezifikationstechnik wählt Turowski eine formale Notation, da diese
die notwendige subjektive Nachvollziehbarkeit der Spezifikationsergebnisse unterstützt. Für die ergänzende Spezifikationstechnik wird die Forderung nach einer formalen Notation fallen gelassen.
Insgesamt soll im Sinne einer breiten Lehr-, Lern- und Beherrschbarkeit ein möglichst kompakter
Notationsmix gefunden werden (siehe Abbildung 6-5).
Einige Autoren stehen der formalen Spezifikation von Anwendungssystemen kritisch gegenüber,
sodass man nicht von einem Standard sprechen kann. So ist umstritten, wie Softwarekomponenten zu spezifizieren sind, welche Notationen dazu einzusetzen sind und welches die
konkreten zu spezifizierenden Objekte sind. Einige Autoren stufen den damit verbundenen Aufwand als zu groß und die allgemeine Verständlichkeit als zu gering ein. Vor diesem Hintergrund
1
2
3
4
5
6
Eine Notation wird als formal bezeichnet, wenn Syntax und Semantik eindeutig und widerspruchsfrei definiert sind.
Vgl. /Hein-2001/.
Vgl. /Weis-2002 (S. 256)/.
Vgl. /Turo-2002 (S. 3)/.
Eine Interface Definition Language, auch Interface Description Language (kurz: IDL), ist eine deklarative
Programmiersprache und beinhaltet eine Sprachsyntax zur Beschreibung von Schnittstellen einer Softwarekomponente. Mit ihrer Hilfe lassen sich Objekte und Methoden mitsamt der möglichen Parameter und Datentypen
beschreiben, ohne dabei die Eigenschaften einer bestimmten Programmiersprache zu verwenden.
Vgl. /Turo-2002 (S. 9)/.
- 94 -
wird weder in Hochschulen noch in den Ausbildungsberufen eine einheitliche Lehre vermittelt1. In
der betrieblichen Praxis hat die formale Spezifikation von Komponenten daher keine Bedeutung.
Ritter2 schlägt daher eine nichtformale Sprache vor, die insbesondere zur Beschreibung der verhaltensbezogenen Aspekte dient. Im Rahmen dieser Arbeit wird in Anlehnung an Ritter die nichtformale Sprache zur Spezifikation von Komponenten genutzt3.
Abbildung 6-5: Beschreibungsebenen und zu spezifizierende Sachverhalte von Komponenten4
1
2
3
4
Im Bereich der Web-Services wurden in der Vergangenheit eine Vielzahl von Pseudo-Standards vorgeschlagen und
auch wieder zurückgezogen. Welche Initiative sich durchsetzt, bleibt abzuwarten und ist aufgrund des taktischen
Verhaltens der beteiligten Firmen schwer abzuschätzen. So gibt es auf der einen Seite herstellerübergreifende
Standardisierungskomitees wie die Open Application Group (OAG) oder die Object Management Group (OMG), die
inhaltliche Standards entwickeln. Durch die Vielfalt der Hersteller und damit verbundener Vorschläge blähen sich
diese Standards unweigerlich auf, sodass der praktische Einsatz in Frage gestellt werden kann. Andererseits
könnten sich die Ansätze der marktbeherrschenden Unternehmen als De-facto-Standards etablieren.
Vgl. /Ritt-2000/.
In diesem Kontext soll jedoch auch nicht unerwähnt bleiben, dass andererseits häufig die geringe Qualität der Spezifikationsergebnisse, insbesondere hinsichtlich Eindeutigkeit und Nachvollziehbarkeit, bemängelt wird.
Vgl. /Turo-2002 (S. 4)/.
6.3.5
- 95 -
Modellgetriebene Architektur
Die modellgetriebene Architektur (MDA)1 ist ein Gestaltungsansatz, der sich in einer frühen Phase
befindet. Die Philosophie der MDA besteht in der generativen Softwareentwicklung auf Basis von
UML2. Der grundsätzliche Gedanke ist, die Softwareentwicklung auf eine abstraktere, technologieunabhängige und dadurch flexiblere Ebene zu heben3.
Ein Ziel der modellgetriebenen Architektur ist die Trennung der fachlichen und technischen
Aspekte im Entwurf. Bei einem Wechsel der verwendeten Technologie, beispielsweise der
Implementierungssprache, des Betriebssystems oder der Middleware, kann sich zwar die
technische Realisierung und Darstellung verändern, die fachliche Logik ist aber weiterhin dieselbe.
Die fachlichen Anforderungen werden in einem plattformunabhängigen Modell (PIM)4 erstellt. Das
PIM wird anschließend auf eine bestimmte Technologie in ein plattformabhängiges Modell (PSM)5
überführt. Das PSM lässt sich bei Bedarf weiter verfeinern. Schließlich wird aus diesem Modell
Code generiert. Abbildung 6-6 zeigt eine Übersicht dieses Prozesses.
Zukünftig sollen die Möglichkeiten der automatischen Codegenerierung so gesteigert werden, dass
nur noch ein geringer Anteil in der Zielsprache direkt implementiert werden muss. Langfristig wird
eine vollständige Codegenerierung angestrebt. Die automatische Codegenerierung soll durch die
Anreicherung von UML-Modellen mit Semantik erreicht werden. Hierbei wird das Verhalten von
Objekten durch Zustands- und Aktionsdiagramme modelliert, die durch semantische Ausdrücke
zur Formulierung der Zustandsänderungen ergänzt sind.
Abbildung 6-6: Ablauf der modellgetriebenen Architektur6
1
2
3
4
5
6
MDA, englische Abkürzung für Model Driven Architecture
MDA ist seit der Version 2.0 Bestandteil von UML. Vgl. /OMG-2006a/.
Zum Vergleich wird oft der Übergang von Assembler zu COBOL und später zu C angeführt. Dieser Übergang hob die
Implementierung auf eine höhere Abstraktionsebene, auf der sich der Entwickler nicht mehr um bestimmte Details,
wie beispielsweise die Zuordnung von Variablen zu Speicheradressen, kümmern musste.
PIM, englische Abkürzung für Platform Independent Model
PSM, englische Abkürzung für Platform Specific Model
Vgl. /Fett-2003 (S. 555)/.
- 96 -
Die modellgetriebene Architektur beinhaltet jedoch auch Nachteile1:

In den frühen Phasen muss ein höherer Aufwand für die Erstellung der Modelle betrieben
werden, der sich nur dann auszahlt, wenn die Konzepte tatsächlich umgesetzt werden.

Nicht alle Systembestandteile können gleich gut modelliert und generiert werden. Dadurch besteht die Gefahr, dass parallel zum Modell auch der Quellcode gepflegt werden muss.

Da der Ansatz noch relativ neu ist, ist die Werkzeuglandschaft im Entstehen. Kommerziell
einsetzbare Softwarewerkzeuge für die modellgetriebene Architektur existieren zwar, unterliegen aber hohen Änderungsraten mit teilweise aufwendigem Migrationsaufwand2.
Der Grundgedanke von MDA ist nicht neu – hat sich jedoch bisher in der Praxis nicht durchgesetzt,
obwohl die theoretischen Vorteile anerkannt sind. Ein wesentlicher Grund hierfür war bislang der
Mangel an geeigneten Standards. Die modellgetriebene Architektur kann daher als ein
interessantes Konzept eingestuft werden, das seine Vorteile in der Praxis noch beweisen muss.
6.3.6
Zusammenfassende Bewertung komponentenbasierter Software
Die komponentenbasierte Softwareentwicklung bietet viele Vorteile hinsichtlich einer schnelleren
und einfacheren Entwicklung sowie Wartung. Bis heute fehlen jedoch methodische Standards zur
Beschreibung von Komponenten. Damit wird der Trend zur komponentenbasierten Softwareentwicklung gebremst und das Wirtschaftlichkeitspotenzial nur teilweise ausgeschöpft. In Teilbereichen hat sich die komponentenbasierte Technologie bereits durchgesetzt. Die Arbeit zielt
daher bewusst nicht darauf ab, weitere generalisierte Pseudo-Standards mit fragwürdigem Reifeund Verbreitungsgrad zu definieren.
In der Praxis stellt die komponentenbasierte Softwareentwicklung hohe Anforderungen an die Entwickler und Anwender von Komponenten. Bei der Spezifikation muss von vornherein auf die
Wiederverwendbarkeit geachtet werden. Dies erfordert erfahrene Entwickler und einen Mehraufwand an Zeit und Kosten im aktuellen Projekt, der sich erst in späteren Projekten auszahlt.
Die komponentenbasierte Softwareentwicklung bezieht sich dabei nicht nur auf die Erstellung
einzelner Anwendungen, sondern erstreckt sich auch auf die Erstellung und Nutzung der
informationsund kommunikationstechnischen Frameworks und Software-Architekturen, die im
folgenden Kapitel 6.4 vorgestellt werden.
1
2
Vgl. /Spat-2005a (S. 14)/.
Vgl. z. B. Produkt ArcStyler der Firma Interactive Objects oder das Produkt OptimalJ der Firma Compuware.
- 97 -
6.4 Software-Architekturen
Ähnlich wie in der Architektur von Bauwerken definiert eine Software-Architektur die Gesamtorganisation eines IT-Systems. Sie wird im RM-DP-Modell dem Computational Viewpoint zugeordnet. Eine allgemeingültige Definition des Begriffs Software-Architektur existiert bislang nicht1.
In Anlehnung an Balzert2 wird folgende Definition verwendet: Eine Software-Architektur beschreibt
die Struktur eines Systems mit seinen Komponenten und deren Beziehungen untereinander. Software-Architekturen bieten somit ein Rahmenwerk zur Einbettung von Softwarefunktionen an,
sagen aber nichts über deren Implementierung aus3.
Eine gute Software-Architektur trägt zur Effizienz des Entwicklungsprozesses bei, indem sie Teilaufgaben voneinander entkoppelt und kapselt, um so eine Arbeitsteilung und eine flexible Projektorganisation zu ermöglichen. Eine gute Software-Architektur zeichnet sich durch Robustheit
gegenüber Änderungen, gute Wartbarkeit und hohes Wiederverwendungspotenzial aus4.
Zur Trennung der Abstraktionsstufen bietet sich die Verwendung eines Schichtenmodells5 an.
Jede Schicht wird durch eine definierte Schnittstelle beschrieben, welche die Kommunikation
zwischen der darüber- und darunterliegenden Schicht steuert. Somit lässt sich die Implementierung innerhalb einer Schicht ohne Auswirkungen auf andere Schichten verändern. Die Komponenten einer Schicht greifen in der Regel nur auf die Funktionalitäten der jeweils nächsten Schicht
zu. Innerhalb einer Schicht wird ein Softwaresystem in Module aufgeteilt, die über Schnittstellen
horizontal interagieren. Der Aufbau eines Softwaresystems in Schichten erfordert eine Zuordnung
von Komponenten zu jeweils einer Schicht. Dies erleichtert die Klassifizierung von Komponenten
und impliziert eine formale Abgrenzung ihrer Funktionalität.
Im Software Engineering haben sich Mehrschicht-Architekturen durchgesetzt. Für webbasierte Anwendungen sind primär drei- und vierschichtige Architekturen relevant, die nun vorgestellt werden.
6.4.1
Mehrschicht-Architekturen
6.4.1.1 Zweischicht-Architektur
Bei einer Zweischicht-Architektur ist die Client-Schicht normalerweise auf der Seite des Endgeräts,
während die Persistenzschicht6 auf dem Server lokalisiert ist.

Die Client-Schicht repräsentiert unterschiedliche Zugriffskanäle, die sich aufgrund unterschiedlicher Anwender, Endgeräte, Übertragungswege etc. ergeben, um mit einer Softwareanwendung zu interagieren. Beispiel: Web-Zugriff über einen Web-Browser.

Die Persistenzschicht stellt die Datenspeicherung sicher und steht als Sammelbegriff für die
Funktionalitäten spezifischer Datenbanken. Neben der Datenhaltung fallen darunter auch betriebliche Informationssysteme, wie z. B. EDM-, PDM-, ERP- oder allgemeiner PLM-Systeme,
die auch umfangreiche Anwendungslogik beinhalten können.
1
Das Software Engineering Institute (SEI) der Carnegie-Mellon-Universität listet auf seiner Webseite
</http://www.sei.cmu.edu/architecture/definitions.html/>, letzter Abruf am: 01.05.2008, über fünfzig Definitionen auf.
Vgl. /Balz-2001/.
Vgl. /Reus-2006 (S. 129)/.
Vgl. /Weis-2002 (S. 200)/.
OSI/ISO-Schichtenmodell. Vgl. /Furr-2003 (S. 35)/.
Vgl. /Baue-2001 (S. 115)/.
2
3
4
5
6
- 98 -
Zweischicht-Architekturen verfügen über keine klare Trennung zwischen Darstellung, Geschäftslogik und Datenhaltung. Ein weiterer Nachteil liegt im Zwang zur Nutzung herstellerspezifischer
Prozeduren des Datenbanksystems. Anwendungen, die nicht vom Hersteller des Datenbanksystems sind, können nur mit Anpassungsaufwand in die Datenbanksysteme integriert werden.
6.4.1.2 Dreischicht-Architektur
Die Dreischicht-Architektur eliminiert die Nachteile der Zweischicht-Architektur durch das Einführen
einer dritten, mittleren Ebene zwischen der Client- und der Persistenzschicht. Eine DreischichtArchitektur besteht demnach aus der Client-, Mittel- und Persistenzschicht.

Die Mittelschicht – auch Applikationsschicht genannt – beherbergt die wesentlichen Komponenten zur Implementierung der Anwendungslogik. Hier findet die Programmablaufkontrolle
statt. Dazu werden die Daten aus der Persistenzschicht aufbereitet und an die Präsentationsschicht übergeben sowie Benutzereingaben validiert. Ein optionaler Teil dieser Schicht stellt
die Integration von externen Komponenten und Bestandssystemen her.
Die Trennung von Client- und Geschäftslogik führt zu einer besseren Strukturierung der Architektur, wodurch Wartbarkeit, Fehlerbehebung, Flexibilität, Wiederverwendbarkeit und Nachvollziehbarkeit deutlich verbessert werden. Als weiterer Vorteil ist anzumerken, dass die Trennung
die Skalierbarkeit unterstützt, da sich die Mittelschicht auf verschiedenen Rechnern verteilen lässt.
6.4.1.3 Vierschicht-Architektur
In einigen Softwareanwendungen entsteht in der Client-Schicht hoher, teilweise redundanter
Implementierungsaufwand für jedes verwendete Endgerät. Bei mobilen Endgeräten mit geringen
Ressourcen, z. B. Personal Digital Assistants (PDAs) oder Smartphones1, muss u. U. die Anwendungslogik modifiziert werden. Dies erhöht den Wartungsaufwand und lässt sich durch eine
Auftrennung der Client-Schicht umgehen.

Die Präsentationsschicht beschreibt die Informationsaufbereitung für den Client und die
Interaktion des Nutzers mit dem Softwaresystem. Eine Trennung von Präsentations- und
Mittelschicht dient der Unterstützung mehrerer Präsentationskanäle, wie z. B. verschiedener
Web-Browsertypen oder mobiler Endgeräte. Anpassungen an neue Endgeräte erfordern damit
lediglich Anpassungen in der Präsentationsschicht.
Eine andere Vierschicht-Architektur liegt dann vor, wenn die Mittelschicht aus einem Web- und
einem Applikationsserver besteht. Der Web-Server verfügt über ein Archiv an fertigen HTMLSeiten. Erreicht den Web-Server eine Anfrage vom Client nach einer fertigen HTML-Seite, sendet
der Web-Server diese unmittelbar zurück. Falls die Anfrage nicht direkt beantwortet werden kann,
leitet der Web-Server die Anfrage an den Applikationsserver weiter. Die Aufgabe des Applikationsservers ist es dann unter Nutzung der implementierten Geschäftslogik eine Antwort zu berechnen,
diese an den Web-Server weiterzuleiten, der diese dann an den Client sendet. Der Web- und
Applikationsserver stellt damit die Ausführungsumgebung zur Verfügung.
1
Ein Smartphone vereint den Leistungsumfang eines Mobiltelefons mit dem eines PDAs. Smartphones haben einerseits die Fähigkeit, sich in ein Mobilfunknetz einzuloggen und darüber telefonieren zu können, andererseits haben sie
auch die Fähigkeit, als kleiner Rechner Anwendungen auszuführen, wie dies auch ein PDA kann.
6.4.2
- 99 -
Frameworks
Frameworks sind wiederverwendbare Softwaresysteme von interagierenden Klassen oder
Komponenten, die einen Rahmen für eine Anwendung bieten. Frameworks definieren die Art des
Zusammenwirkens der Software und beinhalten allgemeine Funktionalitäten. Frameworks bestehen aus einer Software-Architektur, die sich durch zusätzliche Komponenten erweitern lässt.
Ein Framework stellt damit ein halb fertiges Architekturgerüst1 für einen Anwendungsbereich dar,
das an die Bedürfnisse und Anforderungen einer konkreten Anwendung angepasst werden muss.
Man unterscheidet horizontale2, vertikale3 und kombinierte4 Frameworks.
Frameworks bieten eine Programmierschnittstelle (API5) und setzen ein definiertes Verhalten
voraus, das durch die zu ergänzenden Softwareelemente eingehalten werden muss. Die Schnittstellen und das Verhalten werden in einem Contract definiert. Wesentlicher Bestandteil des
Contracts ist das Format der Eingabe- und Ausgabedaten.
Der Hauptunterschied zwischen Frameworks und Programmbibliotheken liegt im unterschiedlichen
Kontrollfluss. Bibliotheken werden von Anwendungsprogrammen aufgerufen, die den Programmablauf steuern. Bei Frameworks ist dies genau umgekehrt. Das Framework definiert einen
generischen Kontrollfluss und bietet Ansatzpunkte, an denen die anwendungsspezifische
Funktionalität eingefügt werden kann.
6.4.2.1 Klassenframeworks
Klassenframeworks – auch objektorientierte Frameworks genannt – basieren auf speziellen
Klassenbibliotheken, die ein Softwareentwickler unter Nutzung von Vererbungmechanismen zur
Implementierung eigener Erweiterungen nutzen kann. Klassenframeworks definieren das
Standardverhalten und die Struktur aller Anwendungen mittels einer Gruppe von abgestimmten
abstrakten6 und konkreten7 Klassen. Das Erstellen neuer Anwendungen wird durch Ableitung
abstrakter Frameworkklassen und durch Einbettung anwendungsspezifischer Logik realisiert.
Ein Nachteil der Klassenframeworks ist, dass diese dem Softwareentwickler nur in einem abgeschlossenen Kontext als Basis dienen, aber nicht als Plattform für unabhängig entwickelte oder
frei am Softwaremarkt angebotene Komponenten. Die Wiederverwendung bezieht sich ausschließlich auf die Bibliothek beziehungsweise das Framework, aber nicht auf angekoppelte
Systemerweiterungen. Die starren Strukturen von Klassenframeworks können deshalb zu unvorhergesehenen Problemen in der Entwicklung führen.
6.4.2.2 Komponentenframeworks
Das Konzept der Klassenframeworks wird durch Komponentenframeworks, die auch Application
Frameworks genannt werden, flexibilisiert und ergänzt. Hinsichtlich des Einsatzzwecks werden von
Klassen- und Komponentenframeworks ähnliche Ziele verfolgt. Während bei Klassenframeworks
1
2
3
4
5
6
7
Framework, englisch für Gerüst, Rahmen oder Skelett
Beispiele für horizontale Frameworks sind: Open Step, Weblogic, NetDynamics, CORBA Common Horizontal
Facilities und die Microsoft ActiveX-Architektur.
Ein Beispiel für vertikale Frameworks ist CORBA Common Vertical Facilities.
Ein Beispiel für ein vertikales und horizontales Framework ist der WebSphere Application Server von IBM.
Abkürzung für Application Programming Interface, englisch für Schnittstelle zur Anwendungsprogrammierung. Eine
API ist eine Programmierschnittstelle, die ein Softwaresystem einem anderen Softwaresystem zur Verfügung stellt.
Abstrakte Klassen definieren nur Schnittstellen, die dann durch konkrete Methoden einer Unterklasse gefüllt werden.
Konkrete Klassen sind vollständig implementierte Klassen mit einer bestimmten Funktionalität.
- 100 -
die Wiederverwendbarkeit von Programmbestandteilen lediglich auf Klassenebene vollzogen wird,
lassen sich bei Komponentenframeworks vollständige Komponenten wiederverwenden.
Softwarekomponenten benötigen eine Ausführungsumgebung in Form eines Applikationsservers
oder eines Frameworks, die fachunabhängige Leistungen bereitstellen. Da die angebotenen
Funktionalitäten nicht mehr in den Komponenten selbst realisiert werden müssen, lässt sich die
Softwareentwicklung vereinfachen und beschleunigen. Damit die Komponenten die angebotene
Funktionalität nutzen können, müssen Vereinbarungen, die Contracts, getroffen werden. Komponenten werden immer für genau einen Typ eines Komponentenframeworks realisiert.
Komponenten, die innerhalb eines Komponentenframeworks verwendet werden, können selbst
wieder Frameworks sein, wodurch ein rekursives Prinzip unterstützt wird.
6.4.3
Serviceorientierte Architekturen
Die Grundidee einer serviceorientierten Architektur (SOA1) – auch diensteorientierte Architektur
genannt – ist, Systeme zu konzipieren, die ihre Dienste über klar definierte Schnittstellen und standardisierte Technologien zur Verfügung stellen2. Der Ansatz einer serviceorientierten Architektur
basiert auf der Trennung von Zuständigkeiten nach fachlichen Gesichtspunkten sowie in der
Kapselung technischer Details. Das Ziel serviceorientierter Architekturen ist, eine bessere Struktur
der Systeme, vor allem in Bezug auf Wartbarkeit und Erweiterbarkeit, zu erhalten sowie die
Wiederverwendung einzelner Dienste zu erhöhen. Der Grundgedanke der SOA entspricht demnach dem der Komponentenframeworks bzw. der komponentenbasierten Anwendungssysteme3.
Ein Service ist im SOA-Kontext ein Dienst, der von einer Softwarekomponente bereitgestellt wird.
Demnach werden bei der SOA neue Anwendungen aus einzelnen Services erstellt. Ein gemäß
SOA bereitgestellter Service kann selbst wiederum andere Services aufrufen, um seine Aufgabe
zu erfüllen. SOA unterstützt die lose Kopplung. Im Gegensatz zur engen Kopplung lassen sich lose
gekoppelte Komponenten relativ leicht voneinander lösen und flexibel kombinieren. Die lose
Kopplung ist grundsätzlich zu bevorzugen, da diese flexibler bei Änderung ist. Die
Implementierung einer losen Kopplung ist allerdings aufwendiger, als bei einer engen Kopplung.
SOA sind weder ein Standard noch eine Technologie, sondern vielmehr ein konzeptioneller Ansatz
zur Realisierung von Software-Architekturen4. Bisher gibt es noch keine vollständige und umfassende Softwareunterstützung für alle Aspekte von SOA. Die angebotenen Produkte decken
bisher vor allem die Infrastrukturkomponenten ab5. SOAs werden oft mit Web-Services in Verbindung gebracht; diese Kombination ist aber nicht zwingend. Web-Services bieten eine geeignete
Technologie, um SOAs zu realisieren. Sie lassen sich aber auch mit anderen Technologien, wie
beispielsweise CORBA oder EJB, umsetzen.
1
2
3
4
5
SOA, englische Abkürzung für Service Oriented Architecture
Vgl. /Spat-2006/Spat-2005b/.
Das Reference Model for Service Oriented Architecture 1.0 wurde 2006 von der OASIS vorgestellt. Das Modell dient
in erster Linie zur Begriffsklärung. Vgl. /OASI-2006/.
Vgl. /Capg-2007 (S. 32)/Capg-2006 (S. 18)/Capg-2005 (S. 16)/ Spat-2005a (S. 31)/.
SAP bietet mit der Produktsuite NetWeaver eine Integrationsplattform. Herzstück ist der Web Application Server, der
als Ablaufumgebung für alle NetWeaver Komponenten sowie für die ERP-Produkte von SAP dient. Bei IBM wird SOA
als Weiterentwicklung der EAI-Infrastruktur verstanden und unter der Bezeichnung WebSphere vermarktet. Zentrales
Konzept ist der sogenannte Enterprise Service Bus, der notwendige Aufgaben wie Kommunikation, Choreographie,
Sicherheit und weitere Querschnittsdienste übernimmt. Microsoft bietet mit .NET eine Entwicklungs- und
Integrationsplattform, die den Aufbau einer SOA durch Web Services und SOAP unterstützt. Mit BizTalk wird ein
Produkt für die Integration und Orchestrierung der Services bereitgestellt.
- 101 -
6.5 Softwaretechnologien
Internetbasierte Dienste lassen sich mit verschiedenen Softwaretechnologien realisieren, die im
RM-DP-Modell dem Technology Viewpoint zugeordnet sind. Die im vorangegangenen Kapitel 6.4
vorgestellten Software-Architekturen werden im Folgenden technische Standards zugeordnet und
diese kurz beschrieben. Eine besondere Rolle nehmen hierbei die Komponententechnologien ein,
die sich wie folgt gliedern lassen:

Komponententechnologien für Clients

Komponententechnologien für Server

Komponententechnologien zur Kommunikation
6.5.1
Komponententechnologien für Clients
Komponententechnologien auf der Client-Seite werden hauptsächlich für grafische Benutzeroberflächen (GUI1) verwendet. Es existieren jedoch auch nichtvisuelle Komponenten. Bei elektronischen Diensten ist es oft notwendig, dynamisch veränderbare Inhalte darzustellen. Mit der
Dokumentenbeschreibungssprache HTML ist dies nicht hinreichend realisierbar, da HTML lediglich
die passive Anforderung und Darstellung von statischen Dokumenten erlaubt. Im Folgenden sollen
die wichtigsten Technologien zur Erstellung dynamischer Anwendungen vorgestellt werden.
6.5.1.1 JavaBeans zur Erstellung von Java-Applets
JavaBeans2 sind wiederverwendbare Softwarekomponenten und finden vor allem bei GUIs Anwendung. JavaBeans lassen sich grafisch konfigurieren, in die Java-Entwicklungsumgebungen
importieren und sind wie Java-Standard-GUI-Elemente nutzbar. JavaBeans sind – wie alle JavaProgramme – plattformunabhängig. Es muss lediglich eine Java Virtual Machine (JVM) auf dem
Endgerät verfügbar sein. In Java erstellte Applikationen werden durch den JVM-Interpreter abgearbeitet, wodurch eine Unabhängigkeit von den eingesetzten Endgeräten erreicht wird.
JavaBeans haben allerdings auch Nachteile. Durch die interpretierte Ausführung ist die Ausführungsgeschwindigkeit gegenüber kompilierten C/C++-Anwendungen langsamer. In Tabelle 6-11
sind die Vor- und Nachteile von JavaBeans zur Erstellung von Java-Applets gegenübergestellt.
Vorteile
JavaBeans sind als Java-Applet offline nutzbar
gute Entwicklungswerkzeuge sind vorhanden
einfache Technik, ohne Serverkomponenten
Nachteile
unter Umständen lange Ladezeit der Applets
begrenzte Funktionalität bei begrenzter
Rechen- und Speicherkapazität des Endgeräts
langsamere Ausführungsgeschwindigkeit gegenüber kompilierten C/C++-Anwendungen
Tabelle 6-11: Vor- und Nachteile von JavaBeans zur Erstellung von Java-Applets
1
2
GUI, Abkürzung für Graphical User Interface, englisch für grafische Benutzerschnittstelle.
Trotz Namensähnlichkeit haben JavaBeans und Enterprise JavaBeans (EJB) wenig gemeinsam. Während
JavaBeans vorrangig auf der Client-Seite zur Anwendung kommen, sind EJB ein serverseitiges Komponentenmodell.
- 102 -
6.5.1.2 ActiveX
In Konkurrenz zum Konzept der Java-Applets wurde von Microsoft ein anderes Verfahren entwickelt, das unter der Bezeichnung ActiveX firmiert. ActiveX ist weder eine Programmiersprache
noch eine Internettechnologie, sondern bietet lediglich Mechanismen an, um auf Basis des Microsoft-Betriebssystems Windowsprogrammen eine Pseudo-Internetfähigkeit zu verleihen1. ActiveXKomponenten laufen in ActiveX-Containern ab, welche die notwendige Ablaufumgebung bereitstellen. Auch der Web-Browser von Microsoft kann als ActiveX-Container fungieren. So können
ActiveX-Komponenten zur Erweiterung von Webseiten genutzt werden. Der grundlegende Unterschied zum Java-Konzept liegt darin, dass ActiveX-Objekte plattformabhängigen Maschinencode
enthalten. Sie lassen sich daher nur auf Intel x86-kompatiblen Plattformen unter Windows beziehungsweise im Internet Explorer von Microsoft ausführen.
Die ActiveX-Technologie hat einige schwerwiegende Nachteile. ActiveX ist nicht auf heterogenen
Rechnerplattformen lauffähig, sondern auf Windows-Systeme beschränkt. Zudem verfügt ActiveX
über das uneingeschränkte Zugriffsrecht auf alle Funktionen und Ressourcen des Clients, was ein
ausgesprochenes Sicherheitsrisiko darstellt2. Böswillig programmierte ActiveX-Komponenten
können einen vollen Zugriff auf den Client-Rechner erlangen und beispielsweise beliebige Dateien
lesen, verändern oder ins Internet übermitteln. Daher wird ActiveX weder in der Industrie noch in
dieser Arbeit favorisiert. Tabelle 6-12 fasst die Vor- und Nachteile von ActiveX zusammen.
Vorteile
Nachteile
ActiveX-Komponenten sind offline nutzbar
Plattformabhängigkeit
einfache Erstellung von Anwendungen
gute Entwicklungswerkzeuge
uneingeschränkter Zugriff auf alle Funktionen
und Ressourcen des Clients (IT-Sicherheit)
einfache Technik, ohne Serverkomponenten
unter Umständen lange Ladezeit
Tabelle 6-12: Vor- und Nachteile von ActiveX
6.5.1.3 JavaScript und VisualBasic-Script
Die Skriptsprachen JavaScript3 und VisualBasic-Script sind interpretierte Programmiersprachen,
die entwickelt wurden, um kleine aktive Programmfragmente in HTML-Seiten einzubauen, ohne
eine Java-Applikation erstellen zu müssen. Diese aktiven Inhalte bieten unter anderem die
Möglichkeit, mit einfachen Mitteln ein Maß an Flexibilität und Dynamik herzustellen.
Skript-Programme haben den Vorteil, dass sie z. T. erheblich einfacher und schneller zu
implementieren sind, da das Kompilieren entfällt und ein sofortiger Test möglich ist. Die in den
Skriptsprachen geschriebenen Funktionen werden in eine HTML-Seite mithilfe spezieller
Markierungen, sogenannter Tags, als Text eingebettet oder in separaten Dateien hinterlegt und
später beim Laden durch den Web-Browser interpretiert. Die Ausführung aktiver Inhalte auf der
Client-Seite ist abhängig von der Konfiguration des Web-Browsers.
1
2
3
Vgl. /Göhr-2001 (S. 47)/.
Vgl. /Göhr-2001 (S. 47)/.
Trotz der Namensähnlichkeit haben JavaScript und Java keine Gemeinsamkeiten.
6.5.2
- 103 -
Komponententechnologien für Server
Das Spektrum der Softwaretechnologien, die zur Bereitstellung von Mehrwertdiensten auf ServerSeite angeboten werden, ist breit gefächert und auf unterschiedliche Anwendungsfälle ausgerichtet. Es reicht von einfachen CGI-Skripten bis hin zu mächtigen Plattformen wie beispielsweise .NET. Im Folgenden werden die wichtigsten Komponententechnologien für Server vorgestellt.
6.5.2.1 Common Gateway Interface (CGI)
Die erste Möglichkeit, um nichtstatische HTML-Inhalte über das Internet anzubieten, bot das
Common Gateway Interface (CGI). Die CGI-Schnittstelle bietet eine einfache Möglichkeit, um
Programme oder Skripte auf Web-Servern bereitzustellen, die von HTML-Dateien aus aufgerufen
werden können. Auf dem Web-Server werden dann dynamische HTML-Dokumente in Abhängigkeit der Übergabewerte generiert und an den Web-Browser zurückgesandt1.
Zur Verbreitung des Common Gateway Interface (CGI) hat neben der einfachen Handhabung auch
die Unterstützung durch alle gängigen Web-Server beigetragen. Ein Nachteil von CGI ist die Performanz sowie das fehlende Sitzungsmodell, da bei jeder Anfrage die zugehörige Anwendung als
eigener Prozess gestartet wird. Dies verschlechtert die Reaktionszeit für Benutzeranfragen.
Das Spektrum einsetzbarer Programmiersprachen ist groß, da lediglich die CGI-Konventionen einzuhalten sind. Hauptsächlich finden Skriptsprachen, wie z. B. Perl Verwendung. Es sind aber auch
andere Programmiersprachen wie C, Pascal oder Java nutzbar2.
6.5.2.2 Eingebettete serverseitige Skriptsprachen
Eine Weiterentwicklung von CGI stellen eingebettete serverseitige Skriptsprachen dar, die sich in
mehrschichtigen Architekturen wiederfinden. Die Anfragen der Clients werden vom Web-Server an
den Application-Server der jeweiligen Skriptsprache weitergeleitet und dort verarbeitet. Der
Application-Server stellt eine Ausführungsumgebung für die eingebetteten Skripte bereit, die unter
anderem das Sitzungsmanagement verwaltet. Die Programmlogik wird in Form von Tag-basierten
Skriptfragmenten in HTML-Seiten eingefügt. Typische Vertreter der eingebetteten Skriptsprachen
sind in Tabelle 6-13 aufgeführt.
JSP und ASP finden in den Plattformen Java EE und .NET Verwendung. Sie können jedoch auch
als eingebettete Skriptsprachen unabhängig betrieben werden.
1
2
Vgl. /Fran-2000 (S. 73)/.
Vgl. /Fran-2000 (S. 75)/Göhr-2001 (S. 47)/.
Technologie
- 104 -
Beschreibung
Hypertext PrePHP besitzt einen Leistungsumfang, der z. B. auch mit CGI und Perl realisiert
processor (PHP) werden kann. Der PHP-Interpreter ist auf das Web-Publishing ausgerichtet.
Servlet
Servlets1 sind Java-Klassen, die aus übergebenen Parametern sowie unter Ausnutzung von Cookies und Session-Variablen dynamische Webseiten in HTML
oder XML erzeugen können. Servlets basieren auf der Programmiersprache
Java und nutzen die Java-APIs wie Datenbankzugriff, Dateizugriff etc. Servlets
können nur innerhalb eines Containers (z. B. Web-Browser) ablaufen. JavaServlets unterscheiden sich von der CGI-Technologie durch den Integrationsgrad in die Serverapplikation. Während bei CGI-Skripten jeweils ein neuer
Prozess durch das Betriebssystem gestartet wird, laufen Servlets in einer
Instanz der Serverapplikation ab. Servlets erreichen dadurch eine deutlich
bessere Performance als Scriptsprachen.
JavaServer
Pages (JSP)
JSP ist eine Technologie, die zur einfachen dynamischen Erzeugung von HTMLund XML-Ausgaben eines Web-Servers dient. Sie erlaubt es, Java-Klassen und
spezielle JSP-Aktionen in einen statischen Inhalt einzubetten. Im Unterschied zu
den Servlets steht bei JSP das Seitendesign im Vordergrund, während kleine
eingebettete Java-Klassen lediglich zur Erzeugung des dynamischen Inhalts
notwendig sind. Dadurch lassen sich JSP-Seiten leichter layouten als Servlets.
Tabelle 6-13: PHP, ASP und Java-Servlets
6.5.2.3 COM, COM+ und DCOM
Die Komponentenmodelle COM2, COM+ und DCOM3 sind unabhängige und proprietäre Plattformtechnologien von Microsoft. COM, COM+ und DCOM repräsentieren hierbei verschiedene Entwicklungsstufen. COM entstand aus einer weiteren Microsoft-Technologie, dem Object Linking and
Embedding (OLE).
Der Aufruf eines Dienstes einer Komponente erfordert relativ viel zusätzlichen Code, was das
COM-Komponentenmodell schwer benutzbar und den Quellcode weniger lesbar macht. Aus
diesem Grund erweiterte Microsoft für COM+ die eigenen Übersetzer derart, dass sie den entsprechend komplexen Code aus einfacherem Quellcode generierten. Hierdurch wurde es zwar
deutlich leichter, in den jeweiligen Sprachen Komponenten zu entwickeln, die Übersetzer waren
jedoch durch zusätzliche Schlüsselwörter nicht mehr standardkonform. Mit DCOM wurde ein
Protokoll geschaffen, um Programmkomponenten über ein Netzwerk kommunizieren zu lassen.
1
2
3
Bei dem Begriff Servlets handelt es sich um eine Wortkreation aus den Begriffen Server und Applet. Das serverseitige Applet nennt man Servlet.
COM, englische Abkürzung für Component Object Model.
DCOM, englische Abkürzung für Distributed Component Object Model.
- 105 -
6.5.2.4 Sun Microsystems Sun ONE Initiative
Sun ONE ist eine Initiative von Sun Microsystems, die Architektur, Plattform und einen Entwicklungsprozess für die Bereitstellung von „Services on Demand“ umfasst1. Zu der Initiative gehören:

Sun ONE Server: Betriebssysteme und Middleware

Sun ONE Development Tools: Unterstützung für die Entwicklung von Anwendungen

Java EE: Entwicklungsplattform und Framework für Unternehmensanwendungen
Die Anwendungen basieren auf der Programmiersprache Java. Der Java Code wird in eine binäre
Form compiliert und von der Java Virtual Machine (JVM) ausgeführt. Aus der hohen Verfügbarkeit
von JVM für viele Systemplattformen resultiert ein hoher Grad an Plattformunabhängigkeit für
Java-basierte Anwendungen.
Enterprise JavaBeans (EJB) ist eine serverseitige Komponentenarchitektur. Die EJB-Spezifikation
hat das Ziel, die Erstellung von Serverkomponenten zu ermöglichen, die ohne Anpassungen auf
verschiedenen Plattformen und Applikationsservern einsetzbar sind.
Die Java EE-Architektur2 bildet den Kern von Sun ONE. Java EE besteht aus einem ApplicationServer, der jeweils einen Container für Web-Anwendungen und einen für Enterprise JavaBeans
(EJB) 3 enthält. Der Container für Web-Anwendungen 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. Die Java Server Pages (JSP), 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 Container für Enterprise JavaBeans umfasst die Enterprise JavaBeans (EJB) und stellt eine
abstrahierte, plattformunabhängige Sicht auf die Dienste, wie z. B. Persistenz, Messaging etc.,
bereit. Die Dienste können je nach Applikationsserver unterschiedlich implementiert sein. Ein Java
EE-Application-Server hält den ausgeführten Anwendungen eine Vielzahl von Programmierschnittstellen (APIs) zur Integration und Kommunikation bereit4.
6.5.2.5 Microsoft .NET Initiative
Da alle drei COM-Technologien in ihrer Entwicklung immer schwieriger zu handhaben waren und
da sich durch die Web-Service-Technologie neue Anforderungen ergaben, die nur schwer durch
die bisherige Technologie realisierbar waren, startete Microsoft die .NET Initiative. Die Zielsetzung
der .NET Initiative ist die Schaffung eines integrierten Plattformkonzepts für die Entwicklung von
Anwendungen. Der Ansatz umfasst verschiedene Technologien und Softwareprodukte:
1
2
3
4
Vgl. /Sun-2002/.
Vgl. /Sun-2007/.
Trotz des verwirrenden Namens sind Enterprise JavaBeans keine JavaBeans. Folgende Punkte unterscheiden die
beiden Komponententechnologien voneinander: Enterprise JavaBeans sind keine visuellen Komponenten, Enterprise
JavaBeans laufen auf dem Server ab und die JavaBeans-Spezifikation gilt nicht für Enterprise JavaBeans.
Z. B. JavaMail API (Framework für e-Mail und Messaging Anwendungen), JNDI API (Zugriff auf Directory Services)
und JDBC API (Zugriff auf Datenbanken).
- 106 -

Windows-Betriebssysteme: Vista, XP, Server 2003, …

.NET Enterprise Server: Groupwareserver Exchange, EAI-Plattform BizTalk, …

.NET My Services: verschiedene von Microsoft bereitgestellte Web-Services

.NET Framework: Ausführungsumgebung Common Language Runtime (CLR) für unterschiedliche Programmiersprachen und 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 Systems (CTS) unterstützen. Die Compiler der einzelnen
Programmiersprachen erzeugen mit der Microsoft Intermediate Language (MSIL, IL) einen
prozessorunabhängigen Zwischencode, der im Gegensatz zum Bytecode von Java direkt lesbar
ist. Die Ausführung von Programmen erfolgt durch die Common Language Runtime (CLR), die Bestandteil einer Ausführungsplattform ist. Die Erstellung webbasierter Anwendungen erfolgt in der
.NET-Plattform mittels einer Weiterentwicklung der Active Server Pages (ASP), dem ASP.NET. Die
Anwendungsintegration in .NET kann mittels verschiedener Technologien erfolgen: Web-Services,
Middleware COM+, Datenbank-Schnittstelle ADO.NET, Microsoft Message Queue (MSMQ) und
anderen.
6.5.2.6 CORBA und CORBA Component Model
Die Common Object Request Broker Architecture (CORBA) ist ein Standard der Object
Management Group (OMG) für die Kommunikation zwischen verteilten und heterogenen Objekten.
Der Ansatz der OMG zur Entwicklung einer offenen Infrastruktur für verteilte Objekte ist, im
Gegensatz zum Component Object Model von Microsoft, ein offener Standard. Die Grundlage für
CORBA bildet die Object Management Architecture, deren einzelne Komponenten der Object
Request Broker, die Object Services, die Common Facilities und die Application Objects sind.
Das CORBA Component Model basiert auf den gleichen Grundgedanken wie Enterprise
JavaBeans und kann deshalb als programmiersprachenunabhängige Obermenge der EJBSpezifikation betrachtet werden. Das CORBA Component Model geht von einer Architektur aus, in
der ein Container existiert, der die eigentliche Komponente beinhaltet. Ein weiterer Aspekt ist die
Kompatibilität und Interoperabilität zu anderen Komponentenmodellen, insbesondere zu Enterprise
JavaBeans, und schließlich die Sprachunabhängigkeit der Realisierung, wie dies auch schon bei
CORBA der Fall ist. Es wurden die Programmiersprachen C, C++ und CORBA spezifiziert.
Als Standard für die Interoperabilität von Anwendungen hat sich CORBA nicht durchgesetzt. Es ist
komplex, kostenintensiv und mittlerweile veraltet1. Für die Integration bereits bestehender Anwendungen hat diese Technologie jedoch noch Relevanz.
6.5.3
Komponententechnologien zur Kommunikation
Das Grundmuster heutiger Kommunikationsstandards basiert auf Remote Procedure Calls (RPC2).
Mithilfe von RPC können über ein Netzwerk Funktionsaufrufe auf entfernten Rechnern durchgeführt werden. Damit lassen sich Funktionen im Netzwerk verteilen, ohne sich um die Mechanismen des Verbindungsaufbaus und -abbaus, die Netzwerktopologie und die automatische Konvertierung von Parametern und Rückgabewerten kümmern zu müssen.
1
2
CORBA wird in der aktuellen SAGA-Version nicht mehr als Standard geführt. CORBA hatte in der Vergangenheit
jedoch seine Berechtigung und unterliegt somit dem Bestandsschutz. Vgl. /KBSt-2006/.
Remote Procedure Calls, englisch für Aufruf einer fernen Prozedur
- 107 -
Die Grundlage von RPC bildet die Interface Definition Language (IDL). IDL ist eine Sprachsyntax
zur Beschreibung von Schnittstellen einer Softwarekomponente. Die IDL dient der Beschreibung,
nicht jedoch der Formulierung von Algorithmen, und ist damit wesentlich einfacher als der Umgang
mit TCP/IP-Sockets (siehe Abbildung 6-7).
Aufruf
Client
Client
Stub
Stub
Netzwerkkommunikation
Server
Server
Skeleton
Skeleton
Object Request Broker
Generierung
IDL
IDL
Abbildung 6-7: Kommunikation in verteilten Systemen unter Nutzung der IDL
6.5.3.1 COM, COM+ und DCOM
Microsoft bietet eine Reihe von Technologien an, die beim Windows-Betriebssystem mitgeliefert
werden. Diese Technologien reichen von clientseitigen Lösungen wie ActiveX-Komponenten über
die Kommunikationsprotokolle von DCOM bis hin zu serverseitigen Komponentenmodellen für den
Microsoft Transaction Server. Der Vorteil der Nutzung von Microsoft-Technologien ist die sehr gute
Integration in das Betriebssystem Windows. Der Nachteil dieser Technologien ist die Fixierung auf
Microsoft. Andere Plattformen werden nicht explizit unterstützt.
6.5.3.2 .NET Remoting
Anders als der Vorgänger DCOM ist die neue Technologie .NET Remoting nicht auf ein bestimmtes Übertragungsformat und -protokoll festgelegt und bietet eine Vielzahl von Aktivierungsund Konfigurationsoptionen. Im Gegensatz zu den standardisierten XML-basierten Web-Services
ist .NET Remoting allerdings ein proprietäres Fernaufrufkonzept, bei dem der Client Teile der
Implementierung des Servers kennen muss. Dies ist ein Schwachpunkt von .NET, da es dem
Konzept der losen serviceorientierten Kopplung nicht entspricht.
6.5.3.3 Object Request Broker von CORBA
Der Object Request Broker (ORB) von CORBA dient zur Vermittlung der entfernten Methodenaufrufe, z. B. zwischen Client und Komponente oder zwischen der Komponente und den CORBAServices. Dabei wird zur Übertragung das General Inter-ORB Protocol (GIOP) verwendet. Als
Interface Definition Language dient die CORBA IDL.
6.5.3.4 Remote Method Invocation
Remote Method Invocation (RMI) ist der Aufruf einer Methode eines entfernten Java-Objekts.
Entfernt bedeutet dabei, dass sich das Objekt in einer anderen virtuellen Maschine befindet. Die
virtuelle Maschine kann auf einem entfernten oder auf dem lokalen Rechner ablaufen. Der Aufruf
eines lokalen Objekts unterscheidet sich nicht vom Aufruf eines entfernten Objekts. Allerdings
müssen Besonderheiten, wie z. B. ein Verbindungsabbruch, bei der Entwicklung eines Dienstes
entsprechend berücksichtigt werden.
- 108 -
Das Remote Method Invocation Internet Inter-ORB Protocol (RMI-IIOP) ist integraler Bestandteil
von Java EE. Über RMI-IIOP können Java EE-Applikationen oder Applikationskomponenten mit
CORBA-Komponenten kommunizieren, falls auf den zugehörigen Applikationsservern die geeigneten Object Request Broker zur Verfügung stehen. Als Interface Definition Language dienen
die Java Interfaces.
Bei der Client-Server-Kommunikation sind Besonderheiten zu beachten. Firewalls können die
statusbehaftete Kommunikation per RMI verhindern, daher ist dieses Protokoll im WAN1 ungeeignet. Daneben existiert keine garantierte Systemverfügbarkeit, was eine synchrone Kommunikation via RMI erschwert. Für eine Kommunikation im LAN gilt, dass von der Kommunikation betroffene Firewalls entsprechend zu konfigurieren sind.
6.5.4
Web-Services
Aufgrund der Bedeutung der Web-Services für die vorliegende Arbeit sind deren Konzepte im
folgenden Kapitel geschlossen und übersichtlich dargestellt. Die technische Grundlage für WebServices bildet die Extensible Markup Language (XML), die dazu verwendet wird, Daten plattformunabhängig zu übertragen und darzustellen. Die Kommunikation von Web-Services basieren auf
Remote Procedure Calls. Von der Softwaretechnologie her betrachtet, sind Web-Services daher
nichts Neues. Der entscheidende Unterschied der Web-Services gegenüber den in Kapitel 6.5.3
vorgestellten Kommunikationstechnologien liegt in der Verwendung des Ports 80. Dieser HTTPProtokoll-Port liegt auch dem World Wide Web als Basisprotokoll zugrunde und ist in den meisten
Firewalls bereits freigeschaltet. In Abbildung 6-8 der Protokoll-Stack von Web-Services zusammengefasst dargestellt.
Abbildung 6-8: Protokoll-Stack von Web-Services
1
Ein Weitverkehrsnetz oder auch Weitbereichsnetz (engl. Wide Area Network, abgekürzt WAN) ist ein Rechnernetz,
das sich im Gegensatz zu einem LAN über einen sehr großen geografischen Bereich erstreckt.
- 109 -
6.5.4.1 Extensible Markup Language
Die Extensible Markup Language (XML) ist eine Metasprache für das Definieren von Dokumenttypen. Durch die Trennung von Inhalt (Dokument, Datenbank), Struktur (DTD, XML) und Layout
(XML, XSL) kann ein XML-Dokument von verschiedenen Empfängern, wie z. B. Webseiten, PDAs,
Smartphones etc., genutzt werden. XML unterstützt damit den strukturierten Informationsaustausch. Die Struktur der übertragenen Informationen liegt bereits in den ausgetauschten
Dokumenten vor und kann vom Empfänger direkt interpretiert werden, unabhängig davon, welches
System er einsetzt. Komplexe Einigungen auf verwendete Datenbankstrukturen entfallen somit1.
Beim Daten- und Informationsaustausch über Firewalls, in heterogenen Netzen oder bei der Kopplung unterschiedlicher Komponentenstandards wie CORBA und DCOM bietet die Kommunikation
über XML ebenfalls Vorteile2. Es gibt jedoch auch Fälle, bei denen das XML-Format den Anforderungen nicht gerecht wird. So sind z. B. die Dateigrößen von XML-Dateien mitunter ein Problem.
6.5.4.2 SOAP
SOAP3 ist ein vom W3C standardisiertes Protokoll für entfernte Methodenaufrufe. SOAP stützt sich
auf die Dienste anderer Standards, wie etwa XML, zur Repräsentation der Daten und auf das
Internet-Protokoll zur Nachrichtenübertragung ab. SOAP ist daher selber keine Spezifikation eines
Transportprotokolls, sondern enthält eine Bindung an HTTP. Diese Bindung legt fest, wie SOAPNachrichten mithilfe von HTTP übertragen werden können. Die Nachricht, die vom Client zum
Server gesandt wird, heißt SOAP-Request, die Nachricht, die vom Server zum Client zurückgesendet wird, heißt SOAP-Reply. Die versandten Nachrichten sind XML-Dokumente und werden
in der SOAP-Terminologie als Envelopes bezeichnet. Prinzipiell kann SOAP auch in Verbindung
mit anderen Transportprotokollen, wie etwa SMTP, eingesetzt werden. Es müssen dann entsprechende Bindungen spezifiziert werden.
Prinzipiell soll der SOAP-Standard garantieren, dass der Austausch von SOAP-Nachrichten auch
dann funktioniert, wenn die austauschenden Komponenten unterschiedliche Software verwenden.
In der Praxis existieren allerdings zwei Hauptquellen für Interoperabilitätsprobleme: Zum einen ist
der XML-Schema-Standard dermaßen umfassend, dass es durchaus vorkommt, dass unterschiedliche SOAP-Werkzeuge unterschiedliche Teile des Standards unterstützen. Zum anderen bestehen in der Praxis auch Unterschiede in Bezug auf die Abdeckung der anderen EncodingVarianten. Es kann daher vorkommen, dass eine SOAP-Nachricht, die von einem System erzeugt
wird, von einem anderen System nicht gelesen oder verarbeitet werden kann. Die Web Services
Interoperability Organization (WS-I)4 adressiert solche Probleme.
1
2
3
4
Mit XML-Schemata lässt sich die Struktur von XML-Dokumenten beschreiben. Ein Schema legt demnach das Format
der XML-Daten fest. Wenn Anwendungen unterschiedliche XML-Schemata verwenden, kann die Konvertierung von
einem Format in ein anderes notwendig werden. Diese Formatkonvertierung erfolgt über die durch die W3C definierte
Sprache XSLT. Es exsistieren jedoch auch noch andere Standards, wie z. B. XLink oder XSL-FO.
Vgl. /Quan-2003 (S. 31)/.
Ursprünglich war SOAP die Abkürzung für Simple Object Access Protocol (englisch für einfaches Objekt-ZugriffsProtokoll). Seit der aktuellen Version 1.2 ist dies jedoch offiziell keine Abkürzung mehr, da SOAP nicht mehr nur dem
Zugriff auf Objekte dient. Vgl. </http://www.w3.org/TR/soap/>, letzter Abruf am: 01.05.2008.
Vgl. </http://www.ws-i.org/>, letzter Abruf am: 01.05.2008.
- 110 -
6.5.4.3 Web Services Description Language
Während SOAP die Formate der übertragenen Nachrichten für einen XML-basierten entfernten
Methodenaufruf festlegt, dient die Web Services Description Language (WSDL)1 der formalen,
programmiersprachunabhängigen Beschreibung der Web-Service-Schnittstelle. Dazu gehört insbesondere die Definition zusammengesetzter Datentypen sowie der bereitgestellten Methoden,
Parameter und Rückgabewerte. Mit einer solchen API ist ein Service vollständig beschrieben, zumindest, was seine syntaktischen Eigenschaften angeht. WSDL unterstützt allerdings keine tiefer
gehende semantische Servicebeschreibung. Moderne Entwicklungsumgebungen generieren die
WSDL-Schnittstellenbeschreibung automatisch aus der Klassendefinition und erzeugen darüber
hinaus die notwendigen Rumpfprozeduren zur komfortablen Nutzung der Web-Services.
6.5.4.4 Universal Description, Discovery and Integration
Die Grundidee von Universal Description, Discovery and Integration (UDDI) besteht darin, eine
Registrierungsfunktionalität von Web-Services in zentralen Verzeichnissen zur Verfügung zu
stellen. Bei einer solchen Registrierung können detaillierte Informationen über den Service angegeben werden, die sich von potenziellen Nutzern auswerten lassen2.
Obgleich UDDI von Beginn an als Bestandteil der Web-Service-Technologie angesehen wurde, hat
dieser Standard bis heute nicht die gleiche Akzeptanz und Relevanz erreichen können wie SOAP
und WSDL. Einige Experten bezweifeln, dass bei den aktuellen Einsatzszenarien für Web-Services
die manuelle oder (semi-) automatische Suche nach Services benötigt wird3. Stattdessen wird eher
erwartet, dass Web-Services zunächst zur Integration mit bekannten Partnern eingesetzt werden,
sodass eine Suche nach im Internet erhältlichen Diensten unwahrscheinlich erscheint.
Auch wenn UDDI bisher noch keine große Verbreitung gefunden hat, könnte Registrierung und
Suche langfristig auch für die Web-Service-Technologie relevant werden. UDDI ermöglicht die
Entkopplung von Services durch URI-Endpunkte4. So wie ein Domain Name System (DNS) eine
symbolische Webadresse in eine IP-Adresse umsetzt, kann UDDI symbolische Servicebezeichnungen auf konkrete Endpunkte von Serviceimplementierungen abbilden. Dies unterstützt
die lose Kopplung von Systemen und erleichtert den Austausch konkreter Implementierungen.
6.5.5
Zusammenfassende Bewertung der Komponententechnologien
Ein wichtiger Aspekt bei der Auswahl einer geeigneten Komponententechnologie ist die Zielplattform. Wenn nur Windows als Zielplattform vorgesehen ist, verfügen die Microsoft-Technologien
über den großen Vorteil, dass sie optimal in die Systemumgebung integriert sind.
Wenn jedoch Portabilität wichtig ist, bieten Java-basierte Technologien Vorteile: Java ist plattformunabhängig, unterstützt das objektorientierte Paradigma, die Ausführungsumgebungen sind stabil,
es existieren viele frei sowie kommerziell verfügbare APIs und nicht zuletzt besitzen eine Vielzahl
von Entwicklern Java-Kenntnisse. Die Orientierung auf eine Mittelschicht und die Verwendung von
Java bedeuten in der Regel den Einsatz von Java EE. Damit erhält man ein detailliertes
Entwicklungs-Paradigma und zugleich ein Application Framework zur Implementierung.
1
2
3
4
WSDL wurde ursprünglich von Ariba, IBM und Microsoft entwickelt und wird heute vom W3C vorangetrieben.
Seit dem Jahr 2002 wird UDDI beim Standardisierungsgremium OASIS weiterentwickelt. Vgl. /OASI-2006/.
Vgl. /Quan-2003 (S. 35)/.
Uniform Resource Identifier (URI), englisch für einheitlicher Bezeichner für Ressourcen.
- 111 -
Auch CORBA bietet Plattformunabhängigkeit, indem versucht wird, möglichst viele Zielsysteme
und Sprachen zu unterstützen. Derzeit gibt es jedoch keine kommerzielle Implementierung. In
Tabelle 6-14 sind wichtige Eigenschaften der vorgestellten Komponententechnologien aufgeführt.
Wenngleich Java Vorteile bietet, kann die Festlegung auf eine bestimmte Technologie den
gesetzten Zielen nach Offenheit und Interoperabilität nicht gerecht werden. Die Verwendung einer
einzigen Technologie ist zur Herstellung von Interoperabilität auch nicht erforderlich und sollte
deshalb nicht festgeschrieben werden.
Komponententechnologie
JavaBeans
ActiveX
Enterprise
JavaBeans
CORBA
Components
COM(+),
DCOM, .NET
Vorgesehener
Einsatzort
Client
Client
Server
Server
Server
Treibende
Kraft
SUN
Microsoft
SUN
OMG
Microsoft
Sprache
Java
beliebig, wenn
ActiveX unterstützt wird
Java
Transaktionsunterstützung
keine
keine
vorhanden
vorhanden
vorhanden
Persistenzunterstützung
vorhanden
keine
vorhanden
vorhanden
keine
Eventunterstützung
BeansEventmodell
AciveXEventmodell
keine
EventService
EventService
Sicherheitsmechanismen
keine
keine
vorhanden
vorhanden
vorhanden
Erfragung von
Schnittstellen
Introspection
unknownFunktion
Introspection
Äquivalenzschnittstelle
unknownFunktion
Tabelle 6-14: Komponententechnologien im Überblick1
1
Vgl. /Weis-2002 (S. 183)/.
mit CORBA- beliebig, wenn
Mappings beCOM unterliebig
stützt wird
- 112 -
6.6 Automation aus Sicht der IT
Die der Arbeit zugrunde liegende Idee betrachtet eine Maschine oder Anlage neben seiner
Produktionsfunktion gleichzeitig als Lieferanten und Empfänger von Informationen. Bei maschinennahen fernerbrachten Diensten ist die IT des Diensterbringers unmittelbar mit dem IT-System beziehungsweise der Steuerung der Maschine verknüpft. Die Kommunikationsfähigkeit der Maschinen und Anlagen ist eine Voraussetzung zur Nutzung solcher maschinennaher Dienste. Die Basis
hierfür bildet die fortschreitende Ausstattung der Maschinenausrüstung mit kommunikativen
Rechnersystemen in Form von IPCs1 und eingebetteten Systemen. In der Industrie findet man
heute eine große Bandbreite unterschiedlicher IT-Systeme in der Automation vor. Diese reichen
von der einzelnen – evtl. webfähigen – SPS über Bussysteme bis hin zur systemweiten
Middleware.
In der Praxis überwiegen heute Dienste, bei denen der Mensch die Maschinendaten2 zunächst einsieht, interpretiert und ggf. verdichtet, bevor er diese dem Mehrwertdienst zur Verfügung stellt.
Dies hat Vorteile in Bezug auf die IT-Sicherheit aber auch im Hinblick auf psychologische Aspekte.
Der Maschinenbetreiber möchte in der Regel aus wettbewerbstaktischen und Gewährleistungsgründen vermeiden, dass Dritte sich unkontrolliert Zugang zur Steuerung verschaffen können. Da
es dennoch maschinennahe Dienste gibt und somit ein Integrationsbedarf besteht, sollen im
Folgenden die Grundlagen der Automation aus Sicht der IT beleuchtet werden.
6.6.1
Beginn der softwaregesteuerten Industrieautomation
Ein softwaregesteuertes System besteht grundsätzlich aus:

Sensoren: Die Sensoren erfassen die physikalischen Größen eines Prozesses, setzen diese
in geeignete Werte um und stellen diese der Steuerungssoftware zur Verfügung.

System- und Kommunikationssoftware: Diese stellt der Steuerungssoftware alle Grundfunktionen zur Verfügung und regelt die zeitlichen Abläufe im System.

Steuerungssoftware: Die Steuerungssoftware steuert, regelt und überwacht den Prozess. Sie
wird durch Bedienstationen beeinflusst und kommuniziert mit anderen Systemen.

Aktoren: Die Aktoren beeinflussen die Ausführungselemente, wie z. B. Motoren und Ventile,
und wirken damit auf den Prozess ein.
Der Beginn der softwaregesteuerten Industrieautomation liegt in den 60er Jahren und beruht auf
der Idee, Instruktionen nicht mehr durch Relais, sondern durch programmierbare Systeme ausführen zu lassen – die speicherprogrammierbare Steuerung (SPS) entstand. Zu Beginn bildete
jede SPS eine Steuerungsinsel, d. h., sie beherrschte autonom einzelne Arbeitsschritte im
Prozess.
1
2
IPC für Industrie-PC.
Sammelbegriff für NC-Programme, NC-Messprogramme, Prüfprotokolle, Sensordaten etc.
6.6.2
- 113 -
Proprietäre Kommunikation
Das erste Zeitalter der Industrieautomation (ca. 1975 – 1985) ist durch serielle Punkt-zu-PunktVerbindungen zwischen einzelnen SPSen sowie zwischen SPSen und den übergeordneten
Systemen gekennzeichnet. Alle SPS-Hersteller entwickelten ihre eigenen – meist inkompatiblen –
Kommunikationsprotokolle für diese Verbindungen. Da diese Kommunikationsprotokolle eng in die
Ausführungsumgebung der entsprechenden SPS eingebunden waren, erschwerte dies die
herstellerübergreifend serielle Kommunikation (siehe Abbildung 6-9).
6.6.3
Bushierarchien
Mit dem Auftreten von industriellen Netzwerken Mitte der 80er Jahre – dem 2. Zeitalter der
Industrieautomation – wurde eine serielle Kommunikation in Echtzeit über einen gemeinsamen
Kommunikationsbus zwischen Steuerungen möglich. Die kurzen Antwortzeiten erlaubten den
Steuerungen auch bei schnelleren Prozessen, Prozessdaten und Zustandsinformationen via Telegramm an andere Anlagenteile zu übergeben. Damit wurde es möglich, die Steuerungsaufgaben
für einen Anlagenteil nicht mehr in einer einzigen Steuerung zu konzentrieren, sondern diese auf
mehrere, eng gekoppelte Steuerungsknoten zu verteilen.
Da die Kommunikationsanforderungen – vor allem bezüglich Datenmengen, Übertragungszeiten
und Echtzeitanforderungen – für verschiedene Steuerungsfunktionen sehr unterschiedlich sind,
wurden verschiedene Bussysteme entwickelt1. Es entstand eine Bushierarchie. Diese Hierarchie
umfasste mindestens die folgenden drei Ebenen (Abbildung 6-10):

Leitebene mit Factory-Bussen

Steuerungsebene mit Feldbussen

Sensor-/Aktorebene mit physikalischen Schnittstellen zum Prozess
RS-232
Leitstand
Leitstand
(Visualisierung)
(Visualisierung)
Factory-Bus
Leitebene
RS-232
Feldbus
RS-232
Ein-/Ausgabe
Feldbus
Steuerungsebene
Ein-/Ausgabe
Sensor-/
aktorebene
Ein-/Ausgabe
Abbildung 6-9: Proprietäre Kommunikation2
1
2
3
Abbildung 6-10: Bushierarchie3
In der Literatur existieren unzählige Busvergleiche, vgl. /Furr-2003 (S. 25)/.
Vgl. /Furr-2003 (S. 4)/
Vgl. /Furr-2003 (S. 5)/.
Sensor-/
Aktorbus
- 114 -
Die Bushierarchien unterstützen die Implementierung verteilter Anwendungen1. Die Nutzung der
entstandenen Kommunikationstechnologien (siehe Kapitel 6.5) ermöglichte die Erzeugung von
Objekten und deren Aufruf über Rechnergrenzen hinweg. Damit konnte die rechnergestützte
Integration von Produktionsprozessen zunächst wesentlich vereinfacht werden.
Die Bushierarchien stießen jedoch im heterogenen Steuerungsumfeld an ihre Grenzen. Viele Anlagen in der Produktion bestanden aus unterschiedlichen Zuführsystemen, Handhabungsgeräten
und Maschinen. Die Anlagenteile hatten oftmals nicht kompatible Steuerungen, mit eigenen Bediensystemen und eigenen Funktionen. Die unterschiedlichen Bussysteme und verschiedenen
Steuerungen konnten – wenn überhaupt – nur mithilfe von Protokollkonvertern miteinander
kommunizieren und Daten austauschen. Dies erschwert die Weiterverarbeitung der anfallenden
Daten in übergeordneten Leitsystemen zu Analysezwecken beziehungsweise erfordert aufwendige, individuelle Anpassungen. An dieser Situation hat sich im Wesentlichen bis heute nichts
verändert.
Seit Mitte der 80er Jahre hat sich auf dem Markt eine große Anzahl verschiedener Feldbusse
etabliert, die sich hinsichtlich des Zugriffsverhalten, der Leistungsdaten, des Funktionsumfangs
etc. unterschieden. Da sich die Industrie nicht auf gemeinsame Protokolle einigen konnte, wurden
von verschiedenen Herstellern und Interessengruppen inkompatible Bussysteme entwickelt2.
Ca. seit dem Jahr 2000 etablieren sich parallel zu den Feldbussen Kommunikationssysteme auf
der Basis der Ethernet-Technologie. Industrial Ethernet ist der Oberbegriff für alle Bestrebungen,
die Ethernet-Technologie für die Vernetzung von Maschinen und Anlagen in der industriellen
Fertigung nutzbar zu machen. Um die Echtzeitanforderungen von weniger als 1 ms zu erfüllen,
musste man spezielle Protokolle definieren sowie spezifische Hardware entwickeln. Verschiedene
Interessengemeinschaften, wie z. B. die IAONA3 und IDA4, haben sich zum Ziel gesetzt, die Ethernet-Technologie voranzubringen. Trotz vieler Bemühungen hat man es jedoch nicht geschafft,
einen einheitlichen Standard zu definieren, der es ermöglicht, Geräte verschiedener Systeme gemeinsam zu betreiben5. Durch die höheren Bandbreiten werden konventionelle Feldbussysteme
trotz höherer Kosten in einzelnen Anwendungen durch Industrial Ethernet ersetzt.
1
2
3
4
5
Verteilte Anwendungen bestehen aus Objekten, die über Prozess- und Rechnergrenzen hinweg miteinander
kommunizieren können.
In den letzten Jahren hat eine Marktkonsolidierung stattgefunden. Heute dominieren folgende Feldbusse: CAN,
INTERBUS, PROFIBUS, SafetyBUS p, Fieldbus Foundation. Seit dem Jahr 1999 – also ca. 25 Jahre nach deren Einführung – werden Feldbusse in der Norm IEC 61158 weltweit standardisiert.
Die Europäische Industrial Automation Open Networking Alliance (IAONA) fördert den Einsatz offener, auf Ethernet
basierender Netzwerk-Lösungen für die Automatisierungstechnik. Nach 7 jähriger Tätigkeit wurde im Jahr 2006 die
Arbeit für beendet erklärt und die europäische Dachorganisation aufgelöst. In der Schweiz werden die IAONAAktivitäten fortgeführt. Vgl. </http://www.iaona.org/>, letzter Abruf am: 01.05.2008.
Die IDA (Abkürzung für Interface for Distributed Automation) ist eine Interessengruppe, die das Ziel verfolgt, eine
Schnittstelle für die verteilte Automation auf der Grundlage von Ethernet und TCP/IP zu entwickeln. Vgl.
</http://www.ida-group.org/>, letzter Abruf am: 01.05.2008.
Wie 25 Jahre zuvor bei den Feldbussen, sind heutige Industrial Ethernet System untereinander nicht kompatibel.
Dennoch sprechen alle Systemanbieter davon, den „offenen Standard“ geschaffen zu haben. Zu den z. Z.
wichtigsten Systemen gehören: EtherCAT, SERCOS III, PROFINET, ETHERNET/IP und SafetyNET p.
6.6.4
- 115 -
Systemweite Middleware
Wir befinden uns heute im Übergang von den Bushierarchien zur systemweiten Middleware - dem
dritten Zeitalter der Industrieautomation. Im Verlauf des zweiten Zeitalters der Industrieautomation
haben zwei Trends eine zentrale Bedeutung erhalten:

Die Komplexität der Steuerungsaufgaben ist ständig gestiegen. Einerseits wurden die Anforderungen von den Anwendungen her immer umfangreicher, und andererseits wurden die
zugrunde liegenden Systeme immer komplizierter und vielfältiger.

Die Notwendigkeit der Wiederverwendbarkeit von Softwarekomponenten wurde zwingend:
Dem Zeit- und Kostendruck bei der Implementierung von Software lässt sich nur durch die
Wiederverwendung von bewährten Softwarekomponenten erfolgreich begegnen.
Diese Trends waren bei den kommerziellen IT-Systemen schon Jahre früher wirksam, und im Umfeld der kommerziellen Informationstechnologie wurden geeignete Technologien entwickelt.
Internet
Visualisierungskomponente
Web-ServerKomponente
QSKomponente
Interface
Interface
Interface
Steuerungskomponente
Interface
Interface
Interface
Systemweite Middleware
Interface
Interface
Interface
Interface
Interface
Interface
Regelung
Intelligente
Sensoren/Aktoren
Intelligente
Sensoren/Aktoren
Intelligente
Sensoren/Aktoren
Intelligente
Sensoren/Aktoren
Abbildung 6-11: Industrieautomation mit systemweiter Middleware1
1
Vgl. /Furr-2003 (S. 8)/.
Regelung
- 116 -
Die zwei grundlegenden Konzepte sind:

Einsatz einer erweiterten Systemsoftwareschicht – Middleware genannt –, welche die
Steuerungsprogramme von allen plattformabhängigen Details kapselt und alle benötigten
Funktionen und Dienste in herstellerunabhängiger Form anbietet.

Nutzung einer komponentenbasierten Software-Architektur: Alle Softwarekomponenten
(Steuerungs-, Sensor-/Aktortreiberprogramme und Visualisierungssysteme) basieren auf
einem standardisierten, plattform- und herstellerunabhängigen Komponentenmodell.
Zurzeit sind noch keine Standards für industrielle Middleware verfügbar. Es bestehen Aktivitäten,
Middleware aus dem Consumer Umfeld mit geeigneten Kommunikations- und Echtzeitbetriebssystemen zu kombinieren, um die gewünschte Funktionalität und Leistungsfähigkeit zu erreichen.
Verschiedene Gremien, wie z. B. die OMG, IDA, ODVA1, haben sich diese Standardisierung zur
Aufgabe gemacht (siehe Abbildung 6-11).
6.6.5
Trend zur Consumer-IT
Die Entwicklung von Systemsoftware und Kommunikationssystemen ist eine zeitund kostenintensive Aufgabe. Es hat sich gezeigt, dass eine Kostenverteilung auf sehr viele Anwender beziehungsweise Lizenznehmer notwendig ist. Der technologische Fortschritt im Bereich der IT wird
weitestgehend vom Consumer-Markt beeinflusst. Dies betrifft Computerhardware, Betriebssysteme, Softwaretechnologien, Entwicklungsumgebungen etc.
Der industrielle Markt ist gezwungen, diese Consumer-IT über kurz oder lang – mit kleineren Anpassungen in Richtung Industrietauglichkeit – zu übernehmen. Auf diese Weise sind der PC als
I-PC, die Microsoft Betriebssysteme, das Client-/Serverkonzept, Ethernet, die modernen Programmiersprachen, wie z. B. C++ und Java, in die Industrieautomation vorgedrungen. Einige InternetTechnologien haben bereits heute einen festen Platz in der Industrieautomation gefunden. Damit
hat das Internet bereits einen starken De-facto-Standardisierungseffekt ausgelöst2. Das Gleiche
geschieht zurzeit mit der Objekt- und Middlewaretechnologie. Die treibende Kraft ist dabei der
Produktivitätsfortschritt, welcher durch die neuen Technologien erreichbar ist. Zunehmend dringt
Middlewaretechnologie aus der Consumer-IT in die Industrieautomation ein.
Die Ethernet-Bustechnologie eröffnet durch die durchgängige Kommunikation neue Möglichkeiten
der Integration in die unternehmensweiten Informationsstrukturen – mit enormem Rationalisierungs- und Qualitätsverbesserungspotenzial. Allerdings setzt man auf diese Weise das industrielle
Automationssystem auch neuen Bedrohungen aus. Durch seine Öffnung nach außen, seien es
Intranets, Extranets oder das Internet, wird es ggf. auch für Unberechtigte zugänglich. Entsprechende Sicherheitsmechanismen sind daher unerlässlich.
1
2
ODVA (Abkürzung für open DeviceNet vendor association). Die Organisation beschäftigt sich mit der Weiterentwicklung und Verbreitung offener Feldbus-Protokolle, die vorwiegend in den USA und Asien, aber auch in Europa zum
Einsatz kommen sollen. Die IDA kooperiert mit der ODVA. Vgl. </http://www.odva.org/>, letzter Abruf am: 01.05.2008
Vgl. /Furr-2003 (S. 317)/.
7 Vorgehensmodell zur Gestaltung internetbasierter Mehrwertdienste
Es gibt nichts Praktischeres als eine gute Theorie!
Immanuel Kant
Philosoph
Das in diesem Kapitel beschriebene Vorgehensmodell zur Gestaltung internetbasierter Mehrwertdienste basiert auf den Vorgehensmodellen des Service Engineerings (siehe Kapitel 4.4) und des
Software Engineerings (siehe Kapitel 4.5) sowie auf den Informations- und Kommunikationstechnologien zur Diensterbringung (siehe Kapitel 6). Das Vorgehensmodell verbessert und vereinfacht die Dienstgestaltung, indem es die genannten Aspekte ganzheitlich und integriert betrachtet.
Die möglichen Projektkonstellationen zur Gestaltung von Mehrwertdiensten sind vielfältig. Einerseits existieren Pilotprojekte, die das Ziel haben, neue Funktionalitäten oder innovative Technologien zu evaluieren. Solche Pilotprojekte haben häufig den Charakter von Machbarkeitsstudien, in
denen die prinzipielle Umsetzbarkeit einer Idee nachzuweisen ist. Einen anderen Fokus haben
hingegen unternehmensübergreifende Integrationsprojekte. Dort stehen Anforderungen an die
Skalierbarkeit, Interoperabilität und Sicherheit im Vordergrund.
Das nachfolgend beschriebene Vorgehensmodell hat den Anspruch allgemeingültig zu sein, um in
möglichst vielen Projektkonstellationen Nutzen zu stiften. Es ist daher notwendig, die Vorgehensschritte an die jeweiligen konkreten Projektbedingungen anzupassen. Aufgrund des modularen
Aufbaus lässt sich das Vorgehensmodell flexibel an die spezifischen Anforderungen eines Projekts
anpassen. Das sequenzielle Durcharbeiten der Kapitel unterstützt den Anwender darin, alle
relevanten Aspekte eines Mehrwertdienstes zu berücksichtigen und die einzelnen Schritte strukturiert durchzuführen. Zur Vertiefung einzelner Inhalte sind in der Arbeit viele Literaturverweise gegeben. Dadurch wird das Vorgehensmodell den Anforderungen einer effizienten und individuellen
Durchführung von Projekten gerecht. Die Grundstruktur des Vorgehensmodells zur Gestaltung
internetbasierter Mehrwertdienste basiert auf einem Phasenmodell (siehe Abbildung 7-1).
Methoden
und
Werkzeuge
E-ServiceStrategie
E-ServiceIntegrationsarchitektur
E-ServiceDesign
E-ServiceAnwendungsarchitektur
E-ServiceKomponentenkatalog
E-ServiceInfrastruktur
E-ServiceDatenarchitektur
E-ServiceKommunikationsarchitektur
E-ServiceRollenmodell
E-ServiceKomposition
und Konfiguration
Abbildung 7-1: Vorgehensweise zur Gestaltung internetbasierter Mehrwertdienste
E-ServiceProzessarchitektur
Auswahl
InternetservicePlattform
IT-ServiceManagement
E-ServicePilotierung
und
Einführung
- 118 -
7.1 Methoden und Werkzeuge zur Gestaltung internetbasierter Mehrwertdienste
Wie bereits im Kapitel 4.1 erwähnt, liegen allen Vorgehensmodellen Methoden zugrunde. Oftmals
sind Methoden nicht eindeutig einer bestimmten Entwicklungsphase zuzuordnen, sondern eignen
sich für unterschiedliche Fragestellungen. Zur Verbesserung der Übersichtlichkeit erfolgt in diesem
Kapitel zunächst die Referenzierung der wichtigsten Methoden.
7.1.1
Verbreitungsgrad und Akzeptanz der Methoden und Werkzeuge
Zur Unterstützung der Dienstleistungsentwicklung stehen ingenieurwissenschaftliche, betriebswirtschaftliche sowie dienstleistungsspezifische Methoden zur Verfügung. In der Praxis zeigt sich,
dass die vorhandenen Instrumente nicht ausgeschöpft werden. Studien von Fähnrich1 und van
Husen et al.2 zufolge finden vor allem die klassischen Instrumente der Betriebswirtschaft Anwendung. So sind die Methoden der Kosten-Nutzen-, Wirtschaftlichkeits-, Wettbewerbsanalysen
weit verbreitet und werden regelmäßig eingesetzt. Spezifische Methoden zur Dienstleistungskonzeption, wie z. B. Rollenkonzepte oder das Service Blueprinting, werden hingegen kaum eingesetzt.
Im Vergleich zur Produktentwicklung (CAD), Fabrikplanung (Digitale Fabrik) und Ressourcenplanung (ERP) ist der integrierte Werkzeugeinsatz zur Dienstleistungsgestaltung außerhalb von
Forschungsprojekten nicht vorhanden. Es dominieren isolierte Einzelwerkzeuge aus verschiedenen Anwendungsbereichen. Beispiel hierfür sind Office-Produkte, Modellierungs- und
Simulationswerkzeuge, Projektmanagementsoftware etc. Aufgrund der fehlenden Werkzeugintegration sind beim Übergang von der Konzeption zur Implementierung die Modelle neu zu gestalten. Änderungen, die während der Implementierung auftreten, werden häufig in den Produkt-,
Prozess- und Ressourcenmodellen nicht aktualisiert, sondern direkt umgesetzt. Dies führt in der
Praxis dazu, dass die Modelle zunächst veralten, dann aufgrund der Diskrepanz von Modell und
Realität an Bedeutung verlieren und letztlich aus Aufwandsgründen gar nicht mehr verwendet
werden3.
Der Werkzeugeinsatz zur Modellierung der Produkt-, Prozess- und Ressourcenmodelle birgt noch
weitere Gefahren in sich. Die Erfahrung aus vielen Umsetzungsprojekten mit Industriepartnern
zeigt, dass ein im Team erarbeiteter Lösungsvorschlag, der am Flipchart dokumentiert wird,
oftmals die Rahmenbedingungen und Anforderungen besser erfasst, als ein perfekt ausgearbeitetes UML-Diagramm. Komplexe werkzeuggestützte Notationen werden in der Regel lediglich von wenigen Personen erarbeitet und oftmals nicht von allen Beteiligten semantisch verstanden und infolgedessen auch nicht akzeptiert. Entscheidend für den Erfolg bei der Umsetzung
ist allerdings gerade die Schaffung einer breiten Akzeptanz bei allen Beteiligten.
Darüber hinaus ist in den frühen Phasen eines Projekts nicht gewährleistet, dass eine Dienstleistungsidee realisiert wird. Es besteht die Gefahr, dass ein hoher Aufwand zur exakten und
widerspruchsfreien Darstellung von Detailabläufen betrieben wird, und am Ende das Projekt nie
zur Umsetzung kommt. In dieser Arbeit wird daher auf die Vorgabe formaler Methoden und entsprechender Werkzeuge zur Modellierung der Produkt-, Prozess- und Ressourcenmodelle verzichtet.
1
2
3
Vgl. /Fähn-2006/Fähn-2004a/Fähn-2004b/.
Vgl. /Huse-2005 (S. 46)/.
Lösungsansätze verspricht man sich zukünftig durch die modellgetriebenen Architekturen (MDA). Vgl. Kapitel 6.3.5.
7.1.2
- 119 -
Methoden- und Werkzeugsammlung zur Dienstleistungskonzeption
Im Rahmen des Projekts E-Industrial Services entstand eine umfangreiche Methodensammlung,
welche den Gestaltungsprozess internetbasierter Mehrwertdienste unterstützt. Für jede Methode
ist deren Zielsetzung, Anwendung sowie die Vor- und Nachteile aufgeführt. Teilweise umfassen die
Beschreibungen auch Hilfsmittel auf Basis des Office-Pakets, exemplarische Beispiele sowie
Literaturangaben, um dem Anwender den Einstieg in eine Methode zu erleichtern. Abbildung 7-2
zeigt den exemplarischen Aufbau der Methodensammlung am Beispiel der SWOT-Analyse1.
Abbildung 7-2: Methodenbeispiel aus der Methodensammlung von E-Industrial Services
1
englisches Akronym Strength - Stärken, Weaknesses - Schwächen, Opportunities – Chancen und Threats - Gefahren
- 120 -
Aufgrund der Vielzahl von über 200 Methoden lassen sich diese im Rahmen der vorliegenden
Arbeit nicht beschreiben, sondern lediglich referenzieren. Tabelle 7-1 zeigt eine Sammlung von
Methoden zur Gestaltung von Mehrwertdiensten. Die Methoden sind als Hyperlink angelegt und
ermöglichen somit den direkten Zugriff auf die Methoden auf der Webseite http://www.e-industrialservices.de. Alternativ können die Methodennamen auch unter Nutzung der Volltextsuche auf der
Webseite gefunden werden.
Methodensammlung zur Gestaltung internetbasierter Mehrwertdienste
Abgrenzung Strat. Geschäftsfelder
Affinitätsdiagramm
Amortisationsrechnung
Analogiebetrachtung
Analytic Hierarchy Process
Attribute Listing
Audit
Auswahlliste
Auswertung Kundenreklamationen
Balkenplan
Baumdiagramm
Benchmarking
Beschwerdemanagement
Marktfeldstrategischer Optionen
Bewertung in der Moderation
Bionik
Black-box-Testfallentwurf
Blitzlicht
Bottleneck Engineering
Brainstorming
Brainwriting
Branchenanalyse
Business Networking-Methode
Case-Based-Reasoning ( CBR )
Chancen- und Gefahrenanalyse
Checklisten
Class-Responsibility-Collaboration
Clusteranalyse
Conjoint-Analyse
Data-Navigation Modeling
Datenflussdiagramm Demarco
Datenfluss-Modellierung
Debatte
Delphi Methode
Design Review
Design To Cost (DTC)
Designverifikation
Dialog Design Modellierung
Entity Life History
Entity-Relationship-Model (ERM)
FMEA
Flussdiagramme
Fokusgruppenbefragung
Force-Fit Methode
Formale Spezifikation
Fragebogen
Funktionale Dekomposition
Funktionsanalyse
Funktionsnetz-Modellierung
Galerie-Methode
Gantt-Diagramm
Garantiekostenanalyse
Gedankliches Testen
Gemeinkostenwertanalyse
Geschäftsprozessmodellierung
Gewichtungsmethode
Grenzwertanalyse
Gruppenarbeit
Gruppendiskussion
Heuristiken
Hoshin Kanri
Informationsbeschaffungsplan
Innovation Road Map
Interaktionsmodellierung
Ishikawa-Diagramm
Kano-Methode
Kapitalwertmethode
Kärtchentechnik
Kartenabfrage
Kernkompetenzanalyse
Klassen-/Objektmodellierung
Klassischer Betriebsvergleich
Komponent. Softwareentwicklung
Komponentenbaum
Konkurrenzanalyse
Kontrollflussmodellierung
Konzepttest
Kosten-Nutzen-Analyse
Kräftefeld-Analyse
Kundenbefragung
Meta-Plan-Technik
Methode 635
Methode des vernetzten Denkens
Mindmapping
Mind-Maps
MKL-Metamind
Moduldiagramme
Monte-Carlo-Simulation
Morphologische Matrix
Morphologische Methoden
Multiagententechnologien
Multidimensionale Skalierung
Nebenfeldintegration
Netzplantechnik
Neuronale Netze
Normalisierung
Nutzwertanalyse
Objektentwurfstechnik
Objektorientierte Modellierung
Ontologie
Organigramm
Osborn-Methode
Paarvergleich
Pareto-Diagramm
Patentanalyse
Petri-Netze
Pflichtenhefterstellung
Plausibilitätskontrolle
Poka-Yoke
Polaritätsprofil
Portfolio-Analyse
Potenzialanalyse
Primärquellenvergleich
Prioritätenmatrix
Proben und Versuche
Problemlösungsbaum
Product Reverse Engineering
Produkttest
Programmverifikation
Progressive Abstraktion
Tabelle 7-1: Methodensammlung zur Gestaltung internetbasierter Mehrwertdienste 1
1
Vgl. /eIS-2007/.
QFD
Ressourcenbas. Kostenkalkulation
Review
Schwachstellenliste
Scratch-Line-Budgeting
Sekundärquellenvergleich
Sensitivitätsanalyse
Sequenzdiagramm
Shadowing
SIL-Methode
Simulationsbudgetierung
Simulationsmodelle
Six Sigma - 6
Standardbudgetierung
Statische Analyse
Strategiepapier erstellen
SWOT
Structured Design
Subsystemmodellierung
Synektik
Systemverhaltensmodelle
Szenariomanagement
Szenario-Methode
Szenariotechnik
Taguchi-Methoden
Target Costing
Technische Diagnose
Testen
TILMAG-Methode
Timingstrategie
Tragfähige Ideen
Trendextrapolation
TRIZ-Widerspruchsmatrix
T-Wand
Ursache-Wirkungsanalyse
Use-Case-Modellierung
Virtual Reality
Walt Disney-Strategie
Web-Service
Wertanalyse
- 121 -
7.2 E-Service-Strategie
Die Entwicklung jeder Strategie beruht auf Informationen aus einer Vielzahl von Quellen. Marktund Wettbewerbsanalysen sind dabei ebenso wichtig, wie Downstream-Analysen, die Analyse der
eigenen Potenziale sowie die Beobachtung von Trends. Die E-Service-Strategie ist Bestandteil des
Enterprise Viewpoints im RM-ODP-Modell.
7.2.1
E-Service-Strategie als Teil der Unternehmensstrategie
Die Entwicklung einer Dienstleistungsstrategie kann nicht losgelöst von der Unternehmensstrategie erfolgen. Die Planung und Ausrichtung des Angebots an produkt- und produktionsbegleitenden Dienstleistungen muss sich vielmehr an den strategischen Zielen eines Unternehmens anlehnen, um die eigenen Wettbewerbsstärken wirkungsvoll zu unterstützten1.
Wie die Erfahrung zeigt, muss jede Strategieentwicklung bei der individuellen Ausgangslage eines
Unternehmens ansetzen. Ein wichtiger Aspekt ist dabei die Wertschöpfungsstufe, in der sich ein
Unternehmen befindet. Das Dienstleistungsangebot eines Unternehmens, das komplexe Investitionsgüter an Endkunden liefert, unterscheidet sich von den Unternehmen, die als Systemlieferanten, Komponentenlieferanten oder als Modullieferanten agieren. Die Möglichkeit und die
Bedeutung von Dienstleistungen nehmen in der Regel mit zunehmender Wertschöpfungsstufe ab,
da die darüber liegenden Ebenen Interesse an der Bereitstellung von Dienstleistungen haben2.
Strategieüberlegungen werden im Servicebereich häufig durch die Ertrags- und Wachstumspotenziale bestimmt. Durch den Maschinenverkauf konnten in den vergangenen Jahren zwar hohe
Umsätze realisiert werden, die Gewinne entstehen jedoch vor allem durch das Folgegeschäft mit
Dienstleistungen wie Diagnose, Wartung, Teileverkauf etc3. Neben diesen monetären Aspekten
wurden bereits in Kapitel 2.2 und 2.3 weitere Gründe für den Einstieg beziehungsweise den Ausbau von Mehrwertdiensten gegeben und entsprechende Studien referenziert. Hierzu zählt unter
anderem die Differenzierung vom Wettbewerb, die Zunahme der Maschinenkomplexität welche
Herstellerdienstleistungen erfordert und die Schwindung technologischer Alleinstellungsmerkmale4.
Jede Strategie sollte in einem Strategiedokument schriftlich fixiert sein sowie konkrete
Empfehlungen für die Durchführung eines E-Service-Projekts im Unternehmen beinhalten. Das
Strategiedokument sollte wirtschaftliche, zeitliche und organisatorische Rahmenbedingungen
während der Projektdurchführung und nach der Einführung der Dienste beschreiben.
1
2
3
4
Vgl. /Homb-2006 (S. 339)/.
Vgl. /Lay-2002 (S. 69)/.
Vgl. /Merc-2006 (S. 13)/Merc-2005 (S. 3)/Lay-2005/.
Vgl. /Wild-2006b (S. 249)/
7.2.2
- 122 -
Markt- und Wettbewerbsanalyse
Im Rahmen von Marktanalysen sind die Kundenbedürfnisse und ggf. bestehende Marktlücken aufzudecken. Dabei ist zu prüfen, welche Akzeptanz und Zahlungsbereitschaft bzgl. elektronischer
Dienstleistungen bei den Kunden vorhanden ist. Die zu klärenden Fragen sind dabei:

Welche Dienstleistungen erwarten die Kunden?

Welche Dienstleistungen können durch aktive Vermarktung so in den Markt eingeführt werden,
dass latente Bedürfnisse geweckt werden?

Mit welchen Dienstleistungen können neue Kundengruppen erschlossen werden?
Darüber hinaus sind, wie in jedem anderen Geschäftsfeld auch, Wettbewerbsanalysen durchzuführen, um die Aktivitäten der Mitbewerber zu untersuchen. Hierzu sind nicht nur die Mitbewerber
aus der Investitionsgüterindustrie zu betrachten, sondern auch Anbieter aus der IT-Branche sowie
Komponenten- und Steuerungshersteller. Eine besondere Form der Wettbewerbsanalyse ist die
Downstream-Analyse1. Dabei wird untersucht, welche Dienstleistungen dem Betreiber eines
Produktionssystems über den gesamten Maschinenlebenszyklus angeboten werden. Die Renditen
für solche Dienstleistungen sind im Verhältnis zum reinen Anlagenverkauf häufig viel höher und
werden häufig nicht vom Hersteller, sondern von Dritten erbracht2. Zur Markt- und Wettbewerbsanalyse stehen neben spezifischen Studien, Analysen und Veröffentlichungen auch Querschnittsmethoden3 sowie dienstleistungsspezifische Methoden zur Verfügung:

von Lay eingeführte Strategische Positionierung4

von Backhaus beschriebene Monetäre Klassifikationsmatrix5

von Piller beschriebene Systematisierungsmatrix6
Die Ergebnisse der Markt- und Wettbewerbsanalyse sollten in die E-Service-Strategie einfließen.
7.2.3
Potenzialanalyse
Neben dem marktund wettbewerbsorientierten Ansatz ist im Rahmen des E-Service-Strategieprozesses ein potenzialorientierter Ansatz zu verfolgen. Die Potenzialanalyse ist eine Analyse der
eigenen Situation mit dem Ziel, sich der unternehmerischen Stärken und Schwächen sowie der zur
Verfügung stehenden Ressourcen bewusst zu werden. Dabei sind folgende Ziele zu verfolgen:

Die Analyse der eigenen Stärken kann zur Entwicklung neuer Dienstleistungsideen beitragen,
die aufgrund der eignen Expertise eine gute Ausgangsbasis haben.

Die Untersuchung von Produktschwächen kann Hinweise geben, wie mithilfe von Dienstleistungen die Schwächen evtl. kompensiert werden.
Zur Potenzialanalyse stehen zahlreiche Methoden zur Verfügung, von denen die SWOT-Analyse
eine der Bekanntesten ist1. Die Analyseergebnisse sollten in die E-Service-Strategie einfließen.
1
2
3
4
5
6
Bezeichnung für die Flussrichtungen von Gütern, Dienstleistungen, Daten etc.
Vgl. /Merc-2003 (S. 3)/ADL-2001 (S. 13)/. Siehe auch Abbildung 2-2.
Vgl. Beschwerdeanalyse, Benchmarking, Branchenanalyse, Expertenbefragung, Marktforschung, Konkurrenzanalyse, Kundenbefragung, Lead-User-Analyse, Patentanalyse etc. Siehe Tabelle 7-1.
siehe Kapitel 4.4.4.
siehe Kapitel 4.4.4.
Vgl. /Pill-2001 (S. 15)/.
7.2.4
- 123 -
Trendanalyse
Die Konzeption einer Strategie unter Berücksichtigung von Trends erlaubt es, für Märkte Vorbereitungen zu treffen, die bislang noch nicht existieren. Man gewinnt so einen Zeitvorsprung vor
seinen Wettbewerbern, die evtl. erst dann reagieren, wenn der Markt starke Signale sendet.
Darüber hinaus hilft die Analyse von Trends, die mittelfristige Tragweite aktueller Entscheidungen
besser abzuschätzen zu können.
Die Auswahl der Felder, auf die sich eine Trendanalyse bezieht, ist entscheidend für deren Erfolg.
Beispielsweise besteht aufgrund der zunehmend höheren Leistungsdichte, dem stetigen Preisverfall und der zunehmenden Verbreitung eingebetteter Systeme eine Substitutionsgefahr gegenüber
fernerbrachter Dienste. Statt vernetzter Systeme, die über das Internet Dienstleistungen beziehen,
könnten intelligente, autarke Systeme Teilfunktionen übernehmen, die bisher internetbasierten
Dienstleistungen vorbehalten waren. Zu beachten sind auch gesellschaftliche Trends sowie die
allgemeine Preis- und Kostenentwicklung vor allem in der Telekommunikationsbranche.
Eine verbreitete Methode zur Trendanalyse ist neben den klassischen Befragungsmethoden2 die
Szenario-Technik. Ein Szenario ist dabei eine mögliche Zukunftssituation, die anhand einer Reihe
von Beschreibungskriterien definiert wird, deren Ausprägungen zueinander kompatibel sind. Ein
Szenario ist demnach aus konsistenten Teilbildern zusammengesetzt. Ein zentraler Aspekt ist
dabei, dass mehrere alternative Zukunftsbilder parallel entwickelt werden. Die treffsichere
Prognose der Zukunft steht demnach nicht im Vordergrund. Den Ausgangspunkt der Betrachtung
bildet das Trendszenario, welches auf einer Zeitachse aufgespannt wird. Dieses Trendszenario
stellt die zukünftige Entwicklung unter der Annahme stabiler Umweltentwicklungen dar. Da im
Regelfall allerdings von instabilen Umweltbedingungen auszugehen ist, müssen sowohl positive
als auch negative Entwicklungsmöglichkeiten Berücksichtigung finden.
7.3 E-Service-Design
Das E-Service-Design setzt auf den Ergebnissen der Markt- und Wettbewerbsanalyse, der
Potenzialanalyse sowie der Trendanalyse auf und ist Bestandteil des Enterprise Viewpoints im
RM-ODP-Modell. In der Dienstleistungsdefinitionsphase ist ein geeigneter Dienst zu finden. Im
Rahmen der Anforderungsanalyse wird der Dienst aus Sicht unterschiedlicher Rollenträger untersucht. Das IT-Sicherheitskonzept beleuchtet den Dienst aus Sicht der Bedrohungen und Risiken.
Schließlich wird alles Obengenannte in der Dienstleistungskonzeption zusammengeführt, der
logische Dienstablauf definiert und ein Business Case oder Business Plan erstellt.
Die beschriebenen Vorgehensschritte sind nicht als fest vorgegebene Reihenfolge zu verstehen,
wenngleich der Aufbau logisch strukturiert ist. Oftmals haben Anforderungen Auswirkung auf die
konkrete Dienstleistungskonzeption und umgekehrt können sich aus dem Dienstleistungskonzept
neue Anforderungen ableiten. Deshalb sind die Vorgehensschritte als Zyklus zu betrachten.
1
2
Vgl. Expertenbefragung, Fragebogen, Auswertung von Kundenreklamationen, Gruppendiskussion, Portfolio-Analyse,
Produkttest, Stärken-Schwächen-Analyse etc. Siehe Tabelle 7-1.
Vgl. Delphi-Methode, Expertenbefragung, Kundenbefragung, Lead-User-Analyse etc. Siehe Tabelle 7-1.
7.3.1
- 124 -
Projektmanagement
Das Projektmanagement stellt einen wesentlichen Einflussfaktor für den Projekterfolg dar, wie
unter anderem die Chaos-Studien der Standish-Group1 zeigen, bei denen ca. 270.000 IT-Projekte
untersucht wurden. Das Projektmanagement begleitet alle Phasen der Dienstgestaltung. Zu den
konventionellen Aufgaben des Projektmanagements gehören:

Projektorganisation,

Projektplanung,

Projektsteuerung,

Qualitätssicherung,

Konfigurationsmanagement,

Problem- und Änderungsmanagement,

Projektkommunikation sowie die

Qualifizierung von Personal.
Da jedes Projekt einmalig ist, muss jeweils eine spezifisch angepasste Projektdurchführungsstrategie definiert werden. Welche Projektdurchführungsstrategie für ein Projekt eines bestimmten
Typs geeignet ist, lässt sich anhand der Projektmerkmale ermitteln. Zu diesen Projektmerkmalen
gehören unter anderem der Projektgegenstand, die Projektdauer und -größe sowie die Projektrolle.
Die Anpassung der Projektdurchführungsstrategie an die spezifischen Projektmerkmale wird
Tailoring genannt und ist beispielsweise im V-Modell XT2 umfassend erläutert.
Das hier vorgestellte Vorgehensmodell zur Gestaltung internetbasierter Mehrwertdienste unterstützt das Projektmanagement durch die Vorgabe konkreter Methoden, standardisierter Vorgehensweisen sowie erwarteter Ergebnisse. Damit erhöht das Vorgehensmodell die Projekttransparenz, erleichtert das Management von Projekten und erhöht die Erfolgswahrscheinlichkeit. Die
oben genannten konventionellen Aufgaben des Projektmanagements sollen in dieser Arbeit nicht
vertieft werden, da sie sich nicht wesentlich von konventionellen Service Engineering und Software-Engineering Projekten unterscheiden und es hierzu bereits ausreichend Literatur gibt3.
7.3.2
Dienstleistungsdefinition
7.3.2.1 Ansatzpunkte zur Dienstleistungsdefinition
Im Rahmen der Dienstleistungsdefinition erfolgt der Such- und Auswahlprozess neuer Dienstleistungen. Bei der Dienstleistungsdefinition sollte der Kunde und dessen Problemlösung im
Vordergrund stehen. Die IT ist dabei lediglich ein Mittel zur Zielerreichung. Die Ideen für neue
Dienstleistungen können aus unterschiedlichen Quellen stammen. Insbesondere Mitarbeiter mit
Kundenkontakt, also die aus dem Marketing, Vertrieb oder Service, sind prädestiniert, aus
Kundenproblemen adäquate Lösungsansätze abzuleiten. Aber auch Fachgremien, Wettbewerber,
Forschungseinrichtungen oder Verbände können Ansatzpunkte für neue Dienstleistungen liefern.
Die Bündelung der Ideen und Ansätze an einer zentralen Stelle erweist sich dabei als einfaches
und effektives Mittel, um die vielfältigen Quellen zu kanalisieren.
1
2
3
Lediglich 34 % der analysierten IT-Projekte sind demnach heute erfolgreich. Vgl. /Stan-2006/Stan-1994/. Zu
vergleichbaren Ergebnissen kommen auch Mertins /Mert-2004/.
Vgl. /VMod-2006 (Teil 3)/.
Vgl. /Bull-2006/VMod-2006/Mang-2004/Balz-2001/.
- 125 -
Die meisten Literaturstellen weisen darauf hin, dass die Kundeneinbindung ein wichtiger Erfolgsfaktor ist1. Dabei ist die Orientierung an den Kundenbedürfnissen umso entscheidender, je
individueller die Leistungen sind. Die Autoren fordern deshalb, die Kundeneinbindung zusätzlich
zur Produkt-, Prozess-, Ressourcen- und Marketingplanung als 5. Glied aufzunehmen. Über den
optimalen Startzeitpunkt der Kundeneinbindung wurde bereits im Kapitel 4.4.5 berichtet.
Die Ansatzpunkte für neue Dienstleistungen sind nicht auf die Funktionalität von Maschinen oder
die häufig genannten After-Sales-Services wie Diagnose, Wartung, Instandhaltung und Ersatzteile
beschränkt, wie u. g. Aufzählung von möglichen Ansatzpunkten aufzeigt:

Wie können die Kosten über die gesamte Prozesskette gesenkt werden?

Wie kann der Kunde sein gebundenes Kapital reduzieren?

Wie kann die Produktion des Kunden beschleunigt, seine Flexibilität gesteigert und die Qualitätsanforderungen erfüllt werden?

Welchen Beitrag könnte ein Maschinen- und Anlagenbauer leisten, um den Umsatz seiner
Kunden zu steigern?
7.3.2.2 Verbesserung existierender Dienstleistungen
Eine Möglichkeit zur Definition neuer fernerbrachter Dienstleistungen bietet die Orientierung an
bereits etablierten, konventionell erbrachten Dienstleistungen. Bestehende Prozesse sowie die Ablauf- und Aufbauorganisation müssen gegebenenfalls angepasst und vereinfacht werden. Die
elektronische Abbildung historisch gewachsener Vorgehensweisen führt in der Regel nicht zur
Optimierung. Tabelle 7-2 zeigt einige Ansatzpunkte zur Identifikation von Potenzialen.
Betrachtungsobjekt
Untersuchungsgegenstand
Methoden und
Techniken
Potenziale
Prozess
Aufgabe,
Informationsbedarf,
Prozessergebnis
Methoden zur
Prozessmodellierung
Vereinfachung von
Verfahren, Verkürzung
von Prozessketten
Benutzer
Aufgabe, Qualifikation, Interview,
Wissen, Informations- schriftliche Befragung
bedarf
Reduzierung
beteiligter Rollenträger
Organisation
Aufbau- und
Ablauforganisation
Schnittstellenreduzierung, Verkürzung
von Durchlaufzeiten
Kommunikationsund Informationstechnologie
Datenquellen, -senken Methoden zur
und -menge, IT-Tech- Prozessmodellierung
nologie und -Systeme
Organigramme,
Rollenbeschreibungen
Datenaktualität,
Medienbrüche,
Wartungskosten
Tabelle 7-2: Ansatzpunkte zur Verbesserung existierender Dienstleistungen2
1
2
Vgl. /Bull-2006 (S. 141)/Huse-2005 (S. 44)/Fähn-2004a (S. 26 und S. 53)/Spat-2003b (S. 90)/Lay-2002 (S. 139)/Meir2002 (S. 40)/ Lies-2001 (S. 16)/.
In Anlehnung an /Fähn-2004a (S. 32)/.
- 126 -
7.3.2.3 Findung neuer Dienstleistungsideen
Zur Findung neuer Dienstleistungsideen gibt es zahlreiche Methoden1 von denen das Methodische
Konstruieren nach VDI 2221 sowie das Systems Engineering bereits im Kapitel 4.3 behandelt
wurden. Darüber hinaus kommen Kreativitätstechniken zum Einsatz, die sich in intuitive und diskursive Methoden unterscheiden lassen. Durch den Einsatz intuitiver Methoden lässt sich die
Kreativität der Beteiligten fördern. Andere intuitive Methoden sind Regeln für die Gruppenarbeit,
durch die Assoziationen angeregt werden sollen. Diskursive Methoden zielen auf die Zerlegung
des Problems in seine Komponenten sowie die Erarbeitung von Alternativen für jede der gefundenen Problemkomponenten ab. Auf dieser Grundlage werden dann Lösungsansätze gebildet.
7.3.2.4 Auswahl geeigneter Dienstleistungsideen
Im Anschluss an die Findung von Dienstleistungsideen müssen die Erfolg versprechenden Ideen
ausgewählt und in eine kommunizierbare Form gebracht werden, um eine Ideenbewertung durch
Dritte zu ermöglichen. Dies erfolgt in der Regel durch eine umgangssprachliche Beschreibung der
Anwendungsszenarien mit dem Schwerpunkt auf der Darlegung des Kundennutzens, einer
Wirtschaftlichkeitsbetrachtung sowie der Beschreibung von Realisierungsmöglichkeiten.
Die Auswahl geeigneter Dienstleistungsideen ist darüber hinaus vor dem Erfahrungshintergrund
der Beteiligten mit internetbasierten Diensten zu bewerten, sowie auch eng mit der Auswahl
potenzieller Pilotkunden verbunden. In vielen Fällen trägt die Auswahl geeigneter Pilotkunden
nachhaltig zur Definition geeigneter Anforderungen bei. Anforderungen, die mangels Erfahrung
lediglich auf Annahmen und Hypothesen beruhen, führen häufig zu äußerst komplexen Systemen,
deren Funktionalität in der Praxis nicht benötigt wird. Pilotkunden spielen darüber hinaus auch
später in der Vermarktung der Dienste eine große Rolle. Zufriedene und kommunikationsbereite
Pilotkunden ebnen den Weg zu einer breiteren Anwendung.
Nicht zuletzt sind die Dienstleistungsideen an der Unternehmensstrategie zu spiegeln. Erfüllt keine
Idee die Anforderungen, so ist mit der Ideengenerierung fortzufahren. Im Rahmen der Ideenauswahl sind gut bewertete Ideen für die weitere Detaillierung auszuwählen. Methoden zur
strategischen Positionierung und Klassifikation von Diensten wurden bereits im Kapitel 4.4.4 erläutert.
7.3.3
Anforderungsanalyse
Im Rahmen der Anforderungsanalyse sind die Rahmenbedingungen für die Entwicklung zu erfassen und festzulegen. Mit der Anforderungsanalyse wird die Zielsetzung verfolgt, eine umfassende Sichtweise der zu entwickelnden Dienstleistung zu gewinnen und diese in einem Lastenheft2 zu dokumentieren. Die Anforderungsanalyse ist eine sehr wichtige Projektphase. Aus den Erfahrungen der Softwareentwicklung weiß man, dass viele Projekte scheitern, weil die Anforderungen nicht ausreichend genau oder zu spät spezifiziert wurden3.
1
2
3
Vgl. Kartenabfrage, Benchmarking, SWOT, Expertenbefragung, Fragebogen, Funktionsanalyse, Ishikawa-Diagramm,
Lead-User-Analyse, Morphologische Methoden, Nutzwertanalyse, Szenariotechnik etc. Siehe Tabelle 7-1.
Gemäß /DIN-69905/ beschreibt ein Lastenheft die vom Auftraggeber festgelegte Gesamtheit der Forderungen an die
Lieferungen und Leistungen eines Auftragnehmers innerhalb eines Auftrages.
Neben dem vollständigen Scheitern eines Projekts können falsch spezifizierte Anforderungen aber auch weitere
negative Auswirkungen haben. Zu diesen gehören z. B. Nichteinhaltung des Budgets und Zeitplans, unzureichende
Qualität, unzureichende Funktionalität, schlechte Performance, Unzufriedenheit der Kunden, negative Auswirkungen
auf die Mitarbeitermotivation, wirtschaftlicher Schaden etc. Vgl. /Rupp-2002/.
- 127 -
An dieser Stelle erfolgt noch keine Berücksichtigung der IT-Sicherheitsanforderungen. Im Mittelpunkt der Betrachtung stehen vor allem die Kunden und der Kundennutzen. Zwar handelt es sich
bei den IT-Sicherheitsanforderungen ebenfalls um Anforderungen, jedoch kann eine aussagekräftige Analyse der IT-Sicherheitsanforderungen ohnehin erst dann erfolgen, wenn die Anforderungsanalyse bzgl. der fachlichen Dienstinhalte initial erfolgt ist. Es handelt sich demnach um
einen iterativen Prozess, den Anforderungsmanagementprozess, der nun vorgestellt wird.
7.3.3.1 Anforderungsmanagementprozess
Anforderungen sind in der Regel zu Beginn eines Projekts grob und konkretisieren sich im Lauf der
Zeit mit zunehmendem Erkenntnisgewinn. Der Anforderungsmanagementprozess ist demnach als
Zyklus zu verstehen. Gestellte Anforderungen und deren Änderungen sind zu dokumentieren,
bezüglich ihrer Risiken zu bewerten, zu berücksichtigen und über den gesamten Prozessverlauf zu
verfolgen (siehe Abbildung 7-3). Durch die Erfassung und Priorisierung interner und externer Anforderungen lässt sich Schritt für Schritt erarbeiten, welche Eigenschaften eine Dienstleistung
haben muss, um sowohl am Markt erfolgreich als auch im Unternehmen umsetzbar zu sein. Ferner
sollten kritische Erfolgsfaktoren erkannt und im weiteren Projektverlauf berücksichtigt werden.
Abbildung 7-3: Anforderungsmanagementprozess
7.3.3.2 Anforderungsanalyse aus Sicht der beteiligten Partner
Zur Anforderungsanalyse müssen die Dienstleistungsideen jeweils aus der Sicht der beteiligten
Partner betrachtet werden. Bei der Erbringung internetbasierter Dienstleistungen sind i. d. R.
mehrere Unternehmen in Kooperation beteiligt, weshalb man auch von der ASP1 Value Chain2
spricht. Fernerbrachte Dienste können nur dann genutzt werden, wenn die gesamte Wertschöpfungskette funktionsbereit ist, denn das schwächste Glied in der Kette bestimmt die
Leistungsfähigkeit des Gesamtsystems. Für die Fernerbringung von Diensten lassen sich die
folgenden Aufgaben identifizieren: der Netzwerkzugang, das Data Hosting, das Server Hosting, die
Softwareerstellung und -wartung sowie das Kundenmanagement (siehe Abbildung 7-4).
1
2
Ein Dienstleister, der seine Leistungen über Netzwerke anbietet, wird Application-Service-Provider (ASP) genannt.
ASP Value Chain, englisch sinngemäß für ASP-Wertschöpfungskette. Bruhn spricht in diesem Zusammenhang auch
von der Service Profit Chain für Dienstleistungen. Vgl. /Brun-2003 (S. 13)/
Infrastruktur
Netzwerkzugang und
dienste

Transport
und Zugriff
vom Kunden
zum Datacenter

- 128 -
Application Service Providing
Datahosting
Serverhosting
Softwareerstellung und
-wartung
Portalmanagement
Kunde /
Benutzer
Kunden Beschaffung, SystemInfrastruktur
management
integration
Konfiguration
(Datenspeich Helpdesk,
Lösungsund
er, -sicherheit,
Billing, usw.
design,
Installation
garantierter
Consulting
von ServerDurchsatz)
hardware und AnwendungsSystem- und
entwicklung,
-software
NetzwerkAnpassungen
management
Abbildung 7-4: ASP-Wertschöpfungskette
In Tabelle 7-3 sind die beteiligten Rollenträger genannt und exemplarisch unterschiedliche Anforderungen aufgeführt. Wie die Übersicht zeigt, sind die Anzahl der Beteiligten und die Verschiedenartigkeit der Anforderungen beachtlich groß1.
Rolle
Beschreibung
Beispiele
Anforderungsbeispiele
Anwender beim Der Dienstnutzer nutzt
Kunden
die Dienste.
Maschinenbediener,
Servicetechniker
Funktionalität, Benutzerfreundlichkeit
Kunde
Der Kunde schließt mit
dem Dienstbetreiber
Verträge.
Betreiber eines
Produktionssystems
Preise, Betriebskosten,
IT-Sicherheit
IT des Kunden
Die IT sorgt für den
reibungslosen IT-Betrieb
in der Domäne des
Kunden.
Rechenzentrum,
IT-Abteilung
Kompatibilität mit vorhandenen IT-Systemen,
IT-Sicherheit
Betreiber
(Datahosting)
Der Betreiber bietet
seinen Kunden Dienste
an.
Maschinenhersteller,
Automatisierer
Wartungsfenster,
Vertragslaufzeit
Third Party
Dienstanbieter
Ein Third Party Dienstanbieter bietet seine
Dienste Betreibern an.
SMS- und Fax-Versand,
Shopsystem,
Kreditkartenanbieter
Wartungsfenster,
Nutzungshäufigkeit
Dienstentwickler
Der Dienstentwickler
entwickelt Dienste.
interner oder externer
Softwareentwickler
Einspielen von Updates
und Upgrades
Infrastruktur IT
Internet Service Provider
Telekommunikationsanbieter
Datenmenge,
Vertragslaufzeit
Tabelle 7-3: Anforderungsanalyse aus Sicht der beteiligten Partner 2
Die Anforderungen der oben genannten Rollträger sind zu erfassen und entsprechend zu berücksichtigen. Man unterscheidet die in Tabelle 7-4 genannten Anforderungstypen:
1
2
Viele Telekommunikationsanbieter und IT-Dienstleister verfolgen die Strategie, diese Wertschöpfungskette aus einer
Hand anzubieten. Die dabei erwarteten Synergien sind unter dem Schlagwort Konvergenz gebündelt.
Vgl. /Tina-1997/Krei-2004 (S. 81)/.
Anforderungstyp
- 129 -
Ausprägung
bewusste
Anforderungen
Diese basieren auf konkreten Vorstellungen, Mängeln bestehender Produkte
oder dem Einsatz neuer Technologien und sind daher einfach zu formulieren.
unbewusste
Anforderungen
Hierzu gehören z. B. Funktionen eines Vorgängersystems, an die man sich
gewöhnt hat. Solche Funktionen werden häufig als selbstverständlich verstanden und können bei der Anforderungsanalyse übersehen werden.
ungeahnte
Anforderungen
Darunter versteht man Anforderungen, die im Projektverlauf erst dann aufkommen, wenn die Anwender die Möglichkeiten der neuen Anwendungen verstehen. Dieser Typ von Anforderung ist am schwersten zu identifizieren.
Tabelle 7-4: Anforderungstypen
Eine Möglichkeit zur inhaltlichen Einordnung der Anforderung ist die Einteilung in funktionale und
nicht-funktionale Anforderungen, technische Anforderungen sowie in Rahmenbedingungen.
Anforderungsart
Beschreibung
Funktionale
Anforderungen
Funktionale Anforderungen beschreiben die Fähigkeiten eines Systems, die
ein Anwender erwartet, um mit dessen Hilfe seine Aufgaben zu erfüllen. Die
Anforderungen werden aus den relevanten Geschäftsprozessen und Ablaufbeschreibungen zur Nutzung des Systems abgeleitet. Die Anforderungsbeschreibung kann in Form von Anwendungsfällen (Use Cases) erfolgen
(siehe Kapitel 4.1). Ein Anwendungsfall beschreibt einen in sich geschlossenen
Teilvorgang. Die Gesamtheit der Anwendungsfälle definiert das Systemverhalten.
Nichtfunktionale
Anforderungen
Nicht-funktionale Anforderungen beschreiben Anforderungen an das System,
die nichtfachlicher Natur sind, jedoch zur Anwendbarkeit des Systems beitragen. In der Regel sind sie daher schwerer quantifizierbarer als funktionale
Anforderungen. Sie definieren unter anderem Qualitätsanforderungen, Sicherheitsanforderungen oder Performanceanforderungen.
Technische
Anforderungen
Neben den funktionalen und nicht-funktionalen Anforderungen existieren auch
technische Anforderungen. Exemplarisch seien hier das Betriebssystem, die
Hardwareanforderungen und die Art der Datenbank genannt. Technische Anforderungen haben vor allem Einfluss auf die Anwendungsarchitektur.
Rahmenbedingungen
Zu den Rahmenbedingungen gehören Anforderungen, wie z. B. Zeit-, Budgetvorgaben sowie rechtliche Rahmenbedingungen. Diese Vorgaben müssen
immer eingehalten werden, sind aber nicht immer offensichtlich.
Tabelle 7-5: Anforderungsarten
7.3.4
- 130 -
IT-Sicherheitskonzept
Leider stehen den Vorteilen internetbasierter Mehrwertdienste durch die Vernetzung von Systemen
auch neue Gefahren gegenüber: die Bedrohung von Daten, Programmen und Ressourcen durch
Eingriffe von Dritten1. Die Bedrohung reicht von unbeabsichtigten Fehlern, über absichtliche
Manipulation oder Zerstörung, bis hin zur Computerkriminalität. Die Angriffstechniken2 auf Netzwerke, Rechner und Maschinen haben eine große Kraft und Vielfalt erreicht. Die Erarbeitung und
Durchsetzung eines wirksamen IT-Sicherheitskonzepts ist daher eine Notwendigkeit3.
Die Erstellung des IT-Sicherheitskonzepts hat Auswirkungen auf die Dienstleistungsdefinition, die
Anforderungsanalyse sowie auf die Dienstleistungskonzeption. Oftmals beeinflussen sich die
Aktivitäten gegenseitig, weshalb das IT-Sicherheitskonzept als Zyklus zu betrachten ist, der mehrfach zu durchlaufen ist.
In dieser Arbeit wird das IT-Sicherheitskonzept als eigenes Kapitel behandelt, um dessen Bedeutung herauszustellen. Von der IT-Sicherheit hängt es ab, ob die Anwender der Informationstechnik vertrauen und die Dienste nutzen. Die IT-Sicherheit wird damit zur entscheidenden
Schlüsselfrage.
7.3.4.1 Vorgehensweise zur Erstellung eines IT-Sicherheitskonzepts
Um zu einem bedarfsgerechten IT-Sicherheitsniveau zu kommen, ist nicht nur Hard- und Software
notwendig, sondern ein ganzheitliches IT-Sicherheitsmanagementkonzept. Beim IT-Sicherheitsmanagement handelt es sich um einen kontinuierlichen Prozess, dessen Strategien und Konzepte
ständig auf ihre Leistungsfähigkeit zu überprüfen und fortzuschreiben sind. IT-Sicherheit ist
demnach nicht ausschließlich eine Frage der Technik, sondern hängt in erheblichem Maße von
den organisatorischen Rahmenbedingungen ab. Dementsprechend ist auch das IT-Sicherheitsmanagement im Dienstbetrieb zu organisieren. Diesem Thema widmet sich Kapitel 7.14.
Da die Relevanz von Sicherheitsmaßnahmen in den letzten Jahren durch die zunehmende
Nutzung des Internets stark gestiegen ist, lässt sich auch ein Anstieg von Normungsbestrebungen
in diesem Bereich verzeichnen. Es sind eine Vielzahl unterschiedlicher Sicherheitsstandards,
-richtlinien und -empfehlungen entstanden4. Für die Erstellung eines IT-Sicherheitskonzepts für
internetbasierte Dienste sollten unter anderem die Empfehlungen von Berger5, Furrer6, Kreidler7,
KBSt8 sowie des BSI1 beachtet werden. Darüber hinaus ist den Online-Quellen eine hohe Bedeutung zuzumessen, da die IT-Sicherheit hohe Innovationsraten aufweist2.
1
2
3
4
5
6
7
8
Die Bedrohung von Daten, Programmen und Ressourcen wird auch als Netzwerksicherheit bezeichnet.
Zu den technischen Angriffstechniken zählen u. a.: Flooding, Spoofing, Sniffing, Ausnutzen von Lecks in Betriebssystemen, Viren, Trojanische Pferde, (Distributed) Denial of Service, Buffer Overflowing, Applets/ActiveX, Scanning,
Passwortcracker, Umkonfiguration, Broadcast-Angriff, Router/Switch-Attack etc.
Ein Beispiel: Der Computerwurm W32.Blaster beziehungsweise W32.Lovsan verbreitete sich innerhalb von nur vier
Stunden und infizierte dabei ca. 138.000 Rechner. Man geht davon aus, dass der flächendeckende Stromausfall am
14.08.2003 an der Ostküste der USA und Kanada durch diesen Computerwurm ausgelöst wurde.
Viele dieser Sicherheitsstandards, -richtlinien und -empfehlungen orientieren sich an dem international anerkannten
Sicherheitsstandard /DIN-61508/.
Vgl /Berg-2005 (S. 39)/
Vgl. /Furr-2003 (S. 243)/
Vgl. /Krei-2004 (S. 72)/.
Die Koordinierungs- und Beratungsstelle der Bundesregierung für Informationstechnik in der Bundesverwaltung
(KBSt) hat Standards und Architekturen für E-Government-Anwendungen (SAGA) veröffentlicht und schreibt diese
seit mehreren Jahren fort. Vgl. /KBSt-2006 (S. 109)/.
- 131 -
Die Empfehlungen des Bundesamts für Sicherheit in der Informationstechnik (BSI) gehören zu den
am meisten genutzten Standards für Informationssicherheit. Die Dokumente sind öffentlich zugänglich und werden regelmäßig fortgeschrieben. Die Vorgehensweise nach IT-Grundschutz3 und
die IT-Grundschutz-Kataloge4 empfehlen sowohl technische als auch nicht-technische Sicherheitsmaßnahmen für IT-Anwendungen und IT-Systeme5 und bieten eine systematische Methodik zur
Erarbeitung von IT-Sicherheitskonzepten und Sicherheitsmaßnahmen an. Tabelle 7-6 und Tabelle
7-7 beschreiben in Anlehnung daran eine Vorgehensweise beziehungsweise verweist auf die entsprechenden Kapitel.
Vorgehensschritt
Definition
des
Sicherheitsperimeters
Gegenstand
Die Erstellung eines IT-Sicherheitskonzepts beginnt mit der Definition des
Sicherheitsbereiches. Die Elemente innerhalb des Sicherheitsperimeters
müssen gesichert werden. Die Elemente außerhalb des Sicherheitsperimeters
gelten als nicht vertrauenswürdig und deren Zugang zum Sicherheitsperimeter
muss entsprechend kontrolliert beziehungsweise verhindert werden.
Die Sicherheit von Netzwerken und der angeschlossenen Rechner ist direkt miteinander verbunden. Die Netzwerksicherheit umfasst deshalb auch die
Computersicherheit, die durch Sicherheitslücken im Betriebssystem, in
Kommunikationstreibern, Anwendungsprogrammen etc. Bedrohungen ausgesetzt sind.
Bedrohungsanalyse
Die Bedrohungsanalyse besteht aus zwei Teilen: 1. Welcher Personenkreis
kann und mit welcher Motivation können Dritte ein Interesse haben, den
Elementen im Sicherheitsperimeter zu schaden? 2. Welche technischen
Möglichkeiten bestehen, um im Sicherheitsperimeter Schaden anzurichten?
Neue technische Bedrohungen treten täglich auf. Studien belegen allerdings,
dass die größten Sicherheitsrisiken von alten Softwareversionen stammen,
deren Sicherheitslücken bereits bekannt aber nicht gepatcht6 sind7.
Eine nicht zu unterschätzende Bedrohung geht von Angriffen von innen heraus
aus, bei denen die eigenen Mitarbeiter willentlich oder unwissentlich beteiligt
sind. Die Beeinflussung von Mitarbeitern zur Kollaboration ist meist die einfachste und schnellste Methode und wird als Social Engineering bezeichnet.
Tabelle 7-6: Vorgehensweise zur Erstellung eines IT-Sicherheitskonzeptes (1. Teil)
1
2
3
4
5
6
7
Das Bundesamt für Sicherheit in der Informationstechnik (BSI) entwickelt seine Vorgehensweise ständig weiter und
veröffentlicht diese seit 1994 jährlich neu. Vgl. /BSI-2006/BSI-2005a/BSI-2005b/BSI-2005c/BSI-2005d/.
Z. B. Heise Security News, vgl. /Heis-2007/.
Vgl. Der BSI-Standard 100-2 IT-Grundschutz-Vorgehensweise v1.0 /BSI-2005b/ beschreibt, wie ein IT-Sicherheitsmanagement in der Praxis aufgebaut ist und sich im laufenden Betrieb aufrechterhalten und verbessern lässt.
Vgl. Die IT-Grundschutz-Kataloge /BSI-2005d/ beschreiben Standardsicherheitsmaßnahmen. Durch die Nutzung der
Baustein-, Maßnahmen- und Gefährdungskataloge wird die Erstellung von IT-Sicherheitskonzepten unterstützt.
Vgl. Der BSI-Standard 100-1 Managementsysteme für Informationssicherheit (ISMS) v1.0 /BSI-2005a/ ist vollständig
kompatibel zum ISO-Standard 27001 und berücksichtigt die Empfehlungen der ISO-Standards 13335 und 17799.
Ein Patch (engl. für Flicken) ist eine Softwarekorrektur, um Sicherheitslücken zu schließen. Der Begriff stammt aus
der Zeit, als man Softwarekorrekturen auf Lochkarten durch Stanzen bzw. Zukleben von Löchern bewerkstelligte.
Ein Beispiel: Zwischen dem bekannt werden der Sicherheitslücke in der RPC-Schnittstelle des WindowsBetriebssystems und dem Auftreten des Computerwurms W32.Blaster beziehungsweise W32.Lovsan vergingen fast
vier Wochen. Microsoft stellte rechtzeitig Patches bereit und bat die Anwender diese zu installieren. Dem kamen die
Anwender allerdings nur unzureichend nach, was zu den bekannten Problemen führte.
Vorgehensschritt
Risikoanalyse
- 132 -
Gegenstand
Risiken werden durch Gefährdungen verursacht. Eine Gefährdung ist eine
Situation, die zu einem Schadensereignis führen kann. Um die Wahrscheinlichkeit eines Angriffs zu beurteilen, muss man folgende Szenarien unterscheiden:
- Ein Angriff richtet sich nicht direkt gegen das eigene Netzwerk. Das eigene
Netzwerk soll lediglich dazu benutzt werden, um Angriffe auf Dritte durchzuführen. Eine typische Angriffstechnik ist das DoS beziehungsweise DDoS1.
- Der Angriff richtet sich direkt gegen das eigene Netzwerk.
Der Schutzbedarf von IT-Systemen orientiert sich an den möglichen Schäden,
die mit einer Beeinträchtigung der betroffenen Softwareanwendung verbunden
sind. Ein hohes Risiko besteht immer dann, wenn der Dienstnutzer selbst Teil
eines Netzwerks ist. Störungen oder Angriffe können sich gegebenenfalls auf
das gesamte Netzwerk des Dienstnutzers ausdehnen. Die höchsten Sicherheitsanforderungen sind notwendig, wenn das betroffene System zugleich Aufgaben zur Steuerung und Regelung einer Maschine hat. Angriffe können unmittelbare Auswirkungen auf die Hardware somit auf das Bedienerpersonal
haben2.
Kap. 7.3.4.2
Aufwand-Nutzen-Relation für IT-Sicherheit
Kapitel 7.4
E-Service-Infrastruktur
Kapitel 7.7
E-Service-Anwendungsarchitektur
Kapitel 7.14
IT-Service-Management
²
Vorgriff auf nachfolgende Kapitel
Tabelle 7-7: Vorgehensweise zur Erstellung eines IT-Sicherheitskonzeptes (2. Teil)
7.3.4.2 Aufwand-Nutzen-Relation für IT-Sicherheit
Ganz grundsätzlich gilt, dass es keine absolut sicheren Systeme gibt. Jedes System hat Sicherheitslücken, die mit entsprechendem Aufwand gefunden und ausgenutzt werden können. Bedrohungen können Schäden und damit Kosten verursachen; Risikovorsorge kostet jedoch auch
Ressourcen. Das Ziel aller Sicherheitsbemühungen ist, einerseits den Aufwand eines Angreifers
zu erhöhen und andererseits die Wirkung eines erfolgreichen Angriffs zu minimieren. Deshalb ist
beim Festlegen des IT-Sicherheitsniveaus darauf zu achten, dass das angestrebte IT-Sicherheitsniveau auch wirtschaftlich sinnvoll ist. Die nachstehende Abbildung 7-5 soll symbolisch den Zusammenhang zwischen Aufwand und angestrebtem IT-Sicherheitsniveau verdeutlichen.
1
2
Als Denial of Service (DoS), englisch für Dienstverweigerung, bezeichnet man einen Angriff auf einen Host, um einen
oder mehrere seiner Dienste arbeitsunfähig zu machen. In der Regel geschieht dies durch Überlastung. Erfolgt der
Angriff koordiniert von einer größeren Rechneranzahl aus, so spricht man von Distributed Denial of Service (DDoS).
Vgl. /Berg-2005 (S. 28)/.
- 133 -
100 %
IT-Sicherheitsniveau
sehr hoch
hoch
normal
IT-Grundschutz
Aufwand
Abbildung 7-5: Aufwand-Nutzen-Relation für IT-Sicherheit1
Ein weiterer Aspekt ist, dass die Anforderungen bezüglich Benutzerfreundlichkeit und IT-Sicherheit
häufig gegenläufig sind. Eine hohe Sicherheit ist in der Regel mit niedrigerer Benutzerfreundlichkeit verbunden und gute Benutzerfreundlichkeit hat oft eine geringere IT-Sicherheit zur Folge. Falls
die eingeführten Sicherheitsprozeduren den Anwender an der Arbeit hindern, wird dieser versuchen, sie zu umgehen. Es ist demnach auch wichtig, dass die Anwender von den Sicherheitsprozeduren überzeugt sind. Dies sollte bei der Gestaltung berücksichtigt werden.
7.3.5
Die Dienstleistungskonzeption ist eine Entwicklungsphase, in welcher die Ideen aus der Dienstleistungsdefinition, der Anforderungsanalyse und des IT-Sicherheitskonzepts konsolidiert werden.
Sukzessiv erfolgt die Entwicklung des Produkt- und Prozessmodells sowie des Ressourcen- und
Marketingkonzeptes. Das Ergebnis der Dienstleistungskonzeption ist ein widerspruchsfreies und
fehlerfreies Konzept. Die Grundlagen hierzu wurden bereits im Kapitel 4.4.5 erläutert.
7.3.5.1 Festlegung des Produkts
Die Formulierung des Kundennutzens steht bei der Festlegung des Dienstleistungsprodukts beziehungsweise des Dienstleistungsergebnisses an erster Stelle. Dabei wird explizit herausgearbeitet, welche Vorteile dem Kunden durch eine neue Dienstleistung entstehen. Eine verbreitete Möglichkeit zur Festlegung eines Produkts ist die Erstellung von Anwendungsszenarien.
Aus diesen umgangssprachlich formulierten Anwendungsszenarien sind die notwendigen Aktoren,
funktionale und technische Systemgrenzen sowie Use Cases abzuleiten. Use Cases beschreiben
die Anwendungsszenarien, und somit die Funktionalität eines Mehrwertdienstes. Die Use Cases
können unter Verwendung von UML erzeugt werden (siehe Kapitel 4.1.3). Um die Produkte greifbarer zu machen, bietet es sich an, Entwürfe von Benutzeroberflächen (siehe Kapitel 4.5.7) zu erstellen. Anwendungsszenarien, Use Cases und Testszenarien bilden das Produktmodell.
Aus den unterschiedlichen Use Cases lassen sich in der Regel mehrere Dienstleistungsprodukte
ableiten, die zu verschiedenen Leistungsvarianten kombiniert werden können. Dabei sollte auch
die Kombination von geplanten und eventuell bereits vorhandenen Dienstleistungsprodukten zu
einem ganzheitlichen Angebot untersucht werden.
1
Vgl. /BSI-2005b (S. 26)/.
- 134 -
7.3.5.2 Festlegung der Prozesse
In diesem Entwicklungsschritt werden die notwendigen Prozesse und die Schnittstellen identifiziert
und in einem Prozessmodell festgehalten. Hierfür sollen von der Anfrage bis zur Leistungserbringung alle Vorgänge betrachtet werden. Die Effizienz der Dienste hängt wesentlich von einer
ganzheitlichen Betrachtung ab. Das heißt, dass man zunächst nicht die Informationstechnologie in
den Vordergrund stellt, sondern die fachlichen Prozessmodelle betrachtet und beschreibt. Diese
Prozessmodelle sollten in dieser Entwicklungsphase auf einem relativ abstrakten Niveau verbleiben.
Methoden zur Prozessmodellierung, wie z. B. das Service-Blueprinting, eEPKs etc., wurden bereits
in Kapitel 4.1 vorgestellt. Grundlagen zum Gap-Modell sind in Kapitel 4.4.5 erläutert.
7.3.5.3 Festlegung der Ressourcen
Aus dem Prozessmodell ist ein Ressourcenkonzept abzuleiten, das die zur Leistungserbringung
notwendigen Personal- und IT-Ressourcen definiert. Wie bereits in Kapitel 7.3.3.2 vorgestellt, sind
bei der Erbringung fernerbrachter Dienstleistungen mehrere Unternehmen in Kooperation beteiligt.
Aufgrund der Vielfältigkeit der Thematik ist es für die Erstellung des Ressourcenkonzepts in dieser
Phase des Vorgehensmodells noch nicht erforderlich, für alle assoziierten Themen ein detailliertes
Ressourcenkonzept zu haben. Es genügt, einen Einblick in die grundsätzliche Thematik zu haben.
Die Detaillierung der Konzepte erfolgt im Rahmen des IT-Feinkonzepts ab Kapitel 7.4.
7.3.5.4 Konsolidierung der Dienstleistungskonzeption
Eine Möglichkeit zur Konsolidierung einer Dienstleistungsidee und zur Bewertung deren Wirtschaftlichkeit liegt in der Erstellung eines Business Cases oder Geschäftsplans. Das Ziel ist dabei,
die Kosten eines Projekts den erwarteten Erträgen gegenüberzustellen, und damit Aussagen über
die Kapitalrendite, die Amortisationszeit und andere betriebswirtschaftlichen Kennzahlen abzuleiten. Diese Ergebnisse sind mit der Unternehmensstrategie und den Ergebnissen der Markt- und
Wettbewerberanalyse sowie der Potenzial- und Trendanalyse in Einklang zu bringen. Werden
einzelne Anforderungen nicht erfüllt, so sind frühere Konzeptionsphasen erneut zu durchlaufen.
Während zur Umsetzung eines einzelnen Mehrwertdiensteprojekts die Erstellung eines Business
Case1 häufig ausreicht, empfiehlt sich bei größeren Projekten oder gar beim Aufbau neuer Geschäftsfelder die Erstellung eines umfassenderen Geschäftsplans2. Ein solcher Geschäftsplan
dient der schriftlichen Fixierung der Unternehmensplanung zur betriebswirtschaftlichen Absicherung von Chancen und Risiken. Ein Geschäftsplan enthält neben der Marktforschung vor
allem die Wettbewerbsabgrenzung sowie eine Zielformulierung für den Einsatz der einzelnen
Produktionsfaktoren.
Oftmals wird auf Basis des Business Case beziehungsweise Geschäftsplans darüber entschieden,
ob eine Dienstleistung realisiert wird oder nicht. Im positiven Fall ist mit der weiteren Ausgestaltung
und Planung fortzufahren3.
1
2
3
Ein Business Case ist ein Szenario zur betriebswirtschaftlichen Beurteilung einer Investition.
Business Plan, englisch für Geschäftsplan.
Umfangreiche Literatur, Werkzeuge und sonstige Hilfsmittel zur Geschäftsplanung bietet das Bundesministerium für
Wirtschaft im Internet unter </http://www.softwarepaket.de/>, letzter Abruf am: 01.05.2008, an.
- 135 -
7.4 E-Service-Infrastruktur
Wie bereits in Kapitel 6.1 definiert, beschreibt eine Infrastruktur die Kapselung von Systemeinheiten und deren Vernetzung. Die Definition einer E-Service-Infrastruktur dient dem Ziel, die
infrastrukturellen Voraussetzungen für den Betrieb von Mehrwertdiensten zu definieren. Neben
Fragen der Verfügbarkeit und Skalierbarkeit hängt von der Infrastruktur maßgeblich die IT-Sicherheit ab. Die E-Service-Infrastruktur ist Bestandteil des Engineering Viewpoints im RM-ODP-Modell.
Die Gestaltung der E-Service-Infrastruktur setzt auf der in Kapitel 7.3.5 erarbeiteten Dienstleistungskonzeption auf und detailliert diese insbesondere bezüglich des IT-Ressourcenkonzepts.
7.4.1
Hardware-Architektur
Die unterschiedlichen Hardware-Architekturen wurden bereits in Kapitel 6.2 erläutert. Tabelle 7-8
fasst die Merkmale zusammen und bewertet diese.
Merkmal
Mainframe
Filesharing
Client-Server
Terminalserver
Ausführungsort
nur Server
nur Client
Server und Client
nur Server
Hardwareanforderungen Server
sehr hoch
jeder Client ist
zugleich Server
hoch
sehr hoch
Hardwareanforderungen Client
gering
abhängig von der
Anwendung
abhängig von der
Anwendungsarchitektur
gering
Plattform
monolithisch und
zentralisiert
heterogen
heterogen
Server monolith.,
Clients heterogen
Netzwerk
geschlossen
heterogen
heterogen
heterogen
Datenformat
proprietär
heterogen
proprietär
proprietär
Kommunikation
Datenbank
Kommunikation
Technologiefokus Betriebssystem
Bewertung
Mainframe
Filesharing
Client-Server
Terminalserver
-
--
++
Ø
Eignung
Begründung
Legende
ursprünglich
zeichenbasierte
Anwendungen
++
sehr gut
keine
gut nutzbar,
InformationsverStandard
arbeitung möglich
+
gut
Ø
durchschnitt
ausreichend
eingeschränkt
nutzbar, schlechte
Grafikdarstellung
-mangelhaft
Tabelle 7-8: Gegenüberstellende Bewertung verschiedener Hardware-Architekturen
Zwar haben in einigen Sonderfällen Mainframes noch ihre Berechtigung, die meisten IT-Systeme
werden heute jedoch auf Basis von Client-Server- und zunehmend auch Terminalserver-Konzepten realisiert1. Heutige Filesharing-Architekturen ermöglichen den Austausch von Daten. Sie ermöglichen jedoch keine Informationsverarbeitung und sind daher ungeeignet. Aus diesen Gründen
wird für internetbasierte Mehrwertdienste eine Client-Server-Hardware-Architektur favorisiert.
1
Neuere Mainframe-Entwicklungen versuchen, in bestimmten Fällen – z. B. bei besonders hohen PerformanceAnforderungen – Großrechner zu positionieren. Dabei emuliert der Großrechner mithilfe einer Applikation eine Vielzahl virtueller Server, die jeweils mit eigenem Betriebssystem und eigenen Applikationen scheinbar unabhängig sind.
7.4.2
- 136 -
Kommunikationsnetzwerk
Abgeleitet von den Anforderungen der Dienste (siehe Kapitel 7.3.5) sowie den Schutzbedarfsanforderungen (siehe Kapitel 7.3.4) ist ein geeignetes Kommunikationsnetzwerk auszuwählen,
dessen Eigenschaften (siehe Kapitel 6.1.2) den Anforderungen entsprechen. In der Regel wird
man zur Diensterbringung aufgrund der flächendeckenden und kostengünstigen Verfügbarkeit das
öffentliche Internet nutzen. Gegebenenfalls unter Zuhilfenahme von Sicherheitstechnologien, wie
beispielsweise VPN. Für Dienste mit sehr hohen Anforderungen empfiehlt sich die Nutzung eines
Private Networks, wie z. B. ENX. Solche Kommunikationsnetzwerke garantieren Sicherheit bei der
Datenübertragung, Authentizität der Partner und feste Bandbreiten.
7.4.3
Kommunikationsstruktur
Wie bereits in Kapitel 6.1.3 dargestellt, sind Kommunikationsstrukturen, bei denen der Client die
Funktion des Web-Servers beziehungsweise Web- und Applikationsservers einnimmt, aufgrund
der notwendigen öffentlich bekannten IP-Adressen als problematisch einzustufen. Öffentlich bekannte IP-Adressen sind von jedem Internetnutzer ansprechbar, und damit beliebigen Angriffen
aus dem Kommunikationsnetzwerk ausgesetzt. Daher wird dringend empfohlen, den Dienstnutzer
als Client und den Dienstleister als Server zu gestalten.
7.4.4
Ausführungsort und Datenhaltung
Um zu vermeiden, dass jeder neue Mehrwertdienst die manuelle Installation einer eigenen ClientSoftware erfordert, wird der einheitliche Zugang über Web-Browser empfohlen. Es sei denn, die
umzusetzenden Dienstleistungen sind weder über Web-Browser noch über Web-Browser Addons1 beziehungsweise Plug-ins2 sinnvoll abbildbar. Da aus Gründen der IT-Sicherheit die Mehrwertdienste auch dann noch nutzbar sein sollen, wenn beim Client alle aktiven Inhalte deaktiviert
wurden, sollte die Informationsaufbereitung in allen übrigen Fällen serverseitig stattfinden. Damit
wird verhindert, dass die Anwender die Sicherheitseinstellungen des Browsers herabsetzen und so
Beschädigungen durch unsichere Webseiten ermöglichen.
Der Ausführungsort eines Mehrwertdienstes lässt sich nur aus dem individuellen E-Service-Design
ableiten und ist daher dienstspezifisch. Gegebenenfalls sind hybride Infrastrukturen zu gestalten
(siehe Kapitel 6.1.4). Mehrwertdienste sollten – falls möglich – keine Programmteile oder Daten auf
den Client-Computern der Anwender ablegen. Unkontrollierte Manipulationen könnten die Integrität
der Daten verletzen und u. U. zum Ausfall der Dienste führen. Andererseits ist die Verwendung
von Add-ons oder Plug-ins aus Aufwandsgründen der manuellen Installation einer dienstspezifischen Client-Software vorzuziehen.
7.4.5
Physikalische Infrastruktur und Zonenkonzept
Der Schutz von IT-Systemen gegen äußere Einflüsse, unbefugten Zugang etc. bedingt die Einrichtung einer physikalischen Infrastruktur. Systemeinheiten, die außerhalb des Sicherheitsperimeters liegen, lassen sich in der Regel nicht schützen. Die Systeme innerhalb des Sicherheitsperimeters müssen in verschiedenen Zonen platziert werden, die anhand der Sicherheitsanforderungen für Dienste und Daten zu definieren sind. Um den grundsätzlichen Schutzbedarf
1
2
Ein Add-on (von engl. to add „hinzufügen“) ist ein optionales Modul, welches eine bestehende Software erweitert.
Ein Plug-in (von engl. to plug in „einstöpseln“) ist ein Computerprogramm, das in ein anderes Softwareprodukt „eingeklinkt“ wird, um dieses zu ergänzen. Im Unterschied zum Add-on stellt ein Plug-in eine eigenständige Software dar.
- 137 -
von Anwendungen abdecken zu können, sollen mindestens folgende fünf Zonen in der Infrastruktur eines Rechenzentrums vorhanden sein: Informations- und Dienstzone, Logik- und Verarbeitungszone, Datenzone, Managementzone, Datensicherung (siehe Abbildung 7-6). Für den
Betrieb komplexer Anwendungen können weitere Zonen erforderlich werden. Dabei sollte auf eine
physikalische Trennung der Zonen geachtet werden1.
Benutzer /
externe
Systeme
Bestandssysteme
Zentrale
Basisdienste
Benutzer sowie externe Systeme und Dienste
Intranet
Extranet
Internet
Netzwerk
Logik- und Verarbeitungszone
Datensicherung
Administration
Informationsbereitstellungszone
Datenhaltungszone
Anwendungsarchitektur
Abbildung 7-6: Spezifikation einer physikalischen Infrastruktur sowie eines Zonenkonzepts2
1
2
Hierzu gehören: geschlossener Sicherheitsraum, Eintrittskontrolle mit Authentifizierung, Löschanlage, redundante
Energieversorgung mit unterbrechungsfreier Stromversorgung, redundant ausgelegte Klimaanlage sowie Datensicherung in einem Tresor außerhalb des Rechenzentrums. Vgl. /KBSt-2006 (S. 69)/.
Vgl. /KBSt-2006 (S. 71)/.
- 138 -
7.5 E-Service-Prozessarchitektur
Die Aufgabe der Prozessarchitektur ist die Festlegung der erforderlichen Diensterbringungsprozesse. Die E-Service-Prozessarchitektur ergänzt und detailliert die in Kapitel 7.3.5 erarbeitete
Dienstleistungskonzeption im Hinblick auf die technischen Prozesse unter Berücksichtigung der in
Kapitel 7.4 gewählten E-Service-Infrastruktur. Die Prozessarchitektur ist im RM-ODP-Modell Bestandteil des Enterprise Viewpoints.
7.5.1
Zielsetzung und Vorgehensweise
Die Erarbeitung einer Prozessarchitektur dient dem Zweck, gemeinsame Prozessmerkmale zu
identifizieren und zusammenzuführen, indem Aktivitäten entweder als alternative Verzweigungen
modelliert oder unter Verwendung von abstrakteren Prozessschritten generalisiert werden. Ziel ist
es, Prozessteilmodelle zu erstellen, die dienstunabhängig mehrfach verwendet werden können.
Hierzu sind die im E-Service-Design erstellten Use Cases einzeln zu betrachten und daraus Interaktionsdiagramme zu entwerfen. Je nach Anwendungsumfang können auch mehrere Interaktionsdiagramme erstellt werden, um die verschiedenen Abläufe und Szenarien darzustellen. Damit ist
der Grundstein für den wiederverwendbaren Komponentenkatalog gelegt, der im Kapitel 7.11 vorgestellt wird. Falls bereits ein Komponentenkatalog existiert, ist zu prüfen, welche Teile der
Prozessarchitektur mit bereits vorhandenen Komponenten abbildbar sind.
7.5.2
Generisches Prozessmodell zur Dienstleistungserbringung
Basierend auf den oben genannten Überlegungen wird im Folgenden ein generisches Dienstleistungsmodell abgeleitet. Die Teilschritte sind in Phasen gegliedert, aus denen sich später
funktionale Komponenten ableiten lassen. Das generische Prozessmodell hat sich bei den vom
Autor gestalteten Mehrwertdiensten bewährt. Die Anwender des Vorgehensmodells sind aufgerufen, dieses Prozessmodell entsprechend ihrer Anforderungen individuell anzupassen.
Phase 1: Dienstanbahnung und -vorbereitung
In der Dienstanbahnungs- und -vorbereitungsphase recherchiert der Kunde, sammelt
Informationen und vergleicht Angebote.
Teilschritt
Aktion und Rolle
Recherche
Zur Recherche verwenden die Anwender zunächst Suchmaschinen
oder Registry-Dienste, um eine geeignete Dienstleistung zu finden.
Authentifikation des
Benutzers
Nach der Sichtung des Leistungsangebots eines Dienstanbieters erfolgt
dessen Authentifikation zur Feststellung seiner Identität.
Präsentation des
Dienstangebots
Die Dienstverwaltungsfunktion einer Internetservice-Plattform prüft,
welche Dienste der angemeldete Anwender nutzen darf.
Tabelle 7-9: Teilschritte, Aktionen und Rollen in der Dienstanbahnung und -vorbereitung
- 139 -
Phase 2: Dienstverhandlung und -vereinbarung
In der Dienstverhandlungs- und -vereinbarungsphase werden die Leistungen, Konditionen und die
Abwicklung verhandelt. Gegebenenfalls mündet diese Phase in eine Dienstvereinbarung (Vertrag).
Teilschritt
Aktion und Rolle
Dienstverhandlung
In der Dienstverhandlung werden die Leistungen und Konditionen verhandelt sowie technische Abwicklungsfragen, wie z. B. verfügbare
Bandbreite, Kompatibilität der Systeme etc., geklärt.
Dienstvereinbarung
Sind die Verhandlungen beendet, wird eine Dienstvereinbarung geschlossen. Das Zustandekommen des Vertrags wird protokolliert.
Tabelle 7-10: Teilschritte, Aktionen und Rollen in der Dienstverhandlung und –vereinbarung
Phase 3: Dienstnutzung
Die effektive Dienstnutzung startet mit Beginn dieser dritten Phase. Optional können noch weitere
Dienste gestartet werden, d. h., die Phase 3 kann mehrfach durchlaufen werden.
Teilschritt
Aktion und Rolle
Start der Dienstnutzung
Dazu wird eine entsprechende Aufforderung vom Anwender übermittelt,
die den Start der Dienstinstanz beim Dienstanbieter initiiert.
Logging
Grundlage für die Abrechnung ist der Nachweis über in Anspruch genommene Leistungen. Dies erfordert die Aufzeichnung der Dienstnutzung durch Logging-Mechanismen.
Dateneingabe und
-kommunikation
Zur Nutzung der Dienste sind Kommunikationsmedien und -protokolle
notwendig, um Benutzereingaben und Nutzdaten zwischen dem Anwender und dem Dienstanbieter auszutauschen.
Dienstlogik
Die empfangenen Daten werden beim Dienstanbieter durch interne
Logiken oder externe IT-Systeme verarbeitet, die sich je nach Inhalt
und Ausprägung der Dienstleistung unterscheiden. Gegebenenfalls
kann die Dienstlogik selbst andere Dienste starten.
Benachrichtigung des
Nutzers
Da die Durchführung komplexer Berechnungen beim Dienstanbieter
unter Umständen einige Zeit dauern kann, ist eine Benachrichtigung
des Benutzers über vorliegende Berechnungsergebnisse notwendig.
Visualisierung der
Ergebnisse
Der Anwender bekommt das Ergebnis über ein Content-ManagementSystem o. ä. angezeigt.
Archivierung der
Ergebnisse
Die ermittelten Ergebnisse werden in aufbereiteter Form gesammelt
und für den Anwender in einem Archiv dokumentiert.
Tabelle 7-11: Teilschritte, Aktionen und Rollen in der Dienstnutzung
- 140 -
Phase 4: Beendigung der Dienstnutzung
Zum Zeitpunkt der Dienstbeendigung wird der Dienst gestoppt. Gegebenenfalls kann sich direkt
eine Rechnungsstellung anschließen.
Teilschritt
Aktion und Rolle
Beendigung des
Dienstes
Die Nutzung eines Dienstes kann prinzipiell auf zwei Ebenen beendet
werden. Zum einen kann die Dienstnutzung aus dem Dienst heraus beendet werden. Zum anderen ist eine Beendigung des Dienstes aus der
Zugangssitzung heraus durch den Anwender möglich.
Accounting
Das Accounting errechnet auf Basis der Logging-Daten den Preis für
die Nutzung der Dienste.
Tabelle 7-12: Teilschritte, Aktionen und Rollen in der Beendigung der Dienstnutzung
Phase 5: Beendigung des Dienstzugangs
Wird der Dienstzugang durch den Dienstanbieter gestoppt, ist der Dienstnutzer nicht mehr zur
Nutzung des Dienstes berechtigt.
Teilschritt
Aktion und Rolle
Beendigung des
Dienstzugangs
Nachdem der Kunde einen Dienst beendet hat, kann der Dienstanbieter
gegebenenfalls den Zugang zur Plattform vollständig stoppen.
Tabelle 7-13: Teilschritte, Aktionen und Rollen in der Beendigung des Dienstzugangs
Aus den oben genannten generischen Phasen lässt sich das in Abbildung 7-7 exemplarisch dargestellte Modell einer Diensterbringung ableiten. Jeder Teilprozess benötigt dabei mindestens eine
Komponente zur Ausführung des Prozesses. Die in der Abbildung eingezeichneten Komponenten
und Verknüpfungen haben nur symbolischen Charakter und müssen individuell zugeordnet
werden.
Dienstanbahnung
und -vorbereitung
Authentifizierung
Verzeichnisdienste
Dienstverhandlung und vereinbarung
Datenübertragung
Kooperationskomponenten
Dienstnutzung
Beendigung
der Dienstnutzung
Berechnung
Ergebnisdarstellung
Anwendungskomponenten
Basiskomponenten
Abbildung 7-7: Exemplarische E-Service-Prozessarchitektur
Beendigung
des Dienstzugangs
Leistungsnachweis
Integrationskomponenten
- 141 -
7.6 E-Service-Integrationsarchitektur
Viele Mehrwertdienste basieren auf der Nutzung verschiedener Informationsquellen und Anwendungen und stellen diese unter einer gemeinsamen Benutzeroberfläche dar. Die Abwicklung von
Geschäftsprozessen erfordert daher eine Betrachtung der Schnittstellen zwischen den Bestandssystemen und der E-Service-Architektur. Diesem Aspekt trägt die E-Service-Integrationsarchitektur
Rechnung. Sie wird im RM-ODP-Modell dem Computational Viewpoint zugeordnet.
7.6.1
Integrationsarten
Grundsätzlich lassen sich die in Tabelle 7-14 dargestellten Integrationsarten unterscheiden. In den
beiden oberen Quadranten wird der manuelle Zugriff auf Anwendungen mittels Portalen dargestellt. Zur Anwendergruppe gehört z. B. ein Servicetechniker, der Zugriff auf Dokumentationen,
aktuelle Lagerbestände oder Liefertermine von Ersatzteilen benötigt. Ähnliche Anforderungen
haben Geschäftspartner und Kunden, die für sie zugängliche Dienste nutzen wollen.
Da die Informationen oftmals auf unterschiedlichen Systemen verteilt sind, ist in der Praxis häufig
kein direkter Zugriff möglich. Es bedarf einer Integrationsarchitektur, welche die Verknüpfung
zwischen den Systemen herstellt und die Applikationen und Daten integriert. Dies ist in den
unteren beiden Quadranten dargestellt.
Interner Zugriff
von Mitarbeitern
Externer Zugriff
von Partnern und Kunden
Menschliche
Integration
einheitlicher Zugriff auf
unternehmensinterne Anwendungen
(Portale)
einheitlicher Zugang zu
freigeschalteten Diensten
(Portale)
Applikationsintegration
Integration unternehmensinterner Anwendungen
(Enterprise Application Integration)
unternehmensübergreifende
Integration von Geschäftsprozessen
(Enterprise Application Integration)
Tabelle 7-14: Integrationsarten von Diensten
7.6.2
Spezifikation einer Integrationsarchitektur
Die Applikationsintegration kann auf vier Ebenen erfolgen, wie Abbildung 7-8 zeigt. Tabelle 7-15
beschreibt und bewertet diese Integrationsmöglichkeiten.
1. Integration durch Benutzerinteraktion auf Präsentationsebene
Präsentation
Präsentation
3. Integration durch Benutzerinteraktion auf Präsentationsebene
Geschäftslogik
Geschäftslogik
Geschäftslogik
Geschäftslogik
4. Integration zwischen den
Geschäftslogikebenen
Persistenz
Persistenz
2. Datenaustausch auf
Persistenzebene
Abbildung 7-8: Integrationsmöglichkeiten zwischen IT-Systemen
Persistenz
Persistenz
System 22
System
System 11
System
Präsentation
Präsentation
Integrationsebene
- 142 -
Beschreibung
Bewertung
1. Integration durch
Benutzerinteraktion
auf Präsentationsebene
Der Anwender arbeitet auf einer
Präsentationsebene, die von verschiedenen autarken Subsystemen gespeist wird. Die Geschäftslogikebenen der Systeme
weisen keine Kopplung auf.
Hoher Wartungsaufwand, da
Änderungen in beiden Systemen
parallel gepflegt werden müssen.
2. Datenaustausch
auf Persistenzebene
Der Datenaustausch erfolgt über
einen Informationsspeicher z. B.
über eine Datenbanktabelle.
Gefahr von Inkonsistenzen, da unbekannt ist, wann im Fremdsystem
die Speicherung erfolgt.
Da kein Kontext zwischen den
Systemen ausgetauscht wird,
leidet die Benutzerfreundlichkeit.
Detaillierte Kenntnisse des Fremddatenmodells erforderlich.
Die Abhängigkeit zwischen den
Systemen steht im Widerspruch
zum Wunsch nach loser Kopplung.
3. Benutzerinteraktion zwischen
Präsentations- und
Geschäftslogikebene
Die Benutzerinteraktion zwischen
der Präsentationsebene des
Systems 1 erfolgt durch einen
Methodenaufruf der Geschäftslogikebene des Systems 2.
Wenngleich diese Art der
Integration flexibler ist, als die
beiden oben skizzierten, stellt
diese Integrationsform dennoch ein
Gefahrenpotenzial dar. Mit zunehmender Anzahl von Verknüpfungen wird der Wunsch nach
loser Kopplung zunehmend beeinträchtigt.
Diese Integrationsform sollte nur in
Ausnahmefällen benutzt werden.
4. Integration
zwischen den
Geschäftslogikebenen
Diese Integrationsform basiert auf
der Nutzung öffentlich bereitgestellter Programmierschnittstellen.
Der Wunsch nach loser Kopplung
wird erfüllt.
Diese Integrationsform unterstützt
die Kommunikation und Interoperabilität unterschiedlicher Anwendungen und Prozesse.
Die bevorzugte Integration von
Systemen ist die Integration auf
der Geschäftslogikebene.
Die Erweiterbarkeit und Anpassbarkeit sind gegeben.
Tabelle 7-15: Beschreibung der Integrationsmöglichkeiten zwischen IT-Systemen
7.6.3
- 143 -
Integrationsmuster
Jeder Integrationsmöglichkeit lassen sich Technologien zuordnen, wenngleich es Überlappungen
zwischen den Integrationsmöglichkeiten und den dafür erforderlichen Technologien gibt. Dies rührt
aus der unterschiedlichen Technologieverwendung her. Die Spezifikation einer Integrationsarchitektur umfasst streng genommen keine Technologien, sondern beschäftigt sich mit der
prinzipiellen Integration. Dennoch sollten die grundlegenden Integrations- und Transaktionsansätze1 bekannt sein. Eine Vertiefung der technologischen Aspekte erfolgt im Kapitel 7.12.1.

Der Begriff EAI2 umfasst verschiedene Technologien und Architekturen, welche die Kommunikation und Interoperabilität unterschiedlicher Anwendungen und Geschäftsprozesse durch die
Verwendung von Middleware ermöglichen.

In jüngster Vergangenheit wird der Begriff EAI zunehmend durch den Begriff der SOAArchitektur verdrängt, die bereits im Kapitel 6.4.3 vorgestellt wurde.

Business Process Management-Systeme (BPM) stellen die nächste Evolutionsstufe dar. Der
Kern solcher Systeme liegt im Austausch von Nachrichten. Eingehende Meldungen werden
interpretiert, um festzustellen, ob eine Nachricht ein Ereignis darstellt, das als Auslöser eines
Geschäftsprozesses definiert ist. Technisch gesehen basieren BPM-Systeme auf MassageBrokern (auch EAI-Toolsets oder Integration-Server genannt), deren Basis wiederum SOAArchitekturen sein können. BPM-Systeme nutzen Beschreibungs- und Ausführungssprachen,
die bereits in Kapitel 4.2 zur Prozessmodellierung vorgestellt wurden.
1
Als Transaktion bezeichnet man eine definierte Folge von Operationen, die als logische Einheit betrachtet werden.
Transaktionssicherheit bedeutet, dass eine Transaktion entweder vollständig oder überhaupt nicht ausgeführt wird,
und somit stets die Konsistenz eines Datenbestands gewahrt bleibt (ACID-Eigenschaften).
EAI, englische Abkürzung für Enterprise Application Integration. EAI-Systeme dienen dazu, systemübergreifende
Geschäftsprozesse so abzubilden, dass die am Geschäftsprozess beteiligten unterschiedlichen Systeme in der Lage
sind, prozessrelevante Daten miteinander auszutauschen und dabei ein gleiches Verständnis dieser Daten haben.
2
- 144 -
7.7 E-Service-Anwendungsarchitektur
Die Anwendungsarchitektur beschreibt den strukturellen softwaretechnischen Aufbau des Architekturmodells. In dieser Arbeit wird die Anwendungsarchitektur unter Nutzung von Komponenten
erstellt und daher auch als Komponentenarchitektur bezeichnet. Die Spezifikation einer Komponentenarchitektur definiert die Komponenten und ihre Funktionalität. Ferner umfasst sie die
Strukturierung der Komponenten mit allen zu integrierenden Systemen, deren Anbindung im
Mittelpunkt des vorangegangenen Kapitels 7.6 stand.
Bezüglich der Grundlagen zur Beschreibung von Komponenten wird auf das Kapitel 6.3 verwiesen.
Die Anwendungsarchitektur wird im RM-ODP-Modell dem Computational Viewpoint zugeordnet.
7.7.1
Bedeutung von Anwendungs- bzw. Komponentenarchitekturen
Je größer eine Anwendung ist, umso wichtiger ist ihre Anwendungs- bzw. Komponentenarchitektur. Ist die Aufteilung der Komponenten suboptimal gewählt, wird man für Erweiterungen
oder neue Anforderungen immer öfter auf Hilfskonstruktionen, sogenannte Workarounds, zurückgreifen müssen und die Erfahrung machen, dass simpel klingende Erweiterungen und Änderungen
aufgrund der gegenseitigen Abhängigkeiten immer schwieriger und nur mit wachsendem Zeitaufwand umzusetzen sind. Grundsätzlich gilt jedoch, dass eine Anwendungsarchitektur immer von
der zugrunde liegenden Anwendungsart abhängt. Es gibt demnach keine gute oder schlechte Anwendungsarchitektur, sondern nur bedarfs- oder nicht bedarfsgerechte Anwendungsarchitekturen.
Die Vorteile einer geeigneten Anwendungsarchitektur liegen in der Wiederverwendung von
Komponenten sowie in der Standardisierung von grundlegenden Architektur- und Designmustern.
Diese wirken sich vor allem bei mehrfacher Verwendung positiv aus. Eine Anwendungsarchitektur
sollte daher so flexibel sein, dass sie für viele Projekte anwendbar ist. Der Gestaltungsprozess ist
deshalb nicht nur vor dem Hintergrund eines Dienstes zu betrachten, sondern es sollten auch vergangene und zukünftige Projekte in die Überlegungen einfließen. Die Gestaltung einer Anwendungsarchitektur ist daher eine vielschichtige Aufgabe mit hoher Bedeutung und Tragweite.
Die Spezifikation einer Anwendungsarchitektur ist eng mit der verwendeten Internetservice-Plattform verknüpft. Deren Frameworks geben in der Regel die Softwaretechnologie, die SoftwareArchitektur, die Anwendungsarchitektur, die Entwicklungsumgebung und teilweise sogar die
Hardware vor. Unternehmen, die bereits eine Internetservice-Plattform haben, werden ihre Anwendungsarchitektur vor diesem Hintergrund entwickeln. Anderenfalls sollten zunächst unabhängig von konkreten Softwareprodukten die Bedarfe spezifizieren und anschließend gemäß
der Vorgehensweise in Kapitel 7.10 eine Internetservice-Plattform ausgewählt werden.
7.7.2
Verwendung abstrakter Komponenten
Abstrakte Komponenten sind Komponenten, deren Implementierung nicht näher spezifiziert beziehungsweise nicht bekannt ist. Abstrakte Komponenten verfügen analog zur Komponentendefinition über Schnittstellen für den Zugriff auf ihre Dienste, beschreiben die Dienste der
Komponenten und sind unabhängig vom spezifischen Kontext – also wiederverwendbar. Für die
Anwendungsarchitektur ist eine abstrakte Komponente die kleinste abgrenzbare Einheit. Im
Gegensatz zu konkreten Komponenten, die auf einen Komponententyp begrenzt sind, kann eine
abstrakte Komponente mehrere konkrete Komponenten umfassen. Konkrete Komponenten spielen
erst bei der Gestaltung des Komponentenkatalogs (siehe Kapitel 7.11) eine Rolle.
- 145 -
Die Verwendung abstrakter Komponenten ist vor allem dann von Vorteil, wenn eine Anwendungsarchitektur auch Teilfunktionen von Bestandssystemen umfasst. Eine systemorientierte Architekturgestaltung ist in einem solchen Fall nicht zielführend. Als Beispiel sei eine Benutzer- und
Rollenverwaltung genannt, die Bestandteil eines ERP-Systems ist und für die Authentifizierung benötigt wird. In diesem Fall genügt es, eine abstrakte Komponente und deren Schnittstellen zu
definieren. Detaillierte Kenntnisse über das Bestandssystem sind nicht erforderlich1.
7.7.3
Architektonische Prinzipien zur Spezifikation einer Komponentenarchitektur
Die Komponentenaufteilung erfolgt in Anlehnung an Kapitel 6.3.3 aus folgenden Motiven heraus:

Die entstehenden Komponenten sollen wiederverwendbar sein.

Die Komponenten sollen eine der Aufgabenstellung entsprechende Granularität haben.

Die Komponenten sollen über eindeutig definierte Schnittstellen verfügen.

Technische Entwurfsentscheidungen sollen in den Komponenten gekapselt werden.
Zur Erreichung dieser Ziele und zur Konzeption einer beherrschbaren und wirtschaftlichen Anwendungsarchitektur sind die in Tabelle 7-16 genannten architektonischen Prinzipien zu beachten.
Prinzip
Beschreibung
Serviceorientierung
Jede Komponente bietet fachlich orientierte Dienste über möglichst
standardisierte Schnittstellen nach außen an. Dabei werden nur sinnvolle
Zusammenhänge veröffentlicht. Die Granularität einer Komponente bestimmt, welche Methoden exportwürdig sind (siehe Kapitel 6.4.3 Serviceorientierte Architekturen).
Flexibilität
Flexible Integrationsarchitekturen unterstützen die Erweiterung der
Systeme (siehe Kapitel 7.6 E-Service-Integrationsarchitektur).
Lose Kopplung
der Komponenten
beziehungsweise
Services
Eine lose Kopplung verringert gegenseitige Abhängigkeiten der
Komponenten und unterstützt verteilte Betriebsszenarien. Ein stabiler Betrieb kann durch die asynchrone Kopplung der Systeme auch bei kurzzeitigen Netzwerkausfällen erreicht werden (siehe Kapitel 7.6.3
Integrationsmuster und Kapitel 7.12.1 Integrations- und Transaktionskomponenten).
Skalierbarkeit
Eine stabile Anwendungsarchitektur zeichnet sich durch Skalierbarkeit
aus. Die Anwendungsarchitektur sollte daher über einen mehrschichtigen
Aufbau verfügen, der eine Lastverteilung durch Verteilung der
Komponenten auf verschiedene Server unterstützt (siehe Kapitel 6.4.1
Mehrschicht-Architekturen).
Nutzung von
Standards
Durch die Unterstützung offener Standards werden eine breite Werkzeugunterstützung und ein maximaler Investitionsschutz sichergestellt. Internetbasierte Dienste sollten sich an den Internet- und Web-ServiceStandards (siehe Kapitel 6.5 Softwaretechnologien) orientieren.
Tabelle 7-16: Architektonische Prinzipien zur Gestaltung von E-Service-Anwendungsarchitekturen
1
Vgl. /Kram-2003/.
7.7.4
- 146 -
Vorgehensweise zur Spezifikation einer Komponentenarchitektur
Die Systemelemente sind jeweils hierarchisch in Hard- und Software zu gliedern. Beispielsweise
bilden Bestandssysteme, Datenbanken und Dienste sowie Systemelemente in Anlagen, wie z. B.
Sensoren, Aktoren, Bedienpulte etc., abstrakte zu kapselnde logische Komponenten. Falls möglich
ist das System so zu strukturieren, dass man eine 1:1-Abbildung des realen Systems erhält. Dies
schafft Übersichtlichkeit, Modularität und fördert die Wartbarkeit und Erweiterbarkeit.
Zur Spezifikation einer Komponentenarchitektur ist es darüber hinaus notwendig, die Komponenten zu verallgemeinern, um deren Wiederverwendbarkeitspotenzial zu steigern. Das Ziel ist die
Identifikation ähnlicher oder identischer Komponenten. Hierzu kann ein Business Object Model1
erstellt, untersucht und unter Anwendung von Entwurfsmustern transformiert werden, um ein
flexibleres und vielseitiger einsetzbares Modell zu erhalten.
Wie bereits in Kapitel 6.3 gezeigt, wird in der Softwareentwicklung schon immer auf die
strukturierte Gliederung von Anwendungen in Komponenten und Schichten geachtet. Diese
Strukturierung ist allerdings oft nicht nutzbar, da sie zwar innerhalb der Anwendung existiert, sich
jedoch nicht durch externe Anwendungen nutzen lässt. Demnach ist es sinnvoll, die Komponenten
in mehrere Schichten von Basis-Komponenten bis zu den geforderten fachlich motivierten
individuellen Komponenten zu strukturieren und deren Schnittstellen öffentlich bekannt zu machen.
Bei der Strukturierung müssen bei jeder Detaillierung zunächst die Anforderungen aus den übergeordneten Schichten übernommen, die Zerlegung entworfen, die Komponenten spezifiziert und
schließlich den Anforderungen der nächsten Ebene zugeordnet werden. Dabei kann Bottom-up, d.
h. von existierenden IT-Systemen oder -Komponenten, oder Top-Down, d. h. vom Geschäftsprozess zur Softwarekomponente, vorgegangen werden2. Für die Definition der Schichtung lassen
sich die folgenden Abstraktionskriterien heranziehen:

Funktionale Abhängigkeit: Eine funktionale Abhängigkeit zwischen den 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.

Abstraktionsniveau: Das Abstraktionsniveau wird auf Basis der in Kapitel 6.4.1 definierten
Schichten der Mehrschicht-Architektur hergeleitet. Dort werden die Client-, Präsentations-,
Mittel- und Persistenzschicht unterschieden.
1
2
Ein Business Object Model beschreibt die einer Anwendung zugrunde liegenden Klassen und Methoden.
Dieses Konzept basiert auf den Ideen des Systems Engineerings (s. Kapitel 4.3.2).
- 147 -
7.8 E-Service-Datenarchitektur
Die Datenarchitektur legt die Struktur und die Semantik der ausgetauschten Informationen fest. Die
E-Service-Datenarchitektur basiert auf der Prozess-, Integrations- und Anwendungsarchitektur.
Dort wurden die Quellen und Senken von Informationen sowie deren Transformation und Verarbeitung definiert. Die Datenarchitektur stellt lediglich die statischen Zusammenhänge zwischen
den abstrakten Komponenten des Architekturmodells her. Sie dient damit als Grundlage für die
dynamischen Zusammenhänge, die Gegenstand der Kommunikationsarchitektur im Kapitel 7.12
sind. Die Datenarchitektur wird im RM-ODP-Modell dem Information Viewpoint zugeordnet.
7.8.1
Standards für den Datenaustausch
Das Haupterfordernis des Datenaustauschs zwischen Komponenten beziehungsweise Diensten ist
die Definition eines gemeinsamen Datenformats1. In einem Datenformat wird spezifiziert, wie
Daten beim Laden und Speichern zu interpretieren sind. Ein Datenformat ist nicht zu verwechseln
mit dem Datenmodell einer Komponente das auch Schema2 genannt wird. Datenmodelle beschreiben die intern gespeicherten Daten, ihre Struktur und ihre Beziehungen innerhalb einer
Komponente.
Um den automatisierten Datenaustausch zu gewährleisten, hat sich der Einsatz des XMLStandards bewährt. XML ermöglicht die Definition universeller, plattformunabhängiger Datenformate, ist einfach zu handhaben und findet nicht zuletzt deshalb in Forschung und Industrie
breite Verwendung. Aufgrund dessen sollte XML als universeller und primärer Standard für den
Datenaustausch aller Informationssysteme dienen. Neu zu gestaltende oder zu beschaffende
Systeme sollten in der Lage sein, Daten über XML auszutauschen.
Die Verwendung von XML darf jedoch nicht zu dem Schluss führen, dass alle Dienste und
Applikationen zwangsläufig miteinander kompatibel und interoperabel sind. Wie schon bei zahlreichen früheren Gelegenheiten verkünden die Softwareanbieter die gegenseitige Interoperabilität,
um durch vermeintliche Herstellerunabhängigkeit Kunden zu binden. Tatsache bleibt, dass im Bereich der zugrunde liegenden Basisprotokolle und XML-Sprachen die Interoperabilität keinesfalls
garantiert ist3. Es gibt eine Vielzahl unterschiedlicher, anwendungsspezifischer XML-Standards.
1
2
3
Die Begriffe Datenformat und Dateiformat werden häufig synonym verwendet, obwohl dies nicht korrekt ist. Jedes
Dateiformat ist gleichzeitig auch ein Datenformat, aber nicht jedes Datenformat ist auch ein Dateiformat. So kann z.
B. ein Datenformat aus mehreren Dateien in unterschiedlichen Dateiformaten bestehen. Bekannte Dateiformate für
Dokumente sind z. B. PDF, HTML, RTF etc.
Bei Datenbanken spricht man auch vom Datenbankschema. Bei relationalen Datenbanken beschreibt das Datenbankschema die Tabellen und deren Attribute. Bei objektorientierten Datenbanken spricht man hingegen von
Objektmodellen. Objektmodelle beschreiben die Klassenstruktur sowie deren Funktionen und Relationen.
Zum Beispiel sind Web-Services, die in der Sprache C# unter Microsoft .NET entwickelt wurden, nicht kompatibel mit
Web-Services, die auf einer Sun ONE Plattform unter Java entwickelt wurden.
7.8.2
- 148 -
Interoperabilität von Anwendungen und Diensten
XML liefert eine wichtige technische Basis zur Erreichung des Wunsches nach Interoperabilität,
reicht aber nicht aus, um umfassende Interoperabilität zwischen Anwendungen zu gewährleisten.
Aufgrund der hohen Flexibilität von XML ist allein mit dieser Festlegung keine Vereinheitlichung erreicht. Hierfür ist es notwendig, Interoperabilität sowohl auf technischer, semantischer und
organisatorischer Ebene sicherzustellen (siehe Tabelle 7-17).
Merkmal
Beschreibung
Technische
Interoperabilität
Eine notwendige technische Voraussetzung zur Schaffung von Interoperabilität ist die gemeinsame Sprache für die Datenbeschreibung. Darüber hinaus
muss die Festlegung von Übertragungswegen und Protokollen erfolgen.
Semantische
Interoperabilität
Semantische Interoperabilität ist gegeben, wenn zwei Systeme Daten so austauschen, dass diese von beiden Kommunikationspartnern in gleicher Weise
interpretiert werden. Diese Form der Interoperabilität erreicht man durch die
Festlegung einer einheitlichen Semantik für die ausgetauschten Dateien.
Weiterhin müssen die Daten einheitlich interpretiert werden1.
Organisatorische
Interoperabilität
Die organisatorische Interoperabilität beschreibt den ablauforientierten und
somit nicht-technischen Prozess. Dabei ist festzulegen, in welchem Kontext
und für welchen Zweck Daten ausgetauscht werden sollen.
Tabelle 7-17: Merkmale zur Interoperabilität von Anwendungen, Komponenten und Diensten
Aufgrund der zunehmenden Vernetzung von Anwendungen wird die Sicherstellung der
semantischen Interoperabilität immer wichtiger – und zunehmend schwieriger. Neben der Anzahl
von Kommunikationspartnern steigt zugleich auch die Menge der auszutauschenden Daten.
7.8.3
Vorgehensweise zur Standardisierung von Datenmodellen
Die Struktur der internen Datenmodelle hat auf den ersten Blick keinen Einfluss auf die Interoperabilität, die zunächst auf den externen Datenformaten und Schnittstellen basiert. Bei näherer
Betrachtung muss man allerdings feststellen, dass die internen Datenmodelle sehr große Auswirkungen auf die Interoperabilität haben, da die in den Datenmodellen hinterlegte Intelligenz beim
Im- und/oder beim Export der Datenformate häufig verloren geht2.
Im Folgenden wird daher – in Anlehnung an OASIS, SAGA3 und eigene Erfahrungen – eine Vorgehensweise zur Standardisierung von fachübergreifenden Datenmodellen vorgeschlagen (Tabelle
7-18). Fachübergreifende Datenmodelle zeichnen sich dadurch aus, dass sie verschiedene
Zwecke erfüllen und in unterschiedlichen Einsatzbereichen und Systemen Anwendung finden4.
1
2
3
4
Beispielsweise muss bei einer Adressdatenbank Klarheit darüber herrschen, ob das Element „Vorname“ mehrere
Vornamen oder nur den Rufnamen beinhalten darf.
So verfügen beispielsweise viele CAD-Systeme über Import- oder sogar Nativschnittstellen, um Datenformate von
Wettbewerbsprodukten zu lesen. Beim Import der Daten treten jedoch immer Verluste auf, die sich beispielsweise in
Rundungsfehlern, Topologiefehlern, Verlust von intelligenten Designstrukturen etc. negativ bemerkbar machen. Bekannte Austauschformate, wie beispielsweise IGES, STEP etc., sind oft nur der kleinste gemeinsame Nenner.
Vgl. /KBSt-2006 (S. 53)/.
Im Unterschied zu fachübergreifenden Datenmodellen versteht man unter fachspezifischen Datenmodellen solche,
die einen starken Fachbezug haben und deren Wiederverwendung deshalb nur auf einen Einsatzbereich beschränkt
bleibt. Die Anforderungen an die Interoperabilität sind demnach bei fachspezifischen Datenmodellen geringer.
Schritt
Beschreibung
- 149 -
Nutzen
Sammlung
existierender
Datenmodelle
Zunächst wird mit der Sammlung bekannter Datenmodelle
begonnen. Die Softwareentwickler werden aufgefordert,
diese zu sammeln, zu dokumentieren und zu bewerten.
Ableitung des
Standardisierungsbedarfs
Validierung der
Datenmodelle
und Aufnahme in
einen Katalog
Die gesammelten Datenmodelle werden regelmäßig begutachtet und auf die Einhaltung festgelegter Qualitätskriterien geprüft. Datenmodelle, welche die Qualitätsanforderungen erfüllen, werden in einem Katalog von
qualitätsgesicherten Datenmodellen zusammengefasst.
Bevorzugte
Nutzung dieser
Datenmodelle,
sofern kein
Standard besteht.
Schaffung von
Standards und
Entwicklung von
Komponenten
In einem letzten Schritt wird ermittelt, wo Bedarf für ein
standardisiertes Datenmodell existiert. Dies wird immer
dort der Fall sein, wo mehrere geeignete Datenmodelle zu
einem Anwendungsbereich im Katalog verzeichnet sind.
Situationsabhängig wird entweder eines der bisher im
Katalog geführten Datenmodelle zum Standard erklärt
oder es wird ein neues Datenmodell entwickelt.
Die Standards
sollten vorrangig
eingesetzt
werden und sind
zur Wiederverwendung
empfohlen.
Tabelle 7-18: Vorgehensweise zur Standardisierung von Datenmodellen
Standardisierungsvorhaben in der Industrie haben allerdings gezeigt, dass der Versuch, eine vollständige Standardisierung von Datenmodellen durchzuführen, schwierig und meist zum Scheitern
verurteilt ist1. Viele Unternehmen versuchen, ihr eigenes Datenformat am Markt durchzusetzen.
Konkurrierende Datenformate werden lediglich teilweise unterstützt. Die Ursachen hierfür liegen in
der Komplexität der Datenmodelle, deren Entwicklungshistorie aber auch in taktischen Überlegungen. Man muss in der Regel davon ausgehen, dass selbst die Datenmodelle ähnlicher Anwendungen grundlegend verschieden sind und beim Import beziehungsweise Export immer Verluste auftreten2.
1
2
Die Standardisierung von Datenmodellen wird von verschiedenen Initiativen und Organisationen vorangetrieben. Die
UN/CEFACT und OASIS verfolgen im Rahmen der ebXML-Initiative das Ziel, einen technischen Rahmen zur
Nutzung von XML für elektronische Geschäftsprozesse zu erarbeiten. ebXML ist kein Standard, sondern eine Familie
unterschiedlicher Standards. Eine von der Organisation OASIS unterhaltene Webseite /OASI-2007c/ beschreibt ca.
500 unterschiedliche anwendungsspezifische XML-Standards. ebXML steht in Konkurrenz zu anderen XML basierten
Standards, wie z. B. RosettaNet. RosettaNet ist ein Konsortium, welches das Ziel verfolgt, branchenübergreifende
Kommunikations- und Ablaufverfahren zum Austausch von Geschäftsdokumenten zu unterstützen.
Der „Feldbus-Krieg“ führte zu 200 proprietären Protokollen; Inkompatibilität vieler Industrial Ethernet Protokolle; Inkompatibilität vieler CAD-Datenformate; inkompatible Datenmodelle der „Digitalen-Fabrik-Plattformen“ etc.
- 150 -
7.9 E-Service-Rollenmodell
Im Rollenmodell werden die Zugriffsrechte aller beteiligten Benutzergruppen beschrieben, deren
individuelle Sichten definiert sowie Freigaberegelungen erarbeitet. Das Rollenmodell gehört damit
im RM-ODP-Modell zum Enterprise Viewpoint. Die Ausgangsbasis für die E-Service-Rollenmodelle
wurde bereits in Kapitel 7.3.5 im Rahmen der Dienstleistungskonzeption gelegt. Die beteiligten
Rollen waren Gegenstand des Kapitels 7.3.3.2.
7.9.1
Verwaltung von Nutzern, Rechten und Rollen
Die Verwaltung individueller Nutzer umfasst das Anlegen, Speichern, Modifizieren und Löschen
der Nutzereinträge sowie deren Autorisierung1. Dabei wird in der Regel auf eine bereits vorhandene Nutzerverwaltung zurückgegriffen, in der den Nutzern bereits solche Rollen zugeordnet
sind (siehe Kapitel 7.6 E-Service-Integrationsarchitektur).
Die Vergabe von Zugriffsrechten erfolgt meist nicht auf der Ebene individueller Nutzer. Meistens
werden Rechte gruppiert und zu Rollen zusammengefasst. Hierfür ist festzulegen, wer die Rollen
verändern, wer Benutzerzuordnungen vornehmen sowie ändern und freigeben darf. Die physisch
realen Nutzer sind durch virtuelle User zu ergänzen, denn der physisch reale Nutzer eines Mehrwertdienstes ist nicht zwingend identisch mit dem User eines IT-Systems. Zum Zugriff auf untergeordnete Schichten oder Dienstkomponenten nutzt man aus Gründen der Sicherheit und
Wartbarkeit in der Regel virtuelle User. Der Rechteverwaltung dieser virtuellen User wird in der
Praxis häufig nicht genügend Beachtung geschenkt, was sich negativ auf die IT-Sicherheit auswirken kann.
7.9.2
Personalisierung und Individualisierung
Die Verwaltung von Nutzern und Rollen ist auch notwendig, um einzelnen Person oder einer
ganzen Nutzergruppe jeweils spezifische, dynamisch angepasste Inhalte anzubieten. Dabei unterscheidet man die Personalisierung von der Individualisierung.

Die Personalisierung umfasst dabei eine Anpassung der Inhalte an die Interessen und Bedürfnisse einer Personen- beziehungsweise Kundengruppe.

Die Individualisierung passt die Inhalte an die Interessen und Bedürfnisse einer einzelnen
Person beziehungsweise eines Kunden an.
Die Zielsetzungen der Personalisierung und Individualisierung lassen sich wie folgt gliedern:

Beschränkung des Dienstleistungsangebots entsprechend der Dienstverträge

Zielgruppenspezifische Darstellung von Informationen

Nutzer- und/oder rollenspezifischer Datenzugriff
Die Personalisierung und Individualisierung eines Mehrwertdienstes hat stets vor dem Hintergrund
eines individuellen Dienstes zu erfolgen. So ist es beispielsweise denkbar, nur authentifizierten
Nutzern mit der Rolle Projektleiter einen Zugriff auf Transaktionsdienste, wie z. B. Bestellungen, zu
ermöglichen. Die Erarbeitung eines Rollenmodells umfasst daher im Wesentlichen die korrekte
Zuordnung von Nutzern, Rechten, Rollen und Funktionen.
1
Während die Authentifizierung die Prüfung der Identität eines Benutzers klärt, ermittelt die Autorisierung die zur
Identität zugehörigen Berechtigungen.
- 151 -
7.10 Auswahl einer anforderungsgerechten Internetservice-Plattform
Wie bereits in Kapitel 2.3 aufgezeigt, ist die Bandbreite unterschiedlicher Mehrwertdienste groß.
Entsprechend vielfältig und heterogen sind die Anforderungen an Internetservice-Plattformen. Es
ist demnach nicht sinnvoll, eine für alle Mehrwertdienste gültige und nur auf einem Architekturparadigma basierende Internetservice-Plattform zu definieren. Im Folgenden wird ein Vorgehen zur
Auswahl einer anforderungsgerechten Internetservice-Plattform vorgestellt. Internetservice-Plattformen werden im RM-ODP-Modell dem Technology Viewpoint zugeordnet.
7.10.1 Bedeutung der Auswahl einer anforderungsgerechten Internetservice-Plattform
Die am Markt angebotenen Internetservice-Plattformen sind Frameworks, die oftmals auch Portalsoftware genannt werden1. Teilweise werden die Produkte auch Integrationsplattform, ServicePlattform, Web-Service-Plattform etc. genannt. Da Portalsoftware für völlig unterschiedliche Anwendungsfälle genutzt wird, nutzt diese Arbeit stattdessen den Begriff Internetservice-Plattform.
Internetservice-Plattformen schlagen die Brücke zwischen den fachspezifischen Anforderungen
des Service Engineerings und des Software Engineerings. Aus der Anforderungsdefinition beider
Seiten lässt sich ein anforderungsgerechtes Architekturparadigma ableiten. Während des Auswahlprozesses ist eine Vielzahl von Entscheidungen zu treffen. Die Ziele und Einflussgrößen sind
teilweise unscharf oder widersprechen sich. Die Entscheidungsfindung mündet daher häufig in
Zielkonflikten, die bewertet und abgewogen werden müssen. In der Regel basiert der Auswahlprozess einer anforderungsgerechten Internetservice-Plattform daher auf einem Kompromiss.
Bis vor wenigen Jahren war die verwendete Softwaretechnologie2 das ausschlaggebende
Kriterium zur Auswahl einer anforderungsgerechten Internetservice-Plattform. Inzwischen haben
viele Anbieter umfangreiche Plattformkonzepte entwickelt, die neben der reinen Softwaretechnologie auch integrierte Modellierungs-, Entwicklungs- und Ausführungsumgebungen sowie
Hardwaretechnologien bereitstellen. Diese Integration reduziert die Entwicklungszeit und erhöht
die Produktivität der Softwareentwicklung, da die Programmierer die Entwicklungsumgebung3 für
die Schritte Analyse, Entwurf, Implementierung und Test nicht mehr verlassen müssen. Zu den
Anbietern solcher Plattformen gehören unter anderem Sun und Microsoft (siehe Kapitel 6.5.2).
Zunehmend drängen Anbieter auf den Markt, die unter Nutzung oben genannter Softwaretechnologien eigene Produkte anbieten. Hierzu gehören unter anderem IBM WebSphere, Oracle
Portal, SAP Enterprise Portal. Einen aktuellen Marktüberblick geben die vierteljährlich erscheinenden Magic-Quadrant-Publikationen4 von Gartner, wie z. B. „Magic Quadrant for Horizontal
Portal Products“5, “Magic Quadrant for Enterprise Application Servers”6, „Magic Quadrant for
Application Platform Suites“, „Magic Quadrant for Web Services Platforms“7.
1
2
3
4
5
6
7
Die englische Bezeichnung für Portalsoftware lautet Corporate Portal Frameworks. Vgl. /Vlac-2005/.
Vgl. Kapitel 6.5.
Solche Systeme werden Integrated Development Environment genannt, engl. für integrierte Entwicklungsumgebung.
Der Magic Quadrant von Gartner, Inc. bewertet Anbieter in einem bestimmten Marktsegment einerseits nach ihrer
Vision sowie andererseits nach ihrer Fähigkeit, Visionen in die Tat umzusetzen.
Vgl. /Gart-2006/.
Vgl. /Gart-2005/.
Die Namensgebung bei Gartner orientiert sich am schnelllebigen, durch das Marketing getriebenen Zeitgeist. Es wird
daher empfohlen, nach den Begriffen „Application Integration“ oder „Middleware Software“ zu suchen.
- 152 -
Internetservice-Plattformen sind Frameworks, die eine Anwendungsarchitektur vorgeben. Deren
Verhalten wird durch die abstrakten und konkreten Klassen definiert, die entweder bereits vorhanden sind oder neu eingebracht werden. Der Erstellungsaufwand zur Umsetzung einer benötigten Funktionalität hängt dabei direkt von dem verwendeten Framework ab. Dies kann von
einer einfachen grafischen Konfiguration in der Benutzeroberfläche bis hin zur vollständigen
Implementierung einer Funktion reichen. Die Bandbreite der Schnittstellenfunktionalität einer Internetservice-Plattform reicht beispielsweise von einer einfachen Datenbankschnittstelle (z. B. Java
Database Connectivity – JDBC, Open Database Connectivity – ODBC) bis hin zu einer umfangreichen Enterprise-Application-Integration-Funktionalität (EAI) mit Schnittstellen zu den häufig verwendeten betrieblichen Informationssystemen (z. B. WebSphere SAP Adapter). Es ist demnach
wichtig, vor der Auswahl einer Internetservice-Plattform, Klarheit über die benötigte Integrationsarchitektur, Anwendungsarchitektur und Datenarchitektur zu haben. Ansonsten besteht die Gefahr,
dass aus Unkenntnis der genauen Anforderungen vermeintlich bessere oder kostengünstigere
Internetservice-Plattformen ausgewählt werden, die nicht über die benötigten Funktionalitäten verfügen. Die fehlenden Funktionen müssen gegebenenfalls selbst konzipiert, implementiert und getestet werden, was, ganzheitlich betrachtet, schlechter sein kann. Die Auswahl einer anforderungsgerechten Internetservice-Plattform hat demnach große Auswirkung auf den gesamten
Gestaltungsprozess.
7.10.2 Anforderungsermittlung
Eine Internetservice-Plattform muss den technischen Anforderungen der zu erbringenden Mehrwertdienste (siehe Tabelle 7-19) sowie den Rahmenbedingungen im Unternehmen (siehe Tabelle
7-20) gerecht werden. Bei der Anforderungsermittlung sollten daher möglichst mehrere internetbasierte Mehrwertdienste analysiert werden. Die Grundlagen zur Ermittlung dienstspezifischer Anforderungen wurden in den vorangestellten Kapiteln 7.3 bis 7.9 erarbeitet.
Technische
Anforderung
Bemerkung
Funktionale
Anforderungen
Funktionale Anforderungen haben den größten Einfluss auf die Auswahl einer
Internetservice-Plattform. So ist beispielsweise bei Diensten, die über hohe
Zugriffszahlen verfügen, die Verfügbarkeit von hoher Bedeutung, während
beim Umgang mit personenbezogenen Daten zunächst die Sicherheit im
Vordergrund steht.
Technologische
Anforderungen
Die Auswahl einer Internetservice-Plattform definiert auch die verwendete
Technologie zur Implementierung der Mehrwertdienste. Die in Kapitel 3.3 gestellten Anforderungen bzgl. Interoperabilität, Skalierbarkeit etc. lassen sich am
Besten durch den Einsatz offener Internetstandards und auf Basis nicht
proprietärer Programmiersprachen gewährleisten1.
Tabelle 7-19: Technische Anforderungen zur Auswahl einer anforderungsgerechten Internetservice-Plattform
1
Im Rahmen der dieser Arbeit zugrunde liegenden Gestaltung und Entwicklung von Mehrwertdiensten wurde hierfür
Java verwendet. Java bietet insbesondere vor dem Hintergrund der geforderten Plattformunabhängigkeit, der Unterstützung von objektorientierten Softwaretechniken, der Stabilität der Ausführungsumgebung und der großen Anzahl
der frei oder kommerziell verfügbaren APIs Vorteile. Die Orientierung auf eine Mittelschicht unter Verwendung von
Java bedeutet sinnvollerweise den Einsatz von J2EE. Damit enthält man ein detailliertes technisches Paradigma zur
Softwareentwicklung auf der Basis eines Application Frameworks.
Rahmenbedingung
- 153 -
Bemerkung
Technische
Rahmenbedingungen
Technische Rahmenbedingungen stellen einen wichtigen Einflussfaktor dar.
Sie haben einen projektübergreifenden Charakter und basieren auf strategischen Überlegungen eines Unternehmens. Hierzu gehören u. a. Vorgaben
für die Entwicklungsumgebung, Vorgaben für die Zielplattform etc.
Organisatorische Rahmenbedingungen
Organisatorische Bedingungen schränken ebenfalls die Menge möglicher
Alternativen bei Entscheidungen ein. Häufig werden Bewertungen durchgeführt, welche die politisch-strategischen Rahmenbedingungen des Einkaufs,
des Fachbereiches oder der IT nicht berücksichtigen.
Wirtschaftliche
Rahmenbedingungen
Im Rahmen der Investitionsplanung sollten alle erwarteten Kosten Berücksichtigung finden. Zu den Einmalausgaben gehören Implementierungskosten,
Hardwarekosten, Lizenzkosten etc. Die variablen Kosten umfassen Betriebsund Wartungskosten, regelmäßige Lizenzgebühren, gegebenenfalls zusätzliche Personal- und Ausbildungskosten.
Anbieterspezifische
Rahmenbedingungen
Zu den anbieterspezifischen Rahmenbedingungen1 gehören deren Marktstellung, Marktabdeckung, geografische Verteilung etc. Ebenso ist das verfügbare Personal im Hinblick auf Beratung, Service und Support zu berücksichtigen.
Tabelle 7-20: Rahmenbedingungen zur Auswahl einer anforderungsgerechten Internetservice-Plattform
In Tabelle 7-21 und Tabelle 7-22 sind die wichtigsten Diensteigenschaften den Anforderungskriterien gegenübergestellt. Ferner werden Hinweise gegeben, um den Anwender bei der Erstellung einer individuellen Anforderungsliste zu unterstützen. Die Aufzählung hat keinen Anspruch
auf Vollständigkeit, wenngleich sie sich in der Praxis bewährt hat.
Diensteigenschaft
Anforderungskriterium
Hinweis
Anwenderanzahl
Skalierbarkeit
Bei einer hohen Benutzeranzahl muss darauf geachtet
werden, dass die Hard- und Software-Architektur skalierbar ist.
Mehrschicht-Architekturen unterstützen dies z. B. durch
mehrere Applikations- und Datenbankserver (siehe Kapitel
6.4.1).
Unterstützung
unterschiedlicher Clients
Offenheit,
Flexibilität
Muss eine Vielzahl unterschiedlicher Clients unterstützt
werden, eignen sich Vierschicht-Architekturen, deren Mittelschicht eine Präsentationsschicht enthält, um den Besonderheiten verschiedener Clients gerecht zu werden (siehe Kapitel
6.4.1.3).
Tabelle 7-21: Checkliste mit Hinweisen zur Auswahl einer anforderungsgerechten Internetservice-Plattform (1. Teil)
1
In der Vergangenheit spielten Open Source-Produkte in der industriellen Nutzung eine eher untergeordnete Rolle.
Open Source-Produkte werden allerdings zunehmend interessanter und entwickeln sich zu einer Alternative gegenüber kommerziellen, lizenzpflichtigen Produkten.
Diensteigenschaft
Anforderungskriterium
- 154 -
Hinweis
Heterogenität
der Applikationslandschaft
Offenheit,
Interoperabilität
Ein Aspekt bei der Auswahl einer Internetservice-Plattform ist
der Integrationsbedarf in Bestandssysteme, die häufig über
heterogene Architekturen verfügen (siehe Kapitel 7.6).
Schutzbedarf
IT-Sicherheit,
Verfügbarkeit
Mehrschichtige Architekturen bieten gegenüber Architekturen
mit weniger Schichten grundsätzlich Vorteile, da zwischen den
Schichten technische Schutzmaßnahmen eingerichtet werden
können. Ferner können die Rechnersysteme in verschiedenen
Sicherheitszonen betrieben werden (siehe Kapitel 7.3.4).
Ausfallsicherheit
Verfügbarkeit
Durch Nutzung parallel betriebener Systeme lässt sich bei
einer Störung auf das andere System wechseln. Dies muss die
Anwendungsarchitektur unterstützen (siehe Kapitel 7.7).
Anpassbarkeit
der Architektur
Flexibilität,
Skalierbarkeit
Die Flexibilität einer Architektur zeigt sich in der Fähigkeit, bei
geänderten Anforderungen Änderungen schnell und kostengünstig vorzunehmen. Serviceorientierte Architekturen begünstigen dies, da ihre Services über definierte Schnittstellen
zur Verfügung gestellt werden (siehe Kapitel 6.4.3).
Standardisierung
Offenheit
Die Internetservice-Plattform sollte auf offenen Standards
basieren und möglichst viele Schnittstellen zur Nutzung oder
Bereitstellung von Services bereitstellen (siehe Kapitel 6.5).
Portabilität
Offenheit,
Flexibilität
Falls eine Anwendung auf unterschiedlichen Hardware-Plattformen und Betriebssystemen betrieben werden soll, muss
dies bei der Wahl der Programmiersprache berücksichtigt
werden (siehe Kapitel 6.5.2).
Personalqualifikation
Technologie,
Wiederverwendbarkeit
Die Qualifikation in und die Erfahrung der Softwareentwickler
mit einer Softwaretechnologie hat Auswirkungen auf den Entwicklungsaufwand. Falls die Entwickler mit einer Technologie
nicht vertraut sind, ist mit zeitlichem Mehraufwand zu rechnen.
Entwicklungsrisiko
Technologie
Ausgereifte Softwaretechnologien spiegeln sich in der Performance, der Robustheit und in der Beherrschbarkeit wider.
Für neue Technologien stehen u. U. weniger Softwareentwickler und Entwicklungswerkzeuge zur Verfügung.
Entwicklungsaufwand
Wartbarkeit
Die Unterteilung des Systems in Komponenten verringert zwar
die Komplexität, sie reduziert aber nicht zwangsläufig den
Entwicklungsaufwand. U. U. muss man sogar von höherem
Aufwand ausgehen, da eine sinnvolle Komponentenaufteilung
gefunden werden muss und die Komponenten so entworfen
werden sollten, dass sie wiederverwendbar sind.
Wirtschaftlichkeit
Kosten
Bei der Auswahl einer Internetservice-Plattform müssen die
Kosten des gesamten Lebenszyklus abgeschätzt werden.
Tabelle 7-22: Checkliste mit Hinweisen zur Auswahl einer anforderungsgerechten Internetservice-Plattform (2. Teil)
- 155 -
7.10.3 Gewichtung und Bewertung der Kriterien
Im Rahmen dieses Prozessschritts werden die erarbeiteten Kriterien aus der Anforderungsanalyse
entsprechend ihrer Wichtigkeit gewichtet und anschließend anhand anbieterspezifischer Internetservice-Plattformen bewertet. Dies kann z. B. mit der Methode des paarweisen Vergleichs
erfolgen. Diese Vorgehensweise liefert zunächst eine objektive Grundlage. Dabei sollte möglichst
frühzeitig untersucht werden, ob für Internetservice-Plattformen erstrangige Kriterien vorliegen, die
für sich bereits eine Entscheidung rechtfertigen. Die Prüfung erstrangiger Kriterien kann den Auswahl- und Entscheidungsprozess wesentlich beschleunigen. Falls keine erstrangigen Kriterien vorliegen, müssen alle anderen Kriterien analysiert und gewichtet werden. So schließt beispielsweise
die Anforderung nach Portabilität .NET- Lösungen aus, da Microsoft unter Plattformunabhängigkeit
nur die für verschiedene Windows-Varianten versteht (siehe Kapitel 6.5.2).
7.10.4 Technische Grobkonzeption
Ziel der technischen Grobkonzeption ist, ob, wie und mit welchem Aufwand sich die gestellten Anforderungen mit einer Internetservice-Plattform erfüllen lassen. Hierzu erfolgt die Erarbeitung der
Soll-Prozesse, Rechte- und Rollenmodelle etc. unter Nutzung der Software der vorab ausgewählten Anbieter. Die technische Grobkonzeption erfolgt in der Regel zusammen mit den Softwareanbietern und mündet häufig in einem Lastenheft. Das Lastenheft enthält neben den erarbeiteten Anforderungen auch wirtschaftliche, zeitliche und organisatorische Anforderungen und
dient später als Ausschreibungsunterlage und zur Bewertung der Anbieterangebote.
7.10.5 Entscheidung
In der Entscheidungsphase erfolgt die Festlegung auf eine Internetservice-Plattform. Solche Entscheidungen werden oft nicht ausschließlich auf Basis der oben beschriebenen methodischen
Analyse, Gewichtung und Bewertung abgeleitet, sondern die Produkte werden weiteren Untersuchungen unterzogen. Dies umfasst z. B.:

Demonstration der Softwarelösungen durch die Anbieter, gegebenenfalls mit unternehmensspezifischen Daten und Einstellungen.

Pilotierung einer Minimalimplementierung mit Prototypen mit anschließender Evaluation der
Resultate.
Nach der Anbieterwahl erfolgt die Erstellung eines Feinkonzepts evtl. auch unter Nutzung von
Ressourcen des Anbieters.
- 156 -
7.11 E-Service-Komponentenkatalog
Die komponentenbasierte Softwareentwicklung basiert auf der Grundidee, dass neue Anwendungssysteme beziehungsweise Dienste weitgehend durch Zusammensetzen von Softwarekomponenten erstellt werden. Ein Komponentenkatalog – auch Komponenten-Repository genannt
– ist eine Bibliothek von Softwarekomponenten, die diesen Prozess unterstützt. Die Bestandteile
eines Komponentenkatalogs können aus physisch vorhandenen Komponenten sowie aus Verweisen auf intern oder extern betriebene Services bestehen. Der Aufbau eines Komponentenkatalogs wird im RM-ODP-Modell dem Computational Viewpoint zugerechnet.
Käuflich erwerbbare beziehungsweise bereits vorhandene Softwarekomponenten decken entweder Standards ab oder wurden für spezifische Aufgabenstellungen entwickelt. Falls sich neue
Anforderungen nicht mit den vorhandenen Softwarekomponenten abbilden lassen, ist zunächst zu
prüfen, ob vorhandene Komponenten unter Beibehaltung der Schnittstellenspezifikation und der
bisherigen Funktion erweitert werden können. Falls dies nicht gelingt, sind neue Komponenten zu
entwickeln. Ein E-Service-Komponentenkatalog passt sich demnach fortwährend den neuen Anforderungen an.
7.11.1 Projektübergreifende Integrationsmuster
Die Entscheidung für eine komponentenbasierte Architektur sowie die Auswahl einer anforderungsgerechten Internetservice-Plattform sind wichtige Voraussetzungen, jedoch kein
Erfolgsgarant für gutes Dienstdesign. Allein die technischen Voraussetzungen zu erfüllen, liefert
keine Garantie für eine gute Wiederverwendbarkeit der Komponenten, da die Technik dem Softwareentwickler einen großen Gestaltungsspielraum lässt. Die Wiederverwendbarkeit muss genauso im Design und in der Implementierung der Komponenten berücksichtigt werden.
Designmuster und Richtlinien, im folgenden Integrationsmuster genannt, unterstützen die idealtypische Implementierung internetbasierter Dienstleistungen. Sie beschreiben, wie Komponenten
technisch in Online-Dienstleistungen eines bestimmten Typs eingebunden werden können. Durch
die Erstellung und Nutzung standardisierter und wiederverwendbarer Komponenten kann den Anforderungen nach Interoperabilität Rechnung getragen werden. Die Struktur eines Komponentenkatalogs und die Güte seiner Komponenten entscheiden darüber, ob dieser genutzt wird, und wie
letztendlich der Grad der Wiederverwendung ist.
7.11.2 Dilemma des Komponentenentwicklers
Der Softwareentwickler steht beim Aufbau eines Komponentenkatalogs vor folgendem Dilemma:
Die Kompontenfindung ist ein Teil des Entwicklungsprozesses eines spezifischen Softwaresystems. Dadurch wird jede Komponente primär auf das zu entwickelnde System zugeschnitten.
Dies kann die Allgemeingültigkeit und Wiederverwendbarkeit einschränken. Es muss also bereits
vorher über die weiteren Einsatzmöglichkeiten von Komponenten nachgedacht und deren Anforderungen und Schnittstellen abgeleitet werden. Weiterhin sind konfigurierbare Parameter festzulegen. Dies erfordert zusätzliche Zeit und Ressourcen. Beides ist jedoch in Projekten oft knapp.
Ein weiteres Problem bei der Entwicklung wiederverwendbarer Softwarekomponenten besteht in
der Unsicherheit der Investition. Damit sich eine Investition lohnt, muss eine Komponente genügend oft wiederverwendet werden, was zum Zeitpunkt ihrer Erstellung meist noch ungewiss ist.
- 157 -
Um sicherzustellen, dass die Komponenten wiederverwendet werden, müssen diese bzgl.
Funktion, Konfiguration, Dokumentation eine hohe Attraktivität bieten. Da die Nutznießer einer gut
spezifizierten und dokumentierten Komponente unter Umständen Dritte sind, sollten
organisatorische Regelungen getroffen werden, die den fairen Ausgleich zwischen Entwicklern und
Nutznießern sicherstellen.
Hinzu kommt, dass Softwarekomponenten häufig technologieabhängig sind. Es besteht die Gefahr, dass die von der Komponente verwendete Technologie schon veraltet ist, bevor die
Komponente oft genug wiederverwendet wurde. Es ist daher wichtig, bei der Wiederverwendbarkeit einer Softwarekomponente besonders auf die Technologie- und Plattformunabhängigkeit zu
achten.
7.11.3 E-Service-Komponenten zur Erbringung internetbasierter Mehrwertdienste
Im Rahmen des Projekts E-Industrial Services wurden die im Folgenden beschriebenen E-ServiceKomponenten identifiziert, spezifiziert und realisiert beziehungsweise zugekauft. Die Auswahl der
vorgestellten Komponenten hat somit keinen Anspruch auf Vollständigkeit, sondern beschreibt die
fachübergreifenden Komponenten, die zur Umsetzung der zwölf Mehrwertdienste1 notwendig
waren. Über die hier vorgestellten fachübergreifenden Komponenten hinaus wurden weitere fachspezifische Komponenten geschaffen. Deren Funktion erschließt sich allerdings nur im Kontext
spezifischer Dienste, weshalb hier auf eine Nennung verzichtet wird. Auf eine ausführliche Beschreibung der E-Service-Komponenten sowie deren Schnittstellen, Attribute und Methoden wird
ebenfalls verzichtet, da das Vorgehensmodell und nicht die Informationstechnik im Vordergrund
steht2.
7.11.3.1 Transportkomponenten
Aufgesetzt auf den Internetprotokollen werden in der Anwendungsschicht von TCP/IP die InternetBasisdienste3 bereitgestellt. Tabelle 7-23 zeigt diese Basisdienste, welche dem Datentransport
und der Kommunikation zwischen Komponenten dienen.
Dienst
Beschreibung
FTP
Das Standardprotokoll zur Dateiübertragung ist das File Transfer Protocol (FTP).
HTTP
Für die Kommunikation zwischen Client und Server kann das Hypertext Transfer
Protocol (HTTP) eingesetzt werden.
SMTP
Für den E-Mail-Transport wird das Simple Mail Transfer Protocol (SMTP) genutzt.
POP3/
IMAP
Das Post Office Protocol Version 3 (POP3) und das Internet Message Access
Protocol (IMAP) kommen beim Abrufen von E-Mails zum Einsatz.
Tabelle 7-23: Transportkomponenten beziehungsweise Internet-Basisdienste
1
2
3
Vgl./Grau-2001a (S. 26)/Dani-2003 (S. 27)/Dani-2005 (S. 44)/Sihn-2001b (S. 413)/Sihn-2001f (S. 1145)/Sihn-2003c
(S. 239)/Sihn-2003e (S. 579)/Löff-2001 (S. 87)/Berg-2003 (S. 209)/Blüm-2003 (S. 219)/Hell-2003 (S. 199)/Uhlm-2004
(S. 313)/Uhlm-2006 (S. 455)/.
Das in Publikationen häufig praktizierte Vorgehen, projektspezifische Gegebenheiten oberflächlich darzustellen, hat
nach Erkenntnis des Autors ohnehin nur einen begrenzten Nutzen. Es wird zwar ein Eindruck vermittelt, aber zur
Nutzung der Komponenten sind detaillierte Schnittstellenbeschreibungen auf Attributebene notwendig.
Auch Anwendungsprotokolle beziehungsweise Standarddienste genannt. Bei diesen Diensten handelt es sich streng
genommen nicht um Komponenten, sondern um genau spezifizierte Protokolle. Da jedoch zum Ausführen der
Protokolle Software notwendig ist, wird häufig der Begriff der Basiskomponente benutzt.
- 158 -
7.11.3.2 Speicherungskomponenten
Die Aufgabe von Speicherungsdiensten ist, anfallende Daten sicher und effizient persistent zu
machen. Persistenz bezeichnet dabei die Fähigkeit, Datenstrukturen oder Objekte in nichtflüchtigen Speichermedien zu speichern. Datenstrukturen oder Objekte, welche diese Fähigkeit
nicht besitzen, existieren nur im Hauptspeicher des Computers und gehen verloren, sobald das
Programm endet, von dem sie angelegt wurden.
Als Speicherungskomponenten kommen vor allem relationale Datenbanken und Dateisysteme
zum Einsatz. Objektorientierte Datenbanken werden selten verwendet.
7.11.3.3 Directory-Komponenten
Während Transport- und Speicherungskomponenten direkt Prozesse oder Teilprozesse von Anwendungen übernehmen, stellen Directory-Komponenten – auch Verzeichnisdienste genannt –
unterstützende Dienste zur Verfügung. Verzeichnisdienste dienen dazu, systemrelevante
Informationen, wie z. B. Angaben zu Benutzern, deren Rechte etc., zu verwalten (siehe Tabelle
7-24).
Dienst
Beschreibung
LDAP
Das Lightweighted Directory Access Protocol (LDAP) ist ein auf hierarchisch geordnete Informationen optimiertes Protokoll und wird für den Zugriff auf Verzeichnisdienste verwendet.
UDDI
Universal Description, Discovery and Integration (UDDI) ist eine XML-basierte
Technologie, um Web-Services zu publizieren, strukturiert zu verwalten und dem
Nutzer verfügbar zu machen (siehe Kapitel 6.5.4.4).
Tabelle 7-24: Verzeichnisdienste
7.11.3.4 Kooperationskomponenten
Kooperationskomponenten setzen sich aus Komponenten zur Informationsbereitstellung,
Kommunikation, Koordination und Kooperation zusammen und besitzen in der Anwendungsarchitektur eine höhere Ordnung als Basiskomponenten. Wie aus Abbildung 7-9 ersichtlich ist,
lassen sich die adressierten Bereiche nicht vollständig voneinander abgrenzen. So ist z. B. eine EMail zunächst ein Kommunikationsmittel. Wird diese E-Mail in Diskussionsforen veröffentlicht, so
erfüllt sie zugleich die Kriterien zur Informationsbereitstellung.
Eine besondere Bedeutung kommt bei Mehrwertdiensten der Informationsbereitstellung zu, wofür
sich offene Content-Management-Systeme1 bewährt haben. Ein Content-Management-System
dient zur Erstellung und Bearbeitung des Inhalts von Text- und Multimedia-Dokumenten sowie zur
Verwaltung von Websites. Der darzustellende Informationsgehalt wird als Content bezeichnet.
Content-Management-Systeme sollten die Trennung von Inhalt, Gestaltung und Funktion vornehmen können. Ein besonderer Wert wird deshalb auf eine medienneutrale Datenhaltung gelegt.
Darüber hinaus sollten Content-Management-Systeme über eine Programmierschnittstelle (API)
verfügen, die es ermöglicht, dynamisch generierte Inhalte zu integrieren. Eine Suchfunktion rundet
ein Content-Management-System ab und ist heute Standard bei vielen Systemen.
1
Content-Management-System, englisch für Inhaltsverwaltungssystem.
- 159 -
InternetTelefoniesystem
Koordination
Kommunikation
Kooperation
Chat
Videokonferenzsystem
WorkflowManagementWerkzeuge
E-Mail
Audiokonferenzsystem
Gruppeneditoren
Diskussionsgruppe
MonitoringSystem
Datenbank
Planungssysteme
FTP
Entscheidungsunterstützungssysteme
Informationsbereitstellung
Abbildung 7-9: Kooperationskomponenten 1
Alle Kooperationskomponenten verfügen über Mensch-Maschine-Schnittstellen, deren Gestaltung
zunehmend wichtiger wird. An der Mensch-Maschine-Schnittstelle treten große Teile der Gesamtfunktionalität eines Systems zutage. Damit ist die Mensch-Maschine-Schnittstelle bei den späteren
Anwendern ausschlaggebend für die Akzeptanz des Systems. Die Bandbreite möglicher MenschMaschine-Schnittstellen ist breit gefächert, wenngleich der konventionelle Bildschirm mit Tastatur
immer noch weit verbreitet ist. Bei der Mensch-Maschine-Schnittstelle ist ein Trend in Richtung
kleiner und mobiler Anwendungen zu beobachten2.
7.11.3.5 Workflow-Komponenten
Bei Workflow- bzw. Workflowmanagement-Komponenten handelt es sich um Softwaresysteme zur
visuellen Modellierung von Prozessen. Moderne Systeme unterstützen darüber hinaus die
Simulation, Steuerung und Ausführung von Prozessen. Die Grundlagen hierfür wurden bereits im
Kapitel 4.2 Beschreibungs- und Ausführungssprachen für die Prozessmodellierung behandelt.
Die Aufrufsequenzen werden hierzu in einem Process Model definiert. Dort ist hinterlegt, welcher
Dienst wann und von wem aufgerufen wird. Ein Dienst kann sowohl von einem anderen Dienst
aufgerufen als auch über einen Dialog von einem Anwender gestartet werden. Das Process Model
beschreibt dabei nicht nur die Aufrufreihenfolge der Dienste, sondern managt auch die Voraussetzungen und Aktivitäten, die auf die Aufrufe der Dienste zu folgen haben. Es ist wesentlich
besser und flexibler, Geschäftsregeln im Process Model zu verwalten, statt sie in den Diensten zu
belassen. Das Process Model bietet damit die Grundlage für die E-Service-Komposition und Konfiguration, die im Kapitel 7.13 näher behandelt wird.
1
2
Vgl. /Weis-2000 (S. 53)/.
Vgl. /Capg-2007 (S. 39)/Capg-2006 (S. 38)/Capg-2005 (S. 25)/Spat-2005a/.
- 160 -
7.11.3.6 Sicherheitskomponenten
Zum Schutz von IT-Systemen steht eine Reihe von technischen Sicherheitskomponenten1 zur Verfügung, die sich zusammen mit den wachsenden Bedrohungen2 ständig weiterentwickeln. Alle
Sicherheitsmechanismen basieren auf Sicherheitstechnologien, die in Tabelle 7-25 den jeweiligen
Anwendungsfällen zugeordnet sind.
Anwendungsfall
Information
Übertragung von Web-Inhalten
(Integrität und Vertraulichkeit)
SSL/TLS
Web-Server-Authentizität
SSL/TLS
Kommunikation
E-Mail-Kommunikation
ISIS-MTT
Dokumentenaustausch
(Integrität, Vertraulichkeit und
Authentizität)
XML-Signature
und -Encryption
sowie ISIS-MTT
Web-Services
Transaktion /
Integration
WS Security
Tabelle 7-25: Sicherheitstechnologien für verschiedene Anwendungsfälle
Das bekannteste kryptografische Protokoll ist SSL, das zum TLS-Protokoll weiterentwickelt wurde.
Es sichert die Integrität, Vertraulichkeit und Authentizität einer Kommunikationsverbindung. SSL
und TLS sichern die Kommunikationsprotokolle, wie z. B. HTTP, FTP, IIOP etc., ab.
Die ISIS-MTT-Spezifikation3 basiert auf den Grundfunktionen der elektronischen Signatur, Verschlüsselung und Authentifizierung. Die ISIS-MTT-Spezifikation definiert ein interoperables Datenaustauschformat für signierte und verschlüsselte Daten. Es berücksichtigt auch die Sicherung
binärer Daten, sodass beliebige Dateien als E-Mail-Anlagen gesichert übertragen werden können.
Die XML Signature4 ist ein internationaler Standard und beschreibt digitale Signaturen für beliebige
Daten, indem ein XML-Schema und ein Verarbeitungsregelwerk für die Generierung und
Validierung der Signatur bereitgestellt werden. Die XML Encryption5 ist ein internationaler
Standard, der ebenfalls ein XML-Schema und ein Verarbeitungsregelwerk für die Ver- und Entschlüsselung beliebiger Daten bereitstellt. Zusammen mit der XML Signature ist die XML
Encryption Grundlage mehrerer von der Industrie genutzter Standards für den sicheren
Dokumentenaustausch.
WS Security6 ist bislang lediglich ein OASIS-Standard für Web-Services. Er definiert Erweiterungen des SOAP-Protokolls, um Vertraulichkeit, Integrität und Verbindlichkeit der SOAPNachrichten bereitzustellen. Die Relevanz ist derzeit noch nicht vollständig abschätzbar.
1
2
3
4
5
6
Die folgende Aufzählung listet einige technische Sicherheitsmechanismen auf: Virenschutzprogramm, Firewall, User
Authentifikation, Message Authentifikation, Client Authentifikation, Digitale Zertifikate, Digitale Unterschriften, Public
Key Infrastructure, Zertifizierungsstellen, Intrusion Detection, Security Scanner, Code Signing, Secure VPNs etc.
Das Vorgehen zur Schutzbedarfsfeststellung erfolgte bereits im Kapitel 7.3.4.
Vgl. </http://www.isis-mtt.org/>, letzter Abruf am: 01.05.2008.
Vgl. </http://www.w3.org/TR/xmldsig-core/>, letzter Abruf am: 01.05.2008.
Vgl. </http://www.w3.org/TR/xmlenc-core/>, letzter Abruf am: 01.05.2008.
Vgl. </http://www.oasis-open.org/specs/index.php#wssv1.1/>, letzter Abruf am: 01.05.2008.
und </http://www.oasis-open.org/specs/index.php#wssprofilesv1.0/>, letzter Abruf am: 01.05.2008.
- 161 -
7.11.3.7 Anwendungskomponenten
Anwendungskomponenten sind spezifisch auf die einzelnen Anwendungsgebiete ausgerichtet und
in der Mittelschicht für die Anwendungslogik eines Dienstes zuständig. Die Anzahl möglicher Anwendungskomponenten ist – entsprechend der vielen Anwendungsmöglichkeiten – vielfältig.
Tabelle 7-26 zeigt einen Ausschnitt möglicher Anwendungskomponenten auf.
Anwendungskomponente
Beschreibung
Messen
Ermittlung von Kennwerten, z. B. Temperatur, Druck etc.
Steuern
Stellen, Bewegen, Schalten etc. von Aktoren
Regeln
Regelung eines Antriebs oder sonstiger Aktoren
Bewerten
Einschätzung des Wertes oder der Bedeutung eines Sachverhaltes oder
Gegenstandes
Optimieren
Bestimmung optimaler zulässiger Einstellungen eines Optimierungsproblems
hinsichtlich einer gegebenen Zielfunktion
Prognostizieren
Datenmaterial, auf dessen Grundlage mit einer bestimmten Wahrscheinlichkeit
Voraussagen gemacht und Entscheidungen getroffen werden können.
Tabelle 7-26: Anwendungskomponenten
7.11.4 E-Service-Komponenten zur Verwaltung internetbasierter Mehrwertdienste
Zur Administration von Internetservice-Plattformen werden Verwaltungskomponenten für die
Konfiguration, Überwachung, Abrechnung und Wartung benötigt. Die Anforderungen gehen weit
über die oft zitierte „Benutzer- und Rechteverwaltung“ hinaus. Auch kommerzielle InternetservicePlattformen decken oft nur Teilaspekte der benötigten Funktionalität ab (siehe Tabelle 7-27).
Verwaltungskomponente
- 162 -
Kurzbeschreibung der Merkmale
Benutzerverwaltung
Die Benutzerverwaltung organisiert und verwaltet die Anwender, Identitäten,
Rollen, Profile, Zugriffsrechte etc. und stellt damit einen zentralen Baustein
einer Internetservice-Plattform dar. Dabei ist es sinnvoll, zwischen Anwendern und Kunden zu unterscheiden. Während der Vertrag zur Nutzung
einer Dienstleistung in der Regel mit einem Unternehmen (Kunde) abgeschlossen wird, nutzen die Mitarbeiter des Unternehmens (Anwender) die
Dienste. Aus diesem Grund ist die Benutzerverwaltung mit abgestuften
Rechten für den Administrator des Plattformbetreibers, den Administrator des
Kunden und für die Selbstadministration des Anwenders zu gestalten.
Vertragsverwaltung
Die Vertragsverwaltung managt die Verträge, die zwischen dem Plattformbetreiber und den Kunden geschlossen werden. Bei der Anlage eines Dienstnutzungsvertrags für einen Kunden ist unter Umständen festzulegen, wie
viele Anwender den Dienst maximal nutzen dürfen, wie oft der Dienst in Anspruch genommen werden darf, über welchen Zeitraum die Nutzung gestattet
ist etc. Zusätzliche Einschränkungen, z. B. Obergrenzen für übertragene oder
gespeicherte Datenmengen, sollten optional möglich sein1.
Dienstadministration
Die Dienstadministration beschreibt Funktionen zur Administration in der
Domäne des Plattformbetreibers. Dies umfasst Funktionen zur Inbetriebnahme, Wartung oder Löschung von Diensten. Ferner müssen
implementierte Dienste (neu)gestartet beziehungsweise gestoppt werden
können.
Authentifizierung
Alle nicht öffentlich verfügbaren Dienste erfordern eine Benutzerauthentifizierung. Neben der heute üblichen Authentifizierung mit BenutzernamePasswort-Kombination gewinnen Verfahren auf der Grundlage von Smartcards und biometrischen Informationen an Bedeutung. Single Sign-On2 ist bei
vielen Systemen heute bereits Standard.
Monitoring und
Reporting
Überwachungssysteme können die Systemverfügbarkeit erhöhen. Dabei wird
das Ziel verfolgt, möglichst umfassende Informationen über das Verhalten
einzelner Komponenten und Systeme zentral zugänglich zu machen. Neben
einer effizienten Identifikation von Fehlerquellen unterstützt eine MonitoringFunktionalität die Optimierung der Komponenten und Prozesse3.
Logging
Das Logging dient dem Nachweis der Dienstnutzung. Aus Datenschutzgründen sind unterschiedliche Sichten für Anwender, Kunde und Dienstleister
vorzusehen.
Abrechnung
Die Daten, die beim Logging anfallen, bilden die Grundlage für die
Rechnungserstellung. Dabei muss transparent sein, welche Leistungen in
Anspruch genommen wurden und welche Kosten dadurch entstanden sind.
Tabelle 7-27: Administrationskomponenten
1
2
3
Vgl. /Baue-2001 (S. 147)/Quan-2003 (S. 60)/.
Single Sign-On (englisch sinngemäß mit Einmalanmeldung übersetzt) bedeutet, dass ein Anwender nach einer einmaligen Authentifizierung auf alle Dienste zugreifen kann, ohne sich erneut anmelden zu müssen.
Vgl. /Quan-2003 (S. 53)/.
- 163 -
7.11.5 Spezifikation konkreter Softwarekomponenten
Das in Abbildung 7-10 dargestellte Vorgehen zur Spezifikation konkreter Softwarekomponenten
wurde aus verschiedenen Quellen abgeleitet und wird in den folgenden Unterkapiteln näher erläutert. Zum einen orientiert sich der Prozess am Rational Unified Process (siehe Kapitel 4.5.5),
zum anderen an einem speziell für die Komponentenerstellung entwickelten Prozess1.
Abbildung 7-10: Vorgehensweise zur Spezifikation neuer Softwarekomponenten
1
Vgl. /Chee-2001/Kram-2003/.
- 164 -
7.11.5.1 Notwendige Vorarbeiten
Die Spezifikation konkreter Softwarekomponenten ist beim erstmaligen Durchlaufen des
Vorgehensmodells ein Teil des Gesamtprozesses. Der häufigere Fall ist allerdings der, dass im
Rahmen neuer Anforderungen, bei Änderungen oder zur Schaffung neuer Funktionalität einzelne
Komponenten neu gestaltet werden. Dieses Unterkapitel behandelt diesen Fall und vereinfacht
den Quereinstieg durch Referenzierung auf vorangestellte Kapitel. Für diejenigen, die das
Vorgehensmodell im Ganzen durchlaufen, stellt dieses Kapitel eine Zusammenfassung vorangegangener Kapitel dar.

Die Spezifikation von Softwarekomponenten basiert auf spezifischen Dienstleistungsideen und
entsprechenden Anforderungen, die im Kapitel 7.3 E-Service-Design erarbeitet wurden. Um
die Softwarekomponenten und deren Schnittstellen zu entwerfen, sind zunächst die notwendigen Funktionen zu analysieren. Funktionen können von Benutzerschnittstellen, aber
auch von anderen Softwarekomponenten genutzt werden.

Bereits in Kapitel 7.4 E-Service-Infrastruktur wurden die infrastrukturellen Voraussetzungen
für den Betrieb von Mehrwertdiensten behandelt.

Die Gestaltung der E-Service-Prozessarchitektur dient dazu, gemeinsame Merkmale der
Prozesse zu identifizieren und zusammenzuführen. Dabei wird das Ziel verfolgt dienstunabhängige Prozessteilmodelle zu erstellen (siehe Kapitel 7.5).

Die in Kapitel 7.6 behandelte E-Service-Integrationsarchitektur beschreibt, wie Bestandssysteme einzubinden sind.

Die Spezifikation der Komponentenarchitektur bündelt die Prozesse in abstrakte
Komponenten und definiert damit ihre Funktionalität (siehe Kapitel 7.7).

Die anschließend zu erstellende E-Service-Datenarchitektur (siehe Kapitel 7.8) legt dann die
Struktur und die Semantik der ausgetauschten Informationen fest.
7.11.5.2 Entwurf konkreter Softwarekomponenten
Nach dem zuvor die Auswahl einer Internetservice-Plattform erfolgte, steht die zu verwendende
Technologie und das Framework fest. Damit ist definiert, über welche Funktionalität und
Komponenten die Internetservice-Plattform verfügt, beziehungsweise was manuell zu implementieren ist. Damit sind die Ausgangsvoraussetzungen geschaffen, um die in Kapitel 7.7 definierten
abstrakten Komponenten in konkrete Komponenten zu transformieren.
Hierzu sind zunächst die Kernklassen einer abstrakten Komponente zu identifizieren. Kernklassen
sind Klassen, die im Business Object Model unabhängige Einheiten bilden, die nur von klassifizierenden oder näher bestimmenden Klassen abhängen. Die Rollen und Unterklassen sind dabei
nur näher bestimmend. Nachdem die Kernklassen identifiziert wurden, sind die Verantwortlichkeiten zu bestimmen. Jede Nicht-Kernklasse muss einer verantwortlichen Kernklasse zugeordnet
sein. Für die Rollen der Unterklassen ist diese Zuordnung trivial. Komponenten können aus drei
verschiedenen Arten von Klassen bestehen1:

Zum einen gibt es Klassen, die Daten speichern und verwalten. Diese entstehen aus den
Geschäftsklassen, indem deren Attribute kopiert werden und durch Operationen zur Erstellung,
Auffindung und Löschung ergänzt werden. Weiterhin werden Verantwortlichkeiten, die bei der
1
Um Use Cases zu erstellen, zu verfeinern und daraus die Verantwortlichkeiten einzelner Klassen abzuleiten, eignet
sich ein Vorgehen gemäß des Rational Unified Process. Vgl. Kapitel 4.5.5.
- 165 -
Verfeinerung der Use Cases gefunden wurden, als Operationen entworfen. Schließlich werden
noch Operationen zum Zugriff auf die Attribute benötigt, sofern die verwendete Entwicklungsumgebung diese nicht automatisch generiert.

Die zweite Art von Klassen implementiert die Logik der Komponenten und realisiert damit
die im vorigen Abschnitt identifizierten Schnittstellen und deren Operationen. Es kann hierbei
pro Komponente eine solche Klasse geben, die alle Schnittstellen der Komponente
implementiert oder mehrere Klassen, die jeweils einen Teil der Schnittstellen implementieren.
Generell muss in jeder Komponente jede für sie spezifizierte Schnittstelle genau einmal
implementiert werden. Es kann notwendig sein, für die Kommunikation zwischen mehreren
Klassen weitere Operationen zu entwerfen.

Die Klassen der dritten Art sind Hilfs- und Ressourcenklassen. Diese enthalten gemeinsam
genutzte Methoden und erlauben den Zugriff auf Konfigurationsparameter der Komponente.
Dafür sind jeweils Attribute und Zugriffsoperationen in dieser Klasse vorzusehen.
Je nach Granularität einer Komponente kann es sein, dass diese lediglich über Klassen zur
Implementierung der Logik verfügt. Insbesondere triviale Komponenten benötigen keine Datenklassen.
Mit den spezifizierten Schnittstellen sowie den durch Interaktionsdiagramme verfeinerten Use
Cases und den daraus abgeleiteten Klassen und Verantwortlichkeiten werden nun die Komponenten möglichst plattformunabhängig entworfen. Dieser Schritt ist, wie die vorangegangenen
Schritte auch, noch weitgehend technologie- und plattformunabhängig. Es werden plattformunabhängige Modelle (PIM) im Sinn der modellgetriebenen Architektur (MDA) erstellt (siehe Kapitel
6.3.5).
Beim Entwurf von Komponenten ist möglichst darauf zu achten, dass sie in dem Maße erweiterbar
sind, dass sie beim Auftreten von neuen Anforderungen oder bei der Einbindung in andere ITSysteme wiederverwendet werden können. Gerade durch die Eigenschaft von Komponenten, verschiedene Schnittstellen anbieten zu können und konfigurierbar zu sein, ist es möglich, eine
Komponente stets weiterzuentwickeln und trotzdem kompatibel zu früheren Versionen zu bleiben.
7.11.6 Implementierung, Test und Dokumentation von Softwarekomponenten
Die Implementierung neuer Komponenten setzt voraus, dass vorher spezifiziert wurde, wie die
Kommunikation zwischen den Komponenten stattfinden soll. Die grundsätzlichen Entscheidungen
sollten bereits im Rahmen der E-Service-Integrationsarchitektur (siehe Kapitel 7.6) und bei der
Definition von projektübergreifenden Integrationsmustern (siehe Kapitel 7.11.1) getroffen worden
sein. Eine finale Klärung der E-Service-Kommunikationsarchitektur erfolgt erst im Kapitel 7.12.
Dies ist kein Widerspruch, sondern zeigt, dass das Vorgehensmodell in Zyklen zu betrachten ist.
7.11.6.1 Implementierung neuer Softwarekomponenten
Im Rahmen der Implementierung erfolgt die Umsetzung des Entwurfs in eine ausführbare Softwarekomponente. Sind die Komponenten nach der bisher beschriebenen MDA-Methodik entworfen, so kann die Transformation des Modells auf die Zielplattform stattfinden, d. h., es erfolgt
der plattformabhängige Entwurf. Wie bereits im Kapitel 6.3.5 beschrieben, sind die heutigen Werkzeuge der modellgetriebenen Architektur noch nicht vollständig ausgereift. Die Transformation des
Modells auf die Zielplattform bleibt mit manuellem Aufwand verbunden. Man geht jedoch davon
aus, dass sich dies zukünftig vollständig automatisieren lässt.
- 166 -
Die Implementierung neuer Softwarekomponenten wird heute in der Praxis oftmals in zwei
Iterationen erstellt. Zunächst werden ablauffähige Softwarekomponenten entwickelt, welche die
Schnittstellen unterstützen. Anschließend werden die Softwarekomponenten inhaltlich erweitert.
Dies ermöglicht eine bessere Parallelisierbarkeit der Entwicklungsarbeiten und reduziert das Risiko
durch die frühe Bereitstellung von Prototypen (siehe Kapitel 4.5.7).
7.11.6.2 Test der Softwarekomponenten
Der sich an die Implementierung anschließende Test erfolgt in zwei Stufen. Da eine Komponente
unabhängig von anderen Komponenten entwickelt wird, muss sie auch unabhängig zu testen sein.
Um dies zu erreichen, sollte im Entwurf ein zusätzlicher Komponentenparameter berücksichtigt
werden. Mit diesem lässt sich die Softwarekomponente für einen Modultest so konfigurieren, dass
sie keine weiteren externen Komponenten aufruft, die gegebenenfalls noch nicht vorhanden sind.
Der Modultest erfolgt demnach zunächst als Black-Box-Test gegen die Schnittstellenspezifikation.
Ergebnisse, die von anderen Softwarekomponenten abhängen, sind im Testmodus entweder zu
simulieren oder zu ignorieren. Weitere Tests sollten dann als White-Box-Test, also unter Einbeziehung der inneren Funktionsweise der zu testenden Softwarekomponenten, erfolgen.
7.11.6.3 Dokumentation und Katalogisierung im Komponentenkatalog
Die Dokumentation von Softwarekomponenten unterscheidet sich von einer konventionellen
Dokumentation von Softwareanwendungen. Dies rührt vor allem von den unterschiedlichen Zielgruppen her. Bei der konventionellen Softwareentwicklung sind die Leser einer Dokumentation die
Anwender eines Systems. Bei Komponenten sind die Leser die Softwareentwickler. Darüber
hinaus muss zwischen offenen und geschlossenen Systemen unterschieden werden:

Offene Systeme sind Systeme, bei denen die Implementierung und der Entwurf der
Komponenten nach außen hin sichtbar sein dürfen. Offene Systeme sind beispielsweise bei
Open-Source-Software anzutreffen.

Geschlossene Systeme sind schwieriger zu dokumentieren. Organisationen, die
Komponenten anbieten möchten, ohne die Implementierung offen zu legen, müssen bei der
Dokumentation für die Entwickler sehr sorgfältig vorgehen. Auf der einen Seite muss die
Dokumentation genügend Informationen bereitstellen, um die korrekte Zusammenarbeit der
Komponente mit der Umgebung und mit anderen Komponenten zu gewährleisten. Das bedeutet, dass alle Schnittstellen und Seiteneffekte detailliert und genau sowohl syntaktisch als
auch semantisch dokumentiert sein müssen. Andererseits darf die Dokumentation nicht zu viel
über die Realisierung der Komponente aussagen. Es besteht sonst die Gefahr, dass die angebotene Komponente durch eine Eigenentwicklung substituiert wird.
Die Dokumentation einer Komponente muss in beiden Fällen auf die Schnittstellenspezifikationen
der verwendeten Schnittstellen verweisen sowie die Konfigurationsparameter dokumentieren. Zur
Dokumentation gehört auch die Katalogisierung der Komponenten im Komponentenkatalog.
7.12 E-Service-Kommunikationsarchitektur
Eine Kommunikationsarchitektur beschreibt die dynamische Kommunikation zwischen den
Komponenten. Sie ergänzt damit die im Kapitel 7.8 definierte E-Service-Datenarchitektur, deren
Zweck die Darstellung der statischen Datenzusammenhänge zwischen den Komponenten ist. Die
E-Service-Kommunikationsarchitektur wird im RM-ODP-Modell dem Information Viewpoint zugeordnet. Die im Rahmen der Gestaltung der Kommunikationsarchitektur definierten Integrationsund Transaktionskomponenten werden in den E-Service-Komponentenkatalog aufgenommen.
- 167 -
7.12.1 Integrations- und Transaktionskomponenten
Bei der Konzeption von Integrations- und Transaktionskomponenten ist zu entscheiden, wie die
Kommunikation zwischen den Systemen und Komponenten zu erfolgen hat. Die Bandbreite der
Schnittstellenfunktionalität reicht von einfachen Datenbankzugriffen bis zu umfangreichen
Message-Broker-Systemen. Neben der Integrationsmöglichkeit muss in vielen Fällen auch die
Transaktionssicherheit gegeben sein. Tabelle 7-28 listet verschiedene Möglichkeiten zur Umsetzung von Integrationsmustern auf.
Integrationsmöglichkeit
Beschreibung und typische Vertreter
Datenaustausch
über persistenten
Speicher
Der Datenaustausch erfolgt durch einen Dokumentenaustausch. Dies erfordert
eine exportierende Komponente, die ein Dokument ablegt, einen persistenten
Speicher und eine importierende Komponente. Der Austausch erfordert ein
Wissen über den Austauschzeitpunkt oder eine Benachrichtigungsfunktion.
Beispiele: XML, CSV-ASCII Textdatei
Integration über
DBMS
Die Integration erfolgt durch die Verwendung einer Datenbank. Der Zugriff wird
über eine Datenbankschnittstelle realisiert. Beispiele: Java Database Connectivity (JDBC), Open Database Connectivity (ODBC)
HTTP Get-/PostMethode
Die HTTP Get-/Post-Methode nutzt die Mechanismen des HTTP-Protokolls.
Dabei tritt eine Komponente als HTTP-Server auf, die andere Komponente als
HTTP-Client. Datentransfers können entsprechend des Client/Server-Schemas
ausschließlich von dem Client initiiert werden. Beispiele: HTTP 1.0 / HTTP 1.1
Synchrone
Middleware
Die Integration über eine synchrone Middleware erfolgt über den direkten
Funktionsaufruf und ist für Komponenten geeignet, die sich auf dem gleichen
System befinden. Die Technologien sind prozedural (Remote Procedure Call,
RPC) oder objektorientiert (Remote Object) (siehe Kapitel 6.5.3). Beispiele:
Java-RMI, CORBA, Web-Services
Asynchrone
Middleware
Die Integration über asynchrone Middleware basiert auf dem Austausch von
Nachrichten, die über Warteschlangen ausgeliefert werden (Message Oriented
Middleware, MOM). MOM ist als eine Erweiterung von RPC zu sehen, die eine
asynchrone Verarbeitung der Nachrichten erlaubt. Damit wird ein nicht blockierendes Verhalten der zu koppelnden Komponenten ermöglicht. Beispiele:
IBM WebSphere MQ, Microsoft MSMQ, TIBCO Enterprise Message Service
Message
Broker1
Message Broker setzen auf der asynchronen Middleware auf und tauschen
ebenfalls Nachrichten aus. Im Unterschied zur asynchronen Middleware besitzen sie allerdings die Möglichkeit, Nachrichten zu verändern und Regeln bei
der Verarbeitung beziehungsweise in Bezug auf die Weiterleitung anzuwenden. Beispiel: Microsoft BizTalk Server
Tabelle 7-28: Integrationskomponenten
1
Vgl. Technisch gesehen basieren Business Process Management Systeme (BPMS) meist auf einer nachrichtenorientierten Middleware. Die Service-Integration unter Nutzung von BPMS gilt als die nächste Evolutionsstufe. Sie
nutzt alle Vorteile der asynchronen Kommunikation; die Integration ist aber weniger technisch, sondern eher
prozessorientiert. Hierdurch wird die Serviceintegration auf ein fachliches Niveau transferiert.
- 168 -
7.12.2 Bewertung der Einsatzmöglichkeit im Architekturmodell
Die vorgestellten Integrations- und Transaktionskomponenten eignen sich in verschiedenem Maße
für die Kommunikation zwischen den Komponenten. Eine Bewertung kann demnach nur auf Basis
spezifischer Dienste erfolgen. Tabelle 7-29 zeigt grundsätzliche Vor- und Nachteile der unterschiedlichen Integrationskomponenten auf. Neben u. g. technischen Faktoren spielt unter anderem
der Erfahrungsschatz der Beteiligten sowie Lizenzkosten für Softwareprodukte eine Rolle.
Integrationsmöglichkeit
Positiv
Datenaustausch Austausch großer Datenmengen
über persistenten
und Dokumente
Speicher
Einfachheit der Anbindung
kostengünstig
Negativ
Neue Daten stehen nur zu
definierten Zeitpunkten zur Verfügung bzw. Benachrichtigung erforderlich.
paralleler Zugriff nicht möglich
Integration
über DBMS
enge Integration der Komponenten
Datenbankschema entspricht der
Schnittstelle
Eignung für große Datenmengen mit
hoher Änderungshäufigkeit
HTTP Get-/PostMethode
Synchrone
Middleware
Integration grafischer Komponenten
Einfachheit der Anbindung
gemeinsamer Zugriff auf ein DBMS
möglich
gegenseitige Benachrichtigung erforderlich
Lizenzkosten
aufwendige Anpassung bei unterschiedlichen GUIs erforderlich
kostengünstig
fehlende Stabilität gegenüber
Änderungen an der Darstellung der
integrierten Komponente
hoher Wiederverwendungsgrad bestehender Schnittstellen
geringe Eignung für große Datenmengen
geringe Fehlertoleranz
Lizenzkosten
Asynchrone
Middleware
Verteilungstransparenz für die involvierten Komponenten
Möglichkeit zur Lastbalancierung
Anpassungen der Datenformate
zwischen Komponenten auf verschiedenen Plattformen möglich
geringe Eignung für große Datenmengen und Übertragung von
Dokumenten
Lizenzkosten
Fehlertoleranz im Fall der Nichtverfügbarkeit des LANs oder WANs
Message
Broker
hoher Wiederverwendungsgrad
bestehender Broker-Schnittstellen
Verteilungstransparenz für die involvierten Komponenten, Möglichkeit zur Lastbalancierung
Anpassungen auf Datenebene
zwischen Komponenten möglich
Tabelle 7-29: Bewertung der Einsatzmöglichkeit im Architekturmodell
geringe Eignung für kleine ITUmgebungen mit geringem Wiederverwendungsgrad der Schnittstellen
Lizenzkosten
- 169 -
7.13 E-Service-Komposition und -Konfiguration
Die Komposition und Konfiguration behandeln die operative Umsetzung der Konzepte, die ab
Kapitel 7.4 beschrieben sind. Bei der Komposition werden Elemente des E-Service-Komponentenkatalogs ausgewählt, in das entsprechende Framework eingesetzt und eine ablauffähige
Applikation erstellt. Im Rahmen der Konfiguration erfolgt die Anpassung der Komponentenumgebung an projektspezifische Gegebenheiten, z. B. durch Skripting1.
Die Komposition und Konfiguration kann im RM-ODP-Modell keinem einzelnen Viewpoint zugeordnet werden. Aus der Perspektive der Geschäftsprozessmodellierung kann eine Zuordnung
zum Enterprise Viewpoint vorgenommen werden. Betrachtet man das Skripting, so ist der Technology Viewpoint heranzuziehen. Liegt der Schwerpunkt auf den Kommunikationsbeziehungen der
Komponenten, so ist der Computational Viewpoint relevant.
7.13.1 E-Service-Komposition
Die Komposition geschieht durch Verknüpfung der Daten- und Kontrollflüsse zwischen den
Komponenten beziehungsweise zwischen den Komponenten und der Internetservice-Plattform.
Dadurch werden die in den Komponenten implementierten Funktionen und Logiken zu einer
Gesamtlösung zusammengeführt. Die Komposition von Komponenten wird auch Orchestrierung
oder als Binden von Komponenten bezeichnet2.
Neben der technischen Komponentenverknüpfung mit den in Kapitel 7.12 vorgestellten
Integrationsmustern ist auch der Prozess der Verknüpfung zu betrachten. Die statische, zentrale
Komposition bekannter Services mittels Flusssprachen ist heute Stand der Technik. Moderne
Orchestrierungswerkzeuge verfügen über grafische Benutzeroberflächen, die es auch Personen
ohne Programmierkenntnissen erlauben eine Komponentenkomposition vorzunehmen (siehe
Kapitel 4.2).
In der Forschung beschäftigt man sich mit der automatisierten Komposition. Hierunter fallen
Agentensysteme sowie die zentrale automatische Komposition nicht näher bekannter Dienste. Für
diese automatisierte Komposition ist ein zusätzlicher Indirektionsmechanismus erforderlich, der auf
Basis von definierten Kriterien eine dynamische Suche, Auswahl und Dienstkomposition vornimmt.
Eine Voraussetzung hierfür ist, dass die Dienste in geeigneten formalisierten Beschreibungssprachen vorliegen, die eine automatische Suche und Auswahl unterstützen. Über die Unzulänglichkeiten solcher Registrys wurde im Kapitel 4.2.7 berichtet. Dies führt dazu, dass die automatische Komposition heute nur bei trivialen Diensten praktisch angewendet werden kann. In der
Zukunft ist allerdings denkbar, dass sich der Dienstanbieter vollständig vom Dienstnutzer entkoppeln lässt und die Komposition dynamisch stattfindet3.
1
2
3
Unter Skripting wird die Verbindung von Komponenten mittels einer Programmiersprache verstanden. Skripting ist
mitunter notwendig, weil Komponenten nicht immer direkt im Sinne eines Plug and Play, d. h. ohne zusätzliche
Programmierung, miteinander gekoppelt werden können. Ein Skript ist demnach ein Programm und kann somit,
wenn es bestimmte Konventionen einhält, auch als Komponente verstanden werden.
Vgl. /Weis-2002 (S. 156)/Ritt-2000 (S. 179)/Weis-2000 (S. 24)/.
Vergleichbare Konzepte existieren im Telekommunikationsmarkt bei sogenannten Least-Cost-Routern. Solche
Systeme beziehen regelmäßig die aktuellen Tarife verschiedener Telefon- und Internet-Provider. Je nach Zieladresse, Uhrzeit sowie gewünschtem Verbindungstyp sucht der Least-Cost-Router bei Anwahl durch den Anwender
einen geeigneten Kommunikations-Provider und -Tarif aus und stellt eine Verbindung her.
- 170 -
7.13.2 E-Service-Konfiguration
Im Anschluss an die Komposition erfolgt die Parametrisierung der Komponenten. Hierzu werden
die Komponenten entsprechend der zur Verfügung gestellten Konfigurationsmöglichkeiten an die
spezifischen Anforderungen angepasst1.
7.13.3 Integrationstests
Im Anschluss an die Konfiguration beginnen die Integrationstests. Hierbei soll das korrekte Zusammenwirken aller Module und Komponenten sichergestellt werden. Die Prüfungen müssen
zeigen, dass alle Module und Komponenten den spezifizierten Anforderungen entsprechen. Als
Testobjekt eignen sich das Überprüfen anhand der definierten Use Cases.
7.14 IT-Service-Management
Wie bereits in Kapitel 7.3.4 erwähnt, schaffen technische Sicherheitssysteme alleine keine ITSicherheit, sondern sie bedürfen der permanenten menschlichen Überwachung. Bekanntermaßen
ist die IT-Sicherheit nicht statisch; täglich werden neue Sicherheitslücken erkannt, publiziert und
ausgenutzt. Ohne fortlaufende Wartung nimmt der Grad der Sicherheit im Netzwerk dauernd ab.
Im Hinblick auf die Gewährleistung der IT-Sicherheit sowie zur Aufwandsoptimierung existieren
mehrere Standards. Diese Standards überlappen sich teilweise, setzen jedoch auch unterschiedliche Schwerpunkte und richten sich an verschiedene Zielgruppen. Im Folgenden sollen
diese Standards und deren Schwerpunkte kurz aufgeführt werden.
7.14.1 Service Level Agreement
Die Qualität eines internetbasierten Mehrwertdienstes wird von einer Vielzahl zusammenwirkender
IT-Komponenten und Serviceleistungen innerhalb der ASP-Value-Chain bestimmt. Die zur Aufrechterhaltung des E-Service-Betriebs resultierenden Anforderungen an die IT-Systeme und an die
IT-Organisation kann der Anwender beziehungsweise Kunde aufgrund der Komplexität oft nicht
mehr selbst formulieren. Deshalb werden von IT-Organisationen IT-Dienstleistungen definiert, und
deren Leistungsversprechen in Service Level Agreements (SLA)2 festgehalten. In den SLA sind z.
B. Durchsatz, Antwortzeiten, Verfügbarkeit und andere technische Messgrößen festgehalten, aber
auch die Erreichbarkeit der Servicemitarbeiter oder die mittlere Dauer für eine Störungsbehebung.
Charakteristisch für ein SLA ist, dass der Dienstleister jeden relevanten Dienstleistungsparameter
in verschiedenen Gütestufen – den Service Levels – anbietet, aus welchen der Kunde unter betriebswirtschaftlichen Gesichtspunkten auswählen kann.
Die Umsetzung der SLA ist Aufgabe des IT-Service-Managements (ITSM). ITSM umfasst die
Gesamtheit von Maßnahmen und Methoden, die nötig sind, um die Unterstützung von Geschäftsprozessen durch die IT-Organisation zu erreichen. Ein standardisiertes ITSM allein ist allerdings
noch kein Garant für die Nutzerakzeptanz. IT-Organisationen müssen die Anforderungen ihrer
internen und externen Kunden verstehen und ihre Aufbau- und Ablauforganisation darauf ausrichten. Dies wird heute mit dem Begriff Business-IT-Alignment3 verbunden.
1
2
3
Aus Integrationsprojekten im Rahmen der Einführung digitaler Fabrikplanungswerkzeuge ist bekannt, dass Skripting
von Standardkomponenten einen Umfang von bis zu 100.000 Programmzeilen haben kann.
Service Level Agreement, englisch für Dienstgütevereinbarung.
Business IT-Alignment bezeichnet die Ausrichtung (engl. Alignment) der Informationsfunktion eines Unternehmens
an dessen Geschäftsfunktionen.
- 171 -
7.14.2 IT Infrastructure Library
Die IT Infrastructure Library (ITIL) ist das derzeit umfassendste Rahmenwerk und ein De-factoStandard für die Gestaltung der organisatorischen Prozesse zum Betrieb einer IT-Infrastruktur. ITIL
wurde von der Central Computing and Telecommunications Agency, einer Regierungsbehörde in
Großbritannien, entwickelt und wird heute vor allem von der itSMF International Vereinigung1
vorangetrieben. Die Prozesse orientieren sich bei ITIL nicht an der Technik, sondern an den ITDienstleistungen. Daher bildet ITIL eine mögliche Grundlage für ein IT-Service-Management.
ITIL versucht keine endgültige und umfassende Standardisierung, sondern verfolgt einen BestPractice-Ansatz2. Dabei werden in der Praxis erfolgreiche Modelle und Organisationsformen so beschrieben, dass jede Organisation sie beliebig adaptieren und auf ihre Bedürfnisse zuschneiden
kann. ITIL beschreibt nicht, wie etwas getan werden muss, sondern nur, was getan werden sollte.
ITIL liefert Empfehlungen für das IT-Service-Management, für das Management von Kunden- und
Lieferantenbeziehungen in der IT, für das IT-Sicherheitsmanagement, für Leistungserstellungsprozesse sowie für das Vorgehen in der Implementierung dieser Prozesse.
7.14.3 IT-Service- und IT-Sicherheitsmanagement nach ISO 20000
Der ISO 20000 Standard regelt Mindestanforderungen und weitergehende Empfehlungen für die
Umsetzung des IT-Service- und IT-Sicherheitsmanagements sowie für das Kunden- und
Lieferantenmanagement in der IT. Die anderen ITIL-Prozessbereiche wurden hier nicht berücksichtigt.
Abbildung 7-11: Methodik des Service-Managements nach ISO 20000
1
2
Die Vereinigung itSMF International ist – eigenen Angaben zufolge – die weltweit einzige unabhängige und international anerkannte Organisation für IT-Service-Management. Sie dient als Plattform für den Wissens- und Erfahrungsaustausch. Vgl. </http://www.itsmf.org/>, letzter Abruf am: 01.05.2008.
Best Practice, englisch für wörtlich bestes Verfahren; freier übersetzt für Erfolgsrezept bzw. Erfolgsmethode.
- 172 -
Zentraler Ansatz der ISO 20000 ist ein geschlossener Managementzyklus für IT-Services entsprechend des Musters: plan-do-check-act. So lässt sich für die IT-Organisation die gezielte Umsetzung von Anforderungen an die Prozesse planen, die konkrete Umsetzung steuern, die Ergebnisse überwachen und bewerten sowie kontinuierlich verbessern (siehe Abbildung 7-11).
7.14.4 IT-Grundschutz-Standard des BSI
Der IT-Grundschutz-Standard des Bundesamts für Sicherheit in der Informationstechnik (BSI)
sowie das Informationssicherheits-Managementsystem nach ISO 27001 sind zwei der meist genutzten Standards für Informationssicherheit.
Die IT-Grundschutz-Standards beinhalten Richtlinien zur Etablierung eines IT-Sicherheitsmanagements, zum Umgang mit Gefährdungen in der IT-Sicherheit und zur Erstellung von Risikoanalysen. Die BSI-Standards zeigen auf, wie ein angemessenes Sicherheitsniveau erreicht werden
kann (siehe Kapitel 7.3.4). Der IT-Grundschutz wird wie folgt aufgeteilt (siehe Tabelle 7-30):
Standard
Beschreibung
BSI-Standard:
100-11
Das Dokument „Standard Managementsysteme für Informationssicherheit“ behandelt den Aufbau und Betrieb eines IT-Sicherheitsmanagements. Durch die
Anwendung der vom IT-Grundschutz empfohlenen organisatorischen,
personellen, infrastrukturellen und technischen Maßnahmen wird ein IT-Sicherheitsniveau erreicht, das für den normalen Schutzbedarf angemessen ist. Der
BSI-Standard 100-1 ist vollständig kompatibel zum ISO-Standard 27001.
BSI-Standard:
100-22
In dem Dokument „IT-Grundschutz-Vorgehensweise“ wird die Vorgehensweise
beschrieben, mit der ein IT-Sicherheitsmanagement aufgebaut und betrieben
werden kann. Die IT-Sicherheitsanforderungen werden interpretiert und aus
den Grundschutzkatalogen Maßnahmen für die Implementierung eines angemessenen IT-Sicherheitsniveaus empfohlen.
BSI-Standard:
100-33
Die „Risikoanalyse auf der Basis von IT-Grundschutz“ stellt eine Ergänzung
des BSI-Standards 100-2 dar und behandelt höhere Sicherheitsanforderungen.
IT-Grundschutzkataloge4
Die „IT-Grundschutz Kataloge“ dienen als Nachschlagewerk zu Fragen der ITSicherheit sowie zur Ermittlung des erreichten IT-Sicherheitsniveaus. Das Verfahren wird im BSI-Standard 100-2 beschrieben; in den Katalogen können die
entsprechenden Maßnahmen nachgeschlagen werden. Ferner benennen sie
Hilfsmittel zum Umgang mit gängigen Sicherheitsproblemen.
Tabelle 7-30: IT-Grundschutz-Standards des BSI
1
2
3
4
Vgl. /BSI-2005a/.
Vgl. /BSI-2005b/.
Vgl. /BSI-2005c/.
Vgl. /BSI-2005d/.
- 173 -
7.15 E-Service-Pilotierung und -Markteinführung
Die Pilotierung und Markteinführung stellt nicht den Kern der Arbeit dar, die ihren Schwerpunkt auf
der Gestaltung hat. Da jeder Mehrwertdienst nach Durchlaufen des Vorgehensmodells in Betrieb
geht, sollen im Folgenden dennoch die wichtigsten Aspekte genannt werden.
7.15.1 Pilotierung
Nach Abschluss der internen Tests erfolgt die Pilotierung der Mehrwertdienste im Feld unter Einbeziehung von Pilotkunden. Dies dient dazu, um unter Praxisbedingungen die evtl. vorhandenen
Defizite aufzuzeigen und um Verbesserungsvorschläge in Funktionalität und Verhalten aufzugreifen, bevor die Markteinführung erfolgt. Die schriftlich dokumentierten Ergebnisse der
Pilotierung sollten Eingang in die Weiterentwicklung der Dienste finden. Erst nach erfolgreicher
Piloteinführung ist die Dienstleistung am Markt anzubieten. Tabelle 7-31 fasst in Anlehnung an
Kreidler1 und eigene Erfahrungen häufig wiederkehrende Pilotierungsprobleme zusammen.
Themenfeld
IT-Sicherheit
Problembeschreibung
Firewalls lassen keine aktiven Inhalte zu
Firewalls erlauben kein HTTPS-Protokoll
Lokale Anti-Virusprogramme verändern das Systemverhalten
Infrastruktur
Client-Rechner sind teilweise veraltet und schlecht gewartet, was zu langen
Installations- bzw. Ladezeiten und damit zu Akzeptanzproblemen führt.
Nicht ausreichende Bandbreiten führen auf Client-Seite zu Wartezeiten, die
der Anwender durch „herumklicken“ überbrückt. Dies führt auf der ServerSeite zum Mehrfachstarten von Applikationen, was Seiteneffekte auslöst.
Organisation
Bei vielen Firmen wird die Firewall durch externe Firmen oder Zentralabteilungen gewartet. Notwendige Konfigurationsänderungen sind oft mühsam.
Anwender haben keine ausreichenden Rechte, um Software zu installieren.
In der Phase der Pilotierung ist die Änderungshäufigkeit der Funktionen und
Benutzeroberflächen hoch. Ständige Änderungen überfordern die Anwender.
Tabelle 7-31: Typische Pilotierungsprobleme
7.15.2 Markteinführung
Mit Abschluss der positiv verlaufenen Piloteinführung liegt ein getestetes Dienstleistungsprodukt
vor. Die Markteinführung ist Aufgabe des Marketings und des Vertriebs. Potenzielle Kunden
müssen über die neue Dienstleistung informiert, Einführungs- und Schulungskonzepte erarbeitet
werden, d. h., die Inhalte des Marketingkonzeptes sind umzusetzen. Die am Markt zu kommunizierenden Dienstleistungsinformationen umfassen dabei alle Maßnahmen und Medien, die den
Käufer von Dienstleistungen vor der Kaufentscheidung so informieren, dass wesentliche
Leistungsbestandteile nach Inhalt und Umfang erkennbar werden, die Leistungen in ihrer Qualität
mit anderen Angeboten vergleichbar und auch Risiken und Konsequenzen sichtbar und abschätzbar werden. Sie sollen qualifizierte Aussagen über die vertraglichen Bedingungen einschließlich
der zugesicherten Eigenschaften enthalten und gegebenenfalls Anleitungen für die sachgerechte
Nutzung
bieten.
1
Vgl. /Krei-2002/.
8 Anwendung und Bewertung des Vorgehensmodells
Die Neugier steht immer an erster Stelle eines Problems, das gelöst werden will.
Galileo Galilei
Physiker und Astronom
Gegenstand dieses Kapitels ist die Anwendung und Bewertung des Vorgehensmodells zur Gestaltung internetbasierter Mehrwertdienste für den Maschinen- und Anlagenbau. Im Verbundforschungsprojekt E-Industrial Services wurden von allen beteiligten Projektpartnern insgesamt 12
Mehrwertdienste konzipiert und auf einer gemeinsamen Internetservice-Plattform realisiert. Die
einzelnen Mehrwertdienstprojekte fanden unter Mitwirkung von Industriepartnern statt, deren Anforderungen bei der Konzeption und Umsetzung Berücksichtigung fanden.
Bei vier dieser Mehrwertdienste war der Autor der vorliegenden Arbeit für Konzept und Realisierung federführend. In den folgenden Abschnitten werden zwei davon näher beschrieben:
virtuelle Anlagenprojektierung und die internetbasierte Logistikanalyse. Diese Mehrwertdienste
wurden in verschiedenen Entwicklungsprojekten konzipiert, optimiert und zusammen mit den
jeweiligen Projektpartnern prototypisch umgesetzt. Eine Implementierung wird von dem assoziierten Industriepartner bis heute zur Anlagenprojektierung verwendet. Die Konzepte und Projekte
der nicht näher beschriebenen Mehrwertdienste – E-Optimization1 und E-Simulation2 – lassen sich
in publizierten Veröffentlichungen einsehen und nachvollziehen.
Die nachfolgende Beschreibung legt einen Schwerpunkt auf die prinzipielle Herangehensweise
und nicht auf Detailerläuterungen einzelner Klassenstrukturen, Use Cases o. ä. Darüber hinaus
werden nicht alle Facetten des Vorgehensmodells dargestellt. So wird beispielsweise die EService-Strategie als gegeben vorausgesetzt3.
Zunächst erfolgt im Kapitel 8.1 die Vorstellung der konzipierten Internetservice-Plattform. Die in
Kapitel 8.2 und 8.3 beschriebenen Mehrwertdienste setzen auf dieser Internetservice-Plattform auf
und nutzen Funktionen des zuvor beschriebenen E-Service-Komponentenkatalogs. In Kapitel 8.4
erfolgt eine Bewertung des Vorgehensmodells.
1
2
3
E-Optimization ist ein Dienst zur Optimierung von Einlastungsreihenfolgen für die kurz- und mittelfristige Auftragskoordination. E-Optimization nutzt verteilt ablaufende, evolutionäre Algorithmen. Durch den parallelen Einsatz unterschiedlicher Algorithmen (Genetische Algorithmen, Sintflut-Algorithmen, Hill-Climbing, Threshold-Accepting) und dem
zyklischen Austausch von Zwischenergebnissen lassen sich gegenüber konventionellen Ansätzen Vorteile in Bezug
auf die Lösungsgüte und Lösungsgeschwindigkeit erzielen. Vgl. /Sihn-2002e/Sihn-2000b/Sihn-2000c/.
E-Simulation ist ein Mehrwertdienst, der die Nutzung von Materialfluss-Simulationsmodellen über das Internet ermöglicht. Durch E-Simulation wird die technische Voraussetzung geschaffen, die Modelle der Produktionssysteme dauerhaft aktuell zu halten und dem Anlagenbetreiber die Simulationsdienstleistung via Internet anzubieten. Vgl. /Sihn2003c/Sihn-2002a/Sihn-2002c/Grau-2001c/Sihn-2001c/Sihn-2001d/Sihn-2001e/Sihn-2000a/.
Publikationen des Autors, die das Thema der E-Service-Strategie beleuchten vgl. /Sihn-2003a/Grau-2001b/Sihn2001a/Sihn-2001b/Sihn-2001f/.
Anwendung und Bewertung des Vorgehensmodells
- 175 -
8.1 Internetservice-Plattform von E-Industrial Services
Unter Anbetracht der konkreten Randbedingungen und Anforderungen fiel im Projekt E-Industrial
Services die Wahl auf eine Mehrschichtarchitektur, die aus drei Schichten besteht. Durch die Verwendung dieser Architektur wird die Integration externer Software- beziehungsweise Bestandssysteme über standardisierte Schnittstellen in geeigneter Weise unterstützt. Abbildung 8-1 zeigt
den schematischen Aufbau der realisierten Anwendungsarchitektur.
Im Zentrum der Anwendungsarchitektur steht die Servicelogik. Sie muss durch den Dienstentwickler für jeden Dienst individuell erstellt werden. Dazu stehen ihm Schnittstellen zu den verschiedenen Komponenten der Plattform zur Verfügung. Die Entwicklungs- und Administrationswerkzeuge sind nicht integraler Bestandteil der Internetservice-Plattform. Sie stellen eigenständige
Systeme dar, die im Falle der Entwicklungsumgebung die Schnittstellen der Plattform
dokumentieren und für den Dienstentwickler nutzbar machen.
Diese Anwendungsarchitektur hat sich zur Realisierung der 12 Mehrwertdienste bewährt; sie ist
allerdings nicht als verbindliche Empfehlung zu werten. Die Auswahl einer geeigneten Internetservice-Plattform ist – wie im Kapitel 7.10 beschrieben – immer fallspezifisch.
Web-UI
Framework
Authentifizierung
Nutzermanagement
Vertragsmanagement
Sitzungsmanagement
ContentManagement
Service Logik
Kryptographie
Logging und
Abrechnung
Legacy
Schnittstellen
Administration
Entwicklungswerkzeuge
Portal
Kommunikationsschnittstellen
Datenbanken
Abbildung 8-1: Anwendungsarchitektur des Projekts E-Industrial Services1
Im Rahmen des Projekts wurden zahlreiche fachübergreifende Komponenten spezifiziert, realisiert
und in das Framework der Internetservice-Plattform integriert (siehe Tabelle 8-1). Fachspezifische
Komponenten, die lediglich innerhalb eines Dienstes benutzt werden, sind nicht aufgeführt.
1
Vgl. /Berg-2003 (S. 209)/.
Aufgabe
Komponente
- 176 -
Funktion
Transport
Transport
Upload-Dienst
Komponente, welche die o. g. Transportprotokolle unterstützt.
Speicherung
ODBC, JDBC,
Dateien
Komponenten zur Herstellung von Persistenz mittels relationaler Datenbanken und Dateien.
Archive-Dienst
Komponente, die es ermöglicht, Nutzdaten unter Angabe von Metadaten
(z. B. User, Datum etc.) in ein Archiv zu speichern.
Rollback-Dienst
Komponente, die es ermöglicht, unter Angaben von Metadaten Nutzdaten
einer definierten Version aus dem Archiv zu lesen.
Informationsbereitstellung
siehe Content-Management
Kommunikation
siehe Transport sowie Unified Messaging
Kooperation
Sicherheit
Einbindung
Bestandssysteme
Administration
Komponenten, welche FTP, HTTP, SMTP, POP3 sowie RMI unterstützen
Kooperation
siehe Content-Management
HTTPS
Nutzung von SSL durch Einbindung eines Zertifikates
Biometrie
biometrischen Fingerabdrucksensors zum Einloggen von Benutzern in die
Internetservice-Plattform
Einloggen über
URL
Einloggen in die Internetservice-Plattform mittels einer einmalig verwendbaren kryptischen URL
ContentManagement
Integration eines kommerziellen Content-Management-Systems (Produkt
WebGenesis, Fraunhofer IITB)
Unified
Messaging
Integration eines kommerziellen Unified-Messaging-Systems (Produkt David,
Firma Tobit) zur Kommunikation mittels SMS, FAX oder VoiceMail
Simulation
Integration der Materialflusssimulatoren (Produkt eM-Plant, Firma Siemens
PLM/UGS sowie Taylor ED, Firma Incontrol Enterprise Dynamics)
Autostart
Funktion, die nach unerwünschter Beendigung der Internetservice-Plattform
(z. B. Systemabsturz) alle zum Betrieb benötigten Dienste wieder startet
Benutzerverwalt.
Vertragsverwalt.
Authentifizierung
Diese Funktionen sind Bestandteil der Software enaGo der Firma IKV++.
Dienstverwaltung
Monitoring
Sonstige
Funktionen
OnlineSubscription
Komponente, die es Benutzern erlaubt ohne die Mithilfe eines Administrators,
eigenständig ein Profil auf einer Internetservice-Plattform zu erstellen, um die
öffentlichen Dienste zu nutzen.
Logging
Komponente, welche die spezifizierten Dienstnutzungsparameter (z. B. Benutzer, Dienst, Datum, Dauer etc.) aufzeichnet und persistent sichert.
Fragebogen- und
Formulardienst
Komponente, die aus einer vorgegebenen XML-basierten Fragebaumstruktur
einen interaktiven Web-Fragebogen generiert, der eine Unterbrechung der
Befragung ermöglicht und die Befragungsergebnisse persistent sichert.
Spool-andDispatch
Komponente, die eintreffende Events und Daten puffert und dann an
Rechner eines Pools übermittelt, um dort eine Verarbeitung anzustoßen.
Komposition
Komponente, die es Diensten der Internetservice-Plattform ermöglicht,
andere Dienste, die auf derselben Internetservice-Plattform laufen, zu
nutzen.
Föderation
Komponente, die es einem Dienst ermöglicht, Dienste dezentral betriebener
Internetservice-Plattformen zu nutzen, die im WAN betrieben werden.
Notification
Komponente, die unter Nutzung der Komponente Unified Messaging Benutzer oder Systeme via SMS, E-Mail, Fax oder VoiceMail informiert.
zeitgesteuerter
Dienststart
Komponente, die einen Dienst zu einer definierten Zeit startet, um z. B.
Logging-Statistiken automatisiert zu versenden.
Tabelle 8-1: Fachübergreifende Komponenten der Internetservice-Plattform von E-Industrial Services
- 177 -
8.2 Anwendungsbeispiel: virtuelle Anlagenprojektierung
8.2.1
Problemstellung
Um gegenüber dem internationalen Wettbewerb zu bestehen, wird Kundenorientierung im
Maschinen- und Anlagenbau immer wichtiger. Diese Kundenorientierung beginnt bereits im technischen Vertrieb. Um den individuellen Kundenwünschen zu entsprechen, sind maßgeschneiderte
Produktionssysteme erforderlich. Dies war in der Vergangenheit meist mit hohem Aufwand im
Engineering verbunden und führte oft zu Sonderkonstruktionen und Einzelanfertigungen.
Vertrieb
Schw achstellen:
keine Überprüfung auf technische Realisierbarkeit
individuelle Schablonen bei Vertriebsmitarbeiter
Definitionsphase beim Kunden
Anforderungsanalyse
Schw achstellen:
Medienbruch Papier / CAD
aufwändige Nachbearbeitung
Diskussion beim Kunden
Basis: 2D
Ausdruck
Detailplanung beim Kunden
ERP
Basis: 2D
Ausdruck
…
Engineering
Sichtbarkeitslinie
CAD
Konstruktion
kundenspezifischer
Lösung
CAD
Anpassung
der Variante
Schw achstellen:
Medienbruch Papier / CAD
hoher Detaillierungsgrad in der Definitionsphase
technische Zeichnung ist keine Vertriebsunterlage
CAD
technisches
Anlagenlayout
und Kalkulation
…
Schw achstellen:
häufige iterative Schleifen
keine verbindlichen Aussagen über
Leistungsfähigkeit möglich
Abbildung 8-2: Konventioneller Prozess zur Anlagenprojektierung
Um individuell auf Kundenwünsche eingehen zu können, bieten heute zahlreiche Unternehmen
ihre Produktpalette in Form eines Baukastens an. Durch die Verwendung aufeinander abgestimmter Maschinenmodule sind maßgeschneiderte und kostengünstige Individuallösungen auf
Basis von Standards möglich. Abbildung 8-2 zeigt einen konventionellen Prozess zur Anlagenprojektierung.
Die kundenindividuelle Anlagenprojektierung bietet jedoch gegenüber dem „Verkauf von der
Stange“ nicht nur Vorteile. Aufgrund der hohen Variantenvielfalt definiert sich ein Produkt oft über
eine Vielzahl von Attributen. Stellvertretend seien hier einige Problemfelder genannt:

Wer unterstützt den Vertriebsingenieur bei der Auswahl der „richtigen“ Maschinenmodule?

Welche Stückzahlen lassen sich mit der individuellen Anlage erzielen?

Welche Abmessungen, Anschlusswerte etc. hat eine solche Anlage?

Welche Auslegungsalternativen bestehen und welche Vorteile bieten diese?
8.2.2
- 178 -
E-Service-Design
Einen Lösungsansatz für die oben genannte Problemstellung liefert die virtuelle Anlagenprojektierung. Die Aufgabe besteht darin, eine spezifische Zusammenstellung von Maschinenmodulen nach bestimmten Vorgaben und Anforderungen des Kunden vorzunehmen. Der
Konfigurationsprozess basiert dabei oft auf einem Regelwerk, das in Form von Entscheidungstabellen oder -bäumen angelegt ist. Solche Systeme unterstützen demnach den Maschinenmodulauswahlprozess, erzeugen eine 3D-Visualisierung der individuell konfigurierten Fertigungsanlagen
und ermöglichen darüber hinaus eine integrierte Materialflusssimulation zur Analyse der
logistischen Leistungsfähigkeit. Das Prinzip der virtuellen Anlagenprojektierung wurde in verschiedenen Projekten mit Industriepartnern realisiert:

Abbildung 8-3 zeigt eine Anlage zur Prüfung von Leiterplatten. Dieser Mehrwertdienst wurde
zusammen mit der Rohwedder AG (vorher: Pematech GmbH) durchgeführt1.

Die Abbildung 8-4 und Abbildung 8-5 zeigen eine Anlage zur Isolierglasscheibenherstellung.
Das Projekt wurde mit der Bystronic Maschinen AG2 durchgeführt.

Für die Robert Bosch GmbH entstand ein System zur Konfiguration, Layoutplanung und
Simulation von Montagelinien im Sondermaschinenbau.
Obwohl die Anwendungsfälle in allen Projekten gleich sind, unterscheiden sich deren technische
Umsetzungen. Im Folgenden wird daher hauptsächlich die Konfiguration von Montagelinien zur
Prüfung elektronischer Leiterplatten näher betrachtet.
Abbildung 8-3: Linie zur Prüfung von elektronischen Leiterplatten
1
2
Die Konfiguration von Anlagen zur Prüfung elektronischer Leiterplatten wurde bereits in Ausschnitten veröffentlicht.
Vgl. /Grau-2002a/Grau-2002b/Grau-2002d/West-2002c/Sihn-2002d/.
Die Konfiguration von Anlagen zur Herstellung von Isolierglasscheiben wurde bereits in Ausschnitten veröffentlicht.
Vgl. /Grau-2006a/Dani-2005/Grau-2004c/Dani-2003/Grau-2003a/Grau-2003d/Sihn-2003b/Sihn-2003d /Sihn-2002b/.
- 179 -
Abbildung 8-4: Anlage zur Isolierglasscheibenherstellung
Abbildung 8-5: Virtuelles Anlagenmodell zur Isolierglasscheibenherstellung
8.2.3
Für den Auftraggeber sind insbesondere die Benutzerfreundlichkeit („Klick-Geschwindigkeit“)
sowie die Offline- und Onlinefähigkeit der Anwendung von großer Bedeutung. Zur Konfiguration
einer individuellen Anlage sind viele Klicks notwendig, die den Wunsch nach hoher Geschwindigkeit und gutem Antwortverhalten begründen. Die Anforderungen bzgl. Offline- und Onlinefähigkeit
ergeben sich aus dem Nutzungskontext: Da zu den Anwendern auch international tätige Vertriebsmitarbeiter zählen, kann nicht immer ein geeigneter Internetanschluss mit genügend Bandbreite vorausgesetzt werden. Deshalb muss die Applikation auch lokal ablauffähig sein.
8.2.4
E-Service-Prozessarchitektur
Abbildung 8-6 zeigt die E-Service-Prozessarchitektur, deren Ablauf im Folgenden beschrieben
wird: Ein Vertriebsmitarbeiter startet das Programm. Unter Nutzung der hinterlegten Maschinenmodule lässt sich in kurzer Zeit eine spezifische Prüflinie zum Test von Leiterplatten konfigurieren
sowie Einstellungen über den erwarteten Produktmix und die erwartete Fehlerrate definieren. Das
Ergebnis der Konfiguration liegt als Konfigurationsdatei auf dem System des Anwenders vor.
Via E-Mail erfolgt der Versand der Konfigurationsdatei an den Diensteserver (Sim-Service). Dort
erfolgen die Authentifizierung des Absenders und eine Prüfung der Konfigurationsdatei. Nach
positiver Prüfung erhält der Anwender via E-Mail eine Eingangsbestätigung mit einem Link auf
einen Archivpfad des Content-Management-Systems, auf dem die Konfigurationsdatei gespeichert
ist.
- 180 -
Die Konfigurationsdatei wird vom Sim-Service in einer Warteschlange (Job Queue) eingereiht. Bei
freier Simulationskapazität wird der Sim-Service vom lokalen Sim-Manager informiert. In der
Simulationsdomäne erfolgt der generische Aufbau des Simulationsmodells1 sowie die dynamische
Ablaufsimulation. Die Ablaufsimulation errechnet Durchsatz, Kapazität, Bestände und generiert
einen 3D-Film, der die Linie im Vorbeiflug zeigt. Nach Abschluss der Simulation legt der lokale
Sim-Manager die Ergebnisdaten in einem geschützten Bereich im Content-Management-System
ab und informiert den Anwender via E-Mail über das Vorliegen der Simulationsergebnisse.
Der Anwender kann damit sein Anlagenkonzept und dessen Leistungsfähigkeit dem potenziellen
Käufer vorstellen. Entspricht das Anlagenkonzept nicht den Anforderungen, lässt sich die Anlagenkonfiguration so lange verändern, bis die Kundenwünsche erfüllt sind.
Simulationsdienst auf dem
Diensteserver
Job
Queue
ContentM anagementSystem
Lokaler
SimManager
Logging
Fertig
SimService
ContentManagementSystem
Start
Simulationssystem
E-Mail
E-Mail
Anw ender
Simulationsdomäne
Konfiguration
Archivabruf
Bilderläuterung
Eingabe
Ergebnis
Abbildung 8-6: E-Service-Prozessarchitektur des Dienstes virtuelle Anlagenprojektierung
8.2.5
E-Service-Anwendungsarchitektur
Aufgrund der Anforderung nach Offlinefähigkeit wurde eine Anwendungsarchitektur gewählt, die
Rich-Clients auf Basis von Java-Applets und der JavaStart-Technolgie nutzt. Hierbei erfolgt beim
Start eines Dienstes zunächst eine Prüfung, ob die lokale Kopie der Applikation der des zentralen
Diensteservers entspricht. Gegebenenfalls wird zur Laufzeit die Applikation vom Server nachgeladen und anschließend lokal ausgeführt. Im Fall der Offline-Nutzung erfolgt stets die Ausführung der lokal gespeicherten Kopie. Die Anwendungsarchitektur gliedert sich in die nachfolgend
beschriebenen Subsysteme beziehungsweise Komponenten (siehe Tabelle 8-2):
1
Die Funktionsweise der generischen Simulation ist in /Grau-2006a/Dani-2005/Grau-2002b/ beschrieben.
Domäne
Funktion
Auswahl und Parametrisierung
der Maschinenmodule im
Konfigurator
Anwender
- 181 -
Technologie
Nutzen / Vorteil
Java-Applet
Der Konfigurations- und Parametrisierungsvorgang findet lokal statt und ist unabhängig von
der Netzwerkverfügbarkeit.
JavaStart
Definition der Randbedingungen, Eingabe der geforderten
Stückzahl und Definition des
Produktionsprogramms
Kommunikation
Simulati
onsDienst
auf dem
Diensteserver
Die lokale Instanz der Software
verfügt über ein gutes Antwortverhalten und ist schneller als
eine Client-Server-Verbindung.
Versand und Empfang der
Konfigurationsdatei an den beziehungsweise vom
Diensteserver via E-Mail
POP3
Warteschlange aller Simulationsanfragen in der Job Queue
Java
SMTP
Benutzer können transparent
nachvollziehen, welche Daten
verschickt werden.
Kein Mehraufwand in der IT-Administration, da E-Mailsysteme
ohnehin vorhanden sind.
SMTP
Zuführung der Konfigurationsdatei an den Simulator
Verarbeitung paralleler Anfragen von Benutzern
Um Inkonsistenzen zwischen
unterschiedlichen Software
Release-Ständen zwischen
Client und Server zu vermeiden,
erfolgt bei jedem Simulationsstart der Abgleich einer Prüfnummer zwischen Client und
Server.
Benachrichtigung des Benutzers via E-Mail über den Eingang und die Fertigstellung der
Simulation
Fehlermanagement
Simulati
onsdomäne
Durchführung der Ablaufsimulation des Materialflusses
Simulations
system
TaylorED
Ermittlung von Engpässen,
Pufferauslastungen, Werkstückträgerauslastungen,
Stückzahl, 3D-Film
ContentManagement
Speicherung der Simulationsergebnisse und -eingangswerte
und des 3D-Films im Portal
ContentManageme
nt
einfache Verwaltung verschiedener Kunden, Projekte
sowie Konfigurationsvarianten.
Tabelle 8-2: Elemente der E-Service-Anwendungsarchitektur
8.2.6
E-Service-Daten- und Kommunikationsarchitektur
Die Java-Applet-GUI kommuniziert auf dem Client über eine ODBC-Schnittstelle mit einer Microsoft Access Datenbank. In dieser Datenbank sind nach Abschluss der Konfiguration alle Strukturund Ablaufdaten gespeichert. Diese Konfigurationsdatei wird via E-Mail verschickt und beim
Empfänger im Archiv des Content-Management-Systems abgelegt. Beim Eintreffen der E-Mail
erfolgt via RMI ein Eintrag in die Job Queue, um dem Simulationssystem den Bedarf zu melden.
Sobald einer der angeschlossenen Simulationsrechner über freie Kapazität verfügt, greift dieser
über ODBC auf das Archiv mit der Datenbank zu. Die Simulationsergebnisse werden vom
Simulator als HTML-Datei ausgegeben, im Archiv abgelegt und der Anwender via SMTP benachrichtigt.
8.2.7
- 182 -
E-Service-Rollenmodell
Aufgrund der begrenzten Nutzeranzahl von ca. 10 Personen verfügt das System über kein umfassendes Rollen- beziehungsweise Nutzerkonzept, sondern arbeitet mit zuvor registrierten Benutzern.
8.2.8
E-Service-Komponentenkatalog
Eine Besonderheit stellt der Teil des Komponentenkatalogs dar, der die Maschinenmodule zur
Prüfung elektronischer Leiterplatten beschreibt. Er umfasst Maschinenmodule zum Ein- und Ausschleusen, zum Fördern, zum Puffern, zum Prüfen und zum Verteilen der Nutzen (Lose) entsprechend der Qualitätsprüfungsergebnisse. Für jedes Maschinenmodul sind die Geometriedaten,
die technischen Kennzahlen sowie das Verhalten zu erfassen und in einer Softwarekomponente
innerhalb des Simulationssystems abzulegen. Technisch sinnvolle Parameter, wie z. B. Fördergeschwindigkeiten und -beschleunigungen sowie Längen, sind öffentlich und damit über die Benutzeroberfläche editierbar, wie man Abbildung 8-7 entnehmen kann. In der Projektarbeit stellt die
Erfassung und Modellierung dieser Maschinenmodule den größten Aufwand dar.
8.2.9
Technisches IT-Sicherheitskonzept
Die Kommunikation zwischen dem Benutzer und dem Dienst erfolgt über die
Standardmailprotokolle SMTP, POP3 beziehungsweise IMAP sowie über einen SSL-geschützten
und zertifizierten Zugang, um auf das Archiv im Content-Management System zuzugreifen. Da
dies Standards jeder Unternehmenskommunikation sind, traten erwartungsgemäß weder psychologisch motivierte Einwände noch technische Bedenken oder Schwierigkeiten auf. Jede bislang im
Unternehmen verschickte E-Mail hatte dasselbe Sicherheitsniveau wie das neue System zur
virtuellen Anlagenprojektierung. Der Sim-Service auf dem Diensteserver lässt ausschließlich
namentlich bekannte Benutzer beziehungsweise deren E-Mail-Adressen zu. Vorhandene Sicherheitsmechanismen, wie z. B. ein VPN-Zugang für die E-Mail-Kommunikation, konnte ohne Mehraufwand genutzt werden.
8.2.10 E-Service-Komposition und -Konfiguration
Im Rahmen der Komposition wurden zuvor geschaffene Elemente des Komponentenkatalogs zum
E-Mail Versand sowie zur automatischen, API-basierten Generierung von Webseiten im ContentManagement-System genutzt. Eine Besonderheit stellt die Einbindung der Sim-ServiceKomponente dar. Diese Komponente puffert die Simulationsaufträge in einer Warteschlange, führt
die Jobs dem Simulator zu, startet den Simulator und beendet diesen bei auftretenden Problemen.
Diese Komponente entstand in einem anderen Teilprojekt mit einem anderen Fokus. Die Wiederverwendung und Komposition ganzer Dienste – also nicht nur einzelner Komponenten – zeigt die
Nutzenpotenziale des beschriebenen Konzepts auf.
8.2.11 Ergebnis und Kundennutzen
Der Anlagenanbieter kann mithilfe der virtuellen Anlagenprojektierung eine auf die Kundenbedürfnisse zugeschnittene Lösung anbieten, die anhand der realen Produktionsprogrammdaten
simulativ abgesichert ist. Der Kunde muss sich deshalb nicht mehr auf vom Verkäufer geschätzte
Leistungskennwerte verlassen, sondern bekommt „Zahlen, Daten und Fakten“ seiner individuellen,
virtuellen Anlage präsentiert. So ist beispielsweise die Anzahl der benötigten Bänder zur Pufferung
zwischen den einzelnen wertschöpfenden Aggregaten einer Linie oft ein Diskussionspunkt
- 183 -
zwischen Anbieter und Käufer. Die Käufer hegen dabei oft den unterschwelligen Verdacht, dass
sie nicht benötigte Hardware angeboten bekommen. Investitionen in Puffer bringen bei statischer
Betrachtung der Taktzeiten bekanntlich keinen Nutzen, sondern belegen im Gegenteil noch wertvolle Produktionsfläche. Mittels Simulation können die konkreten Bedarfe an Pufferbändern, die
sich durch den Produktmix, notwendige manuelle Eingriffe von Bedienern sowie durch Maschinenstörungen ergeben, objektiv bewertet werden.
Darüber hinaus ist es möglich, alternative Anlagenvarianten quantitativ durch Simulation zu bewerten und gegenüberzustellen. Dies versetzt den Anlagenanbieter in die Lage, dass er seinem
Kunden mehrere Angebote in unterschiedlichen Preis- und Leistungsklassen anbieten kann.
Ferner spielen auch verhandlungstaktische Gründe eine nicht unwesentliche Rolle. Statt einseitig
dem Preisdruck des Kunden nachzugeben, kann der Anlagenanbieter die Aufmerksamkeit auf eine
preisgünstigere Variante lenken. Abbildung 8-7 und Abbildung 8-8 zeigen jeweils einen Ausschnitt
der grafischen Benutzeroberflächen der Konfiguratoren aus zwei Projekten. Abbildung 8-9 zeigt ein
typisches Konfigurationsergebnis.
Abbildung 8-7: Benutzeroberfläche des Anlagenkonfigurators zur Prüfung von Leiterplatten
Abbildung 8-8: Benutzeroberfläche des Konfigurators zur Anlagenprojektierung von Isolierglasscheiben
- 184 -
- 185 -
Projektarchiv,
Navigation
Projektkopfdaten
Auslastung der
Module
Taktzeit der
Linie
3DAbbildung
3DFilm
Projektierungsparameter
Abbildung 8-9: Ergebnis der E-Anlagenkonfiguration auf der geschützten Webseite
- 186 -
8.2.12 Ausblick
In den Projekten mit Industriepartnern hat sich gezeigt, dass die Wartung der Projektierungssysteme aufwendig ist. Die fortlaufenden Änderungen und Optimierungen an der realen Konstruktion und Steuerungslogik müssen in den virtuellen Modellen ständig adaptiert werden, um belastbare Ergebnisse liefern zu können. Der Mehrwertdienst Anlagenprojektierung muss daher als ein
Bestandteil des Product Lifecycle Managements beziehungsweise als Teil der Digitalen Fabrik1
verstanden werden. Hierzu ist es erforderlich, die IT-Systeme zur Anlagenprojektierung organisatorisch in den Produktentstehungsprozess zu integrieren2. Gelingt dies nicht, so veralten die Projektierungssysteme zunehmend und sind für verbindliche Aussagen nicht mehr verwendbar. Dies
muss vor dem Hintergrund betrachtet werden, dass die Projektierungsergebnisse – insbesondere
Taktzeiten – in der Regel Vertragsbestandteil beim Anlagenverkauf sind.
Die im Rahmen der Anlagenprojektierung erstellten 3D-Modelle eignen sich darüber hinaus zur
Visualisierung und weiteren Bearbeitung und Detaillierung3. Abbildung 8-12 zeigt ein konfiguriertes
3D-Modell am Beispiel einer Isolierglasscheibenherstellungslinie in einer 3-Seiten-CAVE. Zur Darstellung in einer CAVE sind heute noch manuelle Zwischenschritte notwendig.
Abbildung 8-10: Immersive Visualisierung einer konfigurierten Anlage in einer 3-Seiten-CAVE4
1
2
3
4
Das Konzept der virtuellen Anlagenprojektierung wurde im Jahr 2006 in der VDI-Richtlinie zur Definition der Digitalen
Fabrik /VDI-4499/ als Anwendungsbeispiel aufgenommen.
Zur Einführung Digitale Fabrik vgl. /Grau-2006b/Grau-2006d/Grau-2005a/Grau-2005b/Grau-2004a/Grau-2004b/.
Anwendungsbeispiele der Digitalen Fabrik. Vgl. /Grau-2006e/Grau-2006c/Grau-2005c/Grau-2005d/Grau-2005e/.
Vgl. /Grau-2006a (S. 411)/.
- 187 -
8.3 Anwendungsbeispiel: internetbasierte Logistikanalyse
8.3.1
Problemstellung
Die meisten produzierenden Unternehmen besitzen ERP- und BDE-Systeme. Sie verfügen damit
über die notwendige Datenbasis zur Durchführung von Logistikanalysen. Oftmals generieren ERPSysteme allerdings nur aggregierte Kennzahlen zu monetären und qualitativen Zielgrößen ganzer
Produktionsbereiche. Dezentral verteilten BDE-Systemen hingegen fehlt oft der übergeordnete
Blick auf alle relevanten Bereiche eines Fertigungssystems. Die zunehmende Durchdringung von
IT-Systemen in der Produktion hat an dieser Situation wenig verändert! Teilweise stammen die in
den ERP-Systemen modellierten Geschäftsprozesse noch aus einer Zeit, in der andere Paradigmen in der Produktionsplanung und -steuerung vorherrschten. Neben methodischer Unsicherheit und Zeitmangel sind dies Gründe, wieso in der Praxis häufig kein effektives LogistikControlling stattfindet.
Die Folge ist, dass manche Produktionssysteme – selbst bei unbefriedigender Leistungsfähigkeit –
so lange betrieben werden, bis die logistischen Probleme enorme Ausmaße erreichen und umfangreichere Einschnitte erfordern. Die anstehenden Maßnahmen stehen dann aufgrund der
späten Problemidentifikation meist noch zusätzlich unter erhöhtem Termindruck. Die zwingend erforderliche fortlaufende Anpassung der Produktionssysteme findet demnach nicht in ausreichendem Maße statt. Überhöhte Bestände und geringe Liefertermintreue sind die resultierenden
Symptome, die in überhöhte Kosten und geringe Kundenzufriedenheit münden.
8.3.2
E-Service-Design
Die Zielsetzung der internetbasierten Logistikanalyse ist, Produktionsbetrieben mit stückgutorientierter Fertigung eine schnelle und kostengünstige Möglichkeit zur Visualisierung
logistischer Zusammenhänge zu vermitteln. Mithilfe des Dienstes lassen sich Produktionsabläufe
transparent darstellen, logistische Engpässe im Materialfluss erkennen und produktionslogistische
Rationalisierungspotenziale bewerten und erschließen. Die internetbasierte Logistikanalyse wird
damit zu einem geeigneten Werkzeug für das Logistik-Controlling.
Der Mehrwertdienst automatisiert die Verarbeitung der vorhandenen Betriebsdaten. Er verdichtet
diese zu logistischen Kenngrößen und stellt sie in geeigneter Weise dar. Der Anwender erhält
Informationen über das logistische Verhalten seines Produktionssystems, geordnet nach einzelnen
Ressourcen und nach Produktionsaufträgen. Die Realisierung als Internetdienst erlaubt eine zeitund ortsunabhängige Nutzung von allen netzwerkfähigen Arbeitsplätzen eines Unternehmens.
Grundlage der internetbasierten Logistikanalyse ist das Trichtermodell des Instituts für Fabrikanlagen der Universität Hannover, das die produktionslogistischen Zielgrößen Bestand, Leistung
und Durchlaufzeit zueinander in Beziehung setzt und damit ein aussagekräftiges Beschreibungsmodell für die Produktionslogistik anbietet1. Mithilfe der berechneten Kenngrößen zu Beständen,
Leistungen, Auftragsstruktur, Durchlaufzeiten, Auslastungen und Terminabweichungen lassen sich
diejenigen Ressourcen schnell ermitteln, welche die logistische Leistungsfähigkeit maßgeblich beeinflussen. Auf dieser Grundlage lassen sich geeignete Maßnahmen mit Schwerpunkt auf Durchlaufzeitverkürzung, Bestandssenkung und Erhöhung der Termineinhaltung einleiten.
1
Vgl. /Nyhu-2003/.
8.3.3
- 188 -
Die zum Dienstbetrieb notwendige Infrastruktur nutzt Standard-Web-Browser als Client unter
Nutzung des HTTP-Protokolls. Die Aufbereitung der Inhalte findet auf der Server-Seite statt,
sodass keine aktiven Inhalte auf der Client-Seite Anwendung finden.
8.3.4
E-Service-Prozessarchitektur
Die Nutzung der internetbasierten Logistikanalyse teilt sich in die Phasen Beitritt und Analyse auf.

In der Beitrittsphase nimmt der Internetdienst die Identifikation des Nutzers vor und legt einen
personalisierten Bereich innerhalb der Internetservice-Plattform an. Danach ist der Dienst für
Logistikanalysen sofort nutzbar.

Bei der Durchführung von Logistikanalysen besteht der erste Schritt darin, die Logistikdaten
(siehe Tabelle 8-3 bis Tabelle 8-7) in eine Tabelle mit einem vorgegebenen Datenformat einzutragen. Dazu steht eine entsprechende Vorlage bereit. Diese Datei wird über den Web-Browser
unter Nutzung der Upload-Komponente an den Internetdienst übergeben, der anschließend die
Analyse durchführt. Hochgeladene Logistikdaten bleiben gespeichert und lassen sich auf
Wunsch löschen.
8.3.5
E-Service-Integrationsarchitektur
Der Bedarf zur Spezifikation einer E-Service-Integrationsarchitektur ist nicht gegeben, da die internetbasierte Logistikanalyse keine Vernetzung mit Bestandssystemen aufweist.
8.3.6
E-Service-Datenarchitektur
Für die Durchführung einer Logistikanalyse werden Unternehmensdaten zu Fertigungsaufträgen,
Ressourcen, Arbeitsgängen und Rückmeldungen benötigt. Falls verfügbar, ist die Angabe von
Arbeitsgangtexten wünschenswert. Die Daten sind als Microsoft Excel-Tabellen in einer Datei zu
bündeln und unter Nutzung der definierten Tabellenblätter abzuspeichern. Die Entscheidung zugunsten eines proprietären Formats wurde vor allem wegen der großen Verbreitung von Excel gewählt. Ferner muss davon ausgegangen werden, dass die benötigten Daten aus verschiedenen
Systemen exportiert und manuell nachbearbeitet werden müssen, sodass der Einsatz von Excel
ohnehin sehr wahrscheinlich ist. Nach dem Hochladen der Logistikdaten erstellt die interne Dienstverarbeitung aus der Excel-Datei zunächst vier einzelne XML-Dateien, auf denen die weitere
Datenverarbeitung basiert. Mit zunehmender Verbreitung von XML-Editoren kann demnach aufwandsarm auf ein XML-Datenformat als Datenträgerformat gewechselt werden. Im Folgenden wird
der genaue Umfang der benötigten Daten angegeben.
Inhalt
Feld
Typ
Muss
Einh.
Bemerkung
Bereich
BER
String
X
-
Name des Unternehmensbereichs
Kostenstelle
KOS
String
X
-
Kostenstelle des Unternehmensbereichs
Maschinengruppe
MGR
String
X
-
Maschinengruppe
Bezeichnung
BEZ
String
-
Bezeichnung der Maschinengruppe
Maschinenanzahl
AZM
Integer
-
Anzahl Maschinen in der Maschinengruppe
ø-Tageskapazität
MTK
Real
h/Tag
mittlere Tageskapazität
Tabelle 8-3: Benötigte Daten zu Ressourcen (RES)
Inhalt
Feld
Typ
- 189 -
Muss
Einh.
Bemerkung
Auftragsnummer
NAU
String
X
-
Sachnummer
NSA
String
X
-
Sachnummer des Artikels
Sachnummernbezeichnung
BEZ
String
-
Beschreibung des Artikels
Zielmenge Auftrag
MEZ
Integer
Stück
Sollfertigstellungstermin
SFT
Datetime
JJJMMTT_
SSMM
Sollfertigstellungstermin
Tabelle 8-4: Benötigte Daten zu Fertigungsaufträgen (FAT)
Inhalt
Auftragsnummer
Feld
Typ
Muss
Einh.
Bemerkung
NAU
String
X
-
Arbeitsgangnummer
NAG
Integer
X
-
Sollmenge
MES
Integer
X
Stück
Bereich
BER
String
X
-
Kostenstelle
KOS
String
X
-
Maschinengruppe
MGR
String
X
-
Planrüstzeit
ZRP
Real
X
Min.
Planstückzeit
ZEP
Real
X
Min./Stück
Bearbeitungszeit für eine Mengeneinheit des
Fertigungsauftrags
Sollstartzeitpunkt
SST
Datetime
JJJJMMTT
_SSMM
vorgegebener Starttermin nach Kalendertag,
Stunde und Minute
Sollendzeitpunkt
SET
Datetime
JJJJMMTT
_SSMM
vorgegebener Endtermin nach Kalendertag,
Stunde und Minute
Einh.
Bemerkung
Einh.
Bemerkung
Tabelle 8-5: Benötigte Daten zu Arbeitsgängen (AVG)
Inhalt
Kürz
el
Typ
Muss
Auftragsnummer
NAU
String
-
Arbeitsgangnummer
NAG
Integer
-
Textzeilennummer
NTZ
Integer
-
Arbeitsgangtext
AGT
String
-
Tabelle 8-6: Nutzbare Daten zu Arbeitsgangtexten (AGT)
Inhalt
Auftragsnummer
Feld
NAU
Typ
Muss
String
X
-
Arbeitsgangnummer
NAG
Integer
X
-
Bereich
BER
String
X
-
Kostenstelle
KOS
String
X
-
Maschinengruppe
MGR
String
X
-
Rückmeldeart
RMT
Integer
X
-
Gutmenge
MEG
Integer
Ausschussmenge
MEA
Integer
Meldedatum
MED
Datetime
Tabelle 8-7: Benötigte Daten zu Rückmeldungen (RMG)
1) Auftrag gestartet, 2) Bearbeitung beendet
Stück
Stück
X
JJJJMMTT
_SSMM
Meldedatum nach Kalendertag, Stunde und
Minute
8.3.7
- 190 -
E-Service-Rollenmodell
Das implementierte Rollenmodell betrachtet jeden Anwender als Individuum. Es kennt demnach
keine Gruppen oder Rollen.
8.3.8
E-Service-Komponentenkatalog
Von besonderer Bedeutung ist bei der Logistikanalyse die Komponente, welche die Datenverarbeitung auf Basis des Trichtermodells vornimmt. Zur Identifikation möglicher Verbesserungsmaßnahmen sollten dessen Grundlagen bekannt sein.
Die Grundvorstellung dieses Erklärungsmodells ist ein Trichter mit Zu- und Ablauf. Der Ablaufstrom ergibt sich aus dem Querschnitt des Ablaufs, der Inhalt des Trichters bestimmt sich aus dem
vorhandenen Inhalt sowie dem Zulauf und dem Ablauf.
Bei der Übertragung des Modells auf die Produktion repräsentiert ein Trichter eine Maschine, eine
Maschinengruppe oder ein gesamtes Werk. Der Inhalt des Trichters entspricht dem Auftragsbestand im Puffer vor einer Ressource. Die eingehenden Aufträge beschreiben den Zulauf. Der
Ablauf hängt von der Leistungsfähigkeit einer Ressource ab und entspricht den fertig gemeldeten
Aufträgen.
Das Trichtermodell stellt damit den Zusammenhang zwischen Bestand, Durchlaufzeit und Leistung
her. Diese logistischen Kenngrößen werden periodenorientiert erhoben. Die Logistikanalyse stellt
damit einen statistischen Ansatz dar.
8.3.9
Technisches IT-Sicherheitskonzept
Die Kommunikation zwischen dem Benutzer und dem Dienst erfolgt ausschließlich über das
HTTP-Protokoll unter Nutzung eines SSL-geschützten und zertifizierten Zugangs. Es kommen
somit die Standard-Komponenten der Internetservice-Plattform zur Anwendung.
8.3.10 Ergebnis und Kundennutzen
Die internetbasierte Logistikanalyse weist ein gutes Kosten-Nutzen-Verhältnis auf. Durch einfachen Zugang über das Internet, Selbstadministration der Anwender, Nutzung vorhandener
Unternehmensdaten, kleine Veränderungsnotwendigkeit an vorhandenen Informationssystemen
erschließen sich folgende Nutzenpotenziale für die Produktionslogistik: Durchlaufzeitverkürzungen,
Erhöhung des Kundenservicegrades sowie Bestandsabsenkung. Im Rahmen der Logistikanalyse
werden die in Tabelle 8-8 genannten Kennzahlen ermittelt.
Abbildung 8-11 zeigt die Einstiegsseite des Mehrwertdienstes, welche nach dem Hochladen der
Daten zur Verfügung steht.
Der Anwender hat mit diesem Mehrwertdienst ein Werkzeug an der Hand, das hilft, die Materialflusslogistik kontinuierlich zu überwachen und zu analysieren. Der Mehrwertdienst zeigt dadurch
Verbesserungspotenziale auf und hilft, frühzeitig geeignete Maßnahmen zu ergreifen. Für jeden
der Kenngrößenbereiche Durchlaufzeit, Auftragszeitstruktur, Leistung, Bestand und Termineinhaltung werden eigene Auswertungen generiert und die Ressourcen absteigend anhand der
jeweiligen Kenngröße sortiert.
Klasse
Analyse
- 191 -
Bemerkung
Auftragszeitstrukturkennzahlen
mittlere Auftragszeit
Summe der Auftragszeiten (Rüstzeit und Einzelzeiten) gemittelt über die
Anzahl der im Bezugszeitraum abgearbeiteten Arbeitsgänge
Variationskoeffizient
der Auftragszeit
Standardabweichung der Auftragszeit bezogen auf die mittlere Auftragszeit
Durchlaufzeitkennzahlen
mittlere Reichweite
Mittlerer Bestand dividiert durch die mittlere Leistung des Arbeitssystems
im Betrachtungszeitraum. Die mittlere Reichweite gibt also an, wie lange
der Arbeitsvorrat der betrachteten Ressource vorhält.
mittlere Durchlaufzeit
Die Durchlaufzeit für einen Arbeitsgang, die Zeitspanne zwischen Ankunft
an der betrachteten Ressource und Beendigung des Arbeitsgangs. Die
mittlere Durchlaufzeit ist die gemittelte Durchlaufzeit über alle bearbeiteten
Arbeitsgänge an einer Ressource für einen bestimmten Zeitraum.
Variationskoeffizient
der Durchlaufzeit
Standardabweichung der Durchlaufzeit bezogen auf die mittlere Durchlaufzeit
berechnete mittlere
Durchlaufzeit
Theoretische Durchlaufzeit, die sich bei einer auftragszeitunabhängigen
Abarbeitungsreihenfolge (FIFO) ergibt. Diese dient als Vergleichsgröße.
mittlere gewichtete
Durchlaufzeit
Summe aus den Produkten der arbeitsgangbezogenen Durchlaufzeit und
der arbeitsgangbezogenen Auftragszeit bezogen auf die Summe der Auftragszeiten. Die mittlere gewichtete Durchlaufzeit wird für einen Betrachtungszeitraum und eine Ressource berechnet und sagt aus, wie groß
die mittlere Durchlaufzeit für eine Auftragszeiteinheit ist.
Leistungskennzahlen
mittlere Leistung
Summe der im Betrachtungszeitraum fertig gemeldeten Arbeitsgänge bezogen auf die Länge des Betrachtungszeitraums
Anzahl Aufträge
Anzahl der im Betrachtungszeitraum zurückgemeldeten Arbeitsgänge
Bestandskennzahlen
mittlerer Bestand
Summe der zugegangenen Arbeitsinhalte (Auftragszeiten der zugegangenen Aufträge) abzüglich der Summe der fertig gemeldeten
Arbeitsinhalte bezogen auf die Länge des Betrachtungszeitraums
Anzahl Bestand
mittlere Anzahl der Aufträge in der Ressource, d. h., Anzahl der im Betrachtungszeitraum zugegangenen Aufträge abzüglich der Summe fertig
gemeldeter Aufträge
relativer Bestand
Mittlerer Bestand bezogen auf den idealen Mindestbestand. Der ideale
Mindestbestand ergibt sich aus der Summe der quadrierten Auftragszeiten
dividiert durch die Summe der Auftragszeiten. Im Fall des idealen Mindestbestands besteht der Bestand an einer Ressource nur aus dem in Bearbeitung befindlichen Auftrag; ein neuer Auftrag kommt an der Ressource
dann an, wenn der zuvor bearbeitete Auftrag die Ressource verlässt.
relative Terminabweichung
Differenz zwischen Ist-Durchlaufzeit und Soll-Durchlaufzeit. Entspricht der
Differenz der Terminabweichung im Abgang abzüglich der Terminabweichung im Zugang.
Standardabweichung
der relativen Terminabweichung
berechnete Standardabweichung der relativen Terminabweichung
relative Terminabweichung im Abgang
Ist-Fertigtermin minus Soll-Fertigtermin
Durchlaufzeit
Fertigtermin minus Starttermin, d. h., Ist-Starttermin des ersten Arbeitsgangs minus Ist-Fertigtermin des letzten Arbeitsgangs
Auftragszeit
Summe der Auftragszeiten aller Arbeitsgänge des Auftrags. Die Auftragszeit pro Arbeitsgang ist die Vorgabezeit, die sich aus der Rüstzeit und der
Summe der Einzelzeiten ergibt.
Terminabweichungskennzahlen
Kennzahlen zu
den Aufträgen
Tabelle 8-8: Berechnete logistische Kenngrößen
Abbildung 8-11: Benutzeroberfläche der internetbasierten Logistikanalyse
- 192 -
- 193 -
Abbildung 8-12: Auswertungsmöglichkeiten am Beispiel der Durchlaufzeit
8.3.11 Ausblick
Als erfolgskritisch hat sich bei diesem Mehrwertdienst das Vertrauensverhältnis zwischen Dienstleister und Dienstnutzer herausgestellt. In allen durchgeführten Projekten hatten die Dienstnutzer
nach anfänglicher Euphorie und positiver Testphase Bedenken, ihre sensiblen Daten kontinuierlich
an Dritte zu senden. Dabei kam von allen Unternehmen der Wunsch auf, die Services im lokalen
Intranet betreiben zu wollen. Die geschaffene Infrastruktur lässt sich auch im Intranet des Kunden
betreiben, allerdings hat dann der Dienstleister keinen Einblick mehr in die Gegebenheiten beim
Kunden. Der Hauptnutzen des Dienstes – die kontinuierliche Kundenbetreuung und -beratung
durch den Dienstbetreiber – ist in dieser Konstellation nicht mehr gegeben1.
1
Vgl. /Sihn-2002a/Sihn-2002c/Sihn-2001e/Löff-2001/.
- 194 -
8.4 Bewertung der Anwendungsbeispiele
Die in den Kapiteln 8.2 und 8.3 vorgestellten Anwendungsbeispiele adressieren völlig unterschiedliche Anwendungsfälle aus unterschiedlichen Lebenszyklusabschnitten eines Produktionssystems.
Während die virtuelle Anlagenprojektierung vor der Entstehung einer physischen Anlage zur Anwendung kommt, greift die internetbasierte Logistikanalyse erst dann, wenn die ursprünglichen
Konzepte und Produktionssysteme den sich veränderten Anforderungen nicht mehr standhalten.
Unter Umständen ist ein Ergebnis der Logistikanalyse, dass man neue Produktionssysteme benötigt, die es zu konfigurieren gilt.
In beiden Anwendungsbeispielen wurden jeweils nur Teilelemente des gesamten Vorgehensmodells dargestellt. Ein Grund hierfür liegt darin, dass der Autor versucht hat, Wiederholungen von
weniger wichtigen Gegebenheiten zu vermeiden. Alle Dienste nutzen z. B. die Internetbasisdienste, verfügen über Logging-Mechanismen etc. Diese Aspekte tragen jedoch nichts
Wesentliches für das Vorgehensmodell bei, sind aber zum Konzeptnachweis in der Praxis notwendig. Der wichtigere Grund, nicht alle Aspekte des Vorgehensmodells zu erwähnen, liegt aber
darin, dass nicht alle Aspekte für jeden Dienst gleichermaßen relevant sind. Z. B. besteht die Anwendungsarchitektur der internetbasierten Logistikanalyse im Kern aus einer Komponente, in
welcher die Algorithmen des Trichtermodells implementiert sind. Dementsprechend trivial ist die
Anwendungsarchitektur.
Teilweise wurde in den Anwendungsbeispielen von den in Kapitel 7 empfohlenen Konzepten abgewichen. Als Beispiel sei der Rich-Client zur Anlagenkonfiguration genannt. Dies ist kein Widerspruch zum Vorgehensmodell, sondern soll aufzeigen, dass das Vorgehensmodell einen Rahmen
liefert, von dem beim Vorliegen von belegbaren Gründen auch Ausnahmen zulässig sind. Im
konkreten Fall hätte man ansonsten keinen Mehrwertdienst realisieren können. Das Abrücken von
der empfohlenen Vorgehensweise hat in der Regel Auswirkungen, die konzeptionell berücksichtigt
werden müssen. Beispielsweise muss aufgrund des Offline-Konzepts sichergestellt sein, dass die
Versionen von Client und Server stets kompatibel sind.
Beide Anwendungsbeispiele stammen aus dem Umfeld der Fabrik- und Logistikplanung. Diese
Anwendungsbeispiele wurden gewählt, da dem Autor dieses Themenfeld aus einer Vielzahl von
Projekten mit Industriepartnern bekannt ist und er im Verbundforschungsprojekt E-Industrial
Services in dieser Domäne tätig war. Im Projekt E-Industrial Services wurden von anderen
Projektpartnern Dienste geschaffen, welche die Personalschulung1, die vorausschauende Wartung
und Instandhaltung2 sowie die mandantenfähige Prozesskostenrechnung von Logistiksystemen3
zum Gegenstand haben. Wenngleich diese Dienste ohne Nutzung des beschriebenen
Vorgehensmodells erzeugt wurden, basieren sie dennoch auf denselben architektonischen
Prinzipien. Eine Übertragbarkeit in diese Anwendungsfelder ist demnach möglich. Entsprechende
Mehrwertdienste
wurden
konzipiert,
in
der
Praxis
validiert
und
veröffentlicht.
1
2
3
Dieser Mehrwertdienst entstand unter Federführung des Fraunhofer IFF zusammen mit der MAN Roland Druckmaschinen AG. Vgl. /Blüm-2003/.
Dieser Mehrwertdienst entstand im Rahmen des Projekts E-Industrial Services unter Federführung der FraunhoferInstituten IPK und IPT zusammen mit der TRAUB Drehmaschinen GmbH & Co. KG. Vgl. /Uhlm-2006/Grau-2003c/.
Dieser Mehrwertdienst entstand unter Federführung des Fraunhofer IML, Dortmund. Vgl. /Kuhn-2005/.
9 Zusammenfassung, Grenzen und Ausblick
Es ist unmöglich, in die Zukunft zu sehen,
und es ist gefährlich, es nicht zu tun.
Sir Henry Deterding
Gründer und Hauptaktionär von Shell
9.1 Zusammenfassung
Paradigmenwechsel: Der industrielle Wettbewerb im Maschinen- und Anlagenbau steht im
Zeichen eines Paradigmenwechsels. Die Branche erzielt zwar durch den Maschinen- und Anlagenverkauf hohe Umsätze; die Gewinne werden jedoch bei vielen Produktherstellern durch die
dazugehörigen lukrativen Dienstleistungen erzielt.
In zunehmendem Maße versuchen daher die Investitionsgüterhersteller, durch die Bündelung von
Sach- und Dienstleistungen, kombinierte Angebote – sogenannte hybride Servicedienstleistungen
– anzubieten. Charakteristisch für solche hybriden Lösungen ist die intelligente Verzahnung
zwischen materiellem Produkt, Software und Dienstleistung. Die zunehmende Substitution
mechanischer Komponenten durch Software verstärkt diesen Trend noch.
Anforderungsgerechte, am Kundennutzen orientierte, hybride Dienstleistungspakete können
produktbezogene Preisvorteile internationaler Mitbewerber in den Hintergrund drängen. Die enge
Verzahnung von Produkt, Software und Dienstleistung führt ferner dazu, dass die Leistungsangebote nur noch schwer voneinander zu entkoppeln sind und nur von den Investitionsgüterherstellern selbst angeboten werden können.
Problem: Industrielle Dienstleistungen werden bisher überwiegend vor Ort erbracht. Die Anlagenbetreiber fordern jedoch, dass diese Dienstleistungen mit garantierten Reaktionszeiten weltweit
angeboten und erbracht werden müssen. Die Präsenz vor Ort stellt vor allem für die überwiegend
mittelständisch geprägten, deutschen Maschinen- und Anlagenbauer eine finanzielle und
personelle Herausforderung dar.
Investitionsgüter mit einem hohen Softwareanteil bieten prinzipbedingt eine gute Plattform für die
Erbringung IT-basierter Dienstleistungen, die auch über große Distanzen hinweg in die Zielmärkte
deutscher Maschinen- und Anlagenbauer exportiert werden können.
IT-basierte Dienstleistungen, zu denen auch die in der vorliegenden Arbeit näher betrachteten
Mehrwertdienste gehören, werden bislang weitgehend in Form von Einzelprojekten konzipiert und
realisiert. Durch den Mangel an geeigneten Vorgehensweisen und fehlenden Plattformstrategien
erfolgt die Dienstleistungsentwicklung häufig ineffizient und teilweise am Anwenderbedarf vorbei.
Die Folge: hoher Aufwand in der Entwicklung und Wartung von Diensten, zu lange Umsetzungszeiträume zwischen Ideenfindung und Inbetriebnahme sowie qualitativ und technisch nicht ausgereifte Gesamtsysteme.
Zusammenfassung, Grenzen und Ausblick
- 196 -
Ansatz: Eine spezifische Problemstellung solcher IT-basierter Dienstleistungen liegt in den Interdependenzen zwischen der Dienstleistung und der Software. Während die Spezifikation der
Dienstleistung in der Regel Einflüsse auf die Spezifikation der Software hat, ist auch umgekehrt die
Machbarkeit der Softwarelösung bei der Dienstleistungskonzeption zu berücksichtigen. Es bedarf
demnach einer Synchronisierung des Service Engineerings und des Software Engineerings. Das
Erbringen von Dienstleistungen, die aus einer Kombination von Software und Dienstleistung bestehen, setzt demnach voraus, dass ein Entwicklungsprozess sowohl für die Dienstleistung wie
auch für die benötigte Software stattfindet.
Ziel der Arbeit: Ziel der vorliegenden Arbeit war die Definition und Ausarbeitung einer integrierten
Entwicklungsmethodik zur Gestaltung internetbasierter Mehrwertdienste. Das erarbeitete
Vorgehensmodell soll die Gestaltung internetbasierter Dienste erleichtern, indem es ein
integriertes Vorgehen in Bezug auf die Aspekte des Projektmanagements, des Service
Engineerings und des Software Engineerings aufweist und diese vor dem Hintergrund der technologischen Möglichkeiten und Internetstandards in ein gesamtes Vorgehensmodell überführt.
Service Engineering und Software Engineering ergänzen sich dabei und werden unter dem Begriff
E-Service Engineering zusammengefasst. Das geschaffene Vorgehensmodell ist dabei so allgemeingültig formuliert, dass es für eine möglichst große Bandbreite internetbasierter Dienstleistungen angewendet werden kann.
Vorgehensweise: Kapitel 1 führt in das Thema ein. Kapitel 2 dient der Einordnung der Arbeit und
zur Festlegung des Untersuchungsbereichs. Kapitel 3 beschreibt die Anforderungen an die Gestaltung von Mehrwertdiensten. Kapitel 4 widmet sich dem Stand der Technik. Hier werden unter
anderem konventionelle Vorgehensmodelle des Software Engineerings und Service Engineerings
beschrieben. Kapitel 5 befasst sich mit der Beschreibung des grundsätzlichen Lösungsansatzes
sowie der Methodik, die dieser Arbeit zugrunde liegt. Kapitel 6 behandelt die zur Diensterbringung
notwendigen Informations- und Kommunikationstechnologien. Kapitel 7 bildet den Kern der Arbeit.
Hier wird das Vorgehensmodell zur Gestaltung internetbasierter Mehrwertdienste für den
Maschinen- und Anlagenbau beschrieben. Kapitel 8 gibt einen Einblick in die realisierten Anwendungsprojekte und bewertet das Vorgehensmodell.
Ergebnis der Arbeit: Im Rahmen der Ausarbeitung wurde eine standardisierte Vorgehensweise
entwickelt, welche alle relevanten Aspekte von der Ideengenerierung bis zur Inbetriebnahme internetbasierter Mehrwertdienste abdeckt. Das Vorgehensmodell erhöht damit die Projekttransparenz
und verbessert deren Planbarkeit. Planungsabweichungen und Risiken werden bereits frühzeitig
erkannt. Prozesse lassen sich besser steuern und das Projektrisiko wird insgesamt eingedämmt.
Anhand der beiden vorgestellten Anwendungsbeispiele, virtuelle Anlagenprojektierung und internetbasierte Logistikanalyse, und in den assoziierten Pilotprojekten mit Industriepartnern konnte die
Entwicklungsmethodik und das entwickelte Framework erfolgreich erprobt und evaluiert werden.
Übertragbarkeit: Das erarbeitete Vorgehensmodell ist prinzipiell auf beliebige Klassen von Mehrwertdiensten übertragbar. Im Verbundforschungsvorhaben E-Industrial Services wurden von den
beteiligten Partnern insgesamt 12 Mehrwertdienste konzipiert und auf einer gemeinsamen Internetservice-Plattform realisiert. Zum Zeitpunkt der Realisierung war das hier beschriebene
Vorgehensmodell noch nicht fertiggestellt, jedoch sind Teilaspekte aus den Arbeiten der Projektpartner in diese Arbeit eingeflossen und umgekehrt.
- 197 -
9.2 Grenzen
9.2.1
Vorgehensmodelle
Das erarbeitete Vorgehensmodell beschreibt einen Prozess zur Erstellung von Mehrwertdiensten.
Es gibt damit einen Rahmen vor, in dem ein Projekt geordnet ablaufen kann. Vorgehensmodelle
können den Erfolg eines Projektes jedoch nicht garantieren. Die Auswahl und Konzeption geeigneter Dienste, die sowohl wirtschaftlich erbracht werden können als auch vom Markt angenommen werden, bleibt Aufgabe der Projektbeteiligten. Darüber hinaus muss auch sichergestellt
sein, dass die Konzepte qualitativ hochwertig in Software umgesetzt werden. Dies ist bei
komplexen IT-Projekten nicht immer einfach, wie die Praxis z. B. bei der Umsetzung der fortschrittlichen Ideen des Toll-Collect-Systems gezeigt hat. Die Qualität des Softwareprodukts beziehungsweise der zu erstellenden Dienste bleibt primär von der Qualifikation der Projektbeteiligten, ihrer
Teamfähigkeit und ihrem gesunden Menschenverstand abhängig.
9.2.2
Komponentenbasierte Software
Das Vorgehensmodell favorisiert die Verwendung von Softwarekomponenten zum Aufbau der
Internetservice-Plattform. Die komponentenbasierte Softwareentwicklung hat nicht nur positive
Aspekte. Die komponentenbasierte Softwareentwicklung stellt hohe Anforderungen an die Entwickler und Nutzer von Komponenten. Bei der Spezifikation muss von vornherein auf die Wiederverwendbarkeit geachtet werden. Dies erfordert erfahrene Entwickler und einen Mehraufwand an
Zeit und Kosten im aktuellen Projekt, der sich erst in späteren Projekten auszahlt. Einige Autoren
behaupten sogar, dass wiederverwendbare Komponenten erst dann entwickelt werden sollten,
wenn das Problem bereits mehrmals aufgetreten und gelöst worden ist. Nur in einem solchen Fall
wäre genügend Erfahrung vorhanden, um Komponenten in der geeigneten Granularität und mit
stabilen Schnittstellen entwickeln zu können. Obwohl die Vorteile sich eher mittel- und langfristig
auswirken und kurzfristig die negativen Effekte nicht auszuschließen sind, hat sich für den Autor
die komponentenbasierte Softwareentwicklung im Kontext der Arbeit bewährt.
9.2.3
Integration des Vorgehensmodells mit dem Produktentwicklungsprozess
Der Dienstleistungsträger des beschriebenen Vorgehensmodells ist eine Maschine oder Anlage. In
dieser Arbeit wurde stillschweigend vorausgesetzt, dass der Dienstleistungsträger bereits existiert.
Falls dies nicht gegeben ist, muss das hier erarbeitete Vorgehensmodell mit dem Produktentwicklungsprozess des Dienstleistungsträgers harmonisiert und verzahnt werden. Aufgrund der
Phasenorientierung des Vorgehensmodells sollte dies kein Problem darstellen.
Heutige internetbasierte Dienstleistungen generieren als Add-on Mehrwerte an Maschinen und Anlagen. Bislang wurden nach Kenntnis des Autors jedoch noch keine Maschine oder Anlagen entwickelt, bei denen internetbasierte Dienstleistungen elementare Kernfunktionen abdecken. Es ist
jedoch denkbar, dass zukünftig z. B. die Steuerung oder die Insitu-Qualitätskontrolle einer
Maschine als Internetdienst genutzt wird. Die Folge wäre, dass völlig neue Maschinenkonzepte
und Preismodelle entstehen würden.
- 198 -
9.3 Ausblick
9.3.1
Hybride Produkte
Der aktuelle Stand der integrierten Produkt-, Software- und Dienstleistungsforschung weist heute
noch Lücken auf. Es fehlen empirische Grundlagen der hybriden Wertschöpfung insgesamt sowie
angepasste, fundierte Methoden, Modelle und Werkzeuge zur Gestaltung, Erbringung, Vermarktung und zum Life Cycle Management kombinierter Produkt- und Dienstleistungsbündel.
Das Ziel dieser Arbeit war, einen fundierten Überblick über den Stand der Technik zu geben sowie
ein Vorgehensmodell zur Gestaltung internetbasierter Mehrwertdienste für den Maschinen- und
Anlagenbau zu entwickeln. Das gesamte Themenfeld ist jedoch bei Weiten noch nicht erforscht,
wie folgende Ansammlung von offenen Themen zeigt:

theoretische und empirische Grundlagen hybrider Wertschöpfung

Strategien für hybride Wertschöpfung

ökonomische Bedeutung hybrider Lösungen

organisatorische Gestaltung hybrider Lösungen

Anwenderakzeptanz hybrider Lösungen für unterschiedliche Branchen und Lösungen
9.3.2
Technologischer Fortschritt
Der technologische Fortschritt der Informations- und Kommunikationstechnik ist enorm. Das
Mooresche Gesetz1 aus dem Jahr 1975 sagt aus, dass sich die Anzahl an Transistoren auf einem
Prozessor alle achtzehn Monate verdoppelt. Das „Gesetz“ hat bis heute Gültigkeit. Der exponentielle Technologiefortschritt im Bereich der integrierten Schaltung bildet eine wesentliche
Grundlage der digitalen Revolution, die den beschriebenen Strukturwandel hin zur Informationsgesellschaft ausgelöst hat. Alle beschriebenen Technologien unterliegen daher einem ständigen
Wandel. Wir stehen demnach erst am Anfang der technischen Möglichkeiten internetbasierter
Mehrwertdienste.
Die Digitalisierung der Wertschöpfung basiert auf Modellen, die der Digitalen Fabrik beziehungsweise dem Product-Life-Cycle zugeordnet werden. Die zunehmende horizontale und vertikale Verbreitung solcher digitaler Produkt-, Prozess- und Ressourcenmodelle schafft ständig neue Voraussetzungen, um Dienstleistungen an Maschinen und Anlagen zu erbringen. Das ist zunächst nichts
Neues: So ist beispielsweise die Roboter-Offlineprogrammierung im Karosserierohbau seit mehr
als einem Jahrzehnt eine etablierte Dienstleistung, die zunächst ausschließlich virtuell, d. h. ohne
Vorhandensein der physischen Bleche oder Roboterhardware, erbracht wird. Die heute verfügbaren Übertragungsbandbreiten machen es allerdings inzwischen möglich, solche Dienstleistungen global zu erbringen. Die Informationstechnik hat die Ausgangsvoraussetzungen geschaffen, um eine globale Arbeitsteilung zu ermöglichen, die sich an den Kernkompetenzen der
Beteiligten – aber auch an globalen Kostenstrukturen orientieren.
1
Das Mooresche Gesetz (engl. Moore's Law) ist kein wissenschaftliches Naturgesetz, sondern basiert auf empirischen
Beobachtungen.
9.3.3
- 199 -
Kulturelle Herausforderungen
Software- und Dienstleistungsentwickler stammen häufig aus unterschiedlichen Fachdisziplinen,
sodass andere Denkweisen, Perspektiven und Sprachwelten vorherrschen. In der beruflichen
Praxis konnte der Autor häufig erleben, dass Personen aus verschiedenen Fachdisziplinen ein und
dieselbe Sachlage völlig unterschiedlich empfinden und darstellen. Während Mitarbeiter aus dem
IT-Umfeld vorwiegend von Problemen und nicht vollständigen implementierten Funktionen berichten, beschäftigen sich die Dienstleistungsentwickler mit Visionen, ohne die technische Machbarkeit zu prüfen beziehungsweise ohne zu wissen, ob die Ideen überhaupt umsetzbar sind. Da
neben einem integrierten Vorgehensmodell die gute Zusammenarbeit der Fachdisziplinen eine
Erfolgsvoraussetzung darstellt, ist die Gestaltung von internetbasierten Dienstleistungen nicht nur
als eine projekt- oder prozessbezogene, sondern auch als eine kulturelle Herausforderung zu begreifen.
9.3.4
Mehr Mut zu Innovationen
Ein nachhaltiges Problem internetbasierter Mehrwertdienstleistungen liegt im grundsätzlichen Verständnis von Dienstleistungen und speziell IT-Dienstleistungen. Solange solche Dienstleistungen
nicht als ein Produkt von gleichem Rang wie Sachgüter angesehen werden, fehlt die Basis für
deren Umsetzung. Ein Problem internetbasierter Mehrwertdienstleistungen liegt demnach nicht in
dem Erkenntnisstand der Forschung, sondern in dem mangelnden Willen der Industrie, die gewonnenen Erkenntnisse in die Praxis umzusetzen.
Interessanterweise besteht jedoch weitgehend Konsens darin, dass eine Exportnation wie
Deutschland Beschäftigung und Wohlstand nur dann sichern kann, wenn ihre Produkte und
Dienstleistungen auf den Weltmärkten konkurrenzfähig sind. Ein Preiswettbewerb mit z. B. Staaten
aus Asien ist nicht zu gewinnen. Und Kostensparen allein macht die Unternehmen im Hochlohnland Deutschland nicht wettbewerbsfähig. Der deutsche Maschinen- und Anlagenbau muss der
Konkurrenz aus den Niedriglohnländern Innovationen entgegensetzen. Für einzigartige Produkte
und Dienstleistungen, die im Idealfall als schwer kopierbare hybride Produkte angeboten werden,
sind die Käufer auch bereit, einen höheren Preis zu bezahlen.
Die im Rahmen dieser Arbeit vorgestellten Konzepte liefern eine ganzheitliche Orientierungshilfe
für das Themenfeld der internetbasierten Mehrwertdienste. Die technologische Basis ist vorhanden, Pilotprojekte mit Industriepartnern haben die Nutzenpotenziale gezeigt. Nun müssen die
Konzepte in die Praxis umgesetzt werden. Der Autor möchte daher die Unternehmen aus dem
Maschinen- und Anlagenbau ermuntern und ermutigen, über eigene elektronische Dienstleistungen nachzudenken, diese schnell und qualitativ hochwertig zu konzipieren und zu entwickeln, um diese schließlich profitabel am Markt zu platzieren. Der Autor hofft, mit dieser Arbeit
und in den assoziierten Projekten einen kleinen Betrag hierfür geleistet zu haben.
10 Summary, Constraints and Outlook
A procedure model for the development of web-based services for mechanical engineering,
plant engineering and construction
10.1 Summary
Paradigm shift: Industrial competition in the mechanical engineering, plant engineering and construction is experiencing paradigm shift. The industry admittedly achieves high revenues through
the hardware sales; however, the profits are made through appropriate lucrative services. To increase profit, the companies therefore try to combine offers – so called hybrid services – by bundling hardware and service. The intelligent combination of product, software and service is characteristic of such hybrid solutions. The increasing substitution of mechanical components through
software reinforces this trend.
Customer-benefit oriented, hybrid service packages can offset price advantages of competitors.
The well thought out combination of product, software and service are then offered exclusively as a
package. And only the investment goods manufacturers themselves can offer such hybrid service
packages.
Problem: Industrial services are produced and delivered mainly on site. The plant and machine
operators demand these services with guaranteed reaction times world wide. A global presence on
site is challenging both financially and in terms of personnel, especially for the predominantly middle class German machine builders.
Modern machinery uses increasingly more electronic system controls. These machines provide a
good platform to receive IT-based services. These IT-based services can be exported over long
distances to international customers of German machine builders.
IT-based services and especially the examined value-added-services are presently developed and
realized in customer specific projects. Lacking suitable procedure models as well as product platform strategies, service development is inefficient and not focused on customer demands. The
consequence: each value-added-service must be individually developed resulting in higher costs,
more complex maintenance, and long implementation periods between service creation and rampup as well as systems which are qualitatively and technically not fully developed.
Approach: A specific problem of such IT-based services is the interdependency between the service and the software which is necessary to deliver the service. Therefore service engineering and
software engineering must be synchronized. The delivery of hybrid services presupposes that the
development process of software and service is linked.
Objective: The objective of this thesis was to create an integrated procedure model to design and
develop web-based value-added services. This model should facilitate the formation of web-based
services by simultaneously taking into account project management, service engineering and software engineering. In addition it’s necessary to consider both technological possibilities and internet
standards. Service engineering and software engineering are summarized under the term EService Engineering. The developed procedure is intended to be universal so it can be applied for
a broad range of different web-based services.
Summary, Constraints and Outlook
- 201 -
Proceeding: Chapter 1 introduces the subject of the thesis. Chapter 2 defines the scope of the
analysis. Chapter 3 describes the requirements for the formation of web-based value added services. Chapter 4 explains the current state-of-the-art. Among other things conventional develop
procedures for software engineering and service engineering are examined. Chapter 5 is a brief
synopsis of the fundamental approach of the thesis and the used methodology. Chapter 6 describes the information and communication technology which can be used to deliver web-based
services through the internet. Chapter 7 contains the core of the work. Here, the developed procedure is described to specify, implement and deploy web-based value-added-services for mechanical engineering, plant engineering and construction. Chapter 8 gives an insight into realized
projects and examines the developed procedure.
Achievement: The outcome of the thesis is a standardized procedure model which covers all relevant aspects of IT-service, starting with service creation, continuing through the ramp-up phase,
finishing with competent and efficient availability of service. This procedure increases the transparency of projects so that they are easier to schedule. Deviations from projected cost, time and quality can be recognized earlier and avoided. The developed methodology and IT-Framework was
tested and evaluated successfully during several pilot projects with industrial partners. In this paper
two application examples are described in detail: virtual plant engineering and web-based logistics
analysis.
General applicability: The developed procedure model can easily be transferred onto other webbased value-added-services. Within the Fraunhofer Alliance joint research project called EIndustrial Services, 12 different value-added-services were realized from the involved partners on a
common internet-service-platform. During this project the described procedure model was not fully
completed. However, some ideas and aspects from the model where used from the project partners and vice versa.
10.2 Constraints
10.2.1 Procedure model
The procedure model explains how to design value-added-services. It serves as a framework in
which a project can run. It must, however, be said that procedure models cannot guarantee the
success of a project. The selection and conception of suitable services which can be designed and
delivered economically and which will also be accepted from the market remains a task for the
project team.
In addition, it’s important to make sure that the services ideas are properly specified in order to be
consequently implemented into high quality software. This is not always easy with complex ITprojects as was shown e.g. in the Toll-Collect-System project, where an innovative and progressive
idea proofed completely untenable in its realization. The success of the software product depends
on the quality of the project team and their ability to work together.
- 202 -
10.2.2 Component-Based Software
The component based software development has many but not only positive aspects. During the
software specification, reusability must continuously be tracked from the outset. The development
of component-based software requires skilled developers and an increased expenditure of time
and costs. This pays off only in later projects.
Some authors even claim that reusable components should only be developed, if the problem occurred already several times and has been solved by using conventional software development
techniques. Otherwise, the experience wouldn’t be adequate to develop suitable components with
the right granularity and stable interfaces. Although the advantages might pay off in the medium or
long term and negative effects in short term are possible, the component based software development stands the test for this author.
10.2.3 Integration of the Web-Service Generating Procedure Model with the Product Development Process
The carrier of the described web-service generating procedure model is a machine. This thesis is
based on the idea that the machine already exists. Should this not be so, the web-service generating procedure model must be synchronized with the product development process of the hardware.
Due to the modular step-by-step procedure model this should not be a problem.
Today web-based value-added-services only provide add-on functionalities for machines. At
present, there are – according to the knowledge of the author – no machines on the market which
principally use web-based value-added-services in their main functions. It is however possible that
in the future, numeric control or in-situ quality control of a machine could use web-service to reduce investment costs or to enhance quality. As a consequence, completely new machine concepts and price models could evolve.
10.3 Outlook
10.3.1 Hybrid products
The research on integrated product development, software development and service engineering
requires further improvement. Basic principles of hybrid value creation are missing. Consolidated
and reliable methods, models and tools for the development, delivery and commercial exploitation
of hybrid products are also needed. Hybrid products are more generally a marketing term then an
actual topic for research.
The goal of this thesis was to give a well founded overview about procedure models and software
technologies for value-added-service-design. The entire subject area is not explored yet, as seen
in the following accumulation of open topics:

theoretical and empirical basis of hybrid value creation

strategies for hybrid value creation

economic relevance of hybrid solutions

organizational configuration of hybrid solutions

user acceptance of hybrid solutions in different industries
- 203 -
10.3.2 Technological progress
Progress in the field of information and communication technology is enormous. Moore's Law predicted in 1975 that the number of transistors on a processor would double every eighteen months.
Moore's Law is still valid. This ongoing progress in integrated circuits forms the basis of the digital
revolution that led to structural change into the modern information era. All described technologies
therefore are subject to a continuous change. We are only now beginning to see the technical possibilities of web-based value-added-services.
The creation of value-added-services is based on digital models, which are assigned to Product
Life Cycle Management (PLM). The increased use of horizontal and vertical digital product-,
process-, and resource-models constantly creates new prerequisites and possibilities in order to
deliver services for machines. For example, robot-off-line-programming has been an established
service in the body-in-white area for more than a decade. These services are carried out without
any robotic hardware or physical materials. Today the communication bandwidth has reached a
high level making it possible to deliver such services globally. Information and communication
technology has created the prerequisites to enable global collaboration. Locally needed tasks can
be produced and provided globally using global cost structures.
10.3.3 Cultural challenge
Software developers and service developers often have different skills and work on different technical disciplines and departments. Therefore, they think differently and use different language. In
general, software developers talk about problems with unclear specifications. Service developers
talk about their visions without considering how to realize the ideas or even knowing if the ideas
are technically feasible.
Success is above all achieved through good collaboration between the different disciplines. An efficient procedure model can help but is not the only key to success. The successful creation of
web-based value-added-services is not only a project or process driven affair but can also be seen
as a cultural challenge.
10.3.4 Desire for innovation
Consumer perception continues to be a problem for web-based value-added-services. As long as
such services are not valued at the same level as investment goods the impetus is missing for their
realization. A persisting problem is not only the advances in research but the reticence of industry
to put the won knowledge into practice. However, an export nation such as Germany can only secure employment and affluence if its products and services are competitive in world markets. We
cannot win a typical price competition with countries from Asia e.g. Cost saving alone will not allow
businesses in Germany to remain competitive. The machine builders must counter the competition
from low wage countries with ever increasing innovations. Buyers are willing to pay a higher price
for unique products and services, which can be offered as hybrid products.
Concepts introduced in this work provide an integral guide for web-based value-added-services.
The technological basis exists. Pilot projects with industrial partners showed the benefit potentials.
Now, the concepts must be put into practice. The author would therefore like to encourage the machine building industry to consider offering their own value-added-services and to develop these
quickly and in high quality in order to place these profitably on the market. The author hopes that
this work and associated projects make a small contribution to this development.
11 Literaturverzeichnis
ADL-2001
Arthur D. Little, Inc.:
Service Innovation: Produktbegleitende Services: Status-Stars-Strategien.
Wiesbadener Unternehmergespräche, 15.-16. November 2001.
Wiesbaden, Arthur D. Little International, 2001
ADL-2004
Arthur D. Little, Inc.:
Service Innovation: Ergebnisverbesserung durch zielgerichtete Servicestrategien
und -entwicklungen in der produzierenden Industrie.
München: Arthur D. Little International, 2004
Aldi-2006
Aldinger, Lars; Constantinescu, Carmen; Hummel, Vera; Kreuzhage, Rita; Westkämper, Engelbert:
Neue Ansätze im "advanced Manufacturing Engineering".
In: wt Werkstattstechnik 96 (2006), Nr. 3, S. 110-114
Back-2003
Backhaus, Klaus (Mitarb.); Erichson, Bernd (Mitarb.); Plinke, Wulff (Mitarb.);
Weiber, Rolf (Mitarb.):
Multivariate Analysemethoden: Eine anwendungsorientierte Einführung.
10., neu bearb. und erw. Aufl.
Berlin u. a.: Springer, 2003
Back-2006
Backhaus, Klaus, Voeth, Markus:
Industriegütermarketing. 8., überarb. Aufl.
München: Vahlen, 2006
Balz-2001
Balzert, Helmut:
Lehrbuch der Software-Technik - Bd. 1: Software-Entwicklung. 2. Aufl.
Heidelberg u. a.: Spektrum Akademischer Verlag, 2001
Band-2001
Bandow, Gerhard:
Mehrwert und Mehrwertdienste - Identifizierung, Systematisierung, Realisierung
am Beispiel logistischer Arbeitsmittel.
Dortmund: Verlag Praxiswissen, 2001
Zugl.: Dortmund, Univ., Diss., 2001
Baue-2001
Bauer, Herbert:
Unternehmensportale: Geschäftsmodelle, Design, Technologie. 1. Aufl.
Bonn: Galileo Press, 2001
Berg-2003
Berger, Ralph; Hohwieler, Eckhard:
Service Platform for Web-based Services for Production Systems.
In: Universität des Saarlandes / Lehrstuhl für Fertigungstechnik: Progress in
Virtual Manufacturing Systems: Proceedings. 36th CIRP International Seminar on
Manufacturing Systems, June 03-05, 2003, Saarbrücken, Germany.
Saarbrücken, 2003, S. 209-213
Literaturverzeichnis
- 205 -
Berg-2005
Berger, Ralf:
Sicherheitszentrierte Architektur für Internet-basierte Dienste im Maschinen- und
Anlagenbau.
Stuttgart: Fraunhofer IRB, 2005
Zugl.: Berlin, TU, Diss., 2005
Blüm-2003
Blümel, Eberhard; Salem, Waleed; Schenk, Michael:
Using Virtual Reality in In-Factory Training: Adding More Value to the Production
System.
BMBF-2004
Kreibich, Rolf; Oertl, Britta; Bundesminister für Bildung und Forschung (BMBF):
Erfolg mit Dienstleistungen. Innovationen, Märkte, Kunden, Arbeit: Beiträge der 5.
Dienstleistungstagung des BMBF am 10.-11. Dezember 2003, Berlin.
Stuttgart: Schäffer-Poeschel, 2004
BMBF-2006
Streich, Deryk (Hrsg.); Wahl, Dorothee (Hrsg.); Bundesminister für Bildung und
Forschung (BMBF):
Moderne Dienstleistungen: Impulse für Innovation, Wachstum und Beschäftigung.
Beiträge der 6. Dienstleistungstagung des BMBF am 30.-31. März 2006, Berlin.
Frankfurt/M.; New York: Campus Verlag, 2006
BMWi-2007
Bundesministerium für Wirtschaft und Technologie:
Monitoring Informationswirtschaft: 10. Faktenbericht. Juli 2007.
</http://www.bmwi.de/BMWi/Navigation/Technologie-und-Innovation
/Informationsgesellschaft /Informationswirtschaft/monitoring, did=210766.html/>,
letzter Abruf am: 01.05.2008
Boeh-1988
Boehm, Barry W:
A Spiral Model of Software Development and Enhancement.
In: IEEE Computer 21 (1988), Nr. 5, S. 61-72.
Brun-2003
Bruhn, Manfred:
E-Service: Das Management einer Erfolgskette.
In: Science Factory 5 (2003), Nr. 1, S. 1-4
Bürk-2001
Bürkner; Stephan:
Internetbasierter Service im Lebenszyklus komplexer Produkte.
Düsseldorf: VDI-Verlag, 2001 (Fortschritt-Berichte VDI, Reihe 2, Nr. 577)
Zugl.: Hannover, Univ., Diss., 2001
BSI-2005a
Bundesamt für Sicherheit in der Informationstechnik (BSI), Bonn:
BSI-Standard 100-1: Managementsysteme für Informationssicherheit. Vers. 1.0,
2005
</http://www.bsi.de/literat/bsi_standard/standard_1001.pdf/>, letzter Abruf am:
01.05.2008
BSI-2005b
BSI-Standard 100-2: IT-Grundschutz-Vorgehensweise. Vers. 1.0, 2005
01.05.2008
- 206 -
BSI-2005c
BSI-Standard 100-3: Risikoanalyse auf der Basis von IT-Grundschutz, Vers. 2.0,
2005
01.05.2008
BSI-2005d
IT-Grundschutz-Kataloge Standardwerk zur IT-Sicherheit, 2005
</http://www.bsi.de/gshb/deutsch/>, letzter Abruf am: 01.05.2008,
BSI-2006
E-Government-Handbuch. BSI-Schriftenreihe zur IT-Sicherheit, Band 11, 2006
</http://www.bsi.de/fachthem/egov/3a.htm/>, letzter Abruf am: 01.05.2008,
Bull-2006
Bullinger, Hans-Jörg (Hrsg.), Scheer, August-Wilhelm (Hrsg.):
Service Engineering, Entwicklung und Gestaltung innovativer Dienstleistungen.
2. vollst. überarb. u. erw: Aufl.
Capg-2005
Capgemini:
Studie IT-Trends 2005.
Berlin, 2005.
</http://www.de.capgemini.com/m/de/tl/IT-Trends_2005.pdf/>, letzter Abruf am:
01.05.2008
Capg-2006
Capgemini:
Berlin, 2006.
01.05.2008
Capg-2007
Capgemini:
Berlin, 2007.
01.05.2008
Chee-2001
Cheesman, John; Daniels, John:
UML Components - A Simple Process for Specifying Component-Based Software.
München: Addison-Wesley, 2001
Dani-2003
Daniel, Christian; Richter, Hendrik; Graupner, Tom-David:
Projektierung von Systemlösungen für die Isolierglasherstellung: Unter Nutzung
von Konfiguration, Simulation und 3D-Visualisierung.
In: wt Werkstattstechnik 93 (2003), Nr. 1/2, S. 27-30
Dani-2005
Daniel, Christian; Graupner, Tom-David; Ritter, Arno:
Virtuelle Anlagenkonfiguration: Modulare Produktionssysteme mit Werkzeugen
der Digitalen Fabrik kundenindividuell projektieren.
DIHK-2006
Deutscher Industrie- und Handelskammertag:
DIHK-Dienstleistungsreport - Ergebnisse der DIHK-Umfrage bei den Industrieund Handelskammern.
Berlin, 2006
- 207 -
DIN-75
Service Engineering - Entwicklungsbegleitende Normung für Dienstleistungen.
Berlin: Beuth, 1998 (DIN-Fachbericht, 75)
DIN-61508
Norm DIN EN IEC 62061 2005-10:
Sicherheit von Maschinen - Funktionale Sicherheit sicherheitsbezogener
elektrischer, elektronischer und programmierbarer elektronischer Steuerungssysteme
DIN-66001
Norm DIN 66001 1983-12:
Informationsverarbeitung; Sinnbilder und ihre Anwendungen.
DIN-69905
Norm DIN 69905 1997-05:
Projektwirtschaft - Projektabwicklung - Begriffe.
eIS-2007
Homepage des Verbundforschungsprojekts der Fraunhofer-Gesellschaft:
E-Industrial Services.
</http://www.e-industrial-services.de/>, letzter Abruf am: 01.05.2008
ENX-2007a
Homepage des European Network Exchange Konsortiums:
</http://www.enxo.com/>, letzter Abruf am: 01.05.2008
ENX-2007b
European Network Exchange Konsortium:
ENX Briefing Day 2007, Köln 07. Februar 2007
</http://www.enxo.com/_files/pdf/bd2007/index.php />, letzter Abruf am:
01.05.2008
Fähn-2004a
Fähnrich, Klaus-Peter (Hrsg.); van Husen, Christian (Hrsg.):
Entwicklung IT-basierter Dienstleistungen in der Praxis: Kurzstudie
Fähn-2004b
Fähnrich, Klaus-Peter:
Professionelle Entwicklung IT-basierter Dienstleistungen; Praxisforum 26. März
2004
Fraunhofer IAO, Stuttgart: Fraunhofer IRB, 2004
Fähn-2006
Fähnrich, Klaus-Peter:
Vorlesung: Engineering IT-basierter Dienstleistungen
Leipzig: Vorlesungsskript der Universität Leipzig, Sommersemester 2006.
</http://bis.informatik.uni-leipzig.de/de/Lehre/0506/SS/SE/>, letzter Abruf am:
01.05.2008
Fahr-1995
Fahrwinkel, Uta:
Methode zur Modellierung und Analyse von Geschäftsprozessen zur Unterstützung des Business Process Reengineering.
Paderborn, Univ., Diss., 1995.
Fett-2003
Fettke, Peter; Loos, Peter:
Model Driven Architecture (MDA).
In: Wirtschaftsinformatik 45 (2003), Nr. 5, S. 555–559
FIR-2005
Forschungsinstitut für Rationalisierung <Aachen>:
8. Aachener Dienstleistungs-Forum: Kernkompetenz Dienstleistungsqualität Entwicklung, Aufbau und Umsetzung in der Industrie. 08.-09. September 2005,
Aachen.
Aachen, 2005
- 208 -
FIR-2006
9. Aachener Dienstleistungs-Forum: Lean Services - Effiziente Strukturen für
erfolgreiche Dienstleistungsunternehmen. 05.-06. September 2006, Aachen.
Aachen, 2006
FIR-2007
10. Aachener Dienstleistungs-Forum: Service Innovation - Innovative Unternehmen bewegen Märkte. 05.-06. September 2007, Aachen.
Aachen, 2007
Fran-2000
Franke, H.-J.; Lux, S; Kochanowski, W.; Gamp, S.:
Internetbasierte Angebotserstellung für komplexe Produkte
In: Der Ingenieur im Internet – Erfolgreiche Anwendungen in der Industrie
Düsseldorf: VDI-Verlag, 2000, S. 67-74 (Fortschritt-Berichte VDI, Reihe 1, Nr.
537)
Furr-2003
Furrer, Frank J.:
Industrieautomation mit Ethernet-TCP/IP und Web-Technologie.
3., neubearb. Aufl.
Heidelberg: Hüthig, 2003
Gart-2005
Gartner, Inc:
Magic Quadrant for Enterprise Application Servers, 2Q2005
Kostenpflichtig unter: </http://www.gartner.com/>, letzter Abruf am: 01.05.2008
Gart-2006
Gartner, Inc:
Magic Quadrant for Horizontal Portal Products, 2Q2006
</http://mediaproducts.gartner.com/gc/reprints/ibm/external/article12/article12.htm
l/>, letzter Abruf am: 01.05.2008
Gerh-2000a
Gerhardt, Axel:
Produktbegleitende Dienstleistungen – eine notwendige Leistungsergänzung des
Maschinen- und Anlagenbaus.
In: Vom Lieferanten zum Wertschöpfungspartner Dienstleistung im Maschinenbau
Frankfurt/M.: VDMA Verlag, 2000, S. 5-11
Gerh-2000b
Gerhardt, Axel:
Neue Kaufkriterien für Maschinen und Anlagen. Die Diversifikation der Wettbewerbsfelder im Maschinen- und Anlagenbau.
ZWF 95 (2000) Nr. 11, S. 560-562.
Göhn-2004a
Göhner, Peter; Eberle, Stephan:
Softwareentwicklung für eingebettete Systeme mit strukturierten Komponenten.
Teil 1: Komponentenorientierte Zerlegung.
In: atp - Automatisierungstechnische Praxis 46 (2004), Nr. 3, S. 41-52
Göhn-2004b
Göhner, Peter; Eberle, Stephan:
Softwareentwicklung für eingebettete Systeme mit strukturierten Komponenten.
Teil 2: Komponentenorientierte Modellierung und Realisierung.
In: atp - Automatisierungstechnische Praxis 46 (2004), Nr. 4, S. 61-73
Göhr-2001
Göhringer, Jürgen:
Integrierte Telediagnose via Internet zum effizienten Service von Produktionssystemen.
Bamberg: Meisenbach, 2001
Zugl.: Erlangen-Nürnberg, Univ., Diss., 2001
- 209 -
Grau-2001a
Graupner, Tom-David; Berger, Ralf; Blümel, Eberhard; Borrmann,
Andreas; Hellmann, Andreas:
Das e für den Service.
In: Computer & Automation (2001), Nr. 1, S.26-31
Grau-2001b
Graupner, Tom-David:
Internet-Services - Mehrwerte für den Kunden schaffen.
In: KÖTTER Consulting Engineers: 5. Workshop Kolbenverdichter: Tagungsband,
24.-25. Oktober 2001, Rheine.
Rheine, 2001, S. 111-119
Grau-2001c
Simulationsdienstleistung über das Internet nutzen.
In: Tecnomatix End-to-End Solutions for Manufacturing - E-Manufacturing Conference, 23. Oktober 2001, Stuttgart
Stuttgart, 2001
Grau-2002a
Graupner, Tom-David; Sihn, Wilfried:
Simulation-based configuration and animation of manufacturing systems via the
Internet.
In: Lee, Jay (Chairman) u. a.; University of Wisconsin / Center for Intelligent Maintenance Systems: Managing Innovative Manufacturing MiM 2002 - Conference
Proceedings: E-Manufacturing and E-Business Integration. Milwaukee, Wisconsin, USA. September 9-11, 2002.
Milwaukee, Wisconsin, USA, 2002, S. 210-214
Grau-2002b
Graupner, Tom-David; Richter, Hendrik; Sihn, Wilfried:
Configuration, simulation and animation of manufacturing systems via the internet.
In: Yücesan, Enver (Hrsg.) u. a.: Exploring New Frontiers: WSC '02: Proceedings
of the Winter Simulation Conference, 8-11 December 2002, San Diego, California,
USA,
Piscataway, NJ, USA: IEEE Press, 2002, S. 825-831
Grau-2002c
Graupner, Tom-David; Hohwieler, Eckhard:
Service-Scheckheft für die Maschine.
In: Computer & Automation (2002), Nr. 10, S. 26-30
Grau-2002d
Graupner, Tom-David; Sihn, Wilfried:
Simulation-based configuration and animation of production systems via the Internet.
In: Amborski, Krzysztof (Hrsg.) u. a.; The Society for Computer Simulation International: Modeling and Simulation 2002: 16th European Simulation Multiconference,
June 3-5, 2002, Darmstadt, Germany.
Gent, Belgien: SCS International, 2002, S. 593-596
Grau-2003a
Graupner, Tom-David; Richter, Hendrik; Sihn, Wilfried; Westkämper, Engelbert:
Sales and planning support for manufacturing system solutions by utilization of
digital factory tools.
In: Hamza, M.H. (Ed.); International Association of Science and Technology for
Development u. a.: Modelling and Simulation: Proceedings of the IASTED International Conference. February 24-26, 2003, Palm Springs, California, USA.
Anaheim, California, USA u. a.: Acta Press, 2003, S. 614-618
- 210 -
Grau-2003b
Anlagen zeigen schon auf dem Computer ihr ganzes Können.
In: Metallbearbeitung Deutschland (2003), S. 40-41
Grau-2003c
Graupner, Tom-David; Westkämper, Engelbert:
E-maintenance: web-based services for production systems.
In: Qu, Liangsheng (Ed.) u. a.; Jiaotong University <Xi'an, China> u. a.: IMS 2003:
Proceedings of International Conference on Intelligent Maintenance Systems. October 30 - November 1, 2003, Xi'an, China.
Changsha, China: National University of Defense Technology Press, 2003, S.
637-645
Grau-2003d
Layoutplanung und 3-D-Simulation bei der Firma Bystronic Glas.
In: Tecnomatix eM-Plant Usermeeting: Tagungsunterlagen. 21. Oktober 2003,
Korntal-Münchingen.
Korntal-Münchingen, 2003, S. 117-123
Grau-2004a
Graupner, Tom-David (Workshopleiter); Fraunhofer-Institut für Produktionstechnik
und Automatisierung IPA:
Wege zur Digitalen Fabrik: Praxisorientierter Leitfaden zur Einführung und Umsetzung. Workshop, 11. Februar 2004, Bad Homburg.
Eschborn, Management Circle, 2004
Grau-2004b
How to Implement the Digital Factory: A Practical Guideline Describing the State
of the Art in Automotive, Aerospace and Manufacturing.
In: Oregon State University <Corvallis, Oregon, USA.> u. a.: DET 2004: Proceedings of the 2nd International Seminar in Digital Enterprise Technology, September 13-15, 2004 , Seattle, Washington, USA.
Seattle, USA., 2004, o. Z.
Grau-2004c
Konfigurationssysteme zur Anlagenprojektierung.
In: IT&Production (2004), Nr. 4, S. 24
Grau-2005a
Einleitung und Überblick: Was ist die Digitale Fabrik; Die Digitale Fabrik im Detail;
Chancen und Zukunft der Digitalen Fabrik.
In: Innovationsservice Salzburg u. a.: Die Potenziale der Digitalen Fabrik:
Innovationstag des Innovationsservice, 25. Jänner 2005, Salzburg.
Salzburg, Österreich, 2005, S. 1-56
Grau-2005b
Graupner, Tom-David; Bierschenk, Sabine:
Erfolgsfaktoren bei der Einführung der Digitalen Fabrik.
In: Industrie Management 21 (2005), Nr. 2, S. 59-62
Grau-2005c
Graupner, Tom-David; Shligerskiy, Mykhailo:
Von der realen Fabrik in die Digitale Fabrik und zurück.
In: Stuttgarter Messe- und Kongress-Gesellschaft: CAT.PRO 2005: 21. Internationale Fachmesse für innovative Produktentwicklung, Daten- und Prozessmanagement, 04.-07. Oktober 2005, Stuttgart.
Stuttgart, 2005, 16 S.
- 211 -
Grau-2005d
Von der realen Fabrik in die Digitale Fabrik und zurück - ein Beispiel aus der
Papier verarbeitenden Industrie.
In: Tecnomatix eM-Plant Usermeeting: Tagungsunterlagen. 14. Oktober 2005,
Stuttgart.
Stuttgart, 2005, 16 S.
Grau-2005e
Digitale Fabrik geht fremd: Lebensmittelindustrie plant taktische Kapazitäten und
operative Produktion mit Simulationslösungen.
In: IT & Production 5 (2005), Nr. 4, S. 30-31
Grau-2006a
Graupner, Tom-David; Tix, Frank:
Projektierung modularer Produktionssysteme unter Nutzung von Werkzeugen der
Digitalen Fabrik.
In: Wenzel, Sigrid (Hrsg.); Gesellschaft für Informatik / Fachausschuss 4.5:
Arbeitsgemeinschaft Simulation / Fachgruppe 4.5.6: Simulation in Produktion und
Logistik: Simulation in Produktion und Logistik: Tagungsband zur 12. Fachtagung.
Kassel, 26.-27. September 2006.
Erlangen: SCS Publ. House, 2006, S. 403-412 (ASIM Mitteilung 104)
Grau-2006b
Graupner, Tom-David; Brandner, Carsten; mic - management information center;
Automobilproduktion:
3. Internationaler Fachkongress, Digitale Fabrik in der Automobilindustrie: Einführungsworkshop Wege zur Digitalen Fabrik, 22. Mai 2006, Ludwigsburg.
Ludwigsburg, 2006, 114 S.
Grau-2006c
Virtuelle Inbetriebnahme mit Werkzeugen der Digitalen Fabrik.
In: Müller, Egon (Moderation); mic - management information center u. a.: Ramp
up - Anlaufmanagement in der Automobil-Produktion: Fachtagung, 28.-29. September 2006, Leipzig.
Leipzig, 2006, 26 S.
Grau-2006d
Status quo der Digitalen Fabrik: Potenziale, Branchen, Herausforderungen.
In: Kompetenzzentrum für Virtuelle Realität und Kooperatives Engineering (VDC):
Digitale Fabrik - vom Modell zur Simulation, VDC-Workshop, 13. Juli 2006, Fellbach/Stuttgart.
Fellbach/Stuttgart, 2006, 37 S.
Grau-2006e
Digital Factory - Barrier, potential, outlook.
In: Freudenberg Anlagen- und Werkzeugtechnik GMBH: Intelligente Produktionssysteme aus einer Hand: FAW Open Days, 17. Mai 2006, Laudenbach.
Laudenbach, 2006, 61 S.
Guds-2003
Gudszend, Tim:
Zusammenarbeit von Instandhaltung und Service im Maschinen- und Anlagenbau. Status Quo im Verhältnis von Betreibern, Herstellern und Dienstleistern.
- 212 -
Gurz-2006
Gurzki, Thorsten:
Ein Architekturmodell für Portale im Technischen Vertrieb.
Heimsheim: Jost-Jetter Verlag, 2006 (IPA-IAO Forschung und Praxis, Nr. 442)
Zugl.: Stuttgart, Univ., Fak. Maschinenbau, Diss., 2006
Habe-2002
Haberfellner, Reinhard (Hrsg.):
Systems Engineering. Methodik und Praxis
Zürich: Verlag Industrielle Organisation, 2002
Haus-2003
Hauser, Andreas; Stark, Monika:
Trendstudie After-Sales-Service.
Aachen: Forschungsinstitut für Rationalisierung, 2003 (FIR+IAW-Praxis, Nr. 8)
Hein-2001
Heinemann, George T.; Councill, William T.:
Component Based Software: Engineering: Putting the Pieces Together.
Boston, Munich: Addison-Wesley, 2001
Hein-2003
Heine, Ingo:
Internetbasierte Dienstleistungsplattform für heterogene Automatisierungsstrukturen.
Aachen: Shaker, 2003 (Schriftenreihe, Lehrstuhl für Produktionssysteme 2003).
Zugl.: Bochum, Ruhr-Univ., Fak. für Maschinenbau, Diss., 2003
Heis-2007
Homepage Heise Security News:
</http://www.heise.de/security/news/>, letzter Abruf am: 01.05.2008
Hell-2003
Hellmann, Andreas; Jessen, Ulrich; Wenzel, Sigrid:
e-Services – a part of the Digital Factory.
Herm-2000
Hermsen, Martin:
Ein Modell zur kundenindividuellen Konfiguration produktnaher Dienstleistungen.
Aachen: Shaker, 2000
Zugl.: Bochum, Univ., Diss., 2000
Hoec-2004
Hoeck, Hendrik; Kutlina, Zornitsa, Forschungsinstitut für Rationalisierung
<Aachen>:
Status quo und Perspektiven im Service 2004: Ergebnisse der Expertenbefragung
Servicemanagement.
Aachen, 2004
Hoec-2005
Hoeck, Hendrik:
Produktlebenszyklusorientierte Planung und Kontrolle industrieller Dienstleistungen im Maschinenbau.
Aachen: Shaker, 2005 (Schriftenreihe Rationalisierung und Humanisierung, Nr.
76).
Zugl.: Aachen, RWTH, Fak. für Maschinenwesen, Diss., 2005
Holl-1995
Hollingsworth, David:
The Workflow Management Coalition Specification - The Workflow Reference
Model.
Document Number TC00-1003, Document Status - Issue 1.1; 19. Jan. 1995
- 213 -
Homb-2006
Homburg, Christian; Krohmer, Harley:
Marketingmanagement: Strategie - Instrumente - Umsetzung - Unternehmensführung. 2. Ausg.,
Wiesbaden: Gabler, 2006
Huse-2005
van Husen, Christian; Opitz, Marc; Böttcher, Martin; u. a.:
Co-Design von Software und Services 2005: Studie zur Entwicklung IT-basierter
Dienstleistungen in deutschen Unternehmen.
Huse-2006
van Husen, Christian; Meiren, Thomas:
Service Engineering. Erfolg mit innovativen Dienstleistungen, Seminarunterlagen,
Stuttgart, 9. Mai 2006
Fraunhofer IAO, Stuttgart: Fraunhofer IRB, 2006
ISO-10746-3
Norm ISO/IEC 10746-3: 1996-09
Information technology Open Distributed Processing - Reference Model: Architecture
Jaco-1999
Jacobson, Ivar; Booch, Grady; Rumbaugh, James:
The Unified Software Development Process.
Boston, Munich: Addison-Wesley, 1999
KBSt-2006
Koordinierungs- und Beratungsstelle der Bundesregierung für Informationstechnik
in der Bundesverwaltung im Bundesministerium des Innern (KBSt):
Standards und Architekturen für E-Government-Anwendungen (SAGA), Vers. 3,
Oktober 2006
</http://www.kbst.bund.de/saga/>, letzter Abruf am: 01.05.2008
King-1989
Kingman-Brundage, Jane:
The ABC´s of Service System Blueprinting.
In: Bitner, Mary Jo; Crosby , L.A.: Designing a Winning Service StratChicago
1989, S. 30-33
Kink-2003
Kinkel, Steffen; Jung Erceg, Petra; Lay, Gunter (Hrsg.):
Controlling produktbegleitender Dienstleistungen.
Heidelberg: Physica-Verlag, 2003
Koer-2002
Körner, Mike; Verband Deutscher Maschinen- und Anlagenbau:
E-Service-Support im Maschinen- und Anlagenbau: Ausgewählte Aspekte zum
erfolgreichen Management von e-Service-Leistungen.
Frankfurt/M.: VDMA Verlag, 2002
Zugl.: St. Gallen (Schweiz), Univ., Diss., 2002
Kräm-2006
Krämer, Hagen:
Wirkungszusammenhänge zwischen Industrie und Dienstleistungen.
In: Deryk Streich (Hrsg.); Dorothee Wahl (Hrsg.): Moderne Dienstleistungen: Impulse für Innovation, Wachstum und Beschäftigung.
Frankfurt/M.: Campus, 2006, S. 1104
Kram-2003
Krammer, Andreas; Zaha, Johannes Maria:
Komponentenfindung in monolithischen betrieblichen Anwendungssystemen.
In: Tagungsband zum 5. Workshop Komponentenorientierte betriebliche Anwendungssysteme, Augsburg.
Augsburg, 2003, S.155-166
- 214 -
Krei-2002
Kreidler, Volker:
Pilotierungsbericht: Internetbasierte Automatisierungs-Dienstleistungen
In: VDMA-Anwenderforum Teleservice, 5. Juni 2002, Frankfurt/M.
Frankfurt/M., 2002, 34 S.
Krei-2004
Kreidler, Volker:
Internet-basierte Produktions-Dienstleistungen für Werkzeugmaschinen.
Essen: Vulkan, 2004
Zugl.: Braunschweig, Techn. Univ. Carolo-Wilhelmina, Fak. für Maschinenbau und
Elektrotechnik, Diss., 2003 (Schriftenreihe des IWF)
Kuhn-2005
Kuhn, Axel; Hellmann, Andreas; Ellerkmann, Frank:
Mehrwertdienst im Lebenszyklus von Sachanlagen in der Logistik
In: elogistics-journal, November 2005.
</http://www.elogistics-journal.de/archiv/2005/11/mehrwertdienst>, letzter Abruf
am: 01.05.2008
Lang-1997
Lang, Klaus:
Gestaltung von Geschäftsprozessen mit Referenzprozessbausteinen.
Wiesbaden: Gabler, 1997.
Zugl.: Erlangen, Nürnberg, Univ., Diss., 1996
Lay-1999
Lay, Gunter (Hrsg.); Schneider, Robert (Hrsg.); Fraunhofer-Institut für Systemtechnik und Innovationsforschung ISI:
ProService: Den Wettbewerb aktiv gestalten.
Lay-2000
Lay, Gunther; Rainfurth, Claudia; Eggers, Thorsten:
Industrie in Baden-Württemberg im Wandel von der Produktion zur Dienstleistung.
Karlsruhe: Fraunhofer ISI, 2000
Lay-2001
Lay, Gunther; Schneider, Robert:
Wenn Hersteller zu Servicedienstleistern werden.
In: HARVARD BUSINESS manager (2001), Nr. 2, S. 16-24
Lay-2002
Lay, Gunter; Jung Erceg, Petra (Hrsg.):
Produktbegleitende Dienstleistungen: Konzepte und Beispiele erfolgreicher
Strategieentwicklung.
Lay-2005
Lay, Gunter (Hrsg.); Nippa, Michael (Hrsg.):
Management produktbegleitender Dienstleistungen: Konzepte und Praxisbeispiele
für Technik, Organisation und Personal in serviceorientierten Industriebetrieben.
Leym-2001
Leymann, Frank:
Web Services Flow Language (WSFL 1.0), May 2001.
IBM Academy of Technology, IBM Software Group
</http://www-306.ibm.com/software/solutions/webservices/pdf/WSFL.pdf/>, Quelle
nicht mehr verfügbar, da inzwischen veraltet. Die Ideen flossen in BPEL ein.
Lies-2001
Liestmann, Volker; Forschungsinstitut für Rationalisierung <Aachen>:
Dienstleistungsentwicklung durch Service Engineering: Von der Idee zum
Produkt.
Aachen, Forschungsinstitut für Rationalisierung, 2001 (FIR+IAW-Praxis Edition 2)
- 215 -
Löff-2001
Löffler, Benno:
Internetbasierte Logistikanalyse.
In: Westkämper, Engelbert (Hrsg.) u. a.; Fraunhofer-Institut für Produktionstechnik
und Automatisierung (IPA) u. a.: E-Business-Lösungen in Produktion und Logistik:
Einführungsstrategien, Prozesse, Anwendungen und Technologien für mittelständische Produktionsunternehmen. 13. März 2001, Stuttgart.
Stuttgart, 2001, S. 87-103
Lucz-2000
Luczak, Holger (Hrsg.) u. a.:
Service Engineering: Der systematische Weg von der Idee zum Leistungsangebot.
München: TCW Transfer-Centrum, 2000 (TCW-Report 19)
Lucz-2004
Luczak, Holger (Hrsg.); Stich, Volker (Hrsg.):
Betriebsorganisation im Unternehmen der Zukunft.
Mang-2004
Mangold, Pascal:
IT-Projektmanagement kompakt. 2. Aufl.
Heidelberg: Spektrum Akademischer Verlag, 2004
Maßb-2000
Maßberg, Wolfgang (Hrsg.); Hermsen, Martin (Hrsg.); Zuther, Magnus (Hrsg.):
Telec: Multimedialer TeleService.
Aachen: Shaker, 2000 (Schriftenreihe des Lehrstuhls für Produktionssysteme)
McIl-1969
McIlroy, Douglas M.:
Mass produced software components.
In: Naur, Peter; Randell, Brian (Hrsg.): Software Engineering: Report of a conference sponsored by the NATO Science Committee, Garmisch, Germany, 7-11 Oct.
1968.
Brussels, Scientific Affairs Division, NATO (1969), S. 138-155.
Meie-2004a
Meier, Horst:
Embedded online services: Internetbasierte Dienstleistungsplattform für
Produktionsbetriebe.
Meie-2004b
Meier, Horst (Hrsg.):
Dienstleistungsorientierte Geschäftsmodelle im Maschinen- und Anlagenbau:
Vom Basisangebot bis zum Betreibermodell.
Meie-2005
Meier, Horst; Uhlmann, Eckart; Kortmann, Daniel:
Hybride Leistungsbündel - Nutzenorientiertes Produktverständnis durch interferierende Sach- und Dienstleistungen.
Meie-2006a
Meier, Horst; Kortmann, Daniel; Krug, Christian:
Von der Technologie zur Nutzerführerschaft - Die Zukunft der Werkzeugmaschine
als hybrides Leistungsbündel.
In: ZWF 101 (2006) Nr. 7-8, S. 431-437
Meie-2006b
Meier, Horst; Kortmann, Daniel:
Automatisierte Dienstleistungsprozesse hybrider Leistungsbündel.
In: ZWF 101 (2006) Nr. 10, S. 557-560
- 216 -
Meir-2001
Meiren, Thomas:
Systematische Entwicklung von Dienstleistungen,
In: Industrie-Management 17 (2001) Nr. 2, S. 27-30
Meir-2002
Meiren, Thomas; Volker Liestmann (Hrsg.):
Service Engineering in der Praxis - Kurzstudie zu Dienstleistungsentwicklung in
deutschen Unternehmen
Meir-2006
Meiren, Thomas:
Service Engineering im Trend. Ergebnisse einer Studie unter technischen Dienstleistern.
Merc-2003
Mercer Management Consulting:
Maschinenbau-Studie – Steigerung der Ertragskraft durch neue Geschäftsmodelle
München, Mercer Management Consulting, 2003
Merc-2005
Studie: Maschinenbau 2010: Steigerung der Ertragskraft durch innovative Geschäftsmodelle, Februar 2005
Merc-2006
Globalisierungsstrategien für Maschinen- und Anlagenbauer, November 2006
Meye-1990
Meyer, Anton:
Dienstleistungs-Marketing.
In: Meyer, P.W./Meyer, A. (Hrsg.): Marketing-Systeme, Grundlagen des
institutionalen Marketing. S. 173-220.
Stuttgart, Kohlhammer, 1990, S. 173-220
Meye-2004
Meyer, Anton:
Dienstleistungsmarketing. Impulse für Forschung und Management.
München, Deutscher Universitätsverlag, 2004
Mert-2004
Mertins, Kai; Spath, Dieter (Hrsg.):
Studie zu IT-Services – Neue Wege zur professionellen Dienstleistungsentwicklung.
Nyhu-2003
Nyhuis, Peter; Wiendahl, Hans-Peter:
Logistische Kennlinien: Grundlagen, Werkzeuge und Anwendungen. 2. erw. und
neubearb. Aufl.
OASI-2006
Organization for the Advancement of Structured Information Standards (OASIS):
OASIS Reference Model for Service Oriented Architecture V 1.0 - Official Committee Specification, approved Aug 2, 2006.
</http://www.oasis-open.org/committees/download.php/19679/soa-rm-cs.pdf/>,
letzter Abruf am: 01.05.2008
- 217 -
OASI-2007a
Organization for the Advancement of Structured Information Standards (OASIS):
Web Services Business Process Execution Language Version 2.0 (WS-BPEL),
Committee Draft, 31 January, 2007.
</http://docs.oasis-open.org/wsbpel/2.0/wsbpel-v2.0.pdf/>, letzter Abruf am:
01.05.2008
OASI-2007b
Homepage der Organization for the Advancement of Structured Information Standards (OASIS):
</http://www.oasis-open.org/>, letzter Abruf am: 01.05.2008
OASI-2007c
Homepage Cover Pages:
</ http://xml.coverpages.org/>, letzter Abruf am: 01.05.2008
OMG-2006a
Object Management Group:
Unified Modeling Language: Superstructure, Version 2.1, April 2006
</http://www.omg.org/docs/ptc/06-04-02.pdf/>, letzter Abruf am: 01.05.2008
OMG-2006b
Object Management Group / Business Process Management Initiative:
Business Process Modeling Notation (BPMN), OMG Final Adopted Specification,
February 6, 2006
</http://www.bpmn.org/Documents/OMG%20Final%20Adopted%20BPMN%2010%20Spec%2006-02-01.pdf/>, letzter Abruf am: 01.05.2008
OMG-2007
Homepage der Object Management Group (OMG):
</http://www.omg.org/>, letzter Abruf am: 01.05.2008
Para-1985
Parasuraman, A.; Zeithaml, V.; Berry, L.:
A Conceptual Model of Service Quality and Its Implications for Future Research.
In: Journal of Marketing, 49 (1985). S. 41-50
Pill-2001
Piller, Frank Thomas; Meier, Roland:
Strategien zur effizienten Individualisierung von Dienstleistungen.
In: Industrie-Management 17 (2001), Nr. 2, S. 13-17
Quan-2003
Quantz, Joachim; Wichmann, Thorsten:
Basisreport Integration mit Web-Services - Konzept, Fallstudien und Bewertung;
August 2003
Berlin, Berlecon Research GmbH, 2003
</http://www.berlecon.de/research/reports.php?we_objectID=135/>, letzter Abruf
am: 01.05.2008
Reic-2000
Reichwald, Ralf; Goecke, Robert; Stein, Susanne:
Dienstleistungsengineering: Dienstleistungsvernetzung in Zukunftsmärkten.
München: TCW Transfer-Centrum, 2000 (TCW-Report 17)
Reus-2006
Reussner, Ralf; Hasselbring, Wilhelm (Hrsg.):
Handbuch der Software-Architektur
Heidelberg: dpunkt, 2006
Ritt-2000
Ritter, Jörg;
Prozessorientierte Konfiguration komponentenbasierter Anwendungssysteme.
Oldenburg, Univ., Diss., 2000
- 218 -
Rose-1996
Rosemann, Michael:
Komplexitätsmanagement in Prozessmodellen: methodenspezifische Gestaltungsempfehlungen für die Informationsmodellierung.
Wiesbaden: Gabler, 1996
Zugl.: Münster, Univ., Diss., 1996
Rupp-2002
Rupp, Chris:
Requirements-Engineering und -Management.
München: Hanser, 2002
Sche-1991
Scheer, August-Wilhelm:
Architektur integrierter Informationssysteme. Grundlagen der Unternehmensmodellierung.
Berlin u. a.: Springer, 1991.
Sche-2002
Scheer, August-Wilhelm:
ARIS - Vom Geschäftsprozess zum Anwendungssystem.
4. Aufl.,
Sche-2004
Scheer, August-Wilhelm; Spath, Dieter:
Computer Aided Service Engineering, Informationssysteme in der Dienstleistungsentwicklung.
Sihn-2000a
Sihn, Wilfried; Graupner, Tom-David:
E-Industrial Services: Value-Added Services for the Producing Sector Using the
Example of Simulation.
In: Al-Akaidi, Marwan (Ed.); The Society for Computer Simulation International
u. a.: 2nd Middle East Symposium on Simulation and Modeling - MESM 2000:
August 28-30, 2000, Amman, Jordanien.
Gent, Belgien: SCS Europe, 2000, S. 95-99
Sihn-2000b
A parallel evolutionary algorithm approach to solve sequencing problems.
In: Mathematical Modelling and Scientific Computing: Science and Technology 10
(2000), Proceedings International Conference, August 2-4, 1999, Chicago, Illoniois, USA.
Chicago, Illoniois, USA, 2000, S. 1-7
Sihn-2000c
A parallel evolutionary algorithm approach to solve sequencing problems.
In: International Federation of Automatic Control u. a.: IFAC Workshop on Future
trends in automation in mineral and metal processing 2000, Preprints, August 2224, 2000, Helsinki, Finnland.
Helsinki, 2000, S. 144-149
Sihn-2001a
E-Industrial Services: Value-Added Services for the Producing Sector.
In: Dimitrov, Dimitri (Hrsg.); Preez, Nick du (Hrsg.); University of Stellenbosch /
Depart. of Industrial Engineering, Global Competitiveness Centre in Engineering:
COMA 2001: Proceedings International Conference on Competitive Manufacturing, 31 January - 2 February 2001, Stellenbosch, South Africa.
Stellenbosch, South Africa, 2001, S.457-468
- 219 -
Sihn-2001b
In: Chryssolouris, George (Hrsg.); University of Patras / Dept. of Mechanical Engineering and Aeronautics / Lab. for Manufacturing Systems and Automation:
Technology and Challenges for the 21st Century: CIRP 34th International Seminar on Manufacturing Systems, May 16-18, 2001, Athens, Greece.
Athens, Greece, 2001, S. 413-424
Sihn-2001c
In: Domingo, Manuel Esteve (Hrsg.) u. a.; The Society for Modeling and Simulation International: EUROMEDIA 2001: Sixth Annual Scientific Conference on Web
Technology, New Media, Communications and Telematics Theory, Methods,
Tools and Applications, April 18-20, 2001, Valencia, Spain.
Gent, Belgien: SCS Europe, 2001
Sihn-2001d
E-Industrial Services Value-Added Services for the Producing Sector Using the
Example of Simulation.
In: Jiang, Pingyu (Hrsg.) u. a.: ICECE 2001: Abstracts for Proceedings of Internaional Conference on e-Commerce Engineering: New Challenges for Global
Manufacturing in the 21st Century, September 16-18, 2001, Xi'an, China.
Beijing, China: China Machine Press, 2001, S. 40
Sihn-2001e
Sihn, Wilfried; Halmosi, Hans; Mandel, Jörg:
Komplexe simulationsgestützte Internetdienstleistungen: die Beispiele
Produktionssimulation und Logistikanalyse.
In: Schulze, Thomas (Hrsg.) u. a.; Otto-von Guericke Universität <Magdeburg> /
Institut für Simulation und Graphik: Simulation und Visualisierung 2001:
Proceedings der Tagung, 22.-23. März 2001, Magdeburg.
Sihn-2001f
E-Industrial Services, Value-Added Services from the socket.
In: Stanford-Smith, Brian (Ed.) u. a.; Information Society Technologies: E-work
and E-commerce - Volume 2: Novel solutions and practices for a global networked economy.
Amsterdam u. a.: IOS Press, 2001, S. 1145-1150
Sihn-2002a
Sihn, Wilfried; Graupner, Tom-David; Mußbach-Winter, Ute; Wiedenmann, Harald:
E-Business requires the simulation of logistics processes.
In: Kuljanic, Elso (Hrsg.); CISM - Centre International des Sciences Mécaniques:
Advanced manufacturing systems and technology: Proceedings of the Sixth International Conference, AMST '02, June 20-21, 2002, Udine, Italy.
Wien, New York: Springer, 2002, S. 291-298
Sihn-2002b
Sihn, Wilfried; Graupner, Tom-David; Richter, Hendrik; Tix, Frank:
Simulationsbasierte Konfiguration zur Vertriebsunterstützung von Produktionssystemen.
In: Tavangarian, Djamshid (Hrsg.) u. a.; Gesellschaft für Informatik /
Fachausschuß 4.5: Arbeitsgemeinschaft Simulation u. a.: 16. Symposium
Simulationstechnik - ASIM 2002. 10.-13. September 2002, Rostock.
- 220 -
Sihn-2002c
E-Industrial services: web-based simulation and logistic analyser.
In: Da Rocha Brito, Claudio u. a.; School of Engineering and Technology SENAC: Intertech 2002: International Conference on Engineering and Technology
Education, March 17-20, 2002, Santos, Brasil.
Santos, Brasil, 2002
Sihn-2002d
Sihn, Wilfried; Graupner, Tom-David; Kuhlmann, Timm; Richter, Hendrik: Internetbasierte Konfiguration und Simulation von Produktionssystemen.
In: Schulze, Thomas (Hrsg.) u. a.; Otto-von-Guericke Universität <Magdeburg> /
Institut für Simulation und Graphik: Simulation und Visualisierung 2002:
Proceedings der Tagung am Institut für Simulation und Graphik der Otto-vonGuericke-Universität Magdeburg am 28. Februar - 1. März 2002, Magdeburg.
Sihn-2002e
Sihn, Wilfried; Graupner, Tom-David; Asal, Matthias:
Parallel evolutionary algorithms.
In: Amborski, Krzysztof (Hrsg.) u. a.; The Society for Computer Simulation International u. a.: Modelling and Simulation 2002: 16th European Simulation Multiconference, June 3-5, 2002, Darmstadt, Germany.
Gent, Belgien: SCS International, 2002, S. 172-175
Sihn-2003a
E-Industrial Services for Manufacturing Systems: Differentiation Through Internet
Services.
In: Universität des Saarlandes <Saarbrücken> / Lehrstuhl für Fertigungstechnik:
Progress in Virtual Manufacturing Systems: Proceedings, 36th CIRP International
Seminar on Manufacturing Systems, June 03-05, 2003, Saarbrücken, Germany.
Sihn-2003b
Simulation-based Configuration, Animation and Simulation of Manufacturing Systems.
In: Universität des Saarlandes <Saarbrücken> / Lehrstuhl für Fertigungstechnik:
Progress in Virtual Manufacturing Systems: Proceedings. 36th CIRP International
Seminar on Manufacturing Systems, June 03-05, 2003, Saarbrücken, Germany.
Sihn-2003c
Sihn, Wilfried; Mandel, Jörg; Graupner, Tom-David:
Collaboration support in factory planning by means of e-simulation.
In: Monostori, László (Hrsg.) u. a.; Hungarian Academy of Sciences <Budapest>
u. a.: Intelligent Manufacturing Systems - IMS '03, Preprints: 7th IFAC Workshop,
April 6-8, 2003, Budapest, Hungary.
Budapest, 2003, S. 239-242
Sihn-2003d
Sihn, Wilfried; Richter, Hendrik; Graupner, Tom-David:
Projektierung von Fertigungssystemen durch Konfiguration, Visualisierung und
Simulation.
In: Schulze, Thomas (Hrsg.) u. a.; Otto-von Guericke Universität <Magdeburg> /
Institut für Simulation und Graphik u. a.: Simulation und Visualisierung 2003:
Proceedings der Tagung am Institut für Simulation und Graphik der Otto-vonGuericke-Universität Magdeburg am 6.-7. März 2003, Magdeburg.
- 221 -
Sihn-2003e
Web-based maintenance services for manufacturing systems.
In: Lemke, Heinz U. (Hrsg.) u. a.: CARS 2003 Comuter Assisted Radiology and
Surgery: Proceedings of the 17th International Congress and Exhibition, June 2528, 2003, London, UK.
Amsterdam u. a.: Elsevier, 2003, S. 579-590 (International Congress Series 1256)
Simo-1993
Simon, Hermann (Hrsg.):
Industrielle Dienstleistungen.
Stuttgart: Schäffer-Poeschel, 1993
Soda-2006
Sodan:
Business Process Modeling Tools. Eighth edition, August 2006, Uxbridge, UK.
Sodan, Uxbridge, UK, 2006
</http://www.sodan.co.uk/>, letzter Abruf am: 01.05.2008
Spat-2003a
Spath, Dieter (Hrsg):
Service Engineering 2003: Neue Dienstleistungen erfolgreich entwickeln,
Fraunhofer IAO-Tagung.
Stuttgart, 9.-10. Juli 2003
Spat-2003b
Spath, Dieter (Hrsg.); Zahn, Erich (Hrsg.):
Kundenorientierte Dienstleistungsentwicklung in deutschen Unternehmen:
Ergebnisee einer empirischen Studie
Studie Fraunhofer IAO.
Spat-2004a
Spath, Dieter (Hrsg.):
DL'04: Dienstleistungswirtschaft - produktiv und international in die Zukunft. Entwicklung und Management von Dienstleistungen.
Tagungsband, 25. November 2004, Fraunhofer IAO-Seminar, Stuttgart.
Spat-2004b
Spath, Dieter; Schuster, Erwin:
Neue Geschäftsmodelle durch Betreibermodelle.
Spat-2005a
Spath, Dieter (Hrsg.); Weisbecker, Anette (Hrsg.); Höß, Oliver (Hrsg.):
Stuttgarter Softwaretechnik Forum 2005: Modellbasierte Softwareentwicklung.
Tagungsband, 27. Juni 2005, Fraunhofer IAO, Stuttgart.
Spat-2005b
Stuttgarter Softwaretechnik Forum 2005: Serviceorientierte Architekturen und
Enterprise Application Integration.
Tagungsband, 28. Juni 2005, Fraunhofer IAO, Stuttgart
Spat-2006
Stuttgarter Softwaretechnik Forum 2006: Serviceorientierte Architekturen.
Tagungsband, 8. November 2006, Fraunhofer IAO, Stuttgart.
Spat-2007
Spath, Dieter; Fähnrich, Klaus-Peter (Eds.):
Spat-2007Advances in Services Innovations
- 222 -
Spec-2005
Specht, Thomas:
Engineering multimedialer Online-Services für den Maschinenbau.
Heimsheim: Jost-Jetter, 2005 (IPA-IAO Forschung und Praxis, Nr. 415)
Zugl.: Stuttgart, Univ., Diss., 2005
Stan-1994
The Standish Group:
The CHAOS Report (1994).
</http://www.standishgroup.com/sample_research/chaos_1994_1.php/>, letzter
Abruf am: 01.05.2008
Stan-2006
The Standish Group:
Third Quarter Research Report 2006.
Kostenpflichtig unter: </http://www.standishgroup.com/>, letzter Abruf am:
01.05.2008
Stolz-2003
Stolz, Marcus:
Neue Produktnutzungskonzepte und Tele-Technologien.
In: Bullinger, Hans-Jörg (Hrsg.) u. a.: Neue Organisationsformen im Unternehmen: Ein Handbuch für das moderne Management.
Berlin u. a.: Springer, 2003, S. 861-874
Sun-2002
Sun Microsystems:
Sun ONE Architecture Guide - Delivering Services on Demand.
Palo Alto: Sun Microsystems.
</http://www.sun.com/software/sunone/docs/arch/S1-arch-guide.pdf.zip/>, letzter
Abruf am: 01.05.2008
Sun-2007
Sun Microsystems:
Java Platform, Enterprise Edition (Java EE).
Palo Alto: Sun Microsystems.
</http://java.sun.com/javaee/>, letzter Abruf am: 01.05.2008
Tina-1997
TINA Consortium:
TINA 1.0 Deliverables and Specifications, TINA Business Model and Reference
Points, Vers. 4.0, Mai 1997
</http://www.tinac.com/specifications/documents/bm_rp.pdf/>, letzter Abruf am:
01.05.2008
Turo-2002
Turowski, Klaus; et al.:
Vereinheitlichte Spezifikation von Fachkomponenten, Memorandum des Arbeitskreises 5.10.3 Komponentenorientierte betriebliche Anwendungssysteme, Gesellschaft für Informatik, Februar 2002, Augsburg.
</http://wi2.wiwi.uni-augsburg.de/fachkomponenten/memorandum.php/>, letzter
Abruf am: 01.05.2008
Turo-2003
Turowski, Klaus (Hrsg.):
Tagungsband, 4. Workshop Modellierung und Spezifikation von Fachkomponenten, Oktober 2003, Bamberg, Gesellschaft für Informatik, Arbeitskreis
5.10.3, Komponentenorientierte betriebliche Anwendungssysteme
</http://wi2.wiwi.uni-augsburg.de/fachkomponenten/wmsf4.php/>, letzter Abruf
am: 01.05.2008
Uhlm-2003
Uhlmann, Eckart; Hohwieler, Eckart, Berger, Ralf:
E-Services in der vernetzten Produktion.
- 223 -
Uhlm-2004
Uhlmann, Eckart; Hohwieler, Eckart:
e-Anlagen-Services.
Uhlm-2006
Uhlmann, Eckart; Hohwieler, Eckart, Geisert, Claudio:
Verfügbarkeits-Monitoring.
VDI-1999
VDI Verein Deutscher Ingenieure:
Professionelle Vermarktung von Dienstleistungen in der Investitionsgüterindustrie;
Untersuchungsbericht;
Düsseldorf: VDI-Verlag, 1999
VDI-2001
VDI Verein Deutscher Ingenieure:
E-Services in der Investitionsgüterindustrie: Eine Befragung von Anbietern und
Anwendern
Düsseldorf: VDI-Verlag, 2001
VDI-2221
VDI-Richtlinie 2221 1993-05
Methodik zum Entwickeln und Konstruieren technischer Systeme und Produkte
VDI-3633
VDI-Richtlinie 3633 Blatt 1 Entwurf 2000-03
Simulation von Logistik-, Materialfluss- und Produktionssystemen – Grundlagen.
VDI-4499
VDI-Richtlinie 4499 Blatt 1 Entwurf 2006-05
Digitale Fabrik - Grundlagen.
Vlac-2005
Vlachakis, Joannis; Kirchhof, Anja; Gurzki, Thorsten:
Marktübersicht Portalsoftware 2005.
Stuttgart: Fraunhofer IRB, Stuttgart 2005
VDMA-2000a
Verband Deutscher Maschinen- und Anlagenbau:
Die Zahlungsbereitschaft des Kunden für produktbegleitende Dienstleistungen Ergebnisse einer Kundenbefragung.
In: Reihe Entscheidungshilfen Marktkommunikation, Nr. 5
VDMA-2000b
Entwicklung, Produktion und Service von Software für eingebettete Systeme in
der Produktion.
VDMA-2005
Projektinformationen Online für den Service: Abschlussbericht. Projekt PROSERV.
VDMA-2006a
VDMA Maschinenbau in Zahl und Bild 2006.
VDMA-2006b
Teleservice - Ein Werkzeug zur Sicherung der Produktion und Minimierung der
Kosten für Hersteller, Anwender und Betreiber: Ein Leitfaden zu "Wirtschaftlichkeit
durch Teleservice".
- 224 -
VDMA-2006c
Statistisches Handbuch für den Maschinenbau: Volkswirtschaft und Statistik.
VDMA-2006d
VDMA-Positionspapier: Forderungskatalog für eine europäische Strategie gegen
Produktpiraterie.
Venn-2000
Van de Venn, Hans Wernher (Red.):
Teleservice für Maschinen und Anlagen: TeSMA.
VMod-2006
Koordinierungs- und Beratungsstelle der Bundesregierung für Informationstechnik
in der Bundesverwaltung (KBSt):
V-Modell XT, Release 1.2, Februar 2006
</http://www.v-modell-xt.de/>, letzter Abruf am: 01.05.2008
Weis-2000
Weisbecker, Anette:
Komponentenbasierte Software für Produkte und Dienstleistungen (KoSPuD).
Abschlußbericht.
Weis-2002
Weisbecker, Anette:
Software-Management für komponentenbasierte Software-Entwicklung.
Heimsheim: Jost-Jetter Verlag, 2002 (IPA-IAO Forschung und Praxis, 361).
Zugl.: Stuttgart, Univ., Fak. Konstruktions- und Fertigungstechnik, Habil.-Schr.,
2002
West-1997
Westkämper, Engelbert; Rist, Thomas; Schmidt, Thomas:
Intelligente Produktionskonzepte mit Mehrwertdiensten: Blickpunkt EMO.
In: Die Maschine - dima 51 (1997), Nr. 9, S. 20-26
West-2001a
Westkämper, Engelbert:
E-Manufacturing und E-Service - Eine neue Herausforderung für die verarbeitende Industrie.
In: Verein Deutscher Ingenieure / VDI Bildungswerk u. a.: E-Services im Anlagenund Maschinenbau: Mehrwertdienste der Zukunft für die Industrie-Automation,
20.-21. März 2001, Köln.
Düsseldorf, 2001
West-2001b
Westkämper, Engelbert; Niemann, Jörg; Stolz, Marcus:
Steigerung des Lebenslauferfolges durch TeleX-Technologien.
West-2002a
Westkämper, Engelbert:
Teleservice via Internet: Direkter Draht zum Kunden.
In: WB Industrielle Metallbearbeitung 135 (2002), Nr. 4, S. 12-17
West-2002b
Westkämper, Engelbert; Stolz, Marcus; Niemann, Jörg:
Web-basiertes Tele-Management für Werkzeugmaschinen.
In: Metallbearbeitung Deutschland (2002), S. 18-19
West-2002c
Westkämper, Engelbert; Sihn, Wilfried; Graupner, Tom-David; Richter, Hendrik:
Simulationsbasierte Konfiguration und Animation von Produktionssystemen via
Internet.
- 225 -
West-2002d
Westkämper, Engelbert (Leitung):
VDI-Wissensforum; VDI Nachrichten / Konferenzen: E-Services im Anlagen- und
Maschinenbau: Mehrwertdienste für die Industrie-Automation, 5.-6. März 2002,
Pforzheim.
Düsseldorf, 2002, o. Z.
West-2003
Maschinenbau: Mehrwertdienste für die Industrie-Automation, 25.-26. Februar
2003, Karlsruhe.
Düsseldorf, 2003
West-2004
VDI-Wissensforum; VDI Nachrichten / Konferenzen: E-Services im Maschinenbau: Mehrwertdienste für die Industrie-Automation, 10.-11. März 2004, Pforzheim.
Düsseldorf, 2004
West-2005
Maschinenbau: Mehrwertdienste der Zukunft für die Investitionsgüterindustrie,
11.-12. Mai 2005, Karlsruhe.
Düsseldorf, 2005
West-2006
VDI-Wissensforum; VDI Nachrichten / Konferenzen: E-Services im Maschinenbau: 21. März 2006, Kaiserslautern.
Düsseldorf, 2006
Wild-2003
Wildemann, Horst; TCW Transfer Centrum:
Betreibermodelle: Leitfaden zur Berechnung, Konzeption und Einführung von Betreibermodellen und Pay on Production Konzepten.
München: TCW Transfer-Centrum, 2003 (TCW-Leitfaden )
Wild-2004
Wildemann, Horst:
Betreibermodelle: Eine neue Outsourcingstrategie?
München: TCW Transfer-Centrum, 2004 (TCW-Leitfaden)
Wild-2006a
Wildemann, Horst:
Service, 8. Aufl.
Wild-2006b
Wildemann, Horst:
E-Technologien: Leitfaden zum Einsatz von E-Technologien in der Wertschöpfungskette, 7. Aufl.
WfMC-2005
Workflow Management Coalition:
Workflow Management Coalition Workflow Standard Process Definition Interface XML Process Definition Language. Document Number WFMC-TC-1025: Version
1.13; Document Status - Final, September 7, 2005.
WfMC-2007
Homepage der Workflow Management Coalition.
</http://www.wfmc.org/>, letzter Abruf am: 01.05.2008
Zuse-2004
- 226 -
Zuser, Wolfgang; Grechening, Thomas; Köhle, Monika:
Software Engineering mit UML und dem Unified Process. 2. überarb. Aufl.,
München: Pearson Education, 2004
Das Verbundforschungsprojekt E-Industrial Services
Die Fraunhofer-Gesellschaft entwickelte im Rahmen einer strategischen Innovationsinitiative
zwischen 1999 und 2005 die organisatorischen und technischen Voraussetzungen, um Unternehmen des Maschinen- und Anlagenbaus in der Konzeption, Umsetzung, Integration und Erbringung von internetbasierten Mehrwertdiensten zu unterstützen.
An dieser Initiative waren alle produktionstechnischen Institute der Fraunhofer-Gesellschaft sowie
die Institute Fokus und IITB aus dem Informations- und Kommunikationstechnik-Cluster beteiligt.
Die Projektleitung oblag dem Fraunhofer IPA. Die komplementären Kompetenzschwerpunkte gewährleisteten ein breites Einsatzspektrum der erarbeiteten Lösungen.
Gemeinsam mit Pilotkunden wurden insgesamt 12 Mehrwertdienste aus den Anwendungsfeldern
e-Logistics, e-Learning sowie e-Maintenance konzipiert, entwickelt und in der Praxis erprobt und
optimiert (siehe Abbildung 11-1).
e-Logistics
e-Learning
e-M aintenance
Elpro
Abbildung 11-1: Projektpartner der strategischen Innovationsinitiative E-Industrial Services
Um die erdachten Konzepte in funktionsfähige internetbasierte Mehrwertdienste zu verwandeln,
mussten zunächst die technischen Voraussetzungen geschaffen werden. Als Basis hierfür diente
eine eigens entwickelte Internetservice-Plattform, da bei Projektstart die auf dem Markt verfügbaren Softwareprodukte lediglich Teilaspekte der Anforderungen abdecken konnten. Dies änderte
sich im Projektverlauf. Zunehmend betraten die Global Player der Informationstechnik – unter
anderem IBM, Microsoft, Sun, SAP – das lukrative Feld der Internetdienste, wenngleich ohne die
spezifischen Anforderungen der Investitionsgüterindustrie zu berücksichtigen. Bis heute betreiben
sie in großem Umfang Marketing und Entwicklung für ihre Produkte, was zu einer De-facto-Standardisierung bei Internetservice-Plattformen geführt hat. Dieser Umstand machte während der
Projektbearbeitung einen Wandel vom Technologie- zum Prozessfokus notwendig.
Lebenslauf
Persönliche Daten
Name
Tom-David Graupner
Geburt
08. Mai 1969, in Neuenbürg/Enzkreis
Eltern
Gerhard Graupner und Mireille Graupner, geb. Smid
Geschwister
Annabel Graupner
Familienstand
verheiratet mit Sonja Graupner, geb. Seyler
zwei Töchter, Sophia und Lea Graupner
ein Sohn, Maximilian Graupner
Schulbildung
1975-1979
1979-1989
Sonnenhof Grundschule, Pforzheim
Theodor-Heuss-Gymnasium, Pforzheim
Grundwehrdienst
1998-1990
Fernmeldeausbildungskompanie in Dillingen a. d. Donau
letzter Dienstgrad: Obergefreiter
Studium
1990-1997
Beruf
1996-1997
1997-2002
2002-2007
2007-2009
seit 2009
Universität Stuttgart, Fachrichtung Maschinenwesen
Hauptfächer: Technologiemanagement und Thermodynamik
Abschluss: Diplom-Ingenieur
Freier Mitarbeiter bei der Festo AG & Co. KG, Esslingen sowie beim
Wissenschaftlicher Mitarbeiter am Fraunhofer-Institut für Produktionstechnik und
Automatisierung (IPA), Stuttgart;
Abteilung: Auftrags- und Prozessmanagement (1997-2001) sowie
Abteilung: Supply Chain Management und E-Business (2001-2002)
Gruppenleiter am Fraunhofer-Institut für Produktionstechnik und
Automatisierung (IPA), Stuttgart;
Abteilung: Fabrik- und Logistikplanung (2002-2004) sowie
Abteilung: Engineering-IT/Digitale Fabrik (2004-2007)
Key Account Manager im Bereich Digitale Fabrik bei der
Dassault Systèmes DELMIA GmbH, Fellbach
Client Executive Aerospace im Bereich Product Lifecycle Management bei der
Dassault Systèmes Deutschland GmbH, Stuttgart
Projekte am Fraunhofer IPA
1997-2007
Leitung über 35 Industrieprojekte in den Branchen Maschinenbau, Automobil,
Stahl und Luftfahrt.
2000-2005
Stellvertretender Projektleiter des strategischen Fraunhofer-Leitprojekts
E-Industrial Services.