Entwicklung und Evaluierung von Architekturkonzepten für E-Business-Transaktionszentren unter Berücksichtigung gegebener Standards und Schnittstellen

Entwicklung und Evaluierung von Architekturkonzepten für E-Business

Transaktionszentren unter Berücksichtigung gegebener Standards und Schnittstellen ⋅ Klaus Meffert ⋅ Technische Universität Ilmenau ⋅ Diplomarbeit

© 2000, 2001 Klaus Meffert

Dieses Werk ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Jede Verwertung außerhalb der engen Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des Verfassers unzulässig. Insbesondere gilt dies für Vervielfältigung, Übersetzung, Mikroverfilmung und Einspeicherung in elektronische Systeme und Verarbeitung mittels dieser.

II

KURZFASSUNG

Die elektronische Abwicklung von Geschäftsprozessen gehört zu den aktuellen Top-Themen des Internet-Zeitalters. E-Business ist ein Geschäftsfeld, das zur Zeit von Eu-phorie beherrscht wird und enorme Wachstumschancen bietet.

Die Abwicklung von Geschäftsprozessen über das Internet erfordert von allen teilnehmenden Geschäftseinheiten die Bereitstellung geeigneter softwaretechnischer Strukturen, insbesondere die Unterstützung vorgegebener Schnittstellen. Der Anbieter von elektronischen Services hat für die Abwicklung und Verarbeitung der unterschiedlichsten Geschäftsprozesse Sorge zu tragen. Die vorliegende Arbeit stellt eine allgemeine Struktur für eine E-Business Plattform bereit, die als Intermediär externe Geschäftseinheiten integriert, die Abwicklung von Geschäftsprozessen zwischen Anbietern und Kunden ermöglicht und Standardformate für den Datenaustausch bereitstellt. Die bloße Abwicklung von Geschäftsprozessen über das Internet ist durch heutige Technologien möglich. Darauf basierend, beschäftigt sich diese Arbeit mit der Aufgabe, für Unternehmen und Endkunden eine Architektur für einen zentralen elektronischen Transaktionsplatz zu schaffen und eine Grundlage für die softwaretechnische Analyse zu entwickeln. Neben der Entwicklung eines Architekturkonzeptes werden Konzepte von auf dem Markt erhältlichen Systemen untersucht und bewertet. Anhand eines Praxisbeispiel wird außerdem dargestellt, wie ein bestehender Online Shop hin zu einer B2B-Plattform weiterentwickelt werden kann.

III

VORWORT

Ich danke Herrn Dr. Bernd Binder von der fashionmarket AG für die fachliche Unterstützung.

Weiterhin rechne ich meinen Eltern hoch an, daß ich die Möglichkeit erhalten habe, in einem angenehmen und ungestörten Umfeld einen Gutteil meiner Arbeit zu Hause anfertigen zu können.

Abschließend danke ich Marius Obst für die konstruktive Hilfe beim Korrekturlesen der vorliegenden Arbeit.

Ilmenau, im März 2001

Klaus Meffert

IV

Thesen

THESEN

(1) Für den universellen Datenaustausch zwischen unterschiedlichen Applikationen wird sich die eXtensible Markup Language (XML) als Standard etablieren.

(2) XML wird von modernen Datenbanksystemen verstärkt unterstützt werden.

(3) Relationale Datenbanksysteme sind ungeeignet zur optimalen Speicherung und Verarbeitung von XML-Daten.

(4) Java wird sich für die plattformunabhängige Entwicklung von Applikation durchsetzen und behaupten.

(5) Java und XML sind Schlüsseltechnologien bei der Entwicklung moderner E-Business Anwendungen.

(6) Der Markt zur elektronischen Abwicklung von Geschäftsprozessen befindet sich momentan in einer Orientierungs- und Umstrukturierungsphase. E-Business wird sich in Zukunft auf dem Markt etablieren.

V

Inhaltsverzeichnis Inv.-Nr. 2001-03-29/0008/IN95/2253

  INHALTSVERZEICHNIS  

  THESEN  V

  INHALTSVERZEICHNIS  VI

  ABBILDUNGSVERZEICHNIS  X

TABELLENVERZEICHNIS XII   

  ABKÜRZUNGSVERZEICHNIS  XIII

1.  EINLEITUNG  1

1.1.  ÜBERBLICK UND MOTIVATION  1

1.2.  AUFGABENSTELLUNG UND GLIEDERUNG DER ARBEIT  4

1.2.1.  Aufgabenstellung  4

1.2.2.  Gliederung der Arbeit  5

1.3.  KONVENTIONEN  6

2.  GRUNDLAGEN  7

2.1.  EINLEITUNG  7

2.2.  BEGRIFFSERKLÄRUNGEN  7

2.2.1.  Die Begriffe E-Business und E-Commerce  7

2.2.2.  Der Begriff des E-Business Transaktionszentrums  8

3.  ANFORDERUNGEN AN EIN E-BUSINESS TRANSAKTIONSZENTRUM  12

3.1.  ÜBERBLICK  12

3.2.  DATENAUSTAUSCH MIT XML  13

3.3.  ELEKTRONISCHE SERVICES  15

4.  KONZEPTION EINES E-BUSINESS TRANSAKTIONSZENTRUMS  17

