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

Größe: px
Ab Seite anzeigen:

Download "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: 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

Kopplungsarchitekturen zur überbetrieblichen Integration von Anwendungssystemen und ihre Realisierung mit SAP R/3

Kopplungsarchitekturen zur überbetrieblichen Integration von Anwendungssystemen und ihre Realisierung mit SAP R/3 Kopplungsarchitekturen zur überbetrieblichen Integration von Anwendungssystemen und ihre Realisierung mit SAP R/3 Martin Schissler, Stephan Mantel, Otto K. Ferstl, Elmar J. Sinz 1 1 Dipl.-Wirtsch.Inf.

Mehr

Integration und Interoperabilität. von Anwendungssystemen

Integration und Interoperabilität. von Anwendungssystemen Seite 1 Integration und Interoperabilität von Anwendungssystemen Prof. Dr. Otto K. Ferstl Universität Bamberg Nürnberg, Begriff betriebliches Informationssystem Seite 2 Abgrenzungskriterium: AT: Anwendungssysteme

Mehr

Standardisierte Integration und Datenmigration in heterogenen Systemlandschaften am Beispiel von Customer Relationship Management

Standardisierte Integration und Datenmigration in heterogenen Systemlandschaften am Beispiel von Customer Relationship Management Standardisierte Integration und Datenmigration in heterogenen Systemlandschaften am Beispiel von Customer Relationship Management Inauguraldissertation zur Erlangung des akademischen Grades eines Doktors

Mehr

Eine Entwicklungsmethodik für die überbetriebliche Integration von Anwendungssystemen

Eine Entwicklungsmethodik für die überbetriebliche Integration von Anwendungssystemen Eine Entwicklungsmethodik für die überbetriebliche Integration von Stephan Mantel, Universität Bamberg Sven Eckert, Universität Bamberg Martin Schissler, Universität Bamberg Claus Schäffner, Universität

Mehr

Client/Server-Systeme

Client/Server-Systeme Fachbereich Informatik Projektgruppe KOSI Kooperative Spiele im Internet Client/Server-Systeme Vortragender Jan-Ole Janssen 26. November 2000 Übersicht Teil 1 Das Client/Server-Konzept Teil 2 Client/Server-Architekturen

Mehr

Grundlagen der Wirtschaftsinformatik

Grundlagen der Wirtschaftsinformatik Grundlagen der Wirtschaftsinformatik von Univ.-Prof. Dr. Otto K. Ferstl Lehrstuhl für Wirtschaftsinformatik insbes. Industrielle Anwendungssysteme an der Otto-Friedrich-Universität Bamberg und Univ.-Prof.

Mehr

Java 2, Enterprise Edition Einführung und Überblick

Java 2, Enterprise Edition Einführung und Überblick Universität aiserslautern AG Datenbanken und Informationssysteme Seminar Datenbank-Aspekte des E-Commerce Java 2, Enterprise Edition Einführung und Überblick m_husema@informatik.uni-kl.de Vortragsinhalte

Mehr

EDI/XML Datentransaktionen über System- und Unternehmensgrenzen. Referent: Jan Freitag

EDI/XML Datentransaktionen über System- und Unternehmensgrenzen. Referent: Jan Freitag EDI/XML Datentransaktionen über System- und Unternehmensgrenzen Referent: Jan Freitag Warum EDI? Internet bedeutender Wirtschaftsfaktor Nur wenige Unternehmen steuern Geschäftsprozesse über das Internet

Mehr

EAI - Enterprise Application Integration

EAI - Enterprise Application Integration EAI - Enterprise Application Integration Jutta Mülle WS 2005/2006 EAI - Folie 1 Überblick und Begriffsbildung Zusammenfassung und Ausblick hinweise EAI - Folie 2 Conclusion EAI Enterprise Application Integration

Mehr

Vorgehensmodelle und webbasierte Technologien zur Integration von Systemen zur Unterstützung der Collaboration in Communities

Vorgehensmodelle und webbasierte Technologien zur Integration von Systemen zur Unterstützung der Collaboration in Communities Synopsis I Vorgehensmodelle und webbasierte Technologien zur Integration von Systemen zur Unterstützung der Collaboration in Communities Abschlussarbeit zur Erlangung des Grades Master of Science (MSc)

Mehr

SOA goes real Service-orientierte Architekturen erfolgreich planen und einführen

SOA goes real Service-orientierte Architekturen erfolgreich planen und einführen Daniel Liebhart SOA goes real Service-orientierte Architekturen erfolgreich planen und einführen ISBN-10: 3-446-41088-0 ISBN-13: 978-3-446-41088-6 Inhaltsverzeichnis Weitere Informationen oder Bestellungen

Mehr

Guten Tag! CampusSource. Die CSE Integration Platform. CampusSource Engine. Christof Pohl Softwareentwicklung Medienzentrum Universität Dortmund

Guten Tag! CampusSource. Die CSE Integration Platform. CampusSource Engine. Christof Pohl Softwareentwicklung Medienzentrum Universität Dortmund Engine Die CSE Integration Platform Guten Tag! Christof Pohl Softwareentwicklung Medienzentrum Universität Dortmund Integriertes Informationsmanagement mit der Engine - A2A vs. EBI Folie 2 Integration

Mehr

PROZESSE INTEGRIEREN leicht gemacht EFFIZIENTE PROZESSE

PROZESSE INTEGRIEREN leicht gemacht EFFIZIENTE PROZESSE PROZESSE INTEGRIEREN leicht gemacht DURCH TransConnect Geschäftsprozesse ableiten mit der Universal Worklist (UWL) Integrationsszenarien effektiver verwalten und transportieren Optimierte Personalverwaltung

