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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Vernetzte Produktentwicklung

Vernetzte Produktentwicklung Vernetzte Produktentwicklung Der erfolgreiche Weg zum Global Engineering Networking von Jürgen Gausemeier, Axel Hahn, Hans D. Kespohl, Lars Seifert 1. Auflage Hanser München 2006 Verlag C.H. Beck im Internet:

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

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

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

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

Wrapper und Konnektoren geht die Rechnung auf?

Wrapper und Konnektoren geht die Rechnung auf? Wrapper und Konnektoren geht die Rechnung auf? Klaudia Hergula DaimlerChrysler AG Forschung und Technologie Wissensaustausch / Austauschgruppe (FTK/A) HPC 0516, Epplestr. 225, D-70546 Stuttgart klaudia.hergula@daimlerchrysler.com

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

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

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

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

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

Ordentliche Geschäftsprozessmodellierung (GPM) nutzt auch Ihrer IT-Infrastruktur. (Was hat GPM mit IT zu tun?) Antonius J.M.

Ordentliche Geschäftsprozessmodellierung (GPM) nutzt auch Ihrer IT-Infrastruktur. (Was hat GPM mit IT zu tun?) Antonius J.M. Ordentliche Geschäftsprozessmodellierung (GPM) nutzt auch Ihrer IT-Infrastruktur (Was hat GPM mit IT zu tun?) Antonius J.M. van Hoof Fachrichtung Informationstechnik GPM-Workshop 07.07.2006 Inhalt Kernpunkte

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

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

Vorlesung Anwendungssysteme WS 2005/06 - Studentische Präsentationen und Ausarbeitungen - Themenliste und Leitfragen

Vorlesung Anwendungssysteme WS 2005/06 - Studentische Präsentationen und Ausarbeitungen - Themenliste und Leitfragen Prof. Dr. Katja Lenz Prof. Dr. Urs Andelfinger Vorlesung Anwendungssysteme WS 2005/06 - Studentische Präsentationen und Ausarbeitungen - Themenliste und Leitfragen 1 27.. Thema: Modellierung von betrieblichen

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

Management Support Systeme

Management Support Systeme Folie 1 Management Support Systeme Literatur zur Vorlesung MSS Gluchowski, Peter; Gabriel, Roland; Chamoni, Peter (1997): Management Support Systeme. Computergestützte Informationssysteme für Führungskräfte

Mehr

Konzepte und Methoden des Supply Chain Management. Kapitel 6 IT-Systeme für das Supply Chain Management Modul Produktionslogistik W 2332-02 SS 2015

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

Mehr

Geschäftsprozessmodellierung und implementierung am Beispiel SAP ERP

Geschäftsprozessmodellierung und implementierung am Beispiel SAP ERP Geschäftsprozessmodellierung und implementierung am Beispiel SAP ERP V04 02. Mai 2011, 16.15-17.45 Uhr, ITS-Pool nur zugelassene Teilnehmer Niedersächsisches Hochschulkompetenzzentrum für SAP (CCC) Aktuelles

Mehr

Worum geht es beim CRM? Geben Sie den Inhalt des nachstehenden Textes mit eigenen Worten wieder.

Worum geht es beim CRM? Geben Sie den Inhalt des nachstehenden Textes mit eigenen Worten wieder. Präsenzübung Service 2.1. CRM Customer-Relationship Management a) Anliegen des CRM Worum geht es beim CRM? Geben Sie den Inhalt des nachstehenden Textes mit eigenen Worten wieder. CRM, auch Beziehungsmanagement

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

ODEX Enterprise. ODEX Enterprise. Beratungsbüro Kasch GmbH & Co. KG. Beratungsbüro Kasch GmbH & Co KG Hemsener Weg 73 D-29640 Schneverdingen

ODEX Enterprise. ODEX Enterprise. Beratungsbüro Kasch GmbH & Co. KG. Beratungsbüro Kasch GmbH & Co KG Hemsener Weg 73 D-29640 Schneverdingen ODEX Enterprise Beratungsbüro Kasch GmbH & Co. KG ODEX Enterprise Im Firmenalltag müssen Geschäftsdokumente zuverlässig und effizient ausgetauscht werden, ansonsten drohen schwerwiegende finanzielle Konsequenzen.

