Eine Architektur zur»optimistischen Integration«von KMU-Wertschöpfungsnetzwerken

Transkript

1 Eine Architektur zur»optimistischen Integration«von KMU-Wertschöpfungsnetzwerken Von der Fakultät Konstruktions-, Produktions- und Fahrzeugtechnik der Universität Stuttgart zur Erlangung der Würde eines Doktor-Ingenieurs (Dr.-Ing.) genehmigte Abhandlung Vorgelegt von Dipl.-Phys. Jochen Kokemüller geboren in Alkmaar Hauptberichter: Prof. Dr.-Ing. Dr.-Ing. E.h. Dieter Spath Mitberichter: Prof. Dr.-Ing. Prof. E.h. Dr.-Ing. E.h. Dr. h.c. mult. Engelbert Westkämper Tag der mündlichen Prüfung: 3. November 2011 Institut für Arbeitswissenschaft und Technologiemanagement der Universität Stuttgart, 2011

2 IPA-IAO Forschung und Praxis Berichte aus dem Fraunhofer-Institut für Produktionstechnik und Automatisierung (IPA), Stuttgart, Fraunhofer-Institut für Arbeitswirtschaft und Organisation (IAO), Stuttgart, Institut für Industrielle Fertigung und Fabrikbetrieb (IFF), Universität Stuttgart und Institut für Arbeitswissenschaft und Technologiemanagement (IAT), Universität Stuttgart Herausgeber: Univ.-Prof. Dr.-Ing. Prof. e.h. Dr.-Ing. e.h. Dr. h.c. mult. Engelbert Westkämper und Univ.-Prof. Dr.-Ing. habil. Prof. E.h. mult. Dr. h.c. mult. Hans-Jörg Bullinger und Univ.-Prof. Dr.-Ing. Dr.-Ing. E.h. Dieter Spath

3 Jochen Kokemüller Eine Architektur zur optimistischen Integration von KMU-Wertschöpfungsnetzwerken Nr. 514 Fachverlag Heimsheim

4 Dr.-Ing. Dipl.-Phys. Jochen Kokemüller Fraunhofer-Institut für Arbeitswirtschaft und Organisation (IAO), Stuttgart Univ.-Prof. Dr.-Ing. Prof. e.h. Dr.-Ing. e.h. Dr. h.c. mult. Engelbert Westkämper ord. Professor an der Universität Stuttgart Fraunhofer-Institut für Produktionstechnik und Automatisierung (IPA), Stuttgart Univ.-Prof. Dr.-Ing. habil. Prof. E.h. mult. Dr. h.c. mult. Hans-Jörg Bullinger ord. Professor an der Universität Stuttgart Präsident der Fraunhofer-Gesellschaft, München Univ.-Prof. Dr.-Ing. Dr.-Ing. E.h. Dieter Spath ord. Professor an der Universität Stuttgart Fraunhofer-Institut für Arbeitswirtschaft und Organisation (IAO), Stuttgart D 93 ISBN Jost Jetter Verlag, Heimsheim Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik Deutschland vom 9. September 1965 in der jeweils gültigen Fassung zulässig. Sie ist grundsätzlich vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des Urheberrechtsgesetzes. Jost-Jetter Verlag, Heimsheim Printed in Germany. Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften. Sollte in diesem Werk direkt oder indirekt auf Gesetze, Vorschriften oder Richtlinien (z. B. DIN, VDI, VDE) Bezug genommen oder aus ihnen zitiert worden sein, so kann der Verlag keine Gewähr für die Richtigkeit, Vollständigkeit oder Aktualität übernehmen. Es empfiehlt sich, gegebenenfalls für die eigenen Arbeiten die vollständigen Vorschriften oder Richtlinien in der jeweils gültigen Fassung hinzuzuziehen. Druck: printsystem GmbH, Heimsheim

5 Geleitwort der Herausgeber Über den Erfolg und das Bestehen von Unternehmen in einer marktwirtschaftlichen Ordnung entscheidet letztendlich der Absatzmarkt. Das bedeutet, möglichst frühzeitig absatz marktorientierte Anforderungen sowie deren Veränderungen zu erkennen und darauf zu reagieren. Neue Technologien und Werkstoffe ermöglichen neue Produkte und eröffnen neue Märkte. Die neuen Produktions- und Informationstechnologien verwandeln signifikant und nachhaltig unsere industrielle Arbeitswelt. Politische und gesellschaftliche Ver ände rungen signalisieren und begleiten dabei einen Wertewandel, der auch in unseren Indu striebetrieben deutlichen Niederschlag findet. Die Aufgaben des Produktionsmanagements sind vielfältiger und anspruchsvoller ge - worden. Die Integration des europäischen Marktes, die Globalisierung vieler Industrien, die zunehmende Innovationsgeschwindigkeit, die Entwicklung zur Freizeitgesellschaft und die übergreifenden ökologischen und sozialen Probleme, zu deren Lösung die Wirtschaft ihren Beitrag leisten muss, erfordern von den Führungskräften erweiterte Perspektiven und Antworten, die über den Fokus traditionellen Produktionsmanagements deutlich hinausgehen. Neue Formen der Arbeitsorganisation im indirekten und direkten Bereich sind heute schon feste Bestandteile innovativer Unternehmen. Die Entkopplung der Arbeitszeit von der Betriebszeit, integrierte Planungsansätze sowie der Aufbau dezentraler Strukturen sind nur einige der Konzepte, welche die aktuellen Entwicklungsrichtungen kennzeichnen. Erfreulich ist der Trend, immer mehr den Menschen in den Mittelpunkt der Arbeitsgestaltung zu stellen - die traditionell eher technokratisch akzentuierten Ansätze weichen einer stärkeren Human- und Organisationsorientierung. Qualifizierungsprogramme, Training und andere Formen der Mitarbeiterentwicklung gewinnen als Diffe renzierungsmerkmal und als Zukunftsinvestition in Human Resources an strategischer Bedeutung. Von wissenschaftlicher Seite muss dieses Bemühen durch die Entwicklung von Methoden und Vorgehensweisen zur systematischen Analyse und Verbesserung des Systems Produktionsbetrieb einschließlich der erforderlichen Dienstleistungsfunktionen unterstützt werden. Die Ingenieure sind hier gefordert, in enger Zusammenarbeit mit anderen Disziplinen, z. B. der Informatik, der Wirtschaftswissenschaften und der Arbeitswissenschaft, Lösungen zu erarbeiten, die den veränderten Randbedingungen Rechnung tragen. Die von den Herausgebern langjährig geleiteten Institute, das - Fraunhofer-Institut für Produktionstechnik und Automatisierung (IPA), - Fraunhofer-Institut für Arbeitswirtschaft und Organisation (IAO), - Institut für Industrielle Fertigung und Fabrikbetrieb (IFF), Universität Stuttgart, - Institut für Arbeitswissenschaft und Technologiemanagement (IAT), Universität Stuttgart

6 arbeiten in grundlegender und angewandter Forschung intensiv an den oben aufgezeigten Entwicklungen mit. Die Ausstattung der Labors und die Qualifikation der Mitarbeiter haben bereits in der Vergangenheit zu Forschungsergebnissen geführt, die für die Praxis von großem Wert waren. Zur Umsetzung gewonnener Erkenntnisse wird die Schriftenreihe IPA-IAO - Forschung und Praxis herausgegeben. Der vorliegende Band setzt diese Reihe fort. Eine Übersicht über bisher erschienene Titel wird am Schluss dieses Buches gegeben. Dem Verfasser sei für die geleistete Arbeit gedankt, dem Jost Jetter Verlag für die Aufnahme dieser Schriftenreihe in seine Angebotspalette und der Druckerei für saubere und zügige Ausführung. Möge das Buch von der Fachwelt gut aufgenommen werden. Engelbert Westkämper Hans-Jörg Bullinger Dieter Spath

7 Vorwort Die vorliegende Arbeit entstand während meiner Tätigkeit als wissenschaftlicher Mitarbeiter am Institut für Arbeitswissenschaft und Technologiemanagement (IAT) der Universität Stuttgart und am Fraunhofer-Institut für Arbeitswirtschaft und Organisation (IAO) in Stuttgart. Herrn Prof. Dr.-Ing. Dr.-Ing. E.h. Dieter Spath, Leiter des Instituts für Arbeitswissenschaft und Technologiemanagement der Universität Stuttgart sowie des Fraunhofer-Instituts für Arbeitswirtschaft und Organisation, danke ich für die wohlwollende Förderung meiner Arbeit und die Übernahme des Hauptberichts. Ebenfalls gilt mein Dank Herrn Prof. Dr.-Ing. Prof. E.h. Dr.-Ing. E.h. Dr. h.c. mult. Engelbert Westkämper, Leiter des Instituts für Industrielle Fertigung und Fabrikbetrieb (IFF) der Universität Stuttgart sowie des Fraunhofer-Instituts für Produktionstechnik und Automatisierung (IPA), für die Übernahme des Mitberichts. Für die sehr gute Betreuung der Arbeit möchte ich mich ganz besonders bei Frau Prof. Dr.- Ing. habil. Anette Weisbecker, Institutsdirektorin am Fraunhofer-Institut für Arbeitswirtschaft und Organisation, bedanken, die meine Arbeiten immer unterstützt hat und mir jederzeit mit wertvollen Hinweisen sowie konstruktiver Kritik zur Seite stand. Ich bedanke mich ebenfalls bei allen Kollegen, die mich durch intensive Diskussionen in der Erstellung der Dissertation unterstützt haben. Mein besonderer Dank gilt Herrn Dr. Wolf Engelbach. Insbesondere möchte ich mich auch bei allen Studenten bedanken, welche als wissenschaftliche Hilfskräfte, im Rahmen ihrer Bachelorarbeiten oder als Teilnehmer der Studienprojekte zum Gelingen der Arbeit beigetragen haben. Stellvertretend sei hier Herrn Florian Haupt und Herrn Tobias Droste gedankt. Mein besonderer Dank gilt meinen Eltern, die mich immer unterstützt haben und somit den Grundstein für meinen beruflichen und wissenschaftlichen Werdegang gelegt haben. Auch meinem Bruder Stefan Kokemüller danke ich für seine Unterstützung. Meiner Frau Viviana, die durch ihr selbstloses Verständnis und ihre stetige Motivation auf ganz besondere Weise zum Gelingen dieser Arbeit beigetragen hat und dabei auf viel gemeinsame Zeit verzichten musste, gilt mein Dank von ganzem Herzen. Ihr und meiner Tochter Daniela widme ich diese Arbeit. Stuttgart, im November 2011 Jochen Kokemüller

8

9 Inhalt 1 Einleitung Ausgangssituation Handlungsbedarf und Problemstellung Anwendungsdomäne Handelsvertretungen Barrieren Zielsetzung Aufbau der Arbeit Grundlagen, Vorarbeiten und Stand der Technik Begriffsbildung Information Datenschemata und -modelle Kommunikation Softwarearchitektur Integration von Informationssystemen Technische Integrationsperspektive Systemtheoretische Integrationsperspektive Strategische Integrationsperspektive Organisatorische Integrationsperspektive Zusammenfassende Bewertung Verteilung, Autonomie und Heterogenität Ursachen der Komplexität in der Informationsintegration Zusammenfassende Bewertung Integrationsebenen Vergleichende Darstellung Zusammenfassende Bewertung Integrationstopologien Chaotische Integration Hub-and-Spoke Bus Peer-to-Peer Zusammenfassende Bewertung Stammdatenmanagement Informationsqualität Verortung des Stammdatenmanagement Architekturen des Stammdatenmanagements Erwartung von Anwendern an Stammdatenmanagementsysteme Stammdatenmanagementsysteme Zusammenfassende Bewertung Virtuelle und materialisierende Integration Vergleichende Darstellung Zusammenfassende Bewertung...62

10 Replikation Pessimistische Replikation Optimistische Replikation Abgrenzung zu Transaktionen Integrationsparadigmen in Unternehmen Enterprise Application Integration (EAI) Service-orientierte Architekturen (SOA) Electronic Data Interchange (EDI) Standards Zusammenfassende Bewertung Ansatz und Anforderungen Defizite Ansatz Anforderungen Eine Architektur zur Integration von KMU-Wertschöpfungsnetzwerken Konnektor Objekte Informationsfluss Adapter VIANA Framework Schematische Ebenen im Integrationsprozess Natives Schema Lokales Schema Konzeptionelles Schema Exportiertes Schema Transformationen Benutzungsschnittstellen Operative Benutzungsschnittstelle Administrationsoberfläche Optimistische Integration Definitionen Objektidentifikation Ausführungspläne Konzeption der Konfliktbehandlung Intrinsische Konflikte Extrinsische Konflikte Realisierung der Integrationsarchitektur VIANA Softwaretechnische Komponenten Komponenten der Adapter Komponenten des VIANA Frameworks Implementierung des Integrationsframeworks Reduktion der Heterogenitäten Konfliktbehandlung

11 6.2.3 Kennzahlerfassung Implementierung von Adaptern Benutzungsschnittstellen Administrative Benutzungsschnittstelle Operative Benutzungsschnittstelle Einsatz der Integrationsarchitektur CAS genesisworld e-pro Mediando Handelsvertreterplattform M3V Evaluation Überprüfung der Anforderungserfüllung Klassifikation der optimistischen Integration Effizienz des Ansatzes Versuchsaufbau Versuchsdurchführung Evaluation der Integrationsfunktion Bewertung der Ergebnisse Ausblick Zusammenfassung Summary Anhang A Abkürzungsverzeichnis Anhang B Glossar Anhang C Global Data Synchronisation Network Anhang D Implementierungsschemata Anhang E Implementierung der Komponenten Anhang F Implementierung des Integrationsprozesses Anhang F.1 Ausgehende Operation Anhang F.2 Eingehende Operation Anhang F.3 Pulling Service Anhang G Web Service-Schnittstellen Anhang H Gemessene Methodenlaufzeiten Anhang I Literaturverzeichnis Platzhalter 11

12 12

13 Abbildungsverzeichnis Abbildung 1.1: Histogramm der Anzahl vertretener Lieferanten Abbildung 1.2: Informationsbedarfe von Handelsvertretungen Abbildung 1.3: Anwendungsszenario Abbildung 1.4: Struktur der Arbeit Abbildung 2.1: Überblick zum Stand der Technik Abbildung 2.2:»Wissenspyramide«in Anlehnung an (Wolf et al., 1999; Schlegel, 2009) Abbildung 2.3: Information ist»modell-wovon-wofür-für-wen«(steinmüller, 1993) Abbildung 2.4: Strategisches Modell der Integration nach Wainwright und Waring (2004) Abbildung 2.5: Arten der systemtheoretischen Beziehungen nach Das (1992) Abbildung 2.6: Barrieren der B2B IT-Integration für KMU nach Stockdale und Standing (2004) Abbildung 2.7: Integrationsebenen Abbildung 2.8: Ablauf des Stammdatenaustauschs im GDSN Abbildung 2.9: Beziehungen zwischen betrieblichen Datenkategorien Abbildung 2.10: Handlungsfelder des Stammdatenmanagements nach Österle und Winter (2003) Abbildung 2.11: Architekturvarianten im Stammdatenmanagement Abbildung 2.12: Anzahl unternehmensintern eingesetzter Systemklassen Abbildung 2.13: Ablauf des EDIFACT Datenaustausches Abbildung 4.1: Konzept zur Umsetzung des Integrationsszenarios Abbildung 4.2: Spezialfall einer Hub-and-Spoke Architektur Abbildung 4.3 Informationsfluss Abbildung 4.4: Systemüberblick mit Integrationsvarianten und Informationsfluss Abbildung 4.5: Funktionalitäten des VIANA Frameworks Abbildung 4.6: Relevante schematische Ebenen Abbildung 4.7: Umsetzung des konzeptionellen Schemas Abbildung 4.8: Transformationen zwischen exportierten Schemata Abbildung 5.1: Verwendung von IDs in schematischen Ebenen Abbildung 5.2: Lineare Änderungssequenz Abbildung 5.3: Sich aufteilende und zusammengeführte Operation Abbildung 5.4: Nicht terminierender Zyklus Abbildung 5.5: Segmentierter Graph Abbildung 5.6: Widersprüchliche Operationen Abbildung 5.7: Zeiten in widersprüchlichen Operationen Abbildung 5.8: Operation auf lokal nicht existentem Objekt Abbildung 6.1: Funktionale Komponenten eines Konnektors Abbildung 6.2: Informationsfluss der XQuery Update Erstellung Abbildung 6.3: Eclipse Editor zur Topologiekonfiguration Abbildung 7.1: Szenario der heterogenen Evaluation Abbildung 7.2: Integration des CRM-Systems CAS genesisworld Abbildung 7.3: Integration des PIM-Systems e-pro Mediando Abbildung 8.1: Relaxationszeit für Topologien bestehend aus 10 Peers Abbildung 8.2: Relaxationszeit pro Operation für Topologien bestehend aus 10 Peers Abbildung 8.3: Relaxationszeit im skalenfreien Netzwerk

14 Abbildung 8.4: Nebenläufigkeit in vollständig vernetzter Topologie Abbildung 8.5: Normierte Nebenläufigkeit in vollständig vernetzter Topologie Abbildung D.1: Implementierungsschemata in VIANA (UML-Klassendiagramm) Abbildung E.2: Implementierte Komponenten Abbildung E.3: Für XML-Verarbeitung relevante Klassen (UML-Klassendiagramm) Abbildung F.4: Web Service-Schnittstellen zur Integration mit benachbarten Peers Abbildung F.5: Programmablauf über schematische Ebenen Abbildung F.6: An der Verarbeitung eingehender Operationen beteiligte Klassen (UML-Klassendiagramm)

15 Tabellenverzeichnis Tabelle 1.1: KMU-Definition (Europäische Union, 2003) Tabelle 1.2: Größenstruktur der Handelsvermittlungen in 2006 (ifo Institut für Wirtschaftsforschung, 2008) Tabelle 1.3: Barrieren der betriebsübergreifenden IT-Integration Tabelle 2.1: Datenmodelle im Vergleich Tabelle 2.2: Vergleich synchroner und asynchroner Kommunikation Tabelle 2.3: Autonomiearten (Leser und Naumann, 2007) Tabelle 2.4: Heterogenitätsarten (Leser und Naumann, 2007) Tabelle 2.5: Charakteristika von Integrationsprojekten in Abhängigkeit von der verwendeten Integrationsebene 42 Tabelle 2.6: Gegenüberstellung verbreiteter Integrationstopologien Tabelle 2.7: Informationsqualitätsdimensionen nach Wang und Strong (1996) und Rohweder et al. (2008) Tabelle 2.8: Maßnahmen zur Erhöhung der Informationsqualität Tabelle 2.9: Charakteristiken betrieblicher Datenkategorien Tabelle 2.10: Gegenüberstellung der Architekturen des Stammdatenmanagements Tabelle 2.11: Untersuchte Stammdatenmanagementsysteme Tabelle 2.12: Vergleich kommerzieller Stammdatenmanagementsysteme Tabelle 2.13: Gegenüberstellung virtueller und materialisierenden Integration Tabelle 2.14: Morphologischer Kasten der Freiheitsgrade von Algorithmen zur optimistischen Replikation und ihre Realisierungsmöglichkeiten in KMU-Wertschöpfungsnetzwerken Tabelle 2.15: ACID-Anforderungen (vgl. Kemper und Eickler, 2009) Tabelle 2.16: Hemmnisse der EDI Umsetzung nach Teo et al. (2006) Tabelle 2.17: Integrationsparadigmen im betrieblichen Einsatz Tabelle 3.1: Anforderungen an das zu entwickelnde System Tabelle 4.1: Adaptervarianten Tabelle 5.1: Exemplarische Mapping-Tabelle (Peer 1) Tabelle 5.2: Exemplarische Mapping-Tabelle (Peer 2) Tabelle 6.1: Eingesetzte Technologien Tabelle 6.2: Heterogenitätsdimensionen Tabelle 6.3: Lokale Metadaten einer Operation Tabelle 6.4: Metadaten eines lokalen Objektes Tabelle 6.5: Erfasste Operationskennzahlen Tabelle 6.6: Erfasste Methodenkennzahlen Tabelle 6.7: Realisierung der schematischen Ebenen im Adapter für relationale Datenbanksysteme Tabelle 8.1: Evaluation der Autonomieerhaltung Tabelle 8.2: Anforderungserfüllung der Anforderungsgruppen Tabelle 8.3: Morphologischer Kasten zur Klassifikation der optimistischen Integration nach Saito und Shapiro (2005) Tabelle 8.4: Evaluation der Integrationsfunktion nach Themistocleous et al. (2004) Tabelle F.1: Propagierte Metadaten einer Operation Tabelle G.2: Web Service-Schnittstelle für Peer-Kommunikation Tabelle G.3: Web Service-Schnittstelle für Auswertung von Kennzahlen Tabelle G.4: Web Service-Schnittstelle für die Konfiguration Platzhalte 15

16

17 1 Einleitung 1.1 Ausgangssituation Überbetriebliche Kooperation, entlang der Wertschöpfungsketten oder in Partnernetzwerken, gehört zur täglichen Praxis vieler Unternehmen. Insbesondere kleine und mittlere Unternehmen (KMU) sind auf Kooperationen angewiesen. Diese können sich auf einzelne Projekte beschränken oder strategisch langfristiger Natur sein. Für letzteres hat sich der Begriff der Wertschöpfungsnetzwerke etabliert. Kennzeichnend ist der Austausch tangibler und intangibler Werte innerhalb einer Gruppe von Unternehmen oder Personen (Allee, 2003). So werden etwa Kataloge zur Verfügung gestellt oder Aufträge erteilt. Traditionell geschieht dies zwischenmenschlich und damit manuell, d.h. in Gesprächen, Telefonaten, Geschäftsbriefen, etc. Durch den Einsatz von betrieblichen Informationssystemen, etwa für die Warenwirtschaft, und der damit verbundenen Automatisierung interner Prozesse wurde es möglich, die Kooperation zu automatisieren. Dies verspricht bspw. eine höhere Skalierbarkeit, kürzere Bearbeitungszeiten oder eine höhere Fehlerfreiheit der ausgetauschten Informationen. Hierfür müssen die Informationssysteme der Kooperationspartner miteinander kooperieren. Dies ist insbesondere dann erstrebenswert, wenn die Kooperation strategisch langfristig ausgelegt ist (König et al., 1996; Irani et al., 2003; Gronau, 2004; Kurbel, 2011). Die Integration von Informationssystemen wird erreicht, indem über spezielle Schnittstellen dieser Systeme Daten ausgetauscht werden. Austauschformate der Daten, Interaktionsmuster und technische Schnittstellen müssen zu diesem Zweck spezifiziert werden (Leser und Naumann, 2007). Es hat sich gezeigt, dass IT-Integration aufgrund dessen aufwändig ist (Haas, 2006). Daher wurden zahlreiche Technologien entwickelt, dem zu begegnen 1. Entsprechend ihrem Einsatzzweck optimieren diese Integrationstechnologien unterschiedliche Dimensionen. So kann eine Homogenität der Prozesse, konsolidierte Systemlandschaften, geringe Redundanzen, hohe Aktualität, hohe Zuverlässigkeit u.v.m. angestrebt werden. Viele Dimensionen können gut durch zentralisierte Ansätze erfüllt werden. Hierbei steigen in aller Regel jedoch die Komplexität und die Abhängigkeit von einer zentralen Komponente. Architekturen, die zentralisierte Ansätze umsetzen, sind Service-orientierte Architekturen (SOA) und Enterprise Application Integration (EAI). Da sich die Abbildung abweichender Informationsdarstellungen aufeinander aufwändig gestaltet (Bernstein und Haas, 2008; Laudon et al., 2010), wurden weiterhin Standards für den Informationsaustausch entwickelt, bspw. UN/EDIFACT (UN/CEFACT, 1987). Durch den Versuch, möglichst alle Anwendungsfälle abzubilden, wurde UN/EDIFACT komplex, was letztendlich dazu geführt hat, dass nur Teile des Standards eingesetzt werden und auch dies noch aufwändig in der Realisierung ist (Laudon et al., 2010). Weiterhin besteht hierbei die Herausforderung, dass eine Einigung erzielt werden muss, welche Bestandteile des Standards 1 Siehe Abschnitt 2.9

18 1 Einleitung weggelassen und welche beibehalten werden. Häufig ist dies unmöglich, da kein Partner hierfür die Verantwortung übernehmen möchte und auch nicht a-priori klar ist, das die Möglichkeit für einen gemeinsamen Standard existiert (Halevy et al., 2006). Wertschöpfungsnetzwerke sind insbesondere für KMU vorteilhaft (Ceglie und Dini, 1999). Allerdings wird IT-Integration bei diesen Unternehmen selten durchgeführt. Gründe hierfür basieren auf äußeren Einflüssen oder sind technischer sowie organisatorischer Natur (Teo et al., 2006). So wurden etablierte Integrationsarchitekturen entweder vor dem Hintergrund einer technischen Verbesserung oder für große Unternehmen entwickelt. Integration wird daher meist nur in Kooperationen mit großen Unternehmen realisiert, da diese die Marktmacht besitzen, Integration zu erzwingen. Die verwendeten Technologien entsprechen nicht den Anforderungen von in Wertschöpfungsnetzwerken organisierten KMU. Allerdings sind 99,7% der Unternehmen in Deutschland KMU (Institut für Mittelstandsforschung IfM, 2009). Die fehlende IT-Infrastruktur, welche IT-Integration für KMU praktikabel sein ließe, ist also ein Defizit, welches ein hohes betriebs- und bedingt durch dessen Skalierung volkswirtschaftliches Potential hat. 1.2 Handlungsbedarf und Problemstellung Der Begriff KMU-Wertschöpfungsnetzwerk wird im Folgenden in Anlehnung an die Definition von Allee (2003) verwendet. Er bezeichnet die strategische Kooperation von Individuen, Gruppen oder Organisationen welche sowohl tangible als auch intangible Werte austauscht. Tangible Werte bezeichnen hierbei jegliche Art von Gütern, Produkten und Dienstleistungen. Intangible Werte bezeichnet Wissen und Vorteile, welche Wertschöpfungspartnern zur Verfügung gestellt werden. Diese Definition der Wertschöpfungsnetzwerke grenzt sich daher auch von sogenannten virtuellen Unternehmen ab, welche explizit temporär ausgelegt sind (Martinez et al., 2001). Größenklasse Anzahl vollzeitäquivalente Mitarbeiter Jahresumsatz oder Jahresbilanzsumme Mittleres Unternehmen < Mio. EUR (Umsatz) oder 43 Mio. EUR (Bilanz) Kleines Unternehmen < Mio. EUR Kleinstunternehmen < 10 2 Mio. EUR Tabelle 1.1: KMU-Definition (Europäische Union, 2003) Gemäß der durch die EU-Kommission veröffentlichten Definition (Europäische Union, 2003) werden kleine und mittlere Unternehmen (KMU) in dieser Arbeit als Unternehmen mit weniger als 250 vollzeitäquivalenten Mitarbeitern und einen Jahresumsatz von weniger als 50 Mio. EUR definiert (Tabelle 1.1) Anwendungsdomäne Handelsvertretungen Die Branche der Handelsvermittlungen und vertretungen kennzeichnet sich durch Unternehmen kleiner Größe. Sie vertreten Lieferanten, welche, häufig aufgrund ihrer lediglich 18

19 1.2 Handlungsbedarf und Problemstellung mittleren Größe, keine eigene Vertriebsstruktur, zumindest in dem durch die Handelsvermittlung und vertetungen betreuten Markt, unterhalten. Zusätzlich kollaborieren Handelsvermittler und vertreter mit anderen kleinen Unternehmen zwecks gemeinsamer Leistungserbringung. Beide Arten der Kollaboration sind durch ihre strategische Ausrichtung gekennzeichnet, welche sie für die IT-Integration prädestiniert. Daher werden diese intensiv in KMU-Wertschöpfungsnetzwerken kollaborierenden Unternehmen als Anwendungsdomäne in der vorliegenden Arbeit besonders betrachtet. Nach dem ifo Institut für Wirtschaftsforschung (2008) weist»die Umsatzsteuerstatistik für das Jahr Unternehmen mit wirtschaftlichem Schwerpunkt in der Handelsvermittlung aus (Tabelle 1.2). Sie erzielten eine ionen für vermittelte Warenumsätze und Kostenerstattungen vertretener Unternehmen, die im Rahmen des Fremdgeschäfts anfallen, ebenso enthalten wie Umsätze aus Eigengeschäften, bei denen sich die Handelsvertreter als Großhändler betätigen. Generell sind Handelsvertreter in den verschiedenen Branchen des Produktionsverbindungshandels sowie des Konsumgütergroßhandels aktiv. Üblicherweise handelt es sich bei den Handelsvermittlern eher um kleinere Firmen. Der Umsatzsteuerstatistik zufolge erzielen knapp vier Fünftel der Unternehmen einen Tabelle 1.2). Ihr Umsatzanteil beläuft sich auf 13,7%. Auf der anderen Seite gibt es aber auch 12 Handelsvermittlungen mit Umsätzen von 100 Mill. oder des Großhandels handeln.«handelsvermittlungen und -vertretungen verantworten in Deutschland einen jährlichen Umsatz von 180 Mrd. Euro für ihre Auftraggeber. Sie haben einen Einschaltungsgrad von 30 Prozent in deutsche Warenströme (Centralvereinigung Deutscher Wirtschaftsverbände für Handelsvermittlung und Vertrieb CDH, 2009). Um die genaue Situation von Handelsvermittlungen und -vertretungen zu erfassen, wurde ein Fragebogen an unabhängige Handelsvermittler und -vertreter in Baden-Württemberg gesendet. Insgesamt wurden 53 Fragebögen ausgefüllt zurückgesendet. Dies entspricht einer Rücklaufquote von 3,3%. Obwohl die Aussagen aus dieser Studie (Kett et al., 2008a) daher nicht verallgemeinert werden können, reichen sie aus, um die Zielgruppe zu charakterisieren. 19

20 1 Einleitung Größenklasse Unternehmen (Anteile in %) Umsatz (Anteile in %) Über ,1 2, ,9 3, ,7 7, ,7 7, Mio. 6,1 9,6 1 Mio. - 2 Mio. 3,5 11,1 2 Mio. - 5 Mio. 1,4 8,9 5 Mio Mio. 0,3 4,5 10 Mio Mio. 0,2 5,7 25 Mio Mio. 0,1 4,4 50 Mio Mio. < 0,1 4,8 100 Mio Mio. < 0,1 3,2 250 Mio. und mehr < 0,1 26,4 Quelle: Statistisches Bundesamt, Umsatzsteuerstatistik Tabelle 1.2: Größenstruktur der Handelsvermittlungen in 2006 (ifo Institut für Wirtschaftsforschung, 2008) Zentrale Ergebnisse sind wie folgt: Die befragten Unternehmen verfügen über durchschnittlich 4,7 Angestellte. Dies bestätigt obige Zahlen. Sie können daher als Kleinstunternehmen klassifiziert werden. Im Außendienst sind bei 96% der befragten Unternehmen weniger als 5 Personen beschäftigt, der Durchschnitt liegt hier bei 1,7 Personen. Durchschnittlich sind also 3 Personen im Backoffice tätig, um Vertriebsaktivitäten vor- und nachzubereiten. Da diese Aktivitäten nicht das Kerngeschäft von Handelsvermittlungen und -vertretungen sind, kann die Produktivität dieser Unternehmen durch eine Prozessunterstützung signifikant erhöht werden (Buehrer et al., 2005). Weiterhin sind 93% für mehr als einen Lieferanten tätig. Tatsächlich verfügen 83% der Handelsvertretungen und -vermittlungen über Geschäftsbeziehungen zu zwei bis zehn Lieferanten. Der Durchschnitt liegt hier bei 6,7 Lieferanten mit einer Standardabweichung von 9,2 (Abbildung 1.1). Auch die Lieferanten sind in der Regel Unternehmen mittlere Größe, die sich aufgrund ihrer Größe auf ihre Kernkompetenz, meistens die Produktion, konzentrieren und sich dementsprechend für den Vertrieb externe Unterstützung suchen. Jedoch sind Handelsvertreter nicht nur als reine Vertriebskräfte aktiv, sondern versuchen ihren Kunden vollständige Lösungen zu verkaufen. Aufgrund der hierfür notwendigen Expertise arbeiten Handelsvertreter eng mit anderen Unternehmen in KMU-Wertschöpfungsnetzwerken zusammen und kaufen notwendige Dienstleistungen zu. Beispiel 1: Die Handelsvertretung Eike Koch Projektberatung verkauft unter anderem an große deutsche Einzelhändler Pfannen. Eike Koch Projektberatung nimmt hierfür die genauen Anforderungen des Kunden (Einzelhändlers) auf und beauftragt die verbundenen Tätigkeiten wie Produzenten, Verpackungsdesigner oder Logistiker. 20

21 1.2 Handlungsbedarf und Problemstellung Mittelwert = 6,71 Std.-Abw. = 9,164 N = 52 Häufigkeit Anzahl Lieferanten Abbildung 1.1: Histogramm der Anzahl vertretener Lieferanten Die strategische Ausrichtung der Geschäftspartnerbeziehung wird deutlich in ihrer geringen Volatilität von ungefähr einer neuen oder beendeten Geschäftsbeziehung pro Jahr (Walker und Barnes, 2005). Nach Themistocleous et al. (2004) werden Unternehmungen daher nicht länger als eigenständig betrachtet werden können, sondern nur im Kontext ihres Wertschöpfungsnetzwerkes etwa in ihrer Verbindung mit Herstellern oder Logistikern. Die meisten Handelsvertreter und -vermittler setzen Informationssysteme ein. und Office-Anwendungen haben sich in der Breite durchgesetzt. Allerdings setzen nur 56% ein System zur Kontaktverwaltung, 31% IT-Systeme für die Buchhaltung und nur 15% ein ERP- System ein. Von einer weiter zunehmenden Verwendung von IT-Systemen kann ausgegangen werden (Leek et al., 2003). Interessant ist, dass 47% der Befragten angaben, dass sie über schlechte oder sehr schlechte IT-Kenntnisse verfügen, gleichzeitig jedoch selbständig ihre IT- Systeme administrieren (Kokemüller und Roßnagel, 2011). Der Kernprozess von Handelsvertretungen und -vermittlungen ist der in Abbildung 1.2 dargestellte Verkaufsprozess. Er beginnt mit der Besuchsvorbereitung. Hierbei wird auf Informationen vorangegangener Kontakte mit dem Kunden zugegriffen. Abgerufen werden vorherige Bestellungen und Besuchsberichte. Während eines Besuchstermins werden Produkte und Dienstleistungen mehrerer Lieferanten vorgestellt, dokumentiert wird dies in der Nachbearbeitung durch transaktionale Dokumente 2 und Besuchsberichte. Besuchsberichte dokumentieren die Tätigkeit einer Handelsvermittlung (Holland und Naudé, 2004). Sie zu erstellen ist in Deutschland gesetzlich vorgeschrieben. 2 Bestellungen, Angebotsanfragen, Angebote, etc. 21

22 1 Einleitung Allerdings sind Handelsvermittlungen und -vertretungen nicht ausschließlich im Vertrieb tätig, sondern beteiligen sich auch aktiv in Projekten bspw. zur modularen Produktentwicklung (Spath und Koch, 2007). Hierfür kooperieren sie in Wertschöpfungsnetzwerken in der Regel mit weiteren KMUs, bspw. mit Logistikpartnern oder Verpackungsdesignern. Die größten Schwachstellen dieser Prozesse sind (Kett et al., 2008b; Kett et al., 2008a): Hoher manueller Aufwand in der Verwaltung von Informationen und notwendige Informationen sind nicht zur richtigen Zeit am notwendigen Ort verfügbar. Durch den automatisierten Austausch von Informationen kann diesen Aspekten begegnet werden. Denn hierdurch wird der durch Medienbrüche bedingte manuelle Aufwand hinfällig. Ferner werden Informationen, die in den Informationssystemen der Lieferanten verfügbar sind, für Handelsvermittlungen und -vertretungen verfügbar. Die Integration der Informationssysteme von Handelsvermittlungen und -vertretungen mit denen ihrer Lieferanten ist daher ein Ansatz, um Prozessverbesserungen zu realisieren (Merritt und Newell, 2001; Kett et al., 2009). Allerdings ist die Verwendung von IT-Integration durch KMU nur gering (Chau und Hui, 2001). Das betrachtete Anwendungsszenario ist daher die überbetriebliche Integration zwischen kleinen und mittleren Unternehmen sowohl entlang der Wertschöpfungskette, als auch in Wertschöpfungsnetzwerken (Abbildung 1.3). Hierbei ist zu beachten, dass Lieferanten, Handelsvertreter und Netzwerkpartner miteinander kommunizieren und hierfür potentiell mehrere Systeme einsetzen. Stammdaten: Kunde Produkte und Dienstleistungen Prozess: Besuchsvorbereitung Besuchstermin Besuchsnachbereitung Transaktionale Dokumente Transaktionale Daten: Besuchsberichte Besuchsberichte Transaktionale Dokumente : Informationsprodukt Abbildung 1.2: Informationsbedarfe von Handelsvertretungen 22

