Integration von Informationssystemen; Integration of information systems;

1 Einleitung

Die Integration von Geschaftsprozessen istbetriebswirtschaftlicher Kern modernerKonzepte der zwischenbetrieblichen Wert-schopfung. Elektronische Markte fokussie-ren als Informationssysteme den markt-basierten Austausch zwischen Agenten inallen Transaktionsphasen [BaBo01, 590;Schi01, 175]. Die Teilnehmer entlang derWertschopfungskette sind dabei prinzipiellgleichberechtigt und besitzen vollstandigeAutonomie. Der Markt wird als der einzigeubergeordnete Koordinationsmechanismusakzeptiert. Im Gegensatz dazu basiert dasKonzept des Supply-Chain-Managementsauf einer von allen Partnern akzeptierten,ubergeordneten Koordinationsinstanz.Supply-Chain-Management (SCM) strebtaus Gesamtsicht abgestimmte, uberbetrieb-liche Wertschopfungsprozesse mit demZiel der maximalen Befriedigung der Kon-sumentenbedurfnisse unter Einschluss desService an [Chri98, 7 f.; Ross98, 267; Be-Ja97, 16 ff.; Stad00, 7 ff.]. Insbesondere Ad-vanced Planning Systems (APS) zur uber-betrieblichen Planung dienen alsKoordinationsinstrumente [Goet00, 79 ff.].Zur Realisierung der hier beispielhaft ge-nannten betriebswirtschaftlichen Konzeptemussen heterogene Anwendungssystemegekoppelt und Geschaftsprozesse integriertwerden. Anwendungssysteme sind zu ver-stehen als auf betriebswirtschaftlich-fachli-che Aufgabenstellungen ausgerichtete Soft-waresysteme [Seib01, 46]. Die Kopplungder betrieblichen Anwendungssysteme istTeil der Integration von Informationssyste-men, welche, zusatzlich zu den Anwen-dungssystemen, organisatorische Ablaufe

und die Zusammenarbeit von Menschenumfassen [Seib01, 47; Schu98, 66 f.; Teub99,26].

Der vorliegende Beitrag gibt einen �ber-blick uber Standards und Techniken, diefur die Integration von Informationssyste-men relevant sind. Diese werden inAbschnitt 2 anhand der bekannten Ent-wicklungsphasen Fachkonzeption, DV-Konzeption und Implementierung syste-matisiert. Da derzeit keine allgemeinakzeptierte Methode zur Integration vonInformationssystemen verfugbar ist, wer-den in Abschnitt 3 methodische Integrati-onsansatze anhand eines Rahmenmodellssystematisiert. Ziel ist es, einen erstenSchritt zur Entwicklung einer Integrations-methode aufzuzeigen. Der Beitrag schließtmit einer Zusammenfassung (Abschnitt 4).

2 Systematisierungausgewahlter Standards,Konzepte und Technikenmittels derIS-Entwicklungsphasen

Aktuell werden in der Literatur eine Fullevon Standards, Konzepten und Technikendiskutiert, die in einzelnen Phasen der In-formationssystementwicklung unterschied-liche Gestaltungsoptionen eroffnen. Siewerden in diesem Abschnitt in Anlehnungan die ARIS-Architektur [Sche98, 18 ff.;Sche97a, 19 ff.] anhand der bekannten Pha-sen der Informationssystementwicklungsystematisiert. In jeder Entwicklungsphasesind Entscheidungen zu treffen, fur welche

WIRTSCHAFTSINFORMATIK 45 (2003) 1, S. 41–52

Der Autor

Roland Holten

Dr. Roland Holten,Westfalische Wilhelms-UniversitatMunster,Institut fur Wirtschaftsinformatik,Leonardo-Campus 3, 48149 Munster,E-Mail: [email protected]

Integrationvon Informationssystemen

WI – State-of-the-Art

die Standards, Konzepte und Techniken alsGegenstande oder Hilfsmittel von Bedeu-tung sind.

In der Phase der fachkonzeptionellen Spe-zifikation ist festzulegen, was die Integrati-on der Informationssysteme aus betriebs-wirtschaftlicher Domanensicht leisten soll.Diese Phase ist als Teil des RequirementsEngineering zu verstehen. In der Phase derSpezifikation des DV-Konzeptes wird fest-gelegt, welche Bausteine oder Komponen-ten zur Integration der IS erforderlich sind

und wie diese interagieren sollen. DiesePhase entspricht der Designphase des Soft-ware Engineering und spezifiziert die In-formationssystemarchitektur. In der Imple-mentierungsphase schließlich werden diebenotigten Komponenten algorithmischund programmtechnisch umgesetzt. Dertechnische Stand der logisch nachgeord-neten Implementierungsphase limitiertEntscheidungen in der Phase DV-Konzep-tion. Entsprechendes gilt fur das Verhaltnisvon DV- und Fachkonzeption. Daher wirdder Stand der Technik zur Integration von

Informationssystemen in der ReihenfolgeImplementierung, DV-Konzeption undFachkonzeption erlautert.

2.1 Implementierungsphase

Die aktuelle Diskussion zur Kopplung vonInformationssystemen ist bezogen auf dieImplementierungsphase ganz wesentlichdurch das Potenzial von XML gepragt.Insbesondere das Simple Object AccessProtocol (SOAP) zum Austausch vonNachrichten zwischen Endpunkten (sog.peers) in dezentralen, verteilten Umgebun-gen ist von Bedeutung. Des Weiteren wirdin diesem Abschnitt das Problemfeld desSchema-Matchings angesprochen. Schema-Matching hat die Kopplung von unter-schiedlich strukturierter Information zumGegenstand und ist somit ein Kernproblemin heterogenen Anwendungssystemland-schaften.

Simple Object Access Protocol (SOAP)

Das Simple Object Access Protocol (SOAP)definiert anhand des strukturellen Aufbauseine wichtige Klasse von XML-Dokumen-ten zur Kopplung von Anwendungssyste-men [BEK+00; Holl02, 98]. Die ExtensibleMarkup Language (XML) selbst ist einetextbasierte Meta-Auszeichnungssprachefur Beschreibung, Austausch, Darstellungund Manipulation von strukturierten Da-ten. Sie wurde vom World Wide Web Con-sortium (W3C) 1998 als Standard ver-abschiedet [BPSM00; BuLW01, 259 f.] undgilt als syntaktische Standard-Infrastrukturzur Kopplung von Anwendungssystemen[WeHB01, 66]. SOAP als Protokoll defi-niert eine modulare Struktur zum Aufbauund zur Kodierung von XML-Dokumen-ten und besteht aus den drei Teilen „Enve-lope“, „Encoding Rules“ und „RPC Re-presentation“ [BEK+00].

Als umfassendes Rahmenmodell spezifi-ziert der erste Teil des Protokolls (Envelo-pe) inhaltlich, was sich in der Nachrichtbefindet, wer damit umgehen soll und, obdie Bearbeitung der Nachricht fur dieadressierte Ressource zwingend oder op-tional ist. Im zweiten Teil des Protokolls(Encoding Rules) werden die sehr flexiblenStrukturierungsregeln von XML durch ei-ne begrenzte Menge von Moglichkeitenzur Definition von Datentypen einge-schrankt. Insbesondere wird festgelegt,dass Typen von Werten ausschließlich mit


POST /StockQuote HTTP/1.1Host: www.stockquoteserver.comContent-Type: text/xml; charset="utf-8"Content-Length: nnnnSOAPAction: "Some-URI"

<SOAP-ENV:Envelopexmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/><SOAP-ENV:Header>

<t:Transactionxmlns:t="some-URI"SOAP-ENV:mustUnderstand="1">

5</t:Transaction>

</SOAP-ENV:Header><SOAP-ENV:Body>

<m:GetLastTradePrice xmlns:m="Some-URI"><symbol>DEF</symbol>

</m:GetLastTradePrice></SOAP-ENV:Body>

</SOAP-ENV:Envelope>

SOAP Message Embedded in HTTP Request

HTTP/1.1 200 OKContent-Type: text/xml; charset="utf-8"Content-Length: nnnn

<SOAP-ENV:Envelopexmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/><SOAP-ENV:Header>

<t:Transactionxmlns:t="some-URI"xsi:type="xsd:int" mustUnderstand="1">

5</t:Transaction>

</SOAP-ENV:Header><SOAP-ENV:Body>

<m:GetLastTradePriceResponsexmlns:m="Some-URI">

<Price>34.5</Price></m:GetLastTradePriceResponse>

</SOAP-ENV:Body></SOAP-ENV:Envelope>

SOAP Message Embedded in HTTP Response

BO

DY

HE

AD

ER

EN

VE

LOP

E

BO

DY

HE

AD

ER

EN

VE

LOP

E

Bild 1 Beispiele fur SOAP-Nachrichten [BEK+00]

42 Roland Holten

Bezug auf ein Schema ermittelt werdendurfen [BEK+00]. XML-Schemas beschrei-ben formal syntaktische Anforderungen anXML-Dokumente und sind selber in derBeschreibungssprache XML formuliert[BiMa01; Fall01; TBMM01; WeHB01, 29].