Mehr

Enterprise Application Integration

Enterprise Application Integration Enterprise Application Integration Titel des Lernmoduls: Enterprise Application Integration Themengebiet: New Economy Gliederungspunkt im Curriculum: 2.2.1.3.4 Zum Inhalt: Dieses Modul befasst sich mit

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

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

Geschäftsprozessmanagement

Geschäftsprozessmanagement Geschäftsprozessmanagement Der INTARGIA-Ansatz Whitepaper Dr. Thomas Jurisch, Steffen Weber INTARGIA Managementberatung GmbH Max-Planck-Straße 20 63303 Dreieich Telefon: +49 (0)6103 / 5086-0 Telefax: +49

Mehr

1. Einleitung. 1.1. Ausgangssituation

1. Einleitung. 1.1. Ausgangssituation 1. Einleitung In der vorliegenden Arbeit wird untersucht, welche Faktoren den erfolgreichen Ausgang eines Supply-Chain-Projektes zwischen zwei Projektpartnern beeinflussen. Dazu werden zum einen mögliche

Mehr

Java Enterprise Architekturen Willkommen in der Realität

Java Enterprise Architekturen Willkommen in der Realität Java Enterprise Architekturen Willkommen in der Realität Ralf Degner (Ralf.Degner@tk-online.de), Dr. Frank Griffel (Dr.Frank.Griffel@tk-online.de) Techniker Krankenkasse Häufig werden Mehrschichtarchitekturen

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

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

Berner Fachhochschule. Bildung und Forschung auf dem faszinierenden Gebiet der Informatik. bfh.ch/informatik

Berner Fachhochschule. Bildung und Forschung auf dem faszinierenden Gebiet der Informatik. bfh.ch/informatik Berner Fachhochschule Bildung und Forschung auf dem faszinierenden Gebiet der Informatik. bfh.ch/informatik Berner Fachhochschule Technik und Informatik Postfach, CH-2501 Biel/Bienne T +41 32 321 61 11

Mehr

Software Engineering II (IB) Serviceorientierte Architektur

Software Engineering II (IB) Serviceorientierte Architektur Serviceorientierte Architektur Prof. Dr. Oliver Braun Fakultät für Informatik und Mathematik Hochschule München SS 2015 Webservices Ziel: flexible programmatische Zusammenarbeit zwischen Servern Bereitstellung

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

Service-Orientierte Architekturen

Service-Orientierte Architekturen Hochschule Bonn-Rhein-Sieg Service-Orientierte Architekturen Kapitel 7: Web Services IV Exkurs über Sicherheitsanforderungen Vorlesung im Masterstudiengang Informatik Sommersemester 2010 Prof. Dr. Sascha

Mehr

Fakultät. Modulkoordinator Frank Termer. Modul-Name Wirtschaftsinformatik Modul-Nr : 51012

Fakultät. Modulkoordinator Frank Termer. Modul-Name Wirtschaftsinformatik Modul-Nr : 51012 Fakultät Wirtschaftswissenschaften Studiengang Betriebswirtschaft f. kleine u. mitt. Unternehmen Modulbeschreibung Modulkoordinator Frank Termer Modul-Name Wirtschaftsinformatik Modul-Nr : 51012 CP SWS

Mehr

Prozessorientierte Integration von Anwendungssystemen SS 2013 FWP-Fach Wirtschaftsinformatik

Prozessorientierte Integration von Anwendungssystemen SS 2013 FWP-Fach Wirtschaftsinformatik Prozessorientierte Integration von Anwendungssystemen SS 2013 FWP-Fach Wirtschaftsinformatik Prof. Dr. Torsten Zimmer, Hochschule München T. Zimmer 2013 Motivation Integration Die Fortune-1000-Unternehmen

Mehr

Integrating Architecture Apps for the Enterprise

Integrating Architecture Apps for the Enterprise Integrating Architecture Apps for the Enterprise Ein einheitliches Modulsystem für verteilte Unternehmensanwendungen Motivation und Grundkonzept Inhalt Problem Ursache Herausforderung Grundgedanke Architektur