4.1.  EINLEITUNG  17

4.2.  DIE FUNKTIONSBEREICHE DES TRANSAKTIONSZENTRUMS  18

4.3.  DIE INTERNE VERARBEITUNG DES TRANSAKTIONSZENTRUMS  20

4.3.1.  Einleitung  20

4.3.2.  Allgemeine Beschreibung  22

4.3.3.  Der Transaktionskoordinator  23

4.3.4.  Fehlerbehandlung  29

4.3.4.1.  Direkter Abbruch  29

VI

Inhaltsverzeichnis Inv.-Nr. 2001-03-29/0008/IN95/2253

4.3.4.2.  Mehrmaliges Wiederholen mit zeitlicher Verzögerung  29

4.3.4.3.  Mehrmaliges Wiederholen in Wellen  29

4.3.5.  Sicherheitsmechanismen  29

4.3.6.  Entwicklungsumgebung  31

4.4.  DIE VERBINDUNGSEINHEIT DES TRANSAKTIONSZENTRUMS  33

4.4.1.  Einleitung  33

4.4.2.  Verbindung mit dem Internet  35

4.4.3.  Lastenteilung  35

4.4.4.  Request Router  38

4.5.  DATENAUSTAUSCH MIT DEM TRANSAKTIONSZENTRUM  38

4.5.1.  Einleitung  38

4.5.2.  Datenaustausch über XML-Dateien  41

4.5.3.  Der Exportvorgang  44

4.5.4.  Der Data Aggregator im Detail  45

4.6.  KOMPONENTEN DES TRANSAKTIONSZENTRUMS  47

4.6.1.  Einleitung  47

4.6.2.  Interne Softwarekomponenten  47

4.6.2.1.  Überblick  47

4.6.2.2.  Der Transaktionskoordinator  49

4.6.2.3.  Empfang und Senden  51

4.6.2.4.  Import und Export  52

4.6.2.5.  Request Routing  53

4.6.2.6.  Sicherheit  54

4.6.2.7.  Visualisierung  56

4.6.2.8.  Datenverarbeitungsprozesse  57

4.6.2.9.  Datenhaltung  58

4.6.2.10.  Datenpflege  59

4.6.2.11.  Logistik und Versand  60

4.6.2.12.  E-Services  61

4.6.3.  Interne Hardwarekomponenten  64

4.6.3.1.  Überblick  64

4.6.3.2.  Peripherie  65

4.6.3.3.  Datenbankserver  65

4.6.3.4.  Data Warehouse und Data Mart  66

4.6.4.  Die externe Umgebung  68

4.6.4.1.  Externe Hardwaresysteme  68

4.6.4.2.  Externe Softwaresysteme  69

5.  EVALUIERUNG VON ARCHITEKTURKONZEPTEN  71

VII

Inhaltsverzeichnis Inv.-Nr. 2001-03-29/0008/IN95/2253

5.1.  EINLEITUNG  71

5.2.  DATENBANKSYSTEME UND E-BUSINESS UNTERSTÜTZUNG  71

5.2.1.  Überblick  71

5.2.2.  Oracle 8i  72

5.2.3.  DB2 Version 7 von IBM  73

5.2.4.  Tamino XML Datenbank von der Software AG  73

5.2.5.  Bewertung  75

5.3.  DIE XML-PLATTFORM DER SOFTWARE AG  75

5.3.1.  Überblick  75

5.3.2.  Bolero  75

5.3.3.  Bolero Component Studio  78

5.3.4.  EntireX  80

5.3.5.  Tamino X-Bridge  82

5.3.6.  Bewertung  83

5.4.  BEA WEBLOGIC SERVER VERSION 6  83

5.4.1.  Überblick  83

5.4.2.  Kommunikation  84

5.4.3.  Die Middleware Tuxedo  86

5.4.4.  Unterstützung von Clustern  87

5.4.5.  Entwicklungsumgebung  88

5.4.6.  Bewertung  90

5.5.  INTERSHOP ENFINITY  90

5.5.1.  Überblick  90

5.5.2.  Die Architektur  91

5.5.3.  Kommunikation mit anderen Systemen  93

5.5.4.  Die Entwicklungsumgebung  94

5.5.4.1.  Templates  94

5.5.4.2.  Pipelines  94

5.5.5.  Bewertung  95

5.6.  INTOS M2, RELEASE 2 1  96

5.6.1.  Überblick  96

5.6.2.  Funktionsbereiche  96

5.6.2.1.  E-Commerce  96

5.6.2.2.  Data Interchange  97

5.6.2.3.  Content Management  100

5.6.2.4.  Collaboration  101

5.6.3.  Bewertung  101

5.7.  BEWERTUNG DER VORGESTELLTEN KONZEPTE  102

VIII

Inhaltsverzeichnis Inv.-Nr. 2001-03-29/0008/IN95/2253

6.  PRAXISBEISPIEL: DIE „FASHIONMARKET AG“  107

6.1.  EINLEITUNG  107

6.2.  DIE TÄTIGKEIT BEI DER FASHIONMARKET AG  108

6.2.1.  Einleitung  108

6.2.2.  Umstellung des bestehenden Systems  109

6.2.3.  Der Aufbau der B2B-Plattform  111