Im dritten Teil des Simple Object AccessProtocols (RPC Representation) werdenKonventionen zur Reprasentation von sog.Remote Procedure Calls (RPC) definiert.Ein wesentliches Gestaltungsziel von SO-AP ist es, RPCs kapseln und austauschenzu konnen [BEK+00]. Prozeduren auf ent-fernten Rechnern werden durch sog. Uni-form Resource Identifiers (URIs) identifi-ziert. URIs sind Text-Strings mit einerstandardisierten Syntax, die auf Internet-Ressourcen verweisen [W3C; BFIM, 98].Jede Ressource im Internet wird durch ei-nen URI identifiziert. Als Ressourcen wer-den Dokumente, Maschinen (Ressourcenim eigentlichen Sinne), Prozeduren undPersonen angesehen. In der grundlegendenQuelle zu URIs spezifizieren [BFIM, 98]das URI-Schema und zeigen, dass URIsz. B. die Uniform Resource Locators (URL)umfassen. Um eine Prozedur (Methode)auf einem entfernten Rechner auszufuhren,verlangt SOAP folgende Informationen:Den URI des Zielobjektes, den Namen derMethode, eine optionale Signatur der Me-thode zur Definition von Typen und Na-men der Parameter, die Parameter der Me-thode selbst und optionale zusatzlicheInformationen, die fur die Kodierung desMethodenaufrufes relevant sind (headerdata).

SOAP-Nachrichten (Messages) sind XML-Dokumente, die den strukturellen Vor-gaben von SOAP entsprechen. Sie sind ineinen obligatorischen SOAP Envelope ein-gefasst, enthalten einen optionalen SOAPHeader und einen obligatorischen SOAPBody [BEK+00]. Der SOAP Envelopekennzeichnet eine Nachricht als SOAP-Nachricht. Der SOAP Header erlaubt es,bestimmte Eigenschaften von SOAP Mes-sages zu definieren, die in einer verteiltenUmgebung verwendet werden konnen, oh-ne vorher zwischen den Kommunikations-partnern vereinbart worden zu sein. DerHeader kann zusatzlich Attribute umfas-sen, die spezifizieren, wer die Nachrichtverarbeiten soll, und ob diese Verarbeitungzwingend oder optional ist. Der SOAPBody umfasst obligatorische Informatio-nen fur den endgultigen Empfanger derNachricht. Methodenaufrufe und Antwor-ten von RPCs werden im SOAP-Body-

Element transportiert. Bild 1 zeigt Beispie-le von SOAP-Nachrichten: Von einerbeliebigen Ressource („Some-URI“) wer-den Aktienkurse angefordert (oberer Teil)und das Ergebnis („34.5“) wird zuruck-gesendet (unterer Teil). Sowohl Anfrage alsauch Antwort enthalten einen optionalenHeader, der festlegt, dass die Nachrichtvom jeweiligen Empfanger verstanden wer-den muss (Wert „1“ der Option „mustUn-derstand“).

Mit Bezug auf das 7-Schichten-ISO/OSI-Referenzmodell zur Kommunikation vonSystemen [ISO94; StHa97, 124 f.] ist XML– und damit auch SOAP – der sechstenSchicht, der Darstellungssicht (presentationlayer), zuzuordnen [Holl02, 96].

Schema-Matching

In heterogenen Umgebungen, in welchenz. B. Electronic Data Interchange (EDI),SOAP oder proprietare Datenformatebeim Austausch von Nachrichten genutztwerden, ist das sog. Schema-Matching eingrundlegendes Problem. Um Anwen-dungssysteme zu integrieren, mussen hau-fig Teilschemas aus unterschiedlichenDomanen verglichen oder integriert wer-den. Beispielsweise gehort das Attribut„AccountOwner“ zum Schema eines Fi-nanzinformationssystems, wahrend dasAttribut „Customer“ aus einer Verkaufs-datenbank herruhrt (Bild 2). Anwendungs-systementwickler konvertieren die beno-tigten Formate dann manuell oderwerkzeugunterstutzt [RaBe01, 335 ff.].

Komplexe Schema-Matching-Vorgangewerden in einzelne Matching-Operationengegliedert, welche auf der Grundlage vonMetadaten (Schemainformationen) arbei-

ten. Metadaten beschreiben z. B. die Da-tentypen einzelner Attribute oder dieStruktur komplexer Datentypen. Es ist furKonvertierungsvorgange im Allgemeinennicht moglich, alle erforderlichen Mat-ching-Operationen auf der Grundlage ver-fugbarer Metadaten vollstandig automati-siert zu generieren. Der Hauptgrund dafurist, dass es immer semantische Aspekte vonSchemas gibt, die nicht formal spezifiziertoder dokumentiert sind. Die entsprechen-den Metainformationen fehlen in solchenFallen. Attribute von Datentypen oder Da-tenstrukturen mussen dann aus dem Quell-code der Anwendungssysteme rekonstru-iert werden. Die Unterstutzung desSchema-Matchings muss sich daher daraufbeschranken, Kandidaten fur das Matchingzu identifizieren, die von Anwendungssys-tementwicklern im Rahmen der Integrationakzeptiert, verworfen oder geandert wer-den konnen. Einen �berblick uber aktuellePrototypen, die sich diesen Aspekten desSchema-Matchings widmen, geben [Ra-Be01, 343 ff.].

Strukturell liegt dem Schema-Matching einsog. Mapping zugrunde (Bild 2) [RaBe01,336]. Ein Mapping ordnet Elemente (Attri-bute oder komplexe Strukturen) einesSchemas einem anderen Schema zu. EinMapping-Element bildet Elemente einesSchemas S1 auf Elemente eines Schemas S2ab. Ein Mapping fur einen Konvertierungs-vorgang besteht ublicherweise aus einerMenge von Mapping-Elementen, welchedurch formale Mapping-Ausdrucke spezi-fiziert sein konnen. Mapping-Elementebasieren jedoch haufig auf heuristischenKriterien und mussen durch Anwendungs-systementwickler entsprechend in Abbil-dungsvorschriften umgesetzt werden.


Kernpunkte fur das Management

& Konzepte zur Integration von Geschaftsprozessen erfordern die Integration von Informati-onssystemen.

& Aktuelle Standards und Techniken, die fur die Informationssystemintegration relevantsind, werden anhand akzeptierter Entwicklungsphasen systematisiert und erlautert.

& Methodische Aspekte der Integration von Informationssystemen werden in einem Rah-menmodell zusammengefuhrt.

Stichworte: Anwendungssystem-Kopplung, Enterprise Application Integration,Integrations-Rahmenmodell, Komponentenbauweise, Meta-Informationssystem, RosettaNet,Schema-Matching, SCOR-Modell

Integration von Informationssystemen 43

[RaBe01] schlagen eine Taxonomie fur dasSchema-Matching-Problem vor. Sie klassi-fizieren Matching-Operationen anhandfolgender Kriterien [RaBe01, 337]:

& Instanz- versus Schema-Matching: Eswird unterschieden, ob die Matching-Operationen lediglich Schemainformati-on oder auch Elemente der Auspra-gungsebene berucksichtigen.

& Element- versus Struktur-Matching: Ei-ne Matching-Operation kann element-weise, z. B. fur einzelne Attribute oderfur komplexe Datenstrukturen, bei-spielsweise fur XML-Elemente, definiertwerden.

& Sprach- versus Constraint-Matching:Namen oder textuelle Beschreibungenkonnen die Basis von Matching-Opera-tionen sein (linguistic approach); oder eskonnen Schlusselbeziehungen und sons-tige Relationen herangezogen werden(constraint-based approach).

& Matching-Kardinalitaten: Ein Matching-Element kann im Sinne der bekanntenKardinalitaten als 1 : 1-, 1 : n-, n : 1- odern:m-Relation zwischen zwei Schemasklassifiziert werden.

& Hilfsinformationen fur das Matching:Zusatzlich kann Information aus Data-Dictionaries, globalen Schemas, fruhe-ren Matching-Operatoren und nichtdokumentiertem Nutzerwissen heran-gezogen werden.

Dem Schema-Matching-Problem speziell inXML-Umgebungen widmet sich der For-schungsprototyp SIMPLEX [BuMW01;BuMW02]. Der Konvertierungsvorgangwird bei SIMPLEX durch Abbildungsvor-

schriften in Form sog. XSL Transformati-ons (XSLT) spezifiziert. XSLT ist eineSprache zur Transformation von XML-Dokumenten in andersartig strukturierteXML-Dokumente [Clar99]. XSLT stellt einVokabular zur Beschreibung von Transfor-mationsregeln bereit, welche, ohne die Se-mantik zu andern, ein XML-Dokumentelementweise in eine andere Struktur uber-fuhren [BuMW01, 450; WeHB01, 40 ff.].

2.2 Phase der DV-Konzeption

In der Phase der DV-Konzeption ist zuspezifizieren, aus welchen Bausteinen In-formationssysteme bestehen sollen und wiediese zu integrieren sind. Die aktuell dis-kutierten Konzepte komponentenbasierteAnwendungssysteme und Enterprise Appli-cation Integration (EAI) sind aus Sicht derDV-Konzeption von Bedeutung. DieserAbsatz beschreibt zunachst das Konzeptder komponentenbasierten Anwendungs-systeme und erlautert eine darauf basieren-de Anwendungssystemarchitektur. An-schließend wird das Konzept EAIdargestellt.

Komponentenbasierte Anwendungs-systemarchitektur

Das Konzept komponentenbasierter An-wendungssysteme ist fur die Realisierungder Integration von Informationssystemenrelevant [Turo01]. Die Komponententech-nologie hat bisher wesentliche Beitragezur Bildung von Informationssystemar-