Mehr

Von SAP R/3 zu mysap ERP und NetWeaver

Von SAP R/3 zu mysap ERP und NetWeaver Von SAP R/3 zu mysap ERP und NetWeaver Bremerhaven 06.05.2006 T4T Bremerhaven 1 Inhaltsverzeichnis 1. Motivation für SAP NetWeaver 2. SAP R/3 mysap ERP und SAP Business Suite 3. Application Platform T4T

Mehr

MASTERTHESIS ABSCHLUSSVORTRAG. Kristina Hamann

MASTERTHESIS ABSCHLUSSVORTRAG. Kristina Hamann MASTERTHESIS ABSCHLUSSVORTRAG Kristina Hamann Eckdaten Thema Bearbeiter Betreuer Kooperationspartner Beginn Abgabe Ein Vorgehensmodell zur kooperativen Analyse einer Unternehmensarchitektur im Kontext

Mehr

Service Economics Strategische Grundlage für Integiertes IT-Servicemanagement. Dr. Peter Nattermann. Business Unit Manager Service Economics USU AG

Service Economics Strategische Grundlage für Integiertes IT-Servicemanagement. Dr. Peter Nattermann. Business Unit Manager Service Economics USU AG Economics Strategische Grundlage für Integiertes IT-management Dr. Peter Nattermann Business Unit Manager Economics USU AG Agenda 1 Geschäftsmodell des Providers 2 Lifecycle Management 3 Modellierung 4

Mehr

Effizientes Änderungsmanagement in Outsourcing- Projekten

Effizientes Änderungsmanagement in Outsourcing- Projekten Effizientes Änderungsmanagement in Outsourcing- Projekten Dr. Henning Sternkicker Rational Software IBM Deutschland GmbH Sittarder Straße 31 52078 Aachen henning.sternkicker@de.ibm.com Abstract: Es werden

Mehr

Seminare Softwaretechnik - Einführungsveranstaltung

Seminare Softwaretechnik - Einführungsveranstaltung Seminare Softwaretechnik - Einführungsveranstaltung Stefan Malich, Peter M. Schuler Wintersemester 2004/2005 Version 1.0 Lehrstuhl für Wirtschaftsinformatik und Softwaretechnik Prof. Dr. Stefan Eicker

Mehr

Serviceorientierte Vorgehensmodelle

Serviceorientierte Vorgehensmodelle Serviceorientierte Vorgehensmodelle Überblick, Klassifikation und Vergleich: Ein Paper von Oliver Thomas, Katrina Leyking und Michael Scheid Der Hype um Serviceorientierte Architekturen ist der Wahrnehmung

Mehr

Geschäftsarchitektur, Domänen, Anwendungen

Geschäftsarchitektur, Domänen, Anwendungen LMU Ludwig- Maximilians- Universität München Lehr- und Forschungseinheit für Programmierung und Softwaretechnik Vorlesung am 26.5.2009 Serviceorientiertes egovernment Geschäftsarchitektur, Domänen, Anwendungen

Mehr

Stand September 2010. TransConnect Die Plattform für skalierbare Anwendungsintegration

Stand September 2010. TransConnect Die Plattform für skalierbare Anwendungsintegration Stand September 2010 TransConnect Die Plattform für skalierbare Anwendungsintegration Herausforderungen für EAI-Lösungen Spezialisierte Anwendungssysteme ERP CRM ecommerce Gesundheitswesen Produktion Herausforderungen

Mehr

Praktikum aus Softwareentwicklung 2. Web Services. Java Praktikum SS 2010 Gerald.Ehmayer@borland.com

Praktikum aus Softwareentwicklung 2. Web Services. Java Praktikum SS 2010 Gerald.Ehmayer@borland.com Web Services Java Praktikum SS 2010 Gerald.Ehmayer@borland.com 1 Web Services Einführung Definition, Eigenschaften, Anwendungen... JAX-RPC Überblick, Architektur... JAX Übersicht, Architektur Java Praktikum

Mehr