7.  SCHLUßBETRACHTUNGEN UND AUSBLICK  113

  LITERATURVERZEICHNIS  115

IX

  Abbildungsverzeichnis Inv Nr 2001 03 29 0008 IN95  2253

  ABBILDUNGSVERZEICHNIS  

  ABBILDUNG 1: E-BUSINESS UMFELD  1

  ABBILDUNG 2: MARKETPLACE EVOLUTION  3

  ABBILDUNG 3: DIMENSIONEN DES WACHSTUMS  4

  ABBILDUNG 4: GESCHÄFTSBEZIEHUNGEN  8

  ABBILDUNG 5: TRANSAKTIONSZENTRUM UND UMGEBUNG  9

  ABBILDUNG 6: FUNKTIONSBEREICHE DES TRANSAKTIONSZENTRUMS  18

  ABBILDUNG 7: INTERNE STRUKTUR EINES TRANSAKTIONSZENTRUMS  21

  ABBILDUNG 8: SEQUENZDIAGRAMM ZUR AUFGABE „STATISTIK ERSTELLEN“, TEIL 1  25

  ABBILDUNG 9: SEQUENZDIAGRAMM ZUR AUFGABE STATISTIK ERSTELLEN , TEIL 2  26

  ABBILDUNG 10: WATCHDOG AGENT  30

  ABBILDUNG 11: BIBLIOTHEKSSERVER  32

  ABBILDUNG 12: VERBINDUNG EINES TRANSAKTIONSZENTRUMS MIT DER AUßENWELT  34

  ABBILDUNG 13: LASTENTEILUNG  37

  ABBILDUNG 14: DATENAUSTAUSCH ZWISCHEN SYSTEMEN  39

  ABBILDUNG 15: IMPORT UND EXPORT VON DATEN  40

  ABBILDUNG 16: DATENEXPORT HIN ZUM TRANSAKTIONSZENTRUM  43

  ABBILDUNG 17: VERARBEITUNG VON EINGABE MIT REGELWERK  45

  ABBILDUNG 18: FUNKTIONSDIAGRAMM EINES DATA AGGREGATORS  46

  ABBILDUNG 19 INTERNE SOFTWAREKOMPONENTEN  48

  ABBILDUNG 20: ANFRAGEBEARBEITUNG DURCH DEN TRANSAKTIONSKOORDINATOR  49

  ABBILDUNG 21: SOFTWAREKOMPONENTE MESSAGE HANDLER  50

  ABBILDUNG 22: SOFTWAREKOMPONENTE EMPFANG SENDEN  51

  ABBILDUNG 23: SOFTWAREKOMPONENTE IMPORT EXPORT  52

  ABBILDUNG 24: SOFTWAREKOMPONENTE REQUEST ROUTING  53

  ABBILDUNG 25: SOFTWAREKOMPONENTE SICHERHEIT  55

  ABBILDUNG 26: SOFTWAREKOMPONENTE VISUALISIERUNG  56

  ABBILDUNG 27: SOFTWAREKOMPONENTE DATENVERARBEITUNGSPROZESSE  57

  ABBILDUNG 28: SOFTWAREKOMPONENTE DATENHALTUNG  59

  ABBILDUNG 29: SOFTWAREKOMPONENTE DATENPFLEGE  60

  ABBILDUNG 30: SOFTWAREKOMPONENTE LOGISTIK VERSAND  61

  ABBILDUNG 31: SOFTWAREKOMPONENTE E-SERVICES  62

  ABBILDUNG 32: SOFTWAREKOMPONENTE E-MARKETING  63

  ABBILDUNG 33: INTERNE HARDWAREKOMPONENTEN  64

  ABBILDUNG 34: HARDWAREKOMPONENTE DATENBANKSERVER  66

  ABBILDUNG 35: DATA WAREHOUSE UND DATA MARTS  67

X

  Abbildungsverzeichnis Inv Nr 2001 03 29 0008 IN95  2253

  ABBILDUNG 36: HARDWAREKOMPONENTEN EINES EXTERNEN SYSTEMS  69

  ABBILDUNG 37: SOFTWAREKOMPONENTEN EINES EXTERNEN SYSTEMS  69

  ABBILDUNG 38: TAMINO XML DATENBANK ARCHITEKTUR  74

  ABBILDUNG 39: BOLERO ARCHITEKTUR  76

  ABBILDUNG 40: BOLERO UMFELD  77

  ABBILDUNG 41: BOLERO UND ENTIREX  81

  ABBILDUNG 42: TAMINO X-BRIDGE ARCHITEKTUR  82

  ABBILDUNG 43: BEA WEBLOGIC SERVER SCHICHTENMODELL  85

  ABBILDUNG 44: BEA WEBLOGIC CONNECTION POOL  86

  ABBILDUNG 45: BEA WEBLOGIC ANWENDUNGSSCHICHTEN  89

  ABBILDUNG 46: ARCHITEKTUR VON INTERSHOP  92

  ABBILDUNG 47: ENFINITY REMOTE XML INTERFACE  93

  ABBILDUNG 48: INTOS ARCHITEKTUR DATA INTERCHANGE  98

  ABBILDUNG 49: INTOS DATENAUSTAUSCH MIT ANDEREN SYSTEMEN  100

  ABBILDUNG 50: FASHIONMARKET ALS GESAMTDIENSTLEISTER DER MODEBRANCHE  107

  ABBILDUNG 51: GESTALTUNGSDIMENSIONEN UND EINFLUßFAKTOREN DES WEBAUFTRITTS  109

  ABBILDUNG 52: RESTRUKTURIERUNG DER PRODUKTIVDATEN  110