chitekturen geleistet. Den derzeitigenStand der Technik stellen Komponentenzur Datenhaltung, Steuerung der Ablaufe,Prasentation und Vermittlung von Diens-ten dar [RaTu01, 681 ff.]. Die Visionkomponentenbasierter Anwendungssyste-me geht davon aus, dass sog. BusinessObjects (betriebliche Anwendungssystem-komponenten) kommerziell verfugbarsind und zu komplexen Anwendungssys-temen kombiniert werden konnen. An-wendungssysteme werden dadurch flexib-ler anpassbar an geanderte geschaftlicheoder technische Rahmenbedingungen,weil die Komponenten leichter als in mo-nolithischen Systemen austauschbar sind[Turo01, 269; Wesk99, 6]. Die Kombinier-barkeit von Business Objects basiert aufeiner fachlichen und technischen Standar-disierung [Wesk99, 6; RaTu01, 688 f.].Die (betriebliche) Ablauflogik wird indiesem Konzept zentral durch Work-flowmanagementsysteme (WFMS) gesteu-ert [BeMG02, 44 ff.; RaTu01, 682 f.]. DieKommunikation zwischen den BusinessObjects und den ubrigen Komponentenwird durch sog. Middleware unterstutzt,welche z. B. als Vermittler zwischen denKomponenten und den Netzwerkdienstenfungiert. Die Common Object RequestBroker Architecture (CORBA) stellt einenentsprechend standardisierten Ansatz dar[Wesk99, 7].

Ausgehend vom Konzept komponenten-basierter Anwendungssysteme konnen inAnlehnung an [RaTu01, 683 f.] drei Grup-pen von Komponenten unterschieden wer-den (Bild 3):


S1 elements S2 elements

Address

StreetCityStateZIP

CustomerAddressStreetCityUSStatePostalCode

AccountOwner CustomerName

BirthdateTaxExempt

CnameCaddressCphone

Address

...

...

Mapping-Element

Mapping

Ver

mitt

lung

Präsentation

Ablauf(WFMS)

Datenhaltung

Funktion

Legende:Komponenten für EnterpriseApplication Integration (EAI)

Bild 2 Beispiel zur Struktur des Schema-Matchings Bild 3 Anwendungssystemarchitektur zur Komponentenbauweise

44 Roland Holten

& Die Systemkomponente Funktion decktbetriebliche Anwendungsfalle (wie Pro-duktionsplanung und –steuerung, Wa-renwirtschaft, Finanzbuchhaltung usw.)ab.

& Die Systemkomponenten Ablauflogik(WFMS), Datenhaltung und Prasentati-on sind unabhangig von konkreten be-trieblichen Aufgaben verwendbar.

& Die Systemkomponente Vermittlungumfasst alle Komponenten zur Losungdes Kommunikationsproblems in hete-rogenen technischen Umgebungen.

Auch wenn die Vision der komponenten-basierten und flexibel kombinierbarenAnwendungssysteme aus konzeptionellerSicht einen erheblichen Reiz bietet und imBereich der technischen Komponenten(insbes. Datenbankmanagementsysteme,WFMS und Middleware zur Vermittlung)beeindruckende Resultate erzielt wurden,sind Anwendungssysteme in der Realitatheute keinesfalls aus Komponenten belie-big kombinierbar. In der Fachliteratur wirdsogar bestritten, „dass eine vollstandige(fachliche) Standardisierung der betriebli-chen Anwendungsdomane jemals gegebensein wird“ [RaTu01, 689; Turo01, 270]. Ineiner aktuellen empirischen Studie wirdder Mangel an Entwicklungsmethoden undWerkzeugen als wesentlicher Grund furdie bisher nicht erfullten Erwartungen andie Komponententechnologie im Bereichbetrieblicher Anwendungssysteme identifi-ziert [DiEs01, 708].

Enterprise Application Integration (EAI)

Aktuell werden in der Literatur unter demSchlagwort Enterprise Application Integra-tion (EAI) Gestaltungsoptionen zur Inte-gration von Informationssystemen dis-kutiert. Nach Sichtung einer Vielzahl vonDefinitionen grenzen [BuCP01] EAI als„Integration von Anwendungen uber un-terschiedliche technische und logischeInfrastrukturen hinweg“ [BuCP01, 9] ab.Techniken und Prozesse von individuellerund Standardsoftware sind uber EAI somiteinander kombinierbar, „dass Ge-schaftsprozessdaten in Format und Zusam-menhang jederzeit ausgetauscht werdenkonnen, ohne dass dabei die Bedeutungder Daten verandert wird bzw. verlorengeht“ [BuCP01, 9].

EAI umfasst die beiden Aspekte zentralesSchema-Matching (Komponenten Vermitt-lung) der Anwendungssysteme und zentra-le Ablaufsteuerung. Diese sind in der Sys-temarchitektur zur Komponentenbauweise

(Bild 3) grau hinterlegt dargestellt. BeideAspekte zusammen fuhren zu einer Hub-and-spoke-Architektur [Kopp01, 93]. DasKonzept Workflowmanagement (WFM)geht wie EAI ebenfalls von einer zentralen,betrieblichen Ablaufsteuerung der Anwen-dungssysteme aus [BeMG02, 44 ff.; Ra-Tu01, 682 f.]. Das Verhaltnis von EAI undWFM ist derzeit in der Literatur nochnicht abschließend geklart. Es gibt Stim-men [Mari02, 136 f.], die EAI als relevantfur Prozesse mit sehr kurzer Lebensdauer(im Sekunden- oder Minutenbereich) undWFM fur solche mit einer Lebensdauervon Tagen oder gar Monaten ansehen. Au-ßerdem wird EAI im Vergleich zu WFMals besser geeignet fur die Kopplung vonAnwendungssystemen und als schlechtergeeignet fur menschliche Prozessinterakti-on angesehen [Mari02, 136 f.]. Es wirdauch vorgeschlagen, EAI als Konzept, wel-ches WFM umfassen konnte, anzusehen[Ston01, 5]. Diesem Ansatz folgend wirdhier lediglich EAI weiter erlautert.

Schon der EAI-Aspekt des zentralen Sche-ma-Matchings alleine erzwingt eine zentra-lisierte Architektur (Bild 4). Zur Durch-fuhrung des Schema-Matchings mussenSchema-Informationen der einzelnenKomponenten importiert und exportiertund intern reprasentiert werden konnen.Ein Beispiel fur globale Bibliotheken zumSchema-Matching sind XML Namespaces,die uber einen eindeutigen URI adressiertwerden [RaBe01, S. 341]. Ein XML Name-space ist eine zentrale Zusammenstellung

von Namen, die in XML-Dokumenten de-zentral fur Elementtypen und Attributebenutzt werden [BrHL99]. Diese Zusam-menstellung wird als markup vocabularybezeichnet und definiert die universell ein-heitliche Gultigkeit von Namen uber ein-zelne Module und Dokumente hinaus. Dajedoch nicht vermutet werden kann, dassalle Welt einem zentralen Schema (z. B. ei-nem markup vocabulary) zustimmen wird,sollten Schemas im Rahmen uberschauba-rer Projekte zentral definiert werden, umdie Varietat zu reduzieren, also etwa inner-halb eines Unternehmens bzw. innerhalbeines Netzwerks von Geschaftspartnern[RaBe01, S. 341].

Der zentralisierte Integrationsansatz desEAI wird gelegentlich als „Ruckgrat derunternehmensweiten Informationsver-arbeitung“ [BuCP01, 11] bezeichnet. SeineBedeutung als Kern der semantischenKopplung von Anwendungssystemen zei-gen [LiKS99] anhand von Prototypen. DieAnzahl der Schnittstellen zwischen An-wendungssystemkomponenten kann auf-grund der zentralisierten EAI-Strukturvon n*(n�1)/2 � O(n2) auf O(n) reduziertwerden [LiKS99, 12; Mari02, 133 f.]. Dabeibezeichnet n die Anzahl der zu integrieren-den Schnittstellen der Anwendungssystemeund O(x) in Anlehnung an die Komplexi-tatstheorie die Abschatzung des Aufwan-des des Integrationsproblems. Es wird da-von ausgegangen, dass der Aufwandgemessen in Entwicklungs- und Wartungs-zeit in Abhangigkeit von der Anzahl der


Zentrale Bibliotheken(Data Dictionaries,

Schemas ...)

Portal-SchemasDatenbank-

schemas (OLTP)

Data-Warehouse-

SchemasWFM-Schemas

Interne Schema-Repräsentation

Generischer Matching-Operator

Schema-Import/Export

Legende:

OLTP Online Transaction Processing

WFM Workflowmanagement

Bild 4 High-level-Architektur des zentralisierten, generischen Schema-Matchings (inAnlehnung an [RaBe01, 337])


zu integrierenden Schnittstellen mindestenslinear steigt.

EAI-Werkzeuge unterstutzen die semanti-sche Integration von Informationssyste-men, da die Nutzung zentraler Biblio-theken neben der syntaktischenVereinheitlichung auch eine eindeutige Be-deutung der verwendeten Komponentengarantiert [Mari02, 134 f.]. Der Datentyp„Kunde“ beispielsweise hat somit nichtnur eine einheitliche Struktur, sondernauch eine einheitliche Bedeutung. Derzeitsind eine Fulle von Systemen fur den Be-reich EAI am Markt verfugbar (vgl. zu ei-nem �berblick [BuCP01]). Nahezu alleEAI-Systeme bieten XML-Schnittstellen.Die Auswahl von geeigneten EAI- undWFM-Systemen im Rahmen der Spezifika-tion des DV-Konzeptes ist in der Literaturmehrfach behandelt worden. Eine Vor-gehenssystematik zur Auswahl von EAI-Systemen findet sich bei [BuCP01, 24–42].[WGHS01, 40 f.] definieren fur die Aus-wahl von WFMS eine Hauptphase„Design“, welche als Teilaktivitat die Spe-zifikation von workflowgestutzten Soll-prozessen (to-be workflow modeling) um-fasst und Voraussetzung der Phase der