Proseminar Unternehmensübergreifende IT- Transformationen. Sebis Lehrstuhl Prof. Dr. Florian Matthes. Susanne A. Braun

Proseminar Unternehmensübergreifende IT- Transformationen. Sebis Lehrstuhl Prof. Dr. Florian Matthes. Susanne A. Braun Proseminar Unternehmensübergreifende IT- Transformationen Sebis Lehrstuhl Prof. Dr. Florian Matthes Susanne A. Braun 1 1. Definitionen Konsolidierung Anwendungslandschaft 2. Fusion zweier Unternehmen Symbiose

Mehr

NetWaever-Komponenten

NetWaever-Komponenten NetWaever-Komponenten Bremerhaven 07.05.2006 T4T Bremerhaven 1 Inhaltsverzeichnis 1. People Integration 2. Information Integration 3. Process Integration 4. Solution Management T4T Bremerhaven 2 Kapitel

Mehr

CRM Architektur. New Economy CRM Architektur Page 1

CRM Architektur. New Economy CRM Architektur Page 1 CRM Architektur Titel des Lernmoduls: CRM Architektur Themengebiet: New Economy Gliederungspunkt im Curriculum: 4.2.4.2 Zum Inhalt: Dieses Modul beschreibt mögliche Architekturen von CRM-Systemen. Insbesondere

Mehr

Business Process Execution Language. Christian Vollmer Oliver Garbe

Business Process Execution Language. Christian Vollmer <christian.vollmer@udo.edu> Oliver Garbe <oliver.garbe@udo.edu> Business Process Execution Language Christian Vollmer Oliver Garbe Aufbau Was ist BPEL? Wofür ist BPEL gut? Wie funktioniert BPEL? Wie sieht BPEL aus?

Mehr

E-Business-Integration

E-Business-Integration E-Business-Integration Fallstudien zur Optimierung elektronischer Geschäftsprozesse von Petra Schubert, Ralf Wölfle, Walter Dettling 1. Auflage Hanser München 2003 Verlag C.H. Beck im Internet: www.beck.de

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

Welcome to PHOENIX CONTACT

Welcome to PHOENIX CONTACT Welcome to PHOENIX CONTACT Electronic Data Interchange (EDI) Überblick Begriffsdefinition: EDI Elektronischer Datenaustausch, englisch Electronic Data Interchange (EDI), bezeichnet als Sammelbegriff alle

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

CRM im Mittelstand Ist Mittelstand anders?

CRM im Mittelstand Ist Mittelstand anders? Ist Mittelstand anders? CRM im Mittelstand ist im Trend und fast alle CRM-Unternehmen positionieren ihre Lösungen entsprechend. Aber sind Lösungen für den Mittelstand tatsächlich anders? Oder nur eine

Mehr

VORLESUNGSVERZEICHNIS. Wirtschaftsinformatik und E-Business

VORLESUNGSVERZEICHNIS. Wirtschaftsinformatik und E-Business VORLESUNGSVERZEICHNIS Studiengang: Wirtschaftsinformatik und E-Business Wintersemester 2015/16 Seite 2 Wirtschaftsinformatik und E-Business Studienkompetenz 1 SWS Der Termin wird noch bekannt gegeben Eggendorfer/

Mehr

Hans Robert Hansen und Gustaf Neumann. 520 Abbildungen. 10., völlig neu bearbeitete und erweiterte Auflage. Lucius & Lucius Stuttgart

Hans Robert Hansen und Gustaf Neumann. 520 Abbildungen. 10., völlig neu bearbeitete und erweiterte Auflage. Lucius & Lucius Stuttgart U Hans Robert Hansen und Gustaf Neumann 520 Abbildungen 10., völlig neu bearbeitete und erweiterte Auflage Lucius & Lucius Stuttgart Gebrauchsanleitung XV Kapötel 1s GinuiinidDegeindeir ÜbeirbDick 1.1

Mehr

Die Rolle von Stammdaten-Management in einer SOA

Die Rolle von Stammdaten-Management in einer SOA Die Rolle von Stammdaten-Management in einer SOA Frankfurt, Sept. 2007 Dr. Wolfgang Martin Analyst, ibond Partner, Ventana Research Advisor und Research Advisor am Institut für Business Intelligence Rolle