Mehr

DISKUSSIONSBEITRÄGE DER FAKULTÄT FÜR BETRIEBSWIRTSCHAFTSLEHRE MERCATOR SCHOOL OF MANAGEMENT UNIVERSITÄT DUISBURG-ESSEN. Nr. 378

DISKUSSIONSBEITRÄGE DER FAKULTÄT FÜR BETRIEBSWIRTSCHAFTSLEHRE MERCATOR SCHOOL OF MANAGEMENT UNIVERSITÄT DUISBURG-ESSEN. Nr. 378 DISKUSSIONSBEITRÄGE DER FAKULTÄT FÜR BETRIEBSWIRTSCHAFTSLEHRE MERCATOR SCHOOL OF MANAGEMENT UNIVERSITÄT DUISBURG-ESSEN Nr. 378 Umsetzung ausgewählter Supply-Chain-Operations-Reference-Metriken durch das

Mehr

XML in der betrieblichen Praxis

XML in der betrieblichen Praxis Klaus Turowski, Klement J. Fellner (Hrsg.) XML in der betrieblichen Praxis Standards, Möglichkeiten, Praxisbeispiele Ги dpunkt.verlag Inhaltsverzeichnis 1 XML/EDI-Standardisierung: Ein Überblick 1 1.1

Mehr

Heterogene Informationssysteme

Heterogene Informationssysteme Arbeitsberichte des Instituts für Informatik Friedrich-Alexander-Universität Erlangen Nürnberg Band 35 Nummer 4 September 2002 Lutz Schlesinger, Wolfgang Hummer, Andreas Bauer (Hrsg.) Heterogene Informationssysteme

Mehr

E-Procurement besser elektronisch einkaufen

E-Procurement besser elektronisch einkaufen E-Procurement besser elektronisch einkaufen Starten Sie durch mit E-Business-Lösungen von Sonepar There is E-Business or out of business, so Larry Ellison, Gründer von Oracle. Und in der Tat hat E-Business

Mehr

Prozessorientierte Integration von Anwendungssystemen WS 2015 FWP-Fach für Bachelor Wirtschaftsinformatik

Prozessorientierte Integration von Anwendungssystemen WS 2015 FWP-Fach für Bachelor Wirtschaftsinformatik Prozessorientierte Integration von Anwendungssystemen WS 2015 FWP-Fach für Bachelor Wirtschaftsinformatik Prof. Dr. Torsten Zimmer, Hochschule München Motivation für Integrationsplattformen Nach einer

Mehr

Inhaltsverzeichnis VII. Vorwort zur vierten Auflage... V

Inhaltsverzeichnis VII. Vorwort zur vierten Auflage... V VII Vorwort zur vierten Auflage... V 1 Grundlagen der Wirtschaftsinformatik... 1 1.1 Womit beschäftigt sich die Wirtschaftsinformatik?... 2 1.2 Was macht ein Wirtschaftsinformatiker im Unternehmen?...

Mehr

Enterprise Portale & Enterprise Application Integration

Enterprise Portale & Enterprise Application Integration EP & - & Enterprise Application Integration Jörg Streibhardt Technische Universität Dresden EP & 21. Januar 2005 / Seminar Rechnernetze Gliederung Enterprise Application Integration EP & - EP & & Enterprise

Mehr

EAI. Integration. EAI Version 0.9 1

EAI. Integration. EAI Version 0.9 1 EAI Enterprise Application Integration EAI Version 0.9 1 Heterogene Informationssysteme KIS DRG Grouper Stand-alone Anwendung (Windows) PACS Client-Server Anwendung (Java, LINUX, Caché) QM-System Client-Server

Mehr

Hauptseminar Management von Softwaresystemen. Techniken der System-Integration EAI, Middleware, SOA, CORBA

Hauptseminar Management von Softwaresystemen. Techniken der System-Integration EAI, Middleware, SOA, CORBA Hauptseminar Management von Softwaresystemen Techniken der System-Integration EAI, Middleware, SOA, CORBA Betreuerin: Referent: Ulrike Hammerschall Alexey Krivoborodov Agenda Motivation Arten der Verteilung

Mehr

Inhaltsverzeichnis. Vorwort zur vierten Auflage... V

Inhaltsverzeichnis. Vorwort zur vierten Auflage... V Inhaltsverzeichnis Vorwort zur vierten Auflage... V 1 Grundlagen der Wirtschaftsinformatik... 1 1.1 Womit beschäftigt sich die Wirtschaftsinformatik?... 2 1.2 Was macht ein Wirtschaftsinformatiker im Unternehmen?...

Mehr

Business-Software. ERP, CRM, EAI, E-Business - eine Einführung. von. Carsten Dorrhauer und Andrej ZIender

Business-Software. ERP, CRM, EAI, E-Business - eine Einführung. von. Carsten Dorrhauer und Andrej ZIender Business-Software ERP, CRM, EAI, E-Business - eine Einführung von Carsten Dorrhauer und Andrej ZIender Tectum Verlag Marburg 2004 Inhaltsverzeichnis Vorwort 11 1 Einführung 13 1.1 Betriebswirtschaftliche

Mehr

Webservices. 1 Einführung 2 Verwendete Standards 3 Web Services mit Java 4 Zusammenfassung. Hauptseminar Internet Dienste