Systemauswahl (System Selection) ist. Wirdweniger strukturiert vorgegangen, kann ei-ne Auswahlentscheidung beispielsweise aufeiner sog. „process choreography“, die alsVertrag zwischen mehreren zu verbinden-den Prozessen bzgl. deren Kommunikationzu verstehen ist, basieren [Mari02, 141].Ein Beispiel fur eine solche process cho-reography ist der Ansatz des sog. EDI-Workflows [Sche97b, 201 ff.]. Dort werdenim Rahmen der semantischen Geschafts-prozessintegration EDIFACT-Nachrich-tentypen und die damit verbundenen Ge-schaftsprozesstypen als Grundlage derunternehmensubergreifenden Kopplungvon Anwendungssystemen herangezogen.Es wird außerdem ein Werkzeug kon-zipiert, dass diese Kopplung auf Prozess-ebene unterstutzt [Sche97b, 209 ff.].

Neben dem zentralisierten Ansatzes zurKopplung von Anwendungssystemen wer-den dezentrale Ansatze diskutiert. Ein Ar-chitektur-Beispiel liefert der Einsatz vonMicrosofts BizTalk Server [BizT02]. Ver-schiedene BizTalk Server kommunizierendezentral anhand standardisierter Aus-tauschformate (sog. BizTalk-Messages)[WeHB01, 84 ff.; BizT02]. BizTalk-Mes-

sages basieren auf SOAP als syntaktischemStandard und einem zentral vereinbarten(und in einem Repository abgelegten) se-mantischen Standard [WeHB01, 88]. UnterVerwendung eines XML-Schemas aus demzentralen Repository werden Geschafts-dokumente, die aus dezentralen Applika-tionen stammen (etwa eine Bestellung), inBizTalk-Messages umgewandelt und an ei-nen Ziel-Server gesendet (Bild 5). Dortwerden sie im umgekehrten Verfahren ubereine XML-Schnittstelle der entsprechendenZiel-Applikation bereitgestellt. Aufgrunddes standardisierten Austauschformateszwischen allen beteiligten BizTalk Servernund der einheitlich definierten Semantikder Nachrichtentypen, bestehen bei diesemSzenario die oben erlauterten Schwierig-keiten des Schema-Matchings und der Ver-waltung einer Vielzahl von Schnittstellennicht. Allerdings kann dieses Szenario nurin eng abgegrenzten Bereichen umgesetztwerden und es ist auch langfristig mit hete-rogenen Anwendungssystemlandschaftenzu rechnen.

2.3 Phase der fach-konzeptionellen Spezifikation

Aus fachkonzeptioneller Sicht sind zu-nachst die zu koppelnden Geschaftspro-zesse zu spezifizieren, um anschließend dieSchnittstellen zwischen den Anwendungs-systemen der betroffenen Funktionsberei-che spezifizieren zu konnen. Zum Beispielwerden im Rahmen des Supply-Chain-Ma-nagements (SCM) derzeit Konzepte wieFourth-Party-Logistik (4PL) und 4PL-Marktplatze diskutiert [Niss01]. Eineumfassende informationstechnische Ver-netzung der Logistikprozesse durch 4PL-Logistikmarktplatze mit Standardtech-nologien wie TCP/IP und XML ist heutegrundsatzlich moglich [PoLi99]. Jedochbestehen zentrale Herausforderungen inder Definition geeigneter Schnittstellen zuden beteiligten ERP-Systemen der Kundenund in der Anpassung der Geschaftspro-zesse der beteiligten Parteien [Niss01, 600].Damit Geschaftsprozesse zwischen Part-nern der betriebswirtschaftlichen Logikgemaß integriert werden konnen, mussenzunachst die domanenspezifischen Fach-sprachen vereinheitlicht werden. DieserAbschnitt erlautert die Bedeutung von Re-ferenzmodellen fur die Vereinheitlichungvon Fachterminologien und stellt dann mitdem SCOR-Modell und RosettaNet zweiReferenzmodelle fur die Integration bran-


BizTalk Message

BizTalk Document

BizTalk Header

Document Body

Transport Envelope

BizTalk Server BizTalk Server

Zentrales Repository

(schema library)

Anwendungssystem

Adapter zu BizTalk

5. BizTalk-Message wirdan Zielserver gesendet

6. BizTalk- Message wirdgeprüft und der Ziel-Applikation bereitgestellt

3. BizTalk-Dokumentwird zum Server gesendet

1. Anwendungsereignis trittein

2. Adapter generiert BizTalk-

Dokument zu Schema aus demRepository

4. BizTalk-Message wirderzeugt

BizTalk-Dokument

BizTalk Header

Document Body

Adapter zu BizTalk

BizTalk-Dokument

BizTalk Header

Document Body

Anwendungssystem

Bild 5 Beispiel zum dezentralen Ansatz der Kopplung von Anwendungssystemen

46 Roland Holten

chenspezifischer Informationssysteme vor.Anschließend werden weitere Standardisie-rungsbemuhungen und – initiativen skiz-ziert.

In der Literatur werden Entwicklung undNutzung von Fachsprachen unter denSchlagworten Ontologie, Terminologieund Referenzmodell diskutiert. Mit Termi-nologie und Ontologie werden Begriffssys-teme fur ein bestimmtes Fachgebiet be-zeichnet. Terminologien wurden zunachstin der Sprachanalyse betrachtet [Seif96, 56].Ontologien – als ein Zweig der Philoso-phie [Bung77] – werden derzeit intensiv inder (Wirtschafts-)Informatik untersucht.Beispielsweise stellen Wand und Weber inmehreren Beitragen aufbauend auf den Ar-beiten von [Bung77] eine umfassende On-tologie fur Informationssysteme vor [Wa-We89; WaWe90a; WaWe90b; WaWe93a;WaWe93b]. Diese Ontologie wird in aktu-ellen Beitragen verwendet, um Architekturund Modellierungsmethoden von ARIS[Sche98, 18 ff.; Sche97a, 19 ff.] zu analysie-ren [GrRo00; RoGr99]. Ausgehend vonden angegebenen Quellen liegt es nahe, denBegriff Ontologie im Rahmen der Ent-wicklung von Modellierungsmethoden derWirtschaftsinformatik und den Begriff Ter-minologie fur den Bereich der fachlichenDurchfuhrung von Geschaftsprozessen, et-wa bei der Integration von Fachsprachenin Supply-Chain-Management-Projekten,zu verwenden [GaNW99]. Referenzmodel-le formulieren Sollempfehlungen fur eineKlasse von Anwendungsgebieten und er-hohen die Wirtschaftlichkeit der Informati-onsmodellierung, indem sie Ausgangs-losungen zur Verfugung stellen [BDKK02,25 f.]. Sie liefern damit auch Grundlagenzur Vereinheitlichung der Fachterminolo-gien in den betrachteten Domanen[Ortn00, 10]. Initiativen wie das SupplyChain Council (SCC) und RosettaNet, er-stellen Referenzmodelle fur abgegrenzteBranchen.

Das SCC entwickelt als gemeinnutziger,weltweit agierender Verein mit Mitgliedernaus Wirtschaft, Wissenschaft und Verwal-tung mit dem Supply Chain OperationsReference Model (SCOR) ein Referenzmo-dell zur Gestaltung und Kopplung von un-ternehmensubergreifenden Geschaftspro-zessen [Step01; SCC01a; SCC01b]. Diesesbietet außerdem ein System von Kennzah-len zur Unterstutzung der Leistungsmes-sung, spezifiziert fur die einzelnen Prozes-se empfohlene Vorgehensweisen (sog. BestPractices) sowie Vorschlage, wie sich diese

durch Softwarefunktionalitaten geeignetunterstutzen lassen [KaBl00, 134]. DasSCOR-Modell ist in vier Ebenen geglie-dert, von denen lediglich die obersten dreiGegenstand der Ausarbeitungen in[SCC01a] sind. Auf der hochsten Ebenewerden die funf Kernprozesse Planung(Plan), Beschaffung (Source), Produktion(Make), Vertrieb (Deliver) und Retouren(Return) definiert. Die zweite Ebene glie-dert jeden Prozess in Prozesskategorien,die den drei Geschaftsmodellen Lagerfer-tigung (Make-to-Stock), Auftragsfertigung

(Make-to-Order) und konstruktionsorien-tierte Einzelfertigung (Engineer-to-Order)entsprechen. Die dritte Ebene definiert furjede Prozesskategorie die erforderlichenProzesselemente. Dabei handelt es sich umkomplexe Aufgabenbundel, die in Formvon tabellarischen Aufstellungen einheit-lich definiert werden.

Bild 6 zeigt im oberen Teil die Spezifikati-on des Prozesselementes „S1.1: ScheduleProduct Deliveries“, welches zur Prozess-kategorie „S1: Source Stocked Products“


Bild 6 Darstellung von Prozesselementen der Ablauflogik einer Prozesskategorie aufder dritten Ebene des SCOR-Modells [SCC01a]

Process Element: Schedule ProductDeliveries Process Element Number: S1.1Process Element DefinitonScheduling and managing the execution of the individual deliveries of products against an existingcontract or purchase order. The requirements for product release are determined based on thedetailed sourcing plan or other types of product pull signals.