Mehr

Business Process Monitoring mit dem SAP Solution Manager

Business Process Monitoring mit dem SAP Solution Manager Thomas Schröder Business Process Monitoring mit dem SAP Solution Manager Galileo Press Bonn Boston Geleitwort -... 9 Einleitung 11 1.1 E2E-Support-Standards und Run SAP 17 1.2 Betrieb eines Auftragsprozesses

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

Übungen zur Softwaretechnik

Übungen zur Softwaretechnik Technische Universität München Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering Markus Pister, Dr. Bernhard Rumpe WS 2002/2003 Lösungsblatt 1 17. Oktober 2002 www4.in.tum.de/~rumpe/se

Mehr

Integrationsmöglichkeiten von E-Procurement-Systemen in inner- und überbetrieblichen Systemen

Integrationsmöglichkeiten von E-Procurement-Systemen in inner- und überbetrieblichen Systemen MKWI 2002 Nürnberg Integrationsmöglichkeiten von E-Procurement-Systemen in inner- und überbetrieblichen Systemen Johannes Gutenberg-Universität, Mainz Peter Loos, Thomas Theling 10.09.2002 Folie 1 Inhalt

Mehr

Abb. 1: Informationsbedarf, -nachfrage und -angebot müssen sich überdecken

Abb. 1: Informationsbedarf, -nachfrage und -angebot müssen sich überdecken Abb. 1: Informationsbedarf, -nachfrage und -angebot müssen sich überdecken Informationsbedarf Informationsangebot Informationsnachfrage Informationsbedarf Informationsnachfrage Informationsangebot Informations-

Mehr

Kollaborative Engineering Communities. Communities. Agenda. MKWI Nürnberg 2002 Prof. Dr.-Ing. Norbert Gronau. Motivation

Kollaborative Engineering Communities. Communities. Agenda. MKWI Nürnberg 2002 Prof. Dr.-Ing. Norbert Gronau. Motivation Kollaborative Engineering MKWI Nürnberg 2002 Prof. Dr.-Ing. Norbert Gronau Agenda Motivation Eigenschaften von Der Produktlebenszyklus Begriff der Kollaborativen Engineering Community Anforderungen an

Mehr

Microsoft Dynamics NAV Technische Details

Microsoft Dynamics NAV Technische Details Microsoft Dynamics NAV Technische Details INHALT Microsoft Dynamics NAV Technische Details........................................ [3] Infrastruktur.............................................. [3] Systemanforderungen.....................................

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

Relationale Datenbanken Datenbankgrundlagen

Relationale Datenbanken Datenbankgrundlagen Datenbanksystem Ein Datenbanksystem (DBS) 1 ist ein System zur elektronischen Datenverwaltung. Die wesentliche Aufgabe eines DBS ist es, große Datenmengen effizient, widerspruchsfrei und dauerhaft zu speichern

Mehr

Umsetzungsalternativen für die kooperative Auftragsabwicklung

Umsetzungsalternativen für die kooperative Auftragsabwicklung Umsetzungsalternativen für die kooperative Auftragsabwicklung Dimitrios Gizanis, Dr. Christine Legner MKWI 2004,, 10.03.2004 Seite 2 Übersicht Zielsetzung der Untersuchung Umsetzungsalternativen der kooperativen

Mehr

Standardsoftware II. Klassifikation Schnittstellen

Standardsoftware II. Klassifikation Schnittstellen Standardsoftware II Schnittstellen zu ERP-Systemen Schnittstellen-1 Klassifikation Schnittstellen datenorientierte funktionale objektorientierte Schnittstellen-2 Was zeichnet eine Schnittstelle aus? Merkmale

Mehr

Wirtschaftsinformatik

Wirtschaftsinformatik Wirtschaftsinformatik Unterrichtsbeispiel: Zusammenfassendes Projekt Lehrplaneinordnung: - Jgst. 9: Nach 2. Kapitel als Zusammenfassung - Jgst. 10: Projektarbeit (ggf. zu lange her?) In jedem Fall stellt

Mehr