XI

Tabellenverzeichnis Inv Nr  2001 03 29 0008 IN95  2253

  TABELLENVERZEICHNIS  

TABELLE 1:  UNTERSCHIEDE ZWISCHEN EDI UND E-COMMERCE  15

TABELLE 2:  UNTERSCHIEDE ZWISCHEN DATA WAREHOUSE UND DATA MART  68

XII

Abkürzungsverzeichnis

ABKÜRZUNGSVERZEICHNIS

A2A Administration to Administration

A2B A2C ACID Atomic, Consistent, Isolated, Durable API Application Programming Interface ASP Active Server Pages B2A Business to Administration B2B Business to Business B2B2C Business to Business to Consumer B2C Business to Consumer BLOB Binary Large Object C2A Consumer to Administration

C2B Consumer to Business C2C Consumer to Consumer CBL Common Business Library cCommerce Collaborative Commerce CLIP Component Library Integration Package CORBA Common Object Request Broker Architecture CRM Customer Relationship Management CSS Cascading Stylesheets cXML Commercial eXtensible Markup Language DB Database bzw. Datenbank DBMS Database Management System bzw. Datenbank-Management-System DCOM Distributed Component Object Model DMZ De-Militarized Zone DOM Document Object Model DSSSL Document Style Semantics and Specification Language DTD Document Type Definition EAI Enterprise Application Integration eCAPI enfinity Cartridge Application Programming Interface EDI Electronic Data Interchange EDIFACT Electronic Data Interchange For Administration, Commerce And Transport EJB Enterprise Java Beans ERP Enterprise Resource Planning eRXI enfinity Remote XML Interface

XIII

Abkürzungsverzeichnis

FTP File Transfer Protocol GUI Graphical User Interface HTML Hyper Text Markup Language HTTP Hyper Text Transfer Protocol HW Hardware J2EE Java 2 Enterprise Edition JDBC Java Database Connectivity JDK Java Development Kit JMS Java Messaging Service JNDI Java Naming and Directory Interface JSP Java Server Pages JTA Java Transaction API JVM Java Virtual Machine LDAP Lightweight Directory Access Protocol MOF Meta Object Facility ODBC Open Database Connectivity OMG Object Management Group P2P Person to Person, Peer to Peer PDA Personal Digital Assistant PDF Portable Document File PHP PHP: Hypertext Preprocessor RAID Redundant Array of Inexpensive Disks RDBMS Relational Database Management System bzw. Relationales Datenbank-Management-System RMI Remote Method Invocation RMI-IIOP Remote Method Invocation over Internet Inter-ORB Protocol RPC Remote Procedure Call

SAN Storage Area Network SAX Simple API for XML SDK Software Developer’s Kit SGML Standard Generalized Markup Language SMS Short Message Service SQL Structured Query Language SSL Secure Socket Layer SW Software TAK Transaktionskoordinator TAZ Transaktionszentrum TLE Template Language Extension (v. Intershop)

XIV

Abkürzungsverzeichnis

UML Unified Modelling Language UMTS Universal Mobile Telecommunications System URL Uniform Resource Locator W3C World Wide Web Consortium WAP Wireless Application Protocol WDDX Web Distributed Data eXchange

WML WWS WWW World Wide Web XMI XML Metadata Interchange XML eXtensible Markup Language XQL eXtensible Query Language XSL eXtensible Stylesheet Language, eXtensible Style Language XSLT eXtensible Stylesheet Language Transformations, eXtensible Style Language

1 Einleitung

1. EINLEITUNG

1.1. Überblick und Motivation

E-Business als Schlagwort für die elektronische Abwicklung von Geschäftsprozessen, unter Integration der Bereiche Einkauf, Logistik und Produktion, ist ein Thema, das im Zeitalter des Internets zunehmend an Bedeutung gewinnt. Die elektronische Geschäftsabwicklung wird geprägt durch das Verbinden und Einbinden heterogener Systeme und die Eingliederung verschiedenster informationstechnischer, betriebswirtschaftlicher und logistischer Konzepte, wie die nächste Abbildung verdeutlicht.

Die Abbildung zeigt Einflußfaktoren auf das zentrale Geschäftsfeld E-Business. Einige wesentliche Einflußfaktoren basieren auf informationstechnischen, andere auf betriebswirtschaftlichen Grundlagen. Die Bereiche Multimedia und Geschäftsprozesse können beiden

¹ Nach [MER99], S. 6.

1

1 Einleitung

Richtungen zugeordnet werden. Im Rahmen dieser Arbeit werden hauptsächlich die informationstechnischen Belange berücksichtigt, dabei steht die Betrachtung softwaretechnischer Aspekte im Vordergrund. Betriebswirtschaftliche und logistische Problematiken werden nur am Rande betrachtet.