23 1.2 Handlungsbedarf und Problemstellung Lieferant Handelsvertretung Netzwerkpartner Lieferant Organisation Handelsvertretung Kooperationsbeziehung Netzwerkpartner Netzwerkpartner Informationssystem Informationssystem Informationssystem Informationssystem Informationssystem Informationssystem Informationssystem Informationssystem Abbildung 1.3: Anwendungsszenario Barrieren Eine Betrachtung der Literatur offenbart Barrieren der IT-Integration innerhalb von KMU- Wertschöpfungsnetzwerken. Die Kategorisierung der Barrieren erfolgt in der Literatur nicht einheitlich. So unterscheiden Chwelos et al. (2001) zwischen äußerem Druck, wahrgenommenen Vorteilen und der Fähigkeit zur Umsetzung. Teo et al. (2006) hingegen führen eine Strukturierung in organisatorische, technische und durch die Umgebung bedingte Faktoren ein. Da dies eine klarere Verortung der Handlungsfelder ermöglicht, werden diese Bereiche hier aufgegriffen. Tabelle 1.3 untergliedert diese in Kategorien und benennt zu diesen Barrieren aus der Literatur. Da die Einflüsse der Umgebung durch eine Technologie kaum beherrschbar sind, müssen vor allem die organisatorischen und technischen Barrieren adressiert werden. Durch ihre häufige Nennung in der Literatur sind vier Barrieren als besonders wichtig zu erachten: Auch wenn Kosten in ihrer Abwägung zum erzielbaren Nutzen bewerten werden müssen, so sind hohe erwartete Kosten für die IT-Integration die am häufigsten genannte Barriere. Gerade für in Wertschöpfungsnetzwerken organisierte KMU mit vergleichsweise geringen liquiden Mittel ist dies daher besonders zu adressieren. Die geringe technische und wirtschaftliche Expertise in Bezug auf IT-Integration ist ein Hemmnis, sofern es nicht durch geeignete Dienstleistungsangebote aufgefangen wird. Da diese nicht in ausreichendem Maße angeboten werden, ist das fehlende Dienstleistungsangebot für KMU-Wertschöpfungsnetzwerk eine hohe Barriere (Lawson et al., 2003). Als große Barriere zeigt sich auch die unpassende Struktur einer IT- Integrationsarchitektur für die sie einsetzende Organisation. Für KMU-Wertschöpfungsnetzwerke bedarf es daher einer IT-Integrationsarchitektur, welche in ihrer Dezentralität die des Wertschöpfungsnetzwerkes reflektiert. 23

24 1 Einleitung Die fehlende Unterstützung von Legacy-Systemen bedeutet einen hohen Aufwand in der Realisierung der Integration (Chong, 2006), da nicht auf existierende Komponenten zurückgegriffen werden kann oder gar bestehende IT-Systeme ausgetauscht werden müssen. Die Akzeptanz der betriebsübergreifenden IT-Integration wird durch die diskutierten Barrieren gehemmt. Es kann daher erwartet werden, dass eine Akzeptanzzunahme erreicht wird, wenn diese Barrieren durch eine IT-Integrationsarchitektur adressiert werden. Kategorie Barriere KMU-spezifisch Allgemein Iacovou et al. (1995) Jones et al. (2003) Khazanchi (2005) Lawson et al. (2003) MacGregor und Vrazalic (2005) Stockdale und Standing (2004) Parker und Castleman (2007) Zheng et al. (2004) Chwelos et al. (2001) Goodhue et al. (1992) Kagermann und Österle (2006) Spath et al. (2006) Teo et al. (2006) Veit (2010) Vijayasarathy (2010) Wainwright und Waring (2004) Wojda et al. (2006) Zhu et al. (2003) Organisatorisch Änderungsmanagmenschiebung Befürchtete Machtver- Expertise Fehlendes Dienstleistungsangebot Management Fehlende Management Unterstützung Unterstützung Strategie Inkompatible Geschäftsmodelle Prozessdefizite Finanzielles Hohe Kosten Technisch Struktur Unpassende IT- Struktur für Organisationsstruktur Infrastruktur Fehlende Unterstützung für Legacy- Systeme Hohe Komplexität Interoperabilität Niedrige Sicherheit Fehlende Standardisierung Umgebung Rechtliche Aspekte Gesetzliche Vorgaben Angst und Ungewissheit Entwicklung und Erwartung der Umgebung Marktsituation Fähigkeiten Fähigkeiten der Partner Tabelle 1.3: Barrieren der betriebsübergreifenden IT-Integration 24

25 1.3 Zielsetzung 1.3 Zielsetzung Die Herausforderungen kleiner Unternehmen werden in dieser Arbeit durch eine spezielle Integrationsarchitektur für Informationssysteme aufgegriffen. Ihre spezielle Situation wird durch die Analyse der relevanten Barrieren adressiert. Entscheidend für die Akzeptanz eines hierfür entwickelten Ansatzes ist, dass er die Autonomie der beteiligten Unternehmen wahrt und somit jeder Partner über gleich große Entscheidungsfreiheiten verfügt. Andernfalls würde dessen organisatorische Autonomie eingeschränkt. Die Kooperation von Partnern, welche gleichberechtigt Informationen austauschen, muss sich hierzu in der Struktur einer Integrationsarchitektur widerspiegeln (Walter et al., 2006). Durch die Integration von Informationssystemen soll erreicht werden, dass die Qualität der Informationen zunimmt 3. Insbesondere sollen die Zugreifbarkeit, Bearbeitbarkeit, Aktualität, Vollständigkeit, Fehlerfreiheit, Glaubwürdigkeit und das Ansehen der Informationen zunehmen. Wirtschaftliches Handeln manifestiert sich in Transaktionen, also etwa Angeboten, Aufträgen oder Rechnungen. Da betriebliche Transaktionen Stammdaten referenzieren, hängt die Qualität der Transaktionen von der der Stammdaten ab. Eine Fokussierung auf Stammdaten ist daher sinnvoll, da Stammdaten in der Regel kontinuierlich und häufig in Transaktionen verwendet werden, welche ihrerseits in der Regel nur eine kurze Verwendungsdauer haben. Für die Integration eignen sich Stammdaten besonders, denn durch die Reduktion auf wenige wichtige Daten kann die Komplexität der Integration signifikant reduziert werden. Eine solche Architektur zur Integration von Stammdaten zu entwerfen ist das Ziel dieser Arbeit. Im Folgenden wird die Integration von Informationssystemen (IT-Integration) untersucht. Soweit es sich nicht anders aus dem Kontext ergibt, wird der Begriff Integration in diesem Sinne verwendet. 3 Für eine ausführliche Diskussion des Konzeptes Informationsqualität siehe Abschnitt

26 1 Einleitung 1.4 Aufbau der Arbeit Kapitel Ausgangssituation 1 Einleitung Anwendungsdomäne Barrieren Zielsetzung Begriffsbildung Verteilung, Autonomie und Heterogenität Integration von Informationssystemen Integrationsebenen 2 Stand der Technik Integrationstopologien Stammdatenmanagement Virtuelle und materialisierende Integration Replikation Integrationsparadigmen in Unternehmen 3 Ansatz und Anforderungen Defizite Anforderungen Ansatz 4 Konnektor Schematische Ebenen Benutzungsschnittstellen 5 Optimistische Integration Definitionen Objektidentifikation Ausführungspläne Konfliktbehandlung 6 Realisierung Softwaretechnische Komponenten Framework Adapter Benutzungsschnittstellen 7 Anwendung CAS genesisworld e-pro Mediando Handelsvertreterplattform Anforderungserfüllung Klassifikation der opt. Integration 8 Evaluation Effizienz des Ansatzes Evaluation der Integrationsfunktion Zusammenfassende Bewertung und kritische Diskussion der Ergebnisse der Arbeit 9 10 Ausblick Architekturkonzept Zusammenfassung Ausblick Zusammenfassung Abbildung 1.4: Struktur der Arbeit 26

27 2 Grundlagen, Vorarbeiten und Stand der Technik In diese Arbeit fließen unter anderem Erkenntnisse aus den Bereichen der Wirtschaftsinformatik zur organisatorischen Integration und zum Informationsmanagement; der Betriebswirtschaftslehre zur Organisationsgestaltung und Situation von KMU; der Informatik zu Datenbanksystemen und Softwarearchitekturen sowie der Benutzungsschnittstellenmodellierung ein. Hierbei soll durch Nutzung von Stärken und Erkenntnissen dieser Disziplinen nebst Verringerung bekannter Defizite eine verbesserte Integrationsarchitektur entwickelt werden. Im Rahmen dieses Kapitels werden die für diese Arbeit relevanten Themen untersucht (siehe Abbildung 2.1). Das Paradigma der Design Science zielt auf die Entwicklung nützlicher IT-Lösungen ab, die durch das (proaktive) Schaffen und Evaluieren verschiedener Artefakte in Form von Modellen, Methoden oder Systemen untersucht werden sollen (Wilde und Hess, 2007). Hierdurch wird der Beitrag des Artefakt zur Problemlösung gezeigt (Nunamaker Jr et al., 1991). Diese beiden fundamentalen Schritte des Schaffens und Evaluierens erzeugen einen wissenschaftlichen Beitrag (Hevner et al., 2004). Dieses Vorgehen wird in dieser Arbeit aufgegriffen. Im deutschsprachigen Raum hat sich für Design Science keine einheitliche Übersetzung etabliert. So übersetzen Österle et al. (2010) dies als»gestaltungsorientier Ansatz«, Rohde und Wulf (2011) verwenden»gestaltungswissenschaftliche Orientierung«, während Wilde und Hess (2007) den Begriff»konstruktionswissenschaftliches Paradigma«prägen. Diese Übersetzungen können jedoch ungewollte Assoziationen mit Paradigmen anderer Disziplinen als der Wirt- Herausforderungen und Anforderungen im Stand der Technik Betriebs wirts chafts lehre Organisationsgestaltung KMU Wertschöpfungsnetzwerke Wirts chafts informatik Informationsmanagement Stammdatenmanagement Integrationsparadigmen Organisatorische Integration Informatik Datenbanksysteme Replikation Optimistische/pessimistische Verfahren Integrationsebenen Anforderungsanalyse Architekturentwicklung Methodisches Vorgehen Design Science Benutzungsschnittstellenentwurf Softwareentwicklung Integrations paradigma Softwarekomponenten, Algorithmen und Benutzungsschnittstellen Abbildung 2.1: Überblick zum Stand der Technik

28 2 Grundlagen, Vorarbeiten und Stand der Technik schaftsinformatik wecken, sodass der Begriff Design Science in dieser Arbeit unübersetzt verwendet wird. 2.1 Begriffsbildung Kooperierende Unternehmen tauschen zur Kooperation notwendigerweise Informationen aus. Ein Großteil dieses Informationsaustausches geschieht auf zwischenmenschlicher Ebene und ist daher nicht automatisierbar (van den Heuvel, 2010). Soll der Informationsaustausch automatisiert werden, so wird eine Integration der Informationssysteme sinnvoll. Diese IT- Integration kooperierender Unternehmen geschieht durch den Austausch von Daten. In der Integration werden Daten einer Datenquelle einer Datensenke zur Verfügung gestellt. In der bidirektionalen Integration übernimmt ein System beide Rollen. Hier sei auf den Unterschied zwischen Daten und Informationen hingewiesen: Informationen sind Daten, die in einen semantischen Kontext eingebettet sind und dadurch eine Bedeutung tragen (Laudon et al., 2010, S. 791). Daten werden häufig in Datenbanken und Textdateien gespeichert. Verarbeitet werden Daten hingegen in Informationssystemen. Dies verdeutlicht, dass diese Systeme über das Wissen der semantischen Bedeutung der Daten verfügen (Sommerville, 2007, S. 333ff). Werden Informationssysteme miteinander integriert, so sind sie in einer spezifischen Topologie miteinander verbunden. Hiermit wird Bezug genommen auf die Kommunikationskanäle und die Verteilung der in Informationssystemen gespeicherten Information (Laudon et al., 2010, S. 345ff). Die hierfür notwendigen Komponenten der Integrationsarchitektur werden in ihrer Gesamtheit in dieser Arbeit als Konnektor bezeichnet. Zusammen mit dem Konnektor der Integrationsarchitektur wird ein Informationssystem als Peer bezeichnet Information Der Begriff der Information wird in mehreren Disziplinen gebraucht und doch unterschiedlich verwendet. Wichtig ist der Begriff unter anderem in der Informatik, Wirtschaftsinformatik, Nachrichtentechnik, Informationstheorie und Semiotik. Die Nachrichtentheorie etwa reduziert den Informationsbegriff auf Mitteilung und Nachricht. Information wird begriffen als diejenige Unsicherheit, die durch Erscheinen des betreffenden Zeichens reduziert wird (Shannon, 1948). Mehr Erklärungspotential liefert die Semiotik, die als allgemeine Lehre von Zeichen und Zeichenreihen die Aspekte Syntaktik, Semantik und Pragmatik untersucht (Krcmar, 2005, S. 16) (Abbildung 2.2). Auf der Ebene der Syntaktik wird Information lediglich als Struktur von Zeichen gesehen. Die Ebene der Semantik erweitert dies um eine Bedeutung der Informationen. Die Relevanz der Informationen für Entscheidungen ist schließlich der Aspekt der Pragmatik. Die semiotische Analyse vermag daher die Beziehung zwischen einem Objekt und dem Begriff der Information genauer in einem Model zu definieren. Allerdings wird in dieser Analyse kein Bezug genommen auf den Zweck und die Relativität der Informationen. Krcmar (2005, S. 17) schlägt daher in Anlehnung an Steinmüller (1993) 28

29 2.1 Begriffsbildung Entscheidung Pragmatik Semantik Syntaktik Handeln Wissen Information Daten Zeichen Abbildung 2.2:»Wissenspyramide«in Anlehnung an (Wolf et al., 1999; Schlegel, 2009) vor den Informationsbegriff durch ein immaterielles Modell eines Originals für Zwecke eines Subjekts zu ersetzen. Dies bietet sich an, da Modelle subjektrelativ sind, d.h. die Auswahl des Originals und der Abbildungsregeln sind auf den Erzeuger zugeschnitten. Weiterhin sind Modelle zweckrelativ (auf die Belange des Erzeugers ausgerichtet) und perspektivisch (auf den Blickwinkel des Erzeugers eingehend) (Steinmüller, 1993). Dieser systemische Informationsbegriff (Abbildung 2.3) definiert also Informationen als nicht zwingend eindeutige Abbildung, welche von unterschiedlicher Qualität sein können. Dies führt unmittelbar zum Begriff der Informationsqualität und dem verwandten Begriff der Dublette, da ein Original mehrfach auf ein Informationssystem abgebildet sein kann. Diese systemische Definition wird daher in dieser Arbeit verwendet. Informationen können weiter charakterisiert werden als strukturiert, semi-strukturiert und unstrukturiert (Batini und Scannapieco, 2006, S. 6; Hildebrand et al., 2008). (Semi-)Strukturierte Informationen aggregieren kleinere Informationsaggregate 4 zu größeren Einheiten. Für strukturierte Informationen ist die Bedeutung jedes Informationsaggregats explizit definiert, in semistrukturierten Informationen ist dies nur implizit der Fall. Die explizite Beschreibung wird als Schema bezeichnet. Für unstrukturierte Informationen ist eine strikte und eineindeutige Abgrenzung einzelner Informationsaggregate in der Regel nicht möglich. Insbesondere Fließtexte sind unstrukturierte Informationen Datenschemata und -modelle Das Schema strukturierter Informationen definiert den Ausschnitt der Realität, welcher beschrieben wird. Beschreiben zwei Schemata überlappende Ausschnitte der Realität, können die Informationen ineinander transformiert werden. Transformationen bezeichnen daher Abbildungen zwischen Schemata. Dies ist in der Informationsintegration wichtig, da Schemata unterschiedlicher Informationssysteme in der Regel voneinander abweichen (Leser und Naumann, 2007, S. 105). 4 Bspw. Formularfelder, Attribute oder Objekte 29

30 2 Grundlagen, Vorarbeiten und Stand der Technik Subjekt Subjekt Zwecks Beeinflussung des Adressaten A verfügt über Information = Modell Information A über Original Original Abbildung 2.3: Information ist»modell-wovon-wofür-für-wen«(steinmüller, 1993) Die Ausdrucksfähigkeit eines Schemas wird durch das verwendete Datenmodell beeinflusst. Ein Datenmodell beschreibt als Metamodell, welche Elemente für ein Schema verfügbar sind und in welcher Beziehung diese zueinander stehen können. Datenmodelle können auf Domänen spezialisiert sein. Wichtig ist, ob sie den Anforderungen zur Beschreibung der jeweiligen Anwendungsdomäne vollständig genügen. Von Bedeutung ist weiterhin, ob sie über eine angemessene Ausdrucksstärke verfügen, d.h. dass sie angemessen differenziert in den Modellierungsmöglichkeiten sind (Elmasri et al., 2009, S. 40f). Übliche Elemente von Datenmodellen sind atomare Entitäten und Beziehungen zwischen diesen. Wichtige Beziehungsarten sind Vererbungen, welche allgemeine Konzepte spezialisieren, Hierarchien und allgemeine Relationen. Weiterhin existieren Datenmodelle, die ausschließlich zur Modellierung von Daten, jedoch nicht der Datenspeicherung dienen (Elmasri et al., 2009, S. 40f). Wenn Daten gespeichert werden ist ein weiteres Kriterium, wie gut sich das Datenmodell als Ausgangspunkt für Transformationen in Schemata desselben oder anderer Datenmodelle eignet. Dies hängt mit der Ausdrucksstärke zusammen, da die implizite Information eines differenzierten Schemas entscheidend beeinflusst, ob es sich als Ausgangspunkt für Transformationen eignet (Leser und Naumann, 2007, S. 32ff). Wichtige Datenmodelle sind XML für die (semi)strukturierte Beschreibung hierarchischer Daten, das relationale Datenmodell, welches beliebige Beziehungen zwischen Entitäten (Relationen) erlaubt, das objektorientierte Datenmodell, welches zusätzlich Vererbungsstrukturen ermöglicht und das unstrukturierte Datenmodell, welche weder Entitäten noch Beziehungen zwischen diesen definiert (Elmasri et al., 2009, S. 40f). Rein für die Modellierung sind das konzeptionelle Entity Relationship (ER) Modell (Chen, 1976) und die Unified Modeling Language (UML) (OMG, 2010) von Bedeutung. Da letztere allerdings keine Datenspeicherung vorsehen, eignen sie sich nicht für eine operative Integration von Informationen (Tabelle 2.1). 30

31 2.1 Begriffsbildung Datenmodell XML Relational Objektorientiert Unstrukturiert ER (Chen, 1976) UML (OMG, 2010) Kriterium Vollständigkeit Angemessene Ausdrucksstärke Entitäten Hierarchien Vererbung Allgemeine Relationen Datenspeicherung Ausgangspunkt für Transformationen Legende: : vollständig gegeben : bedingt gegeben : nicht gegeben Tabelle 2.1: Datenmodelle im Vergleich Kommunikation Es können prinzipiell zwei Arten der Kommunikation differenziert werden. Diese unterscheiden sich in der Notwendigkeit, für den Sender oder Empfänger einer Nachricht, solange die interne Verarbeitung blockieren zu müssen, bis die Rückmeldung des Kommunikationspartners vorliegt. Weiterhin kann es für einen Sender unterschiedlich schwierig sein, eine Rückmeldung über die erfolgreiche Verarbeitung einer Nachricht im Kontext der versendeten Informationen zu erhalten. Synchrone Funktionsaufrufe unterbrechen solange die weitere Verarbeitung, bis die Funktion ein Ergebnis liefert. Das Ergebnis der Funktion kann direkt im Kontext des Funktionsaufrufs weiterverarbeitet werden. Im Gegensatz dazu werden Funktionen in der asynchronen Kommunikation aufgerufen, aber die lokale Verarbeitung wird dessen ungeachtet fortgesetzt. Dies erfordert zusätzliche Funktionalitäten, um das Ergebnis des Funktionsaufrufs dem ursprünglichen Kontext wieder zuzuordnen. Allerdings skaliert eine Architektur, die asynchrone Kommunikation verwendet, besser, da sie weniger durch Wartezeiten blockiert wird. Generell ist die Abhängigkeit zwischen Aufrufer und Aufgerufenem in der asynchronen Kommunikation geringer (Mandl et al., 2010, S. 318ff) (Tabelle 2.2). Kommunikationsart Synchrone Kommunikation Kriterium Mehrstufige Kommunikation Rückmeldung des Empfängers Blockieren des Senders Asynchrone Kommunikation Blockieren des Empfängers Legende: trifft voll zu, trifft teilweise zu, trifft nicht zu Tabelle 2.2: Vergleich synchroner und asynchroner Kommunikation 31

32 2 Grundlagen, Vorarbeiten und Stand der Technik Softwarearchitektur Asynchrone Kommunikation wird daher häufig in ereignisgesteuerten Architekturen (engl. event driven architectures) eingesetzt. Diese Architekturen bestehen aus mehreren unabhängigen Komponenten, welche Zustandsänderungen in Form von Ereignissen publizieren (Sommerville, 2007, S. 292ff). Hierfür steht in der Regel eine zentrale Komponente zur Verfügung, welche es Komponenten dem Observer-Muster (Gamma et al., 1994) folgend erlaubt, Ereignisse zu abonnieren. Tritt ein abonniertes Ereignisse ein, wird es der abonnierenden Komponente zugestellt. Dieses Muster ist auch als publish & subscribe Muster bekannt. Da die genaue Interaktion der Komponenten nicht während ihrer Entwicklung festgelegt werden muss, ist dies eine lose gekoppelte Interaktion. Beispiel 2: Ein Beispiel für asynchrone Kommunikation sind s. Diese werden in Mailprogrammen erstellt und versendet. Nach dem Versenden ist nicht bekannt, ob die angekommen ist. Noch weniger bekannt ist, ob der Empfänger die Nachricht verstanden hat. Antwortet der Empfänger auf die , so muss der ursprüngliche Sender unter Umständen die Antwort in Beziehung zu seiner setzten, also den Kontext wiederherstellen, um die Nachricht interpretieren zu können. ISO (International Organization for Standardization, 2007) definiert den Begriff Architektur für softwareintensive Systeme als die fundamentale Organisation eines Systems, wie sie sich in seinen Komponenten, deren Beziehungen untereinander und zur Umgebung ausdrückt, sowie die Prinzipien, nach denen es entworfen und entwickelt wurde. Auf dieser Ebene soll in dieser Arbeit die Integration von Informationssystemen beschrieben werden. Es wird daher eine Integrationsarchitektur entwickelt. 2.2 Integration von Informationssystemen Integration ist ein komplexer Begriff, welcher je nach Verwendungszweck unterschiedliche Bedeutungen tragen kann. In der Integration von Informationssystemen identifizieren Wainwright und Waring (2004) vier Aspekte, die in jedem umfassenden Projekt betrachtet werden müssen. Dies sind technologische, systemtheoretische, strategische und organisatorische Aspekte (Abbildung 2.4). Eine Integrationsarchitektur muss dementsprechend alle diese Aspekte berücksichtigen Technische Integrationsperspektive Nach Puschmann und Alt (2004) investieren Organisationen mindesten 40% ihres IT- Budgets für die technische Integration. Hierbei wird über komplexe IT- Integrationsparadigmen eine Verbindung von zuvor isolierten Informationssystemen durch eine technische Integrationsfunktion angestrebt. Diese Integrationsfunktion kann auf unterschiedlichen Ebenen mit Datenquellen und senken interagieren, diese werden in Abschnitt 2.4 diskutiert. Der technische Integrationsbegriff ist eine Perspektive auf die Integration, welcher für sich alleine nicht ausreichend ist, jedoch wichtige Ansätze für die operative Durchführung der 32

33 2.2 Integration von Informationssystemen Perspektive auf Integration Technisch Daten, Kommunikation, Automatisierung Systemtheoretisch Operationen, Workflows, Geschäftsprozesse Analytische Methoden und Werkzeuge Daten/Systeme Designanalyse Methoden und Werkzeuge Praktiziert durch IT Anwender Software/Hardware IT Verantwortliche Integration von Informationssystemen Strategisch Intern Extern Strategische Analyse Geschäftsführung Berater Strukturelle Analyse Organisatorisch Sozial Politisch Sozialer und historischer Kontext Machtpolitische Analyse Stakeholder Kulturelle Analyse Abbildung 2.4: Strategisches Modell der Integration nach Wainwright und Waring (2004) Integration liefert. Denn die Rolle und Auswirkung der Integration kann nicht außerhalb eines spezifischen Geschäftskontextes bewertet werden (Sharif et al., 2004). Integration als rein technische Herausforderung zu betrachten greift zu kurz, da sie nach Wainwright und Waring (2004) nicht berücksichtigt, dass Schwierigkeiten entstehen können, wenn organisatorische Grenzen berührt werden. Dass die organisatorische Perspektive besonders wichtig ist berichtet auch Vijayasarathy (2010). Er zeigt, dass für die operative Performanz der Integration insbesondere die Qualität der Partnerschaft definiert als Vertrauen und Bindung wichtig ist. Die spezielle eingesetzte Technologie hat auf die operative Performanz jedoch nur geringen Einfluss Systemtheoretische Integrationsperspektive Eine ganzheitlichere Perspektive auf die Integration von Informationssystemen liefert der systemtheoretische Ansatz. Hierin werden Organisationen nach Wainwright und Waring (2004) als komplexe adaptive Systeme betrachtet, welche ausgeprägte, gewachsene Eigenschaften haben. Verbundene Systeme (Abbildung 2.5) kommunizieren in dieser Perspektive uni- oder bidirektional und treffen Entscheidungen, die sich am eigenen Vorteil orientieren. Integrierte 33

34 2 Grundlagen, Vorarbeiten und Stand der Technik A B A B A B A B isoliert verbunden integriert universal Abbildung 2.5: Arten der systemtheoretischen Beziehungen nach Das (1992) Systeme treffen demgegenüber Entscheidungen für den gemeinsamen Vorteil. In universalen Systemen werden keine individuellen Entscheidungen getroffen. In dieser systemtheoretischen Betrachtung wird also zwischen einer lose gekoppelten Verbindung und einer eng gekoppelten Integration unterschieden. In dieser Definition ist Integration innerhalb von Unternehmen oder in sehr eng kooperierenden Unternehmensverbünden realisierbar. KMU-Wertschöpfungsnetzwerke sind daher eher als verbundene Unternehmen zu verstehen, die zuerst auf ihren eigenen Vorteil bedacht sind. Systemtheoretisch stellt sich daher die Frage, wie die Kommunikationsbeziehungen (Integrationsfunktionen) ausgestaltet sind. Technisch können diese virtuell oder materialisierend realisiert sein. Dies wird in Abschnitt 2.7 diskutiert. Die Systemtheorie liefert den Ansatz, Integration auch als organisatorisches Thema zu betrachten. Allerdings geschieht dies in der Literatur nur am Rande (Wainwright und Waring, 2004), eine gesonderte Diskussion der strategischen und organisatorischen Einflussfaktoren sollte jedoch explizit geschehen. In der Praxis ist dies besonders im Stammdatenmanagement wichtig und wird daher in Abschnitt 2.6 gesondert diskutiert Strategische Integrationsperspektive Bedingt durch die hohen Investitionskosten für die Integration von Informationssystemen hat sich eine strategische Planung etabliert (Wainwright und Waring, 2004). Nach Goodhue et al. (1992) setzt Integration eine Abwägung zweier konkurrierender Ziele voraus: der Flexibilität einerseits und der Reduzierung des»unwissens«andererseits. Denn nach Goodhue sinkt mit zunehmender Integration die Flexibilität der integrierten Partner, sich an neue oder geänderte Anforderungen anzupassen. Gleichzeitig nimmt jedoch auch das Unwissen ab. Das strategische Ziel, welches verfolgt werden soll, ist daher, unter Berücksichtigung dieser Parameter eine Kostenoptimierung zu erreichen (Capiello und Comuzzi, 2009). Der von Goodhue verwendete Begriff des Unwissens (engl. uncertainty) ist jedoch nicht umfassend genug. Iacovou et al. (1995) und Khazanchi (2005) verwenden hierfür den Begriff der Informationsqualität. In seiner umfassenden Definition, wie durch Wang und Strong (1996) eingeführt, reicht der Begriff aus, um die strategischen Vorteile der Integration zu erklären. Das Konzept der Informationsqualität wird daher in Kapitel diskutiert. In der Analyse der wichtigsten Hemmnisse für die Umsetzung von IT-Integration zeigt sich (Teo et al., 2006), dass speziell unzureichende finanzielle Ressourcen ein häufiges Hemmnis sind. Dies wird durch Cragg und King (1993), Iacovou et al. (1995), Jones et al. (2003) und Zheng et al. (2004) gestützt. Sie stellen fest, dass KMU IT-Integration vor allem wegen der 34

35 2.2 Integration von Informationssystemen hohen Kosten ablehnen. In Anbetracht dessen, das nach Puschmann und Alt (2004) über 40% der IT-Budgets in die IT-Integration investiert wird, ist dies nachvollziehbar. Schönemann et al. (2009) führen an, dass dezentrale Peer-to-Peer (P2P) Architekturen Kostenvorteile für KMU realisieren, da Kosten über alle Netzwerkpartner gleich verteilt sind und keine Gebühren an eine zentrale Stelle abgeführt werden müssen. Unter Berücksichtigung des Aspektes, dass die Effektivität und Effizienz der Integration nur gering von der verwendeten Technik abhängen (Ryssel et al., 2004; Vijayasarathy, 2010) ist dies daher ein vielversprechender Ansatz Organisatorische Integrationsperspektive Nach Wainwright und Waring (2004) müssen Informationssysteme derart gestaltet und eingerichtet sein, dass sie der Kultur der sie verwendenden Organisation entsprechen, nicht vice versa. Genauer wurde dies bereits von Conway (1968) beschrieben. Nach seiner Analyse muss die Struktur eines Informationssystems der Struktur der es verwendenden Organisation entsprechen. Das hier ein Defizit besteht wird durch die Tatsache verdeutlicht, dass KMU als Hemmnis für die IT-Integration fehlende adäquate standardisierte Technologien ansehen (Jones et al., 2003). Integrationstopologien werden daher in Abschnitt 2.5 diskutiert. KMU-Wertschöpfungsnetzwerke sind ihrer Struktur nach dezentral. Diese Dezentralität muss daher auch in der Topologie der Integrationsarchitektur reflektiert werden, wenngleich sich die Kultur der Organisation nicht auf diese reduziert. Neben der strukturellen Analyse führen Wainwright und Waring (2004) daher auch noch den sozialen und historischen Kontext, eine machtpolitische sowie kulturelle Analyse an. Die zugrundeliegenden Aspekte wurden in der Literatur ausführlich diskutiert. So führen Iacovou et al. (1995) drei Faktoren an, die eine Umsetzung von IT-Integration in KMU befördert. Dies sind die organisatorische Fähigkeit, äußerer Druck und wahrgenommene Vorteile. Die organisatorische Fähigkeit wird von Zhu et al. (2003) speziell für europäische Unternehmen genauer untersucht. So sind die Kosten und technischen Fähigkeiten, über die eine Organisation verfügen kann, entscheidende Größen, welche die Umsetzung von IT- Integration beeinflussen. Stockdale und Standing (2004) führen weitere Hemmnisse für die IT-Integration von KMU-Wertschöpfungsnetzwerken auf (Abbildung 2.6). Sie führen an, dass flankierende Dienstleistungsangebote auf die Bedürfnisse von KMU abgestimmt sein müssen. Nach Parker und Castleman (2007) müssen auf KMU spezialisierte Dienstleistungsangebote entwickelt werden, da für größere Unternehmen entwickelte Angebote nicht auf diesen Anwendungsbereich übertragbar sind. Als Gründe werden hierfür hohe Beratungskosten sowie eine andere Marktposition und -situation von KMUs genannt, mit denen Berater vertraut sein müssen (Lawson et al., 2003). Beratungsdienstleistungen können maßgeblich dann kostengünstig angeboten werden, wenn sie auf einem standardisierten Vorgehensmodell beruhen und auf wiederverwendbare Elemente zurückgreifen können. Nicht zuletzt ermöglicht dies auch eine belastbare ex-ante Kalkulation der Projektkosten und somit Planungssicherheit für das KMU (Bobrowski und Vazquez Soler, 2004). 35

36 2 Grundlagen, Vorarbeiten und Stand der Technik Externe Barrieren Fehlendes Verständnis der Bedürfnisse von KMU Fehlender technischer Standard e-kompetenz der Branche KMU Identifizierung der Vorteile Globaler Handel Finanzielle Rahmenbedingungen SCM Integration Verständnis der e-umgebung Interne Barrieren Abbildung 2.6: Barrieren der B2B IT-Integration für KMU nach Stockdale und Standing (2004) Zusammenfassende Bewertung Zusammenfassend muss also festgestellt werden, dass Integration eine vielschichtige Aufgabe ist, die sich nicht alleine auf organisatorische, strategische, systemtheoretische oder technische Aspekte reduzieren lässt. Erfolgsentscheidend ist die Berücksichtigung aller Bereiche in der Entwicklung einer Integrationsarchitektur. In Abschnitt wurden Barrieren aus diesen Bereichen analysiert. Es zeigt sich nun, dass alle formulierten Barrieren gleichermaßen adressiert werden müssen. 2.3 Verteilung, Autonomie und Heterogenität Nach Busse et al. (1999) beschreiben drei orthogonale Dimensionen die Schwierigkeiten der Informationsintegration: Verteilung, Autonomie und Heterogenität Ursachen der Komplexität in der Informationsintegration Verteilt sind Informationen, wenn sie auf unterschiedlichen Systemen liegen. Verteilung kann sowohl physisch als auch logisch vorliegen. Physische Verteilung bedeutet, dass Informationen an unterschiedlichen Orten gespeichert sind und für die Integration verfügbar gemacht werden müssen. Logische Verteilung bedeutet, dass identische Daten im Gesamtsystem an verschiedenen Stellen gespeichert sein können (Neuman, 1994; Leser und Naumann, 2007). Leser und Naumann (2007) definieren Autonomie als die Freiheit der Datenquelle, unabhängig über die von ihr verwalteten Daten, deren Struktur und die Zugriffsmöglichkeiten auf diese Daten zu entscheiden. Autonome Datenquellen werden häufig angetroffen, wenn unternehmensübergreifend bestehende Informationssysteme integriert werden sollen. Heterogen sind zwei Informationssysteme, wenn sie nicht exakt die gleichen Methoden, Modelle und Strukturen zum Zugriff auf ihre Daten anbieten. 36