Performance Attributes Metric

Asset

Reliability

Cost

Flexibility and Responsiveness

Raw Material or product Days of Supply

% Defective, Defective parts per million (dppm) Completion tobudget and scope of service description

Product management and Planing Costs as a % of ProductAcquisition Costs

Total Source Lead Time % of EDI Transactions

Best practice Features

VMI agreements allow suppliers tomanage (replenish) inventory

Utilized EDI transaction to reduce cycletime and costs

Supplier managed inventories with scheduling interfaces toexternal suppliers systems

EDI interface for 830, 850, 856 & 862 transactions

Consignment agreements are usedto reduce assets and cycle time whileincreasing the availability of critical items

Mechanical (Kanban) pull signals areused to notify suppliers of the needto deliver product

Consignment inventory management

Electronic Kanban support

Advanced ship notices allow for rightsynchronization between source and makeprocesses

Banket order support with scheduling interfaces to externalsupplier systems

Inputs Plan DeliverMakeSourceSourcing Plans P2.4Source Execution Data ES.2

Logistic Selection ES.6Production Schedule M1.1, M2.1, M3.2Replenishment Signals D1.3M1.2, M2.2, M3.3Outputs Plan DeliverMakeSourceProcurement Signal (Supplier)Sourced Product on Order P2.2 ES.9

Scheduled receipts M1.1, M2.1, M3.2

(P2.4) Sourcing Plans(ES.2) Source Execution Data(M1.1, M2.1, M3.2) Production Schedule(M1.2, M2.2, M3.3, D1.3) ReplenishmentSignals

(Supplier) Sourced Products

Receipt Verification(ES.1, ES.2)

Receipt Verification(ES.1, ES.2, ES.6, ES.8)

Procurement Signal (Supplier)Sourced Product on Order (P2.2), (ES.9)Scheduled Receipts (M1.1, M2.1, M3.2, D1.8)


gehort. Fur jedes Prozesselement sind derElementname, eine textuelle Beschreibung,einige Kennzahlen zur Leistungsmessung,empfohlenen Praktiken (Best Practices)und Moglichkeiten der informationstech-nischen Unterstutzung aufgefuhrt. DieSchnittstellen der Prozesselemente werdendurch In- und Outputs mit der Angabevon Quellen und Senken spezifiziert. Zu-satzlich wird die Ablauflogik einer Prozess-kategorie mittels einer einfachen grafischenDarstellung, welche auch die Beziehungenzu Prozesselementen anderer Prozesskate-gorien enthalt, dargestellt. Bild 6 zeigt diesim unteren Teil fur die Prozesskategorie„S1: Source Stocked Products“. Das durchdie Tabelle im oberen Teil spezifizierteProzesselement (S1.1) ist grau hinterlegt.Auf die Erarbeitung konkreter Prozess-modelle auf der vierten Ebene, die die ein-zelnen Prozesselemente der dritten Ebenedetaillieren wurden, wurde beim SCOR-Modell verzichtet, da jede konkrete Sup-ply-Chain den Anforderungen der Branchebzw. des Einzelfalls gerecht werden muss.

Konkrete Prozessmodelle, die logisch dervierten Ebene des SCOR-Modells zuzu-ordnen sind, liefert beispielsweise Rosetta-Net. RosettaNet ist ein unabhangiges Non-Profit-Konsortium, welches u. a. Standardsfur die Abstimmung der Partner in kon-kreten Supply-Chains des elektronischenHandels mit Elektronikkomponenten undInformationstechnologie – also fur einespezielle Branche – entwickelt. RosettaNetwird getragen von großen IT- und Logis-tikunternehmen [WeHB01, 129 f.; Fran01,289]. Das Vorgehen zur Entwicklung derStandards basiert auf einer Analyse deroperativen Prozesse und deren �berfuh-rung in Sollprozesse, fur die im Konsorti-um ein Konsens besteht. RosettaNet defi-niert die Sollprozesse in Form sog. PIPBusiness Process Flow Diagrams, einerUML-ahnlichen Notation, die in [Rose00,6–10] eingefuhrt wird. Bild 7 zeigt einenBeispielprozess. Ein wesentliches Kriteri-um bei der Entwicklung der Sollprozesseist das wirtschaftliche Verbesserungspoten-zial, welches durch die Einfuhrung vonsog. RosettaNet Partner Interface Processes(PIPs) erreicht werden kann. Die Imple-mentierungskomponenten fur den elektro-nischen Datenaustausch werden formalspezifiziert [Rose00, 2 f.; WeHB01, 128 f.].

Es existiert derzeit eine Fulle weiterer Be-muhungen, Terminologien fur die Kopp-lung von Informationssystemen zu stan-dardisieren. Einen aktuellen �berblick und

eine Einschatzung der Relevanz prasentiert[Fran01] (siehe auch [WeHB01, 75 ff.]).Beispielhaft sollen hier noch die InitiativenOAGIS und ebXML skizziert werden.

Die Open Application Group IntegrationSpecification (OAGIS) [Conn99] stellt ei-nen domanenspezifischen Standard zurKopplung von Informationssystemen be-reit. OAGIS ist darauf gerichtet, die Inte-gration von Anwendungen innerhalb einesUnternehmens und uber Unternehmens-grenzen hinweg zu unterstutzen [Fran01,290]. OAGIS-Nachrichtentypen, sog.Business Object Documents (BOD), habenneben einem Teil zur Spezifikation der Artund Struktur der Information einen alsBusiness Service Request (BSR) bezeichne-ten Aktionsteil, der beschreibt, wie derEmpfanger mit der Information umzuge-hen hat [LiKS99, 15 f.]. Beispielsweise istfur eine Anwendung, die als Nachricht denBSR Update Credit erhalt, spezifiziert,dass der Kreditstatus eines Kunden zu ak-tualisieren ist. Ein Anfrage, die den BSRGet Credit enthalt, ist mit einer Kredit-information (Show Credit) zu beantwor-ten.

ebXML ist eine gemeinsame Initiative vonOASIS (Organization for the Advance-ment of Structured Information Standards)und UN/CEFACT (United Nations Cen-tre for Trade Facilitation and ElectronicBusiness) [WeHB01]. Ziel von ebXML istdie Schaffung einer terminologischen undstrukturellen Plattform fur den globalenE-Commerce. Dabei sollen kleine und mit-telstandische Unternehmen und die DritteWelt besonders berucksichtigt werden[Fran01, 290]. Es ist davon auszugehen,dass sich dezentrale und damit uberschau-barere Standards wie z. B. SCOR von SCCund RosettaNet schneller und einfacherentwickeln und warten lassen als globaleStandardisierungsbemuhungen wie z. B.ebXML. �hnliche Erfahrungen wurdenfruher im Rahmen von UN/EDIFACTmit entsprechenden Branchenstandards ge-macht.

3 Methodische Ansatze zurIntegration vonInformationssystemen

Die bisherigen Ausfuhrungen haben deut-lich gemacht, dass es fur alle Entwicklungs-phasen Techniken und Standards gibt, die

einzelne Aufgaben der Integration von In-formationssystemen unterstutzen. Ande-rerseits wurde auch deutlich, dass eine all-gemein akzeptierte Methode zurInformationssystemintegration derzeitnicht verfugbar ist. Dennoch mussen Inte-grationsvorhaben methodisch sinnvoll ge-staltet werden. Die folgenden �berlegun-gen sollen einen ersten Schritt zurEntwicklung einer Integrationsmethodeaufzuzeigen.

Die Entwicklung einer einheitlichen Ter-minologie ist zwingende Voraussetzungder Integration von Geschaftsprozessenund Informationssystemen. Die Bedeutungdieser terminologischen Integration liegt inder Notwendigkeit, zusatzlich zur Kor-rektheit der Strukturen (mittels Grammati-ken und Datentypen) auch die Korrektheitder Inhalte (mittels der Fachterminologie)prufen zu mussen [Ortn00, 11]. Referenz-modelle wie RosettaNet und SCOR kon-nen dabei als Vorlagen zur Vereinheitli-chung von Terminologien in konkretenProjekten herabgezogen werden. Eine voll-standige Anwendbarkeit ohne Anpassun-gen in konkreten Projekten oder gar eineautomatisierte �bernahme der standardi-sierten Vorschlage werden hier skeptischbeurteilt. Aber der Ruckgriff auf derartigeVorlagen reduziert den Aufwand der ter-minologischen Integration erheblich.

Um die Rolle von Referenzmodellen undTerminologien als Vorlagen bei der Inte-gration von Informationssystemen zu ver-deutlichen, ist die Betrachtung von Model-lierungs- bzw. Abstraktionsebenenhilfreich. Fur die Integration von Informa-tionssystemen sind drei Abstraktionsebe-nen relevant: Die Instanzenebene betrach-tet konkrete Vorfalle im Rahmen derDurchfuhrung von Geschaftsprozessen(z. B. Bestellung 4711 von A an B). DieTypebene spezifiziert, wie der Bestell-prozess generell durchzufuhren ist (z. B.als Prozess- und Datenmodell). Die Meta-ebene spezifiziert die Schemas der Elemen-te der Typebene, legt also beispielsweisedie Struktur von Dokumenten, die Prozes-se und Daten (etwa bei der Gestaltung desBestellprozesses) spezifizieren, fest[Holt99, 11–18]. Geschieht dies in Formvon Informationsmodellen, so spricht manmit Bezug auf die Sachverhalte der Instan-zenebene von Metamodellen. WerdenDokumente der Typebene (beispielsweiseProzess- und Datenmodelle, die einen Be-stellprozess spezifizieren) unter Verwen-dung von Informationssystemen erstellt