Trotz aller Euphorie muß eine Unternehmung, die elektronische Dienste anbieten und Transaktionen abwickeln will, ein solides informationstechnisches Fundament besitzen. Zu oft konnte man beobachten oder sogar im Internet auf den entsprechenden Seiten von E-Commerce Anbietern selbst nachprüfen, daß die technischen Strukturen insgesamt nicht ausreichend durchdacht und nicht marktgerecht realisiert wurden ² . Dies gilt um so mehr für noch nicht im Internet vertretene Unternehmen, bei denen momentan kaum die Voraussetzungen dafür vorhanden sind, am elektronischen Handel teilzunehmen. Dies kann durch Fehlen geeigneter Schnittstellen oder durch mangelnde Voraussetzungen in der IT-Infrastruktur des Unternehmens selbst bedingt sein.

Mittlerweile stellt sich für viele Firmen nicht die Frage, ob E-Business zu betreiben ist, sondern wann der günstigste Zeitraum für den Markteintritt ist und wie sich dieser Eintritt gestaltet. Der Wettbewerbsdruck im E-Business Markt wächst an, weil einerseits große Unternehmen den Markt penetrieren ³ und andererseits Gesellschaft, Wirtschaft, Politik und technologischer Fortschritt das E-Business Zeitalter begründen und antreiben ⁴ . Dies führt auf-grund der rasanten Geschwindigkeit, mit der dies vonstatten geht, zu einem relativ unkontrollierten Wachstum, durch das sich der Markt im Laufe der Zeit selbst regulieren wird.

Motivation dieser Arbeit ist es, Strukturen und Mechanismen aus dem Gebiet der Softwaretechnik zu entwickeln. Diese sollen nicht nur die Bereitstellung „ klassischer“ Services im E-Business ermöglichen, wie dies bei elektronischen Marktplätzen, Malls und Portalen der Fall ist, sondern auch die Voraussetzungen für eine tiefgreifende Integration von Geschäftseinheiten schaffen. Ein wichtiger Grund für die Integration vieler Teilnehmer auf einer Plattform ist, daß die administrativen Kosten eines verteilten Systems wesentlich geringer sind als die von mehreren, von einander unabhängigen Systemen. Elektronische Services und Informationen sollen allen Kunden des Dienstes unter Berücksichtigung aktueller Standards und Schnittstellen zugänglich sein.

² Beispiel: bis ins 4. Quartal 2000 war die Yahoo! Shopping Mall für teilnehmende Anbieter finanziell und

organisatorisch eine Zumutung und für Besucher wenig bedienerfreundlich.

³ Beispiel: eVita von der Deutschen Post als elektronischer Marktplatz samt eigenem Shop und elektroni-

schem Arbeitsmarkt.

⁴ Vgl. [KUN00].

2

1 Einleitung

Die in dieser Arbeit entwickelte Architektur, die die Bereitstellung und komplexe Abwicklung elektronischer Geschäftsprozesse ermöglicht sowie Geschäftseinheiten integriert, Transaktionen abwickelt, und dabei als Informations-, Dienst- und Request-Broker, Verzeichnisdienst und Service Provider auftritt, wird im folgenden als „ E-Business - Transaktionszentrum“ bezeichnet.

Die folgende Abbildung, die schematisch die prognostizierte mittelfristige Entwicklung des B2B ⁵ Marktes darstellt, veranschaulicht die Notwendigkeit, zukunftsträchtige Strukturen zu besitzen.

Ohne geeignete informationstechnische Strukturen ist es auf längere Sicht nicht möglich, den sich aufgrund des schnellen Wandels der Technologien ergebenden, wachsenden Anforderungen gerecht zu werden sowie nicht zu den Opfern der Konsolidierungs- und Restrukturierungsphase zu gehören.

Die Vorteile von E-Business sind bekannt, jedoch müssen vorhandene Risiken weitgehend durch ein ausgereiftes Konzept beseitigt werden.

⁵ B2B = Business to Business.

⁶ Quelle: [DUB00], S. 55.

3

1 Einleitung

1.2. Aufgabenstellung und Gliederung der Arbeit

1.2.1. Aufgabenstellung

Geschäftseinheiten ⁷ , die gemeinsam einen Dienst nutzen wollen, müssen sich in geeigneter Weise an diesen Dienst anbinden lassen. Die Anbindung erfolgt über Schnittstellen, für die sich mittlerweile einige Standards etabliert haben. Einerseits existieren Formate für den dateibasierten Austausch von Informationen, andererseits gibt es Protokolle für den Austausch von Datenströmen über das Internet. Ein Schwerpunkt dieser Arbeit liegt in der Betrachtung des dateibasierten Informationsaustausches. Gleichzeitig muß ein Dienst, der Geschäftsprozesse bereitstellt sowie entsprechende Mehrwertservices dazu anbietet, entsprechende Strukturen anbieten, die den angebundenen Einheiten die Abwicklung von Transaktionen erlauben.

Skalierbarkeit des Gesamtsystems steht bei E-Business stark im Vordergrund, da bei positivem Geschäftsverlauf die Anzahl der Teilnehmer am System extrem hoch sein kann. Ein theoretisches, ideales Ziel für ein E-Business Transaktionszentrum ist es, sich bezüglich des Kommunikationsumfangs dem World Wide Web so weit wie möglich anzunähern. Deshalb muß jede Komponente des Systems skalierbar sein. Wie in der nächsten Abbildung dargestellt ist, gibt es drei Hauptgründe für Wachstum: Steigerung des Datenvolumens, Erhöhung der Funktionalität und eine höhere Anzahl Anwender.