Data Warehousing mit Oracle

Data Warehousing mit Oracle Data Warehousing mit Oracle Business Intelligence in der Praxis von Claus Jordan, Dani Schnider, Joachim Wehner, Peter Welker 1. Auflage Hanser München 2011 Verlag C.H. Beck im Internet: www.beck.de ISBN

Mehr

Dokumentenmanagement. DMS Middleware für optimale Systemintegration

Dokumentenmanagement. DMS Middleware für optimale Systemintegration Dokumentenmanagement DMS Middleware für optimale Systemintegration Ausgangssituation Systemlandschaft heute - eine Bestandsaufnahme Heterogene Systeme, eine Vielzahl von Applikationen unterschiedlicher

Mehr

Enterprise Application Integration Erfahrungen aus der Praxis

Enterprise Application Integration Erfahrungen aus der Praxis Enterprise Application Integration Erfahrungen aus der Praxis Teil 1: Begriffe, Anwendungen Tutorial NODs 2002, Wolfgang Keller and Generali 2001, 2002, all rights reserved 1 Überblick Abgrenzung des Begriffes

Mehr

Enterprise Application Integration

Enterprise Application Integration 2008 AGI-Information Management Consultants May be used for personal purporses only or by libraries associated to dandelon.com network. Wolfgang Keller Enterprise Application Integration Erfahrungen aus

Mehr

Integrated Procurement

Integrated Procurement Integrated Procurement Titel des Lernmoduls: Integrated Procurement Themengebiet: New Economy Gliederungspunkt im Curriculum: 2.2.1.3.3 Zum Inhalt: Integrated Procurement als eine Beschaffungsart mit höherer

Mehr

DWH Szenarien. www.syntegris.de

DWH Szenarien. www.syntegris.de DWH Szenarien www.syntegris.de Übersicht Syntegris Unser Synhaus. Alles unter einem Dach! Übersicht Data-Warehouse und BI Projekte und Kompetenzen für skalierbare BI-Systeme. Vom Reporting auf operativen

Mehr

Seminarthemen WS 14/15

Seminarthemen WS 14/15 Dr. Max Mustermann Referat Kommunikation & Marketing Verwaltung Seminarthemen WS 14/15 Präsentation Alexander Schiller, Lars Lewerenz, Dominik Schön Prof. Dr. Bernd Heinrich Lehrstuhl für Wirtschaftsinformatik

Mehr

Liste der Handbücher. Liste der Benutzerhandbücher von MEGA

Liste der Handbücher. Liste der Benutzerhandbücher von MEGA Liste der Handbücher Liste der Benutzerhandbücher von MEGA MEGA 2009 SP4 1. Ausgabe (Juni 2010) Die in diesem Dokument enthaltenen Informationen können jederzeit ohne vorherige Ankündigung geändert werden

Mehr

Matthes & Anthuber Solution Consulting. B2B-Dienstleistungen aus einer Hand

Matthes & Anthuber Solution Consulting. B2B-Dienstleistungen aus einer Hand Matthes & Anthuber Solution Consulting B2B-Dienstleistungen aus einer Hand Komplettlösungen Die Matthes & Anthuber Solution Consulting GmbH bietet im Rahmen ihres Businessto-Business-Angebots (B2B) ein

Mehr

Enterprise Java Beans Einführung

Enterprise Java Beans Einführung Enterprise Java Beans Einführung Vorlesung 8 Ralf Gitzel ralf_gitzel@hotmail.de 1 Themenübersicht Ralf Gitzel ralf_gitzel@hotmail.de 2 Übersicht EJBs im JEE Umfeld Verschiedene Typen von EJBs Von der Javaklasse

Mehr

> BusinessConnect Services > Lösung. ====!" ==Systems= BusinessConnect Services für den integrierten Datenaustausch.

> BusinessConnect Services > Lösung. ====! ==Systems= BusinessConnect Services für den integrierten Datenaustausch. > BusinessConnect Services > Lösung ====!" ==Systems= BusinessConnect Services für den integrierten Datenaustausch. > BusinessConnect Services Das BusinessConnect Center. Die Business Integration Platform.

Mehr