37 2.3 Verteilung, Autonomie und Heterogenität Autonomie und Heterogenität kennzeichnen das Verhältnis zwischen Informationssystemen und deren Entwicklung im Laufe der Zeit. Autonomie und Heterogenität sind zunächst orthogonale Dimensionen, die in der Praxis aber eng zusammenhängen. Generell ist zu beobachten, dass der Grad der Heterogenität zwischen Informationssystemen mit dem Grad ihrer Autonomie zunimmt. Zwei vollkommen unabhängige Informationssysteme werden praktisch immer heterogen sein (Leser und Naumann, 2007). Tabelle 2.3 führt die wichtigsten Autonomiedimensionen auf. Designautonomie bedingt Heterogenitäten, welche hohe Kosten in der Integration verursachen (Themistocleous et al., 2004). Häufig wird daher die Autonomie der zu integrierenden Informationssysteme eingeschränkt. Dies setzt voraus, dass sich alle Beteiligten auf eine entsprechende Reduzierung der Autonomie verständigen. Dies ist nicht immer möglich, da hierbei Flexibilität und Gestaltungsspielräume aufgegeben werden müssen. Da weiterhin die Anforderungen der reduzierten Autonomie im Allgemeinen noch nicht von dem zu integrierenden Informationssystem abgedeckt werden, bedeutet dies zusätzlichen Implementierungsaufwand und somit Kosten. Autonomie Autonom in Bezug auf Beispiele Designautonomie Designentscheidungen der Datenmodell Datenhaltungen Datenschema Syntaktische Darstellung Einheiten Schnittstellenautonomie Technische Schnittstellen Protokoll Zugriffsautonomie Juristische Autonomie Authentifizierung und Autorisierung Integration juristisch unterbinden Tabelle 2.3: Autonomiearten (Leser und Naumann, 2007) Anfragesprache Eigene Benutzerverwaltung Lese-/Schreibrechte nur auf bestimmte Daten Urheberrechte Wird nach Leser und Naumann (2007) die gewährte Autonomie ausgenutzt, entstehen nahezu zwangsläufig unterschiedliche Informationssysteme. Diese Unterschiede manifestieren sich in Heterogenitäten, die in der Informationsintegration berücksichtigt werden müssen. Tabelle 2.4 kategorisiert verschiedene Heterogenitätsarten und zeigt, in welchen Bereichen Herausforderungen entstehen. Heterogenität Entstehende Herausforderungen Technische Technische Realisierung des Zugriffs auf Datenquellen Syntaktische Darstellung von Informationen Datenmodell Verwendete Datenmodelle Strukturelle Strukturelle Repräsentation Schematische Verwendete Datenmodellelemente Semantische Bedeutung von Begriffen und Konzepten Tabelle 2.4: Heterogenitätsarten (Leser und Naumann, 2007) 37

38 2 Grundlagen, Vorarbeiten und Stand der Technik Technische Heterogenität bezeichnet jene Unterschiede, die sich nicht unmittelbar auf Daten und ihre Beschreibungen beziehen, sondern auf die Möglichkeit des Zugriffs auf die Daten. Beispiele sind der Zugriff auf einzelne Datenquellen über SQL, SOAP oder das Dateisystem, oder datenquellenübergreifend via SchemaSQL (Lakshmanan et al., 2001). Syntaktische Heterogenität bezeichnet Unterschiede in der technischen Darstellung gleicher Sachverhalte. Beispiele sind binäre Zahlenformate (little endian versus big endian) oder unterschiedliche Zeichenkodierungen (unicode versus ASCII). Datenmodell Heterogenität liegt vor, wenn miteinander integrierte Systeme Daten in abweichenden Datenmodellen verwalten. Beispiel 3: Das Groupwaresystem Lotus Notes hat bis zur Version 7 Daten intern nur als Dokumente (Listen) dargestellt. Sollen relationale Daten hierein integriert werden, muss entweder das kartesische Produkt von Relationen gebildet werden, dies verursacht große Datenmengen. Alternativ kann eine Tabelle zur Speicherung unterschiedlicher Entitäten angelegt werden. Es wird dann eine Relation verwendet, um mehrere Relationen zu persistieren. Als Konsequenz entstehen ein schlecht lesbares Datenschema sowie eine Verletzung des Schichtenmodells, da Integritätsbeziehungen programmatisch realisiert werden müssen und somit aus der verantwortlichen Persistenzschicht entfernt werden. Strukturelle Heterogenität liegt vor, wenn die Abbildungsregeln eines Objektes auf Informationsdarstellungen differieren. Es handelt sich hierbei also um unterschiedliche Schemata, welche dieselbe Information erfassen. Schematische Heterogenität ist ein Spezialfall der strukturellen Heterogenität mit hoher praktischer Relevanz. Sie entsteht durch unterschiedliche Verwendung von Datenmodellelementen zur Modellierung des gleichen Sachverhalts. Beispiel 4: Im relationalen Datenmodell können Informationen als Relationen, Attribute oder Attributwerte gespeichert werden. So können Kunden und Lieferanten durch unterschiedliche Relationen Kunden und Lieferanten dargestellt werden. Als getrennte boolesche Attribute (Ist_Kunde, Ist_Lieferant) können sie innerhalb einer Relation Geschäftspartner dargestellt werden. Schließlich kann in einer Relation Geschäftspartner ein Attribut Typ genutzt werden, welchem die Attributwerte Lieferant und Kunde zugewiesen werden können. In Anlehnung an die Informationsdefinition als immaterielles Modell entsteht semantische Heterogenität schließlich im systemischen Modellbegriff als perspektivische Beschreibung der Realität durch ein Subjekt (Krcmar, 2005), als Kontext der intensionalen und extensionalen Darstellung. Dies führt zu abweichenden Verwendungen von Namen und Konzepten im Zusammenspiel heterogener Systeme. Die häufigsten semantischen Konflikte sind daher auch Synonyme und Homonyme (Leser und Naumann, 2007). Hieraus wird offensichtlich, dass diese Art der Heterogenität besonders schwierig zu erkennen und zu beseitigen ist, da hierfür der Kontext des Subjektes berücksichtigt werden muss. 38

39 2.4 Integrationsebenen In KMU-Wertschöpfungsnetzwerken sind im Allgemeinen viele unterschiedliche Informationssysteme im Einsatz. Für ihre Integration sind daher alle Heterogenitätsarten relevant. Entstehen Konflikte, so sind diese oft nicht eindeutig einer einzigen Heterogenitätsart zuordenbar. Vergleichbar zur Autonomie wird daher häufig versucht, die Heterogenität einzuschränken (Hasselbring, 2000). Dies führt unmittelbar zur Verwendung von Standards. Standards werden in Abschnitt diskutiert Zusammenfassende Bewertung Verteilung, Autonomie und Heterogenität sind die Herausforderungen, mit denen Projekte zur Informationsintegration konfrontiert sind. Die Reduktion der Komplexität einer dieser Dimensionen hat in der Regel auch eine Reduktion der anderen Dimensionen zur Folge. Abhängig vom Einsatzzweck lässt sich so die Autonomie oder Verteilung reduzieren und hierdurch eine geringere Heterogenität erreichen (Andresen und Gronau, 2006). Dies erfordert jedoch eine zentrale Koordination. Da die Struktur der organisatorischen und technischen Integration der Struktur der KMU- Wertschöpfungsnetzwerke entsprechen muss, kann es in diesem Anwendungsfall keine zentrale Koordination geben. Es muss daher ein Ansatz entwickelt werden, der in der Lage ist, heterogene Informationssysteme zu integrieren. 2.4 Integrationsebenen Die technische Integration von Informationssystemen kann auf unterschiedlichen Ebenen geschehen. Linthicum, (1999) und Laudon et al. (2010) unterscheiden Integration auf Daten-, Informations 5 - und Prozessebene. Dangelmaier et al. (2002) haben eine weitere Unterscheidung zwischen Funktions- und Benutzerebene eingeführt. Im Folgenden wird dies aufgegriffen und zwischen Daten-, Informations-, Funktions-, Prozess- und Benutzungsschnittstellenintegration unterschieden (Abbildung 2.7). Integrationsprojekte unterscheiden sich darin, ob ihre Ergebnisse zwischen Anwendungsfällen übertragbar sind, d.h. ob sie eine generische Lösung darstellen, welche ohne signifikanten Anpassungsaufwand wiederverwendet werden kann. Integration kann auch bedeuten, dass Transformationen ausgeführt werden müssen. In der Vereinigung von Informationsmengen können Konflikte entstehen. Generische Ansätze erlauben eine Automatisierung sowohl der Konflikterkennung als auch der Konfliktlösung, wobei die Ergebnisse beider Schritte generischer Lösungen kein domänenspezifisches Wissen einsetzen können und sich somit auf rein syntaktischer Ebene bewegen. Weiterhin sind Integrationsprojekte von bestimmten Komponenten softwareintensiver Systeme abhängig. Offensichtlich wird dies, wenn eine Änderung einer Komponente Änderungen am Integrationsprojekt bedingt. In der systemtheoretischen Betrachtungsweise bestehen also integrierte Systeme, welche keine isolierte Autonomieausübung aufgrund enger Kopplung erlauben. In der Integration von KMU-Wertschöpfungsnetzwerken ist dies kritisch, da dies auch eine Einschränkung organisa- 5 Laudon et al. (2010) führen dies als Objektintegration ein und verwendet erst später den Begriff Informationsintegration. 39

40 Vorname Nachname Straße PLZ Ort 2 Grundlagen, Vorarbeiten und Stand der Technik torischer Autonomie impliziert. Diese enge Kopplung kann in den Komponentenklassen technische Schnittstellen, Schemata, Prozesse und Benutzungsschnittstellen entstehen. Integration ist meist als Dienst realisiert, für dessen Verwendung betroffene Informationssysteme angepasst werden müssen. Je nach Art der Integration können hohe Anforderungen an die notwendigen Anpassungen bestehen. Ferner existieren rein syntaktische und somit weitgehend generische Ansätze, und solche, für welche ein Verständnis der Semantik der integrierten Informationen notwendig ist Vergleichende Darstellung Datenintegration bezeichnet die Integration von Daten, ohne deren Semantik zu berücksichtigen. Datenintegration kann durch generische Ansätze wie Replikation realisiert werden. Replikation bezeichnet hierbei den Austausch von Daten, um mehrere Datenquellen parallel aktuell zu halten. Aufgrund der fehlenden Semantik ist es allerdings nur möglich, syntaktische Konflikte in der Replikation automatisiert zu lösen. Datenintegration ist für heterogene Umgebungen nicht geeignet, da die dort auftretenden unterschiedlichen Schemata rein syntaktisch nicht integriert werden können. Beispiel 5: Kommerzielle Datenbanken bieten häufig Technologien, durch die ihre Datenbestände, bspw. für die mobile Verwendung, repliziert werden können (Choi et al., 2005; Microsoft Developers Network, 2010). Wird die Semantik einbezogen, wird Objekt- oder Informationsintegration betrieben. Diese Art der Integration ist verwandt zur Datenintegration, da auch hier als Ziel, eine gemeinsame integrierte Datenbasis geschaffen wird, wobei Informationen fachlicher Objekte integriert werden. Dies ermöglicht, dass Transformationen ausgeführt werden können, die die Integration schematisch abweichender Datenbasen erlauben. Prozessintegration Benutzungsschnittstellenintegration Funktionsintegration MDM artikel_ändern() ERP Kontakt Informationsintegration (abweichende Schemata) Kunde 1 n Adresse Datenintegration (identische Schemata) Abbildung 2.7: Integrationsebenen 40

41 2.4 Integrationsebenen Da in der Integration der Zugriff auf ein bestimmtes Informationsobjekt aus unterschiedlichen Systemen möglich ist, können Konflikte entstehen, sobald ein Informationsobjekt gleichzeitig in unterschiedlichen Systemen auf verschiedene Werte geändert wird. Die Konfliktbehandlung ist für das Erkennen und Beheben solcher Konflikte zuständig im Falle der Informationsintegration ist sie durch den bekannten Kontext für einfache Fälle automatisierbar (Terry et al., 1995). Ansätze der Informationsintegration sind jedoch, bedingt durch das anwendungsspezifisches Wissen, im Allgemeinen nicht ohne zusätzlichen Aufwand auf andere Anwendungen übertragbar. Funktionsintegration ist orthogonal zur Integration auf Daten- oder Informationsebene (Leser und Naumann, 2007). Hierbei werden Informationssysteme integriert, indem sie auf Funktionen anderer Informationssysteme zugreifen. Da dies über die Schnittstelle dieser Informationssysteme realisiert wird, wird dies auch als Schnittstellen-Integration bezeichnet. Über diese wird der Zugriff auf Anwendungsfunktionen, bspw. zur Durchführung einer Buchung, realisiert. Voraussetzung für die Funktionsintegration ist, dass alle zu integrierenden Informationssysteme über geeignete Schnittstellen verfügen. Von KMU eingesetzte Systeme verfügen in der Regel nicht über solche Schnittstellen, weshalb eine Funktionsintegration in der betrachteten Anwendungsdomäne nicht möglich ist. Beispiel 6: Sollen innerhalb eines ERP-Systems Stammdaten durch eine dritte Anwendung geändert werden, so kann diese die entsprechende Funktionalität des ERP-Systems vorausgesetzt die Funktion artikel_ändern ) des ERP-Systems aufrufen. Eine weitere orthogonale Dimension bildet die Prozessintegration. Ihre Realisierung zielt auf die Integration von Informationssystemen durch global definierte Prozesse. In den meisten Fällen wird eine Prozessintegration realisiert, indem für einen Anwendungsfall spezifische neue Anwendungen erstellt werden. Dies gestaltet sich nach Haas (2006) bereits für einfache Anwendungsfälle komplexer als die Integration auf einer der anderen beschriebenen Ebenen. Prozessintegration verspricht durch ihre Strukturierung von Prozessen eine Vorgabe optimierter Arbeitsabläufe. Um den Aufwand für die Prozessintegration zu reduzieren wurden Standards und Konzepte für Prozesse entwickelt. Zu den Standards gehören ebxml (OASIS; UN/CEFACT, 2001), RosettaNet (GS1, 1998) und UBL (OASIS, 2006). Da diese Standards eine Allgemeingültigkeit anstreben, gestalten sie sich für viele KMUs als zu komplex oder nicht ausreichend an individuelle Anforderungen anpassbar. Konzepte für Prozesse geben hingegen keine technische Basis vor, sondern unterstützen in der Planung der Prozesse sowie der Erfolgsmessung durch geeignete Metriken. So unterteilt das Supply Chain Operations Reference-Modell (SCOR-Modell) den SCM-Prozess in 5 Unterprozesse (Plan, Source, Make, Deliver, Return) und spezifiziert Kennzahlen für jeweilige Unterprozesse (Supply Chain Council, 2010). Das SCOR-Modell wird insbesondere von 41

42 2 Grundlagen, Vorarbeiten und Stand der Technik großen komplexen Organisationen angewendet. Insgesamt sind Konzepte und Standards für Prozesse durch sehr geringe Marktdurchdringung gekennzeichnet (Berlecon Research, 2010) Unter Benutzungsschnittstellenintegration (Dangelmaier et al., 2002) wird der automatisierte Zugriff auf Informationen über Benutzungsschnittstellen verstanden (engl. Screen Scraping). Es werden dafür Softwarekomponenten entwickelt, die sich gegenüber dem integrierten Informationssystem wie ein menschlicher Benutzer verhalten. Diese Art der Integration ist nicht erstrebenswert, kann aber z.b. bei Mainframe-Anwendungen notwendig sein, die keine Integration auf einer der oben diskutierten Ebenen erlauben. Konzeptionell muss die Benutzungsschnittstellenintegration von einer Portalintegration getrennt werden. In einer Portalintegration werden Informationen verschiedener Quellen auf einer gemeinsamen Oberfläche in sogenannten Portlets angezeigt. Integration geschieht hier zuvorderst in der Wahrnehmung des Anwenders. Eine eventuelle Integration zwischen Portlets geschieht auf oben diskutierten Ebenen. Integrationsebene Datenintegration Informationsintegration Funktionsintegration Prozessintegration Benutzungsschnittstellenintegration Kriterium Übertragbar zwischen Anwendungsfällen Transformationen ausführbar Konflikterkennung generisch automatisierbar Konfliktlösung generisch automatisierbar Abhängig von technischen Schnittstellen Abhängig von Schemata Abhängig von Prozessen Abhängig von Benutzungsschnittstellen Hohe Anforderungen an integrierte Systeme Verständnis der Semantik für Integration notwendig Legende: trifft voll zu, triff weitgehend zu, trifft teilweise zu, trifft kaum zu, trifft nicht zu Tabelle 2.5: Charakteristika von Integrationsprojekten in Abhängigkeit von der verwendeten Integrationsebene Zusammenfassende Bewertung Sowohl die Funktions- als auch die Prozessintegration stellen hohe Anforderungen an die zu integrierenden Informationssysteme. Als relevante Barriere wurde eine mangelnde Integrationsfähigkeit von Legacy-Anwendungen erkannt. Da sich diese in der Regel nicht über Funktions- oder Prozessintegration integrieren lassen (Haas, 2006), sind sie für die Integration von KMU-Wertschöpfungsnetzwerken ungeeignet (Tabelle 2.5). Der primäre Anwendungsfall für Datenintegration ist die Replikation zwischen Datenspeichern mit identischen Schemata. Da unterschiedliche Informationssysteme in der Regel Informationen in abweichenden Schemata halten, wird in dieser Arbeit Integration auf 42

43 2.5 Integrationstopologien Informationsebene realisiert, daher müssen entsprechende Integrationsparadigmen (Kapitel 2.9) und Replikationstechnologien (Kapitel 2.8) betrachtet werden. 2.5 Integrationstopologien Zur Überwindung technischer Heterogenität, wurden unterschiedliche Topologien entwickelt, in welchen Informationssysteme integriert werden können. Eine Topologie bezeichnet hier die logische Anordnung von Informationssystemen zueinander. Topologien unterscheiden sich darin, ob dedizierte Server notwendig sind. Wenn der Ausfall einer Komponente der Topologie das Funktionieren der Integrationsfunktion unterbindet, so handelt es sich um einen»single Point of Failure«. Wichtige qualitative Aspekte sind die Wartbarkeit, der Grad der Wiederverwendung von IT-Komponenten, die Komplexität und Skalierbarkeit. Ob virtuell oder materialisiert integriert wird, ist ein weiteres Unterscheidungsmerkmal. Conway (1968) führt weiterhin als zentrales Kriterium für den Erfolg einer Architektur an, dass ihre Topologie derjenigen der sie einsetzenden Organisation entspricht. Auf den Anwendungsfall kooperierender KMU übertragen bedeutet dies, dass sich eine dezentrale Netzwerkstruktur abbilden lassen muss Chaotische Integration Ursprünglich wurden Systeme paarweise integriert. Historisch ist dies in wachsenden IT-Infrastrukturen begründet, bei der solange zwei Informationssysteme miteinander integriert wurden, bis alle notwendigen Beziehungen bestanden. Bei wenigen beteiligten Informationssystemen lassen sich die Abhängigkeiten hierbei noch überblicken. Mit zunehmender Informationssystemanzahl wächst die Anzahl der Beziehungen jedoch so schnell 6, dass die Infrastruktur nicht mehr wartbar und in ihrer Topologie chaotisch wird. In der chaotischen Integration ist keine Softwarekomponente vorhanden, die für mehrere Integrationsprojekte wiederverwendet werden kann. Jedoch sollte gerade bei der Entwicklung von Softwarekomponenten für die Integration auf Wiederverwendbarkeit (Schwinn und Winter, 2005) geachtet werden, da dies die Komplexität und Wartbarkeit der Integration erhöht. Chaotische Integration bringt im Allgemeinen keine oder nur geringe Vorteile mit sich. Ihre Anwendung in der betrieblichen Praxis ist in der Regel auf ein unkontrolliertes und ungeplantes Vernetzen bestehender Anwendungen zurückzuführen, ohne dass hierfür eine Strategie entworfen wurde. In der chaotischen Integration muss jede bilaterale Integrationsfunktion separat implementiert werden. Im Ergebnis ist diese Topologie durch eine geringe Wartbarkeit und keine bis geringe Wiederverwendung gekennzeichnet. Die Integration in KMU- Wertschöpfungsnetzwerken muss jedoch sowohl wartbar sein, als auch von einer hohen Wiederverwendung softwaretechnischer Komponenten Gebrauch machen. 6 nn ( 1) 43

44 2 Grundlagen, Vorarbeiten und Stand der Technik Diese Integrationstopologie kann daher nicht Basis eines KMU spezifischen Geschäftsmodells sein, hauptsächlich da hohe Kosten erwartet werden müssen Hub-and-Spoke Als Konsequenz wurden Hub-and-Spoke Topologien entwickelt, bei denen sich alle zu integrierenden um ein zentrales System sternförmig gruppieren (Laudon et al., 2010, S. 345f). Hierdurch wird die Komplexität reduziert 7. Die Stern-Topologie ist eine der am weitesten verbreiteten Topologien, was in der geringen Komplexität der notwendigen Software und der einfachen Wartbarkeit begründet ist. Der Hub ist hierbei die zentrale Integrationsinstanz, welche für die Verteilung von Nachrichten, Transformationen und Prozessinteraktionen verantwortlich ist (Erasala et al., 2003). Ein Hub hat den entscheidenden Nachteil, dass er den Flaschenhals in einer Integrationsarchitektur bildet. Damit ist verbunden, dass er schlecht skaliert und einen»single Point of Failure«bildet, sein Ausfall also alle Integrationsfunktionen unterbricht. Vor dem Anwendungsfall der KMU-Wertschöpfungsnetzwerke ist weiterhin die Schwierigkeit gegeben, dass ein Partner des Netzwerkes das zentrale System betreiben muss. Clearing Center (Mucha, 2004) realisieren eine solche zentrale Funktionalität. Sie haben diverse Nachteile: Der Betrieb einer solchen Clearing Centers ist mit einem hohen Aufwand verbunden. Es kann daher nur durch einen spezialisierten Partner betrieben werden. Ein Clearing Center muss, um einen optimalen Service bieten zu können, die Heterogenität reduzieren. Eine Fokussierung auf bestimmte Branchen ist daher üblich. Es wird daher nur Clearing Center für Branchen geben, die einen ausreichend hohen Umsatz generieren, um einen wirtschaftlichen Betrieb garantieren zu können. Die Integration mit einem Clearing Center bedeutet, dass die integrierten Informationen allen Teilnehmer verfügbar gemacht werden. Dies ist für öffentliche Daten, wie sie Produktkataloge (ohne Preisinformationen) sind, unkritisch. Für vertrauliche Daten wie Kundendaten ist dies jedoch nicht akzeptabel. Daher sind Clearing Center in der Regel auf Produktdaten spezialisiert. Die Integrationsfunktion entspricht nicht der organisatorischen Struktur von KMU- Wertschöpfungsnetzwerken. Dies wurde jedoch als relevante Barriere identifiziert. Da diese Barriere nicht adäquat adressiert wird, eignet sich die Hub-Topologie nicht für den Anwendungsfall Bus Die Konsequenz hieraus war die Entwicklung von Bus-Topologien. Hierbei wird das zentrale System durch einen Bus ersetzt, welcher prinzipiell über mehrere Systeme verteilt lauffähig ist. Jedes integrierte Informationssystem wird hierbei mit einem Konnektor versehen, welcher die Kommunikation mit dem Bus sicherstellt. Verglichen mit der Hub-and-Spoke 7 ( n ) 44

45 2.5 Integrationstopologien Architektur löst ein Bus das Problem der schlechten Skalierbarkeit und bietet eine höhere Geschwindigkeit. Bussysteme werden häufig in service-orientierten Architekturen eingesetzt. Ihr Nachteil ist, dass sie komplexe Komponenten sind, die schwer zu administrieren sind (Erasala et al., 2003). Ferner ist eine Busstruktur gleich der Hub-and-Spoke Architektur eine zentrale Integrationstopologie. Alle oben diskutierten Nachteile gelten gleichsam Peer-to-Peer Zunehmend verbreitet sich der Peer-to-Peer (P2P) Ansatz. In dieser Topologie wird jedes System als eigenständige Einheit (Peer) betrachtet. Der Datenaustausch erfolgt bilateral. Im Gegensatz zur chaotischen Integration ist in der P2P-Integration jedoch die Kommunikation standardisiert und Komponenten werden wiederverwendet (Schwinn und Winter, 2005). P2P-Topologien haben weite Verbreitung beim Dateiaustausch gefunden (Androutsellis- Theotokis und Spinellis, 2004). In der betrieblichen Integration ist es allerdings mangels geeigneter Produkte als Integrationsparadigma nur gering verbreitet. Das Global Data Synchronisation Network (GDSN), welches von der Organisation GS1 betrieben wird, ist eine Ausnahme. Es ermöglicht den zwischenbetrieblichen Produktdatenaustausch zwischen Lieferanten und Kunden durch bilaterale (P2P) Kommunikation. Der in Abbildung 2.8 dargestellte Stammdatenaustausch umfasst elf Schritte (GS1, 2008; Schemm et al., 2008). Eine detaillierte Beschreibung der Schritte ist in Anhang C enthalten. Durch die Verteilung der Datenpools sowie die bilaterale Kommunikation in den Schritten 7 und 10 manifestiert sich der P2P-Ansatz im GDSN. Datenpools müssen sich im GDSN zertifizieren lassen. Dies führt dazu, dass Datenpools nur von spezialisierten Unternehmen (z.b. SA2 Worldsync oder 1sync) betrieben werden können. In der Praxis existieren daher einige wenige zentrale Datenpools, über die Datenlieferanten und abnehmer kommunizieren. Die Kommunikation zwischen dem Hersteller- oder 6. Datensubskription GS1 Global Registry 3. Datenregistrierung 5. Datensuche und -subskription 2. Datenpublikation Datenpool des Herstellers 11. Empfangsbestätigung 7. Datenpublikation 10. Empfangsbestätigung 4. Datensuche und -subskription 9. Empfangsbestätigung Datenpool des Händlers 8. Datenpublikation Hersteller-System 1. Datenaufbereitung Händler-System Abbildung 2.8: Ablauf des Stammdatenaustauschs im GDSN 45

46 2 Grundlagen, Vorarbeiten und Stand der Technik Händler-System mit seinem jeweiligen Datenpool ist darüber hinaus standardisiert und damit von den individuellen Anforderungen dieser KMUs unabhängig und nicht unmittelbar beeinflussbar. Änderungen sind nur durch entsprechende Gremien durchsetzbar, was wiederum die Folge hat, das sich der Standard häufig ändert und diese Änderungen durch die Anwenderunternehmen nachgezogen werden müssen. Das GDSN realisiert also eine Peer-to-Peer Architektur, welche ansatzweise auf Ebene der Datenpools die organisatorische Struktur von KMU-Wertschöpfungsnetzwerken reproduziert. Letztlich schafft es jedoch noch keine befriedigende Balance zwischen Autonomie und Heterogenität, da die Autonomie vom Anwenderkreis nur kollektiv ausgeübt werden kann. Ein Homomorphismus zwischen organisatorischer und technischer Integration besteht jedoch erst, wenn jeder Anwender seine Autonomie individuell ausüben kann. Außerhalb der betrieblichen Anwendungen wurden in der Forschung bereits zahlreiche Peer-to-Peer Architekturen untersucht. Deren Stand der Technik wird im Folgenden diskutiert. In der Datenbank-Literatur werden Peer Data Management Systeme (PDMS) diskutiert. Hierzu existieren diverse Forschungsprototypen. Die meisten dieser Systeme konzentrieren sich auf virtuelle Integration 8. Hierbei wird eine verteilte Datenbankumgebung aufgebaut, in welcher alle beteiligten Systeme gleichberechtigt sind. Wenn ein System eine Anfrage erhält, beantwortet es alle Anteile dieser Anfrage soweit es kann. Die verbleibenden Anteile der Anfrage werden zu benachbarten Peers der P2P-Umgebung verteilt (Calvanese et al., 2008). Einige Prototypen bewerten, welche Nachbarn am ehesten eine Antwort geben können und geben Anfragen dann bevorzugt an diese weiter. Zum Erstellen des Anfrageplanes ist exaktes Wissen über das Datenmodell und das Schema der befragten Peers notwendig. Im Piazza Projekt (Halevy et al., 2004) wurde daher untersucht, wie durch semantische Beschreibungen automatisiert Beziehungen zwischen unterschiedlichen Schemata hergestellt werden können. Es wurden hierbei speziell durch die Designautonomie entstehende Herausforderungen adressiert. Einen anderen Ansatz verfolgt PeerDB (Ng et al., 2003). In diesem Forschungsprototyp werden Agenten eingesetzt, um entfernte Datenquellen zu durchsuchen. Dieser Ansatz eignet sich daher gut, um Web-Quellen durchsuchbar zu gestalten, ohne einen zentralen Index aufzubauen. Ein weiterer Prototyp speziell für dieses Szenario ist Peer, welcher sich auf den Austausch und die Suche von großen Datenmengen im Web konzentriert (Huebsch et al., 2005). Das Hyperion Projekt verfolgt das Ziel eine vollkommen dezentrale Organisation der Daten zu erreichen (Arenas et al., 2003). Alle diese Systeme haben jedoch gemein, dass sie keine Datenänderungen ermöglichen. Für die Integration von verteilten heterogenen Informationssystemen sind sie daher ungenügend. Ein System, welches Schreibzugriffe erlaubt, ist Orchestra (Ives et al., 2005; Green et al., 2007). Es wurde für den speziellen Anwendungsfall akademischer Daten Messwerte u.ä. 8 Siehe Abschnitt

47 2.5 Integrationstopologien entwickelt. Als Datenmodell wurde ein proprietäres gewählt, was verhindert, dass Daten in einer standardisierten Ausführungsumgebung durch XML-Technologien wie XQuery (W3C, 2010) oder XSLT (W3C, 1999) verarbeitet werden. Eine Besonderheit von Orchestra ist, dass es Änderungen an benachbarte Peers verteilt, nachdem diese freigegeben wurden. In betrieblichen Informationssystemen, in denen eine solche manuelle Freigabe für die meisten Daten nicht erstrebenswert ist, müssen Änderungen hingegen sofort ausgeführt werden, ansonsten kann die Informationsqualität sinken. P2P-Integration von Geschäftsprozessen verfolgt Peer-to-Peer Enterprise Environment (P2E2) (Kupsch und Werth, 2006). Die Zielsetzung ist hierbei ein selbstorganisierendes Netz, welches beim Ausfall eines Dienstes (genannt werden etwa»auftrag anlegen«oder»zahlung durchführen«) automatisch einen äquivalenten Ersatzdienst ausführt. Dieser Ansatz der adaptiven Selbstkonfiguration ist jedoch eine unpassende Struktur für KMU- Wertschöpfungsnetzwerke, in der jeder technischen Beziehung eine stabile Geschäftsbeziehung zugrunde liegt. Topologie Chaotisch Hub-and- Spoke Kriterium Dedizierte Server notwendig Single Point of Failure Hohe Wartbarkeit Hohe Wiederverwendung von IT Komponenten Hohe Komplexität Hohe Skalierbarkeit Virtuelle Integration Materialisierende Integration Organisatorische Struktur von KMU-Netzwerken abbildbar Legende: trifft voll zu, triff weitgehend zu, trifft teilweise zu, trifft kaum zu, trifft nicht zu Tabelle 2.6: Gegenüberstellung verbreiteter Integrationstopologien Zusammenfassende Bewertung Ein Homomorphismus zwischen Struktur von KMU-Wertschöpfungsnetzwerken und deren technischer Umsetzung lässt sich nur durch eine dezentrale Architektur erreichen (Tabelle 2.6). Da sich eine dezentrale chaotische Integration nicht langfristig kosteneffizient umsetzen und mit einem KMU spezifischem Dienstleistungsangebot verbinden lässt, muss die Integration in einer P2P-Topologie realisiert werden (Schönemann et al., 2008). P2P-Technologien haben im Dateiaustausch Verbreitung gefunden. Die Herausforderungen der Integration von Informationssystemen sind mit denen des Dateiaustausches jedoch nur entfernt vergleichbar. Ansätze zur P2P-Integration von Datenbanken sind noch in den Anfängen und von rein technischen Fragestellungen motiviert. Organisatorische Barrieren der Integration sind hier nur unzureichend berücksichtigt. Bus Peer-to-Peer 47

48 2 Grundlagen, Vorarbeiten und Stand der Technik 2.6 Stammdatenmanagement Im Stammdatenmanagement wird das Ziel verfolgt, durch organisatorische und technische Maßnahmen die Informationsqualität von unternehmensrelevanten Daten zu erhöhen (Otto et al. 2011). Es müssen daher der Begriff der Informationsqualität, Stammdaten in ihrem organisatorischen Kontext und die technischen Realisierungsmöglichkeiten für Stammdatenmanagementsysteme betrachtet werden Informationsqualität Im systemischen Informationsbegriff sind Informationen als Abbild eines Originals für ein Subjekt definiert. Diese zweck- und subjektrelative Abbildung ist fehleranfällig. So können Originale mehrfach auf ein Informationssystem abgebildet werden, dies resultiert in Dubletten. Weiter sind temporale, syntaktische und semantische Abbildungsfehler möglich, welche in einer reduzierten Qualität des Abbildes führen und somit dessen Informationsqualität reduzieren. Die Qualität von Informationen kann in mehreren Dimensionen bewertet werden. Wang und Strong (1996) beschreiben hierfür 15 Dimensionen und haben sie empirisch priorisiert (Tabelle 2.7). Bemerkenswert ist die hohe Priorität subjektiv wahrgenommener Informationsqualitätsdimensionen (Lee et al., 2002). Niedrige Informationsqualität kann beträchtliche wirtschaftliche Konsequenzen (Batini et al., 2007; Pütter, 2007; Becker et al., 2009; Computerwoche, 2010) und sogar Katastrophen zur Folge haben (Fisher und Kingma, 2001). Die Kosten können sich auf bis zu 8-12% des Umsatzes belaufen (Lee et al., 2006, S. 14). Es muss daher betrachtet werden, wodurch sie beeinflusst wird (Kokemüller, 2011c). Wolf (2008) nennt vier Kategorien von Fehlerquellen, die die Informationsqualität beeinflussen: Prozessfehler, Anwenderfehler, Programmierfehler und Kundenfehler. Wolf arbeitet hierbei den Einfluss der Menschen (Anwender, Programmierer und Kunden) heraus. Demgegenüber identifizieren Cykana et al. (1996) vier Kategorien, die sich auf die Organisation und die Systeme beziehen: Prozessfehler, Systemfehler, Policyfehler und Datenbankfehler. Auf Basis dieser Kategorien ist es schwierig, Informationsqualität strukturiert zu erhöhen und welche Aktivitäten zuvorderst durchgeführt werden müssen (Ballou und Tayi, 1999), daher muss die Frage gestellt werden, welche Maßnahmen die Informationsqualität erhöhen (Bobrowski und Vazquez Soler, 2004; Batini et al., 2009). In Tabelle 2.8 wird eine solche Kategorisierung entworfen. Zu jeder Fehlerkategorie werden Maßnahmen zur Erhöhung der Informationsqualität aufgeführt. Informationsqualität wird häufig versucht in Projekten organisatorisch zu erhöhen (McGilvray, 2008). Allerdings zeigt sich, dass dies keinen langfristigen Einfluss auf die wahrgenommene Informationsqualität hat und somit keinen nachhaltigen Beitrag zur Wertschöpfung beiträgt (Kokemüller, 2011a). Auf organisatorischer Ebene werden daher nur die Bestandteile einer Data Governance Initiative berücksichtigt (Österle und Winter, 2003). 48

49 2.6 Stammdatenmanagement Darstellung 15 Angemessener Umfang Prio. Dimension Beschreibung 1 Glaubwürdigkeit Informationen sind glaubwürdig, wenn Zertifikate einen hohen Qualitätsstandard ausweisen oder die Informationsgewinnung und -verbreitung qualitativ hochwertig betrieben wurde. 2 Wertschöpfung Informationen sind wertschöpfend, wenn ihre Nutzung zu einer quantifizierbaren Steigerung einer monetären Zielfunktion führen kann. 3 Relevanz Informationen sind relevant, wenn sie für den Anwender notwendige Informationen liefern. 4 Fehlerfreiheit Informationen sind fehlerfrei, wenn sie mit der Realität übereinstimmen. Diese Dimension wird häufig weiter untergliedert in syntaktische und semantische Fehlerfreiheit, sowie Konsistenz. Eine wichtige Art semantischer Fehler sind Dubletten. 5 Interpretierbarkeit Informationen sind eindeutig interpretierbar, wenn sie in gleicher, fachlicher korrekter Weise begriffen werden. 6 Verständlichkeit Informationen sind verständlich, wenn sie unmittelbar von den Anwendern verstanden und für deren Zwecke eingesetzt werden können. 7 Zugreifbarkeit Informationen sind zugreifbar, wenn sie anhand einfacher Verfahren und auf direktem Weg für den Anwender abrufbar sind. 8 Objektivität Informationen sind objektiv, wenn sie streng sachlich und wertfrei sind. 9 Aktualität Informationen sind aktuell, wenn sie die tatsächlichen Eigenschaften des beschriebenen Objektes den Anforderungen entsprechend zeitnah abbilden. 10 Vollständigkeit Informationen sind vollständig, wenn sie nicht fehlen und zu den festgelegten Zeitpunkten in den jeweiligen Prozessschritten zur Verfügung stehen. Vollständigkeit wird häufig weiter differenziert in schematische Vollständigkeit (Vollständigkeit der Abbildung), Abdeckung (Vollständigkeit in Bezug auf Grundgesamtheit) und Dichte (Fehlende Werte eines Tupels) (Batini und Scannapieco, 2006). 11 Hohes Ansehen Informationen sind hoch angesehen, wenn die Informationsquelle, das Transportmedium und das verarbeitende System im Ruf einer hohen Vertrauenswürdigkeit und Kompetenz stehen. 12 Eindeutige Informationen sind eindeutig dargestellt, wenn genau die benötigten Informationen in einem passenden und leicht fassbaren Darstellung Format dargestellt sind. 13 Bearbeitbarkeit Informationen sind leicht bearbeitbar, wenn sie leicht zu ändern und für unterschiedliche Zwecke zu verwenden sind. 14 Einheitliche Informationen sind einheitlich dargestellt, wenn die Informationen fortlaufend auf dieselbe Art und Weise abgebildet werden. Informationen sind von angemessenem Umfang, wenn die Menge der verfügbaren Informationen den gestellten Anforderungen genügt. Tabelle 2.7: Informationsqualitätsdimensionen nach Wang und Strong (1996) und Rohweder et al. (2008) 49