⁷ Hiermit sind neben Anbietern von Dienstleistungen oder Waren auch Kunden (privat oder kommerziell)

des Dienstes gemeint.

⁸ Vgl. [MAR98], S.92.

4

1 Einleitung

Jedes dieser genannten Kriterien muß in der Architektur eines E-Business Systems durch geeignete Maßnahmen entsprechende Berücksichtigung finden.

Aufgabe dieser Arbeit ist die Vorstellung eines Architekturkonzeptes, das verschiedene Aspekte eines E-Business Transaktionszentrums berücksichtigt. Darüber hinaus werden Konzepte von auf dem Markt befindlichen Systemen präsentiert und bewertet. Alle entwikkelten und vorgestellten Konzepte sind als Vorschlag zu verstehen und sollen helfen, für zukünftige Projekte softwaretechnische Analysen sowie das Treffen von Entwurfsentscheidungen durch Aufzeigen von Möglichkeiten zu vereinfachen.

1.2.2. Gliederung der Arbeit

Die Diplomarbeit gliedert sich im wesentlichen in fünf Teile:

Kapitel 1,2: Einleitung und Grundlagen

Kapitel 3: Anforderungen an ein E-Business Transaktionszentrum Kapitel 4: Erstellung eines Architekturkonzeptes für ein E-Business Transaktionszentrum Kapitel 5: Vorstellung und Evaluierung von Konzepten vorhandener Systeme und abschließende Gesamtbewertung Kapitel 6: Praxisbeispiel „ fashionmarket AG“

Im ersten und zweiten Kapitel wird die Aufgabenstellung und Motivation der Arbeit erläutert. Weiterhin werden Begriffe definiert sowie Grundlagen vermittelt.

Allgemeine informationstechnische Anforderungen an ein E-Business Transaktionszentrum werden im dritten Kapitel dargestellt.

Den Kern des vierten Kapitels bildet die Entwicklung eines Architekturkonzeptes für ein E-Business Transaktionszentrum, das softwaretechnische Belange berücksichtigt. Dieser Abschnitt bildet den ersten Hauptteil der Arbeit.

Das fünfte Kapitel beschäftigt sich mit der Vorstellung und Bewertung von Konzepten von auf dem Markt verfügbaren Systemen, die im Bereich E-Business eingesetzt werden können. Am Ende des Kapitels folgt eine Gesamtbewertung der in dieser Arbeit vorgestellten Konzepte. Dieser Abschnitt bildet den zweiten Hauptteil der Arbeit.

Schließlich folgt im sechsten Kapitel ein Praxisbericht über die Konzeptionierung und Implementierung eines E-Business Systems bei der fashionmarket AG. Exemplarisch wird hier

5

1 Einleitung

dargestellt, welche Lösungsansätze zur Umsetzung vom Konzept hin zum System verwendet wurden und wie das bestehende Online Shopsystem erweitert wurde.

Den Abschluß der Arbeit bilden die Schlußbetrachtungen und ein Ausblick auf mögliche zukünftige Entwicklungen.

1.3. Konventionen

Die in dieser Arbeit verwendeten Abkürzungen werden zusätzlich zur Beschreibung im Abkürzungsverzeichnis bei der ersten Verwendung in einer Fußnote erklärt und danach als bekannt vorausgesetzt.

Englische Begriffe und Terminologie, Abkürzungen, Firmennamen und Produktnamen werden zur Kennzeichnung kursiv gedruckt. Eine Ausnahme sind sehr häufig verwendete Begriffe wie XML und E-Business und gebräuchliche englische Bezeichnungen wie beispielsweise Client oder Server.

Abkürzungen, die im Plural verwendet werden, sind ohne nachgestelltes „ s“ geschrieben.

6

2 Grundlagen

2. GRUNDLAGEN

2.1. Einleitung

Aufgrund des schnellen Wandels der Informationstechnologie werden manche Begriffe oft in unterschiedlicher Bedeutung verwendet. Die folgenden Begriffserklärungen dienen dazu, Grundlagen zu vermitteln sowie die Bedeutung von in dieser Arbeit häufig verwendeten Begriffen zu definieren und mögliche Doppelbedeutungen zu beseitigen.

2.2. Begriffserklärungen

2.2.1. Die Begriffe E-Business und E-Commerce

E-Commerce (Electronic Commerce) ist ein Teil des E-Business und beinhaltet die elektronische Abwicklung von Geschäftsprozessen zwischen Marktteilnehmern über Datennetze wie etwa das Internet.

Eine von vielen Definitionen für E-Commerce ist, daß in einem Unternehmen E-Commerce durchgeführt wird, wenn mindestens elementare Transaktionen wie Bezahlung und Lieferung über elektronische Märkte abgewickelt werden. Bestandteil des E-Commerce ist unter anderem der Kauf und Verkauf von Ware über Online Plattformen sowie das Management der zugehörigen Logistik.