48 Roland Holten

und verwaltet, so spricht man mit Bezugauf die durch diese Dokumente dargestell-ten Sachverhalte (beispielsweise konkreteBestellprozesse der Instanzenebene) vonMeta-Informationssystemen (MetaIS). Me-taIS erhalten somit im Rahmen der Integra-tion von Geschaftsprozessen und Informa-tionssystemen Bedeutung als generelleArchitekturkomponenten. Dies zeigt sichbeispielsweise an der Konzeption von Mi-crosofts BizTalk (Abschnitt 2.2). Dort wirdzur Erzeugung (bzw. zur Entschlusselung)von Nachrichten auf ein zentrales Reposi-tory, das fur den entsprechenden Ge-schaftsvorfall die Terminologie bereitstellt,zuruckgegriffen (Bild 5).

MetaIS (oder Repositories) werden seit ei-niger Zeit im Rahmen des Metadatenmana-gements behandelt [BBC+99; NiJa99; Ra-Be01]. Sie sind fur die terminologischeIntegration von besonderer Bedeutung, dasie entsprechende Terminologien aufneh-men und verwalten konnen [RaBe01, 335;NiJa99, 136 ff.; Ortn00, 9; Ortn99]. AmBeispiel des Schema-Matchings wurde dieBedeutung einer zentralen und damit denzu integrierenden Anwendungen logischubergeordneten Bibliothek von Bezeich-nern verdeutlicht (Abschnitt 2.2). DieselbeBedeutung ist der Bereitstellung einer zen-tralen Bibliothek von Fachbegriffen bei-zumessen, wie aus der Konzeption desBizTalk-Szenarios ersichtlich wurde. Inbeiden Fallen kommt dem Schema einesMetaIS die Rolle der Spezifikation einerDokumentationsstruktur fur die Begriffeder Fachterminologien zu [Ortn00, 11].Dieses Rollenverstandnis geht auf dieSprachstufentheorie der Logik zuruck.Dort werden mehrere Sprachebenen unter-schieden: Eine Sprache, die Gegenstand ei-ner Untersuchung ist, wird als Objektspra-che bezeichnet, eine Sprache, unter derenVerwendung die Untersuchung durch-gefuhrt wird, heißt Metasprache [Holt01,300]. Eine Fachterminologie, die bei derIntegration von Informationssystemen (aufTypebene) herangezogen wird, ist folglichals Objektsprache zu verstehen. DieseFachterminologie wird mittels des Schemasdes MetaIS strukturiert. Daher ist dasSchema des MetaIS in diesem Fall als dieMetasprache zu verstehen. Die Instanzen,die in MetaIS verwaltet werden (beispiels-weise Fachterminologien, Prozess- undDatenmodelle), beziehen sich auf Typenvon Information [Ortn99, 13].

Aus methodischer Sicht sind die Entwick-lungsphasen der Integration von Informa-

tionssystemen mit den soeben eingefuhrtenAbstraktionsebenen zu kombinieren. DieseLogik fuhrt zu dem in Bild 8 gezeigtenRahmenmodell zur Integration von Infor-mationssystemen. Da es jede der drei Abs-traktionsebenen (Instanz, Typ, Meta) injeder der drei Entwicklungsphasen (Fach-konzeption, DV-Konzeption und Imple-mentierung) gibt, fuhrt die Kombinationder Ebenen mit den Phasen zu einem Rah-menmodell mit neun Komponenten. DieEntwicklung von Informationssystemenvollzieht sich dabei auf den Ebenen Typund Instanz, Meta-Informationssystemebetreffen die Ebenen Meta und Typ.

Das Rahmenmodell dient der Systematisie-rung von Entwicklungsaufgaben und Do-kumenten bei der Integration von Informa-tionssystemen. Es folgt den Ansatzen zurStrukturierung von Entwicklungsaufgabenim Bereich des Data Warehousing, die in[JJQV99, JLVV00] und [Holt00; Holt03]vorgestellt werden, und ist wie folgt zu in-terpretieren:

Phase der Fachkonzeption

& Instanzenebene: Die Durchfuhrung ei-nes konkreten Bestellprozesses als Ge-schaftsvorfall (mit der Nr. 4711) ist derInstanzenebene zuzurechnen.


Da ta DictionariesReposit oriesModellierungs werk-zeug e

Schem a-MatchingEntwicklungs werk-zeug e

zumSC OR -B es tellprozes svon Anwendung A beiAnwendung B

derAnwendungen A u. B

für R PC svon

Anwendungssyst emen

Best ellungin SO AP

gemäß vorgegebe nemDatentyp (z . B . S OAP)ohne We rte

inSO AP Nr. 4711 von Aan B

Bestellung von Aan B

Info

rmat

ion

ssys

tem M

eta

-Info

rmat

ion

ssys

temModellierungstechn iken

Fa chterminologien

Bild 7 PIP Business-Process-Flow-Diagramm fur den Prozess Request Price and Avai-lability (entnommen aus [Rose01, 3])

<<RequestResponseActivity>>Request Price and Availability

START

[SUCCESS]

END

[FAIL]

FAILED

<<SecureFlow>>Price and Availability Request

<<SecureFlow>>Price and Availability Request

Process Price and AvailabilityRequest

:Customer :Product Supplier

Bild 8 Rahmenmodell zur Integration von Informationssystemen mit Beispielen aus ei-nem Bestellprozess


& Typebene: Die Integration von Informa-tionssystemen basiert auf der fachkon-zeptionellen Spezifikation von Prozes-sen durch Prozessmodelle auf derTypebene. Dabei sind Terminologienund Aktivitaten, die auf den Austauschvon Nachrichten zu folgen haben, zuspezifizieren. Dies kann beispielsweisein Anlehnung an ein Referenzmodellwie dem SCOR-Modell erfolgen und istfur jedes Projekt durchzufuhren.

& Metaebene: Werden Modelle von Mo-dellierungstechniken und Terminolo-gien, die auf der Typebene verwendetwerden, erstellt, sind dies mit Bezug aufdie Sachverhalte der Instanzenebenefachkonzeptionelle Metamodelle. Diesesind der Metaebene zuzuordnen.

Phase der DV-Konzeption

& Instanzenebene: Wird im Rahmen derDurchfuhrung eines konkreten Ge-schaftsprozesses Speicherplatz auf einemRechner zur Aufnahme eines Bestell-dokumentes eines definierten Datentyps(z. B. ein SOAP-Dokument) reserviert,ist dies der Instanzenebene zuzurech-nen.

& Typebene: Im Rahmen der Spezifikationder IS-Architektur fur die Kopplungvon Anwendungssystemen sind tech-nische Parameter der Geschaftsprozessezu konkretisieren. Beispielsweise ist aufder Typebene festzulegen, mit welchenURIs die sendenden und empfangendenAnwendungssysteme zu erreichen sind,wie die logischen Schemas der zu kop-pelnden Anwendungssysteme aufgebautsind, und welche Namen und Daten-typen die Parameter von RFCs haben.

& Metaebene: Auf der Metaebene sind dielogischen Schemas von Data Dictiona-ries, Repositories und Modellierungs-werkzeugen, die die Information derTypeben aufnehmen, zu spezifizieren.

Phase der Implementierung

& Instanzenebene: Auf Instanzenebenewird eine konkrete Bestellung (mit derNr. 4711), die gemaß eines konkretenDatentyps strukturiert ist, als Doku-ment (beispielsweise als SOAP-Doku-ment) von der Anwendung A an die An-wendung B geschickt.

& Typebene: Im Rahmen der Implemen-tierung ist auf Typeben beispielsweisefestzulegen, wie eine SOAP-Bestellungzur Integration von Anwendungssyste-men strukturiert ist.

& Metaebene: Sind im Rahmen des Sche-ma-Matchings Schemas verschiedenerAnwendungssysteme zu integrieren,sind Schnittstellen erforderlich. Diesekonnen entweder manuell kodiert oderdurch Konvertierungsprogramme teil-weise erzeugt werden. Die Algorithmen,die beispielsweise beim Schema-Mat-ching unter Nutzung des PrototypenSIMPLEX (Abschnitt 2.2) ablaufen,sind der Metaebene zuzuordnen. Algo-rithmen zur Generierung von Data-Mart-Schemas und Report-Queries wer-den in [Holt03] vorgestellt. DieseAlgorithmen der Metaebene nutzen beider Generierung von Schemas die Infor-mation der Data-Dictionaries und Re-positories (Typebene in der Phase derDV-Konzeption) als Parameter.

4 Zusammenfassung

Derzeit diskutierte Standards und Tech-niken, die fur die Integration von Infor-mationssystemen von Bedeutung sind,wurden anhand der bekannten Entwick-lungsphasen Fachkonzeption, DV-Kon-zeption und Implementierung systemati-siert. Fachkonzeptionell werden derzeitStandardisierungsbemuhungen von Fach-terminologien und Geschaftsprozessen furdie zwischenbetriebliche Integration vonGeschaftsprozessen intensiv diskutiert.Beispielhaft wurden die Initiativen Roset-taNet und Supply Chain Council ausfuhr-licher vorgestellt. Aus Sicht der DV-Kon-zeption ist das Konzept EnterpriseApplication Integration von vorrangigerBedeutung. Intention und EAI-Architek-turen wurden vorgestellt. Die Implemen-tierungsphase ist aktuell gepragt durch dieDiskussion der Moglichkeiten und Gren-zen von XML. In diesem Zusammenhangwurden die grundsatzlichen Ideen, XML-Schema, das Protokoll SOAP und Ansatzedes Schema-Matchings erlautert.