50 2 Grundlagen, Vorarbeiten und Stand der Technik Da in dieser Darstellung unten stehende Kategorien durch höhere stehende beeinflusst werden, eignen sich weiter unten angesiedelte durch Implementierung von Informationssystemen, jedoch auch durch Prozessvorgaben besser für strukturierte und automatisierbare Maßnahmen (Strong et al., 1997a). Benutzen Mitarbeiter mehrere Systeme oder Mitarbeiter unterschiedlicher Abteilungen unterschiedliche Systeme, divergiert der Informationsgehalt und entsprechend die Informationsqualität dieser Systeme. Betroffen sind insbesondere die Dimensionen Aktualität, Bearbeitbarkeit, Glaubwürdigkeit, hohes Ansehen, Vollständigkeit und Zugänglichkeit. Die Heterogenität der Informationssysteme ist hierbei also eine wichtige Ursache niedriger Informationsqualität (Computerwoche, 2010). Kategorie Unterebene Maßnahme Organisation Data Governance Prozess Definition von Prozessen Verantwortlichkeiten Definition von Verantwortlichkeiten (z.b. Data Owner / Data Steward) Definition von Entscheidungskriterien Entscheidungskriterien Menschen Definition von guten und von allen verwendeten Schemata 9 Anwender Kenntnis der Anforderungen Schulung von Anwendern zur Sensibilisierung und Vermeidung von Anwenderfehlern Kunde Spezifikation der Anforderungen Programmierer Umsetzen der Anforderungen Testen von Informationssystemen Informationssystem Dubletten (vgl. Elmagarmid et al., 2007) Verwendung von Algorithmen zur Erkennung von Integration von Informationssystemen (Askira Gelman, 2009) Verwendung von Regeln zur Validierung eingegebener Daten Geeignete Benutzungsschnittstellen Tabelle 2.8: Maßnahmen zur Erhöhung der Informationsqualität Die Integration von Informationssystemen vermeidet ebendiese Komplikationen durch die technische Homogenisierung des Datenbestandes (Bergeron und Raymond, 1992; de Corbière, 2009). Für zwischenbetriebliche Prozesse bietet eine Informationsintegration zudem das Potential einer medienbruchfreien automatisierten Kommunikation. Allerdings ist Informationsintegration keine hinreichende Bedingung für eine Zunahme der Informationsqualität (Askira Gelman, 2010). 9 (Moody und Shanks, 2003) hat acht Dimensionen als relevant für gute Datenschemata identifiziert: Korrektheit, Vollständigkeit, Einfachheit, Flexibilität, Verständlichkeit, Integration, Implementierbarkeit und Integrität 50

51 2.6 Stammdatenmanagement Beispiel 1: Werden mehrere Systeme integriert, welche parallel unterschiedliche Informationen aktuell halten, so ist es vergleichsweise einfach möglich, immer die aktuellste Information global verfügbar zu machen. Die maximal verfügbare Informationsqualität in der Dimension»Aktualität«nimmt dann folglich zu. Wird hingegen ein fehlerfreier Datenbestand mit einem fehlerbehafteten Datenbestand zusammengeführt, so nimmt die maximal verfügbare Informationsqualität in der Dimension»Fehlerfreiheit«ab. Die Informationsintegration innerhalb von KMU-Wertschöpfungsnetzwerken ist daher geeignet, um die Informationsqualität global zu erhöhen. Allerdings sollten Mechanismen vorgesehen sein, welche einer Verminderung der Informationsqualität entgegen wirken Verortung des Stammdatenmanagement Informationen, die häufig verwendet werden, haben einen hohen Einfluss auf die unternehmensweite Informationsqualität. Insbesondere Stammdaten sind ein solcher Multiplikator. Weiterhin kommt Stammdaten eine besondere Bedeutung in der zwischenbetrieblichen Kooperation zu, denn durch sie wird ein gemeinsames Referenzsystem der Kommunikation ermöglicht. Daher wird der aktuelle Stand im Stammdatenmanagement eingehend betrachtet. Betriebliche Daten lassen sich in Bewegungsdaten, Bestandsdaten und Stammdaten einteilen (Abbildung 2.9) (Wedekind, 2001; Hansen und Neumann, 2009; International Organization for Standardization, 2009): Bewegungsdaten sind abwicklungsorientierte Daten, welche betriebliche Transaktionen beschreiben. Sie repräsentieren Handlungen 10 oder Ereignisse 11. Sie werden für jede Transaktion neu erstellt, ihr Volumen ist daher hoch. In einer relativ kurzen aktiven Zeit kann es zu häufigen Änderungen kommen, anschließend sind abgeschlossene Transaktionen nur noch von historischem Interesse. Auf sie wird dann in der Regel nur noch selten lesend zugegriffen. Bewegungsdaten Ereignisse und Handlungen Ändern Bestandsdaten Status von Stammdaten Abbildung 2.9: Beziehungen zwischen betrieblichen Datenkategorien 10 Bspw.: Aufträge, Auftragsbestätigungen, Bestellungen, Lieferscheine, Rechnungen oder Reklamationen aber auch Urlaubsanträge, Prüfberichte, Buchungen, Besuchsberichte u.v.m. 11 Bspw.: Schadensmeldungen, Protokolle, Krankmeldungen u.v.m. 51

52 2 Grundlagen, Vorarbeiten und Stand der Technik Bestandsdaten sind zustandsorientierte Daten, die die betriebliche Werte- und Mengenstruktur 12 beschreiben. Bestandsdaten unterliegen häufigen Änderungen durch betriebliche Transaktionen. Sie definieren den Zustand eines Stammdatenobjektes und unterliegen in der aktiven Phase dieses Objektes häufigen Änderungen. Stammdaten sind zustandsorientierte Daten. ISO 8000 (International Organization for Standardization, 2009) definiert Stammdaten als Daten einer Organisation, welche Entitäten beschreiben, die gleichzeitig unabhängig und fundamental für diese Organisation sind und die referenziert werden müssen, um Transaktionen durchzuführen. Die häufigsten von Anwendern genannten Stammdatenklassen sind (Russom, 2006): Kunden, Produkte, Kontorahmen, Geschäftspartner, Mitarbeiter, Liegenschaften und Inventar sowie je nach Branche weitere wie Patienten oder Versicherungspolicen. In der Produktion sind von besonderer Bedeutung Stücklisten und Arbeitspläne. Als solche werden sie über ihre gesamte, in der Regel lange, Lebensdauer in vielen betriebswirtschaftlichen Transaktionen verwendet (Tabelle 2.9). Stammdaten weisen in der Regel eine vergleichsweise geringe Änderungshäufigkeit auf, welche sich über den gesamten Lebenszyklus verteilt (Schemm, 2008). Datenart Bewegungsdaten Bestandsdaten Stammdaten Kriterium Reale Welt Handlung oder Situation Objekt Ereignis Beispiel Auftrag Lagerbestand Produkt Relative Menge Groß Mittel Gering Lebensdauer Mittel Gleich der aktiven Sehr lang Phase des Stammdatenobjektes Dauer der aktiven Phase Kurz Gleich der Lebensdauer Lang Anzahl Änderungen in Mittel Hoch Niedrig aktiver Phase Anzahl Änderung über gesamte Lebensdauer Niedrig Viele Mittel Tabelle 2.9: Charakteristiken betrieblicher Datenkategorien Durch ihre Verwendung in Bewegungsdaten beeinflusst die Qualität der Stammdaten die der Bewegungsdaten und hat somit Einfluss auf das betriebliche Ergebnis. Diese zentrale Position der Stammdaten wird in Unternehmen durch strategische Stammdatenmanagementprojekte aufgegriffen. Das optimale Ziel geht hierbei von der Betrachtung der Stammdaten als eigenständige wertschöpfende Entitäten aus, welche als sogenannte Informationsprodukte durch ganzheitliche organisatorische und technische Ansätze bewirtschaftet werden müssen (Ballou et al., 1998). Dies erfordert einen holistischen Produktionsprozess für Informationsprodukte gleich dem physischer Produkte (Spath und Krause, 2008). 12 Bspw.: Lagerbestand, Verfügbarkeit von Personal oder Arbeitsmitteln, Kontostand u.v.m. 52

53 2.6 Stammdatenmanagement Strategie Informationsqualitätsstrategie Führungssystem Prozesse Organisation und Standards Informationssysteme Datenmanagement- Prozesse Informationsarchitektur Systemarchitektur Abbildung 2.10: Handlungsfelder des Stammdatenmanagements nach Österle und Winter (2003) Hierfür ist es notwendig, der Stammdatenverwaltung eine adäquate organisatorische Struktur zu geben, welche sich ausgehend von der Strategieentwicklung in Führungssystemen niederschlägt und der Definition von Prozessen, Verantwortlichkeiten und Entscheidungskriterien bedarf (Abbildung 2.10). Die Implementierung dieser Organisationsstruktur benötigt für ihre operative Umsetzung Unterstützung durch IT Systeme (Wixom und Watson, 2001). Diese sollen in verteilten Systemen gehaltene Referenzen auf identische Realweltobjekte zusammenführen und den Informationsgehalt harmonisieren. Häufig wird zu diesem Zweck eine zentrale autoritative Replik 13 eingesetzt, welche als Ausgangspunkt für die Replizierung des Objektes in integrierte Informationssysteme dient (Kokemüller und Weisbecker, 2009). Unterschiedliche Architekturansätze des Stammdatenmanagements werden im folgenden Abschnitt beschrieben. Anschließend werden die Erwartungen der Anwender und die Umsetzung des Stammdatenmanagements durch kommerzielle Stammdatenmanagementsysteme 14 diskutiert. 13 Häufig bezeichnet als:»gold Copy«,»Master Copy«oder»Single Version of Truth«14 Im Folgenden durch MDM-Systeme für engl. Master Data Management-Systeme abgekürzt. 53

54 2 Grundlagen, Vorarbeiten und Stand der Technik Architekturen des Stammdatenmanagements Ein zentrales Ziel des Stammdatenmanagements ist es, eine zentrale autoritative Replik eines Stammdatums bereitzustellen (Russom, 2006). Hierfür kann es notwendig sein, einen eigenständigen Server zu betreiben. Zeichnet sich eine Architektur durch geringen Bedarf an Eigenentwicklungen aus, so kann sie durch allgemein verfügbare Produkte realisiert werden. Um die Datenqualität im Sinne der Vermeidung von Dubletten zu erhöhen, ist es notwendig, dass ein System über eine globale Sicht aller relevanten Stammdaten verfügt (Eschinger, 2008). Erfordert eine Architektur, dass ein einheitliches harmonisiertes Datenmodell verwendet wird, so benötigt sie tendenziell einen höheren Aufwand in der Realisierung, da zum einen das zentrale Schema und zum anderen Abbildungen aller Schemata auf dieses zentrale Schema erstellt werden müssen. Von speziellem Interesse in dieser Arbeit ist die Realisierbarkeit durch KMU. Dieses verlangt sowohl einen Homomorphismus der Stammdatenarchitektur mit der organisatorischen Struktur kooperierender KMU (Conway, 1968), als auch leichtgewichtige und finanzierbare Lösungen. Für Architekturen des Stammdatenmanagements ist ferner ein Kriterium, ob Daten virtuell und/oder materialisierend integriert werden. In der Praxis können drei Architekturvarianten im Stammdatenmanagement beobachtet werden (Legner und Otto, 2007). Aufgrund der Bedeutung der P2P-Architektur für diese Arbeit wird diese zusätzlich berücksichtigt. Die Architekturvarianten sind in Abbildung 2.11 dargestellt und werden in Tabelle 2.10 verglichen: Architektur Führendes Peer to Kriterium Zentral System Verzeichnis Peer Zentrale autoritative Replik Eigenständiger Server Geringer Bedarf für Eigenentwicklungen Globale Sicht Harmonisierung der Schemata Realisierbarkeit durch KMU Virtuelle Integration Materialisierende Integration Legende: trifft voll zu, triff weitgehend zu, trifft teilweise zu, trifft kaum zu, trifft nicht zu Tabelle 2.10: Gegenüberstellung der Architekturen des Stammdatenmanagements Die zentrale Architektur verfügt über ein zentrales System, in welches alle integrierten Stammdaten repliziert werden. Hierfür werden meistens CDC-Technologien (Kimball et al., 2008; Bauer und Günzel, 2009) eingesetzt. Change Data Capture (CDC) ist ein Ansatz aus dem Datawarehousing, der darauf abzielt atomare Änderungen im Datenbestand zu erkennen und unmittelbar weiterzuleiten. Das zentrale System hält die autoritative Replik und ist für die Verteilung an integrierte Systeme zuständig. Da dieses System über eine globale Sicht auf alle Daten verfügt, kann hierdurch ein homogener Datenbestand realisiert werden (Maedche, 2010). Diese Architektur kann daher als Hub-Topologie klassifiziert werden. Aufgrund der 54

55 2.6 Stammdatenmanagement Zentrales System Harmonisierung der Schemata niedrig hoch Führendes System für Produktdaten MDM-System ERP-System CRM-System Führendes System Führendes System für Kundendaten Für KMU geeignetster Quadrant ist unbesetzt Verzeichnis Informationssystem Informationssystem Informationssystem Verzeichnis Informationssystem Informationssystem Informationssystem Informationssystem Informationssystem Informationssystem zentral Stammdatenprozesse und Datenhaltung dezentral Abbildung 2.11: Architekturvarianten im Stammdatenmanagement bereits in Abschnitt diskutierten Gründe ist eine zentrale Architektur daher für die Integration von KMU-Wertschöpfungsnetzwerke ungeeignet. In der Architekturvariante des führenden Systems wird für jede Stammdatenklasse ein bestehendes Informationssystem ausgewählt, um den autoritativen Datenbestand zu führen. Hierdurch ist es nicht notwendig, ein weiteres System zu installieren, allerdings muss potentiell zu jedem führenden System eine weitere Schnittstelle implementiert werden, wodurch die Kosten in der Implementierung steigen. Abhängig von der Anzahl der integrierten und führenden Systeme ist dieser Architekturansatz eher als chaotische oder als Hub-Topologie zu klassifizieren. Die Architekturvariante des führenden Systems findet aufgrund ihres technischen Fokus nur in der betriebsinternen Stammdatenlogistik Anwendung (Schemm, 2008). Sie ist für eine betriebsübergreifende Integration, wie es sie in KMU-Wertschöpfungsnetzwerken ist, eine ungeeignete Integrationsform. Nur gering homogenisiert werden kann der Datenbestand durch die Architekturvariante des Verzeichnisses. Das Verzeichnis speichert lediglich Referenzen auf Systeme, welche konkrete Stammdatenobjekte halten. Es ist daher technisch unmöglich zu verhindern, dass eine Referenz auf ein Realweltobjekt mehrfach angelegt wird. Allerdings ermöglicht ein Verzeichnis, vollständig auf Repliken zu verzichten und vergrößert nicht das erforderliche Datenvolumen. 55

56 2 Grundlagen, Vorarbeiten und Stand der Technik Diese Variante eignet sich damit besonders für große verteilte Organisationen. Für KMUs bietet es in der Regel nur zu wenige Vorteile, um eine Umsetzung zu rechtfertigen, während die Kosten, bedingt durch die hier realisierte vollständig virtuelle Integration, in der Regel hoch sind. Diese Architekturvariante ist eine Kombination aus chaotischer und zentralistischer Topologie. Dies liegt darin begründet, dass die direkte Kommunikation paarweise organisiert ist, während der Kommunikationsaufbau über ein Bus- oder Hub-System organisiert wird. Beispiel 2: Das staatliche Gesundheitssystem Großbritanniens, der U.K. National Health Service (NHS), integriert über Systeme Krankenakten und Rezepte (Warnke, 2007). Da für diese Daten von ca. 50 Mio. Patienten eine zentrale Datenhaltung aufgrund ihres Volumens nebst rechtlichen Rahmenbedingungen nicht möglich ist, wird hier die Integration über ein Verzeichnis realisiert (Sun Java CAPS). Ein Verzeichnis eignet sich nur, wenn große Datenmengen innerhalb eines Netzwerkes mit klar definierten und definierbaren Vorgaben integriert werden sollen. Hierfür ist die organisatorische Struktur eine Voraussetzung, die für die Definition und Durchsetzung der Vorgaben zentralisiert sein muss. In der Analyse der Hemmnisse für KMU-Wertschöpfungsnetzwerke wurde deutlich, dass gerade eine zentrale Struktur ein wichtiges Hemmnis ist. Ein Verzeichnis ist daher für diesen Anwendungsfall keine geeignete Integrationsarchitektur. In Abbildung 2.11 werden die Architekturvarianten in zwei Dimensionen klassifiziert: Die durch sie erreichbare Harmonisierung der Datenschemata und Zentralität der Stammdatenprozesse und der Datenhaltung. Es wird deutlich, dass der Quadrant, der eine hohe Harmonisierung bei dezentraler Datenhaltung repräsentiert und daher für den Einsatz durch kleine autonome Unternehmen am besten geeignet wäre, unbesetzt bleibt Erwartung von Anwendern an Stammdatenmanagementsysteme Die Erwartungen von Anwendern an Stammdatenmanagementsysteme wurden von Mucha et al. (2009) untersucht 15. Um die Heterogenität der IT-Landschaften zu messen, wurde gefragt, welche Systemklassen 16 im Unternehmen eingesetzt werden. Es zeigt sich, dass im Durchschnitt 3,76 Systemklassen ( 1,888) eingesetzt werden (Abbildung 2.12). Dabei muss berücksichtigt werden, dass die angegebene Größe lediglich die Untergrenze der im Unternehmen real eingesetzten 15 Es wurde ein Fragebogen an deutschsprachige Anwenderunternehmen verschickt. Zielgruppe für die Erhebung waren Markenanbieter mittlerer Größe mit mindestens einer Million Euro Jahresumsatz und mindestens 50 Mitarbeitern. Nach der Definition der EU Kommission also mittlere Unternehmen (Europäische Union, 2003), welche ihren Vertrieb über Handelsvermittler und vertreter realisieren. Als Ansprechpartner wurde Geschäftsführer und IT-Leiter sowie Entscheider in den Bereichen Marketing, Produktmanagement und Vertrieb ausgewählt. Die Zielgruppe ist damit eine Untermenge der in Abschnitt 2.1 diskutierten Lieferantenunternehmen. Insgesamt beantworteten 179 Unternehmen den Fragebogen. Dies entspricht einer Rücklaufquote von 3,3%. 16 Gefragt wurde nach folgenden Klassen: ERP, PIM, Terminplanung, CMS, CRM, Transaktionsplattform, Unternehmenseigene Datenbanklösung und MDM 56

57 2.6 Stammdatenmanagement Systeme ist, da prinzipiell mehrere Systeme pro Systemklasse und auch Systeme anderer Klassen vorhanden sein können. Alle abgefragten Systemklassen verwenden Stammdaten. Aufgrund der Vielzahl vorhandener Systeme sollten ihre Stammdaten für eine höhere Informationsqualität integriert werden. Da jede Integration beträchtliche Kosten verursachen kann (Bernstein und Haas, 2008), ist es anzustreben, die Komplexität gering zu halten und einen hohen Grad an Wiederverwendung zu erreichen (Höß, 2005). Vor diesem Hintergrund wurde untersucht, welche Anforderungen an ein Stammdatenmanagementsystem gestellt werden: Für 72,2% muss es stets aktuelle Daten in den lokalen Datenspeichern der integrierten Informationssysteme garantieren. 92,4% der Befragten lehnen daher eine periodische Aktualisierung des Datenbestandes ab. Es wird also eine sofortige, asynchrone Verteilung von Änderungen gefordert. Hierfür ist nach Meinung von 68,3 % der Befragten ein dediziertes System notwendig. 86,2% akzeptieren, dass dieses MDM-System Daten paarweise zwischen integrierten Informationssystemen abgleicht, solange es Verfahren zur Erhöhung der Informationsqualität beinhaltet (89,2%). Insbesondere akzeptieren 80,4% der Befragten eine dezentrale Speicherung von Daten. Dies wird auch akzeptiert (68,2%), wenn dies eine verteilte autoritative Replik erfordert Stammdatenmanagementsysteme Zusätzlich wurde untersucht, welche Anforderungen von kommerziellen Stammdatenmanagementsystemen umgesetzt werden 17. Die betrachteten Produkte sind in Tabelle 2.11 zusammengefasst (Kokemüller, 2009). Anbieter Produktname Jahr der Markteinführung Anzahl Kunden weltweit IBM IBM InfoSphere MDM Server for PIM Oracle Oracle Customer HUB-Version 2002 k.a. SAP SAP NetWeaver Master Data Management STIBO Systems STEP >150 Sun Microsystems Java CAPS (Composite Application Platform Suite) 1995 >450 TIBCO Software TIBCO Collaborative Information Manager (CIM) 2005 >10 Tabelle 2.11: Untersuchte Stammdatenmanagementsysteme Kommerzielle Stammdatenmanagementsysteme unterscheiden sich im Fokus ihrer Einsatzgebiete. Hier hängt die Unterstützung von Datenaustauschstandards eng mit ihrer Eignung für eine betriebsübergreifende Nutzung zusammen. Primär integrieren diese Systeme Stammdaten materialisierend, jedoch sind auch Ansätze zur virtuellen Integration erkennbar. 17 Hierfür wurde im ersten Schritt der Markt sondiert. Sechs Anbieter mit deutschsprachiger Kundenbetreuung wurden identifiziert. Im zweiten Schritt wurden an jeden dieser Anbieter zwei Fragebögen gesendet. Diese enthielten Fragen zu insgesamt 45 Themenkomplexen. 57

58 2 Grundlagen, Vorarbeiten und Stand der Technik 40% 39% 35% Häufigkeit in Prozent 30% 20% 10% 0% 27% 24% 19% 15% 11% 7% 2% Anzahl eingesetzter Systemklassen Abbildung 2.12: Anzahl unternehmensintern eingesetzter Systemklassen Standardtechnologien können auch im Bereich der Datenhaltung und Transformation verwendet werden. Aufschluss geben Kriterien, ob XML-Transformationen allgemein unterstützt werden. Da von primärem Interesse die Verwendung von Standards ist, ist hierbei irrelevant welche Technologie (XSLT oder XQuery) genau eingesetzt wird. Die Unterstützung von XML muss weiterhin darin unterschieden werden, ob wohlgeformtes oder gültiges XML unterstützt wird. Gerade um die Konformität der betriebsinternen Prozesse mit gesetzlichen oder organisatorischen Vorgaben (Compliance) nachweisen zu können, ist es wichtig, dass Stammdatenmanagementsysteme eine Versionshistorie realisieren (Kokemüller, 2010). Mechanismen zur Erkennung von Dubletten sind in allen Stammdatenmanagementsystemen enthalten. Algorithmen zur Dublettenerkennung sind allerdings nur eine notwendige, keine hinreichende Bedingung zur Erlangung einer hohen Datenqualität (Friedman und Bitterer, 2009). Hierfür sind vielmehr organisatorische Maßnahmen notwendig, welche wiederum technisch unter anderem durch die Realisierung von Arbeitsplänen unterstützt werden müssen. Grafische Benutzungsschnittstellen sind für eine Verwendung durch Fachanwender unabdingbar. Interessant ist hier, inwieweit der Fachanwender wissen muss, dass ein Stammdatenmanagementsystem eingesetzt wird. Ist kein Wissen notwendig, so ist das System darauf ausgelegt, dass alle Benutzerinteraktion über die ohnehin vorhandenen Unternehmensanwendungen realisiert werden können. Eine technische Unterstützung organisatorischer Data Governance Prozesse ist dann durch das System nicht möglich (Tabelle 2.12). 58

59 2.6 Stammdatenmanagement System IBM InfoSphere MDM Oracle Customer Hub SAP NetWeaver MDM Kriterium Verwendung von Datenaustauschstandards Fokus auf innerbetriebliche Nutzung Materialisierende Integration Virtuelle Integration Unterstützt XML-Transformationen Unterstützt wohlgeformtes XML Unterstützt gültiges XML Realisiert Versionshistorie Beinhaltet Dublettenerkennung Realisiert Arbeitsplan für Bereinigung Grafische Benutzungsschnittstelle Notwendigkeit der Kenntnis des Fachanwenders über Existenz des Stammdatenmanagementsystems Legende: trifft voll zu, triff weitgehend zu, trifft teilweise zu, trifft kaum zu, Stibo Step 5 Sun CAPS TIBCO CIM Tabelle 2.12: Vergleich kommerzieller Stammdatenmanagementsysteme trifft nicht zu Bei der Betrachtung wird deutlich, dass fast alle Produkte als zentralisierte Architektur ausgelegt sind. Nur Sun Java CAPS ist primär als Verzeichnis ausgelegt. Für eine zentralisierte Architektur ist es notwendig, ein Serversystem mit einem zentralen Schema aufzusetzen und anschließend alle relevanten Informationssysteme mit diesem zentralen System zu integrieren. Dies ist mit einem hohen Aufwand verbunden (Puschmann und Alt, 2004), der für KMU kaum finanzierbar ist. Für die Integration innerhalb von KMU-Wertschöpfungsnetzwerken bedürfte es daher eines Systems, das dediziert für die Integration von Stammdaten verantwortlich ist, dabei jedoch eine dezentrale Struktur aufweist. Ein Peer-to-Peer (P2P) System erfüllt diese Kriterien. Der zentrale Ausgangpunkt bei P2P basierenden Systemen ist, dass alle Beteiligten unabhängig sind bezüglich dessen, was sie tun können (Walter et al., 2006). Hierbei wird also eine deutlich höhere Autonomie angestrebt. Es kann davon ausgegangen werden, dass dieser Ansatz für kleine und mittlere Unternehmen (KMU) deutliche Kostenvorteile ermöglicht (Schönemann et al., 2009) Zusammenfassende Bewertung Stammdaten sind für Unternehmen von zentraler Bedeutung. Aufgrund ihrer häufigen Verwendung in betrieblichen Transaktionen ist ihre Informationsqualität von großer Relevanz und beeinflusst die Informationsqualität der Bewegungsdaten. Soll die Komplexität eines Integrationsprojektes begrenzt werden, ist die Beschränkung auf Stammdaten daher eine sinnvolle Reduktion. 59

60 2 Grundlagen, Vorarbeiten und Stand der Technik Stammdatenmanagement ist eine Disziplin, welche zuerst organisatorische Herausforderungen bewältigen muss. Integraler Bestandteil einer langfristigen Umsetzung einer Stammdatenstrategie ist jedoch auch die technische Integration von Informationssystemen. Vom Standpunkt der Informationsqualität ist die zentrale Anforderung, dass eine autoritative Replik eines Stammdatums verwaltet wird. Unternehmensintern wird hierfür bevorzugt auf zentrale Systeme zurückgegriffen. Solange eine autoritative Replik gewährleistet wird, wird jedoch auch eine dezentrale Umsetzung akzeptiert. 2.7 Virtuelle und materialisierende Integration Zwei Ansätze zur Informationsintegration können unterschieden werden: materialisierende und virtuelle Integration (siehe auch Tabelle 2.13) Vergleichende Darstellung In der materialisierenden Integration werden Daten aus dem System, in dem sie entstanden sind, in das System, das auf sie zugreifen möchte, repliziert. Im Resultat werden Daten dadurch mehrfach gespeichert und liegen bei jedem zugreifenden System als lokale Replik vor. Dies hat mehrere Konsequenzen: Durch redundante Datenhaltung ist ein mehrfacher Speicherbedarf notwendig. In einem System geänderte Daten stehen in anderen Systemen erst zur Verfügung, nachdem sie dorthin repliziert wurden. Ein System verfügt jederzeit über eine umfassende Sicht auf alle Daten. Es können daher auch Informationsqualitätsalgorithmen, die eine solche Sicht benötigen, ausgeführt werden. Da bei diesem Integrationsparadigma der Anwender in der Regel nicht auf die Antwort der Integrationsfunktion warten muss, sondern unabhängig davon arbeitet, sind hierbei höhere Latenzzeiten 18 der Integrationsfunktion tolerierbar. Daher sind die Anforderungen an die Bereitstellung und die Integration von Daten geringer und können mit geringerem Aufwand realisiert werden. Im operativen Betrieb muss ausschließlich auf einen lokalen Datenspeicher zugegriffen werden. Die Latenzzeit für den lokalen Zugriff wird daher durch die Integration nicht beeinflusst. Weiterhin behindert ein Ausfall der Netzwerkinfrastruktur nicht den lokalen Betrieb des Informationssystems. Lediglich die Aktualität der verfügbaren Daten nimmt in diesem Fall mit der Zeit ab. Dies ermöglicht insbesondere auch den Anwendungsfall der Offline- Synchronisation mobiler Geräte. Beim Ansatz der virtuellen Integration wird hingegen auf verteilte Datenspeicher zurückgegriffen. Es ist daher nicht notwendig, dass alle Daten in einem Datenspeicher zusammenge- 18 Bezeichnet die Zeit zwischen Funktionsaufruf und der Verfügbarkeit des Funktionsergebnisses. 60

61 2.7 Virtuelle und materialisierende Integration führt werden. Hingegen ist es erforderlich, dass potentiell für jeden Datenzugriff auf entfernte Systeme zugegriffen werden muss. Die Konsequenzen hiervon sind: Jeder Datensatz muss nur einmal gespeichert werden. Da jeder Datensatz nur einmal physisch existiert, stehen Änderungen an diesem Datensatz allen Systemen unmittelbar zur Verfügung. Eine Informationssenke verfügt nicht über eine vollständige Sicht auf alle Daten. Algorithmen zur Erhöhung der Informationsqualität, die alle Informationen sehen müssen, können daher nicht realisiert werden. Soll ein System seine Daten für andere Systeme zur Verfügung stellen, so muss es hierfür entsprechende Schnittstellen anbieten. Da die Latenzzeit der Informationssenke hierbei direkt von der Latenzzeit der Informationsquelle abhängt, existieren hohe Anforderungen an solche Schnittstellen. Der Aufwand für ihre Realisierung ist entsprechend hoch. Da eine Informationssenke auf entfernte Informationsquellen zugreift, muss es speziell hierfür ausgelegt sein. Dies ist im Allgemeinen nicht der Fall. Sie müssen daher entweder aufwändig angepasst oder durch ein System ersetzt werden, das diese Funktionalität unterstützt. Für beide Alternativen ist der Aufwand sehr hoch (Haas, 2006) Die Antwortzeit eines Systems, das virtuelle Informationsquellen integriert, ist nicht deterministisch. Dies liegt begründet in nicht oder nur schwer kontrollierbaren externen Einflüssen wie der Netzwerklatenz oder der Latenz der Informationsquellen. Bei einem Ausfall der Netzwerkinfrastruktur ist ein Zugriff auf virtuelle Informationsquellen nicht möglich. Wenn redundante Datenspeicherung durch virtuelle Integration vermieden werden soll, können diverse Nachteile entstehen (Schwinn und Schelp, 2005): Die Verfügbarkeit aller Komponenten Fachanwendungen, zentrale Datenbank, EAI Infrastruktur, Netzwerkinfrastruktur, usw. muss zu allen Zeiten gewährleistet sein. Der Ausfall einer Komponente verhindert den Einsatz des gesamten Systems. Alle Komponenten müssen über hohe Kapazitätsreserven verfügen. Die gesamte Kapazität muss die kombiniert Last aller Systeme abdecken. Wartung, Weiterentwicklung und Test sind komplexer aufgrund der erhöhten Anforderungen an Verfügbarkeit, Kapazität, Geschwindigkeit, etc. Die Veräußerung von Unternehmensteilen ist schwieriger, wenn eine zentrale Datenbank vorhanden ist. Obige Aspekte sind dann als entscheidender Nachteil zu werten, wenn die finanziellen Möglichkeiten kleiner Unternehmen hierdurch überfordert werden. Tabelle 2.13 stellt die Eigenschaften virtueller und materialisierender Information einander gegenüber. 61

62 2 Grundlagen, Vorarbeiten und Stand der Technik Virtuelle Integration Geringer Speicherbedarf Hohe Aktualität der Daten Hohe Homogenität der Daten Gute Möglichkeiten zur Duplikatseleminierung Geringer Aufwand für die Bereitstellung einer weiteren Informationsquelle Geringer Aufwand für den Konsum einer weiteren Informationsquelle Die durch Externe produzierte Last ist abschätzbar Die operative Zugriffszeit ist gering Materialisierende Integration Hohe Unabhängigkeit von der Netzwerkinfrastruktur Legende: trifft voll zu, triff weitgehend zu, trifft teilweise zu, trifft kaum zu, trifft nicht zu Tabelle 2.13: Gegenüberstellung virtueller und materialisierenden Integration Virtuelle Integration findet häufig Anwendung bei Meta-Suchmaschinen. Eine bekannte Architektur wurde hierfür in der Wrapper/Mediator Architektur durch Wiederhold (1992) beschrieben und später durch Roth und Schwarz (1997) erweitert. Materialisierende Integration haben als bekannten betrieblichen Anwendungsfall Data Warehouses (Jarke et al., 2003; Kimball et al., 2008) Zusammenfassende Bewertung Beide Integrationsvarianten benötigen die wechselseitige Abbildung von Schemata, um die Repräsentation der Daten transformieren zu können. Virtuelle Integration hat den entscheidenden Nachteil, dass für ihre Umsetzung der Abfrageplan der Informationssenke geändert werden muss (Haas et al., 2010). Üblicherweise sind hierzu nur hoch komplexe Softwarelösungen in der Lage. Aufgrund ihrer hohen Anschaffungs- und Betriebskosten werden diese Systeme allerdings kaum von KMU eingesetzt. Im Gegensatz dazu werden in der materialisierenden Integration die Daten in die Informationsquelle des konsumierenden Systems integriert. Dies kann durch eine externe Komponente realisiert werden. Die Anforderungen an eine solche Komponente sind zudem deutlich geringer als sie an ein virtuell integrierbares Informationssystem sind. Zudem steht eine solche Komponente unter der vollen Kontrolle desjenigen, der die Integration implementiert. Sie lässt sich daher einer Vielzahl architektonischer Varianten anpassen, ohne die Informationssenke ändern zu müssen. Für die IT-Integration innerhalb von KMU-Wertschöpfungsnetzwerke stellt die materialisierende Integration also deutlich geringere Anforderungen verglichen mit der virtuellen Integration. Um das wirtschaftliche Optimum im Sinne einer Kosten-Nutzen Optimierung für die Informationsqualität durch Integration zu erreichen (Capiello und Comuzzi, 2009) ist materialisierende Integration daher vorzuziehen. 62