Webservices. 1 Einführung 2 Verwendete Standards 3 Web Services mit Java 4 Zusammenfassung. Hauptseminar Internet Dienste Hauptseminar Internet Dienste Sommersemester 2004 Boto Bako Webservices 1 Einführung 2 Verwendete Standards 3 Web Services mit Java 4 Zusammenfassung Was sind Web Services? Web Services sind angebotene

Mehr

Vortrag im Rahmen des Arbeitskreis i Informatik an der Schule. Prof. Dr. Stefan Sarstedt 04.02.2009

Vortrag im Rahmen des Arbeitskreis i Informatik an der Schule. Prof. Dr. Stefan Sarstedt 04.02.2009 Service-orientierte Architekturen (SOA) Ein Einblick Vortrag im Rahmen des Arbeitskreis i Informatik an der Schule Prof. Dr. Stefan Sarstedt 04.02.2009 Programmieren heute und damals 2009 182910* *************************************TRACE

Mehr

Entwicklungen und Trends im EAI Bereich

Entwicklungen und Trends im EAI Bereich Herzlich willkommen SerCon Ihr Partner Der beherrschende Prozess l IT-Beratung l Analyse l Konzeption l Implementierung l Support & l Strategieberatung l Organisationsberatung l Potenzialberatung l Qualitätsmanagement

Mehr

Grundlagen der Wirtschaftsinformatik

Grundlagen der Wirtschaftsinformatik Grundlagen der Wirtschaftsinformatik Bandl Von Univ.-Prof. Dr. Otto K. Ferstl Lehrstuhl für Wirtschaftsinformatik insbes. Industrielle Anwendungssysteme an der Otto-Friedrich-Universität Bamberg und Univ.-Prof.

Mehr