Die Ausfuhrungen machen deutlich, dassStandards und Techniken fur jede Entwick-lungsphase vorliegen, dass eine allgemeinakzeptierteMethode der Integration von In-formationssystemen jedoch noch weit ent-fernt ist. In einem Rahmenmodell zur Inte-gration von Informationssystemen werdendie Entwicklungsphasen und die Abstrakti-onsebenen, Instanz, Typ und Meta zusam-mengefuhrt, um die Abhangigkeiten vonEntwicklungsentscheidungen und Entwick-lungsdokumenten zu verdeutlichen.

Literatur

[BaBo01] Baldi, Stefan; Borgmann, Hans P.:Ownership Structures of Electronic B2B Mar-ketplaces – A Multi-perspective Analysis. In[BuHR01, 589–603].

[BeJa97] Bechtel, Christian; Jayaram, Jayanth:Supply Chain Management: A Strategic Per-spective. In: The International Journal of Logis-tics Management 8 (1997) 1, S. 15–34.

[BBC+99] Bernstein, Philip A.; Bergstraesser, Tho-mas; Carlson, Jason; Pal, Shankar; Sanders, Paul;Shutt, David: Microsoft Repository Version 2and the Open Information Model. In: Informati-on Systems 24 (1999) 2, S. 71–98.

[BDKK02] Becker, Jorg; Delfmann, Patrick;Knackstedt, Ralf, Kuropka, Dominik: Konfigu-rative Referenzmodellierung. In: Jorg, Becker,Ralf Knackstedt (Hrsg.): Wissensmanagementmit Referenzmodellen. Konzepte fur die An-wendungssystem- und Organisationsgestaltung.Physica-Verlag, Heidelberg 2002, S. 25–144.

[BEK+00] Box, Don; Ehnebuske, David; Kaki-vaya, Gopal; Layman, Andrew; Mendelsohn,Noah; Nielsen, Henrik Frystyk; Thatte, Satish;Winer, Dave: Simple Object Access Protocol(SOAP) 1.1. W3C Note 08 May 2000. W3C2000, http://www.w3.org/TR/SOAP/, Abrufam 2002-03-27.

[BeMG02] Becker, Jorg, zur Muehlen, Michael:Workflow Application Architectures: Classifica-tion and Characteristics of Workflow-based In-formation Systems. In: [Fisc02, 39–50].

[BFIM, 98] Berners-Lee, T.; Fielding, R.; Irvine,U.C.; Masinter, L.: Uniform Resource Identifiers(URI): Generic Syntax. Request for Comments:2396, Network Working Group, 1998.http://www.ietf.org/rfc/rfc2396.txt, Abruf am2002-10-11.

[BiMa01] Biron, Paul V.; Malhotra, Ashok: XMLSchema Part 2: Datatypes. W3C Recommendati-on 02, May 2001. http://www.w3.org/TR/xmlschema-2/, Abruf am 2002-10-12.

[BizT02] Microsoft BizTalk Server 2002 EnterpriseEdition. Product Documentation:http://www.microsoft.com/biztalk/techinfo/productdoc/2002/BTdownload.asp, Abruf am2002-03-26.

[BPSM00] Bray, Tim; Paoli, Jean; Sperberg-McQueem, C. M.; Maler, Eve (Ed.): ExtensibleMarkup Language (XML) 1.0 (Second Edition).W3C Recommendation 6 October 2000. W3C2000, http://www.w3.org/TR/REC-xml, Abrufam 2002-03-27.

[BrHL99] Bray, Tim; Hollander, Dave; Layman,Andrew: Namespaces in XML. World WideWeb Consortium 14-January-1999.http://www.w3.org/TR/REC-xml-names/, Ab-ruf am 2002-10-14.

[BuCP01] Buhl, Lothar; Christ, Jorg; Pape Ulrich:Marktstudie: Softwaresysteme fur EnterpriseApplication Integration. In: Dangelmaier,Wilhelm Bohner, Markus (Hrsg.): ALB-HNI--Verlagsschriftenreihe, Bd. 7, Fraunhofer-An-wendungszentrum fur Logistikorientierte Be-triebswirtschaft, Paderborn 2001.

[BuHR01] Buhl, Hans Ulrich; Huther, Andreas;Reitwiesner, Bernd (Hrsg.): Information AgeEconomy. 5. Internationale Tagung Wirtschafts-informatik 2001. Physica-Verlag, Heidelberg2001.


50 Roland Holten

[BuLW01] Buxmann, Peter, Ladner, Frank; Weit-zel, Tim: Anwendung der Extensible MarkupLanguage (XML): Konzeption und Implemen-tierung einer WebEDI-Losung. In: Wirtschafts-informatik 43 (2001) 3, S. 257–267.

[BuMW01] Buxmann, Peter; Martin, Luis; Wust-ner, Erik: SIMPLEX – Eine prototypische Sup-ply-Chain-Management-Losung fur den Aus-tausch, die Konvertierung und die Integrationvon XML-Dokumenten. In: [BuHR01,441–453].

[BuMW02] Buxmann, Peter; Martin, Luis; Wust-ner, Erik: XML-based Supply Chain Manage-ment – as SIMPLEX as it is. Erscheint in: Pro-ceedings of the 35rd Hawaii InternationalConference on System Sciences (HICSS 2002).

[Bung77] Bunge, M. A.: Ontology I: The Furnitureof the World. Treatise on Basic Philosophy. D.Reidel Publishing Company, Dordrecht, Boston1977.

[Chri98] Christopher, Martin: Logistics and SupplyChain Management. Strategies for ReducingCost and Improving Service. 2. Aufl., FinancialTimes Professional, London 1998.

[Clar99] Clark, James (Ed.): XSL Transformations(XSLT) Version 1.0. W3C Recommendation 16November 1999. W3C 1999http://www.w3.org/TR/xslt,Abruf am 2002-03-27.

[Conn99] Connelly, David : Best practices in busi-ness software integration and the Open Applica-tions Group. In: Wirtschaftsinformatik 41 (1999)6, S. 497–505.

[DiEs01] Dietzsch, Andreas; Esswein, Werner: Gibtes eine „Softwarekomponenten Industrie“? Er-gebnisse einer empirischen Untersuchung. In:[BuHR01, 697–710].

[Fall01] Fallside, Davide C.: XML Schema Part 0:Primer. W3C Recommendation, 2 May 2001.W3C 2001, http://www.w3.org/TR/xmlschema-0/, Abruf am 2002-03-29.

[Fisc02] Fischer, Layna (Hrsg.): Workflow Hand-book 2002. Future Strategies, Book Division,Lighthouse Point, Florida 2002.

[FlTu00] Flatscher, Rony G.; Turowski, Klaus(Hrsg.): Tagungsband. 2. Workshop komponen-tenorientierte betriebliche Anwendungssysteme(WKBA 2). Wirtschaftsuniversitat Wien, 24.–25.Februar 2000.

[Fran01] Frank, Ulrich: Standardisierungsvorhabenzur Unterstutzung des elektronischen Handels:�berblick uber anwendungsnahe Ansatze. In:Wirtschaftsinformatik 43 (2001) 3, S. 283–293.

[GaNW99] Gamper, Johann; Nejdel, Wolfgang;Wolpers, Martin: Combining Ontologies andTerminologies in Information Systems.http://www.kbs.uni-hannover.de/Arbeiten/Publikationen/1999/tke99/,Abruf am 2002-10-15.

[Goet00] Goetschalckx, Marc: Strategic NetworkPlanning. In: [StKi00, 79–95].

[GrRo00] Green, P., Rosemann, M.: IntegratedProcess Modeling. An Ontological Evaluation.Information Systems, Vol. 25, No. 2, 2000,S. 73–87.

[Holl02] Hollingsworth, David: An XML basedArchitecture for Collaborative Process Manage-ment. In: [Fisc02, 95–116].

[Holt99] Holten, Roland: Entwicklung von Fuh-rungsinformationssystemen. Ein methodenori-entierter Ansatz. Gabler, Wiesbaden 1999.

[Holt00] Holten, Roland: Framework and Methodfor Information Warehouse Development Pro-cesses. In: R. Jung, R. Winter (Hrsg.): Data Wa-rehousing 2000 – Methoden, Anwendungen,Strategien. Physica-Verlag, Heidelberg 2000, S.135–163.

[Holt01] Holten, Roland: Metamodell. In: Mertenset al. (Hrsg.): Lexikon der Wirtschaftsinforma-tik, 4. Aufl., Springer, Berlin et al. 2001, S. 300 f.

[Holt03] Holten, Roland: Specification of Manage-ment Views in Information Warehouse Projects.Angenommen zur Veroffentlichung in: Informa-tion Systems.

[ISO94] International Organization for Standardi-zation: OSI Basic Reference Model – The BasicModel. ISO/IEC 7498-1 : 1994. Genf 1994.

[JJQV99] Jarke, M; Jeusfeld, M. A.; Quix, C.; Vas-siliadis, P.: Architecture and Quality in Data Wa-rehouses, An extended Repository Approach.In: Information Systems 24 (1999) 3, S. 229–253.

[JLVV00] Jarke, M.; Lenzerini, M; Vassiliou, Y.;Vassiliadis, P.: Fundamentals of Data Warehou-ses, Berlin et al. 2000.