63 2.8 Replikation 2.8 Replikation Durch materialisierende Integration werden Daten zwischen Informationssystemen repliziert. Hierfür stehen pessimistische und optimistische Verfahren zur Verfügung Pessimistische Replikation Durch Replikation sollen im Allgemeinen Kopien eines Objektes auf mehreren Systemen konsistent gehalten werden. Traditionelle Replikationstechniken versuchen eine Ein-Kopie Konsistenz zu schaffen, d.h. sie möchten die Illusion vermitteln, dass auf eine einzige hochverfügbare Kopie eines Objektes zugegriffen wird (Bernstein et al., 1987). Dieses Ziel kann auf vielen Wegen erreicht werden, der Ansatz bleibt jedoch gleich: traditionelle Verfahren blockieren den Zugriff auf ein Objekt, solange es nicht nachweislich auf dem neuesten Stand ist. Diese Algorithmen werden daher pessimistisch genannt, denn sie gehen davon aus, dass sich ein Objekt geändert hat. Kommerziell weit verbreitete Systeme wählen etwa eine primäre Replik. Diese ist für den Zugriff auf das Objekt verantwortlich und verteilt alle Operationen an sekundäre Repliken (Bernstein et al., 1987). Pessimistische Verfahren eignen sich daher gut in lokalen Netzen, die geringe Latenzen aufweisen und selten ausfallen. Zur Replikation über das Internet sind sie allerdings aus drei Gründen ungeeignet (Saito und Shapiro, 2005): 1. Das Internet bleibt langsam und unzuverlässig. Die Latenz und die Verfügbarkeit verbessern sich nicht (Zhang et al., 2000; Chandra et al., 2001). Versucht ein pessimistischer Algorithmus eine nicht verfügbare Replik zu aktualisieren, so blockiert er. Abhängige fachliche Funktionalitäten werden hierdurch mit blockiert. 2. Pessimistische Algorithmen skalieren schlecht. Es ist schwierig, ein großes, pessimistisch replizierendes System aufzubauen. Insbesondere wenn viele Operationen propagiert werden müssen sinken der Durchsatz und die Verfügbarkeit mit zunehmender Anzahl an Systemen. 3. Einige menschliche Tätigkeiten verlangen asynchronen Datenaustausch. Systeme, bei denen Menschen in relativer Isolation arbeiten 19 funktionieren besser, wenn konkurrierende Operationen erlaubt und nachträglich Konflikte aufgelöst werden Optimistische Replikation Optimistische Algorithmen gehen hingegen davon aus, dass Konflikte nur selten entstehen (Demers et al., 1987). Hieraus ergibt sich ein entscheidender Unterschied: Optimistische Verfahren erlauben, dass Daten ohne a priori Synchronisation gelesen oder geschrieben werden (Kung und Robinson, 1981). Operationen werden im Hintergrund propagiert (Barrett et al., 1996) und Konflikte werden behoben, nachdem sie aufgetreten sind. Informationssysteme profitieren vielfach durch optimistische Replikation (Saito und Shapiro, 2005): Ihre Verfügbarkeit bleibt erhalten, auch wenn das Netzwerk instabil ist. Sie skalieren besser, da weniger Aufwand für die Synchronisation notwendig ist. Ihre Autonomie bleibt 19 Bspw. CAD-Systeme oder Versionskontrollsysteme in der Softwareentwicklung 63

64 2 Grundlagen, Vorarbeiten und Stand der Technik erhalten, sie können asynchrone Zusammenarbeit erlauben, und schließlich können Operationen sofort lokal ausgeführt werden, ohne auf andere Systeme warten zu müssen. Viele internetbasierende Dienste (bspw. Usenet oder DNS) sind daher optimistisch. Allerdings entstehen auch Nachteile. Jedes verteilte System muss zwischen Verfügbarkeit und Konsistenz abwägen. Pessimistische Algorithmen erhöhen die Konsistenz auf Kosten der Verfügbarkeit; optimistische hingegen verringern die Konsistenz zu Gunsten der Verfügbarkeit. Es müssen daher Wege gefunden werden, wie divergierende Repliken und widersprüchliche Operationen zueinander in Einklang gebracht werden können. Optimistische Replikation ist deshalb nur für Systeme anwendbar, für die eine geringe Anzahl an Konflikten erwartet wird. Die Praxis zeigt, dass dies in vielen Fällen gegeben ist (Wang et al., 2002). Der morphologische Kasten in Tabelle 2.14 stellt die Freiheitsgrade gegenüber, die im Design eines Systems zur optimistischen Replikation bestehen. Die einzelnen Freiheitsgerade werden unten diskutiert. Hervorgehoben sind die Freiheitsgerade, die in der Integration von KMU-Wertschöpfungsnetzwerken bestehen. Jedes System, dessen Daten repliziert werden, wird als Knoten in einem Netzwerk verstanden. Als Master wird ein Knoten bezeichnet, der schreibberechtigt ist. Die Anzahl Master gibt an, ob nur ein Knoten, bestimmte ausgezeichnete Knoten oder alle Knoten schreibberechtigt sind. Unterschieden werden kann hier also zwischen zentralen, hybriden und dezentralen Architekturen (Yang und Garcia-Molina, 2001). Innerhalb von KMU-Wertschöpfungsnetzwerken muss im Allgemeinen jedes System autonom in der Lage sein, seine Daten zu bearbeiten. Ausnahmen hiervon können nur Systeme sein, welche Informationen lediglich darstellen und keine Änderungen erlauben. Hierzu gehören analytische Systeme wie Data Warehouses. Freiheitsgrad Mögliche Ausprägungen Anzahl Master M M 1 1 M N M N ( N : Anzahl Knoten) Operationen Zustände Änderungen Ausführungsplan Zeitstempel Versionsvektoren Semantisch Konflikterkennung Zeitstempel Versionsvektoren Semantisch Konfliktlösung Ignorieren Manuell Automatisch Hybrid Kommunikation Pull Push Hybrid Epidemisch Topologie Statisch Variabel Ad-hoc Konsistenzversprechen 1SR Limitierte Divergenz Eventuelle Konvergenz Tabelle 2.14: Morphologischer Kasten der Freiheitsgrade von Algorithmen zur optimistischen Replikation und ihre Realisierungsmöglichkeiten in KMU- Wertschöpfungsnetzwerken Ein weiteres wichtiges Unterscheidungskriterium ist die Art der Operationen, die propagiert werden. Ein System kann so ausgelegt sein, dass immer das vollständige geänderte Objekt propagiert wird. Hierbei ist kein semantisches Wissen über die Struktur eines Objektes notwendig, allerdings werden potentiell große Datenmengen transportiert. Da zusätzlich die 64

65 2.8 Replikation genaue Auswirkung einer Operation nicht bekannt ist, ist es in den meisten Fällen unmöglich zu entscheiden, ob zwei Operationen kommutieren. Kommutierende Operationen können vertauscht werden und stehen daher nicht in Konflikt zueinander. Zum Preis einer höheren Komplexität werden diese Nachteile von Systemen gelöst, die die Änderungen zwischen zwei Zuständen in Form von Operationen propagieren. Für die Integration von KMU-Wertschöpfungsnetzwerken muss beachtet werden, dass der Integrationsfunktion zur Laufzeit nur durch KMU finanzierbare Ressourcen zur Verfügung stehen. Weiterhin müssen möglichst viele potentielle Konflikte automatisiert gelöst werden. Beides lässt sich nur durch die Propagierung von Operationen realisieren. Die Reihenfolge, in der Operationen in den Ausführungsplan übernommen werden, kann durch syntaktische Eigenschaften bestimmt werden. In diesem Fall ist die Ordnung durch Zeitstempel oder Versionsvektoren vorgegeben. Ist anwendungsspezifisches semantisches Wissen verfügbar, so kann ein Ausführungsplan gelegentlich konfliktfrei gestaltet werden, indem Operationen vertauscht werden. Identische Möglichkeiten stehen zur Konflikterkennung zur Verfügung. Die Verwendung semantischen Wissens erscheint erstrebenswert, da hierdurch Konflikte automatisiert gelöst werden können, die ohne Semantik manuell gelöst werden müssen. Die Implementierung semantischer Ausführungspläne und Konflikterkennungen ist jedoch sehr aufwändig und im Allgemeinen auch nur für einfache Anwendungsfälle realisierbar (Saito und Shapiro, 2005). In der Praxis sind daher nur Zeitstempel oder Versionsvektor-basierende Verfahren realisierbar. Viele Systeme ignorieren Konflikte schlichtweg. Ein weiterer häufig verfolgter Ansatz zur Konfliktlösung ist die manuelle Bearbeitung. Aufwändiger gestalten sich Ansätze, die Konflikte automatisiert beheben sollen. In der Regel benötigen sie semantisches Wissen, weshalb sie wie auch semantische Ansätze zur Konflikterkennung nur für sehr einfache Problemstellungen praktisch umsetzbar sind. Einen Mittelweg hierzu gehen hybride Ansätze. Bei der Integration betrieblicher Informationssysteme ist es weder möglich, Konflikte zu ignorieren, noch wegen des hohen operativen Aufwands vollständig manuell zu lösen. Eine vollständige Automatisierung ist zum einen wegen des hohen Implementierungsaufwandes, zum anderen beim Auftreten komplexer semantischer Konflikte ohne die Bewertung durch einen Menschen nicht realisierbar. Praktikabel ist daher nur ein hybrider Ansatz, welcher möglichst viele Konflikte automatisiert solange dies syntaktisch und damit anwendungsfallübergreifend realisierbar ist und verbleibende Konflikte manuell löst. In der Kommunikation zwischen Knoten können vier Muster unterschieden werden: Bei der Pull-Kommunikation erfragt ein Knoten alle Operationen eines anderen Knoten. Im Gegensatz hierzu publiziert ein Knoten seine Operationen in der Push-Kommunikation proaktiv (Barrett et al., 1996). Letztere kann gelegentlich zu Fehlern führen, in diesem Fall können beide Muster in einem hybriden Muster kombiniert werden. Eine besondere Variante der Push-Kommunikation bildet die epidemische Kommunikation (Demers et al., 1987). Hierbei werden Operationen einer zufälligen Anzahl Knoten übermittelt, welche diese auf die gleiche 65

66 2 Grundlagen, Vorarbeiten und Stand der Technik Art weiterverteilen. Eine Operation breitet sich hierbei ähnlich einer Epidemie nicht deterministisch aus. Wang et al. (2002) zeigen, dass die niedrigste Konfliktrate erreicht werden kann, wenn die Zeitspanne zwischen einer Änderung und ihrer Verteilung minimiert wird. Dies kann in einer epidemischen Verteilung nicht erreicht werden. In einem Pull-Ansatz ist dies möglich, allerdings bedingt dies eine häufige Abfrage über eventuelle Änderungen und damit einen unnötigen Netzwerkverkehr. Eine Integration in KMU-Wertschöpfungsnetzwerken sollte daher entweder als Push oder als Hybride-Kommunikation erfolgen, da diese eine zeitnahe Erkennung von Änderungen ohne hohe Belastung des Netzwerkes erlauben. Einige Systeme definieren eine statische Topologie. In diesem Fall werden Operationen über einige fest definierte Kanten zu anderen Knoten propagiert. In einer variablen Topologie können Beziehungen änderbar sein oder es ist nicht definiert, welche statisch definierten Kanten benutzt werden. Ad-hoc Netzwerke bilden das andere Extrem. Hier werden Operationen zu zufällig ausgewählten Knoten propagiert. Letzteres ist insbesondere im Zusammenhang mit epidemischer Kommunikation anzutreffen. Integration in KMU-Wertschöpfungsnetzwerken bedeutet, dass Informationen in stabilen Geschäftsbeziehungen ausgetauscht werden. Die Integrationsfunktion darf sich daher nur definierter Austauschpfade bedienen. Allerdings unterliegen sie auch Änderungen, weshalb eine Topologie konfigurierbar sein soll und nicht statisch definiert. Wie oben erwähnt, verfügen Systeme, die optimistisch replizieren, über eine abgeschwächte Konsistenz. Das Konsistenzversprechen, das die höchste Konsistenz verspricht, ist»single-copy serializability«(1sr). Hier wird angestrebt, dass alle Zugriffe auf allen Knoten denselben Effekt erzielen wie sie eine serielle Ausführung auf einem Knoten hätten (Bernstein und Goodman, 1983). Die meisten Systeme streben allerdings das andere Extrem an. Hier wird angenommen, dass nach gewisser Zeit alle Operationen durch alle Knoten ausgeführt wurden. Knoten konvergieren also eventuell. Einen Mittelweg gehen Systeme, die limitierte Divergenz versprechen. Hierbei muss gemessen werden, wieweit Repliken divergieren. Wird ein Grenzwert überschritten, werden diese Repliken gesperrt und synchronisiert. Technisch lose gekoppelte Systeme, betrieben von Partnern in KMU-Wertschöpfungsnetzwerken, dürfen in ihrer operativen Funktionalität durch die Integration nicht eingeschränkt werden. Daher kann nur eine eventuelle Konsistenz garantiert werden, da dies das einzige Konsistenzversprechen ist, welches Repliken und damit Informationssysteme nicht sperren muss. Optimistische Replikation in betrieblichen Informationssystemen abgesehen vom Aspekt der Synchronisation zur Bereitstellung von Offlinefähigkeit wurde im Forschungsprototypen Bayou (Terry et al., 1995) realisiert. Allerdings zielt die Verwendung in Bayou auf die Verteilung einer Datenbank mit einem Schema, wobei entstehende Konfliktsituation diskutiert und gelöst werden. Demgegenüber stellt die optimistische Integration von Informationssystemen durch die Heterogenität der Anwendungsdomäne weitergehende Anforderungen, welche auf diese Art bisher nicht gelöst wurden. 66

67 2.9 Integrationsparadigmen in Unternehmen Abgrenzung zu Transaktionen Optimistische Replikation ist verwandt mit fortgeschrittenen Transaktionsmodellen (Elmagarmid, 1992). Beide schwächen die ACID-Anforderungen (siehe Tabelle 2.15) traditioneller Datenbanken ab, um hierdurch die Geschwindigkeit und Verfügbarkeit zu erhöhen (Do et al., 1999). Allerdings ist ihre Zielstellung unterschiedlich. Eine Transaktion gruppiert im Allgemeinen mehrere Operationen und verlangt u.a., dass diese atomar ausgeführt werden. Diese Anforderung wird für verteilte Transaktionen aufrechterhalten. Hierdurch entsteht ein hoher Aufwand in der Koordinierung verteilter Systeme, damit eine Transaktion systemübergreifend entweder erfolgreich abgeschlossen oder restlos rückgängig gemacht wird (Elmasri et al., 2009). Ursprünglich wurden Transaktionen entwickelt, um auf einem isolierten Datenbanksystem zu laufen. Verteilte Transaktionen sind jedoch auch in gut verbundenen Netzwerken ausführbar. Im Gegensatz dazu werden durch Replikation konsistente, dauerhafte Ergebnisse von Transaktionen verteilt. Ihr Ziel ist es, hohe Autonomie und Asynchronität herzustellen. Operationen werden im Hintergrund ausgetauscht, oftmals lange nachdem zugehörige Transaktionen erfolgreich abgeschlossen wurden (Saito und Shapiro, 2005). Anforderung Beschreibung Atomar Es werden alle Operationen einer Transaktion oder keine ausgeführt. Schlägt eine Operation einer Transaktion fehl, so müssen daher aller vorangegangenen Operationen dieser Transaktion rückgängig gemacht werden. Konsistent Die Datenbasis wird von einem konsistenten in einen nicht notwendigerweise verschiedenen konsistenten Zustand überführt. Isoliert Laufende Transaktionen sehen sich nicht gegenseitig. Das Ergebnis einer Transaktion wird daher erst nach einem erfolgreichen»commit«einer Transaktion für andere Transaktionen sichtbar. Dauerhaft Der Endzustand wird persistiert. Das Ergebnis einer Transaktion, die durch ein»commit«abgeschlossen wurde, muss auch nach einem kompletten Systemausfall wiederhergestellt werden. Tabelle 2.15: ACID-Anforderungen (vgl. Kemper und Eickler, 2009) 2.9 Integrationsparadigmen in Unternehmen Oben diskutierte Ansätze und Technologien werden in unterschiedliche Arten durch Unternehmen zur Integration ihrer Informationssysteme eingesetzt. Insbesondere haben sich drei Integrationsparadigmen durchgesetzt. In der»enterprise Application Integration«(EAI) werden durch sog. Konnektoren Verbindungen zu Applikationen aufgebaut. Die Integration wird üblicherweise durch den Austausch von Nachrichten realisiert und ist prozessorientiert. Die Weiterentwicklung dieses Ansatzes hat zu»service-orientierten Architekturen«(SOA) geführt. Hierbei sind die Anforderungen an die integrierten Informationssysteme höher, da verlangt wird, dass diese ihre Funktionalitäten als Services ohne Konnektoren bereitstellen. Einen anderen Ansatz verfolgt das»electronic Data Interchange«(EDI), welches im Wesentlichen den Nachrichtenaustausch standardisiert. 67

68 2 Grundlagen, Vorarbeiten und Stand der Technik Gängige Integrationsparadigmen haben eine hohe Komplexität, was ihre Realisierung in KMU häufig verhindert. Wichtige Kriterien zur Unterscheidung der Paradigmen sind die Art der Kommunikation und der unterstützten Integrationsebenen 20. Eine hohe Flexibilität zur Laufzeit bzw. geringe Kosten für Reorganisationen soll durch eine lose Kopplung der Komponenten erreicht werden. Lose Kopplung wird auch unter dem Gesichtspunkt verfolgt, hierdurch eine geringere Bindung an einen Hersteller oder eine spezifische Infrastruktur zu erreichen. Dies ist jedoch nur der Fall, wenn sich Hersteller an relevante Standards halten (Shapiro und Varian, 1999; Themistocleous et al., 2004). Relevant für Standardisierungen sind die Architektur, der technischen Informationsaustausch und die Datenaustauschformate Enterprise Application Integration (EAI) Integration in einer EAI wird in der Regel durch den Austausch von Nachrichten umgesetzt (Hasselbring, 2000). Produkte aus dieser Kategorie erlauben üblicherweise materialisierende und auch virtuelle Integration. Ein Konnektor bildet die Schnittstelle zwischen Informationssystem und integrierender Middleware. Er beobachtet das Informationssystem und ist für die Verfügbarmachung geänderter Daten verantwortlich. EAI Systeme sind schwergewichtige Softwaresysteme, welche insbesondere auf Prozessebene (Leser und Naumann, 2007) Unternehmensanwendungen integrieren können. EAI-Systeme sind heutzutage in vielen großen Unternehmen im Einsatz. Ihr primäres Anwendungsszenario ist die betriebsinterne Integration. Sie ermöglichen die effiziente Integration von Unternehmensanwendungen über eine zentrale Softwareinstanz. Alle Konnektoren sind dafür mit einer zentralen Komponente verbunden. Üblich sind sowohl Hub als auch Bus- Systeme (Puschmann und Alt, 2004). Dies hat den Vorteil, dass ein einheitlicher Zugang zu allen integrierten Systemen geboten wird. Diese zentrale Instanz ist ein Serversystem, welches von kleinen Unternehmen mit geringen finanziellen und personellen Ressourcen weder angeschafft noch gewartet werden kann. Weiterhin verhindert eine zentrale Instanz eine dezentrale Organisation der Integrationsarchitektur, welche der Realität von kleinen kooperierenden Unternehmen entspräche Service-orientierte Architekturen (SOA) Vor dem Hintergrund einer virtuellen Prozessintegration wurde das Paradigma der Serviceorientierten Architekturen (SOA) entwickelt. Hierbei wird üblicherweise über einen zentralen Bus ein Unternehmensprozess orchestriert und verteilt zur Ausführung gebracht. Ein großer Vorteil einer SOA ist, dass an die aufgerufenen Funktionalitäten keine Anforderungen bzgl. ihres Ausführungsortes gestellt werden. Eine SOA eignet sich daher gut für eine zwischenbetriebliche Integration. Ein weiterer Vorteil ist, dass aufgrund der virtuellen Integration gewährleistet werden kann, dass stets nur auf aktuellste Daten zugegriffen wird. 20 Siehe Abschnitt

69 2.9 Integrationsparadigmen in Unternehmen Die Vision einer SOA ist, zuerst einen Geschäftsprozess zu modellieren und diesen anschließend mit technischen Aufrufen anzureichern. Ein solcher Geschäftsprozess sollte dann sofort technisch ausführbar sein. Die Praxis hat allerdings gezeigt, dass dies nicht der Fall ist. Da die Anforderungen zu unterschiedlich sind, werden das fachliche und technische Modell getrennt gehalten. In einer SOA muss üblicherweise für jeden Anwendungsfall eine neue Applikation entwickelt werden. Dies ist notwendig, da der virtuelle Datenzugriff speziell auf die angebotenen Services ausgerichtet sein muss. Nach Haas (2006) gestaltet sich dies aufwändiger als in anderen Paradigmen. Das SOA-Paradigma wird auf Grund der hohen Komplexität, die der reduzierten Schnittstellen- und Designautonomie geschuldet sind, vornehmlich von großen Unternehmen eingesetzt. Im Gegensatz zur EAI zielt eine SOA auf eine rein virtuelle Integration, d.h. sie verzichtet auf die Replikation von Daten. Dies macht diese Architektur abhängiger von der zugrundeliegenden Infrastruktur. Zusätzlich verfügt eine SOA genauso wie eine EAI über eine zentrale Komponente mit den damit verbundenen Nachteilen. Ein entscheidender Nachteil einer SOA bei der Integration ist die Tatsache, dass die Zugriffsschicht der Applikationen so angepasst werden muss, dass sie auf verteilte Daten, von denen i.a. nicht bekannt ist, wo sie liegen, zugreifen kann. Eine SOA ist daher weder in der Lage, die Barriere der erwarteten Kosten noch der Adaptierbarkeit an Legacy-Anwendungen adäquat zu adressieren Electronic Data Interchange (EDI) Für den Austausch von Daten zwischen Großunternehmen wird seit den 1970 Jahren der elektronische Datenaustausch (EDI) entwickelt. Erst später wurden die verwendeten Nachrichtenformate standardisiert. Im europäischen Raum hat sich hierfür UN/EDIFACT und im US-amerikanischen Raum ANSI X.12 durchgesetzt. Da diese Standards vielfältige Standardprozesse unterstützen sollen, haben sie eine hohe Komplexität. Speziell EDIFACT wird eine unnötig hohe Komplexität vorgeworfen (Laudon et al., 2010, S. 503). Die hohe Komplexität des UN/EDIFACT Standards hat zu einer Spezialisierung für individuelle Branchen und Regionen in sog. EDIFACT-Subsets geführt. In Deutschland existieren derzeit ca. 18 Subsets, etwa EDIBDB für die Baustoffbranche oder ODETTE in der Automobilindustrie. Auch wenn dies die Komplexität der Standards reduziert, wird EDI hauptsächlich von großen Unternehmen eingesetzt, die über die Mittel verfügen, um die Einführungskosten zu kompensieren, Ausführungsdetails beeinflussen können und über Erfahrung mit EDI verfügen (Barua und Lee, 1997). Für den Datenaustausch wird aus der Datenquelle eine sog. Inhouse-Datei erstellt, welche anschließend durch einen EDI-Konverter in eine sog. EDIFACT-Datei übersetzt wird. Diese wird an den Empfänger versendet und dort wieder in eine Inhouse-Datei konvertiert und in das integrierte System importiert (Abbildung 2.13). Das Einsatzszenario ist hierbei eine rein überbetriebliche (B2B) Integration. Weiterhin sieht EDI keine Mechanismen zur Erhöhung der innerbetrieblichen Informationsqualität vor. 69

70 2 Grundlagen, Vorarbeiten und Stand der Technik Unternehmen A Informationssystem Unternehmen B Informationssystem Inhouse-Datei Inhouse-Datei EDI-Konverter EDI-Konverter EDIFACT-Datei EDIFACT-Datei Kommunikationssoftware Kommunikationssoftware Abbildung 2.13: Ablauf des EDIFACT Datenaustausches Der Export von Daten aus den Informationssystemen wird hierbei in der Regel entweder manuell angestoßen oder in definierten Zeitabständen durchgeführt. Bei Bewegungsdaten kann dies auch durch ihre Freigabe unmittelbar geschehen. Der Import von Bewegungsdaten wird in hoch automatisierten Unternehmen direkt in das Informationssystem durchgeführt. Stammdaten werden jedoch meistens manuell importiert und erzeugen somit in Wertschöpfungsnetzwerken einen hohen Aufwand. Die Hemmnisse der Integration mittels EDI wurden durch Teo et al. (2006) untersucht (Tabelle 2.16). In der Analyse der Hemmnisse, welche spezielle durch KMU wahrgenommen werden, zeigt sich, dass eine Integrationsarchitektur für KMU-Wertschöpfungsnetzwerke kosteneffizient realisierbar sein muss (Zheng et al., 2004). Die Integrationsarchitektur muss weiterhin der Organisationsstruktur von KMU-Wertschöpfungsnetzwerken entsprechen und durch KMU-spezifische Dienstleistungen flankiert werden (Parker und Castleman, 2007). Dies wird nach Teo et al. (2006) durch EDI nicht geboten, da EDI für KMU zu komplex ist (MacGregor und Vrazalic, 2005). Kategorie Hemmnis Technik Fehlende adäquate IT-Infrastruktur Limitationen durch existierenden Datenbankinfrastruktur Fehlende robuste, stabile und standardisierte Infrastruktur Fehlende Interoperabilität mit Legacy-Systemen Schwierigkeiten der Integration mit existierenden Applikationen Fehlende Interoperabilität mit Systemen der Netzwerkpartner Fehlendes IT-Wissen in der eigenen Organisation Organisation Fehlende adäquate Zuordnung von Ressourcen Fehlende Unterstützung durch externen Berater Umgebung Ungewisse Reaktion der Lieferanten Ungewisse Reaktion der Netzwerkpartner Tabelle 2.16: Hemmnisse der EDI Umsetzung nach Teo et al. (2006) 70

71 2.9 Integrationsparadigmen in Unternehmen Standards Eine andere Möglichkeit Informationssysteme in Unternehmen zu integrieren liegt in der Verwendung von Standards (Shapiro und Varian, 1999, S. 229). Diese umfassen fachliche Standards 21, welche anwendungsfall- und häufig auch branchenspezifische Konventionen für die Kommunikation festlegen. Diese Standards definieren daher die semantische Interoperabilität. Zusätzlich existieren nicht-fachliche Standards 22, welche speziell die technische Heterogenität durch eine syntaktische Standardisierung reduzieren sollen, z.b. durch standardisierte Protokolle (Berlecon Research, 2010). Eine gängige Einteilung von Standards erfolgt nach David (1985) in»de jure«und»de facto«standards. Letztere sind Standards, die durch die Industrie vorgegeben sind und sich durchgesetzt haben. Demgegenüber ist ein»de jure«standard durch öffentliche Institutionen oder private Einrichtungen festgelegt. Da dies zu Missverständnissen führt (Kelkar, 2002), gliedern Kleinemeyer (1998) und Genschel (1995) Standards in staatliche, Kommisions- und Wettbewerbsstandards. Existiert für eine spezifische Integration kein passender Standard, müssen von Unternehmen, Branchenorganisationen, Softwareherstellern oder Integratoren eigene Datenaustauschformate spezifiziert werden. Eine häufige Schwierigkeit ist hierbei, dass sich kein Partner findet, der die Verantwortung für die Pflege eines solchen Datenaustauschformates übernimmt (Halevy et al., 2006). Zusätzlich kann ein Datenaustauschformat in der Praxis üblicherweise nicht alle Anforderungen erfüllen. Es ist daher unklar, ob in einer spezifischen heterogenen Umgebung ein einzelnes gemeinsames Datenaustauschformat gefunden werden kann. In KMU-Wertschöpfungsnetzwerken kann daher im Allgemeinen kein Standard verbindlich vorgeschrieben werden (Tuusjärvi und Möller, 2009). Es ist vielmehr notwendig, die Autonomie zu erhalten und gleichzeitig die entstehende Heterogenität zu kontrollieren. Dies kann einerseits durch Empfehlungen, etwa durch Branchenverbände, geschehen (Berlecon Research, 2010) und setzt andererseits eine flexible Architektur zur Informationsintegration voraus. 21 Bspw.: BMEcat, opentrans, EDIFACT 22 Bspw.: TCP, IP, HTTP, FTP, UDDI, SOAP, WSDL 71

72 2 Grundlagen, Vorarbeiten und Stand der Technik Paradigma EAI SOA EDI Standards Kriterium Eignung für betriebsübergreifende Integration Hohe Komplexität Realisierbarkeit durch KMU Asynchrone Kommunikation Synchrone Kommunikation Eigenständiger Server Virtuelle Integration Materialisierende Integration Wiederverwendung von IT-Komponenten Lose Kopplung Hohe Abhängigkeit von Hersteller Hohe Abhängigkeit von Infrastruktur Integrationsebenen Datenintegration Informationsintegration Funktionsintegration Prozessintegration GUI-Integration Standardisierung Architektur Technischer Informationsaustausch Datenaustauschformate Legende: trifft voll zu, triff weitgehend zu, trifft teilweise zu, trifft kaum zu, trifft nicht zu Tabelle 2.17: Integrationsparadigmen im betrieblichen Einsatz Zusammenfassende Bewertung Die technologisch getriebene Vision der einfachen Austauschbarkeit von Services in einer Service-orientierten Architektur führt technisch zu einer hohen Komplexität und entspricht nicht der ökonomischen Realität. Der Austausch eines Services würde den Austausch einer Geschäftsbeziehung bedeuten. Dies ist vom Erbringer des Service naturgemäß nicht gewollt und auch nur bei stark standardisierten und einfachen Services im Sinne des Serviceabnehmers (Kagermann und Österle, 2006). Eine SOA ist daher für das Anwendungsszenario nicht geeignet. EAI ist ein Begriff, der insbesondere durch die Hersteller dieser Technologie geprägt ist. Die Zielstellung dieser Technologie ist daher so unterschiedlich wie die sie realisierenden Produkte. Ursprünglich wurde die Technologie für den betriebsinternen Einsatz entwickelt. Später entstanden Ansätze, um zwischenbetriebliche Integration zu realisieren, meistens durch den Einsatz von EDI. EDI hat im betrieblichen Einsatz eine weite Verbreitung gefunden (Berlecon Research, 2010). EDI ist von seiner Struktur auf eine rein bilaterale Kommunikation ausgelegt, jedoch steht auch hier dem Einsatz durch KMU ihre hohe Komplexität entgegen (Tabelle 2.17). 72

73 3 Ansatz und Anforderungen Der im Folgenden abgeleitete Ansatz resultiert aus der Analyse der Barrieren und basiert auf den Defiziten des Standes der Technik. Für die Umsetzung des Ansatzes müssen Anforderungen spezifiziert werden, welche die Brücke schlagen zwischen dem abstrakten Ansatz und dem Konzept der Integrationsarchitektur. 3.1 Defizite Integration ist eine vielschichtige Herausforderung. Allerdings ist die Verbreitung der IT- Integration bei KMU nur sehr gering (Iacovou et al., 1995). Da durch Integration hohe Effizienzsteigerungen realisiert werden können, ist dies ein signifikantes Defizit (Bernstein und Haas, 2008). Der Erfolg der Integration hängt dabei entscheidend von organisatorischen Einflüssen und Voraussetzungen ab, welche in ihrer technischen Realisierung reflektiert werden müssen. Gerade in der organisatorischen und technischen Projektgestaltung entstehen Schwierigkeiten durch die geringe Expertise in Bezug auf die Integration vonseiten der Verantwortlichen in KMU. Weder existieren angemessene Dienstleistungsangebote für die Unterstützung in der organisatorischen Realisierung noch in der technischen Umsetzung (Lawson et al., 2003). Die Ablehnung existierender Dienstleistungsangebote ist zu einem wesentlichen Teil auf die erwarteten hohen Kosten zurückzuführen. Dies ist jedoch gleichzeitig eine Chance, da durch entsprechende Dienstleistungsangebote eine Kooperation entstehen kann, die förderlich für die Durchführung von IT-Integrationsprojekten ist (Vijayasarathy, 2010). Bestehende Integrationsansätze reduzieren die Heterogenität der miteinander integrierten Organisationen und Systeme zugunsten einer geringeren Komplexität (Leser und Naumann, 2007), doch steht dies der ökonomischen Struktur von KMU-Wertschöpfungsnetzwerken diametral entgegen. Ein zentrales Defizit ist daher die unpassende Struktur bestehender Integrationsarchitekturen für diese Zielgruppe, welche durch eine hohe Verteilung und Autonomie gekennzeichnet ist. Hohe Heterogenität und Dezentralität in der Integration dürfen jedoch auch keine chaotisch unkoordinierte Integration von Informationssystemen bedingen, da hierdurch die Wiederverwendung abnimmt, wodurch der Implementierungsaufwand, die Fehleranfälligkeit und die Wartungsintensität und somit letztlich die Kosten für die Integration zunehmen (Höß, 2005). Service-orientierte Architekturen sind ein Ansatz, der in letzter Zeit viel Aufmerksamkeit erfahren hat. Durch seine Fokussierung auf virtuelle Prozessintegration verspricht er eine tiefe Integration in unternehmerische Abläufe bei gleichzeitiger flexibler Austauschbarkeit der Geschäftspartner (Services). Dies widerspricht der ökonomischen Realität der Zielgruppe, welche durch organisatorische Partnerschaften und Vertrauen geprägt ist und daher bedingt durch hohe Kundenbindung nicht an einer Austauschbarkeit interessiert ist. Ferner sind sowohl Prozessintegration als auch virtuelle Integration mit hohen Kosten verbunden, da hierfür ein Großteil der bestehenden Informationssysteme neu implementiert werden müssen

74 3 Ansatz und Anforderungen (Haas, 2006). Die Realisierung von Service-orientierten Architekturen scheitert für die Zielgruppe daher an der Barriere der hohen erwarteten Kosten. Materialisierende Integration wird durch EDI realisiert. Der in EDI verfolgte Ansatz der hohen (ggf. regionalen und branchenabhängigen) Standardisierung setzt auf eine Homogenisierung des Datenaustausches, welcher hohe Implementierungsaufwände verursacht (Barua und Lee, 1997). Insbesondere die manuelle Integration von Stammdaten in Wertschöpfungsnetzwerken verursacht hohe Aufwände, die durch eine transparente Automatisierung reduziert werden könnten. Materialisierende Peer-to-Peer Informationsintegration würde die diskutierten Barrieren adressieren. Jedoch wurde eine strukturierte Peer-to-Peer Informationsintegration für betriebliche Informationssysteme nie umgesetzt. Existierende Peer-to-Peer Systeme realisieren etwa den Dateiaustausch oder Datenbankintegration. Systeme für den Dateiaustausch stellen in der Regel Verbindungen ad-hoc zwischen beliebigen Peers her und sind nicht mit der Heterogenität der Datenschemata und Informationssysteme konfrontiert. Erkenntnisse hieraus lassen sich auf die Informationsintegration nicht übertragen. Die Entwicklung der Peer-to-Peer Datenbankintegration ist durch technologische Innovationen getrieben und nur in Forschungsprototypen realisiert. Ihre Technologie ist nicht passend für den Anwendungsfall, weshalb auch hier ein Transfer nur begrenzt möglich ist. Dieses Defizit soll in dieser Arbeit behoben werden. 3.2 Ansatz In der vorliegenden Arbeit soll eine Integrationsarchitektur entworfen werden, welche den Anforderungen von KMU-Wertschöpfungsnetzwerken entspricht. In der Analyse der Barrieren 23 und unterstützenden Faktoren hat sich gezeigt, dass eine solche Architektur mit geringen finanziellen Ressourcen realisierbar, der Topologie des Wertschöpfungsnetzwerkes entsprechen, mit für KMU angepassten Dienstleistungsangeboten verbunden und an Legacy-Systeme adaptierbar sein muss (Kokemüller und Weisbecker, 2010). Es wird daher eine dezentrale Integrationsarchitektur entwickelt, welche sich durch einen hohen Wiederverwendungsgrad kostenintensiver Faktoren auszeichnet. Die Dezentralität wird durch eine Peer-to-Peer Topologie realisiert. Hierbei sind alle Partner gleichberechtigt und nicht in ihrer Autonomie eingeschränkt (Westkämper et al., 1998). Da dies der Struktur von KMU-Wertschöpfungsnetzwerken entspricht, ist hierdurch mit einer Akzeptanzzunahme zu rechnen (Kokemüller et al., 2009a). Reduzierte Kosten werden durch optimistische Integration angestrebt. Optimistische Integration wird als Begriff eingeführt für die Integration heterogener Informationssysteme durch einen materialisierenden Ansatz, welcher auf Sperrmechanismen verzichtet. Änderungen von Daten werden hierbei allen definierten und betroffenen Netzwerkpartner zeitnah zur Verfügung gestellt. Eventuell entstandene Konflikte müssen nachträglich gelöst werden. 23 Vergleiche Abschnitt

