Diese Publikation erschien im Tagungsband der internationalen Konferenz Wirtschaftsinformatik 2003 in Dresden
Relevanz und Komplexität der Aufgabenstellung zwischenbetrieblicher Integration haben sich mit dem Electronic Business weiter erhöht. Dies gilt insbesondere für eine spezifische Erscheinungsform des Electronic Business, die Elektronischen Marktplätze. Speziell im Business-to-Business-Bereich (B2B) haben diese internetbasierten Handelsplattformen, auf denen Verkäufer und Käufer in virtueller Weise aufeinander treffen, in den letzten Jahren stark an Bedeutung gewonnen und für die Zukunft wird weiteres Wachstum prognostiziert, trotz derzeit beobachtbarer Konsolidierungsbewegung. Der Beitrag beschreibt Merkmale und Vorgehensweisen der Integration im Electronic Business, insbesondere für Elektronische Marktplätze. Es werden ein Referenzmodellierungsansatz für Marktplätze sowie Kriterien der Leistungsfähigkeit für Elektroische Marktplätze betrachtet, um darauf aufbauend eine Zielformulierung für Integrationslösungen abzuleiten. Im Rahmen des Betrags wird ein Ansatz eines Referenzmodells für Integrationslösungen vorgestellt.
Schlüsselworte: Integration von IV-Systemen, Electronic Business, Elektronische Marktplätze, Enterprise Application Integration, Referenzmodell der Integration
Die zwischenbetriebliche Integration ist mit der Entstehung des Electronic Business noch bedeutender und komplexer geworden. Besonders gilt dies für die spezifische Erscheinungsform Elektronische Marktplätze (EMP). Ein zentraler Erfolgsfaktor im B2B-Bereich ist der Austausch von Informationen zwischen dem EMP und den innerbetrieblichen Anwendungssystemen der Marktplatz-Teilnehmer [WiRa00, 7]. Dazu müssen der EMP und die innerbetrieblichen Anwendungssysteme gekoppelt werden. Für diesen Zweck sind Integrationslösungen erforderlich, die unter Zuhilfenahme verschiedener Technologien eine automatische Kommunikation zwischen verschiedenen Anwendungssystemen ermöglichen sollen. Für die Analyse der Integrationsanforderungen von EMP werden im Folgenden verschiedene Ausprägungen von EMP kurz dargestellt, Kriterien der Leistungsfähigkeit für EMP hergeleitet und daraus die Zielsetzungen für Integrationslösungen bestimmt.
Markt, Hierarchie und Netzwerk gelten als die drei wichtigsten, wirtschaftlichen Koordinationssysteme [Powe91; ThFr91; Lind00, 36ff; Zbor96, 45ff]. Wird ein Markt durch den Einsatz der Informationsverarbeitung (IV) realisiert, wird analog von Elektronischem Markt gesprochen [Zbor96, 57], welcher sich z. B. als EMP konkretisiert. Der Begriff EMP wird in der Literatur häufig synonym zu E-Market[ScSc00], elektronischem Handelssystem [Zbor96] oder allgemein für Electronic-Commerce-Anwendungen [Hent01; Kelk01; Merz02] verwendet.
Aus Sicht der IV ist der EMP eine konkrete Implementierung, bestehend aus mehreren Anwendungssystemen, die die elektronische Abwicklung der Transaktionsphasen des Kaufprozesses ermöglichen und unterstützen [Mert01a, 61; Zbor96,138ff; Merz02, 18f; Lind00, 36]. Beispiele für entsprechende Anwendungssysteme sind elektronische Kataloge, Shop-Systeme mit Warenkorb oder Software für dynamische Preisfindungsmethoden.
Zur Unterscheidung von EMP sind eine Vielzahl von Merkmalen und zugehörigen Ausprägungen bekannt. Wir verzichten bewusst auf eine ausführliche Darlegung und verweisen auf einschlägige Literatur [Koll01, 33ff; ScSc00, 98ff; WiMa01; Beiträge zur Integrationsproblematik im Kontext von Electronic Business und Elektronischen Marktplätzen 3BuKr00; PWC02, 11ff]. Einen Überblick über die in der Literatur am weitestenverbreiteten Merkmale gibt Abbildung 1.
Die einzelnen Merkmalsausprägungen in Abbildung 1 bedingen sich zumeist gegenseitig. So werden z. B. MRO-Produkte (Maintenance, Repair und Operation) heute üblicherweise auf einem geschlossenen B2B-EMP in Form einer Buy-Side-Lösung zu Festpreisen gehandelt [Hent01, 51]. Diese Kombination von Merkmalsausprägungen wird auch als Electronic Procurement bezeichnet und stellt ein spezielles Geschäftsmodell für EMP dar [Stäh01, 41f].
Eine Kombination von Merkmalsausprägungen definiert somit ein eigenes, charakteristisches Geschäftsmodell mit speziell ausgeprägten Transaktionsphasen innerhalb des Kaufprozesses. Die unterschiedlichen Geschäftsmodelle erfordern spezifische Integrationsszenarios. Bei der Definition von Integrationsanforderungen müssen deshalb möglichst viele Geschäftsmodelle berücksichtigt werden, ebenso gilt es, neben den Marktplatzteilnehmern (Verkäufer und Käufer) auch Marktplatz-Dienstleistungsunternehmen (z. B. Kreditinstitute, Speditionen) zu berücksichtigen.
Zusammenfassen lassen sich alle Kombinationen von Merkmalsausprägungen in einem Referenzmodell. Daher verwenden wir als Basis für weitere Überlegungen im Folgenden das Referenzmodell Elektronischer Märkte, welches durch die Forschungsgruppe „Elektronische Märkte“ des Instituts für Medien- und Kommunikationsmanagement der Universität St. Gallen entwickelt [Schm99; UniG02; erst-mals in LiSc98] und mit besonderer Ausrichtung auf das Internet, speziell für EMP, verfeinert wurde [Lind00].
Mit der Integration von Anwendungssystemen werden verschiedene Ziele verfolgt, die sich als Steigerung der Leistungsfähigkeit des Gesamtsystems zusammenfassen lassen. Dazu wird im Folgenden der Begriff der Leistungsfähigkeit näher untersucht und die resultierenden Integrationsanforderungen bestimmt.
Wie bereits dargestellt, ist der Markt neben Hierarchie und Netzwerk eines der drei wirtschaftlichen Koordinationssysteme. Zur Messung der Leistungsfähigkeit eines Koordinationssystems unterscheidet die Koordinationstheorie die zwei generellen Kriterien Effizienz und Flexibilität, vergleiche Abbildung 2. Besonders der Markt als eine der drei Ausprägungen im Koordinationsformen-Kontinuum hat den Anspruch, Effizienz und Flexibilität gleichzeitig in einem hohen Maß abzudecken (vgl. [Lind00, 88]). Für elektronische Koordinationssysteme gelten die Kriterien Effizienz und Flexibilität analog, wobei sich mit steigender Effizienz und Flexibilität die Leistungsfähigkeit eines EMP erhöht.
An dieser Stelle sei auf den unserer Meinung nach schwach erkennbaren Bezug zum Effektivitätsbegriff in diesem Modell verwiesen. Der (allgemeine) Effizienz- oder Wirksamkeitsbegriff stellt einen ökonomischen Vergleich dar, mit den beiden Ausprägungen des ökonomischen Prinzips (Minimal-/Maximalprinzip), während der Effektivitäts- oder Wirkungskraftbegriff auf ein zielgerichtetes Maß hinweist. Im Kontext von Koordinationsformen kann Effektivität als eine vorgelagerte Fragestellung interpretiert werden, wodurch die Wahl der Koordinationsform Markt unter den drei Alternativen Markt, Hierarchie und Netzwerk bereits das Effektivitätskriterium impliziert. Konkret im Kontext EMP könnte dies die strategische Entscheidung eines Unternehmens zur Teilnahme an einem bestimmten Marktplatz oder gar zur Errichtung einer eigenen Marktplatzlösung darstellen.
Lindemann beschreibt ausführlich die Effizienz von EMP anhand des Referenzmodells für EMP [Lind00, 162ff]. Nach Lindemann wird ein EMP als effizient bezeichnet:
1. wenn die Angebote im Markt sämtliche verfügbaren Informationen, wie z. B. vergangene Preise, Verfügbarkeit, öffentlich zugängliche Informationen und Insiderinformationen, umfassen (Effizienz der Informationsreichhaltigkeit).
2. wenn sich der operative Betrieb dem Ideal eines Marktes ohne Reibungsverluste annähert. Hierzu hat der EMP über die einzelnen Transaktionsphasen des Kaufprozesses hinweg Vertrauens-, Geschwindigkeits-, Qualitäts-, Kosten- und Liquiditätsanforderungen zu genügen. Dieser Teil der Markteffizienz beinhaltet zudem technologische Aspekte, wie z. B. Systemverfügbarkeit und -geschwindigkeit (Effizienz des operativen Betriebes).
3. wenn die Marktpreise den tatsächlichen Wert eines Produktes möglichst genau wiedergeben (Effizienz der Preisgenauigkeit).
4. wenn sein Geschäftsmodell eine Allokation der verfügbaren Ressourcen bewirkt, die dem Pareto-Optimum möglichst nahe kommt (Effizienz der Marktgemeinschaft).
Die Effizienz spielt demzufolge in allen Transaktionsphasen des Kaufprozesses sowohl in organisatorisch-strategischer als auch in technologisch-operativer Hinsicht eine Rolle.
Flexibilität wird als Fähigkeit verstanden, sich an veränderte Situationen anpassen zu können. Für einen EMP stellt dies die Notwendigkeit dar, sich schnell auf neue Bedingungen in der Umwelt bzw. im Umfeld (vergleiche mit Branchenstrukturanalyse von Porter [Lück94]) einzustellen und den veränderten Anforderungen zu genügen [HeSa01, 341]. Zum Beispiel ist es notwendig, schnell und unkompliziert einen neuen Verkäufer als EMP-Teilnehmer zu integrieren. Nur durch Flexibilität kann die Forderung nach einer hohen Effizienz erfüllt und dauerhaft gesichert werden.
Angebot und Nachfrage können durch die Marktteilnehmer nur gestellt werden, wenn die Möglichkeit der Teilnahme auf dem Markt grundsätzlich gegeben ist. Die Leistungsfähigkeit eines Marktes wird demnach stark dadurch bestimmt, wie gut es gelingt, die Partizipation der Teilnehmer am Marktgeschehen zu ermöglichen. Die technologische Brücke zwischen EMP und den EMP-Teilnehmern bilden die Integrationslösungen. Die Leistungsfähigkeit eines EMP wird also stark dadurch bestimmt, wie gut es gelingt, die IV-technische Integration der EMP-Teilnehmer zu realisieren, wobei die realisierten Integrationslösungen der Maxime folgen müssen, größtmögliche Flexibilität und Effizienz für einen EMP und seine Teilnehmer zu bieten.
Wie bereits dargestellt, muss die Definition der Anforderungen an Integrationslösungen unter der Prämisse durchgeführt werden, ausreichende bzw. angemessene Effizienz und Flexibilität eines EMP zu erreichen. Diese Effizienzanforderung strahlt somit nicht nur auf die im Umfeld des EMP zu realisierenden Integrationsszenarios aus, sondern sie ist eine notwendige Bedingung. Für den außerhalb dieses Modells liegenden Begriff der Effektivität wollen wir erneut annehmen, dass er nur auf einer, im Entscheidungshorizont vorgelagerten Meta-Ebene anzusiedeln ist, etwa auf der Ebene der strategischen Unternehmensplanung.
Gesucht sind die Faktoren, die die Effizienz und die Flexibilität einer Integrationslösung bestimmen. Der Begriff Effizienz steht für die im Folgenden ausgeführten konkreten Eigenschaften einer Integrationslösung, vergleiche Abbildung 3 – linker Teil:
Die Quasi-Echtzeit-Interaktion, auch als Realtime bezeichnet, umschreibt die Reaktionszeit des Systems [Lint01, 3f; Lint00, 97f]. Erwartet wird hier eine kurze Reaktionszeit, die sich je nach Anforderungen meist in der Größenordnung von wenigen Sekunden bewegt, jedoch erheblich vom Integrationsszenario abhängt und daher auch deutlich länger sein kann.¹ Bei einer Mensch-Maschine-Kommunikation muss für den Benutzer ein unterbrechungsfreier Arbeitsablauf gewährleistet sein. Im Falle einer Maschine-Maschine-Kommunikation ist eine ereignisgesteuerte Kopplung notwendig. Diese lässt das eine System sofort reagieren, wenn ein definiertes Ereignis in einem anderen System auftritt. Das Pendant zur ereignisgesteuerten ist die zeitgesteuerte Kopplung, die oftmals für eine Massenübertragung von Daten (Batchlauf) verwendet wird (vgl. [ScLZ01, 34]).
Die Transaktionssicherheit einer Interaktion ist gegeben, sofern die Interaktion mehrere Prozesse beinhaltet und nur dann ausgeführt wird, wenn sich auch alle Einzelprozesse ausführen lassen. Im anderen Fall wird keiner der Einzelprozesse verwirklicht. (Anmerkung: Der hier verwendete Begriff der Transaktion ist zu unterscheiden von dem Begriff der Transaktionsphasen innerhalb eines Kaufprozesses.)
Eine Interaktion ist im engeren Sinn transaktionssicher (transaktional), wenn die sogenannten ACID-Eigenschaften (Atomic, Consistent, Isolated, Durable) zutreffen [RuMa01, 108ff; Lint01, 153ff; Lint00, 143ff; ComZ02]. Diese lassen sich jedoch auf Basis der heute verfügbaren Technologien nur bei enger Kopplung von Systemen realisieren. Bei lose gekoppelten Systemen können nicht alle ACID-Eigenschaften gewährleistet werden. An ihre Stelle müssen Ersatzmechanismen treten.
Neben der soeben erläuterten Effizienz steht auf der anderen Seite die Forderung nach Flexibilität, vergleiche Abbildung 3 – rechter Teil. Marktplatzteilnehmer müssen die Möglichkeit haben, schnell und unkompliziert an einem EMP teilzunehmen. Im Einzelnen beinhaltet dies:
Einfache Integrationslösungen sind unkompliziert zu handhabende Systeme und vorwiegend durch Budget- und Zeitrestriktionen geprägt. So kann es bei großen Datenmengen, die nur einmalig zu bewegen sind und die keine Reaktion des Systems erfordern, durchaus sinnvoll sein, eine Batchverarbeitung einzusetzen und damit auf die Forderung nach Effizienz (Echtzeitinteraktion und Transaktionssicherheit) zu verzichten. Aber gerade Kopplungen, die der Forderung nach Effizienz gerecht werden, müssen einfach zu etablieren sein.
Unter der Unabhängigkeit der Systeme soll verstanden werden, dass bei einem Ausfall eines der beteiligten Systeme die anderen Systeme weiterarbeiten können. Dabei ist durchaus hinzunehmen, dass spezielle Funktionen, die das ausgefallene System prinzipiell bereitstellt, nicht mehr verfügbar sind. Asynchrone Kopplungen bieten im Gegensatz zu synchronen Kopplungen diese Unabhängigkeit [RuMa01, 40ff; Lint00, 135ff]. Es ist jedoch sicherzustellen, dass alle anderen Funktionen, unabhängig vom ausgefallenen System, zur Verfügung stehen.
Bei der Integration über Unternehmensgrenzen hinweg sind Teilaspekte zu berücksichtigen, die bei der Interaktion von Systemen innerhalb eines Unternehmens nicht oder nur minder relevant sind. Beispiele hierfür sind: Sicherheitsaspekte [Anko02], gleiches Verständnis von betriebswirtschaftlichen Methoden [Mert01a, 3] oder syntaktische Aspekte wie der Aufbau eines Datumsfeldes [Lint01, 239].
Als Fazit ergibt sich eine Trade-off-Situation zwischen Effizienz und Flexibilität. Die Effizienz beschreibt die Arbeitsweise einer Integrationslösung und fordert möglichst enge Kopplungen. Die Flexibilität hingegen beschreibt den Aufwand, eine Integrationslösung zu etablieren oder zu ändern, und fordert möglichst lose Kopplungen.² Die hier geforderte Vereinigung von Effizienz und Flexibilität ist eine Zielstellung, die sich aus technischer Sicht heute bislang widerspricht, da in der Regel ein Zugewinn an Flexibilität mit einem Verlust an Effizienz einhergehen wird. Dennoch gibt sie gleichzeitig die langfristige Zielrichtung für die Entwicklung EMP-tauglicher Integrationslösungen vor.
Eine mögliche Erweiterung dieses Anforderungsprofils für Integrationslösungen wäre die explizite Aufnahme der Dimension Ressourcenverbrauch, in Analogie zum Effizienzkriterium des operativen Betriebs bei Marktplätzen (vgl. Kapitel 1.2). Hierunter sind u. a. die oben erwähnten Restriktionen (vgl. einfache Integrationslösungen) bezüglich Budget und Zeit, aber auch Entwicklungsaufwand (einmalig) und Pflegeaufwand (repetitiv/permanent) in Form von Humanressourcen zu verstehen. Getrieben werden diese Überlegungen von der Erfahrung, dass in praxi häufig sogenannte quick-and-dirty-Lösungen angewandt werden, also meist zeitnahe Implementierungen mit nur grober Spezifikation und vielen Freiheitsgraden hinsichtlich Effizienz und Flexibilität – zu Lasten personeller Interaktion. Es würde also eine Verschiebung der Gewichtung zwischen den Parametern Effizienz, Flexibilität und Ressourcenverbrauch eintreten.
Ohne auf begriffliche Unschärfen zu achten, wurden in diesem Beitrag bisher die Begriffe Integration und Kopplung verwendet, so wie dies leider häufig in einschlägiger Fachliteratur geschieht. Integrieren bedeutet „Herstellen eines Ganzen“ und wird hier als Integration von Anwendungssystemen verstanden. Natürlich sind die Integrationsprobleme im Kontext Marktplätze nicht eine Herstellung einer zusammengehörigen Einheit. Gemeint ist das Verbinden oder Zusammenführen unabhängiger, physisch und logisch getrennter, meist heterogener Systeme. Kopplung wird allgemein als Vehikel zur Bewerkstelligung dieser Integration angesehen. Die Art der Kopplung beschreibt dabei, wie stark die zu integrierenden Systeme voneinander abhängig sind und wie stark eine Änderung in einem System Anpassungsbedarf in dem anderen System induziert (vgl. [RuMa01, 21]). In diesem Kontext verstehen wir die Begriffe enge/lose Kopplung. Konkret kann unter enger Kopplung beispielsweise Datenintegration im Sinne einer gemeinsamen Verwendung von Datenbanken verstanden werden (shared memory), unter loser Kopplung (manchmal mit dem Begriff Anbindung gleichgesetzt) z. B. die Kopplung über Nachrichten.
Im anglo-amerikanischen Sprachraum findet sich des Weiteren das Begriffspaar Kopplung und Kohäsion (Coupling; Cohesion). Linthicum versteht beispielsweise unter Kohäsion „the act or state of sticking together … or … the logical agreement“. Gemeint ist eine hochgradig flexible Kommunikation zwischen heterogenen Systemen im Sinne eines „brokering“. Kopplung hingegen zielt auf die Wiederverwendung von Geschäftsprozessen ab [Lint01, 36f].
Zur Klassifikation von Integrationslösungen müssen Merkmale definiert werden, die es ermöglichen, Integrationslösungen nach einem einheitlichen Maßstab zu bewerten und gegeneinander abzugrenzen. Um dem Anspruch der Allgemeingültigkeit zu genügen, ist es erforderlich, dabei möglichst alle theoretischen Merkmale von Integrationslösungen zu berücksichtigen.
In der Literatur sind verschiedene Modelle zu finden, die Integrationsansätze klassifizieren. Die Modelle berücksichtigen im Allgemeinen ausgewählte Merkmalevon Integrationslösungen, die jeweils aus unterschiedlichen Perspektiven betrachtet werden. Kein vorgefundenes Modell berücksichtigt jedoch die Gesamtheit aller theoretisch möglichen Merkmale und wird dem Anspruch eines allgemein gültigen Referenzmodells, vergleichbar dem Referenzmodell für EMP (vergleiche Kapitel 1.1), gerecht. Insbesondere wurde bei den Integrationslösungen noch keineeinheitliche Terminologie gefunden.
Im Folgenden werden vier generelle Merkmale von Integrationslösungen, losgelöst von einem Modell, betrachtet und näher untersucht. Im Vordergrund stehen inFortführung des Kapitels 1.3 die Merkmale, die wesentlichen Einfluss auf Effizienz und Flexibilität einer Integrationslösung haben, vergleiche Abbildung 4.
Bei den zu untersuchenden Merkmalen handelt es sich um die Ebenen der Kommunikation (Kapitel 2.2), die Standardisierung (Kapitel 2.3), die Systemtopologie (Kapitel 2.4) sowie die Schnittstellen (Kapitel 2.5) der beteiligten Anwendungssysteme. Abbildung 4 fasst diese Merkmale in einer Übersicht zusammen.
Die Integration von Anwendungssystemen bedeutet vereinfacht, eine Kommunikationsverbindung zwischen diesen Systemen einzurichten.Wenn Menschen in diese Kommunikationsverbindung involviert sind, dann sind Verständnis, Interpretation und Weiterbearbeitung einer übermittelten Nachricht gegeben [Hube00, 61]. Gleichzeitig wird eine hohe Flexibilität erreicht. Das Einwirken von Menschen auf die Kommunikationsverbindung erfüllt jedoch nicht die Forderung nach Effizienz von Integrationslösungen, da das zu erwartende Datenvolumen bei einer EMP-Integration hoch ist und die Daten möglichst in Quasi-Echtzeit-Interaktion mit hoher Übertragungssicherheit ausgetauscht werden sollen.
Um die Anforderungen für eine automatisierte Integrationslösung ohne menschliches Einwirken herauszuarbeiten, ist die Kommunikationsverbindung in einzelne Teilebenen zu zerlegen. Dieses Vorgehen basiert auf dem Kommunikationsmodell von Shannon und Weaver [ShWe49], das von verschiedenen Autoren für den elektronischen Datenaustausch weiterentwickelt und angewendet wurde [Zbor96, 93; Hube00, 62; LeZH01, 22; ScLZ01, 33].
Das Modell unterscheidet vier Kommunikationsebenen, die aufeinander aufbauen. Diese sind analog als Ebenen der Integration zu verstehen, vgl. Abbildung 5:
Die technische Ebene der Integration stellt einen gemeinsamen Kommunikationskanal bzw. ein gemeinsames Medium zwischen verschiedenen Anwendungssystemen zur Verfügung und wird durch die sieben Schichten des ISO/OSI-Modells beschrieben, vergleiche ISO 7498 [Buck96, 57-60; Elsi91; Phil91]. Üblicherweise dient bei einer EMP-Integration das TCP/IP-Protokoll als technische Grundlage, das in die mittleren Schichten des ISO/OSI-Modells (Vermittlungs- und Transportschicht) einzuordnen ist [Elsi91, 218ff]. Darauf bauen einerseits typische Internet-Basisdienste (z. B. HTTP, SMTP oder FTP) in den oberen Schichten des ISO/OSI-Modells auf. Andererseits sind Schnittstellen zu Applikationen (vergleiche Kapitel 2.5), wie z. B. ein Remote Procedure Call (RPC), den oberen Schichten des ISO/OSI-Modells zuzuordnen [Buck96, 59]. Ziel der technischen Integration ist die vollständige Übermittlung einer Nachricht.³
Die syntaktische Ebene der Integration behandelt Reihenfolge, Länge und Typ der auszutauschenden Informationen. Als Beispiel dient der fest definierte Aufbau einer elektronisch ausgetauschten Nachricht. Ziel der syntaktischen Integration ist das richtige Lesen einer Nachricht.
Die semantische Ebene der Integration gibt der auszutauschenden Nachricht sowie deren Inhalt eine Bedeutung. Dies ermöglicht auf der einen Seite die Unterscheidung in verschiedene Nachrichtentypen (z. B. Angebot, Lieferschein oder Rechnung) bei sonst identischem Nachrichtenaufbau. Auf der anderen Seite ermöglicht die Semantik einen variablen Aufbau der Nachricht. Beispielsweise kann die Anzahl der Positionen einer Rechnung beliebig sein. Ziel der semantischen Integration ist das richtige Interpretieren einer Nachricht.
Die pragmatische Ebene der Integration umfasst die Interpretation der Absichten, die durch die Nachricht übermittelt werden sollen. Nur so ist es möglich, auf Nachrichten individuell zu reagieren. Zum Beispiel kann eine Integration, die die pragmatische Ebene mit einschließt, bei der Übermittlung einer Anfrage automatisch prüfen, ob der Absender als Kunde bereits existiert. Ziel der pragmatischen Integration ist das richtige Reagieren auf eine Nachricht.
Nur unter Einbeziehung der pragmatischen Ebene lassen sich einzelne oder ganze Abläufe von Geschäftsprozessen automatisiert abwickeln. Solche Integrationslösungen werden in der Literatur als Business Process Integration [Nußd00, 125ff; Walt00; BuCh01, 13ff] oder auch Total Business Integration [Nußd02] bezeichnet.Aus den einzelnen Kommunikationsebenen resultieren unterschiedliche Anforderungen an eine Integration. Diese werden im Folgenden als technisches, syntaktisches, semantisches und pragmatisches Integrationsproblem bezeichnet.
Eine Integration auf dem Niveau einer der oberen Ebenen (Syntax, Semantik, Pragmatik) kann nur erfolgen, wenn die jeweils untergeordneten Integrationsprobleme erfolgreich gelöst wurden. Eine übergeordnete Ebene bedient sich hierbei der darunter liegenden Ebenen. Wenn Integrationsprobleme nicht in eine Integrationslösung einbezogen werden, muss dies durch das Einwirken des Menschen kompensiert werden. Für eine effiziente Integration ist es notwendig, dass alle Integrationsprobleme ohne Brüche der Maschine-Maschine-Kommunikation bewältigt werden. Durch diese Bedingung steht die dem Menschen inhärente Flexibilität für eine Integrationslösung nicht zur Verfügung. Der Schlüssel für eine effiziente und gleichzeitig flexible Integration unter Einbeziehung aller Integrationsprobleme ist die Verwendung von Standards.
Standards definieren einheitliche Regeln für die Übertragung, Interpretation, Verarbeitung und Speicherung von Informationen. Primäres Ziel des Einsatzes von Standards ist die Realisierung oder Vereinfachung von Integrationslösungen. Erreicht wird eine höhere Kompatibilität der Anwendungssysteme, die zu effizienten und flexiblen Lösungen führt [Buxm01; PiNe00, 386]. Ferner sind Standards der Schlüssel zur überbetrieblichen Prozessintegration [Hube00, 63; PiNe00, 387].
Standards definieren jedoch nur einzelne Teilebenen von Anwendungssystemen. In vielen Fällen werden daher in Anwendungssystemen mehrere Standards gemeinsam eingesetzt, die häufig eine hierarchische Beziehung zueinander aufweisen [Buxm01].
Die einzelnen Standards stehen in direktem Zusammenhang mit einzelnen Kommunikationsebenen, vergleiche Kapitel 2.2. Anwendungssysteme bzw. Teilebenen von Anwendungssystemen, die keine Standards verwenden, werden als proprietär bezeichnet. Abbildung 6 zeigt die nach unserer Meinung möglichen Konstellationen zwischen proprietären und standardisierten Integrationsproblemen.
Konstellation 1: Die beiden zu integrierenden Anwendungssysteme verwenden die gleichen Standards. Das Integrationsproblem besteht hauptsächlich in der Administration und Konfiguration der Schnittstellen sowie in der Definition des Umfanges und der Bedingungen des Datenaustausches. Der Aufwand der Integration erweist sich im Vergleich zu den anderen Konstellationen als gering. Die Flexibilität ist hoch, da die Weiterentwicklung eines gemeinsamen Standards durch gleichzeitige Änderungen in den beteiligten Anwendungssystemen relativ einfach berücksichtigt werden kann. Auch das Ersetzen des einen Anwendungssystems durch ein anderes ist flexibel und mit geringem Aufwand möglich, solange identische Standards verwendet werden.
Konstellation 2: Die beiden zu integrierenden Anwendungssysteme nutzen Standards, jedoch unterschiedliche. Das Integrationsproblem ist, neben den Punkten aus Konstellation 1, vor allem durch die Anpassung der beiden Standards gekennzeichnet. Die Flexibilität ist demzufolge geringer als bei Konstellation 1.
Konstellation 3: Eine standardisierte und eine proprietäre Lösung sollen integriert werden. Dies ist deutlich aufwändiger als Konstellation 2, da die proprietäre Seite einen hohen Grad an Individualität aufzwingt. Gleichzeitig geht die Flexibilität verloren. Noch deutlicher wird dies bei Konstellation 4.
Festzuhalten ist, dass sich mit steigendem Standardisierungsgrad der zu integrierenden Anwendungssysteme die Flexibilität der Integrationslösung erhöht und der Aufwand verringert.
Ein weiterer wichtiger Aspekt dieser Betrachtung wird durch die Erweiterung des Blickwinkels auf das gesamte Integrationsproblem deutlich: Die Unterscheidung in standardisiert bzw. proprietär ist zwingend auf dem Niveau der einzelnen Kommunikationsebenen notwendig und für jedes der einzelnen Integrationsprobleme neu zu lösen, vergleiche Abbildung 7:
Standards leisten ihren Beitrag zur Lösung der Integrationsprobleme auf technischer, syntaktischer, semantischer und pragmatischer Kommunikationsebene. Gespiegelt an diesen Kommunikationsebenen werden wir kurz wichtige aktuelle Standards anführen (vgl. auch [Berl03; Hent01; Kelk01; Lint01; VoZe03]).
Kritisch ist anzumerken, dass es bisher bezüglich der Verbreitung und Anwendung von Standards auf den oberen Ebenen eher unzutreffende Einschätzungen gab. Wie eine aktuelle Studie der Berlecon Research, Berlin im Auftrag des Bundesministeriums für Wirtschaft und Arbeit zeigt, werden die etablierten EDI-Standards stark unterschätzt [Berl03, 171]. Hingegen werden Prozessstandards der pragmatischen Ebene derzeit quasi nicht eingesetzt. Ein Grund ist die fehlende Geschäftsprozessautomatisierung in den Unternehmen, die Standards wie ebXML oder RosettaNet erst nötig machen. Außerdem sind in praxi die Prozesse eher auf technischer Ebene in Programmcodes modelliert (z. B. in Workflows oder durch Regeln für Fehler- und Ausnahme-Handling) und weniger auf fachlicher Ebene der Prozessstandards (vgl. [Berl03, 89f]).
Zusammenfassend ist festzustellen, dass es Standards heute auf einer Kommunikationsebene oder über mehrere Kommunikationsebenen hinweg ermöglichen, einzelne technische, syntaktische, semantische und ansatzweise pragmatische Integrationsprobleme zu bewältigen. Es ist uns aber kein Ansatz bekannt, der alle Kommunikationsebenen abdeckt. Im Besonderen fehlen ausgereifte Standards für die Überwindung des pragmatischen Integrationsproblems (vgl. [Berl03; Kelk01; Hube00, 65; Anko02; ComZ02]).Dies macht die Notwendigkeit deutlich, einerseits neue Standards zu finden, andererseits so zu definieren, dass übergeordnete Kommunikationsebenen sich der Standards untergeordneter Kommunikationsebenen bedienen können.
Die Systemtopologie bezeichnet die beteiligten Anwendungssysteme an einer Integrationslösung und deren Beziehungen zueinander. Im Folgenden werden drei wesentliche Varianten beschrieben, die in der Literatur zu finden sind [Walt00; Nußd02; BuCh01].
Variante 1 in Abbildung 9 beschreibt eine Punkt-zu-Punkt-Kopplung. Diese Integrationslösung kommt ohne die Verwendung eines Integrationssystems aus. Der Austausch von Daten erfolgt direkt von Anwendungssystem zu Anwendungssystem. Möglich ist dies, wenn zwei Anwendungssysteme auf allen Ebenen der Kommunikation aufeinander abgestimmt sind, vergleiche Abbildung 10. Dies ist jedoch in einer heterogenen Systemlandschaft heute selten gegeben, da die Hersteller von Anwendungssystemen sich primär darauf konzentrieren, die eigentlichen Aufgaben und Funktionen ihres Systems zu realisieren und weniger darauf, zu anderen Anwendungssystemen kompatible Schnittstellen bereitzustellen. Daher sind solche Punkt-zu-Punkt-Kopplungen meist individuell geprägt und in einem hohen Maße inflexibel [Ließ00, 56; BuCh01, 1f; Nußd00, 12f; Lint00, 8ff].In Abbildung 9 ist eines der beiden Anwendungssysteme als das führende System gekennzeichnet. Ein führendes Anwendungssystem initialisiert (zeitabhängig oder ereignisabhängig) und überwacht den Datenaustausch. Eine ereignisabhängige Initialisierung ermöglicht einen Realtime-Ablauf des Datenaustauschs. Neben Anwendungssystemen können aber auch Integrationssysteme die führende Rolle übernehmen.
Variante 2, dargestellt im mittleren Teil von Abbildung 9, verwendet ein zentrales Integrationssystem, über das der Datenaustausch zwischen den Anwendungssystemen erfolgt. In der Literatur hat sich für diese Topologie der Begriff Hub-and-Spoke-Architektur etabliert [Nußd00, 125; WiRa00, 20f; Walt00]. Hiervon ist das Buskonzept als Implementierungsalternative zu unterscheiden, das ohne ein zentrales Integrationssystem auskommt [Ließ00, 72; Lint01, 133ff; Pubc02a]. Die Mehrzahl der heute am Markt angebotenen EAI-Systeme (Enterprise Application Integration) basiert auf dieser Hub-and-Spoke-Topologie. Der Unterschied zur Punkt-zu-Punkt-Kopplung wird beim Vergleich von Abbildung 10 und Abbildung 11 deutlich: Das Integrationssystem passt die Anwendungssysteme im Idealfall auf allen Kommunikationsebenen an. Bei Variante 2 ist es aber nicht möglich, Geschäftsprozesse über mehrere Anwendungssysteme hinweg zu steuern. Um dies zu bewerkstelligen, muss das Integrationssystem zusätzlich eine koordinierende Rolle übernehmen.
Variante 3 in Abbildung 9 wird auch als Business Process Integration bezeichnet und erlaubt ein effizientes Abwickeln von Geschäftsprozessen mit einzelnen Teilprozessen über mehrere beteiligte Anwendungssysteme hinweg [Nußd00, 125ff; Walt00; BuCh01, 13ff].
Betrachtet man losgelöst von den in Abbildung 9 dargestellten Systemtopologien ein zu integrierendes Anwendungssystem in isolierter Art und Weise, so stellt sich die Frage, inwieweit die diesem System innewohnende Verarbeitungslogik im Rahmen eines Integrationsszenarios zur Anwendung kommt. Unterscheiden kann man diese Verarbeitungslogik in Business-(Geschäfts-) und in Ablauflogik. Während die Business-Logik die inhaltlichen und logistischen Funktionen der Applikation umfasst, ist mit Ablauflogik die Ablaufsteuerung der Applikation gemeint [SAPP01, 209f]. Benutzt man die inhärente Business- und Ablauflogik eines Anwendungssystems, so spricht man vom Inside-out-Ansatz. Wird eine außerhalb liegende Ablauflogik verwendet (z. B. die eines Integrationssystems), so ist es ein Outside-in-Vorgehen. Diese Terminologie wurde primär von der SAP AG geprägt.
Zusammenfassend ist zu sagen, dass wesentliche Teile des Lösungsbeitrags des Integrationsproblems von den Anwendungssystemen zu den Integrationssystemen verlagert werden. Der Integrationsaufwand wird durch Einsatz eines Integrationssystems verringert und die Kosten für die Wartung der vielen einzelnen Punkt-zu-Punkt-Verbindungen entfallen [WiRa00, 32f]. Systemtopologien mit Integrationssystemen sind daher wesentlich flexibler als Punkt-zu-Punkt-Kopplungen. Übernehmen Integrationssysteme darüber hinaus die koordinierende Rolle, so erreicht man höchste Effizienz. Aus Sicht der dadurch integrierten Anwendungssysteme entspricht dies einem Outside-in-Ansatz.
Für die Integration eines Anwendungssystems ist es grundsätzlich notwendig, dieses technisch zu koppeln. Dafür stellen Anwendungssysteme in Abhängigkeit von Ihrer Architektur externe Schnittstellen bereit. Es sind grundsätzlich drei Schnittstellen-Typen zu unterscheiden, vergleiche Abbildung 12.
Unter Datenschnittstellen werden Zugriffsmöglichkeiten auf Datenbanken (z. B. ODBC, JDBC) bzw. auf Filesysteme (z. B. NTFS, NFS) verstanden. Datenschnittstellen werden für die Mensch-Maschine- sowie für die Maschine-Maschine-Kommunikation eingesetzt.
Applikationsschnittstellen stellen Zugriffsmöglichkeiten auf Programme oder Teile von Programmen und damit verbunden auf die Logik des Anwendungssystems zur Verfügung. Sie werden für die Maschine-Maschine-Kommunikation verwendet. Applikationsschnittstellen werden im Allgemeinen auch mit dem Begriff API (Application Programming Interface) bezeichnet. Es kann in funktionsorientierte (z. B. RPC, RFC), methodenorientierte (z. B. J2EE-Schnittstellen, BAPI) und message(nachrichten)-orientierte (z. B. MQSeries-Schnittstellen, ALE-Schnittstellen) Applikationsschnittstellen unterschieden werden.
Benutzerschnittstellen ermöglichen die Mensch-Maschine-Kommunikation und sind heute üblicherweise in Form einer grafischen Oberfläche realisiert.
Applikationsschnittstellen haben den Vorteil, dass sich die Integrationslösung der Logik des Anwendungssystems bedienen kann. So können Datenintegrität gewahrt und transaktionale Prozesse realisiert werden, allerdings zulasten der Flexibilität. Aufgrund ihrer aufwändigen Realisierung sind Applikationsschnittstellen nicht immer vorhanden. Im Gegensatz dazu ist es in vielen Fällen einfach, via Datenschnittstellen direkt auf einen Datenspeicher zuzugreifen. Jedoch muss bei der Verwendung von Datenschnittstellen die Integrationslösung selbst für die Datenintegrität sorgen [Lint00, 96]. Die Verwendung der Benutzerschnittstelle für eine Maschine-Maschine-Kommunikation ist eine einfache, aber wenig effektive Lösung. Transaktionale Abläufe und die Abwicklung von mehreren aufeinander folgenden Geschäftsprozessen lassen sich auf diese Weise nicht realisieren.
Die vorangegangenen Abschnitte dieses Kapitels konzentrierten sich auf die Kriterien, die die Effizienz und die Flexibilität von Integrationslösungen wesentlich beeinflussen. Dabei wurden Merkmale herausgestellt, deren Beziehung zueinander einen Ansatz eines Referenzmodells für Integrationslösungen liefert.
Die wesentlichen Punkte des Ansatzes eines Referenzmodells werden wie folgt zusammengefasst, vergleiche Abbildung 13:
1. Anwendungssysteme sind Sender und Empfänger von Daten.
2. Anwendungssysteme sind durch Schnittstellen, die sie bereitstellen, und durch Standards, die sie unterstützen, gekennzeichnet.
3. Das eigentliche Integrationsproblem ist die Überwindung der technischen, syntaktischen, semantischen und pragmatischen Unterschiede (Adaption) zwischen heterogenen Anwendungssystemen bei der Übermittlung von Daten.
4. Die Adaption kann durch ein Integrationssystem realisiert werden.
5. Integrationssysteme zeichnen sich dadurch aus, wie flexibel und effektiv sie in der Lage sind, die Schnittstellen und Standards der Anwendungssysteme aneinander anzupassen und die Übermittlung eines Datenaustausches zu ermöglichen (Anbindung und Transformation)
6. Integrationssysteme und Anwendungssysteme sind Teile einer Systemtopologie. Wenn in dieser Systemtopologie das Integrationssystem die Koordination übernimmt, ist es möglich, Geschäftsprozesse unter Einbeziehung mehrerer Anwendungssysteme zu realisieren (Prozessmanagement).
Ein EMP ist ein komplexes Anwendungssystem. Die Komplexität wird bestimmt durch die Anzahl der Marktplatzteilnehmer, das zugrunde liegende Geschäftsmodell, Art und Umfang der verwendeten Produktkataloge sowie den Grad der Individualisierung von Angeboten. Den kurz angerissenen Begriff der Effektivität sehen wir allgemein dem Entscheidungsfeld der strategischen Unternehmensplanung zugeordnet. Die Entscheidungen für oder gegen EMP- und Integrationslösungen müssen sich immer zielkonform mit der gesamtunternehmerischen Zielsetzung verhalten.
Die Leistungsfähigkeit eines EMP wird dadurch bestimmt, wie effizient und gleichzeitig flexibel es gelingt, die IV-technische Integration der EMP-Teilnehmer zu realisieren. Dabei muss eine Integrationslösung technische, syntaktische, semantische und pragmatische Integrationsprobleme bewältigen. Die Integrationslösung ist durch den Grad der Standardisierung, die Systemtopologie sowie die Schnittstellen der beteiligten Anwendungssysteme gekennzeichnet. Integrationslösungen müssen der Maxime folgen, größtmögliche Flexibilität und Effizienz für einen EMP und seine Teilnehmer zu bieten.
Die Flexibilität beschreibt den Aufwand, eine Integrationslösung zu etablieren oder zu ändern. Je höher der Grad der Standardisierung der zu integrierenden Anwendungssysteme, desto höher ist die Flexibilität. Systemtopologien mit Integrationssystemen zeichnen sich durch eine höhere Flexibilität als Punkt-zu-Punkt-Kopplungen aus. Applikationsschnittstellen bieten die geringste Flexibilität.
Die Effizienz kennzeichnet die Arbeitsweise einer Integrationslösung. Für eine effiziente Integrationslösung ist es notwendig, dass alle Integrationsprobleme ohne Brüche der Maschine-Maschine-Kommunikation bewältigt werden. Systemtopologien, in denen Integrationssysteme die koordinierende Rolle übernehmen und Applikationsschnittstellen nutzen, erreichen die höchste Effizienz.
Beim heutigen Stand der Technik geht ein Zuwachs an Flexibilität einer Integrationslösung mit einem Verlust an Effizienz einher. Analog gilt: Der Zuwachs an Effizienz bedeutet einen Verlust an Flexibilität. Herausforderung für die Zukunft ist es, Integrationslösungen zu schaffen, die der Forderung nach Flexibilität und gleichzeitiger Effizienz im hinreichenden Umfang im Hinblick auf das jeweilige Szenario gerecht werden. Der Schlüssel hierfür liegt in der Standardisierung unter Einbeziehung aller Kommunikationsebenen.
¹ Vgl. hierzu auch die aktuelle Diskussion zum Thema Zero Latency, also Echtzeitverfügbarkeit von Informationen, und dem von der Gartner Group ausgerufenen Paradigmenwechsel hin zum Real-Time-Enterprise (RTE) [www.gartner.com]. Einen aktuellen Beitrag zum sogenannten Echtzeitmanagement findet sich u. a. bei [ÖsSe03]
² Somit steht die Effizienz eher im Kontext der „Runtime“ von Integrationslösungen, während die Flexibilität eher der „Designtime“ zuzuordnen ist.
³ Der Übergang von der technischen und syntaktischen Ebene ist unserer Ansicht nach nicht trennscharf. Die Darstellungs- und Anwendungsschicht des ISO/OSI-Modells (Schicht 6 und 7) reicht teilweise von der technischen in die syntaktische Ebene hinein. Die technische Ebene selbst kann in eine physikalische (konkrete physische Parameter) und prozedurale (Art der Zeichenerzeugung und -darbietung) Ebene unterschieden werden.Aus Vereinfachungsgründen scheint die hier vollzogene Trennung in diesem Kommunikationsmodell aber gerechtfertigt.
[Anko02] Ankorion, Itamar: Revolutionizing Process Automation with Web Services. http://e-serv.ebizq.net/wbs/ankorion_1.html, Abruf am 2002-12-19.
[Berl03] Berlecon Research: E-Business-Standards in Deutschland – Bestandsaufnahme, Probleme, Perspektiven. Studie im Auftrag des Bundesministeriums für Wirtschaft und Arbeit, Berlin 2003.
[BuCh01] Buhl, Lothar; Christ, Jörg; Pape, Ulrich: Marktstudie: Softwaresysteme für Enterprise Application Integration. ALB/HNI-Verlagsschriftenreihe, Bd. 7, Fraunhofer-Anwendungszentrum für Logistikorientierte Betriebswirtschaft, Paderborn 2001.
[Buck96] Buck-Emden, Rüdiger: Die Client/Server-Technologie des SAP-Systems R/3: Basis für betriebswirtschaftliche Standardanwendungen. 3. Aufl., Addison-Wesley, Bonn 1996.
[BuKr00] Butscher, Stephan; Krohn, Felix: Klassifizierung und Bewertung von Internet-Marktplätzen – White Paper. Simon Kucher & Partners – Strategy & Marketing Consultants GmbH, Bonn 2000.[Buxm01] Buxmann, Peter: Standards und Standardisierung. In: [Mert01b, 434].
[ComZ02] Computer Zeitung: Integrationssoftware fehlt es noch an der Transaktionssicherheit. In: Computer Zeitung 37 (2002) 6, S. 11.
[Elsi91] Elsing, Jürgen: Das OSI-Schichtenmodell: Grundlagen und Anwendungen der X.200. IWT Verlag, Vaterstetten bei München 1991.
[Hent01] Hentrich, Johannes: B2B-Katalog-Management – E-Procurement und Sales im Collaborative Business. Galileo Press GmbH, Bonn 2001.
[HeSa99] Hermanns, Arnold; Sauter, Michael: Management-Handbuch Electronic Commerce: Grundlagen, Strategien, Praxisbeispiele. Verlag Franz Vahlen, München 1999.
[HeSa01] Hermanns, Arnold; Sauter, Michael: Management-Handbuch Electronic-Commerce: Grundlagen, Strategien, Praxisbeispiele. 2. Aufl., Verlag Franz Vahlen, München 2001.
[Hube00] Huber, Thomas: Business Networking Architekturen – Beispiele und Methoden für die Gestaltung von Prozess- und Applikationsarchitekturen in vernetzten Unternehmen. Dissertation, Universität St. Gallen, 2000.
[Kelk01] Kelkar, Oliver: Exkurs: Herausforderungen bei der Unternehmensintegration im zwischenbetrieblichen E-Commerce. In: [Hent01, 76-79].
[Koll01] Kollmann, Tobias: Virtuelle Marktplätze: Grundlagen – Management – Fallstudien. Verlag Franz Vahlen, München 2001.
[LeZH01] Lejmi, Habib; Zeller, Thomas; Horstmann, Ralph: Anbindung von ERP-Systemen an Elektronische Marktplätze. FORWIN-Bericht FWN-2001-013, Nürnberg 2001.
[Ließ00] Ließmann, Harald: Schnittstellenorientierung und Middleware basierte Busarchitekturen als Hilfsmittel zur Integration heterogener betrieblicher Anwendungssysteme. Dissertation, Universität Erlangen-Nürnberg, Erlangen-Nürnberg 2000.
[Lind00] Lindemann, Markus A.: Struktur und Effizienz elektronischer Märkte – Ein Ansatz zur Referenzmodellierung und Bewertung elektronischer Marktgemeinschaften und Marktdienste. Dissertation, Universität St. Gallen, Prof. Dr. Beat Schmid, Josef Eul Verlag, Lohmar 2000.
[Lint00] Linthicum, David S.: Enterprise Application Integration. 3. Aufl., Addison-Wesley, Boston 2000.[Lint01] Linthicum, David S.: B2B Application Integration – e-Business-Enable Your Enterprise. 2. Aufl., Addison-Wesley, Boston 2001.
[Lint02] Linthicum, David S.: EAI – Application Integration Exposed. http://www.softwaremag.com/archive/2000feb/EAI.html, Abruf am 2002-12-19.
[LiSc98] Lindemann, Markus A.; Schmid, Beat F.: Elements of a Reference Model Electronic Markets. Proceedings of the 31st Annual Hawaii International Conference on Systems Science HICCS'98, Vol. IV, Hawaii 1998-01-06/09, 1998. S. 193-201. http://www.informationobjects.ch:8080/NetAcademy/naservice/publications.nsf/all_pk/466, Abruf am 2002-12-19.
[Lück94] Lücking, Joachim: Branchenstrukturanalyse. In: [Dill94, 129-131].
[Mert01a] Mertens, Peter: Integrierte Informationsverarbeitung 1: Operative Systeme in der Industrie. 13. Auflage, Gabler, Wiesbaden 2001.
[Mert01b] Mertens, Peter; et al. (Hrsg.): Lexikon der Wirtschaftsinformatik. 4. Aufl., Springer Verlag, Berlin 2001.
[Merz02] Merz, Michael: Electronic Commerce – Marktmodelle, Anwendungen und Technologien. dpunkt.verlag GmbH, Heidelberg 1999.
[Nomi02] Nomina Informations-Service (Hrsg.): ISIS EAI Special Report. Edition 2002, München 2002.
[Nußd00] Nußdorfer, Richard: Das EAI-Buch: E-Business und EAI – Integration von Anwendungen – Trends, Technologie und Lösungen. CSA Consulting GmbH, München 2000.
[Nußd02] Nußdorfer, Richard: E-Business meets TBI. In: [Nomi02, 10-11].
[ÖsSe03] Österle, Hubert; Senger, Enrico: Realtime-Management – Fünf Fallstudien. Bericht Nr. BE HSG/ BECS/ 2, 14. Februar 2003. http://www.uni-sg.ch/org/iwi/iwi_pub.nsf/wwwPublAuthorGer/E76C8DEFD834AE8EC1256CD2002FE8FC/$file/AB%20Realtime%20V1.0%20final%20zweiseitig%20CSR.pdf, Abruf am 2003-05-14.
[Phil91] Philips (Hrsg.): Kommunikationsstandards – OSI und andere. Elektor-Verlag GmbH, Aachen 1991.
[PiNe00] Picot, Arnold; Neuburger, Rahild: Informationsbasierte (Re-)Organisation von Unternehmen. In: [Weib00, 385-400].
[Powe91] Powell, Walter: Neither market nor hierarchy: network forms of organization. In: [ThFr91, 265-276].
[PWC02] PricewaterhouseCoopers Unternehmensberatung GmbH (Hrsg.): Elektronische Marktplätze: Chancen und Risiken für Betreiber und Teilnehmer. Version 2.0, Düsseldorf 2002.
[RuMa01] Ruh, William; Maginnis, Francis; et al.: Enterprise Application Integration – A Wiley Tech Brief. John Wiley & Sons, Inc., New York 2001.
[SAPP01] SAPPress (Hrsg.): Internet Selling – Integrierte Online-Verkaufslösungen mit SAP. Galileo Press, Bonn 2001.
[ScLZ01] Schmitzer, B.; Lohmann, M.; Zeller, Th.: Integrationsbedarfe auf Elektronischen Marktplätzen. Information Management & Consulting 16 (2001) 1, S. 32-38.
[Schm99] Schmid, Beat F.: Elektronische Märkte – Merkmale, Organisation und Potentiale. In: [HeSa99, 31-48].
[ScSc00] Schneider, Dirk; Schnetkamp, Gerd: E-Markets: B2B-Strategien im Electronic-Commerce: Marktplätze, Fachportale, Plattformen. Verlag Dr. Th. Gabler GmbH, Wiesbaden 2000.
[ShWe49] Shannon, Claude; Weaver, Warren: The Mathematical Theory of Communication. University of Illinois Press, Urbana 1949.
[Stäh01] Stähler, Patrick: Geschäftsmodelle in der digitalen Ökonomie: Merkmale, Strategien und Auswirkungen. Josef Eul Verlag, Köln-Lohmar 2001.[ThFr91] Thompson, Grahame; Frances, Jennifer; et al.: Markets, Hierarchies and Networks – The Coordination of Social Life. SAGE Publications, London 1991.
[UniG02] Institut für Medien- und Kommunikationsmanagement Universität St. Gallen (Hrsg.): Ein Glossar für die NetAcademy – Version 3.0. http://www.businessmedia.org/netacademy/publications.nsf/all_pk/1563, Abruf am 2002-06-01.
[Walt00] Walter, Jochen: Digital Business Application Strategy: Zielorientierter EAI-Einsatz. interne Präsentation, Diebold Management- und Technologieberatung, 2002-11-01.
[Weib00] Weiber, Rolf (Hrsg.): Handbuch Electronic Business – Informationstechnologien – Electronic Commerce – Geschäftsprozesse. Betriebswirtschaftlicher Verlag Dr. Th. Gabler GmbH, Wiesbaden 2000.
[WiMa01] Wirtz, Bernd; Mathieu, Alexander: B2B-Marktplätze – Erscheinungsformen und ökonomische Vorteile. In: WISU (Hrsg.): Das Wirtschafts Studium, Die Zeitschrift für den Wirtschaftsstudenten, o. Jg. (2001) 10/01, 1332-1344.
[WiRa00] Winkeler, Thomas; Raupach, Ernst; Westphal, Lothar: EAI – Enterprise Application Integration – Die Pflicht vor der E-Business-Kür. PricewaterhouseCoopers – Deutsche Revision, Frankfurt am Main 2000.
[VoZe03] Voigtmann, Peter; Zeller, Thomas: Enterprise Application Integration und B2B Integration im Kontext von Electronic Business und Elektronischen Marktplätzen. Teil II: Integrationssysteme und Fallbeispiele. FORWIN-Bericht FWN-2003-001, Nürnberg 2003. http://www.forwin.de/download/berichte/Internet_FWN_2003-001.pdf, Abruf am 2003-05-14.
[Zbor96] Zbornik, Stefan: Elektronische Märkte, elektronische Hierarchien und elektronische Netzwerke – Koordination des wirtschaftlichen Leistungsaustausches durch Mehrwertdienste auf der Basis von EDI und offenen Kommunikationssystemen, diskutiert am Beispiel der Elektronikindustrie. Schriften zur Informationswissenschaft 22., Universitätsverlag Konstanz GmbH, Konstanz 1996.