[KaBl00] Kaluza, Bernd; Blecker, Thorsten: SupplyChain Management und Unternehmung ohneGrenzen – Zur Verknupfung zweier interorga-nisationaler Konzepte. In: [Wilde00, 117–152].

[Kopp01] Kopper, Franz: Supply Chain Manage-ment benotigt robuste Integrationslosungen. In:Information, Management & Consulting 16(2001) 2, S. 92–95.

[LiKS99] Ließmann, Harald; Kaufmann, Thomas;Schmitzer, Benno: Bussysteme als Schlussel zurbetriebswirtschaftlich-semantischen Kopplungvon Anwendungssystemen. In: Wirtschaftsinfor-matik 41 (1999) 1, S. 12–19.

[Mari02] Marin, Mike: Business Process Technolo-gy: From EAI and Workflow to BPM. In:[Fisc02, 133–145].

[Mert et al.01] Mertens, Peter (Hrsg.): Lexikon derWirtschaftsinformatik. 4. Aufl. Springer-Verlag,Berlin Heidelberg 2001.

[Niss01] Nissen, Volker: Fourth-Party-Logistik-marktplatze als Form der Integration von elek-tronischen Marktplatzen und Supply Chain Ma-nagement. In: Wirtschaftsinformatik 43 (2001) 6,S. 599–608.

[NiJa99] Nissen, Hans W.; Jarke, Matthias: Reposi-tory Support for Multi-Perspective Require-ments Engineering. In: Information Systems 24(1999) 2, S. 131–158.

[Ortn99] Ortner, Erich: Repository Systems. Auf-bau und Betrieb eines Entwicklungsrepositori-ums. In: Informatik Spektrum 22 (2002) 4,S.235–251; 5, S. 351–363.

[Ortn00] Ortner, Erich: Terminologiebasierte,komponentenorientierte Entwicklung von An-wendungssystemen. In [FlTu00, 1–20].

[Ortn02] Ortner, Erich: Sprachingenieurwesen.Empfehlungen zur inhaltlichen Weiterentwick-lung der (Wirtschafts-)Informatik. In: Informa-tik Spektrum 25 (2002) 1, S. 39–51.

[PoLi99] Polzin, Dietmar W.; Lindemann, MarkusA.: Evolution elektronischer Markte in Guterver-kehr und Logistik. In: Wirtschaftsinformatik 41(1999) 6, S. 526–537.

[RaBe01] Rahm, Erhard; Bernstein, Philip A: Asurvey of approaches to automatic schema mat-ching. In: The VLDB Journal 10 (2001),S. 334–350.

[RaTu01] Rautenstrauch Claus, Turowski, Klaus:Common Business Component Model (COB-

COM): Generelles Modell komponentenbasier-ter Anwendungssysteme. In: [BuHR01,681–695].

[RoGr99] Rosemann, M., Green, P.: Enhancing theProcess of Ontological Analysis – The “Who ca-res” Dimension”. Proceedings of the Informati-on Systems Foundations Workshop – Ontology,Semiotics and Practice, Sydney, NSW, Australia1999.

[Rose00] RosettaNet: User’s Guide. Understandinga PIP Blueprint. Release 1.3, 4 January 2000.http://www.rosettanet.org/usersguides/, Abrufam 2002-03-25.

[Rose01] RosettaNet: PIP TM Specification. Cluster3: Order Management. Segment A: Quote & Or-der Entry. PIP3A2: Request Price and Availabili-ty. Release 02.00.00A. 11 June 2001.http://www.rosettanet.org/standards/pips/cluster3, Abruf am 2002-03-25.

[Ross98] Ross, David F.: Competing Through Sup-ply Chain Management. Creating Market-Win-ning Strategies Through Supply Chain Partner-ships. Kluwer Academic Publishers, Boston etal. 1998.

[SCC01a] Supply-Chain Council: Supply-ChainOperations Reference-Model. Version 5.0. Pitts-burgh, PA 2001.

[SCC01b] Supply-Chain Council: Supply-ChainOperations Reference-Model. Overview ofSCORVersion 5.0. Pittsburgh, PA 2001.

[Sche98] Scheer, August-Wilhelm: Business ProcessEngineering. 3rd ed., Springer, Berlin 1998.

[Sche97a] Scheer, August-Wilhelm: Wirtschafts-informatik. Referenzmodelle fur industrielle Ge-schaftsprozesse. 5. Aufl. Springer, Berlin 1997.

[Sche97b] Scheckenbach, Rainer: Semantische Ge-schaftsprozeßintegration. Deutscher Univer-sitats-Verlag, Gabler, Wiesbaden 1997.

[Schi01] Schinzer, Heiko D.: Elektronischer Markt.In: [Mert et al.01, 175 f.].

[Schu99] Schutte, Reinhard: Grundsatze ordnungs-maßiger Referenzmodellierung. Konstruktionkonfigurations- und AnpassungsorientierterModelle. Gabler, Wiesbaden 1998.

[Seib01] Seibt Dietrich: Anwendungssystem. In:[Mert et al.01, 47 f.].

[Seif96] Seiffert, Helmut: Einfuhrung in die Wis-senschaftstheorie 1. 12. Aufl., Verlag C. H. Beck,Munchen 1996.

[Stad00] Stadtler, Hartmut: Supply Chain Manage-ment. An Overview. In: [StKi00, 7–28].

[Step01] Stephens, Scott: The Supply Chain Coun-cil and the Supply Chain Operations ReferenceModel. In: Supply Chain Management 1 (2001)1, S. 9–13.

[Ston01] Stonebraker, Michael: Too Much Middle-ware. In: Ninth International Workshop onHigh Performance Transaction Systems (HPTS),Pacific Grove, California, October 14–17, 2001.http://www.research.microsoft.com/~jamesrh/hpts2001/submissions/, Abruf am 2002-03-26.

[StHa97] Stahlknecht, Peter; Hasenkamp, Ulrich:Einfuhrung in die Wirtschaftsinformatik. 8.Aufl. Springer, Berlin et al. 1997.

[StKi00] Stadtler, Hartmut; Kilger, Christoph(Hrsg.): Supply Chain Management and Advan-ced Planning. Concepts, Models, Software andCase Studies. Springer, Berlin et al. 2000.

[TBMM01] Thompson, Henry S.; Beech, David;Maloney, Murray; Mendelsohn, Noah: XMLSchema Part 1: Structures. W3C Recommendati-



on, 2 May 2001. http://www.w3.org/TR/xmlschema-1/, Abruf am 2002-10-12.

[Teub99] Teubner, Rolf Alexander: Organisations-und Informationssystemgestaltung. Theoretischegrundlagen und integrierte Methoden. DeutscherUniversitatsverlag, Wiesbaden 1999.

[Turo01] Turowski, Klaus: Spezifikation und Stan-dardisierung von Fachkomponenten. In: Wirt-schaftsinformatik 43 (2001) 3, S. 269–281.

[WaWe89] Wand, Y., Weber, R.: An ontologicalevaluation of systems analysis and design me-thods. In: E. Falkenberg, & P. Lindgreen (Eds.),Information Systems Concepts: An In-depthAnalysis, North-Holland, 1989, S. 79–107.

[WaWe90a] Wand, Y., Weber, R.: An OntologicalModel of an Information System. IEEE Trans-actions on Software Engineering, Vol. 16, No.11, 1990, S. 1282–1292.

[WaWe90b] Wand, Y., Weber, R.: Mario Bunge’sOntology as a formal foundation for informati-on systems concepts. In: P. Weingartner,G. Dorn (Eds.), Studies on Mario Bunge’s Trea-tise. Atlanta: Rodopi, 1990, S. 123–149.

[WaWe93a] Wand, Y., Weber, R.: On the ontologi-cal expressiveness of information systems ana-lysis and design grammars. Journal of Informati-on Systems, 3 (1993), No. 4, S. 217–237.

[WaWe93b] Wand, Y., Weber, R.: On the DeepStructure of Information Systems. InformationSystems Journal, Vol. 5 (1993), No. 3, 203–223.

[WeHB01] Weitzel, Tim; Harder, Thomas; Bux-mann, Peter: Electronic Business und EDI mitXML. dpunkt.verlag, Heidelberg 2001.

[Wesk99] Weske, Mathias: Business-Objekte: Kon-zepte, Architekturen, Standards. In: Wirtschafts-informatik 41 (1999) 1, S. 4–11.

[Wilde00] Wildemann, Horst (Hrsg.): SupplyChain Management. TCW Transfer-Centrum-Verlag, Munchen 2000.

[WGHS01] Weske, Mathias; Goesmann, Thomas;Holten, Roland; Striemer, Rudiger: Analysing,Modelling and Improving Workflow Applicati-on Development Processes. In: Software ProcessImprovement And Practice (2001) 6, S. 35–46.

[W3C] o.A.: Uniform Resource Identifier (URI).Activity Stateent. W3C o.J., http://www.w3.org/Addressing/Activity#current, Abruf am2002-03-29.


Abstract

Integration of Information Systems

Standards and techniques relevant to information systems integration are arranged usingthe development phases conceptual specification, design specification and implementation.Core concepts like XML, SOAP, Schema Matching, EAI and the work of councils to developreference models for business integration are discussed. Methodical aspects of informationsystems integration are systematically organized by an integration framework.

Keywords: application integration, EAI, integration framework, component approach,meta information systems, RosettaNet, schema matching, SCOR model

52 Roland Holten