75 3.3 Anforderungen Die Architektur muss durch ein auf KMU-Wertschöpfungsnetzwerke ausgerichtetes Dienstleistungsangebot flankiert werden. Hier besteht eine enge Abhängigkeit zwischen Dienstleistungsangebot und Architektur, denn das Dienstleistungsangebot schafft eine Voraussetzung für die Akzeptanz der Architektur, gleichzeitig muss die Architektur ein entsprechendes Dienstleistungsangebot ermöglichen (Westkämper und Schraft, 1999). Die Entwicklung eines standardisierten Dienstleistungsangebotes sollte nach den Prinzipien des Service-Engineering (Spath et al., 2004) geschehen, es steht jedoch nicht im Fokus dieser Arbeit, lediglich seine Befähigung durch skalierbare Techniken. Die Administration wird daher zentral ausführbar gestaltet und ermöglicht die Wiederverwendung schematischer Elemente. 3.3 Anforderungen Die Defizite gegenwärtiger Integrationsarchitekturen wurden im Stand der Technik beschrieben. Um diese beheben zu können müssen die folgenden Anforderungen (Tabelle 3.1) erfüllt werden: A1 Der fehlende Homomorphismus organisatorischer und technischer Struktur bestehender Integrationsparadigmen ist deren grundlegendes Defizit. Sie sind nicht in der Lage, die Barriere der unpassenden Struktur adäquat zu adressieren. EDI kommt in der Regel nur in Konstellationen mit mindestens einem großen Unternehmen vor. In diesen Fällen ist äußerer Druck die treibende Kraft für die Realisierung der Integration (Zhu et al., 2003). Jedoch erlaubt Integration auch ohne einen dominanten Partner Effizienzsteigerungen, welche aufgrund fehlender Angebote für KMU-Wertschöpfungsnetzwerke (Stockdale und Standing, 2004) derzeit nicht realisiert werden. Der Homomorphismus ist hierfür eine wichtige Voraussetzung, da die Struktur eines Informationssystems der Kultur der es einsetzenden Organisation (des KMU-Wertschöpfungsnetzwerks) entsprechen muss (Wainwright und Waring, 2004; Hanseth und Lyytinen, 2010). A2 Neben der Struktur liegt eine weitere Barriere in mangelnden Dienstleistungsangeboten für KMUs. KMUs verfügen in der Regel nicht über die notwendige Expertise, um Integration realisieren zu können (Kett et al., 2008b), schrecken jedoch auch vor den Kosten für Dienstleistungen zurück (Lawson et al., 2003). Die Befähigung eines skalierbaren Dienstleistungsangebotes, spezialisiert auf die Erfordernisse von KMU- Wertschöpfungsnetzwerken, ermöglicht also erst die IT-Integration dieser Anwendergruppe (Spath und Ganz, 2009). A3 Hohe erwartete Kosten sind die am häufigsten genannte Barriere. Die Integration soll daher mit einem geringen Bedarf an finanziellen Ressourcen realisiert werden. Zu diesem Zweck muss ein möglichst hoher Wiederverwendungsgrad sowohl softwaretechnischer Komponenten als auch schematischer Elemente (Transformationen und Austauschformate) erreicht werden. Besonders letztere werden häufig in Individualprojekten entwickelt. Eine hohe Wiederverwendung reduziert hier den Ressourcenbedarf. A4 Für Administratoren und Fachanwender werden geeignete Benutzungsschnittstellen benötigt. Durch die administrative Benutzungsschnittstelle muss die Integrationsarchitektur 75

76 3 Ansatz und Anforderungen konfiguriert werden können, also die Kommunikationsbeziehungen innerhalb des Netzwerkes sowie die Datenaustauschformate, ohne dass die eigentlichen Daten der Informationssysteme für den Administrator zugreifbar sind. Von administrativem Interesse ist weiterhin das Laufzeitverhalten, welches in Form von Kennzahlen auslesbar sein muss. Für den Fachanwender müssen Funktionalitäten zur Verfügung stehen, um Konflikte lösen zu können und um das Vertrauen in die vorhandenen Informationen sicherzustellen (Ratnasingam, 2005). Konfliktlösung wird notwendig bei Datenqualitätskonflikten, insbesondere erkannten Dubletten, sowie bei Integrationskonflikten, welche durch parallele Änderungen eines Objektes entstehen können. Um Vertrauen zu den vorhandenen Informationen zu erzeugen, muss für den Fachanwender erkennbar sein, durch welchen Partner des KMU- Wertschöpfungsnetzwerkes Datenänderungen durchgeführt wurden. A5 Das Defizit dezentraler chaotischer Integrationstopologien ist deren mangelnde Standardisierung. Es muss daher eine betriebsübergreifende Standardisierung der Integrationsfunktion erreicht werden. Dies ist einerseits Voraussetzung für ihre Wiederverwendung, ist andererseits jedoch auch notwendig, um Heterogenitäten zu reduzieren. Hierdurch wird die Abhängigkeit von einem Softwarehersteller reduziert, was wiederum die Konkurrenzsituation der Dienstleistungsanbieter erhöht und somit perspektivisch zu niedrigeren Preisen führt (Shapiro und Varian, 1999, S. 227). Ein weiteres Defizit ist nach Hanseth und Braa (2001), dass nicht ein Datenaustauschformat die Anforderungen aller Partner eines KMU- Wertschöpfungsnetzwerkes erfüllen und gleichzeitig in seiner Komplexität beherrschbar bleiben kann. Es ist daher notwendig, unterschiedliche Datenaustauschformate zur parallelen Verwendung zu unterstützen. Hierdurch wird auch die Barriere der fehlenden Unterstützung von Legacy-Systemen aufgegriffen. A6 Das grundlegende Defizit bestehender Integrationsparadigmen ist, dass deren Integrationsfunktion unter technischen Gesichtspunkten optimiert wurde, dabei jedoch die Anforderungen von KMU-Wertschöpfungsnetzwerke nicht beachtet wurden und dadurch für diese Anwendergruppe zu komplex gestaltet ist (Stockdale und Standing, 2004). Durch eine optimistische Integrationsfunktion muss dem begegnet werden. Diese soll darauf ausgelegt sein, möglichst wenig mit existierenden organisatorischen und technischen Rahmenbedingungen zu interferieren. 76

77 3.3 Anforderungen Anforderungsgruppe Nr. Anforderung A1 Homomorphismus organisatorischer und technischer Struktur A1.1 Dezentrale Struktur des Integrationsverbundes A1.2 Autonomieerhaltung der Partner A1.3 Keine Branchenabhängigkeit A1.4 Partnerbezogene Freigaben der ausgetauschten Informationen A1.5 Lose Kopplung der Partner A1.6 Kein definierter zentraler Partner A1.7 Kein Single Point of Failure A2 Befähigung eines skalierbaren Dienstleistungsangebotes A2.1 Zentrale Verwaltung der Datenaustauschschemata A2.2 Entfernte Wartbarkeit der Architektur A2.3 Implementierbarkeit durch Dienstleister A2.4 Einfache und skalierbare Wartbarkeit durch Dienstleister A3 Geringer Bedarf an finanziellen Ressourcen A3.1 Geringer Wartungsaufwand A3.2 Geringe Betriebskosten A3.3 Kosteneffiziente Implementierung A3.4 Hoher Wiederverwendungsgrad schematischer Elemente A3.5 Hoher Wiederverwendungsgrad softwaretechnischer Komponenten A3.6 Geringe Anforderung an integrierte Systeme A4 Benutzungsschnittstellen A4.1 Administrationsoberfläche für Kommunikationsbeziehungen A4.2 Administrationsoberfläche für Datenformate A4.3 Darstellung von Kennzahlen A4.4 Benutzungsschnittstelle zur Lösung von Integrationskonflikten A4.5 Benutzungsschnittstelle zur Lösung von Datenqualitätsproblemen A4.6 Entfernte Ausführbarkeit, unabhängig von Integrationsfunktion A4.7 Optionale Integrierbarkeit in Informationssysteme A4.8 Trennung des administrativen Zugriffs vom Zugriff auf integrierte Daten A5 Betriebsübergreifende Standardisierung der Integrationsfunktion A5.1 Vereinheitlichung der Architektur A5.2 Vereinheitlichung der technischen Heterogenität A5.3 Vereinheitlichung der syntaktischen Heterogenität A5.4 Vereinheitlichung der Datenmodellheterogenität A5.5 Möglichkeit zur Verwendung existierender Datenaustauschformate A5.6 Reduktion der Abhängigkeit von Herstellern A6 Optimistische Integrationsfunktion A6.1 Keine Sperren auf Informationssystem durch Integrationsfunktion A6.2 Verwendung gültigen XML A6.3 Asynchrone Integrationsfunktion A6.4 Materialisierende Integrationsfunktion A6.5 Kontrolle der Heterogenität der Integrationsfunktion A6.6 Transformationen zwischen Schemata sind realisierbar Tabelle 3.1: Anforderungen an das zu entwickelnde System 77

78 4 Eine Architektur zur Integration von KMU- Wertschöpfungsnetzwerken Diese Arbeit führt eine Architektur zur optimistischen Integration von KMU- Wertschöpfungsnetzwerken ein. Die Gesamtheit der Architektur zur Laufzeit und der beschriebenen Konzepte wird im Folgenden als VIANA 24 bezeichnet. Das VIANA Konzept basiert auf der Integration von Informationssystemen durch»konnektoren«, welche bilaterale Integrationsbeziehungen unterhalten. In der Analyse des Informationsflusses werden die hierfür notwendigen Funktionalitäten deutlich. Diese verteilen sich auf beide Module des Konnektors: Adapter und VIANA Framework. Die Entkopplung der Konnektoren in ein semantisch autonom organisiertes dezentrales Netz bedarf mehrerer semantischer Ebenen im Integrationsprozess. Diese müssen daher gesondert betrachtet werden. Zur Administration und Konfliktresolution sind menschliche Interaktionen mit VIANA notwendig. Daher müssen hierfür geeignete Benutzungsschnittstellen entworfen werden. 4.1 Konnektor Unternehmen in KMU-Wertschöpfungsnetzwerken sind organisatorisch eigenständige Partner. Der Ansatz dieser Arbeit ist es, diese Betrachtungsweise auf die technische Realisierung zu übertragen. Es wird daher eine dezentrale Integrationsarchitektur aufgebaut, in der Informationen bilateral zwischen beliebigen fest konfigurierten Partnern ausgetauscht werden. Lieferant Handelsvertretung Netzwerkpartner Lieferant Netzwerkpartner Lieferant Handelsvertretung Netzwerkpartner Organisation Konnektor Informationssystem Integrationspfad Kommunikation mit integriertem System Abbildung 4.1: Konzept zur Umsetzung des Integrationsszenarios Netzwerkpartner 24 Der Name VIANA ist ein willkürliches Kunstwort, es ist kein Akronym.

79 4.1 Konnektor Mit diesem Konzept lassen sich Informationssysteme kontrolliert integrieren, ohne dass es einer zentralen Instanz bedarf. Hierfür wird jedes System durch eine autonome Integrationskomponente (Konnektor) integriert (Abbildung 4.1). Der Homomorphismus zu der organisatorischen Autonomie von KMU in Wertschöpfungsnetzwerken wird erreicht, indem jeder Konnektor unabhängig von allen anderen Komponenten der Integrationsarchitektur ist. Ihm kommt die gleiche Autonomie und Eigenverantwortlichkeit zu, wie dem es einsetzenden Unternehmen. Als Spezialfall erlaubt das Konzept auch die Realisierung von zentralisierten Topologien. So kann ein Konnektor besonders herausgehoben werden und als»super-peer«einer zentralisierten Peer-to-Peer Architektur (Androutsellis-Theotokis und Spinellis, 2004) instanziiert werden. Insbesondere die Hub-and-Spoke Architektur (Erasala et al., 2003) ist realisierbar. Abbildung 4.2 zeigt eine beispielhafte Instanziierung, bei der mehrere Konnektoren mit einem zentralen Hub-Konnektor verbunden sind. Eine solche sternförmige Topologie ist etwa für ein Produktdaten-Clearingcenter notwendig (Mucha, 2004). Die Wahl der Topologie ist jedoch eine organisatorische Entscheidung, weshalb technisch kein Unterschied zu anderen als der Hub-and-Spoke Topologie bestehen darf. Daher sind auch in der sternförmigen Topologie alle Konnektoren technisch gleich Objekte Die Idee, Informationen zu kapseln, hat sich vielfach bewährt. Erstmals wurde sie als Information hiding durch Parnas (1972) beschrieben. Das Ziel ist es, komplexe Zusammenhänge analysierbar und wiederverwendbar zu gestalten. Hierfür werden elementare Informationseinheiten (Attribute) in eine sinnvolle Strukturierung durch Klassen gebracht. Über Klassen können fachliche Zusammenhängt modelliert werden. Konnektor Integrationspfade Kommunikation mit integriertem System Informationssystem Konnektor Konnektor Informationssystem Hub Konnektor Informationssystem Informationssystem Informationssystem Konnektor Konnektor Abbildung 4.2: Spezialfall einer Hub-and-Spoke Architektur Informationssystem 79

80 4 Eine Architektur zur Integration von KMU-Wertschöpfungsnetzwerken Definition 1: Ein Attribut ist entweder ein atomares Attribut eines fundamentalen Datentyps oder eine Klasse Mit Hilfe dieser Definition lassen sich Klassen definieren als: Definition 2: Eine Klasse ist ein komplexer Datentyp, welcher sich aus mehreren Attributen zusammensetzt Basierend auf Klassen können nun Objekte definiert werden: Definition 3: Ein Objekt ist eine Instanziierung einer Klasse (Sommerville, 2007, S. 215ff) Beispiel 3: Als Beispiel sei die Klasse Produkt angenommen. Sie hat etwa das atomare Attribut GTIN und die Klasse Preis als Attribut. Ein Objekt dieser Klasse könnte ein Steckverbinder sein mit einer konkreten GTIN und definiertem Staffelpreisen für Ein- und Verkauf mit angegebenen Währungen und Steuerkennzeichen. Dieses Objektverständnis bildet die Basis für die Integrationsarchitektur, denn Objekte bilden erst den notwendigen semantischen Kontext, um Operationen spezifischen Daten zuordnen zu können. Die Integrationsarchitektur soll daher Informationsintegration von Objekten realisieren Informationsfluss Ein Konnektor muss zwei zentrale technische Anforderungen erfüllen. Er muss mit der Heterogenität der Informationssysteme umgehen können, also adaptierbar an unterschiedliche Informationssysteme sein. Im Gegensatz zur chaotischen Integration muss er jedoch auch eine homogene, standardisierte Umgebung zur systemübergreifenden Integration schaffen. Dies muss durch einen vereinheitlichten Informationsfluss umgesetzt werden (Abbildung 4.3). Im Vergleich von materialisierender und virtueller Integration hatte sich gezeigt, dass sich materialisierende Integration mit signifikant geringerem Aufwand realisieren lässt. Basierend auf der Priorisierung kosteneffizienter Integration wird daher im Folgenden ein Konzept zur materialisierenden Integration entworfen. Für diese Art der Integration wird der Begriff optimistische Integration eingeführt. Konnektoren müssen hierfür das Informationssystem beobachten, um schreibende Operationen auf dem Datenbestand zu erkennen. Schreibende Operationen sind Neuanlagen, Änderungen und Löschungen von Objekten. Erkannte schreibende Operationen müssen aus dem Informationssystem gelesen und dem Konnektor verfügbar gemacht werden. Dass für den Datenaustausch keine Semantik in Form definierter Datenaustauschformate vorgeschrieben werden kann, muss beim Auslesen der Informationen beachtet werden, denn die Semantik einer Klasse ist nur lokal nicht global definiert. Da eine möglichst klare Trennung informationssystemspezifischer und unspezifischer Komponenten erreicht werden soll, darf beim Auslesen nicht berücksichtigt werden müssen, welche Datenaustauschformate definiert wurden. 80

81 4.1 Konnektor Konnektor 1 VIANA Framework Konnektor 2 VIANA Framework Übermittlung Transformation in/aus Austauschschemata Objekte identifizieren Adapter Operation auslesen Adapter Operation ausführen Operation erkennen Abbildung 4.3 Informationsfluss Informationssystem 1 Informationssystem 2 Allerdings sind Informationssysteme auch in der lokalen Definition ihrer Klassen autonom. Es kann daher keine Granularität der Beschreibung vorgeschrieben werden. Beispiel 4: Unterschiedliche Granularitätsebenen können sein: ein Katalog, der mehrere Produkte enthält, welche wiederum jeweils mehrere Preisschemata haben. Eine definierte lokale Klasse könnte nun entweder ein Katalog, Produkt oder Preisschema sein. Wenn eine Änderung immer das vollständige Objekt übermitteln würde, wäre der Austausch potentiell großer Datenmengen notwendig. Daher sollen nur atomare Operationen übertragen werden. Um atomare Operationen allgemein berechnen zu können, müssen für erkannte schreibende Änderungen jeweils die Zustände des Objektes vor und nach der Änderung aus dem Informationssystem gelesen werden und in Datenaustauschformate transformiert werden. Nur in dieser Darstellung können Differenzen gebildet werden, welche systemübergreifend in spezifischen Datenaustauschformaten reproduzierbare Änderungen ergeben. Wurde aus zwei Zuständen eine Änderung formuliert, kann diese an konfigurierte Empfänger transportiert werden. Hierbei dürfen Fehler in der Netzwerkinfrastruktur nicht zu einem Verlust der Operation führen, lediglich die Übermittlung darf verzögert werden. Ferner müssen die Auswirkungen einer Netzwerkunterbrechung auf die Ausführungsreihenfolge von 81

82 4 Eine Architektur zur Integration von KMU-Wertschöpfungsnetzwerken Änderungen beim Empfänger minimal sein. Konnektoren müssen daher eine Warteschlange realisieren, in der für jeden Empfänger chronologisch sortiert Änderungen abgelegt werden. Da jedes Informationssystem autonom ist, ist der Absender nicht verantwortlich für die korrekte Verarbeitung der Operation beim Empfänger hierfür ist allein der Empfänger verantwortlich. Daher ist es ausreichend, dass der Empfänger den erfolgreichen Empfang quittiert hat, damit eine Operation aus der Warteschlange entfernt werden kann. Da Änderungen sich auf konkrete Objekte beziehen, muss der Empfänger reproduzieren können, auf welches Objekt sich diese bezieht, um eine Änderung ausführen zu können. Es wird hierfür eine Abbildung zwischen Operationen im Datenaustauschformat und lokalen Objekten benötigt. Durch diese muss identifizierbar sein, welche lokalen Objekte von der Änderung betroffen sind. Eine solche Abbildung kann durch Mapping-Tabellen realisiert werden. Mapping-Tabellen erlauben die Definition von Kongruenzrelationen, welche Objekte aus Datenaustauschformaten umkehrbar auf im Informationssystem definierte Objekte abbilden (Kementsietsidis et al., 2003). Nachdem der Empfänger lokal betroffene Objekte identifiziert hat, müssen diese aus dessen Informationssystem ausgelesen und in das Datenaustauschformat transformiert werden. Hierdurch ist der Kontext wiederhergestellt, in dem die Änderung definiert wurde. Wird die Änderung dann ausgeführt, entstehen vollständige geänderte Objekte. Diese können anschließend wiederum in das Informationssystem geschrieben werden. Allerdings ist dies nur möglich, wenn alle zu ändernden Objekte bereits in der Datenbasis des Empfängers enthalten sind. Da der Absender nicht über die Informationen verfügt, welche Objekte dem Empfänger unbekannt sind und daher angelegt werden müssen, ist diese Situation erst beim Empfänger erkennbar und muss auch dort gelöst werden. Ein Empfänger muss also vom Absender anfordern können, dass eine empfangene Operation statt als Änderung als Neuanlage formuliert wird. Erkennen und Auslesen sowie das abschließende Schreiben in das Informationssystem konfrontiert Konnektoren mit der Heterogenität der Informationssysteme. Sie müssen daher durch eine adaptierbare Komponente umgesetzt werden. Löschungen können ein Informationssystem in einen instabilen Zustand versetzen. Ferner kann es aus rechtlichen und organisatorischen Gründen unerwünscht sein, Löschungen durchzuführen. Wenn ein Objekt gelöscht werden soll, so muss daher die Möglichkeit bestehen, diese Operation in eine Änderung umzuschreiben, sodass die betroffenen Objekte als inaktiv markiert werden können. Um für den Anwender nachvollziehbar zu gestalten, wie eine Änderung der Datenbasis seines Informationssystems zustande kam, muss jede ausgeführte Operation protokolliert werden. 82

83 4.1 Konnektor Adapter Der Adaptierbarkeit kommt eine besondere Bedeutung zu, da die fehlende Unterstützung von Legacy-Systemen eine hohe Barriere ist. Sie hat Einfluss auf den Aufwand und die Umsetzbarkeit jeder neuen Integration eines Informationssystems und ist für jedes Informationssystem in der Regel einmal relevant. Ein Konnektor muss daher über eine individuell adaptierbare Schnittstelle zur materialisierenden Integration verfügen. Diese Komponente wird im Folgenden als Adapter bezeichnet. Adapter können aus Sicht des integrierten Informationssystems weiter klassifiziert werden in eingehende und ausgehende Adapter. Eine Strukturierung der Ansatzpunkte für Adapter bietet das Model-View-Controller (MVC) Architekturmuster (Goldberg und Robson, 1983) für die Aufteilung von Applikationskomponenten. Die Applikationskomponenten sind hierbei im Einzelnen: Das Model definiert die Informationen und steuert, soweit notwendig, ihre Persistenz. Die View definiert die Benutzungsschnittstellen. Der Controller steuert den Programmfluss. Abhängig von der konkreten Implementierung kann die Geschäftslogik entweder im Model oder im Controller realisiert werden. Für die hiesige Diskussion wird die Geschäftslogik als Teil des Controllers verstanden Eingehende Adapter Ein eingehender Adapter stellt die Funktionalitäten bereit, um Operationen in der Informationssenke durchzuführen. Auf der Ebene des Models können eingehende Operationen direkt auf Datenbanken oder Dateien ausgeführt werden. Auf der Ebene des Views können eingehende Operationen durch die automatisierte Bedienung der Benutzungsschnittstelle ausgeführt werden. Auf der Ebene des Controllers erfolgt die Interaktion durch den Aufruf von Schnittstellen der Informationssenke. Hierbei wird die Geschäftslogik berücksichtigt. Die verwendete Schnittstelle kann einerseits eine Abstraktion des Models sein, welche Schreiboperationen auf Objekten ausführbar macht, andererseits können durch den Controller auch höherwertige Funktionen angeboten werden, bspw. um einen Katalog freizugeben. Im Vergleich bietet die Integration auf der Ebene des Controllers die einfachsten Zugriffsmöglichkeiten durch den Adapter, und gleichzeitig durch die Berücksichtigung der Geschäftslogik des Informationssystems die besten Mechanismen zur Wahrung der Konsistenz der Datenbasis. Allerdings bieten nicht alle Informationssysteme die hierfür notwendigen Schnittstellen an (Themistocleous et al., 2004). Es ist daher für jedes Informationsprojekt einzeln zu entscheiden, ob die vorhandenen Schnittstellen für die Integration auf der Ebene des Controllers ausreichen oder ob die Integration auf einer anderen Ebene realisiert werden muss. 83

84 4 Eine Architektur zur Integration von KMU-Wertschöpfungsnetzwerken Ausgehende Adapter Ein ausgehender Adapter stellt Funktionalitäten bereit, um Datenänderungen in der Informationsquelle zu detektieren und auszulesen. Da atomare Operationen detektiert werden müssen, entsteht eine zusätzliche Komplexität. Zur Detektion von Änderungen können Adapter sowohl ereignisgesteuert bei Eintreten einer Änderung informiert werden (push), als auch aktiv den Datenbestand der Informationsquelle überwachen (pull). Da durch eine ereignisgesteuerte Interaktion in der Regel früher über Änderungen informiert und gleichzeitig weniger Last verursacht wird, ist diese Interaktionsart wenn möglich vorzuziehen. Im Model können Datenänderungen anhand von Triggern oder Dateibeobachtern erkannt werden. In der View ist es nur für geringe Datenvolumina möglich, Datenänderungen zu erkennen, da hierbei zu jedem Datensatz eine Benutzungsschnittstelle geöffnet sein muss. Weiterhin ist dies nur möglich, wenn die View bei Datenänderungen aktualisiert wird. Dies wird nur durch wenige Informationssysteme gewährleistet. Unter Verwendung des Controllers können Datenänderungen erkannt werden, indem das Informationssystem externe Applikationen (den Adapter) benachrichtigt, wenn eine interne Datenänderung durchgeführt wurde. Wie beim eingehenden Adapter ist die Integration auf Ebene des Controllers auch für ausgehende Adapter vorzuziehen, solange das Informationssystem entsprechende Schnittstellen bereitstellt Beispiele für Adapter Verschiedene Varianten, wie Adapter realisiert werden können, werden im Folgenden untersucht. Anforderungen an den physischen Ausführungsort eines Adapters werden hierbei ausschließlich durch die Schnittstellen des integrierten Informationssystems gestellt. Das Konzept erlaubt sowohl eine enge Kopplung, bei der die Ausführungsorte identisch sind, als auch eine Kopplung über entferne Funktionsaufrufe 25. Für jede diskutierte Variante wird die Kommunikationsebene mit dem integrierten Informationssystem entsprechend dem MVC Entwurfsmuster als (Eingehend/Ausgehend) angegeben. Mehrere Ebenen werden angegeben, wenn Freiheitsgerade existieren. Zahlen in Klammern verweisen auf die jeweilige Variante in Abbildung Beispielsweise über Web Services, RMI, Corba u.v.m. (vgl. Schwinn und Schelp, 2005) 84

85 4.1 Konnektor Informationssystem Informationssystem 2 3b Entfernte Informationsquelle 4a Konnektor Konnektor Konnektor Konnektor Entfernte Informationssenke 4b Konnektor DB 1b Konnektor Abbildung 4.4: Systemüberblick mit Integrationsvarianten und Informationsfluss Adapter als Datenbankbeobachter (MC/M) Variante (1a) erweitert ein Datenbanksystem um Peer-to-Peer Eigenschaften zur Integration, ähnlich derer PDMS-Systeme. Moderne Datenbanksysteme können Beobachter standardkonform durch SQL/Trigger benachrichtigen. Eine effizientere Möglichkeit wenn auch nicht standardkonform ist es, Transaktionslogs zu verwenden. Dies sind Dateien, in denen in einem herstellerabhängigen binären Format alle Operationen an der Datenbasis protokolliert werden. Die Interaktion mit Datenbanken ist nicht limitiert auf isolierte Systeme. Es können auch Datenbanken von Informationssystemen integriert werden (1b). Dieses Vorgehen birgt Nachteile: Geschäftslogiken können nicht angewandt werden und Operationen am internen Datenschema des Informationssystems haben Einfluss auf die Integration. Dies kann beispielsweise bei der Migration auf eine neue Version geschehen. Allerdings kann diese Art der Integration gelegentlich die einzige Möglichkeit sein, um Legacy-Anwendungen zu integrieren (Barnekow, 2002; Themistocleous et al., 2004). Nachrichtengetriebener Konnektor (MC/C) Die Abhängigkeit vom internen Datenschema sowie die Risiken, die entstehen, wenn die Geschäftslogik umgangen wird, können vermieden werden, wenn das Informationssystem über Schnittstellen für den Datenzugriff verfügt. Wenn diese Schnittstelle nur den Lese- oder Schreibzugriff ermöglicht, dann kann die jeweils andere Zugriffsart über einen direkten Zugriff auf die Datenbank realisiert werden. Einige Informationssysteme verfügen über Mechanismen, über die externe Anwendungen ihren Datenbestand beobachten können. Im Falle einer Operation kann hier eine Nachricht an den Konnektor gesendet werden, durch die dieser über eine atomare Operation informiert DB 1a Ereignisgesteuerte Änderungen Konnektor Informationsfluss Nachrichtenbasierend Informationssystem Periodisches Überprüfen DB 3a Informationssystem Aktive Abfragen 85

86 4 Eine Architektur zur Integration von KMU-Wertschöpfungsnetzwerken wird (2). Die Realisierung der Schreib- und Lesezugriffe bleibt orthogonal zur Detektion der Operation. Iterativ beobachtender Konnektor (MC/MC) Verfügt das Informationssystem über keinen Mechanismus, um proaktiv Datenänderungen zu kommunizieren, so kann die Datenbank (3a) oder das Informationssystem (3b) periodisch auf Änderungen untersucht werden. Wird dieser Ansatz gewählt, so muss mit einer ausreichend hohen Frequenz auf Änderungen geprüft werden. Andernfalls steigt die Wahrscheinlichkeit für zueinander im Konflikt stehende Schreiboperationen (Wang et al., 2002). Unidirektionale Kommunikation Einige Einsatzszenarien erwarten eine unidirektionale Kommunikation. Beispiel 5: Produktkataloge werden üblicherweise von Lieferanten erstellt und den nachfolgenden Teilnehmern der Wertschöpfungskette zur Verfügung gestellt. Änderungen der Produktkataloge können zwar von Abnehmern des Kataloges angefordert werden, sie werden jedoch nur vom Lieferanten durchgeführt. Die Kommunikation ist also unidirektional. Dies hat Einfluss auf die möglichen Topologien des Netzwerkes. Konnektoren, die als reine Informationssenke konfiguriert sind, können nur eingehende Verbindungen benachbarter Konnektoren erlauben (4a). Dementsprechend können reine Informationsquellen nur ausgehende Verbindungen erlauben (4b). Adaptervariante Eingehend auf Ebene Ausgehend auf Ebene Referenz zu Abbildung 4.4 Datenbankbeobachter Model, Controller Model 1a, 1b Nachrichtengetrieben Model, Controller Controller 2 Iterativ beobachtend Model, Controller Model, Controller 3a, 3b Informationssenke Controller - 4a Informationsquelle - Controller 4b Tabelle 4.1: Adaptervarianten Anhand dieser Untersuchung wird die Adaptierbarkeit deutlich, mit der bestehende Informationssysteme durch das Konzept integriert werden können (Tabelle 4.1). Besteht eine Wahlfreiheit, so ist der nachrichtengetriebene Konnektor vorzuziehen, da weder eine Latenz zwischen einer Operation und der Wahrnehmung dieser durch den Konnektor noch erhöhte Last durch periodisches Überprüfen des Datenbestandes generiert wird. Allerdings lassen sich auch Varianten realisieren, die zwar technisch nicht optimal sein mögen, jedoch dem Zwang des Faktischen folgend die einzigen Möglichkeiten zu Realisierung eines Integrationsprojektes sein können. 86

87 4.1 Konnektor VIANA Framework Um eine homogene, standardisierte Integrationsumgebung zu errichten, muss eine einheitliche Integrationsfunktion spezifiziert werden. Hierzu müssen entsprechend den Heterogenitätsdimensionen Aussagen getroffen werden zur technischen, syntaktischen, datenmodellbezogenen, strukturellen, schematischen und semantischen Interoperabilität der Integrationsfunktion 26. Ziel eines Frameworks ist es, eine Struktur vorzugeben und dadurch den Aufwand für die Implementierung neuer Artefakte zu reduzieren. In der Literatur (Szyperski et al., 2002, S. 158ff) werden unterschiedliche Arten von Frameworks definiert. Gemein ist ihnen, dass sie wiederverwendbare Elemente definieren; dies können Funktionalitäten, Methoden oder Schnittstellen sein. Verbirgt ein Framework seine internen Details vor einer konkreten Instanziierung und stellt nur Schnittstellen zur Interaktion zur Verfügung, so wird dies als Blackbox- Framework bezeichnet. Ist die innere Struktur für Instanziierungen sichtbar, etwa um Spezialisierungen abstrakter Klassen implementieren zu können, so wird dies als Whitebox- Framework bezeichnet. Durch ihre Standardisierung müssen die Konventionen der Interoperabilität unabhängig vom Adapter sein. Ein Konnektor muss also über eine Komponente verfügen, welche die systemübergreifende Integrationsfunktion realisiert diese kann wiederverwendbar als Framework realisiert werden. Da eine Kenntnis über ihre innere Struktur für die Realisierung von Integrationsprojekten notwendig ist, werden diese in einem Whitebox-Framework gebündelt. Dieses wird im Folgenden als VIANA Framework bezeichnet. Das VIANA Framework (Abbildung 4.5) stellt Benutzungsschnittstellen und systemnahe Komponenten zur Verfügung. Letztere bieten Funktionalitäten der Kommunikation und der Informationsqualität. Benutzungsschnittstellen stehen für operative und administrative Aufgaben zur Verfügung. Technische Interoperabilität wird erreicht, wenn Konnektoren miteinander Daten austau- Operativ: - Konfliktbehebung - Metadaten - Informationsqualität Benutzungsschnittstellen Administrativ: - Lokale Konfiguration - Topologie - Monitoring Systemnahe Komponenten Kommunikation: - Datenaustausch - Änderungsberechnung Informationsqualität: - Optimistische Integration - Dublettenerkennung 26 Abbildung Siehe hierzu Abschnitt 4.5: Funktionalitäten 2.3 des VIANA Frameworks 87

88 4 Eine Architektur zur Integration von KMU-Wertschöpfungsnetzwerken schen können. Hierfür stehen mehrere Standards zur Verfügung. Einen technologieunabhängigen Ansatz zur Verbindung lose gekoppelter Systeme verfolgen Web Services (W3C, 2009). Sie werden durch zahlreiche Standards umfassend beschrieben und haben sich in der Praxis durchgesetzt. Daher wird durch den Einsatz von Web Service technische Interoperabilität erreicht. Web Services definieren auch Aspekte der syntaktischen Interoperabilität, soweit sich dies auf die Verbindung bezieht. Die syntaktischen Möglichkeiten der Integrationsfunktion sind teilweise bereits dadurch vorgegeben, dass materialisierende Integration erfolgen soll. In der Analyse materialisierender Replikationsalgorithmen wurden deren Freiheitsgerade diskutiert. 27 Die Komplexität herkömmlichen EDI liegt zum Teil auch in der Komplexität des verwendeten textbasierten Datenformats, denn die Schemata der Datenaustauschnachrichten sind fest definiert jedoch aus den Nachrichten selber für Menschen nur schwer deduktiv verständlich. Daher wurde XML (W3C, 2004) als Datenmodell entwickelt, welches sowohl maschinell verarbeitbar als auch für Menschen verständlich ist. Durch die Definition von XMLbasierenden Standards für die B2B Integration entstand so XML-basierendes EDI. Beispiel 6: Der XML basierte Standard BMEcat erlaubt die Beschreibung von Produktkatalogen (Bundesverband Materialwirtschaft Einkauf und Logistik e.v., 1999). Im Gegensatz zur EDI Nachricht PRICAT ist er für Menschen deduktiv verstehbar und durch verbreitete XML-Standardtechnologien maschinell verarbeitbar. Von dieser Entwicklung soll profitiert werden, weshalb XML als alleiniges Datenmodell gewählt wird. Materialisierende Integration beruht auf der Änderung verteilter Kopien. Bereits in der Herleitung der Anforderungen wurde beschrieben, dass die Integration nicht durch ein vorgegebenes Schema realisiert werden kann. Ohne Anforderungen an die Datenaustauschschemata zu stellen kann nicht davon ausgegangen werden, dass diese Schemata Änderungen semantisch abbilden können. Änderungen müssen daher syntaktisch auf Datenmodellebene erkannt und formuliert werden und dürfen nicht auf schematische Ausdrucksmöglichkeiten angewiesen sein. Zur Transformation von XML-Dokumenten haben sich zwei Standards etabliert: XSLT (W3C, 1999) und das neuere XQuery (W3C, 2010). Zu XQuery wurde als Erweiterung XQuery Update (W3C, 2011) definiert, welche es erlaubt, Änderungsoperationen an XML- Dokumenten zu spezifizieren. Diese Erweiterung ist derzeit die einzige etablierte Sprache für diese Anwendung. Sie wird daher verwendet, um auf Datenmodellebene (XML) Änderungen syntaktisch formulieren zu können. Die strukturelle, schematische und semantische Interoperabilität ist durch die verwendeten Datenaustauschformate gegeben. Deren Auswahl ist Bestandteil jedes Integrationsprojektes, 27 Siehe Abschnitt