3. Integrationsdimensionen, u. a. Integrationsrichtungen (vgl. 1 und 2) 4. Vertikale und horizontale Integrationsrichtung (vgl.

3. Integrationsdimensionen, u. a. Integrationsrichtungen (vgl. 1 und 2) 4. Vertikale und horizontale Integrationsrichtung (vgl. Anwendungssysteme 1. Vertikal: unterstützte organisationale Ebene Informationsdichtegrad 2. Horizontal: unterstützter Funktionsbereich betriebliche Grundfunktion 3. Integrationsdimensionen, u. a. Integrationsrichtungen

Mehr

Berichte aus der Medizinischen Informatik und Bioinformatik. Günther Schadow. Krankenhauskommunikation mit HL7

Berichte aus der Medizinischen Informatik und Bioinformatik. Günther Schadow. Krankenhauskommunikation mit HL7 Berichte aus der Medizinischen Informatik und Bioinformatik Günther Schadow Krankenhauskommunikation mit HL7 Analyse, Implementation und Anwendungeines Protokollstandards für medizinische Datenkommunikation

Mehr

Einführung und Überblick Informationssysteme

Einführung und Überblick Informationssysteme Einführung und Überblick Informationssysteme Lernziele Die Studierenden wissen, was betriebliche Informationssysteme (IS) sind kennen den Unterschied zwischen Zeichen, Daten, Informationen und Wissen kennen

Mehr

Modul IAWS-E-COM-M: E-Commerce-Systeme

Modul IAWS-E-COM-M: E-Commerce-Systeme Modul IAWS-E-COM-M: E-Commerce-Systeme Modulgruppen Lernziele / Kompetenzen Wirtschaftsinformatik ->FG Wirtschaftsinformatik ->Fach: Industrielle Anwendungssysteme Kenntnis des Modells der E-Commerce-Systemarchitektur

Mehr

Ein Beispiel. Ein Unternehmen will Internettechnologien im Rahmen des E- Business nutzen Welche Geschäftsprozesse?

Ein Beispiel. Ein Unternehmen will Internettechnologien im Rahmen des E- Business nutzen Welche Geschäftsprozesse? Ein Beispiel Ein Unternehmen will Internettechnologien im Rahmen des E- Business nutzen Welche Geschäftsprozesse? Dipl.-Kfm. Claus Häberle WS 2015 /16 # 42 XML (vereinfacht) visa

Mehr

Wirtschaftsinformatik Zusammenfassung

Wirtschaftsinformatik Zusammenfassung Wirtschaftsinformatik Zusammenfassung Kapitel 1 Informationssysteme Welche Rolle spielen Informationssysteme? - Mit Änderungen im Markt umgehen - Bieten Kommunikations- und Analysemöglichkeit (für globalen

Mehr

COMOS/SAP-Schnittstelle

COMOS/SAP-Schnittstelle COMOS/SAP-Schnittstelle White Paper Optimierter Datenaustausch zwischen COMOS und SAP Juni 2010 Zusammenfassung Ein konsistenter Datenaustausch zwischen Engineering-Anwendungen und ERP-Systemen ist heutzutage

Mehr

Blitzlicht: MES Produktionsplanung und Unternehmensmodelle IEC 62264 Integration von Unternehmensführungs und Leitsystemen

Blitzlicht: MES Produktionsplanung und Unternehmensmodelle IEC 62264 Integration von Unternehmensführungs und Leitsystemen Blitzlicht: MES Produktionsplanung und Unternehmensmodelle IEC 62264 Integration von Unternehmensführungs und Leitsystemen Tagung: Normen für Industrie 4.0 BMWi, Berlin 19.02.2015 Max Weinmann, Emerson

Mehr

Wi rtschaf tsinf or mati k

Wi rtschaf tsinf or mati k Bettina Schwarzer/Helmut Krcmar Wi rtschaf tsinf or mati k Grundlagen betrieblicher Informationssysteme 5., überarbeitete Auflage 2014 Schäffer-Poeschel Verlag Stuttgart Inhaltsverzeichnis Vorwort zur

Mehr

Enterprise Service Bus

Enterprise Service Bus Enterprise Service Bus Christopher Weiß 25.01.2010 Gliederung 1 Motivation und Einordung Integrationsformen 2 Definition und Eigenschaften Definitionen Eigenschaften 3 Aufbau und Konzepte Aufbau Produkte

Mehr

B2B für meine Geschäftspartner

B2B für meine Geschäftspartner B2B für meine Geschäftspartner Michael Stapf Oracle Deutschland B.V. & Co. KG Frankfurt Schlüsselworte B2B, Business-to-Business, Geschäftspartnerintegration, Elektronische Geschäftskommunikation Einleitung

Mehr

1. Was bedeutet EAI? 2. Worin liegen die Vorteile? 3. Worin liegen die Nachteile? 4. EAI-Markt

1. Was bedeutet EAI? 2. Worin liegen die Vorteile? 3. Worin liegen die Nachteile? 4. EAI-Markt Referate-Seminar WS 2001/2002 Veranstaltungsort: Giessen Datum: 03. April 2002 Fachbereich: Wirtschaftsinformatik Referentin: Übersicht 2. Worin liegen die Vorteile? 3. Worin liegen die Nachteile? Seite

Mehr

Kommunikation und interoperable Standards für den Nachrichtenaustausch. Prof. Dr. Hermann Krallmann

Kommunikation und interoperable Standards für den Nachrichtenaustausch. Prof. Dr. Hermann Krallmann Kommunikation und interoperable Standards für den Nachrichtenaustausch Prof. Dr. Hermann Krallmann Agenda Herleitung Interoperabilitätsebenen Studie (national) Zwischenfazit Studie (international) Fazit

Mehr

Inhaltsverzeichnis: Definitionen Informationssysteme als Kommunikationssystem Problemlösende Perspektiven Allgemeine System Annäherung Fazit

Inhaltsverzeichnis: Definitionen Informationssysteme als Kommunikationssystem Problemlösende Perspektiven Allgemeine System Annäherung Fazit Informationssysteme Inhaltsverzeichnis: Definitionen Informationssysteme als Kommunikationssystem Problemlösende Perspektiven Allgemeine System Annäherung Fazit Definitionen: Informationen Informationssysteme

Mehr

Software Engineering. Bibliographisches Institut & F. A. Brockhaus AG, Mannheim; Spektrum Akademischer Verlag GmbH, Heidelberg, 2003

Software Engineering. Bibliographisches Institut & F. A. Brockhaus AG, Mannheim; Spektrum Akademischer Verlag GmbH, Heidelberg, 2003 Software Engineering Softwaretechnik Softwaretechnologie, Software Engineering (engl.) das, -, Teilgebiet der Informatik, das sich mit Methoden und Werkzeugen für das ingenieurmäßige Entwerfen, Herstellen

Mehr

Praxishandbuch SAP NetWeaver" Pl - Entwicklung

Praxishandbuch SAP NetWeaver Pl - Entwicklung Valentin Nicolescu, Burkhardt Funk, Peter Niemeyer, Matthias Heiler, Holger Wittges, Thomas Morandell, Florian Visintin, Benedikt Kleine Stegemann, Harald Kienegger Praxishandbuch SAP NetWeaver" Pl - Entwicklung

Mehr

Koordination Kommunikation Bahn. KoKoBahn. Projektpartner. Laufzeit. Travemünder Datenverbund GmbH, Lübeck. dbh Logistics IT AG, Bremen

Koordination Kommunikation Bahn. KoKoBahn. Projektpartner. Laufzeit. Travemünder Datenverbund GmbH, Lübeck. dbh Logistics IT AG, Bremen Koordination Kommunikation Bahn KoKoBahn Berlin, 09. / 10. Dezember 2010 Projektpartner Travemünder Datenverbund GmbH, Lübeck dbh Logistics IT AG, Bremen Laufzeit 01.06.2008 31.05.2011 Die Komplexität

Mehr

PIWIN II. Praktische Informatik für Wirtschaftsmathematiker, Ingenieure und Naturwissenschaftler II. Vorlesung 2 SWS SS 08

PIWIN II. Praktische Informatik für Wirtschaftsmathematiker, Ingenieure und Naturwissenschaftler II. Vorlesung 2 SWS SS 08 PIWIN II Kap. 3: Verteilte Systeme & Rechnernetze 1 PIWIN II Praktische Informatik für Wirtschaftsmathematiker, Ingenieure und Naturwissenschaftler II Vorlesung 2 SWS SS 08 Fakultät für Informatik Technische

Mehr

Konzepte und Methoden des Supply Chain Management

Konzepte und Methoden des Supply Chain Management Konzepte und Methoden des Supply Chain Management Kapitel 6 IT-Systeme für das Supply Chain Management Modul Produktionslogistik W 2332-02 SS 2014 Grundvoraussetzungen für eine erfolgreiche Planung und

Mehr

Anwendungsorientierte Wirtschaftsinformatik

Anwendungsorientierte Wirtschaftsinformatik Paul Alpar Rainer Alt Frank Be;nsberg Heinz Lothar Grob I Peter Weimahn I Robert Winter Anwendungsorientierte Wirtschaftsinformatik Strategische Planung, Entwicklung und Nutzung von Informationssystemen

Mehr

Beschreibung von interorganisationalen Informationsystemen und Industriestrukturen

Beschreibung von interorganisationalen Informationsystemen und Industriestrukturen Beschreibung von interorganisationalen Informationsystemen und Industriestrukturen Business Networking: A process-oriented Framework by Elgar Fleisch and Hubert Österle Benjamin Spottke 13.06.2005 Agenda

Mehr

Geschäftsstrategie und SOA - ein Thema für den Mittelstand? Prof. Dr. Gunther Piller

Geschäftsstrategie und SOA - ein Thema für den Mittelstand? Prof. Dr. Gunther Piller Geschäftsstrategie und SOA - ein Thema für den Mittelstand? Prof. Dr. Gunther Piller Aktuelles 2 Langfristige strategische IT- Planung existiert [im Mittelstand] in vielen Fällen nicht Bitkom: IuK im Mittelstand,

Mehr

Entwurf partieller SOA auf der Grundlage von Geschäftsprozessmodellen

Entwurf partieller SOA auf der Grundlage von Geschäftsprozessmodellen Entwurf partieller SOA auf der Grundlage von Geschäftsprozessmodellen forflex-tagung 2011 27.05.2011 Dipl.-Wirtsch.Inf. Andree Krücke Prof. Dr. Elmar J. Sinz Gliederung 1. SOA-Ziele und Unternehmensanforderungen

Mehr

1 Einleitung. Betriebswirtschaftlich administrative Systeme

1 Einleitung. Betriebswirtschaftlich administrative Systeme 1 1 Einleitung Data Warehousing hat sich in den letzten Jahren zu einem der zentralen Themen der Informationstechnologie entwickelt. Es wird als strategisches Werkzeug zur Bereitstellung von Informationen

Mehr

ZENITY - Die Software für Ihre Unternehmens-Releaseplanung

ZENITY - Die Software für Ihre Unternehmens-Releaseplanung ZENITY - Die Software für Ihre Unternehmens-Releaseplanung RELEASEPLANUNG HEUTE Heutige Anwendungen in in Grossunternehmen sind sind keine keine alleinstehenden alleinstehenden Insel-Applikationen Insel-Applikationen

Mehr

Seminar Business Process Management und Workflow-Technologie: Grundlagen, Produkte, Forschung

Seminar Business Process Management und Workflow-Technologie: Grundlagen, Produkte, Forschung IBM WebSphere Process Server Seminar Business Process Management und Workflow-Technologie: Grundlagen, Produkte, Forschung AGENDA 1. Überblick 2. WebSphere Process Server 3. Komponenten 4. Präsentation

Mehr

Model Driven Architecture (MDA)

Model Driven Architecture (MDA) Model Driven Architecture (MDA) Vortrag im Fach Software Engineering II BA Mannheim / Fachrichtung Angewandte Informatik Torsten Hopp Gliederung Einleitung Motivation Grundzüge der MDA Ziele & Potenziale

Mehr

Konzeption eines Master-Data-Management-Systems. Sven Schilling

Konzeption eines Master-Data-Management-Systems. Sven Schilling Konzeption eines Master-Data-Management-Systems Sven Schilling Gliederung Teil I Vorstellung des Unternehmens Thema der Diplomarbeit Teil II Master Data Management Seite 2 Teil I Das Unternehmen Vorstellung

Mehr

ecl@ss im Unternehmen Chance oder Hürde? Gerald Lobermeier Weidmüller Interface GmbH & Co. KG, Detmold

ecl@ss im Unternehmen Chance oder Hürde? Gerald Lobermeier Weidmüller Interface GmbH & Co. KG, Detmold ecl@ss im Unternehmen Chance oder Hürde? Gerald Lobermeier Weidmüller Interface GmbH & Co. KG, Detmold Agenda Weidmüller Interface Unternehmensvorstellung Produkte & Prozesse Datenmanagement ecl@ss bei

Mehr

Java und XML 2. Java und XML

Java und XML 2. Java und XML Technische Universität Ilmenau Fakultät für Informatik und Automatisierung Institut für Praktische Informatik und Medieninformatik Fachgebiet Telematik Java und XML Hauptseminar Telematik WS 2002/2003

Mehr

Content Management Datenbanken, Schnittstellen

Content Management Datenbanken, Schnittstellen Unterschiedlichste Informationen übersichtlich organisiert sypress Content Management Systemgruppe sypress bietet Ihnen Produkt oder Themen bezogen die Verwaltung beliebiger Inhalte. Die Speicherung erfolgt

Mehr

EINFÜHRUNG IN DIE WIRTSCHAFTSINFORMATIK -ÜBUNGEN- Marina Tropmann-Frick mtr@is.informatik.uni-kiel.de www.is.informatik.uni-kiel.

EINFÜHRUNG IN DIE WIRTSCHAFTSINFORMATIK -ÜBUNGEN- Marina Tropmann-Frick mtr@is.informatik.uni-kiel.de www.is.informatik.uni-kiel. EINFÜHRUNG IN DIE WIRTSCHAFTSINFORMATIK -ÜBUNGEN- Marina Tropmann-Frick mtr@is.informatik.uni-kiel.de www.is.informatik.uni-kiel.de/~mtr FRAGEN / ANMERKUNGEN Vorlesung Neue Übungsaufgaben MODELLIERUNG

Mehr

Integrationsprozesse. cross component BPM - Steuerung systemübergreifender Szenarien. Konrad Lubenow, FHTW Berlin, Juli 2007

Integrationsprozesse. cross component BPM - Steuerung systemübergreifender Szenarien. Konrad Lubenow, FHTW Berlin, Juli 2007 Integrationsprozesse cross component BPM - Steuerung systemübergreifender Szenarien Konrad Lubenow, FHTW Berlin, Juli 2007 Integrationsprozesse XI(ccBPM) normaler Messageaustausch über den Integrationsserver

Mehr

Business Intelligence

Business Intelligence Business Intelligence Anwendungssysteme (BIAS) Lösung Aufgabe 1 Übung WS 2012/13 Business Intelligence Erläutern Sie den Begriff Business Intelligence. Gehen Sie bei der Definition von Business Intelligence

Mehr

Informationsmanagement Übungsstunde 6

Informationsmanagement Übungsstunde 6 Informationsmanagement Übungsstunde 6 Univ.-Prof. Dr.-Ing. Wolfgang Maass Lehrstuhl für Betriebswirtschaftslehre, insb. Wirtschaftsinformatik im Dienstleistungsbereich (Information and Service Systems

Mehr

Einflussfaktoren auf eine Softwarearchitektur und ihre Wechselwirkungen Entwurfsentscheidungen systematisieren

Einflussfaktoren auf eine Softwarearchitektur und ihre Wechselwirkungen Entwurfsentscheidungen systematisieren 1 Einflussfaktoren auf eine Softwarearchitektur und ihre Wechselwirkungen Entwurfsentscheidungen systematisieren W3L AG info@w3l.de 2011 2 Agenda Softwarearchitektur und Architekturentwurf Definition Überblick

Mehr

Einsatz von Applikationsservern. Untersucht am Beispiel des Sybase Enterprise Application Server

Einsatz von Applikationsservern. Untersucht am Beispiel des Sybase Enterprise Application Server Einsatz von Applikationsservern Untersucht am Beispiel des Sybase Enterprise Application Server Architektur von Datenbanksystemen Client / Server Modell (2 Schichten Modell) Benutzerschnittstelle Präsentationslogik

Mehr

Rainer Thome Axel Winkelmann. Grundzüge der. Wirtschaftsinformatik. Organisation und. Informationsverarbeitung. 4^ Springer Gabler

Rainer Thome Axel Winkelmann. Grundzüge der. Wirtschaftsinformatik. Organisation und. Informationsverarbeitung. 4^ Springer Gabler Rainer Thome Axel Winkelmann Grundzüge der Wirtschaftsinformatik Organisation und Informationsverarbeitung 4^ Springer Gabler XV Inhalt Vorwort V Lesewege durch dieses Buch 1 Grundlegende Aspekte der integrierten

Mehr

In diesem Kapitel werden wir nun mehrere Anwendungen von XML in der betrieblichen Praxis vorstellen. Sie sollen XML bei der Arbeit zeigen.

In diesem Kapitel werden wir nun mehrere Anwendungen von XML in der betrieblichen Praxis vorstellen. Sie sollen XML bei der Arbeit zeigen. 181 In diesem Kapitel werden wir nun mehrere Anwendungen von XML in der betrieblichen Praxis vorstellen. Sie sollen XML bei der Arbeit zeigen. Wir beginnen mit dem Startup-Unternehmen Seals GmbH aus Frankfurt,

Mehr

Wirtschaftsinformatik II SS 2012. Einführung in SAP

Wirtschaftsinformatik II SS 2012. Einführung in SAP Wirtschaftsinformatik II SS 2012 Einführung in SAP SAP als klassisches ERP-System SAP = ERP Enterprise Ressource Planing SAP als klassisches ERP-System SAP: führender Anbieter im Bereich ERP-Systeme (Enterprise

Mehr

Microsoft.NET und SunONE

Microsoft.NET und SunONE Microsoft.NET und SunONE, Plattformen und Application Service Providing Agenda Einordnung.NET und SunONE Kurzvorstellung Gegenüberstellung Zusammenfassung ASP (Application( Service Providing) ) und Ausblick

Mehr

Autor: Peter Seemann Seminar: Softwarearchitekturen Betreuer: Benedikt Meurer

Autor: Peter Seemann Seminar: Softwarearchitekturen Betreuer: Benedikt Meurer Autor: Peter Seemann Seminar: Softwarearchitekturen Betreuer: Benedikt Meurer *Was sind Web Services? *Beispiele für Web Services *Web Service Architektur *Web Services Technologien *Fazit 2 *Übertragungsstandard

Mehr

Message Oriented Middleware am Beispiel von XMLBlaster

Message Oriented Middleware am Beispiel von XMLBlaster Message Oriented Middleware am Beispiel von XMLBlaster Vortrag im Seminar XML und intelligente Systeme an der Universität Bielefeld WS 2005/2006 Vortragender: Frederic Siepmann fsiepman@techfak.uni bielefeld.de

Mehr

DISKUSSIONSBEITRÄGE DER FAKULTÄT FÜR BETRIEBSWIRTSCHAFTSLEHRE MERCATOR SCHOOL OF MANAGEMENT UNIVERSITÄT DUISBURG-ESSEN. Nr. 350

DISKUSSIONSBEITRÄGE DER FAKULTÄT FÜR BETRIEBSWIRTSCHAFTSLEHRE MERCATOR SCHOOL OF MANAGEMENT UNIVERSITÄT DUISBURG-ESSEN. Nr. 350 DISKUSSIONSBEITRÄGE DER FAKULTÄT FÜR BETRIEBSWIRTSCHAFTSLEHRE MERCATOR SCHOOL OF MANAGEMENT UNIVERSITÄT DUISBURG-ESSEN Nr. 350 Ein konzeptioneller Business-Intelligence-Ansatz zur Gestaltung von Geschäftsprozessen

Mehr

Beiträge zur Integrationsproblematik im Kontext von Electronic Business und Elektronischen Marktplätzen

Beiträge zur Integrationsproblematik im Kontext von Electronic Business und Elektronischen Marktplätzen Beiträge zur atik im Kontext von Electronic Business und Elektronischen Marktplätzen Peter Voigtmann Thomas Zeller Zusammenfassung: Relevanz und Komplexität der Aufgabenstellung zwischenbetrieblicher Integration

Mehr

ET-Connector Produktreihe

ET-Connector Produktreihe ET-Connector Produktreihe Die Integration aller Unternehmenslösungen über Unternehmensgrenzen hinweg ist die Herausforderung der Gegenwart ET-Produktreihe Der Zwang zur Kostensenkung ist derzeit in allen

Mehr

Industrie 4.0: ein Megatrend und seine Auswirkungen auf kleine und mittlere Unternehmen und die Nutzung von estandards

Industrie 4.0: ein Megatrend und seine Auswirkungen auf kleine und mittlere Unternehmen und die Nutzung von estandards Industrie 4.0: ein Megatrend und seine Auswirkungen auf kleine und mittlere Unternehmen und die Nutzung von estandards M-Days Expertenforum Industrie 4.0 und estandards Frankfurt, den 14. Mai 2014 Ansprechpartner:

Mehr

Web Services. 1. Quelle. Brian Connel The Seven Pillars of Web Services Management. Erschienen September 2002 im eai Journal

Web Services. 1. Quelle. Brian Connel The Seven Pillars of Web Services Management. Erschienen September 2002 im eai Journal Web Services - Brian Connel: The Seven Pillars of Web Services Management - IBM: IBM Strategy for management of the WebServices infrastrucutre Seminarvortrag von Lukasz Kidawski im Rahmen der Lehrveranstaltung

Mehr

Grundbegriffe der Wirtschaftsinformatik Informationssystem I

Grundbegriffe der Wirtschaftsinformatik Informationssystem I Informationssystem I Keine Definition [Stahlknecht, Hasenkamp (2002) und Mertens et al. (2000)] Ein System zur Beschaffung, Verarbeitung, Übertragung, Speicherung und/oder Bereitstellung von Informationen

Mehr

Etablierung serviceorientierter Architekturen mit Web Services

Etablierung serviceorientierter Architekturen mit Web Services Etablierung serviceorientierter Architekturen mit Web Services Vorlesung im (Übersicht zu den Inhalten der Vorlesung) Somemrsemester 2013 1 Ziele und Abgrenzung 2 Allgemeine Lernziele Vermittlung von Basiskenntnissen

Mehr

Inhalte, Berufsbilder, Zukunftschancen Prof. Dr. Jörg Müller, Institut für Informatik 18.6.2005 Was ist? beschäftigt sich mit betrieblichen, behördlichen und privaten Informations-, Kommunikationsund Anwendungssystemen

Mehr

Übung 6. Verwendung von Referenzdatenmodellen. Prof. Dr. Andreas Schmietendorf 1. Übung 6

Übung 6. Verwendung von Referenzdatenmodellen. Prof. Dr. Andreas Schmietendorf 1. Übung 6 Verwendung von Referenzdatenmodellen Prof. Dr. Andreas Schmietendorf 1 Motivation zur Verwendung von Referenzdatenmodellen Prof. Dr. Andreas Schmietendorf 2 Komplexität von Anwendungsarchitekturen Call

Mehr

Workflow, Business Process Management, 4.Teil

Workflow, Business Process Management, 4.Teil Workflow, Business Process Management, 4.Teil 24. Januar 2004 Der vorliegende Text darf für Zwecke der Vorlesung Workflow, Business Process Management des Autors vervielfältigt werden. Eine weitere Nutzung

Mehr

Agenda. Clients aus drei verschiedenen Perspektiven: Was ist ein Dialog? Komponentenarchitektur innerhalb eines Dialoges

Agenda. Clients aus drei verschiedenen Perspektiven: Was ist ein Dialog? Komponentenarchitektur innerhalb eines Dialoges Komponentenbasierte Client-Architektur Hamburg, 16.11.2007 Bernd Olleck IT-Beratung Olleck Agenda Clients aus drei verschiedenen Perspektiven: Technische Infrastruktur Fachliche Sicht Aufgaben eines Clients

Mehr

Sonstiges Wahlfach Wirtschaftsinformatik

Sonstiges Wahlfach Wirtschaftsinformatik Sonstiges Wahlfach Wirtschaftsinformatik Anhang Nr. 48: Wirtschaftsinformatik Das Fach ist bestanden, wenn 24 Leistungspunkte erworben wurden. Veranstaltungsform SWS Turnus Leistungspunkte Prüfungsform

Mehr

Definition Informationssystem

Definition Informationssystem Definition Informationssystem Informationssysteme (IS) sind soziotechnische Systeme, die menschliche und maschinelle Komponenten umfassen. Sie unterstützen die Sammlung, Verarbeitung, Bereitstellung, Kommunikation

Mehr

White Paper. Konfiguration und Verwendung des Auditlogs. 2012 Winter Release

White Paper. Konfiguration und Verwendung des Auditlogs. 2012 Winter Release White Paper Konfiguration und Verwendung des Auditlogs 2012 Winter Release Copyright Fabasoft R&D GmbH, A-4020 Linz, 2011. Alle Rechte vorbehalten. Alle verwendeten Hard- und Softwarenamen sind Handelsnamen

Mehr

Integrierte Geschäftskommunikation

Integrierte Geschäftskommunikation Integrierte Geschäftskommunikation INAUGURAL-DISSERTATION zur Erlangung des akademischen Grades eines Doktors der Wirtschaftswissenschaften an der Wirtschaftswissenschaftlichen Fakultät der Julius-Maximilians-Universität

Mehr

EDI CONNECT. für Microsoft Dynamics NAV. Auf einen Blick:

EDI CONNECT. für Microsoft Dynamics NAV. Auf einen Blick: Seite 1 PROTAKT Speziallösung EDI Connect Auf einen Blick: EDI CONNECT für Microsoft Dynamics NAV Elektronischer Datenaustausch ganz effizient und einfach über Ihr Microsoft Dynamics NAV System. Vollständige

Mehr

Entwicklung einer Methode zur Bewertung der Transformierbarkeit von On-Premise Anwendungssystemen in Software as a Service Lösungen

Entwicklung einer Methode zur Bewertung der Transformierbarkeit von On-Premise Anwendungssystemen in Software as a Service Lösungen Fakultät für Informatik Technische Universität München Entwicklung einer Methode zur Bewertung der Transformierbarkeit von On-Premise Anwendungssystemen in Software as a Service Lösungen Bachelorarbeit

Mehr

was wie - warum 4 media selling, Dehne & Herrmann GmbH Handel Service Software e-procat Klassifizierung mediando cat4web Outsourcing cat4print

was wie - warum 4 media selling, Dehne & Herrmann GmbH Handel Service Software e-procat Klassifizierung mediando cat4web Outsourcing cat4print BMEcat was wie - warum Heiko Dehne Industrie 4 media selling, Dehne & Herrmann GmbH Handel Katalog Start Software Service Vertrieb Beratung Schulung e-procat mediando Klassifizierung Beratung ERP Datenanalyse

Mehr

OSS/J als Basis für Enterprise Application Integration

OSS/J als Basis für Enterprise Application Integration OSS/J als Basis für Enterprise Application Integration Geschäftsprozessgesteuerte EAI im Telekommunikationsbereich r A business of PwC Agenda OSS-Architekturen als Integrationsherausforderung OSS/J als

Mehr

DB-Aspekte des E-Commerce Schwerpunkt Anwendungen

DB-Aspekte des E-Commerce Schwerpunkt Anwendungen DB-Aspekte des E-Commerce Schwerpunkt Anwendungen Business-to-Business Portale Marco Müller marmue@rhrk.uni-kl.de 1 Einführung Was ist B2B? Daten- und Anwendungsintegration Portale - Ein Rückblick Einteilung

Mehr

Districurement. New Economy Districurement Page 1

Districurement. New Economy Districurement Page 1 Districurement Titel des Lernmoduls: Districurement Themengebiet: New Economy Gliederungspunkt im Curriculum: 2.2.1.3.2 Zum Inhalt: Durch www-orientierte Beschaffungsansätze und Kooperationen mit den Partnern,

Mehr

30. Juni 2006 - Technische Universität Kaiserslautern. Paul R. Schilling

30. Juni 2006 - Technische Universität Kaiserslautern. Paul R. Schilling 30. Juni 2006 - Technische Universität Kaiserslautern Paul R. Schilling ! " #$% & '( ( ) *+, - '. / 0 1 2("$ DATEN SIND ALLGEGENWÄRTIG Bill Inmon, father of data warehousing Unternehmen In einer vollkommenen

Mehr

BPEL als Eckpfeiler einer Serviceorientierten Architektur

BPEL als Eckpfeiler einer Serviceorientierten Architektur BPEL als Eckpfeiler einer Serviceorientierten Architektur Stand der Technik und hands-on Demonstration 1. Dez. 2005 Marc Pellmann www.inubit.com inubit AG = Standardsoftware für integrierte Geschäftsprozesse

Mehr

Enterprise Content Management

Enterprise Content Management Enterprise Content Management Dr.-Ing. Raymond Bimazubute Lehrstuhl für Künstliche Intelligenz Friedrich Alexander Universität Erlangen-Nürnberg Email: raymond.bimazubute@informatik.uni-erlangen.de Vorbemerkungen

Mehr

Peter Körner Adobe Systems Berlin, 3. Juni 2005

Peter Körner Adobe Systems Berlin, 3. Juni 2005 Interactive Forms based on Adobe Software: Überblick Peter Körner Adobe Systems Berlin, 3. Juni 2005 Einleitung Anwendungsszenarios Technologie Einleitung Anwendungsszenarios Technologie Anforderungen

Mehr

Universität OLDENBURG

Universität OLDENBURG CARL VON > OSSIETZKY Universität OLDENBURG Fakultät II - Informatik, Wirtschafts- und Rechtswissenschaften Department für Informatik Föderierte ERP-Systeme auf Basis von Web Services Dissertation zur Erlangung

Mehr

SE2-10-Entwurfsmuster-2 15

SE2-10-Entwurfsmuster-2 15 Architektur und Skalierbarkeit SE2-10-Entwurfsmuster-2 15 Skalierbarkeit Skalierbarkeit bedeutet die Anpassung einer Software an wachsende Last: Interaktionsfrequenz Nutzerzahl Anpassung durch Hinzufügen

Mehr

Einkaufskatalogsystem

Einkaufskatalogsystem Einkaufskatalogsystem Titel des Lernmoduls: Einkaufskatalogsystem Themengebiet: New Economy Gliederungspunkt im Curriculum: 2.2.1.3.5 Zum Inhalt: Dieses Modul befasst sich mit elektronischen Einkaufskatalogen

Mehr