Universität Bamberg, Lehrstuhl Prof. Ferstl Universität Bamberg, Lehrstuhl Prof. Sinz Universität Nürnberg, Lehrstuhl Prof.

Transkript

1 Universität Bamberg, Lehrstuhl Prof. Ferstl Universität Bamberg, Lehrstuhl Prof. Sinz Universität Nürnberg, Lehrstuhl Prof. Mertens Martin Schissler, Thomas Zeller, Stephan Mantel Klassifikation von Integrationsproblemen und -lösungen bei der überbetrieblichen Integration von Anwendungssystemen Feldkirchenstraße 21, Bamberg, Tel , Fax {schissler Äußere Laufer Gasse 13-15, Nürnberg, Tel ,Fax ,

2 FORWIN-Bericht-Nr.: FWN FORWIN - Bayerischer Forschungsverbund Wirtschaftsinformatik, Bamberg, Bayreuth, Erlangen-Nürnberg, Regensburg, Würzburg 2001 Alle Rechte vorbehalten. Insbesondere ist die Überführung in maschinenlesbare Form sowie das Speichern in Informationssystemen, auch auszugsweise, nur mit schriftlicher Einwilligung von FORWIN gestattet. ii

3 Zusammenfassung Der vorliegende Bericht stellt Grundlagen für eine strukturierte Erfassung des Problembereichs der überbetrieblichen Integration vor. Dies erfolgt in Form verschiedener Klassifikationen im Bereich des Integrationsproblems und im Bereich der Integrationslösung, die im Rahmen der Projekte Offene Anwendungssystem-Architekturen in überbetrieblichen Wertschöpfungsketten (OASYS) und Kopplung von Elektronischen Marktplätzen und betrieblicher Standardsoftware (KOELMA) erarbeitet wurden. Außerdem bietet der Beitrag eine Übersicht über verwandte Arbeiten. Stichworte Überbetrieblicher Geschäftsprozess, Integration von Anwendungssystemen, Kopplungsarchitektur, Kopplungsmechanismus Abstract This report introduces basic knowlegde for a structured coverage of intercompany integration by using serveral classifications for the integration problem and the integration solution. The classifications were developped within the research projects Open Application System Architectures in Intercompany Value Chains (OASYS) and Coupling of electronic marketplaces and packaged software (KOELMA). In addition related work is shown. Keywords intercompany business process, application integration, coupling architecture, coupling mechanismen iii

4 Inhalt 1 EINLEITUNG INTEGRATIONSPROBLEME UND -LÖSUNGEN VERWANDTE ARBEITEN B2B APPLICATION INTEGRATION NACH LINTHICUM INTEGRIERTE INFORMATIONSVERARBEITUNG NACH MERTENS BUSINESS NETWORKING NACH FLEISCH ET AL ENTERPRISE APPLICATION INTEGRATION NACH RUH ET AL KLASSIFIKATIONEN DER PROJEKTE OASYS UND KOELMA KLASSIFIKATION VON ÜBERBETRIEBLICHEN GESCHÄFTSPROZESSEN KLASSIFIKATION VON NICHT-FUNKTIONALEN ANFORDERUNGEN KLASSIFIKATION VON KOPPLUNGSMECHANISMEN KLASSIFIKATION VON KOPPLUNGSARCHITEKTUREN ZUSAMMENFASSUNG LITERATURVERZEICHNIS iv

5 1 Einleitung In Zeiten zunehmender Globalisierung liegt das Augenmerk der Unternehmen besonders auf der Gestaltung der überbetrieblichen Geschäftsprozesse. Zur Erreichung einer hohen Effektivität und Effizienz der Interaktionen mit anderen Unternehmen ist eine Integration der Aufgaben der betrachteten Unternehmen erforderlich sowie eine Integration der diese Aufgaben unterstützenden Anwendungssysteme (AwS). Der vorliegende Bericht stellt Grundlagen für eine strukturierte Erfassung des Problembereichs der überbetrieblichen Integration vor. Dies erfolgt in Form verschiedener Klassifikationen im Bereich des Integrationsproblems und im Bereich der Integrationslösung, die im Rahmen der Projekte Offene Anwendungssystem-Architekturen in überbetrieblichen Wertschöpfungsketten (OASYS) und Kopplung von Elektronischen Marktplätzen und betrieblicher Standardsoftware (KOELMA) erarbeitet wurden. Die beschriebenen Klassifikationen können u. a. als Ausgangspunkt für die Entwicklung von Methodiken zum betrachteten Problembereich verwendet werden, wie dies z. B. im OASYS-Projekt erfolgt ist [MES+04]. In Kapitel 2 wird zunächst mithilfe der Unternehmensarchitektur der SOM-Methodik (Semantisches Objektmodell) die Integration von AwS in den Gesamtkontext der überbetrieblichen Integration eingeordnet. Außerdem werden eine Reihe von grundlegenden Begriffen eingeführt, die einen Rahmen für die vorgestellten Klassifikationen bilden. Kapitel 3 bietet eine Übersicht über Klassifikationen aus verschiedenen verwandten Arbeiten. In Kapitel 4 werden mehrere im Rahmen der Projekte OASYS und KOELMA erarbeitete Klassifikationen vorgestellt. In Kapitel 5 erfolgt eine Zusammenfassung der Ergebnisse. 2 Integrationsprobleme und -lösungen In der SOM-Methodik wird ein Unternehmen als betriebliches System verstanden, das mithilfe verschiedener Modelle beschrieben wird (Abb. 1) [FeSi01, 180ff.]. Die SOM- Unternehmensarchitektur definiert hierfür die drei Modellebenen Unternehmensplan (Ebene 1), Geschäftsprozessmodell (Ebene 2) und Spezifikation der Ressourcen (Ebene 3). 1

6 1. Modellebene Außensicht des betrieblichen Systems 2. Modellebene Innensicht des betrieblichen Systems 3. Modellebene Spezifikation von Ressourcen U-Plan Geschäftsprozessmodell Spezifikationen der Aufbauorganisation Anwendungssysteme Maschinen und Anlagen Abb. 1: Unternehmensarchitektur SOM-Methodik [FeSi01, 181] Der Unternehmensplan beschreibt das betriebliche System in der Außensicht. Er spezifiziert die Unternehmensaufgabe anhand ihres Aufgabenobjekts (Abgrenzung von Diskurswelt und Umwelt), ihrer Aufgabenziele, der Leistungsbeziehungen zwischen Diskurswelt und Umwelt sowie der zur Durchführung der Unternehmensaufgabe benötigten Ressourcen und beinhaltet zusätzlich eine entsprechende Strategie zur Umsetzung der Unternehmensziele [FeSi01, 181]. Ebene 2 beschreibt die Innensicht des betrieblichen Systems in Form eines Systems von Geschäftsprozessen, die den Unternehmensplan umsetzen. Auf dieser Ebene werden die fachlichen Aufgaben des betrieblichen Systems erfasst. Der vorliegende Artikel konzentriert sich hierbei auf Informationsverarbeitungsaufgaben, die dem betrieblichen Informationssystem zuzurechnen sind [FeSi01, 1ff.]. Auf Ebene 3 der Unternehmensarchitektur werden Ressourcen zur Durchführung der Geschäftsprozesse spezifiziert. Es können Personal, AwS sowie Maschinen und Anlagen unterschieden werden. Diese Arbeit fokussiert auf die Betrachtung der AwS, die maschinelle Aufgabenträger der Aufgaben des Geschäftsprozesses darstellen. Eine hohe Effektivität und Effizienz der Interaktionen zweier oder mehrerer Unternehmen werden durch eine Integration von Aufgaben der Geschäftsprozesse der betrachteten Unternehmen erreicht [FeSi01, 215ff.]. Grobe Lösungen zur Erreichung einer solchen Integration werden auf Ebene 1 in Form von entsprechend abgestimmten Unternehmensplänen erfasst. Werden die zu integrierenden Aufgaben durch AwS unterstützt, so leitet sich außerdem ein Integrationsbedarf für diese AwS ab. In diesem Sinne sind somit Integrationsprobleme auf allen drei Ebenen der Unternehmensarchitektur zu lösen. Ein Integrationsproblem kann als Spezialfall eines Konstruktionsproblems verstanden werden. Ein Konstruktionsproblem ist gekennzeichnet durch ein Untersuchungsobjekt und ein Untersuchungsziel [Klir65, 48f.]. Das Untersuchungsobjekt ist hierbei ein noch nicht existierendes System, das anhand des gewünschten Verhaltens sowie evtl. durch zusätzliche 2

7 Vorgaben hinsichtlich der Struktur des Systems beschrieben wird. Untersuchungsziel ist die Ermittlung einer Lösung in Form einer Systemstruktur, die zum gewünschten Verhalten führt. Auf Ebene 1 der Unternehmensarchitektur ist das Untersuchungsobjekt ein System von Unternehmensplänen, anhand derer festgelegt wird, wie die Integration der Aufgaben der betrachteten Unternehmen erfolgen soll. Das Untersuchungsobjekt der Ebene 2 ist ein System von überbetrieblichen Geschäftsprozessen. Auf Ebene 3 ist das Untersuchungsobjekt ein Kopplungssystem, das die AwS der betrachteten Unternehmen integriert. In der Regel wird die Vorgehensweise zur Lösung der Integrationsprobleme top-down ausgerichtet sein. Bei der Lösungssuche auf einer Ebene sind Restriktionen zu berücksichtigen, die sich aus der Lösung auf der jeweils übergeordneten Ebene ergeben. Umgekehrt können Änderungen auf den unteren Ebenen (z. B. neue Technologien) entsprechende Strategieänderungen induzieren (bottom-up). AwS U1 AwS U1 Kern AwS U1 Koppl.- Teilsystem Kopplungsmechanismen AwS U2 Koppl.- Teilsystem Kopplungsmechanismen AwS U2 Kern AwS U2 Kopplungssystem Nutzt-Beziehung Kommunikationsbeziehung Abb. 2: Kopplungssystem Im Folgenden beschränkt sich die vorliegende Arbeit auf die Betrachtung des Integrationsproblems der Ebene 3. Das auf dieser Ebene gesuchte Kopplungssystem enthält alle kopplungsrelevanten Elemente der AwS (Abb. 2). Bei jedem der beteiligten AwS wird zwischen dem Kern und dem Kopplungs-Teilsystem unterschieden [MES+02, 184]. Das Kopplungs-Teilsystem enthält diejenigen Elemente des AwS, die ausschließlich der Kopplung mit anderen AwS dienen. Es wird auf der Basis von bestehenden Kopplungsmechanismen realisiert, die Dienste und Kommunikationsprotokolle für die Kopplung bereitstellen. Der AwS-Kern enthält die zu integrierenden Elemente und daneben auch weitere nicht kopplungsrelevante Elemente. Zur Spezifikation des Integrationsproblems der Ebene 3 wird das angestrebte Kopplungssystem (1) anhand des zu unterstützenden überbetrieblichen Geschäftsprozesses, (2) durch nicht-funktionale Anforderungen und evtl. (3) durch zu verwendende Kopplungsmechanismen beschrieben. Jedes Kopplungssystem unterstützt einen überbetrieblichen Geschäftsprozess. Der Geschäftsprozess beschreibt hierbei, was das Kopplungssystem leisten muss. Neben diesen häufig als funktional bezeichneten Anforderungen müssen auch noch nicht-funktionale 3

8 Anforderungen betrachtet werden, die beschreiben, wie die Unterstützung zu erfolgen hat (vgl. z. B. [Somm01, 109ff.]). Typische nicht-funktionale Anforderungen sind Skalierbarkeit und Verfügbarkeit. Gibt es bez. der zu verwendenden Kopplungsmechanismen Vorgaben, so sind diese Kopplungsmechanismen Teil des Integrationsproblems. Das Problem wird hierbei erweitert um Angaben bez. zu verwendender Systemkomponenten, Teilstrukturen usw., die durch die Kopplungsmechanismen vorgegeben werden [Fers79, 45]. Eine Lösung für das Integrationsproblem der Ebene 3 spezifiziert ein Kopplungssystem, das den im Integrationsproblem beschriebenen Anforderungen genügt. Die Spezifikation einer solchen Integrationslösung erfolgt in Form einer Kopplungsarchitektur, die die verschiedenen Elemente des Kopplungssystems und deren Zusammenwirken beschreibt. Existieren keine festen Vorgaben bez. der Kopplungsmechanismen, so müssen diese im Rahmen der Lösungsfindung ausgewählt werden und sind somit Teil der Integrationslösung. 3 Verwandte Arbeiten In den folgenden Abschnitten wird die Beschreibung des Integrationsproblems der Ebene 3 sowie der zugehörigen Integrationslösung aufgegriffen. Die Komplexität dieses Problembereichs macht eine strukturierte Erfassung erforderlich. Hilfreich können hierbei entsprechende Klassifikationen sein. In der Literatur zur Integration von AwS und zur Integration von Aufgaben finden sich häufig Strukturierungen, die hierfür geeignet sind. In den folgenden Abschnitten werden verschiedene dieser Klassifikationen vorgestellt. Es werden Klassifikationen bez. der überbetrieblichen Geschäftsprozesse, der nicht-funktionalen Anforderungen, der Kopplungsmechanismen und der Kopplungsarchitekturen unterschieden. 3.1 B2B Application Integration nach Linthicum Den neueren Ansatz der B2B Application Integration [Lint01] versteht LINTHICUM als Weiterführung der Enterprise Application Integration (EAI) [Lint00], wobei methodisch und technologisch viele Anleihen am älteren Ansatz genommen werden. Eine Klassifikation von Kopplungsmechanismen findet sich in [Lint01] im Rahmen der Diskussion von Middleware-Technologien. Es werden sechs Arten von Middleware unterschieden [Lint01, 136ff.]. Remote Procedure Calls erlauben den synchronen Aufruf einer lokalen Funktion von einem entfernten Rechner aus. Nachrichtenorientierte Middleware dient dem asynchronen Austausch von Nachrichten über Warteschlangen. Über Object Request Broker (ORB) können Objekte objektorientierter AwS mit entfernten Objekten kommunizieren. Datenbankorientierte Middleware erlaubt den Zugriff auf lokale und entfernte Datenbanken. Transaktionale Middleware fasst TP Monitore und Application Server zusammen. Diese unterstützen eine transaktionsgeschützte Kopplung von AwS. 4

9 Message Broker, die häufig auch als Integration Broker bezeichnet werden, erweitern nachrichtenorientierte Middleware um Routing- und Transformationsfunktionen. Im Bereich der Kopplungsarchitekturen diskutiert LINTHICUM verschiedene Dimensionen der überbetrieblichen AwS-Integration. Es werden Daten-, Methoden-, Applikationschnittstellen-, Prozess- und Portalintegration differenziert [Lint01, 27]. Als einfachste Art der Integration nennt [Lint01] die datenorientierte Integration. Ziel ist dabei eine Zusammenführung von heterogenen Datenquellen, ungeachtet der jeweiligen Datenmodelle (relational, hierarchisch, objektorientiert, multidimensional), sowie von Daten und Dokumenten aus AwS wie z. B. Enterprise-Resource-Planning(ERP)-Systemen [BaHS02, 11]. Die Datenintegrität muss durch die Integrationslösung sichergestellt werden [Lint00, 96]. Unter applikationsschnittstellenorientierter Integration wird die Verwendung von AwS- Schnittstellen verstanden [Lint01, 51ff.]. Die Schnittstellenaufrufe, also die Zugriffe auf Programme oder Teile von Programmen, haben den Vorteil, dass im Integrationsszenario die Geschäftslogik des AwS genutzt werden kann. Bei der methodenorientierten Integration steht eine Wiederverwendbarkeit auf Geschäftsprozessebene im Vordergrund [BaHS02, 12]. Beispielsweise kann die Methode zum Anlegen eines Kundenauftrags in heterogenen AwS und für unterschiedliche Geschäftsprozesse die gleiche sein. LINTHICUM schlägt hierzu die Einrichtung eines Method Warehouse vor [Lint01, 80f.]. Die Integration mittels Portalen ist die Zusammenführung heterogener Applikationen auf der Benutzungsschnittstellenebene [Lint01, 29;103f.]. Diese ressourcenschonende und flexible Technik fasst lediglich bestehende Oberflächen zusammen, transaktionale Abläufe und damit die Abwicklung von Geschäftsprozessen sind nur beschränkt möglich [VoZe02, 27]. Die Prozessintegration stellt die anspruchsvollste Ausprägung dar [Lint01, 105ff.]. Grundlage ist hier ein Modell des überbetrieblichen Geschäftsprozesses. Diese Form der AwS-Integration beschäftigt sich mit dem Austausch von Daten und dem Anstoßen von Prozessen zur Unterstützung des überbetrieblichen Geschäftsprozesses. Die Prozessintegration umfasst alle anderen Arten der Integration mit Ausnahme der Integration mittels Portalen. 3.2 Integrierte Informationsverarbeitung nach Mertens In seinem Buch Integrierte Informationsverarbeitung 1 [Mert04] behandelt MERTENS alle drei Ebenen der Unternehmensarchitektur (vgl. Kapitel 2). Domäne des Buches sind Industriebetriebe. Als Bezugsrahmen dient eine Unternehmenspyramide, die Administrationsund Dispositionssysteme (horizontale Integration) sowie Planungs- und Kontrollsysteme (vertikale Integration) für die einzelnen betrieblichen Funktionalbereiche unterscheidet. Es 5

10 wird darüber hinaus ein Referenzmodell der Integrierten Informationsverarbeitung in der Industrie vorgestellt [Mert04, 20-26]. Zwar entstand der Ansatz nach MERTENS im innerbetrieblichen Kontext, eine Übertragung auf den überbetrieblichen Bereich ist aber möglich. Die AwS-Integration trennt sich in eine fachliche und eine IV-technische Sphäre. Als fachliche Aspekte der AwS-Integration differenziert MERTENS die Integrationsgegenstände Funktionen, Prozesse und Methoden [Mert04, 1ff.], die sich zur Klassifikation von überbetrieblichen Geschäftsprozessen eignen. Die Integration von Funktionen meint die Abstimmung von Tätigkeiten. Funktionen bewirken eine Zustands- oder Lageveränderung eines Objekts ohne Raum- und Zeitbezug und werden mit den Komponenten Objekt und Verrichtung beschrieben (z. B. Bestellgrenze ermitteln ) [Mert04, 22]. Bei der Integration von Prozessen (Vorgängen) werden einzelne Prozesse miteinander verbunden, wobei die Prozesse selbst aus der Folge von einzelnen Funktionen bestehen, die aufeinander abgestimmt werden. Prozesse bedürfen eines definierten Anfangs- und Endpunkts [Mert04, 1, 24]. Bei der Methodenintegration wird insbesondere betriebswirtschaftliches Verständnis aufeinander abgestimmt, was zur Kombination von einzelnen Methoden führt. Ein Beispiel für Methodenintegration ist der Abgleich von Algorithmen zur Absatzprognose mit den Einstellungen der Sicherheitsbestände der Lagerhaltung sowie der Losgrößenbildung. Überbetriebliche Methodenintegration wäre beispielsweise das Abstimmen von Geschäftsprozessen und Algorithmen in Kunden- und Lieferantenbeziehungen [Mert04, 3, 97]. Der Begriff Methode bei MERTENS darf nicht mit dem in der Literatur gleich bezeichneten Aufruf einer Methode im Zusammenhang mit der objektorientierten Programmierung verwechselt werden [Lint01, 75]. Im Kontext der Integration auf Objektebene bezeichnen WINKELER et al. Methoden als jene Schnittstellen zu Objekten (Beispiel eines Objekts: Kundenauftrag), welche einen Zugriff auf die vom Objekt repräsentierten Daten ermöglichen [WiRW01, 8]. Im Bereich der IV-technischen Realisierung unterscheidet MERTENS Daten- und Programmintegration [Mert04, 1-5]. Diese Integrationsgegenstände lassen sich dem Bereich Kopplungsarchitekturen zuordnen. Bei der Datenintegration werden Daten logisch zusammengeführt, wobei dies in einfachster Ausprägung automatisch zwischen mindestens zwei Programmen bzw. AwS durch Datenaustausch geschieht und die jeweils richtige Interpretation der Daten sichergestellt sein muss. Weiterentwickelte Kopplungsarchitekturen erlauben die Einbeziehung vieler Programme oder AwS durch gemeinsame Datenbanken. Unter Programmintegration versteht MERTENS die Abstimmung von einzelnen Programmen (Software-Bausteine, Module), insbesondere um Wiederverwendbarkeit zu erreichen. Beispielsweise kann ein Programm oder Modul für adaptive Stichprobenverfahren im Wareneingang ebenso in der Produktion angewandt werden [Mert04, 3]. 6

11 3.3 Business Networking nach Fleisch et al. Der Ansatz Business Networking wurde am Institut für Wirtschaftsinformatik der Universität St. Gallen (IWI-HSG) entwickelt und stellt das Management von IT-gestützten Beziehungen von internen und externen Geschäftspartnern dar [AlFÖ02, 2]. Leitidee ist der Gedanke der Vernetzung, v. a. begründet auf der Transaktionskosten-, Netzwerk- und Koordinationstheorie sowie der Netzwerkökonomie. Gestaltungsprinzip ist die Prozessorientierung [Flei01, 15, 61f.]. Grundlage der folgenden Ausführungen ist das Buch Das Netzwerkunternehmen von FLEISCH [Flei01]. Zu einer Klassifikation von überbetrieblichen Geschäftsprozessen können die von FLEISCH unterschiedenen Koordinationsbereiche zwischen Unternehmen herangezogen werden. Er differenziert Supply-Chain-Management, Beziehungsmanagement, Innovation, Infrastruktur und Organisationsentwicklung [Flei01, 168]. Der Bereich Supply-Chain-Management beschäftigt sich mit der überbetrieblichen Koordination von Planungs-, Beschaffungs-, Produktions- und Vertriebsprozessen. Die Koordinationsform ist meist ein stabiles Netzwerk. Das Beziehungsmanagement befasst sich mit der Koordination von Marketing, Verkauf und Service. Dies erfolgt meist über traditionelle oder elektronische Märkte. Forschungs- und Entwicklungsprozesse werden im Rahmen des Koordinationsbereichs Innovation unternehmensübergreifend abgestimmt. Die Unternehmen sind hier meist Teil eines dynamischen Netzwerks. Zum Bereich der Infrastruktur zählt die Koordination von Rechnungswesen, Vermögens- und Stammdatenverwaltung, etc. Die Koordination erfolgt hier größtenteils in Form eines internen oder stabilen Netzwerks. Die Organisationsentwicklung koordiniert Prozesse, die auf die Erhöhung der Netzwerkfähigkeit von Mitarbeitern und Partnern abzielen [Flei01, 168]. Unter dem Stichwort Enterprise-Application-Integration-Systeme wird eine Klassifikation von Kopplungsmechanismen vorgestellt. Die Kopplungsmechanismen werden hierbei entsprechend der von ihnen unterstützten Ebene der Kommunikation eingeteilt. Es werden die drei Ebenen Syntax, Semantik und Pragmatik unterschieden [Flei01, 124ff.]. Des Weiteren unterscheidet FLEISCH fünf Formen überbetrieblicher Systemintegration [Flei01, 134ff.]. Bei der Integration über Mitarbeiter verläuft der Austausch von Informationen ausschließlich über Menschen. Die AwS kommunizieren nicht miteinander. Im Rahmen einer Integration über Zugriffsgewährung verbindet ein einzelner Mitarbeiter die AwS der beteiligten Unternehmen. Hierzu benötigt er Zugriff auf die AwS der Kopplungspartner. Bei der Integration über elektronische Produktkataloge greift ein Mitarbeiter eines Unternehmens auf den elektronischen Produktkatalog eines Partnerunternehmens zu. FLEISCH hat hierbei einen sehr weitgefassten Begriff von Produktkatalogen. Sie bilden standardisierte, automatisierbare Koordinationsaufgaben geringer (...) und mittlerer Komplexität (...) ab und koordinieren in der Regel marktliche Transaktionen mit hoher Transaktionshäufigkeit. [Flei01, 137]. Kommunizieren die AwS der 7

12 Unternehmen direkt, ohne menschliche Beteiligung miteinander, wird dies als Integration über Maschinen bezeichnet. Die letzte Form ist die Integration über Service. Hierbei wird ein Teil der Integrationsaufgabe auf einen dritten Geschäftspartner ausgelagert. Diese Form der Systemintegration ist in Kombination mit einer Integration über Maschinen die Grundlage zahlreicher neuer Geschäftsmodelle aus dem Bereich des Electronic Commerce, wie beispielsweise Elektronische Marktplätze. Die ersten drei Formen überbetrieblicher Systemintegration beschäftigen sich mit einer manuellen Integration von AwS. Nur die Integration über Maschinen und die Integration über Service haben die automatisierte Kopplung von AwS zum Gegenstand und können als Kopplungsarchitekturarten interpretiert werden. 3.4 Enterprise Application Integration nach Ruh et al. In [RuMB01] beschreiben RUH et al. Grundlagen der innerbetrieblichen AwS-Integration unter dem Schlagwort EAI. Wie auch bei MERTENS wird von einer Übertragbarkeit in den überbetrieblichen Bereich ausgegangen. RUH et al. unterscheiden fünf Arten von Kopplungsmechanismen: Remote Procedure Calls, Middleware für den Datenbankzugriff, nachrichtenorientierte Middleware, Technologien für verteilte Objekte und Middleware zur Transaktionssteuerung [RuMB01, 53f.]. Diese Klassifikation deckt sich weitestgehend mit der von LINTHICUM (vgl. Abschnitt 3.1). Auf eine detaillierte Beschreibung wird aus diesem Grund verzichtet. Die von RUH et al. vorgestellten Integrationsmodelle können als unterschiedliche Arten von Kopplungsarchitekturen interpretiert werden. Es werden Kopplungsarchitekturen auf Präsentations-, Funktions- und Datenebene differenziert [RuMB01, 19f.]. Die Präsentationsintegration gilt als einfachste Form der Integration. Hierbei erfolgt die Integration der AwS über eine gemeinsame Nutzerschnittstelle [RuMB01, 22f.]. Unter Datenintegration wird die Integration über einen direkten Zugriff auf die Daten der zu koppelnden AwS verstanden. Die Anwendungsfunktionen der jeweiligen AwS werden hierbei umgangen. Bei der Funktionsintegration geschieht die Integration über den Aufruf von Schnittstellen der Anwendungsfunktionen, die die AwS nach außen anbieten [RuMB01, 20]. 4 Klassifikationen der Projekte OASYS und KOELMA Die im vorherigen Kapitel vorgestellten Klassifikationen wurden teilweise aus einem leicht anderen Blickwinkel als dem in Kapitel 2 beschriebenen entwickelt. Aus diesem Grund findet sich z. B. bei keinem der Ansätze eine vollständige Abdeckung des betrachteten Problembereichs. Außerdem ist teilweise eine zu geringe Systematik und Motivation der gewählten Klassifikationen zu bemängeln. Hierdurch wird die Verständlichkeit der Klassifi- 8

13 kationen zum Teil erheblich erschwert. Im Rahmen der Projekte OASYS und KOELMA wurden verschiedene Klassifikationen erarbeitet, die im Folgenden vorgestellt werden. Beide Projekte sind Teil des Bayerischen Forschungsverbunds Wirtschaftsinformatik (FORWIN). Die Klassifikationen bez. der überbetrieblichen Geschäftsprozesse, der nicht-funktionalen Anforderungen und der Kopplungsarchitekturen stammen aus dem Projekt OASYS. Die Klassifikation von Kopplungsmechanismen ist ein Ergebnis des Projekts KOELMA. 4.1 Klassifikation von überbetrieblichen Geschäftsprozessen In der Ablaufsicht stellt ein Geschäftsprozess einen ereignisgesteuerten Ablauf von Aufgaben dar [FeSi01, 186]. Ausgangspunkt der hier verwendeten Klassifikation ist der Begriff der betrieblichen Aufgabe (Abb. 3). Eine betriebliche Aufgabe besteht in der Außensicht aus einem Aufgabenobjekt (AO) und Aufgabenzielen sowie aus Vor- und Nachereignissen [FeSi01, 90]. Vorereignisse lösen eine Aufgabendurchführung aus, Nachereignisse sind das Ergebnis einer Aufgabendurchführung. Bei Aufgabenobjekten wird zusätzlich zwischen Typ (AO-Typ) und Instanz (AO-Instanz) unterschieden. Der AO-Typ umfasst die zu einer Aufgabe gehörigen Attribute eines betrieblichen Systems. Beispiel: Der AO-Typ einer Bestellung beschreibt die verschiedenen Attribute einer Bestellung. Er kann z. B. spezifizieren, dass eine Bestellung eine 5-stellige Bestellnummer und ein Bestelldatum enthält. Ziele Ziele Vorereignis (1) Nachereignis (4) Lösungsverfahren Lösungsverfahren Aufgabenobjekt AO-Typ AO-Instanzen (3) (2) AO-Typ AO-Instanzen Aufgabenobjekt Abb. 3: Aufgaben und ihre Beziehungen Zu einem AO-Typ kann es beliebig viele AO-Instanzen geben. Die AO-Instanzen beinhalten Attributwerte, die konkrete Aufgabenobjekte beschreiben. Beispiel: Die Bestellung mit der Bestellnummer und dem Bestelldatum ist eine Instanz zu dem im vorherigen Beispiel beschriebenen AO-Typ. Die Innensicht einer Aufgabe beschreibt das Lösungsverfahren der Aufgabe, das im Rahmen einer Aufgabendurchführung auf den AO-Instanzen ausgeführt wird. Zwischen zwei Aufgaben, die verschiedenen Unternehmen zugeordnet sind, können unterschiedliche Beziehungen bestehen, die durch entsprechende Kopplungen der AwS zu 9

14 unterstützen sind. Es werden vier Arten von Beziehungen unterschieden, die einzeln oder in Kombination auftreten [SMFS02]. (1) Reihenfolgebeziehung zwischen Aufgaben Ist das Nachereignis einer Aufgabe zugleich das Vorereignis einer weiteren Aufgabe, so besteht zwischen den beiden Aufgaben eine Reihenfolgebeziehung. Sind die beiden Aufgaben AwS unterschiedlicher Unternehmen zugeordnet, müssen die AwS der Unternehmen so gekoppelt werden, dass zwischen ihnen das Ereignis übertragen werden kann. Beispiel: Eine Bestellung, die zwischen zwei Unternehmen ausgetauscht wird, stellt auf Seite des Käufers ein Nachereignis der Aufgabe Bestellfreigabe und auf Seite des Verkäufers ein Vorereignis der Aufgabe Auftragsabwicklung dar. (2) Partielle Identität von AO-Instanzen Operieren die Lösungsverfahren zweier Aufgaben auf teilweise gleichen AO-Instanzen, so liegt eine Identität der AO-Instanzen vor. Falls die betrachteten Aufgaben AwS unterschiedlicher Unternehmen zugeordnet sind, müssen diese so gekoppelt werden, dass eine Abstimmung hinsichtlich der AO-Instanzen möglich ist. Ein unabgestimmtes Vorgehen kann hier zu Inkonsistenzen und unnötigem Aufwand, z. B. in Form von Doppelpflege, führen. Beispiel: Im Rahmen des VMI-Konzepts (Vendor-Managed-Inventory) erhält ein Lieferant Zugriff auf die Bestandsdaten eines Kunden (vgl. z. B. [KnMZ02, 62ff.]). Der Lieferant überwacht diese Bestandsdaten und übernimmt die Bestellplanung für den Kunden. Auf Seite des Lieferanten gibt es somit entsprechende Aufgaben, die die Bestellplanung realisieren. Diese Aufgaben operieren lesend auf dem Aufgabenobjekt Bestandsdaten. Gepflegt werden die Bestandsdaten durch den Kunden. Auf seiner Seite existieren folglich Aufgaben, die die Bestandsdaten schreibend bearbeiten. (3) Partielle Gleichheit von AO-Typen Operieren die Lösungsverfahren unterschiedlicher Aufgaben auf teilweise übereinstimmenden Attributmengen ihrer Aufgabenobjekte, so liegt eine partielle Gleichheit der AO-Typen dieser Aufgaben vor. Häufig tritt die Gleichheit von AO-Typen im Zusammenhang mit einer Identität von AO-Instanzen auf. Sind die betrachteten Aufgaben AwS unterschiedlicher Unternehmen zugeordnet, so müssen diese so gekoppelt werden, dass eine Abstimmung hinsichtlich der AO-Typen möglich ist. Ein unabgestimmtes Vorgehen kann auch hier zu Inkonsistenzen und unnötigem Aufwand führen. (4) Partielle Gleichheit von Lösungsverfahren Die vierte Beziehungsart beschäftigt sich mit der partiellen Gleichheit von Lösungsverfahren unterschiedlicher Aufgaben. Hieraus folgt wegen der Verwendung gleicher Attribute sehr häufig auch eine partielle Gleichheit der AO-Typen. Operieren die Lösungsverfahren zumindest teilweise auf den selben Instanzen, so liegt zusätzlich noch eine Identität von AO- Instanzen vor. Sind die betrachteten Aufgaben AwS unterschiedlicher Unternehmen 10

15 zugeordnet, müssen diese so gekoppelt werden, dass eine Abstimmung hinsichtlich des gemeinsamen Lösungsverfahrens möglich ist. Die Nachteile eines unabgestimmten Vorgehens liegen auch hier u. a. in potenziellen Inkonsistenzen und unnötigem Aufwand. Beispiel: Ein Hersteller von Operationsleuchten vertreibt seine Produkte direkt und über Zwischenschaltung von Händlern. Die Operationsleuchten stellen ein sehr komplexes Produkt dar, das unter Berücksichtigung der spezifischen Kundenwünsche und der Gegebenheiten am Einsatzort konfiguriert werden muss. Dieses Konfigurationswissen wird im Rahmen der Auftragsabwicklung sowohl beim Hersteller als auch bei den Händlern benötigt. Das Konfigurationswissen umfasst zum einen entsprechende Lösungsverfahren, zum anderen entsprechende AO-Instanzen (Stammdaten). Zusätzlich zur Gleichheit der Lösungsverfahren liegt hier somit noch eine Identität der AO-Instanzen und eine Gleichheit der zugehörigen AO-Typen vor. Ein anderer Fall ist in Bezug auf die konkreten Konfigurationen gegeben, die unter Verwendung des Konfigurationswissens erstellt werden. Händler und Hersteller bearbeiten unterschiedliche Kundenaufträge und somit auch unterschiedliche Konfigurationen. Hinsichtlich der Konfigurationen liegt somit keine Identität von AO-Instanzen vor, eine Gleichheit der AO-Typen ist jedoch auch hier gegeben. 4.2 Klassifikation von nicht-funktionalen Anforderungen Neben den im Geschäftsprozess spezifizierten funktionalen Anforderungen existieren noch nicht-funktionale Anforderungen an die Integration von AwS. Diese können in der OASYS- Methodik anhand eines strukturierten Katalogs erfasst werden. Der Katalog umfasst die vier Kategorien Flexibilität, Echtzeitverhalten, Integration und Korrektheit [Fers92, 11]. Diese Kategorien können anhand der Systemmerkmale Struktur und Verhalten eines AwS sowie anhand einer vorwiegend zeitpunkt- bzw. zeitraumbezogenen Betrachtung strukturiert werden. Die in Abb. 4 dargestellte Einordnung der Kategorien in dieses Raster erfolgt nach dem jeweiligen Schwerpunkt der Betrachtung. Verhalten Struktur zeitpunktbezogen Korrektheit Integration zeitraumbezogen Echtzeitverhalten Flexibilität Abb. 4: nicht-funktionale Anforderungen [Fers92, 11] Die erste Kategorie befasst sich mit Anforderungen, die sich auf die Flexibilität des Kopplungssystems beziehen. Hierunter fallen u. a. Anforderungen hinsichtlich Skalierbarkeit, Anpassbarkeit und Generizität. Unter dem Aspekt Echtzeitverhalten werden Anforderungen zusammengefasst, die sich insbesondere auf den Grad der Synchronisation zwischen den Vorgängen im Kopplungssystem und denen der abgebildeten Realität beziehen. Verfügbarkeits- [DoC80], Last- und Aktualitätsanforderungen fallen in diese Kategorie. In 11

16 der Kategorie Integration werden die Strukturmerkmale Redundanz und Verknüpfung, die Verhaltensmerkmale Konsistenz und Zielorientierung sowie Aufgabenträgerunabhängigkeit unterschieden [Fers92; FeSi01, 215ff.; MKR+00, 3ff.]. Unter der Kategorie Korrektheit werden abschließend Anforderungen erfasst, die sich auf die Eindeutigkeit, Widerspruchsfreiheit und Vollständigkeit der Aufgabendurchführungen im Kopplungssystem beziehen. Die unter den genannten Kategorien zusammengefassten Anforderungen orientieren sich u. a. an den in der ISO-Norm aufgeführten Merkmalen [ISO01]. Eine ausführliche Beschreibung des Anforderungskatalogs findet sich in [ESMS03]. 4.3 Klassifikation von Kopplungsmechanismen Ein wesentlicher Teilaspekt der Integration von AwS ist das Einrichten einer Kommunikationsverbindung zwischen diesen Systemen. Die Kommunikation findet auf verschiedenen Ebenen statt. Ein Kopplungssystem muss jede dieser Ebenen abdecken, was mithilfe von Kopplungsmechanismen geschieht. Kopplungsmechanismen werden hier aus diesem Grund, wie auch bei FLEISCH (vgl. Abschnitt 3.3), anhand der von ihnen unterstützten Kommunikationsebenen klassifiziert. In Anlehnung an CHOMSKY [Chom56] und REICHWALD [Reic93] werden die Ebenen Technik, Syntax, Semantik und Pragmatik unterschieden. Die technische Ebene der Kommunikation stellt einen gemeinsamen Kommunikationskanal bzw. ein gemeinsames Medium zwischen verschiedenen AwS zur Verfügung. Die syntaktische Ebene der Kommunikation behandelt Reihenfolge, Länge und Typ der auszutauschenden Informationen. Die semantische Ebene der Kommunikation gibt der auszutauschenden Nachricht sowie deren Inhalt eine Bedeutung. Dies ermöglicht einerseits die Unterscheidung in verschiedene Nachrichtentypen (z. B. Angebot, Lieferschein oder Rechnung) bei sonst identischem Nachrichtenaufbau, andererseits einen variablen Aufbau der Nachricht. Beispielsweise kann die Anzahl der Positionen einer Rechnung beliebig sein. Ziel der semantischen Kommunikation ist das richtige Interpretieren einer Nachricht. Die pragmatische Ebene der Kommunikation umfasst die Interpretation der Absichten, die durch die Nachricht übermittelt werden sollen. Kopplungsmechanismen können eine oder mehrere dieser Ebenen abdecken. Eine Kommunikation auf dem Niveau einer der oberen Ebenen (Syntax, Semantik, Pragmatik) kann nur erfolgen, wenn die jeweils untergeordneten Kommunikationsprobleme erfolgreich gelöst wurden. Eine übergeordnete Ebene bedient sich hierbei der darunter liegenden Ebenen. Die hier vorgestellte Klassifikation dient dazu, Kopplungsmechanismen anhand der von ihnen unterstützten Kommunikationsebenen zu unterscheiden. Dies kann bei der konkreten Auswahl von Kopplungsmechanismen am Softwaremarkt hilfreich sein, insbesondere weil viele Anbieter ihre eigene Begriffswelt für die jeweiligen Mechanismen geschaffen haben und damit eine Vergleichbarkeit erschweren. Zur Lösung der Kommunikationsprobleme der 12

17 verschiedenen Ebenen werden sehr häufig Standards eingesetzt, somit können die verwendeten Kopplungsmechanismen zusätzlich nach den unterstützten Standards klassifiziert werden. Auch bei der Auswahl von Standards selbst kann die Klassifikation helfen. Abb. 5 zeigt die verschiedenen Ebenen des vorgestellten Schichtenmodells sowie ausgewählte Standards (vgl. auch [Berl03; Hent01; Kelk01; Lint01; VoZe03]). Pragmatische Ebene der Kommunikation Standards für Aktions- und Reaktionsregeln RosettaNet, BizTalk, ebxml, E-Speak, Punchout i.v.m. cxml, Roundtrip i.v.m. xcbl Semantische Ebene der Kommunikation Syntaktische Ebene der Kommunikation Technische Ebene der Kommunikation Standards für die Bedeutung der auszutauschenden Daten Geschäftsdokumente: RosettaNet, ebxml, opentrans, cxml, xcbl, BizTalk Kataloge: BMEcat, cxml, xcbl, ecx, RosettaNet Produktklassifikation und -identifikation: ecl@ss, UN/SPSC, ETIM, NAICS, CPV, EAN-UCC Standards für das Format der auszutauschenden Daten EDI-Subsets (EDIFACT, ODETTE etc.), XML, CSV, IDoc Standards für die technische Übertragung Protokolle auf TCP/IP-Basis: HTTP, FTP, DNS, SMTP Datenschnittstellen: ODBC, JDBC, NFS Funktions-, Methoden-, Nachrichten-orientierte Applikationsschnittstellen: RPC, RFC, CORBA, J2EE, DCOM Abb. 5: Kommunikationsebenen und ausgewählte Standards 1 (in Anlehnung an [VoZe02, 16; VoZe03, 2]) 4.4 Klassifikation von Kopplungsarchitekturen Die Architektur eines Kopplungssystems wird in Form einer Kopplungsarchitektur spezifiziert. Es werden datenorientierte Kopplungsarchitekturen, ereignisorientierte Kopplungsarchitekturen und funktionsorientierte Kopplungsarchitekturen differenziert. Diese Klassifikation basiert auf einem einfachen Modell von AwS, das nur Funktionen und Kommunikation zwischen Funktionen unterscheidet. Die Funktionen in diesem Modell abstrahieren von physischen Aspekten wie Programmmodulen und Betriebssystemprozessen. Die Kommunikation zwischen den Funktionen kann in Form einer losen Kopplung oder einer engen Kopplung realisiert sein. Unter einer engen Kopplung wird die Kommunikation über Verwendung eines gemeinsamen Speichers verstanden, wohingegen bei einer losen Kopplung die Kommunikation in Form eines Nachrichtenaustausches erfolgt [FeSi01, 225]. 1 Rechte an geschützten Begriffen oder Marken liegen bei den jeweiligen Rechteinhabern bzw. Eigentümern. 13

18 (1) Datenorientierte Kopplungsarchitekturen Datenorientierte Kopplungsarchitekturen dienen der Manipulation gemeinsamer Daten 2 mehrerer AwS in Form einer engen Kopplung der auf den Daten operierenden Funktionen. Hierbei wird zwischen einer Kopplung auf Instanz- und einer Kopplung auf Typ-Ebene unterschieden. Ziel der Kopplung auf Instanz-Ebene, die von datenorientierten Kopplungsarchitekturen generell unterstützt wird, ist die gemeinsame Nutzung von Daten. Aus softwaretechnischer Sicht ist dabei z. B. zu klären, ob jedes AwS eine eigene Kopie der Daten verwaltet oder ob alle beteiligten AwS eine gemeinsame Kopie der Daten verwenden und in welchem AwS diese verwaltet wird. Ziel der Kopplung auf Typ-Ebene ist die gemeinsame Nutzung von Datenobjekttyp-Spezifikationen. Grundsätzlich können mit datenorientierten Kopplungsarchitekturen folgende Aufgabenbeziehungen realisiert werden: Partielle Identität von AO-Instanzen und partielle Gleichheit von AO-Typen. Die partielle Gleichheit von AO-Typen wird allerdings nur von datenorientierten Kopplungsarchitekturen unterstützt, die auch eine Abstimmung von Datenobjekttyp- Spezifikationen vorsehen [SMFS02]. Beispiel: Das ERP-System und das Customer-Relationship-Management(CRM)-System eines Unternehmens greifen auf eine gemeinsame, zentral gehaltene Kunden-Datenbank zu. Die Kopplung wird auf der Grundlage einer datenorientierten Kopplungsarchitektur mit nicht-redundanter Datenhaltung realisiert. (2) Ereignisorientierte Kopplungsarchitekturen Eine ereignisorientierte Kopplungsarchitektur dient der Übertragung von Ereignissen und zugehörigen Daten zwischen AwS durch Austausch von Nachrichten in Form einer losen Kopplung der entsprechenden Funktionen. Die Kopplung erfolgt hierbei in Form einer meldungsorientierten Kommunikation. Meldungsorientierte Kommunikation bezeichnet immer Einwegnachrichten. Das heißt, der Sender schickt eine Nachricht und erwartet höchstens eine Empfangsbestätigung, dass diese Nachricht empfangen wurde. [Webe98, 68]. Ereignisorientierte Kopplungsarchitekturen können zur Unterstützung folgender Aufgabenbeziehungen eingesetzt werden: Reihenfolgebeziehungen zwischen Aufgaben, partielle Identität von AO-Instanzen und partielle Gleichheit von AO-Typen. Die Gleichheit von AO-Typen wird hierbei jedoch nur fakultativ unterstützt [SMFS02]. Beispiel: Die Übermittlung einer Bestellung vom Beschaffungssystem eines Herstellers an das Auftragsbearbeitungssystem seines Lieferanten wird auf der Grundlage einer ereignisorientierten Kopplungsarchitektur realisiert. 2 Der Begriff Daten wird in diesem Beitrag im Sinne von Dateninstanzen verwendet. 14

19 (3) Funktionsorientierte Kopplungsarchitekturen Funktionsorientierte Kopplungsarchitekturen beschäftigen sich mit der gemeinsamen Nutzung von Funktionen und ggf. zugehöriger Daten durch mehrere AwS. Diese Art von Kopplungsarchitekturen muss folglich sowohl die Realisierung der Funktionen als auch die Realisierung der durch die Funktionen bearbeiteten Daten behandeln. Es muss u. a. festgelegt werden, ob Programmmodule, welche die gemeinsame Funktion realisieren, redundant oder nichtredundant gehalten werden, und wie die gemeinsame Funktion aktiviert wird. Die Aktivierung erfolgt typischerweise in Form einer losen Kopplung, die durch eine auftragsorientierte Kommunikation realisiert wird. Bei auftragsorientierter Kommunikation handelt es sich um Hin- und Rücknachrichten. Das heißt, der Sender schickt eine Auftragsnachricht und erwartet daraufhin die Rücksendung eines Ergebnisses. [Webe98, 69]. Bezüglich der Daten stellen sich hier die gleichen Probleme, die im Rahmen der datenorientierten Kopplungsarchitekturen behandelt werden. Funktionsorientierte Kopplungsarchitekturen unterstützen in jedem Fall die partielle Gleichheit von Lösungsverfahren. Je nach Ausprägung der Architektur ist zusätzlich eine Unterstützung der partiellen Identität von AO-Instanzen und der partiellen Gleichheit von AO-Typen möglich [SMFS02]. Beispiel: Ein Beispiel für eine funktionsorientierte Kopplungsarchitektur mit nicht-redundanter Modulhaltung, gemeinsamem Prozess und nicht-redundanter Datenhaltung ist die Verwaltung und Bereitstellung von Funktionen, die von mehreren AwS genutzt werden, durch einen zentralen Funktionsserver. 5 Zusammenfassung Die vorliegende Arbeit stellt Grundlagen für eine strukturierte Erfassung des Problembereichs der überbetrieblichen Integration von AwS vor. Hierbei wird zunächst mithilfe der Unternehmensarchitektur der SOM-Methodik die Integration von AwS in den Gesamtkontext der überbetrieblichen Integration eingeordnet. Es wird herausgestellt, dass auf allen drei Ebenen der Unternehmensarchitektur Integrationsprobleme zu lösen sind. Untersuchungsobjekt des Integrationsproblems auf der Ebene der AwS ist ein Kopplungssystem, das die AwS der betrachteten Unternehmen koppelt. Das angestrebte Kopplungssystem wird (1) durch den zu unterstützenden überbetrieblichen Geschäftsprozess, (2) durch nicht-funktionale Anforderungen und evtl. (3) durch gegebene Kopplungsmechanismen beschrieben. Die Lösung eines solchen Integrationsproblems wird in Form einer Kopplungsarchitektur spezifiziert. Sind die zu verwendenden Kopplungsmechanismen nicht fest vorgegeben, so müssen sie im Rahmen der Lösungsfindung ausgewählt werden und sind somit Teil der Integrationslösung. Sowohl für die einzelnen Teilbereiche des Integrationsproblems als auch für die Integrationslösung werden Klassifikationen angeboten. Zur Klassifikation von Geschäftsprozessen 15

20 werden unterschiedliche Arten von Beziehungen zwischen den Aufgaben des überbetrieblichen Geschäftsprozesses herangezogen. Für die strukturierte Erfassung der nichtfunktionalen Anforderungen wird ein Katalog vorgestellt. Kopplungsmechanismen werden anhand der unterstützten Kommunikationsebenen und der unterstützten Standards kategorisiert. Abschließend werden mit ereignis-, daten- und funktionsorientierten Architekturen drei Arten von Kopplungsarchitekturen klassifiziert und abgegrenzt. Die vorgestellten Klassifikationen im Bereich des Integrationsproblems ermöglichen eine strukturierte Erfassung von Integrationsproblemen. Die Klassifikationen im Bereich der Integrationslösung bieten eine Unterstützung bei der Lösungssuche. Die vorgestellte Einordnung von Kopplungsmechanismen bez. der unterstützten Kommunikationsebenen ist z. B. hilfreich bei der konkreten Auswahl von Kopplungsmechanismen am Softwaremarkt. An den vorgestellten Klassifikationen zur überbetrieblichen Integration von AwS orientiert sich das KOELMA-Projekt in Teilbereichen, im OASYS-Projekt bilden sie den Kern einer Entwicklungsmethodik für die überbetriebliche Integration von AwS. Eine ausführliche Beschreibung dieser Methodik findet sich in [MES+04]. 16