89 4.1 Konnektor jedoch kann der Integrationsaufwand durch die Verwendung von Datenaustauschstandards 28 minimiert werden, da hier eine hohe Wiederverwendung erwartet werden kann. Jeder Datensatz, der in einem Informationssystem gespeichert ist, stellt eine Referenz auf ein Objekt, eine Situation oder einen Prozess der realen Welt dar. Im Folgenden werden diese zusammenfassend als Realweltobjekte bezeichnet. Werden mehrere Datenbasen miteinander integriert, können Dubletten entstehen, sofern ein Realweltobjekt in mehreren Datenbasen referenziert wurde. Die Integrationsfunktion muss daher Mechanismen vorhalten, um durch die Integration entstehende Dubletten frühzeitig zu erkennen. Erschwert wird dies, da es jedem Informationssystem prinzipiell erlaubt ist, seine Objekte zu ändern und seine Objekte schematisch abweichend zu beschreiben. Es kann daher für die Integrationsfunktion nicht ausreichen, Dubletten nur dann als solche zu erkennen, wenn ihre Daten identisch sind. Die Integrationsarchitektur muss daher Algorithmen zur Dublettenerkennung umsetzen, um vor der Neuanlage eines Objektes zu verifizieren, dass durch die Neuanlage kein Duplikat entsteht. Hierfür einsetzbare Algorithmen setzen unscharfe Suchen ein (Fellegi und Sunter, 1969), um möglichst alle Referenzen zu einem Realweltobjekt zu identifizieren (Monge und Elkan, 1997; Hernández und Stolfo, 1998; Bhattacharya und Getoor, 2004; Chen et al., 2005; Dong et al., 2005). Sie wurden ausführlich durch Elmagarmid et al. (2007), Rahm und Do (2000) sowie Rahm und Bernstein (2001) beschrieben. Wurden die Datensätze nicht in unterschiedlichen Informationssystemen, sondern sind als Repliken voneinander bekannt, dann muss eine eindeutige Identifizierung möglich sein. Dies ist der Fall, wenn ein Objekt ursprünglich nur in einem Informationssystem angelegt und durch VIANA in weitere Informationssysteme repliziert wurde. In diesem Fall sind unscharfe Suchen ungeeignet, da sie immer mit einer Unsicherheit behaftet sind. Wie bereits oben beschrieben werden stattdessen Mapping-Tabellen eingesetzt. Diese werden detailliert in Abschnitt 5.2 beschrieben. Unscharfe Suchen müssen also eingesetzt werden, wenn: ein neues Objekt empfangen wurde. Hier muss untersucht werden, ob im integrierten Informationssystem bereits eine Referenz auf dieses Realweltobjekt gespeichert ist. In diesem Fall müssen die Referenzen zusammengeführt werden. Dubletten im integrierten Informationssystem gefunden werden sollen. Da zwei Informationssysteme aufgrund ihres abweichenden Informationsgehalts zu unterschiedlichen Entscheidungen kommen können, ist durch eine Konsolidierung dieser Entscheidungen eine Zunahme der globalen Datenqualität zu erwarten. Hierbei wird negative Entropie (Demers et al., 1987; Terry et al., 1995) zwischen Informationssystemen ausgetauscht. 28 Bspw. BMEcat für Produktdaten, vcard für Kontakte oder vcal für Kalendereinträge. 89

90 4 Eine Architektur zur Integration von KMU-Wertschöpfungsnetzwerken 4.2 Schematische Ebenen im Integrationsprozess Durch Modularisierung wird die Komplexität eines Systems leichter beherrschbar (Parnas, 1972). Im Entwurf von Datenbanksystemen wird dies berücksichtigt, indem das Schema gemäß den Anforderungsbereichen modularisiert wird. Diese sind als schematische Ebenen bekannt (Elmasri et al., 2009). Je nach Art des Systems werden drei oder mehr Ebenen definiert. In einem lokalen RDBMS sind dies das physikalische, konzeptionelle und exportierte Schema (Leser und Naumann, 2007). Diese bezeichnen die Darstellung zur Speicherung (physikalisches), das logische Schema (konzeptionelles) und Darstellungen für externe Abnehmer (exportiertes Schema). Durch das Konzept der schematischen Ebenen wird die Abhängigkeit der Anforderungsbereiche untereinander reduziert. So wird es möglich, dass die Art der physikalischen Datenspeicherung geändert werden kann, ohne dass das logische Datenbankschema davon beeinflusst wird (Kemper und Eickler, 2009). Um eine hohe Wiederverwendbarkeit der Komponenten der Integrationsarchitektur zu erreichen und die Speicherung im Informationssystem vom Datenaustausch zu entkoppeln, wird sich daher dieses Konzeptes bedient. Die für die optimistische Integration durch VIANA benötigten schematischen Ebenen sind in Abbildung 4.6 dargestellt Natives Schema Bei der Integration eines Informationssystems kann der Konnektor nur auf ein exportiertes Schema dieses Informationssystems zugreifen. Dieses Schema ist durch den Konnektor nicht Semantische Schnittstellen zu benachbarten Konnektoren Exportiertes Schema 1 Konnektor Viana Framework Exportiertes Schema n Generisches XML Schema zur Konfliktbehandlung Konzeptionelles Schema Peer-spezifisches XML Schema zur Identifikation von Objekten Semantische Schnittstelle zu Informationssystem Adapter Lokales Schema Natives Schema Semantische Schnittstelle für externe Systeme (u.a. VIANA) Informationssystem Exportiertes Schema Transformation Transport Abbildung 4.6: Relevante schematische Ebenen 90

91 4.2 Schematische Ebenen im Integrationsprozess beeinflussbar, da sonst die Autonomie des Informationssystems verletzt würde. Der Adapter benötigt daher eine Schnittstelle, die den Datenaustausch in dem durch das Informationssystem vorgegebenem Datenschema und auch dem vorgegebenem Datenmodell ermöglicht. Das Schema muss daher an die Heterogenitäten der Informationssysteme angepasst werden können, um die Kommunikation zwischen dem Informationssystem und dem Konnektor zu realisieren. An dieses Schema können folglich keine verallgemeinerbaren Anforderungen gestellt werden. Für diese schematische Ebene wird die Bezeichnung natives Schema verwendet Lokales Schema Um eine eindeutige Identifikation von Objekten realisieren zu können, muss ein Konnektor über die Information verfügen, welche Attribute einer Klasse sich zur Identifikation ihrer Objekte eignen. Aufgrund der Heterogenität der Informationssysteme kann nicht davon ausgegangen werden, dass diese Primärschlüssel oder ähnliche Konstrukte explizit implementieren und für externe Anwendungen transparent gestalten. Das native Schema muss also mit semantischen Informationen angereichert werden können. Als einheitliches Datenmodell soll ferner XML verwendet werden. Es muss daher eine schematische Ebene geben, welche die Daten aus dem Datenmodell des Informationssystems in XML überführt diese wird als lokales Schema bezeichnet. Es verfügt über die Semantik der verarbeiteten Objekte und kann diese daher voneinander abgrenzen und sie identifizieren Konzeptionelles Schema Um den Aufwand für die Realisierung eines Integrationsprojektes möglichst gering zu halten, müssen möglichst viele Funktionalitäten lauffähig sein, ohne dass sie jeweils neu implementiert oder instanziiert werden müssten. Zu diesen generischen Funktionalitäten sollen die Konfliktbehandlung und die Duplikatserkennung gehören. Es muss also eine generische schematische Ebene realisiert werden, auf der generische Funktionalitäten umgesetzt werden können. Das konzeptionelle Schema bildet diese generische Sicht und erlaubt so syntaktische Funktionalitäten (Abbildung 4.7). Hierfür muss es folgende Anforderungen erfüllen: Lokale Objekte müssen separiert werden. Zu jedem lokalen Objekt müssen jeweils alle globalen IDs aufgelistet sein. Da die Konfliktbehandlung auf diesem Schema ausgeführt werden soll ist weiterhin lokale Kontextinformation notwendig. Die schematische Darstellung der Nutzdaten kann frei definiert werden. Wenn sich die Daten des Informationssystems auf einen Standard abbilden lassen, dann kann dieser hier verwendet werden. 91

92 4 Eine Architektur zur Integration von KMU-Wertschöpfungsnetzwerken <VianaEntities> <VianaEntity> <GlobalIds> <GlobalId>GlobalId1</GlobalId> </GlobalIds> <LocalAttributes> <LocalAttribute> <Name>Class</Name> <Value>Article</Value> </LocalAttribute> </LocalAttributes> <Data> <article> <articleid>1</articleid> Abbildung 4.7: Umsetzung des konzeptionellen Schemas Separation lokaler Objekte Globale Ids Lokale Kontextinformation Nutzdaten <descriptionshort>a</descriptionshort> <price>23</price> </article> </Data> </VianaEntity> </VianaEntities> Exportiertes Schema Als letzte schematische Ebene wird eine Sicht auf die Daten benötigt, welche sich zum Datenaustausch eignet. Da keine Vorgabe gemacht werden darf, welche Datenaustauschformate geeignet sind oder verwendet werden sollen, müssen beliebig viele Datenaustauschformate verwendet werden können. Es wird daher eine weitere schematische Ebene eingeführt: die exportierten Schemata eines Konnektors. Exportierte Schemata realisieren somit die semantischen Schnittstellen zu benachbarten Konnektoren, wobei ein exportiertes Schema ein Datenaustauschformat realisiert. Auch wenn die Wahl der Datenaustauschformate frei ist, so kann doch ein höherer Wiederverwendungsgrad an schematischen Elementen und an Transformationen erreicht werden, wenn hierfür Standards verwendet werden. Diverse fachliche Standards mit unterschiedlichen semantischen Ausrichtungen können unterstützt werden, sodass sich unterschiedliche Anforderungen durch unterschiedliche Standards bedienen lassen. Hierdurch wird erreicht, dass die Notwendigkeit für eine Eigenentwicklung eines Datenaustauschformates reduziert wird (Chari und Seshadri, 2004). Die Öffnung der Architektur zur parallelen Verwendung mehrerer Datenaustauschformate ermöglicht die Autonomieerhaltung der integrierten Organisationen und Informationssysteme. Gleichzeitig kann sie jedoch auch eine hohe Komplexität verursachen, da erlaubt ist, dass jede Integrationsbeziehung über ein eigenes Datenaustauschformat verfügt. Hierbei würde der Aufwand für die Pflege der Transformationen und Schemata mit jeder neuen teilnehmenden 92

93 4.2 Schematische Ebenen im Integrationsprozess Konnektor 2 Exportiertes Schema 1 Konnektor 2 Exportiertes Schema j Konnektor n Exportiertes Schema 1 Konnektor n Exportiertes Schema k Konnektor 1 Exportiertes Schema 1 Konnektor 2 Konnektor n Konnektor 1 Konnektor 2 Exportiertes Schema j Konnektor m Exportiertes Schema l Konnektor n Exportiertes Schema k Konnektor 1 Exportiertes Schema 1 Konnektor 1 Exportiertes Schema i Transformation zum exportierten Schema des empfangenden Konnektors Transport Abbildung 4.8: Transformationen zwischen exportierten Schemata Organisation stark zunehmen 29. Obwohl dies theoretisch möglich ist, ist hiervon in der Praxis nicht auszugehen, da nicht erwartet werden muss, dass jedes KMU ein eigenes Datenaustauschformat definiert. Wahrscheinlicher ist es daher, dass sich einige wenige Datenaustauschformate etablieren werden, welche häufig zur Anwendung kommen. Durch einen Dienstleister kann diese Entwicklung begünstigt werden. In der Darstellung der Daten im exportierten Schema ist feststellbar, ob eine Operation für eine Datensenke relevant ist. Irrelevante Operationen können so ausgefiltert werden und erhöhen die Skalierbarkeit der Architektur (Blakeley et al., 1986) Transformationen Zwischen den beschriebenen schematischen Ebenen sind jeweils Transformationen notwendig. Lediglich die Transformationen zwischen nativem und lokalem Schema basieren nicht notwendigerweise auf XML. Da Konnektoren autonom sind, wird nicht verlangt, dass benachbarte Konnektoren über ein gemeinsames exportiertes Schema verfügen. Es wird daher eine Transformation zwischen den exportierten Schemata des Absenders und Empfängers benötigt. Ausführen kann diese Transformation nur der Absender, denn bei einer eingehenden Operation muss vorausgesetzt werden, dass sie einem dem Empfänger bekannten Schema konform ist. Dem Empfänger sind nur seine exportierten Schemata bekannt, er verfügt über keine Information zu den Schemata des Absenders. Somit ist es nur für den Absender möglich, seine Daten in ein exportiertes Schema des Empfängers zu transformieren. Dies bedeutet allerdings nicht, dass der Aufwand für die Integration immer beim Absender liegt, schließlich ist der Empfänger in der Lage, beliebige dem Absender angepasste exportierte 29 nn ( 1) 93

94 4 Eine Architektur zur Integration von KMU-Wertschöpfungsnetzwerken Schemata anzubieten. Abbildung 4.8 zeigt die exportierten Schemata im Zusammenspiel mehrerer Konnektoren. Zusätzlich zu den beschriebenen Transformationen zwischen schematischen Ebenen sollen auch spezielle filternde Transformationen eingesetzt werden können. Diese sollen den Informationsgehalt reduzieren und die Sichtbarkeit von Daten im Sinne der Durchsetzung von Zugriffsrechten oder des Datenschutzes einschränken. Diese filternden Transformationen sollen in jedem Transformationsschritt zusätzlich und unabhängig von jeder semantischen Transformation spezifiziert werden können. 4.3 Benutzungsschnittstellen Die Integration der Informationssysteme ist so ausgelegt, dass sie soweit möglich ohne menschliche Interaktion funktioniert. Allerdings kann eine Interaktion mit einem Fachanwender nicht komplett vermieden werden, Parameter der Integration müssen durch Administratoren geändert werden können. Daher muss das Konzept zwei unterschiedliche Benutzungsschnittstellen vorsehen Operative Benutzungsschnittstelle Im laufenden Betrieb ist es für den Fachanwender in zwei Situationen notwendig, mit der Integrationsarchitektur zu kommunizieren: Wenn zwei zueinander in Konflikt stehende Operationen erkannt werden, ist es in den meisten Fällen nicht automatisiert möglich, eine Operation zu entwerfen, die die Erwartungen beider Operationen erfüllt. Werden mehrere Referenzen auf ein identisches Realweltobjekt erkannt, so müssen diese zusammengeführt werden. Die Erkennung von Dubletten ist einerseits unscharf und dadurch mit einer Ungenauigkeit verbunden (Fellegi und Sunter, 1969), andererseits können zwei Referenzen widersprüchliche Informationen enthalten. Daher kann keine automatisierte Entscheidung erfolgen. In diesen Fällen ist es daher notwendig, dass der Anwender fachlich entscheidet. Zu diesem Zweck muss er mit der Integrationsarchitektur interagieren. Die anfallenden Aufgaben werden am besten im Kontext des integrierten Informationssystems gelöst (Strong et al., 1997b). Nicht zuletzt, da dies die notwendige Einarbeitungszeit des Anwenders reduziert (Engle und Barnes, 2000). Daher ist es notwendig, die Kommunikation so zu gestalten, dass sie in das integrierte Informationssystem integriert werden kann. Dies darf allerdings nicht obligatorisch sein, da eine zwingende Anpassung des integrierten Informationssystems vermieden werden muss. Die operative Benutzungsschnittstelle wird daher als Softwarekomponente entworfen, welche über entfernte Funktionsaufrufe basierend auf Web Services (W3C, 2009) mit einem Konnektor kommuniziert. Die Web Service-Schnittstelle muss beschrieben sein, sodass ihre Verwendung durch alternative Implementierungen möglich ist. 94

95 4.3 Benutzungsschnittstellen Die Benutzungsschnittstelle muss eine Aufgabeliste umsetzen, in der alle durch den Benutzer zu lösende Konflikte im Überblick dargestellt werden. Jeder Konflikt muss innerhalb der operativen Schnittstelle gelöst werden können. Zusätzlich muss es möglich sein, Informationen zu einem spezifischen Objekt darzustellen. Hier müssen Konflikte dieses Objektes dargestellt werden können. Dies wird angestrebt, um den Anwender innerhalb des Informationssystems während der Verwendung des Objektes über offene Aufgaben informieren zu können. Nebst den Aufgaben muss die operative Benutzungsschnittstelle die Änderungshistorie eines Objektes darstellen können. Dies soll dem Anwender transparent darstellen welche Änderungen durch wen angestoßen wurden, die seine Datenbasis geändert haben (Buneman et al., 2001). Hierdurch wird Transparenz geschaffen, die Anwendern eine subjektive Bewertung der Datenqualität ermöglichen (Madnick et al., 2009). Dies ist notwendig, da wichtige Dimensionen der Datenqualität etwa Hohes Ansehen oder Glaubwürdigkeit nur subjektiv bewertet werden können (Lee et al., 2002) Administrationsoberfläche Um ein KMU-spezifisches Dienstleistungsangebot ermöglichen zu können, ist die administrative Benutzungsschnittstelle von zentraler Bedeutung. Sie wird daher so ausgelegt, dass sie entfernt ausführbar ist und mit mehreren Konnektoren parallel verbunden werden kann. Durch diese Zentralisierung der Administration wird Wiederverwendung und Parallelisierung der Administration ermöglicht. Dabei sollen mehrere Dienstleister parallel auf die Integrationsarchitektur zugreifen können und jeweils nur die jeweiligen Ausschnitte der Topologie angezeigt bekommen und administrieren dürfen, zu denen ihnen Zugriff gewährt wurde. Zur Vertrauensbildung ist es ferner notwendig, dass zur Administration nur notwendige operativen Daten sichtbar sind. Dies erst ermöglicht das Vertrauen in den Dienstleister (Ratnasingam, 2005). Über die Administrationsoberfläche sollen folgende Aufgaben bearbeitet werden: Attribute eines Datenschemas sollen mit fachlichen Informationen annotiert werden können. Hierdurch soll ein globales Metadatenmanagement erreicht werden. Die Topologie des Graphen soll konfigurierbar sein. In einem graphischen Modell sollen hierfür Konnektoren modelliert werden können. Zusätzlich sollen Transformationsbeziehungen zwischen Konnektoren angelegt werden können. Exportierte Datenschemata sollen modelliert werden können. Transformationen zwischen lokalem und exportierten Datenschemata sollen modelliert und konfiguriert werden können. Lokale Optionen von Konnektoren sollen editierbar sein. Das Laufzeitverhalten des Integrationsnetzwerkes soll überwachbar sein. Die administrative Oberfläche muss dafür zwei graphische Modelle realisieren. Zum einen ist dies eine Schemaverwaltung zur organisatorischen Kontrolle von Stammdatenobjekten. Dieses Modell soll es erlauben, Stammdatenobjekte in UML-Notation (OMG, 2010) zu modellieren und mit fachlichen Metadaten zu annotieren. Diese sind beispielsweise der zuständige Data Steward, eine genaue Beschreibung der Relationen und Attribute oder Beispiele der Verwen- 95

96 4 Eine Architektur zur Integration von KMU-Wertschöpfungsnetzwerken dung. Diese fachlichen Metadaten sollen Organisationen unterstützen, Master Data Governance Initiativen umzusetzen und so auf organisatorischer Ebene hohe Datenqualität zu unterstützen (Madnick und Zhu, 2006). In der Schemaverwaltung sollen mehrere Schemata erstellt werden können, um sie wiederverwendbar vorzuhalten und unterschiedlichen Konnektoren zuzuweisen. Sie sollen in Konnektoren als internes Datenschema und Datenaustauschformat benutzbar sein. Das zweite graphische Modell soll die Topologie eines Integrationsnetzwerkes wartbar machen. Das Netzwerk soll als Graph dargestellt werden, wobei es zwei Knotenarten geben muss: Konnektoren mit jeweils einem assoziierten konzeptionellen Schema und Datenaustauschformate (exportierte Schemata). Verbunden werden sollen die Knoten über gerichtete Kanten, die Transformationen repräsentieren. Durch diese Modellelemente ist das Integrationsnetzwerk vollständig modellierbar. Durch die zentrale Verwaltung von Transformationen soll eine operative Wiederverwendung (Schwinn und Winter, 2005) ermöglicht werden. Weiterhin soll die zentrale Pflege von Metainformationen ein globales semantisches Verständnis der integrierten Informationen fördern. Soweit es organisatorisch möglich und erwünscht ist erlaubt dies die Konvergenz der Beschreibung von Stammdaten über System- und organisatorische Grenzen hinweg. Dies unterstützt eine hohe Datenqualität in Bezug auf das Datenschema (Moody und Shanks, 2003). Da es keine zentralen Konfigurationsserver gibt, muss die Topologiekonfiguration zu jedem betroffenem Konnektor einzeln übermittelt werden. Hierfür muss die Benutzungsschnittstelle über die Adressen der entsprechenden Web Service-Endpunkte verfügen, um bilaterale Verbindungen aufbauen zu können. Eine weitere Funktionalität der Topologiekonfiguration muss es sein, lokale Optionen einzelner Konnektoren bearbeitbar zu gestalten. Da Konnektoren als Framework und angepasste Adapter realisiert sind, muss auch die Menge dieser Optionen anpassbar sein. Lokale Optionen sind notwendig, um die Kommunikation mit dem integrierten Informationssystem, die Datenqualitätsalgorithmen u.ä. zu konfigurieren. Es muss daher eine Möglichkeit geben, die Menge der lokalen Optionen und ihre Wertebereiche zu spezifizieren. Ein Sprache, um Schemata auf Basis von XML zu spezifizieren, ist XML-Schema Definition (XSD) (W3C, 2004). Ihre semantische Ausdrucksstärke ist ausreichend, um die Menge der lokalen Optionen spezifizierbar zu gestalten. Ferner existieren Standardtechnologien, welche die Validität von XSD und die Konformität von XML-Dateien mit einer XSD überprüfen können. Für die Spezifikation der lokalen Optionen soll daher XSD verwendet werden. Die lokalen Optionen sollen in einer dieser XSD entsprechend gültigen XML-Datei übermittelt werden. Um das Laufzeitverhalten der Integrationsarchitektur überprüfbar zu gestalten, müssen Konnektoren Kennzahlen erfassen. Diese müssen durch die administrative Oberfläche ausgelesen werden können. 96

97 5 Optimistische Integration Optimistische Replikation ist ein Verfahren, welches ohne den Einsatz von Sperren schematisch identische Datenbestände miteinander abgleicht (Saito und Shapiro, 2005). Wenngleich für die Integration heterogener Informationssysteme in KMU- Wertschöpfungsnetzwerken auf Sperrmechanismen verzichtet werden muss, eignet sich optimistische Replikation nicht, da die Datenbasen zweier Informationssysteme nur in Ausnahmefällen schematisch identisch sind. Es wird daher der Begriff optimistische Integration eingeführt. Er wird verwendet, um eine sperrenfreie Integration heterogener Informationssysteme umfassend zu beschreiben, und definiert als relevante Aspekte die systemübergreifende Objektidentifikation sowie die Konfliktbehandlung. 5.1 Definitionen Zur Beschreibung der optimistischen Integration sind mehrere Definitionen notwendig. Definition 4: Sei p eine Menge von Konnektoren p i. Zwei Konnektoren p i und p j können durch eine gerichtete Kante e i, j verbunden werden. Weiterhin sei e die Menge der Kanten. Die Gesamtheit der Konnektoren bildet einen gerichteten Graphen Gpe (, ) Definition 5: Als benachbart werden zwei Konnektoren p i und p j bezeichnet, wenn sie über mindestens eine direkte Kante e i, j verbunden sind. Wobei e i, j als ausgehende Kante zu p i und eingehende Kante zu bezeichnet wird Definition 6: p j Ein Pfad w ist eine sortierte Abfolge an Kanten (1) w ei, j ej, k el, m, wobei für beliebige zwei aufeinanderfolgende Kanten gilt (2) ei, j ej, k Definition 7: Sei k die Definition der Klasse k. Ein Objekt dieser Klasse ist gegeben durch o k k. Ein spezifisches Attribut l dieses Objektes ist gegeben durch o l k. Die lokale Klasse, die das Objekt k in Konnektor pi definiert, wird bezeichnet als k( pi) Definition 8: Das gesamte Schema des Konnektors pi ist gegeben durch den Raum ( p i ) (3) ( p ) o ( p ) i k i k Definition 9: Als Transformation wird eine Abbildung bezeichnet, die ein Objekt von einer schematischen Darstellung in eine nicht notwendigerweise andere Darstellung überführt Definition 10: Wird ein Objekt o k in Konnektor p i instanziiert, so sei es als ok( p i) notiert. Ohne Beschränkung der Allgemeinheit wird weiterhin davon ausgegangen, dass ein Objekt zu jeder gegebenen Zeit t für ein Konnektor pi in einem eindeutigen Zustand ok( pi, t) ist

98 5 Optimistische Integration Definition 11: Eine Operation (4) o * k( pi) u( ok( pi)) überführt ein Objekt von einem Zustand ok( p i) in einen nicht notwendigerweise anderen Zustand o * k( p i). Ist o * k( pi) ist u eine Löschoperation. Ist hingegen ok( pi) so wurde das Objekt neu angelegt. Andernfalls wurde das Objekt geändert Definition 12: Operationen werden auf Pfaden als Sequenzen propagiert. Wird also eine Operation erst in p i und anschließend in p j ausgeführt, so wird dies folgendermaßen notiert: (5) uo ( ( p)) uo ( ( p)) 5.2 Objektidentifikation k i k j Im Gegensatz zu Einfügeoperationen beziehen sich ändernde und löschende Operationen auf ein bereits existentes Objekt. Durch die Autonomie der Informationssysteme kann jedoch kein Attribut definiert werden, das alle Objekte global eindeutig identifiziert. Die Objektidentifikation muss daher Teil der Integrationsarchitektur sein. Das Konzept von VIANA sieht Mapping-Tabellen (Kementsietsidis et al., 2003) für diese Aufgabe vor. Mapping-Tabellen speichern eine umkehrbare Abbildung zwischen lokalen und globalen IDs. Lokale IDs sind dabei definiert als für das integrierte Informationssystem eindeutige IDs. Globale IDs sind hingegen IDs, welche über alle Konnektoren des Integrationsnetzwerkes hinweg Objekte eindeutig identifizieren. Abbildung 5.1 zeigt die Definitionsbereiche der IDs bezogenen auf die schematischen Ebenen. Da keine zentrale Komponente existiert, welche globale IDs generieren könnte, müssen diese dezentral erzeugt werden. Dies geschieht durch einen Konnektor, wenn dieser eine Einfügeoperation aus dem Informationssystem ausgelesen hat. Zu diesem Zeitpunkt muss er davon ausgehen, dass das neue Objekt auch global neu ist. Wäre es nicht neu, so müsste es durch die Integrationsarchitektur bereits in das integrierte Informationssystem repliziert worden sein und wäre daher schon angelegt worden. Dieser Konnektor ist daher verantwortlich dafür, dem Objekt eine global eindeutige ID zuzuweisen. Diese wird zusammengesetzt aus einer global eindeutigen Bezeichnung des Konnektors (bspw. seine URI) und einer im Kontext des Konnektors eindeutigen ID. Letztere kann, muss aber nicht, identisch der lokalen ID sein. Wird ein Objekt versendet, wird es mit globalen IDs annotiert. Beim Empfang können hierdurch lokal betroffene Objekte identifiziert werden. Sollte eine globale ID lokal unbekannt sein, so muss das Objekt lokal neu angelegt werden. Die neue lokale ID wird dann in der Mapping-Tabelle mit der globalen ID verknüpft. Lokale IDs sind eindeutig Objekten zugeordnet, die im lokalen Schema definiert sind. Da kein globales Schema definiert ist, unterscheidet sich im Allgemeinen das Schema semantisch ähnlicher Klassen unterschiedlicher Konnektoren. 98