E-Business erweitert dieses Umfeld durch umfassende Integration von Einkauf, Logistik und Produktion sowie durch Ermöglichen von Partnerschaften zwischen Kunden und Lieferanten sowie Kundenservice, Back Office und Front Office Dienste ⁹ . Unter E-Business versteht man also die Bereitstellung aller Voraussetzungen, um E-Commerce betreiben zu können ¹⁰ .

Am E-Business beteiligte Geschäftseinheiten, das können zum Beispiel Unternehmen, Pri-vatkunden und Institutionen sein, stehen in unterschiedlicher Beziehung zueinander. Mögliche Beziehungen stellt folgende Graphik dar.

⁹ Vgl. [LOM00], S.1.

¹⁰ Vgl. [KAL00], S.1.

7

2 Grundlagen

Hauptsächlich werden in der vorliegenden Arbeit Beziehungen zwischen verschiedenen Unternehmen (B2B) als auch zwischen Unternehmen und Kunden (B2C ¹¹ ) betrachtet. Alle anderen Beziehungen spielen hier, so wie auch momentan auf dem Markt, eine unterge-ordnete Rolle. Neben den dargestellten Gruppen von Geschäftseinheiten wird in der Literatur eine weitere Gruppe erwähnt, nämlich die der Angestellten, die mit „ E“ wie Employee abgekürzt wird. Weiterhin wird auch von Geschäftsbeziehungen zwischen Personen gesprochen, die man als Person to Person (P2P) oder Peer to Peer bezeichnet. Privatleute treten in diesem Fall nicht nur als Konsumenten, sondern auch als Anbieter auf, beispielsweise als Verkäufer auf Auktionen.

2.2.2. Der Begriff des E-Business Transaktionszentrums

Kern dieser Arbeit ist die Ausarbeitung und Vorstellung von Architekturkonzepten für E-Business Transaktionszentren. Unter einem Transaktionszentrum wird eine zentrale Service-plattform verstanden, die zur Bereitstellung von elektronischen Services Transaktionen abwickelt. Dabei wickelt das Transaktionszentrum nicht nur Geschäftsprozesse ab, sondern stellt diese auch bereit. Das Transaktionszentrum ist ein Intermediär, also Vermittler, zwischen einzelnen Marktteilnehmern und Gruppen. Die nächste Graphik zeigt auszugsweise, welche Geschäftseinheiten an ein E-Business Transaktionszentrum angebunden sein können.

¹¹ B2C = Business to Consumer.

8

2 Grundlagen

Kern der dargestellten Abbildung ist das Transaktionszentrum, mit TAZ abgekürzt. An das Transaktionszentrum sind verschiedene Dienstnutzer wie Kunden, Dienstleister oder Verkäufer angebunden. Die Linien zwischen Dienstnutzern stellen Beziehungen zwischen den angebundenen Geschäftseinheiten dar, die Linien zwischen Dienstnutzern und Transaktionszentrum deuten eine direkte Verbindung zwischen diesen beiden Parteien an. Ein Transaktionszentrum integriert die Funktionalität von elektronischem Marktplatz, zentraler Verwaltungsstelle und Transaktionsabwicklungszentrale und stellt sie den dargestellten Geschäftseinheiten zur Verfügung. Die bereitgestellte Funktionalität trägt zur Finanzierung des Transaktionszentrums bei, entweder direkt über entsprechende Abrechnungsmodelle oder indirekt über Werbung.

Mittels eines Transaktionszentrums sind Kommunikations- und Geschäftsverbindungen jeglicher Art realisierbar, sofern die Geschäftspartner über eine entsprechende Anbindung

9

2 Grundlagen

verfügen. Anbieter von Waren und Dienstleistungen, die an das Transaktionszentrum an-gebunden sind, können und sollen selbständig ihre Daten und Angebote administrieren. Dies kann beispielsweise mit Hilfe von Workflows geschehen. Das reduziert den Arbeits-aufwand für den Betreiber des zentralen Services und überträgt die Verantwortung hauptsächlich an die Geschäftspartner selbst.

Ein Transaktionszentrum orientiert sich zunächst, genau wie ein Marktplatz, ein Online Shop oder ein Portal, an einer Thematik. Dies kann etwa Mode, Sport oder der Buchhandel sein, wobei es nicht ausgeschlossen ist, daß neue Themengebiete hinzukommen.

Im Gegensatz zum elektronischen Marktplatz bietet ein Transaktionszentrum nicht nur die direkten Verbindungen von B2B oder B2C, sondern auch darüber hinaus gehende, wie B2B2C ¹² an. Die Funktionalität eines Transaktionszentrums geht hin bis zur Unterstützung von angebundenen Geschäftseinheiten über angebotene Zusatz- und Hilfsmodule. Diese vereinfachen die Anbindung und den Datenaustausch mit dem Transaktionszentrum. Anders als beim Portal, das noch weniger Funktionalität als ein Marktplatz besitzt, werden nicht nur Verweise auf andere Dienste angeboten. Darüber hinaus werden diese Dienste auch gesteuert und überwacht und tragen oft ¹³ zum direkten Profit des Transaktionszentrums bei.