99 5.2 Objektidentifikation Globale IDs Konnektor Viana Framework Ziel-Konnektor Exportierte Schemata Quell-Konnektor Exportierte Schemata Konzeptionelles Schema Adapter Lokales Schema Natives Schema Integriertes System Exportiertes Schema Abbildung 5.1: Verwendung von IDs in schematischen Ebenen Für die folgende Betrachtung wird eine weitere Definition benötigt: Definition 13: Sei der Raum global eindeutiger IDs und ( p i ) der Raum in p i lokal eindeutigen IDs Eine Mapping-Tabelle ermöglicht zwei Funktionen global und lokal, die lokale und globale IDs liefern. Sie realisiert also n (6) global :{ o ( p ) ( p ), i o ( p ) i } i Lokale IDs k i k i g k i eine Funktion, die für das Objekt ok( p i) globale IDs liefert und weiter n (7) lokal i :{ ok( pi) k( pi), il, i ( pi) ok ( pi) il, i} eine Funktion, die für das Objekt ok( p i) lokale IDs liefert Sei im Folgenden p i die Datenquelle und p j die Datensenke. Im Allgemeinen muss daher eine Funktion definiert werden, welche n lokale IDs aus p i auf m lokale IDs in p j abbildet: n m (8) fi, j :{ ili, ( pi ), il, j ( pj ) ili, il, j} (9) f, ( o ( p)) lokal (global ( o ( p)) o ( p ) i j k i j i k i k j g 99

100 5 Optimistische Integration Die Funktion global ist abhängig von der Definition der Klassen in p i. Sie kann daher nur in dessen lokalem Schema definiert werden und muss zu jedem bekannten lokalem Objekt die entsprechenden globalen IDs liefern. Ist das Objekt unbekannt, dann wurde es neu angelegt; in diesem Fall muss eine neue globale ID generiert werden. Da die Definition lokaler Objekte im Allgemeinen in jedem Konnektor anders ist, ist auch die Granularität der globalen IDs unterschiedlich. Es kann daher nicht ausgeschlossen werden, dass der Konnektor, der die Daten des lokalen Objektes ursprünglich erzeugt hat, hierfür mehrere globale IDs angelegt hat. Die Zielmenge von global ist daher n dimensional. Die Funktion lokal ist die Umkehrfunktion zur Funktion global in p j. Sie liefert zu jeder globalen ID die im lokalen Schema von p j definierten lokalen IDs. Analog zu global ist ihre Zielmenge m dimensional. Die Mapping-Tabelle realisiert also eine n:m Abbildung lokaler auf globale IDs. Zwei Spezialfälle werden untersucht. Sind beide Schemata semantisch kongruent, gilt (10) ( p ) ( p ). k i k j In diesem Fall existiert eine bijektive Abbildung 1 1 (11) f :{ i ( p ), i ( p ) i i }, i, j l, i i l, j j l, i l, j welche eineindeutig lokale IDs in p i lokalen IDs in p j zuweist. In diesem Fall existiert ein einzelner Eintrag in der Mapping-Tabelle. Ist das Zielschema semantisch ausdrucksstärker (12) ( p ) ( p ), existiert eine Abbildung (13) k i l j n 1 i, j li, i), l, j j ) li, l, j f :{ i ( p i ( p i i }. In diesem Fall können also mehrere lokale IDs aus p i einer lokalen ID in p j zugewiesen werden. Die Abbildung in p j ist daher eindeutig, auch wenn die Operation mit mehreren globalen IDs annotiert ist. In der Mapping-Tabelle existieren in diesem Fall also mehrere Einträge mit unterschiedlichen globalen IDs zu einer lokalen ID. Lokale ID Globale ID Letzte Operation 42 Peer2.de/hcb11fft :31:34 42 Peer7.de/8774gt :31: Peer 1.de/ :15:21 Tabelle 5.1: Exemplarische Mapping-Tabelle (Peer 1) 100

101 5.3 Ausführungspläne Lokale ID Globale ID Letzte Operation 42 Peer 1.de/ :15: Peer 1.de/ :15: Peer 2.de/hcb11fft :31:30 NULL Peer 7.de/8774gt :34:01 Tabelle 5.2: Exemplarische Mapping-Tabelle (Peer 2) Tabelle 5.1 zeigt eine exemplarische Mapping-Tabelle für Peer 1. Zusätzliche lokale Schlüssel wie das fachliche Objekt sind vernachlässigt worden. Der dritte Eintrag dieser Tabelle (lokale ID 4711) wurde in Peer 1 angelegt. Er wurde zu Peer 2 (Tabelle 5.2) propagiert. Dort wurde identifiziert, dass von dieser Operation im lokalen Kontext zwei fachliche Objekte betroffen sind, weshalb es mit den lokalen IDs 42 und 227 eingefügt wurde. In Tabelle 5.1 werden weiterhin zwei unterschiedliche globale IDs auf die identische lokale ID 42 abgebildet. Da in diesem Fall unterschiedliche Peers involviert sind, ist dies ein Indiz dafür, dass zwei Objekte als Dubletten identifiziert und zusammengeführt wurden. Wurde ein Objekt, anstatt dass es gelöscht wurde, als inaktiv markiert, muss ein Konnektor sicherstellen, dass Operationen auf dieses Objekt lokal nicht mehr ausgeführt werden. Zu diesem Zweck kann eine globale ID in der Mapping-Tabelle auf eine leere lokale ID (NULL) referenzieren (siehe auch Tabelle 5.2). 5.3 Ausführungspläne Ausführungspläne definieren in Datenbanksystemen, wie Anfragen ausgeführt werden (Kemper und Eickler, 2009). Das Ziel eines Ausführungsplans ist es, die optimale Ausführungsreihenfolge der einzelnen Bestandteile einer Anfrage zu berechnen. In der optimistischen Integration ist diejenige Ausführungsreihenfolge optimal, welche die wenigsten Konflikte generiert. Ein Konflikt besteht dann, wenn zwei Operationen nicht kommutieren. Terry et al. (1995) haben gezeigt, dass sich der Kommutator für einfache Integrationsszenarien durch semantische Informationen optimieren lassen, was jedoch in einem heterogenen Integrationsszenario nicht wirtschaftlich umsetzbar ist. Es muss daher syntaktisch ein optimaler Ausführungsplan erstellt werden. Für die optimistische Integration muss daher im Ausführungsplan ein Sortierungskriterium eingeführt werden, welches die Reihenfolge soweit möglich definiert. Hierdurch soll erreicht werden, dass nicht alle Operationen kommutieren müssen. Das Kriterium muss systemübergreifend gültig sein und ohne eine zentrale Instanz erzeugt werden können. Da sich Operationen aufeinander beziehen können, bietet es sich an, die Zeit als Kriterium zu wählen. Als Sortierungskriterium wird daher nach Lamport (1978) der Zeitpunkt der Erstellung der Operation gewählt. Konnektoren müssen daher, um den Ausführungsplan umzusetzen, sicherstellen, dass Operationen der chronologischen Reihenfolge ihrer Erstellung nach bearbeitet werden. Sie müssen dies sowohl für eingehende als auch für ausgehende Operationen gewährleisten. Realisiert werden kann dies durch chronologisch sortierte Warteschlangen. 101

102 5 Optimistische Integration 5.4 Konzeption der Konfliktbehandlung Durch die Integrationsarchitektur werden Objekte zwischen Informationssystemen optimistisch repliziert. Aufgrund der immanenten Parallelität können dabei Situationen auftreten, in denen Zugriffe auf Objekten nicht zu den von allen Beteiligten antizipierten Ergebnissen führen. Es müssen daher Mechanismen bestehen, um Konflikte zu lösen, die durch solche äußeren Einflüsse entstehen. Diese Konflikte werden im Folgenden als extrinsisch bezeichnet. Zusätzlich können jedoch in einer P2P-Architektur ohne zentralen Koordinator Konfliktsituationen entstehen, die keine parallelen Zugriffe als Ursache haben. Die Ursachen hierfür liegen ausschließlich im Aufbau der Architektur und sind für diese intrinsisch Intrinsische Konflikte Operationen werden in einem Graphen Gpe (, ) propagiert. Um die Autonomie der integrierten Informationssysteme zu erhalten erfolgt dies asynchron. Außerhalb eines Konnektors ist weitestgehend unbekannt, welche Objekte das Informationssystem enthält und wie ihr aktueller Zustand ist. Es wird daher verlangt, dass sich Operationen ausschließlich auf absolute Werte beziehen, die die folgende Bedingung erfüllen: (14) u( o ) u( u( o )). k Lineare Sequenz Zuerst wird eine konfliktfreie lineare Sequenz betrachtet. Sie ist in Abbildung 5.2 dargestellt und gegeben durch (15) u1( ok( p1)) u1( ok( p2)) u1( ok( p3)). Da nur lokal geänderte Informationen in einer ausgehenden Operation enthalten sind, kann in einer linearen Sequenz aufgrund von Sichten, die die Operation nicht vollständig abbilden können der Informationsgehalt nur reduziert werden (Fagin et al., 2005). Wenn ohne Beschränkung der Allgemeinheit Konnektoren in aufsteigender Reihenfolge benannt werden, sodass p i vor p j geändert wird, gilt also, wenn i j (16) u( o ( p )) u( o ( p )). k i k j k p1 u p2 1 u 1 p4 p3 Abbildung 5.2: Lineare Änderungssequenz 102

103 5.4 Konzeption der Konfliktbehandlung Sequenzen in zusammenlaufenden Pfaden Eine Sequenz, die sich erst teilt und zu einem späteren Punkt wieder zusammengeführt wird, ist in Abbildung 5.3 gezeigt. Allgemein ist sie definiert durch zwei Pfade w 1 w 2 mit identischem Anfang und Ende. Abbildung 5.3 zeigt zwei Pfade: (17) w1: p1 p2 p3 und (18) w2: p1 p4 p3. Die Sequenz über w 1 ist gegeben durch (19) u1 ok p1 u1 ok p2 u1 ok p3 ( ( )) ( ( )) ( ( )) sowie über w 2 durch (20) u1( ok( p1)) u1 ( ok( p4)) u1 ( ok( p3)). Angenommen beide Sequenzen kommutieren, (21) ui ( ui( ok)) ui( ui ( ok) ), dann entsteht kein Konflikt beim Zusammenführen der Pfade. Aufgrund von (14) ist dies immer der Fall p1 u p2 1 u 1 u 1 p 1 4 p3 Abbildung 5.3: Sich aufteilende und zusammengeführte Operation Nicht terminierende Zyklen Seien ok( p i) und o k( pi) zwei Zustände eines Objektes. Weiterhin sei (22) u1 ( o ( )) ( ) k p i o k p i und (23) u2 ( ok ( pi )) ok ( pi ) in allen in einem zyklischen Pfad w 3 beteiligten Konnektoren. Zwei Sequenzen auf w 3 können dann eine geeignete zeitlich Abfolge vorausgesetzt in einem nicht terminierenden Zyklus resultieren (siehe Abbildung 5.4). u 103

104 5 Optimistische Integration p1 u p2 2 u 1 u 2 Abbildung 5.4: Nicht terminierender Zyklus u p 1 4 p3 Diese Situation wird verhindert, indem jeder Konnektor die Operations-ID eingehender Operationen sofort beim Empfang mit einer lokalen Datenbasis abgleicht. Ist die ID bereits vorhanden, wird die Operation ignoriert, andernfalls wird die ID in die Datenbasis übernommen und die Operation ausgeführt. Nach Wang und Amza (2009) ist dies die effizienteste Methode, um die Parallelität der optimistischer Replikation zu kontrollieren Segmentierte Graphen Bedingt durch die Topologie kann ein Graph durch das Entfernen eines Knoten in mehrere Segmente zerfallen (Abbildung 5.5). Wenn dies ein temporärer Zustand ist, müssen Mechanismen vorhanden sein, um den globalen Datenbestand nach der Reaktivierung des ausgefallenen Knoten zu harmonisieren. Dies wird erreicht, indem Operationen so lange in einer Warteschlange vorgehalten werden, bis: 1. der Empfänger den Empfang quittiert. Hierdurch wird der Effekt temporärer Ausfälle rückgängig gemacht, oder 2. die Kante zum Empfänger gelöscht wird. Hierdurch wird der Graph permanent segmentiert. p1 p2 w w 1 2 w1 w2 p4 p3 Abbildung 5.5: Segmentierter Graph Alle intrinsischen Konflikte können also durch den Bezug auf absolute Werte und die Verwendung von Operations-IDs vermieden werden Extrinsische Konflikte Oben wurden Konflikte betrachtet, die ohne äußere Einflüsse entstehen können. Die in diesem Abschnitt betrachteten extrinsischen Konflikte sind hingegen in widersprüchlichen externen Operationen begründet. Aufgrund der eingesetzten optimistischen Replikation können solche widersprüchlichen Operationen nicht a-priori ausgeschlossen werden. Hierfür wäre der Einsatz von Sperrmechanismen notwendig. 104

105 5.4 Konzeption der Konfliktbehandlung Widersprüchliche Operationen Zwei Operationen sind widersprüchlich, wenn: 1. sie dasselbe Realweltobjekt o k referenzieren, 2. in getrennten Informationssystemen u 1 ( o k ( p i )) und u 2 ( o k ( p j )) parallel erstellt wurden und 3. Pfade w i und w j, die jeweils eines dieser Systeme als Ausgangspunkt haben, in einem Konnektor p k zusammenlaufen. Ohne eine Konfliktbehandlung würde, nachdem u 1 und u 2 in allen System ausgeführt wurden, in allen Konnektoren, die in einer Sequenz hinter p k angeordnet sind, nur die zuletzt ausgeführte Operation dauerhaft gespeichert. Ziel von VIANA ist es, bereits durchgeführte Operationen zu integrieren. Daher wird ein zeitbasierter optimistischer Ansatz zur Konfliktresolution gewählt. Im lokalen Kontext ist jedes Objekt zu jedem Zeitpunkt t in einem eindeutigen Zustand ok( pi, t ). Für jedes Objekt kann weiterhin protokolliert werden, wann dieser Zustand erreicht wurde. Dies ist der Zeitpunkt t p der letzten Operation. Dieser Zeitpunkt muss für die Konfliktresolution in die Metainformationen der Operationen aufgenommen werden. Definition 14: Eine Operation bezieht sich explizit auf den Zeitpunkt t tp der vorherigen Operation, wenn sie wie folgt notiert ist: (24) uot (, ) Abbildung 5.6 zeigt folgende Situation: In p 2 wird ein Objekt zum Zeitpunkt t 0 aktualisiert. Sein geänderter Zustand ist: (25) ok ( p2, t0) u1( ok( p2, t 1), t 1 1) Parallel dazu wird in p 4 dasselbe Objekt geändert: (26) ok ( p4, t1) u2( ok( p4, t 1), t 1 1) Der durch die Topologie definierten Sequenz folgend wird das Objekt daraufhin in dem benachbarten System p 3 aktualisiert. Ohne Beschränkung der Allgemeinheit wird angenommen, dass dies zuerst durch u 1 geschieht: (27) ok ( p3, t0 0) u1( ok( p3, t 1), t 1). Wird anschließend u 2 ausgeführt, ergibt sich (28) ok ( p3, t1 1) u2( ok( p3, t0 0), t 1). p1 p2 u 1 p u 2 4 p3 Abbildung 5.6: Widersprüchliche Operationen 105

106 5 Optimistische Integration p 2 o ( p, k 2 t0 ) o ( p, t ) u ( o ( p, t )) k 2 1 i k 2 0 t 0 t 1 u o, t ) ( k i 0 p 4 p 3 t 2 t Abbildung 5.7: Zeiten in widersprüchlichen Operationen Durch u 1 in (27) durchgeführten Operationen gehen also verloren. Diese Situation kann erkannt werden, indem die Zeiten der vorherigen Operationen verglichen werden. Unter Berücksichtigung von Verzögerungen ( i ), die aufgrund der Netzwerkinfrastruktur und von Vorverarbeitungsschritten entstehen können, wird daher in der in Abbildung 5.7 dargestellten Situation verglichen, ob (29) t1 1 t 2 2 erfüllt ist. Zusätzlich zu den diskutierten i ist eine Toleranz i notwendig, um zu verhindern, dass Operationen aufgrund der Verarbeitungszeit als konfliktbehaftet eingestuft werden. Wenn (29) erfüllt ist, wird davon ausgegangen, dass sich die Operation auf dieselben oder Neuere als die lokal verfügbaren Daten bezieht. Eine solche Operation wird akzeptiert. Da in dem diskutierten Fall allerdings gilt t 2 2 t 1 1, ist eine notwendige Bedingung erfüllt, damit die Operation als konfliktbehaftet eingestuft wird. Obige Bedingung ist allerdings nicht hinreichend, da, wenn t 0 t 2 und t 1 t 2, sie den Konflikt nicht erkennt. Jede Operation muss daher über eine eindeutige Identifikation (Operations-ID) verfügen. Diese kann ähnlich einer globalen ID bestehend aus einem jeweils lokal und global eindeutigen Anteil zusammengesetzt werden. Es ist daher eine weitere notwendige Bedingung, dass für u i und u j gilt i j. Sind beide notwendigen Bedingungen erfüllt, wird die Operation als konfliktbehaftet eingestuft. Die alleinige Verwendung von Operations-IDs kann keine hinreichende Bedingung sein, da es durch sie nicht entscheidbar ist, ob zwei unabhängige zeitlich aufeinanderfolgende Sequenzen konfliktbehaftet sind. Um dies zu verdeutlichen werden zwei Sequenzen betrachtet. Zum Zeitpunkt t 1 wird ausgeführt (30) u1( ok( p1, t0), t0) u1( ok( p2, t0 ), t0). Anschließend wird zum Zeitpunkt t 2 t 1 ausgeführt (31) u2( ok( p1, t1), t1) u2( ok( p2, t1 ), t1). Beide Operationen stehen zueinander nicht im Konflikt. Da allerdings i j kann dies durch die alleinige Verwendung von Operations-IDs nicht erkannt werden. 106 t 1 o ( p ) k o ( p ) k 4, t 1 3, t 2 ok ( p4, t1 1) ui ( ok( p4, t 1), t0) t 1 1 t 2 t2 uj( ok, t 2) o k( p3, t2) uj ( ok( p3, t 2) ) 2

107 5.4 Konzeption der Konfliktbehandlung Erkannte Konflikte können im Allgemeinen nicht automatisiert gelöst werden. Ist ein Konflikt ein Einzelfall, können sie mittels Interaktion eines Benutzers gelöst werden. Hierfür muss eine geeignete Benutzungsschnittstelle zur Verfügung stehen Partiell segmentierte Graphen Allerdings können Konflikte auch entstehen, wenn ein Graph dergestalt segmentiert ist, dass Operationen aus einem Segment das jeweils andere Segment nicht erreichen und gleichzeitig ein drittes Segment existiert, das Operationen aus beiden getrennten Segmenten erhält. Formell bedeutet dies: nicht (32) u( op ( \ p)) u( op ( \ p )) i j j i Jedoch (33) p p p 0. k i j Konnektoren aus p k erfahren potentiell große Mengen zueinander in Konflikt stehender Operationen. In diesem Fall kann eine automatisierte Entscheidung, welche Operationen übernommen werden, vom Pfad abhängig gemacht werden Operationen auf lokal nicht existente Objekte Da sich Operationen auf existierende Objekte beziehen, schlagen sie fehl, wenn das entsprechende Objekt lokal nicht zur Verfügung steht. In diesem Fall kann ein Konnektor vom absendenden Konnektor verlangen, dass er das vollständige Objekt als Einfügeoperation zur Verfügung stellt. Abbildung 5.8 zeigt die involvierten Schritte: 1. Die Sequenz u( o k ( p2)) u( ) in p 3 schlägt fehl. 2. p 3 fordert o k von p 2 an. 3. p 2 sendet o k als Einfügeoperation an p 3. Um diesem Prozess vorzubeugen, oder wenn ein weiteres System in ein bestehendes Netzwerk integriert wird, muss ein Konnektor den gesamten bereits anderweitig publizierten Datenbestand des Informationssystems publizieren können. p1 p p 4 p 3 Abbildung 5.8: Operation auf lokal nicht existentem Objekt 107

108 6 Realisierung der Integrationsarchitektur VIANA Die Referenz Implementierung der Integrationsarchitektur VIANA soll deren Einsetzbarkeit belegen. Das wiederverwendbare Framework und die integrationsprojektspezifischen Adapter, werden hierbei getrennt dargestellt. Zur Realisierung gehört ferner die Umsetzung der Benutzungsschnittstellen (Droste et al., 2011). 6.1 Softwaretechnische Komponenten Komponenten erlauben die Strukturierung von komplexen Systemen und erhöhen somit deren Verständlichkeit, Analysierbarkeit und Wiederverwendbarkeit (Sommerville, 2007, S. 475). Die Zerlegung von Softwaresystemen in Komponenten hat sich daher als vergleichsweise grobgranulare Strukturierung im Entwurf von Softwaresystemen etabliert. Nach Weisbecker (2002, S. 147) bestehen die Vorteile komponentenbasierender Systeme in der individuellen Anpassbarkeit, welche durch die Nutzung vorhandener Komponenten eine geprüfte Qualität und eine kurze Montagezeit ermöglichen. Abbildung 6.1 gibt einen Überblick der funktionalen Komponenten VIANAs Komponenten der Adapter Für jedes integrierte System müssen die Komponenten, die die direkte Kommunikation des Konnektors mit dem integrierten Informationssystem steuern, angepasst werden. Da dem Informationssystem maximale Design- und Schnittstellen-Autonomie gewährt wird, entsteht in der Praxis Heterogenität (Leser und Naumann, 2007). Das Ziel dieser Komponenten ist es, die Heterogenität des Informationssystems aufzufangen. Dies wird erreicht, indem Interoperabilität mit dem Informationssystem durch die Implementierung eines Adapters hergestellt wird. Diese Komponenten sind daher im Allgemeinen nicht wiederverwendbar. Wenn bereits ein Adapter für identische oder ähnliche Schnittstellen implementiert wurde, so können jedoch auch diese wiederverwendet werden. Dies kann beispielsweise der Fall sein, wenn ein System über standardkonforme Web Service-Schnittstellen angebunden wird. Datenzugriff Diese Komponente ermöglicht den Zugriff auf die Daten des integrierten Informationssystems. Sie hängt funktional von diesem System, der Schnittstelle, den Interaktionsmustern, dem Datenmodell und dem Datenschema ab. Dies in eine homogene interne Struktur zu wandeln ist Aufgabe der Komponente Datenzugriff. Die Funktionalität, die ein Konnektor benachbarten Konnektoren anbietet, ist durch das Informationssystem in Bezug auf die enthaltenen Informationen und die Richtung der Kommunikation definiert.

109 6.1 Softwaretechnische Komponenten Benutzerinteraktion: - Konfliktbehebung - Metadaten - Informationsqualität Benachbarte Peers Administration: - Lokale Konfiguration - Topologie - Monitoring Zentrale Komponenten: - Transport - XQuery Update - Konfliktresolution - Zeitsynchronisation - Informationsqualität XML Datenbank: - Staging Area - Transformation Konfiguration: - Topologie - Lokale Optionen - Informationsqualität Adapter: - Beobachter - Datenzugriff Operative Daten: - Mapping Tabellen - Operations IDs - Metadaten Viana Framework Komponenten Informationssystem Abbildung 6.1: Funktionale Komponenten eines Konnektors Beobachter Diese Komponente ist verantwortlich für das Erkennen von atomaren Datenänderungen des Informationssystems. Sie stößt bei einer erkannten Operation die Verarbeitung an Komponenten des VIANA Frameworks Die im Folgenden beschriebenen Komponenten sind Bestandteil des Frameworks und stehen daher allen Instanziierungen als Whitebox-Framework wiederverwendbar zur Verfügung. Transformation XML wurde als internes Datenmodell gewählt, da bereits zahlreiche Technologien, Standards und Produkte für in XML formulierte Daten existieren. Transformationen können durch XSLT oder XQuery implementiert werden. Die Funktionalität, Transformationen auszuführen, wird durch diese Komponente bereitgestellt. Die Komponente selber kann realisiert werden, indem am Markt befindliche Produkte eingesetzt werden. Informationsqualität Um abweichende Referenzen auf ein Realweltobjekt zu identifizieren, stellt diese Komponente Algorithmen zur unscharfen Suche bereit. 109

110 6 Realisierung der Integrationsarchitektur Viana XQuery Update Erstellung Diese Komponente formuliert XQuery Update Befehlssequenzen. Als Eingabewerte dienen hierfür der Zustand des Objektes vor der Operation ok( p i) und der Zustand nach der Operation o * ( p ). Der Informationsfluss ist in Abbildung 6.2 dargestellt. k i o ( p ) k i XQuery Update Erstellung uo ( ( p)) k i o * ( p ) k i Abbildung 6.2: Informationsfluss der XQuery Update Erstellung Konfliktbehandlung Durch die optimistische Integration von Objekten in einem P2P-Netzwerk können Konflikte entstehen. Strategien, um mit diesen umzugehen, wurden diskutiert 30. Diese Komponente stellt Mechanismen zur Verfügung, um diese Strategien umzusetzen. Sie umfasst die Konflikterkennung und die Konfliktlösung. Dazu werden jeder publizierten Operation Metainformationen beigefügt. Diese enthalten die globale ID des Objektes, die Operations- ID, Zeitstempel vorheriger Änderungen des Objektes und alle Konnektoren, in denen diese Operation bereits ausgeführt wurde. Zeitsynchronisation Zueinander in Konflikt stehende Operationen werden unter anderem durch Zeitstempel identifiziert. Jedem Konnektor steht hierfür nur seine lokale Zeit (Lamport, 1978) zur Verfügung. Um Konflikte in verteilten Umgebungen identifizieren zu können, ist dies ungenügend. Allerdings ist es auch keine Option, die Systemzeiten der integrierten Informationssysteme anzugleichen, da dadurch die Autonomie und Stabilität dieser Systeme beeinflusst würde. Diese Komponente simuliert daher die lokalen Zeiten über eingehende Kanten benachbarter Konnektoren. Auf dieser Basis können die Zeitdifferenzen zu lokalen Zeit berechnet und somit die Zeiten eingehender Nachrichten auf die lokale Zeit normalisiert werden. Dies hat zur Folge, dass der Empfänger einer Operation nur die lokale Zeit des Absenders berücksichtigen muss. Die Zeitsynchronisation wird über das Network Time Protokoll (NTP) (Mills, 2010) realisiert. Administration Über die administrative Oberfläche können zwei Bereiche konfiguriert werden: Lokale Optionen eines Konnektors und die Netzwerktopologie. Diese Komponente bietet eine Web Service-Schnittstelle (W3C, 2009), über die aus anderen Applikationen die Konfiguration eines Konnektors durchgeführt werden kann. 30 Siehe Abschnitt

111 6.1 Softwaretechnische Komponenten Benutzerinteraktion Ist eine Operation nicht automatisch entscheidbar, dann ist Interaktion mit dem Benutzer über eine operative Benutzungsschnittstelle notwendig. Diese muss sich optional in das Informationssystem integrieren lassen. Daher wird auch eine generische operative Benutzungsschnittstelle erstellt. Transport Diese Komponente garantiert, dass Operationen zu benachbarten Konnektoren übermittelt werden. Hierfür werden Operationen in eine Warteschlange eingereiht und aus dieser erst wieder entfernt, wenn der Empfänger den Empfang quittiert hat. Der Transport wird durch die Verwendung von Web Service-Technologien 31 realisiert. Hierdurch werden nur geringe Anforderungen an jeden Konnektor gestellt, um in einem Netzwerk zu interagieren (Erasala et al., 2003). Gleichermaßen realisiert diese Schnittstelle eine Warteschlange für den Eingang von Operationen. Eingehende Operationen werden in diese Warteschlange eingereiht und in der Reihenfolge ihrer Erstellung sequentiell ausgeführt. Hierdurch wird die interne Verarbeitung von der Propagierung der Operationen entkoppelt und die korrekte Ausführungsreihenfolge gemäß dem Ausführungsplan gewährleistet. Um eine beidseitige Authentifizierung zu erreichen, erfolgt die Identifikation beider Verbindungspartner durch Zertifikate. Diese werden auch genutzt, um die Verbindung mit SSL oder TLS zu verschlüsseln (Lopez et al., 2004). Gerade die Verwendung von Zertifikaten hat sich noch nicht bei KMUs durchgesetzt. Der Grund hierfür liegt in der Komplexität der Technologie, die nicht ausreichend durch ein auf KMU spezialisiertes Leistungsangebot flankiert wird. In der Umsetzung von Integrationsprojekten durch Dienstleister entsteht hier die Möglichkeit, die Sicherheitsinfrastruktur von KMU auch über die Verwendung der Integrationsarchitektur hinaus zu verbessern (Backhouse et al., 2005). Datenbanken Zur Laufzeit benötigt ein Konnektor drei logisch getrennt Datenbanken. Die Parameter der administrativen und operativen Konfiguration müssen persistiert werden (Konfiguration). Die operativen Daten (Mapping-Tabellen, Operations-IDs und Metadaten) müssen vorgehalten werden. Schließlich wird eine XML-Datenbank als Ausführungsumgebung der Staging Area benötigt. Sie ist notwendig, um folgende Operationen auszuführen: Transformationen zwischen unterschiedlichen Datenschemata Filterung der Daten, um bestimmte Datensätze oder Attribute nicht zu übernehmen oder nicht zu publizieren Algorithmen zur Erhöhung der Datenqualität Formulierung der XQuery Update Statements auf Basis der Zustände eines Objektes vor und nach der Operation 31 Hierzu gehören u.a. folgende Protokolle und Standards: TCP, IP, http, SOAP, XML und WSDL 111

112 6 Realisierung der Integrationsarchitektur Viana 6.2 Implementierung des Integrationsframeworks In der Entwicklung von VIANA wurden verschiedene Technologien und Frameworks eingesetzt (Droste et al., 2011). VIANA wurde in Java EE unter Verwendung des Spring Frameworks implementiert. Java EE eignet sich besonders, da unter anderem sowohl synchrone als auch asynchrone Kommunikation sowie Applikationsserver unterstützt werden (Niemann et al., 2003). Die Erfassung von Kennzahlen sowie die Konflikterkennung wurden als Aspekte mittels AspectJ realisiert. Der Zugriff auf die eingebettete Datenbank H2 erfolgt über Hibernate unter Verwendung von SQL. Nachrichten verwenden als Datenmodell XML. Ihre Verarbeitung erfolgt in BerkeleyDB XML durch XQuery und XQuery Update. Als Framework für die Web Service-Kommunikation wird Apache CXF eingesetzt. Die Web Service- Kommunikation erfolgt durch JAX-WS. JAX-B wird verwendet, um Java Objekte in XML zu (de)serialisieren. Als Laufzeitumgebungen stehen Jetty und Tomcat zur Verfügung. Tabelle 6.1 fasst die Technologien zusammen. Einsatzgebiete Technologien Entwicklung Java EE (Sun Microsystems, 2011) XML (W3C, 2008) Spring (Spring Source, 2011) AspectJ (AspectJ, 2011) SQL XML-Ver-/Bearbeitung XQuery (W3C, 2010) XQuery Update (W3C, 2011) BerkeleyDB XML (Oracle, 2011a) Datenbanken Hibernate (JBoss, 2011) H2 (eingebettet) (H2, 2011) Kommunikation (Web Services) Apache CXF (Apache CXF, 2011) JAX-WS (JAX-WS, 2011) JAX-B (JAX-B, 2011) Laufzeitumgebung Jetty (Jetty, 2011) Apache Tomcat (Apache Tomcat, 2011) Tabelle 6.1: Eingesetzte Technologien Reduktion der Heterogenitäten Ziel von VIANA ist es, heterogene Informationssysteme zu integrieren. Um den Aufwand für die Integration zu minimieren, werden durch Konnektoren diese Heterogenitäten homogenisiert. VIANA ist in Java implementiert. Damit sind interne Schnittstellen durch Java Interfaces definiert. Diese werden synchron aufgerufen. Peer-to-Peer Kommunikation wird durch Web Services realisiert. Auch diese werden synchron aufgerufen, um eine erfolgreiche Übertragung quittieren zu können. Wie beschrieben, ist die interne Verarbeitung hiervon entkoppelt. Bezogen auf die Verarbeitung ist die Kommunikation daher asynchron. 112

113 6.2 Implementierung des Integrationsframeworks Schnittstelle Informationssystems Web Services Corba RMI JDBC/ODBC Interaktionsmuster Push/Pull Publish/Subscribe Periodisch überwachen Datenmodell Relational Objektorientiert XML Als internes Datenmodell wurde XML gewählt. In den generischen Schemata oberhalb des lokalen Schemas sind Daten daher immer in diesem Datenmodell formuliert. Die interne Darstellung der Daten bezogen auf ihre Struktur, Syntax, Schema und Semantik ist abhängig von der betrachteten schematischen Ebene. Diese wurden in Abschnitt 4.2 beschrieben. Tabelle 6.2 erläutert Heterogenitätsdimensionen und zeigt, welche internen homogenen Darstellungen gewählt wurden. Heterogenität Beispiele der Heterogenität des Interne homogene Darstellung in VIANA Java Web Services Synchrone Java Funktionsaufrufe Synchrone Web Service- Aufrufe XML Datenschema Beliebiges internes Schema Entsprechend der schematischen Strukturell Auf interne Verwendung hin optimiertes Schema Granularität von Attributen Ebene Syntaktisch Schematisch Semantisch Little Endian/Big Endian Unicode/ASCII Freiheit, Adresse als Attribut oder Relation zu definieren Freiheit, Kontext und Bezeichnungen zu definieren Tabelle 6.2: Heterogenitätsdimensionen Konfliktbehandlung Die Konfliktbehandlung gliedert sich in drei Teile. Das Logging schafft die Voraussetzung für die Konflikterkennung, welche wiederum Vorbedingung für die Konfliktbehebung ist. Diese drei Teile werden im Folgenden im Einzelnen beschrieben. Logging bezeichnet eine technische Protokollierung. VIANA protokolliert Operationen und Objektzustände. Operationen verfügen hierfür über Metadaten, die zusammen mit der Nutzlast propagiert werden. Diese sind in Tabelle F.1 zusammengefasst. Die Attribute, die zusätzlich für die lokale Konflikterkennung erhoben werden, sind in Tabelle 6.3 aufgeführt. 113

114 6 Realisierung der Integrationsarchitektur Viana Attribut Beschreibung locked Wahr, wenn die Operation momentan verwendet wird enabled Wahr, wenn die Operation erfolgreich ausgeführt wurde inconflict Wahr, wenn die Operation zu anderen Operationen im Konflikt steht merged Wahr, wenn der Konflikt dieser Operation gelöst wurde operationkpi Kennzahlen der Operation creationdate Erstellungszeitpunkt der Operation targetpeers Bei ausgehender Operation eine Liste der Peers, welche die Operation empfangen sollen allreadyknowntopeer Wahr, wenn die Operation lokal schon ausgeführt wurde concurrenttransactionids Liste der Operationen, mit der diese Operation in Konflikt steht Tabelle 6.3: Lokale Metadaten einer Operation Für Objektzustände werden die in Tabelle 6.4 aufgeführten Attribute gespeichert. Die Konflikterkennung basiert auf dem Vergleich der Zeitpunkte der letzten des Objekts, auf dem die Operation erstellt wurde ( t e ), mit dem Objekt auf dem die Operation ausgeführt werden soll ( t a ). Sie wird zu zwei Zeitpunkten ausgeführt: Bei Eingang einer Operation und direkt vor ihrer Ausführung. Operation werden als konfliktbehaftet eingestuft, wenn sie entweder gesperrte Objekte betreffen, oder wenn t a t e. Sind mehrere Objekte betroffen, so besteht ein Konflikt, wenn gilt (34) min( ta) max( te). Operationen werden bei Eingang in eine Warteschlange eingereiht. Die Position in der Warteschlange wird durch den Zeitpunkt t e bestimmt, nicht durch den Empfangszeitpunkt. Sortiert wird dergestalt, dass die Operation mit dem kleinsten t e zuerst ausgeführt wird. Hierdurch wird die Konfliktwahrscheinlichkeit reduziert. Nachdem die Operation ausgeführt wurde, wird t a auf den Zeitpunkt gesetzt, zu dem die Operation erstmalig ausgeführt wurde. Attribut Beschreibung localid ID des lokalen Objektes tombstone Zeitpunkt der Löschung lastoperation Letzte Datenbankoperation{Insert, Update, Delete} lasttransactionid Zuletzt ausgeführte Operation transactionids Liste aller ausgeführter Operationen lockedbytransactions Liste aller dieses Objekt blockierender Operationen locked Wahr, wenn das Objekt gesperrt ist creationdate Erstellungsdatum lastupdate Zeitpunkt der letzten Änderung ( t a ) Tabelle 6.4: Metadaten eines lokalen Objektes Eine automatisierte Konfliktbehebung erfolgt lediglich in dem Spezialfall, wenn das Ergebnis einer Operation dem gegenwärtigen Zustand des Objektes entspricht. In allen anderen Fällen müssen Konflikte manuell behoben werden. Die hierfür implementierte Benutzungsschnittstelle ist in Abschnitt beschrieben. 114

115 6.2 Implementierung des Integrationsframeworks Kennzahlerfassung Um das Laufzeitverhalten der Implementierung evaluieren zu können, werden Kennzahlen erfasst. Implementiert wurden diese mittels AspectJ als Aspekte zu relevanten Funktionsaufrufen und werden somit direkt vor und nach der Ausführung des Funktionsrumpfes ausgeführt. Dazu registriert sich der KpiLoggingAspectListener beim LoggingAspect. Es werden Operationskennzahlen (Tabelle 6.5) und Methodenkennzahlen erhoben. Erhobene Größe Wann (Einheit) Verarbeitungsbeginn Beim Empfang der Operation bzw. Erkennen einer Änderung wird das der Operation Datum für den Verarbeitungsbeginn gesetzt. (Datum) Erhoben bei den Methodenaufrufen: doreceivesoapmessageafter dobegintransactionafter Verarbeitungsende der Operation (Datum) Anzahl der betroffenen Objekte Am Ende der Verarbeitung einer Operation wird das Datum des Verarbeitungsendes gesetzt. Erhoben bei den Methodenaufrufen: doexecutepropagationafter doendtransactionafter Die Anzahl der betroffenen Objekte wird am Ende der Verarbeitung einer Operation erfasst. Dazu werden die in der Propagierung enthaltenen GlobalIds gezählt. Größe der SOAP- Nachricht (Byte) Größe des Updateskripts (Byte) Größe der Metadaten (Byte) Erhoben bei den Methodenaufrufen: doexecutepropagationafter doendtransactionafter Die Größe der SOAP-Nachricht wird beim Empfang bzw. Senden einer SOAP-Nachricht ermittelt. Erhoben bei den Methodenaufrufen: doreceivesoapmessageafter dosendsoapmessageafter Beim Erstellen oder Anwenden eines Updateskripts wird die Größe des Skripts erfasst. Erhoben bei den Methodenaufrufen: docreateupdatescriptatpropagationafter doupdateexporteddataatreceptionbefore Die Größe der Metadaten wird, wie die Größe der SOAP-Nachricht, nach dem Empfang bzw. Senden einer SOAP-Nachricht ermittelt. Es wird die Größe des serialisierten MetaData-Objekts, nicht die des Java- Objekts, erhoben. Erhoben bei den Methodenaufrufen: doreceivesoapmessageafter dosendsoapmessageafter Tabelle 6.5: Erfasste Operationskennzahlen 115

116 6 Realisierung der Integrationsarchitektur Viana Zur Erfassung von Methodenkennzahlen (Tabelle 6.6) wird durch den Aspekt vor der Ausführung des Methodenrumpfes ein Timer gestartet und nach der Ausführung gestoppt. Die berücksichtigten Methoden sind in Anhang H aufgeführt. Erhobene Größe (Einheit) Klassenbezeichnung der Klasse, in der die Methode enthalten ist Methodenbezeichnung Ausführungsbeginn der Methode (Datum) Laufzeit der Methode (ms) Tabelle 6.6: Erfasste Methodenkennzahlen 6.3 Implementierung von Adaptern Um zu zeigen, dass der in VIANA verfolgte Ansatz umsetzbar ist, wurde vier Adapter erstellt: ein generischer Adapter zur Integration von Datenbanken, sowie drei Adapter zur Integration spezifischer heterogener Informationssysteme (Droste et al., 2011). Für jeden Adapter sind jeweils vier Klassen zu implementieren, welche im Konnektor als abstrakte Klassen enthalten sind: LocalDataService: Diese Klasse implementiert eine Darstellung des lokalen Schemas und die Transformationen in dieses Schema aus dem nativen Schema. Sie implementiert weiterhin die Transformation aus dem nativen Datenmodell nach XML. NativeDataService: Diese Klasse implementiert Transformationen in das native Schema. NativeDataAccessService: Diese Klasse implementiert den Zugriff auf das integrierte Informationssystem. NativeDataObservationService: Diese Klasse implementiert einen Beobachter des integrierten Informationssystems, um Änderungen im Datenbestand erkennen zu können. Der Adapter für relationale Datenbanken wurde angepasst für die Integration von Oracle 10g Datenbanksystemen. Er wurde entwickelt, um einfach kontrollierbare homogene Testumgebungen aufbauen zu können. Weiterhin erlaubt er eine generische Integration von Informationssystemen über ihre Datenbank als Schnittstelle. Datenzugriff Der NativeDataService implementiert den Zugriff auf die Datenbank durch Hibernate, einem Objekt Relationaler Mapper (ORM), welcher relationale Daten in Java-Objekte übersetzt. Der LocalDataService realisiert den Übergang zu XML durch das Framework JAX-B. Die Implementierung der Schemata ist in Tabelle 6.7 zusammengefasst. 116

117 6.4 Benutzungsschnittstellen Ebene Technologie Komponente Lokales Schema Abbildung der Java-Klassen auf XML über Adapter JAX-B Natives Schema Abbildung der Datenbankrelationen auf Java Klassen über Hibernate Datenbank Backend RDBMS Informationssystem Tabelle 6.7: Realisierung der schematischen Ebenen im Adapter für relationale Datenbanksysteme Beobachter Beobachtet werden relationale Datenbanken, indem SQL/Trigger die Operationen in separaten Relationen protokollieren. Für jede Relation der Datenbank besteht eine eigene Relation zur Protokollierung, welche jeweils den Stand vor und nach der Operation, sowie den Zeitpunkt der Operation enthält. Ein Adapter erkennt eine Operation, indem diese Relationen periodisch auf neue Einträge hin abgefragt werden. Als Intervalllänge wurde 1 Sekunde gewählt. Für die Integration eines weiteren Schemas (d.h. einer weiteren Datenbank) sind folgende Schritte notwendig: Für die zu integrierenden Relationen müssen Java Klassen und das OR-Mapping für Hibernate implementiert werden. Für die integrierten Relationen müssen SQL/Trigger zur Beobachtung implementiert werden. Ggf. müssen Transformationen aus dem konzeptionellen in exportierte Schemata erstellt werden. Alternativ wurde evaluiert, ob Oracle 10g Datenbanken über Fine Grained Auditing (FGA) und Flashback Queries überwacht werden können. Diese Technologien versprechen eine einfachere Implementierung, da das Datenbanksystem hierbei erlaubt, in der Vergangenheit liegende Zustände abzufragen. Diese Technologien haben sich nicht bewährt, da die Auswirkungen einzelner Operationen nicht getrennt ausgewertet werden können, denn vergangene Zustände können nur auf ca. 10 Sekunden genau adressiert werden. 6.4 Benutzungsschnittstellen VIANA unterstützt Benutzerinteraktion für administrative und operative Zwecke. Zur Administration steht eine Eclipse-Anwendung zur Verfügung, welche lokal installiert werden muss. Beim Entwurf der operativen Benutzungsschnittstelle stand im Vordergrund, dass diese in die Oberfläche des integrierten Informationssystems integriert werden kann. Diese Benutzungsschnittstelle ist daher Web-basiert. Beide Benutzungsschnittstellen kommunizieren mit Konnektoren über Web Service-Schnittstellen. Dies ermöglicht alternative Benutzungsschnittstellen für Benutzer mit abweichenden Anforderungsprofilen oder nicht vorhergesehene Integrationsszenarien. 117

118 6 Realisierung der Integrationsarchitektur Viana Administrative Benutzungsschnittstelle Die administrative Oberfläche wurde in Eclipse (Eclipse Foundation, 2010a) unter Verwendung des Graphical Modeling Frameworks (GMF) (Eclipse Foundation, 2010b) entwickelt. GMF ist ein Framework zur Erstellung Eclipse-basierter Editoren für die graphische Modellierung. Es integriert die Technologien Eclipse Modeling Framework (EMF) (Eclipse Foundation, 2011a) und Graphical Editing Framework (GEF) (Eclipse Foundation, 2011b). Graphische Editoren werden in GMF entwickelt, indem ein (graphisches) Metamodell und Java-Code für weitergehende Funktionalitäten erstellt wird. Die administrative Oberfläche realisiert zwei graphische Modelle: die Schemaverwaltung zur organisatorischen Kontrolle von Stammdatenobjekten, in der mehrere Datenschemata erstellt werden und auf unterschiedliche Konnektoren verteilt werden können. Dadurch können Schemata wiederverwendet werden. Konfigurierte Schemata stehen Konnektoren als lokale und exportierte Sichten zur Verfügung. Das zweite graphische Modell ist in Abbildung 6.3 dargestellt und realisiert die Topologiekonfiguration eines Integrationsnetzwerkes. Konnektoren werden hier als eigenständige Peers modelliert. Zu jedem Konnektor gehört genau ein konzeptionelles Schema, welches im Modell nicht enthalten, jedoch mit ihm verknüpft ist, und direkt aufgerufen werden kann. Das konzeptionelle Schema wird dann in der Schemaverwaltung dargestellt. Das Modell enthält zu jedem Konnektor n exportierte Schemata, welche gleichsam direkt aufgerufen werden können. Diese sind mit Konnektoren durch gerichtete Verbindungen verbunden. Exportierte Schemata unterschiedlicher Konnektoren können weiterhin durch gerichtete Verbindungen verknüpft werden. Gerichtete Verbindungen repräsentieren Transformationen. Zu jeder Abbildung 6.3: Eclipse Editor zur Topologiekonfiguration 118