Das Transaktionszentrum vermittelt Anbieter und Kunden, möglichst immer über den indirekten Weg, nämlich über die Plattform des Transaktionszentrums selbst. Es tritt beratend gegenüber Geschäftspartnern auf. Die Beratung findet weitgehend automatisch und auf elektronischem Wege über elektronische Services statt und nicht in der klassischen Form eines persönlichen Beraters.

Zum Betrieb eines Transaktionszentrums sind umfangreiche Hardware- und Softwareanforderungen zu erfüllen. Hauptsächlich kommen größere Firmen als Betreiber in Frage, davon ausgehend, daß der Betreiber eine entsprechende Plattform selbst entwickelt.

Ein Transaktionszentrum kann in drei logische Schichten unterteilt werden ¹⁴ :

¹² B2B2C bedeutet hier, daß ein Kunde (C) indirekt über einen Zwischenhändler (B) mit einem anderen

kommerziellen Anbieter (B) in Geschäftsbeziehung steht.

¹³ Die Abwicklung von Geschäftsprozessen ist Hauptbestandteil des Transaktionszentrums. Andere Dien-

ste wie Newsletter oder elektronische Foren stehen nicht im Vordergrund, sondern sind Zusatzservices.

¹⁴ Siehe auch [MAR98], S.96.

10

2 Grundlagen

Zum einen handelt es sich um die hardwaretechnische Realisierung des zugehörigen Systems. Diese umfaßt hauptsächlich die Netzwerkarchitektur, die verschiedenen notwendigen Server wie Datenbankserver, Anwendungsserver, File Server, aber auch Sicherheitsvorkehrungen wie Firewalls oder Performancesteigerung durch Lastenteilung. Ein weiterer Bestandteil ist die softwaretechnische Realisierung, also die Bereitstellung einer für den Betrieb geeigneten Infrastruktur. Dazu zählen Schnittstellen, Module und Applikationen zur Bereitstellung der notwendigen E-Business Funktionalitäten sowie Software im engeren Sinne wie zum Beispiel Datenbanksysteme.

Die dritte Komponente ist die Beschaffung von Informationen durch entsprechende Personen. Diese Informationen werden den Marktteilnehmern in Form von Mehrwertdiensten wie Newslettern zur Verfügung gestellt. Ergänzend dazu sind interne Daten und Informationen über Marktteilnehmer zu pflegen und Statistiken zu erstellen.

Wichtigster Bestandteil eines Transaktionszentrums ist der Kern des Systems, dessen Hauptkomponente der Transaktionskoordinator ist, wie er in dieser Arbeit genannt wird. Der Message Handler als Teil des Transaktionskoordinators ist dabei für die Verarbeitung, Aufbereitung und Weiterleitung von Meldungen zuständig. Der Transaktionskoordinator hat insgesamt die Aufgabe, Abläufe zu steuern. Informationen werden in diesem Zusammenhang auch als wichtige Komponente zur Erzielung und Beschleunigung einer möglichen Transaktion angesehen.

11

3 Anforderungen an ein E-Business Transaktionszentrum

3. ANFORDERUNGEN AN EIN E-BUSINESS TRANSAK- TIONSZENTRUM

3.1. Überblick

Der Begriff des E-Business Transaktionszentrums 15 wurde im Kapitel Grundlagen bereits erläutert. In diesem Kapitel wird näher beschrieben, welche informationstechnischen An-forderungen ein solches Transaktionszentrum im allgemeinen zu erfüllen hat. Im darauf folgenden Kapitel werden dann informationstechnische Konzepte vorgestellt.

Wesentliche Bestandteile eines E-Business Transaktionszentrums, das in dieser Arbeit betrachtet wird, sind:

• Bereitstellen von Schnittstellen und Mechanismen zum Datenimport und -export

• Anbinden externer Systeme und Zusammenspiel mit diesen

• Bereitstellen von Dialogen und Masken zur Eingabe von Daten und Informationen

• Bereitstellen, Ermöglichen und Abwickeln von Geschäftsprozessen und elektronischen Services

• Koordinieren und Durchführen von Transaktionen

• Durchführen von Datenhaltung, Datenaufbereitung, Datenarchivierung und Datensicherung

• Bereitstellen von Zugriffsmöglichkeiten für Administratoren und Außendienst

Die Anforderungen an ein Transaktionszentrum sind vielfältig. Die Integration von Standards wie XML ¹⁶ oder EDI 17 ist entscheidend, um möglichst vielen Geschäftseinheiten einen standardisierten Zugang zu ermöglichen. Das Sicherstellen von Hochverfügbarkeit und ausreichender Performance muß gewährleistet werden, damit Kunden dem Dienst Vertrauen entgegen bringen können und zufrieden sind. Das Absichern aller Daten, Transaktionen und Geschäftsprozesse gegen Datenverlust, Instabilität und unbefugten Zugriff ist zwar selbstverständlich, gestaltet sich in der Praxis aber schwierig. Gleichzeitig ist sicherzustellen, daß der administrative Aufwands für den Betreiber des Transaktionszentrums so gering wie möglich ist. Eine steigende Anzahl von Dienstnutzern wirkt sich ansonsten negativ auf die Handlungsfähigkeit des Dienstbetreibers aus. Deshalb

¹⁵ Im folgenden oft mit TAZ abgekürzt.

¹⁶ XML = eXtensible Markup Language.

¹⁷ EDI = Electronic Data Interchange.

12