Entwicklung und Evaluation eines Konzepts für die Umsetzung von EDI-Geschäftsprozessen in serviceorientierten Architekturen

Größe: px
Ab Seite anzeigen:

Download "Entwicklung und Evaluation eines Konzepts für die Umsetzung von EDI-Geschäftsprozessen in serviceorientierten Architekturen"

Transkript

1 Gottfried Wilhelm Leibniz Universität Hannover Fakultät für Elektrotechnik und Informatik Institut für Praktische Informatik Fachgebiet Software Engineering Entwicklung und Evaluation eines Konzepts für die Umsetzung von EDI-Geschäftsprozessen in serviceorientierten Architekturen Masterarbeit im Studiengang Informatik von Bassim Aziz Safi Prüfer: Prof. Dr. Kurt Schneider Zweitprüfer: Prof. Dr. Wolfgang Nejdl Betreuer: M. Sc. Kai Stapel Hannover,

2 Zusammenfassung Die Nachteile von Electronic Data Interchange (EDI) hinsichtlich mangelnder Flexibilität und hoher Kosten lassen sich auf die Inflexibilität bei der Nutzung der durch EDI-Standards vorgegebenen EDI-Dokumente zurückführen. Ein Mittel zur Steigerung der Flexibilität ist der Einsatz einer effizienten Konvertierungslösung, die als Abstraktionsebene verschiedene EDI-Standards ineinander übersetzen kann und so die Abhängigkeiten zwischen Unternehmen mindert. Bei Änderungen in den auszutauschenden Informationen und anderen Änderungen kann dennoch schnell hoher Aufwand entstehen, weil die Abbildung der Information auf passende EDI-Dokumente überarbeitet werden muss, was üblicherweise in mühsamer manueller Arbeit erfolgt und maßgeblich für die Inflexibilität von EDI verantwortlich ist. Die vorliegende Arbeit untersucht die Anwendungsmöglichkeiten von serviceorientierten Architekturen im Hinblick auf eine Steigerung der Flexibilität von EDI durch eine serviceorientierte Konvertierungslösung, in der die Konfiguration eines Konvertierungsprozesses besonders schnell und übersichtlich erfolgen kann. Die Ergebnisse werden in einem Konzept zur serviceorientierten Umsetzung der EDI-Geschäftsprozesse des Unternehmens NEO Business Partners GmbH angewandt. ii

3 Danksagung Mein Dank gilt meinen Prüfern Herrn Prof. Dr. Schneider und Herrn Prof. Dr. Nejdl, nachträglich Herrn Dr.-Ing. Daniel Lübke und den Kollegen von NEO für die gute Zusammenarbeit. Besonders bedanken möchte ich mich bei meinem Betreuer Herrn M. Sc. Kai Stapel für die vorbildliche, ebenso kompetente wie herzliche Betreuung. Mein ganz besonderer Dank gilt meiner Freundin Susanne, meiner Familie und meinen Freunden und nicht zuletzt meinen Bandkollegen von DU, die allesamt oft auf mich verzichten mussten und mich dennoch jederzeit unterstützt haben. iii

4 Inhaltsverzeichnis Abbildungsverzeichnis Tabellenverzeichnis Abkürzungsverzeichnis vi vii viii 1 Einleitung Problemstellung Motivation und Zielsetzung Gliederung der Arbeit Gegenüberstellung von EDI und SOA Electronic Data Interchange Definition und Abgrenzung Funktionsweise EDI-Standards und Übertragungsverfahren Entwicklung der EDI-Standards und Übertragungsverfahren Besondere Anforderungen bei der Übertragung Vorteile Nachteile Serviceorientierte Architekturen Definition Webservices als Implementierungsform Vor- und Nachteile Verhältnis zwischen EDI und SOA Differenzierungsaspekte Flexibilität Sicherheit Heterogenität und Kompatibilität Skalierbarkeit Nachteile von EDI, die sich durch SOA lösen lassen Szenarien Eine serviceorientierte Konvertierungslösung Konzept zur Umsetzung von EDI in SOA Vorstellung des Unternehmens Methodik und Struktur des Konzepts Messziele Fragen Metriken iv

5 Inhaltsverzeichnis 3.3 Ist-Aufnahme Systembeschreibung Konvertierungsprozess Konfiguration Ist-Kritik Schwierige Konfiguration des Konverters Nicht ausreichende Nachvollziehbarkeit Soll-Konzeption Lösungsgenerierung Lösungsansätze Lösungsumsetzung Soll-Konzeption Evaluation Kosten-Nutzen-Betrachtung Evaluation Zusammenfassung und Fazit Ausblick A Interviews 62 A.1 Zusammenfassungen der Interviews A.1.1 Zusammenfassung Interview A.1.2 Zusammenfassung Interview A.1.3 Zusammenfassung Interview A.1.4 Zusammenfassung Interview Literaturverzeichnis 65 v

6 Abbildungsverzeichnis 2.1 EDI Kommunikationsprozess Ebenen von EDI Elemente einer SOA ECON Prozess erste Ebene ECON Prozess Schritt Datei abholen ECON Prozess Schritt Datei verarbeiten ECON Prozess Schritt In XML konvertieren ECON Prozess Schritt Konvertierung vorbereiten ECON Prozess Schritt In internes Format konvertieren ECON Prozess Schritt In Zielformat konvertieren ECON Prozess Schritt Rechnungsliste erstellen ECON Prozess Schritt Datei versenden ECON Konfigurationsebenen ECON Prozessstruktur vi

7 Tabellenverzeichnis 2.1 EDIINT-Standards EDIFACT-Subsets (Auswahl) vii

8 Abkürzungsverzeichnis AS1 EDIINT Applicability Statement 1 AS2 EDIINT Applicability Statement 2 AS3 EDIINT Applicability Statement 3 B2B Business to Business BPEL Business Process Execution Language BPMN Business Process Modelling Notation CORBA Common Object Request Broker Architecture CSV Comma Separated Value EAN EAN-Artikelnummer EANCOM EDIFACT EAN+Communication Subset ebxml Electronic Business using extensible Markup Language EDI Electronic Data Interchange EDIA Electronic Data Interchange Association EDIFACT Electronic Data Interchange For Administration, Commerce and Transport EDIINT Electronic Data Interchange Internet Integration EJB Enterprise Java Beans FTP File Transfer Protocol GQM Goal-Question-Metric GTDI Guidelines for Trade Data Interchange GUI Graphical User Interface HTTP Hypertext Transfer Protocol IETF Internet Engineering Task Force ILN Internationale Lokationsnummer IT Informationstechnik JVM Java Virtual Machine MDN Message Disposition Notification OASIS Organization for the Advancement of Structured Information Standards PDF Portable Document Format PGP Pretty Good Privacy viii

9 Abkürzungsverzeichnis RMI Remote Method Invocation S/MIME Secure Multipurpose Internet Mail Extensions SCM Supply Chain Management SMTP Simple Mail Transfer Protocol SOA serviceorientierte Architektur TDCC Transportation Data Coordinating Committee TRADACOMS Trading Data Communications Standard UDDI Universal Description, Discovery and Integration UN/CEFACT United Nations Centre for Trade Facilitation and Electronic Business UN/ECE United Nations Economic Commission for Europe UN/JEDI United Nations Joint Electronic Data Interchange VAN Value-Added Network W3C World Wide Web Consortium WSDL Web Service Description Language X.400 X.400 Message Handling System X12 ANSI ASC X12 XML extensible Markup Language XSL-FO Extensible Stylesheet Language Formatting Objects XSLT Extensible Stylesheet Language Transformation ix

10 1 Einleitung EDI bezeichnet elektronische Verfahren zur Übertragung strukturierter Nachrichten zwischen Geschäftspartnern und ist nun seit mehreren Jahrzehnten als wichtige Säule des B2B- Bereichs etabliert. EDI gilt als Vorreiter des modernen Supply Chain Management (SCM) und wird heute äußerst erfolgreich von großen Unternehmen eingesetzt: 85% bis 90% aller B2B-Transaktionen werden über EDI abgewickelt [47]. Auffällig ist dabei die Tatsache, dass die Wirtschaftlichkeit eines Einsatzes von EDI von der Größe des Unternehmens abhängig zu sein scheint [24]. Untersuchungen haben ergeben, dass sich der Einsatz von EDI insbesondere dann bezahlt macht, wenn ein Unternehmen viele stabile Geschäftsbeziehungen besitzt und eine genügend große Anzahl von Transaktionen ausführt [39, 40]. 1.1 Problemstellung Durch die Entwicklungen der letzten Jahre auf dem Gebiet der Integration von unternehmensübergreifenden Geschäftsprozessen fallen immer mehr Nachteile von EDI auf. Dazu zählen geringe Flexibilität, hohe Kosten und ein inzwischen überholter Ansatz zur Prozessintegration [5, 26, 41]. Die Ursache für nahezu alle dieser Nachteile ist das Prinzip von EDI und dessen technische Umsetzung, was in engen Kopplungen zwischen den Anwendungssystemen der Unternehmen resultiert. Einrichtung, Betrieb und insbesondere Pflege von EDI-Anbindungen sind dadurch aufwändig und teuer, da sich Änderungen auf geschäftlicher Ebene, z. B. der Wechsel eines Geschäftspartners oder Änderungen im Informationsaustausch auf viele Ebenen der technischen Umsetzung auswirken [41]. Gerade für Unternehmen mit häufig wechselnden Geschäftspartnern, häufig wechselnden Transaktionsausprägungen oder geringem Transaktionsaufkommen lohnt sich die Investition in eine EDI-Infrastruktur daher in der Regel nicht. Im Zuge der fortschreitenden Globalisierung und der steigenden Bedeutung des E-Business als erfolgskritischer Faktor wird es allerdings immer wahrscheinlicher, dass auch Unternehmen über EDI nachdenken müssen, die dies bisher aus den genannten Gründen nicht getan haben. Gleichzeitig steigt der Bedarf nach organisatorischer Flexibilität, um die immer schneller werdenden Veränderungen eines globalen Marktes nachvollziehen zu können. Wie lassen sich diese Faktoren vereinen? 1.2 Motivation und Zielsetzung Serviceorientierte Architekturen (SOA) erfreuen sich zur Zeit großer Aufmerksamkeit. Aufbauend u. a. auf den Prinzipien lose Kopplung, hohe Standardisierung und Wiederverwendung werden Geschäftsprozesse in grobgranulare Einzelschritte zerlegt und diese mit Hilfe von Services umgesetzt. So können Geschäftsprozesse aus Services komponiert und im Idealfall 1

11 1 Einleitung flexibel umgestaltet werden, um sich veränderten Anforderungen anzupassen. Neue Geschäftsprozesse können dabei bestehende Services potentiell wiederverwenden und so nicht nur kostengünstiger, sondern auch schneller umgesetzt werden. Dies hat letztendlich eine erhöhte organisatorische Agilität und eine bessere Abstimmung zwischen Geschäftsprozess und IT-Unterstützung zur Folge. Im Hinblick auf die Verheißungen von SOA stellt sich nun die Frage, inwieweit sich EDI in serviceorientierten Architekturen umsetzen lässt, welche besonderen Anforderungen EDI stellt, welche Kosten und Nutzen dabei entstehen und ob es gelingt, durch die Nutzung einer serviceorientierten Architektur die Nachteile von EDI auszugleichen. Um diese Frage zu beantworten, werden die Prinzipien, Funktionsweisen und Anforderungen von EDI und SOA untersucht, die Ursachen der genannten EDI-Nachteile identifiziert und auf Lösungsmöglichkeiten durch die Anwendung eines serviceorientierten Ansatzes überprüft. Diese theoretischen Überlegungen sollen dabei am konkreten Beispiel des Unternehmens NEO Business Partners GmbH (NEO) nachvollzogen werden. NEO ist unter anderem Dienstleister im EDI-Bereich. Angeboten werden EDI-Anbindungen mit Schwerpunkt auf Konvertierungen von beliebig strukturierten Geschäftsdokumenten wie Bestellungen oder Rechnungen in einschlägige EDI-Nachrichtenformate. Diese Anbindungen werden vor allem zwischen Großhandelsunternehmen und kleineren Zulieferern, für die keine eigene EDI- Infrastruktur lohnt, eingesetzt und über ein bei NEO entwickeltes System namens ECON abgewickelt. Durch kundenseitige Änderungen in Inhalt oder Struktur der übermittelten Nachrichten ergibt sich in der Regel die Notwendigkeit für Änderungen im Konvertierungsprozess. In diesem Fall muss der betreffende Konvertierungsprozess rekonfiguriert werden, wodurch hohe Betriebskosten entstehen: Auf Fehlerkorrekturen und Konfigurationen von Konvertierungsprozessen entfallen 60% der Arbeitszeit des zuständigen Mitarbeiters (s. Anhang A.1.3). NEO scheint in diesem Zusammenhang ein gutes Beispiel für die sich durch EDI ergebenden Probleme zu sein. Als Anbieter von EDI-Anbindungen ergeben sich hier sehr häufig neue Anforderungen durch Anbindung neuer Kunden oder Änderungswünsche bei bestehenden Kunden. Gleichzeitig bleibt die Festlegung auf EDI als technologische Basis für die Kommunikation bestehen. Die Probleme, die sich bei der Nutzung von EDI ergeben, insbesondere in Fragen der Flexibilität, treten hier in konzentrierter Form auf. Ziel dieser Arbeit ist daher die Erstellung und Evaluation eines Konzepts zur Umsetzung von EDI-Geschäftsprozessen in einer serviceorientierten Architektur am Beispiel des ECON- Systems. Das Konzept soll beschreiben, welche Schritte zur Umsetzung notwendig und was die jeweiligen Kosten und Nutzen sind, so dass es als Entscheidungsgrundlage für NEO dienen kann. 1.3 Gliederung der Arbeit Zunächst werden die Technologien EDI und SOA vorgestellt (Kapitel 2). Dabei werden Prinzipien, die Funktionsweise und daraus entstehende Vor- und Nachteile dargelegt (Abschnit- 2

12 1 Einleitung te 2.1 und 2.2). In einer Gegenüberstellung wird das Verhältnis zwischen EDI und SOA erforscht (Abschnitt 2.3), bevor Ansätze zur Lösung der EDI-Nachteile durch den Einsatz einer SOA entwickelt werden (Abschnitt 2.4). Aufbauend auf den Erkenntnissen der Gegenüberstellung wird dann ein Konzept zur Umsetzung von EDI-Geschäftsprozessen in einer serviceorientierten Architektur vorgestellt, in welchem unter Anwendung des Goal-Question-Metric (GQM)-Ansatzes konkrete Anwendungsmöglichkeiten der Lösungsansätze am Beispiel des Unternehmens NEO erarbeitet werden (Kapitel 3). Dabei werden in einer Ist-Aufnahme das ECON-System und die darin ablaufenden Konvertierungsprozesse vorgestellt (Abschnitt 3.3), einer Kritik unterworfen (Abschnitt 3.4) und darauf aufbauend Lösungen konzipiert und evaluiert (Abschnitte 3.5 und 3.6). Die Arbeit schließt mit einer Zusammenfassung und einem Ausblick auf eventuelle zukünftige Erweiterungen des Konzepts (Kapitel 4). 3

13 2 Gegenüberstellung von EDI und SOA In diesem Kapitel werden die Technologien Electronic Data Interchange und serviceorientierte Architekturen vorgestellt und die Beziehung zwischen den Technologien untersucht. 2.1 Electronic Data Interchange In diesem Abschnitt wird der Begriff Electronic Data Interchange (EDI), dt. elektronischer Datenaustausch, definiert und ein Überblick über EDI und die Entwicklung von EDI gegeben. Danach werden besondere Anforderungen und die wichtigsten Vor- und Nachteile von EDI aus heutiger Sicht behandelt Definition und Abgrenzung Es gibt keine allseits anerkannte Definition des Begriffs EDI, auch Definitionen diverser Standardisierungsgremien sind nicht allgemein akzeptiert. Die Gründe dafür liegen in unterschiedlichen Auffassungen bezüglich der Abgrenzung zu verwandten Technologien. Eine in der Fachliteratur verbreitete Unterscheidung verwendet den Begriff traditionelles oder auch klassisches EDI für Ausprägungen, die auf älteren, aber noch immer am weitesten verbreiteten Übertragungsverfahren und Dokumentformaten aufsetzen [1, 19, 44]. Im Gegensatz dazu werden neuere, XML-basierte und Internetprotokolle nutzende EDI- Ausprägungen als nicht-klassisch bezeichnet. Selbst hier können keine klaren Grenzen gezogen werden, was allerdings für die Zwecke dieser Arbeit unerheblich ist. Es wurden zwei Definitionen ausgewählt, die zusammen alle wesentlichen Aspekte von EDI beinhalten und auch auf nicht-klassische EDI-Ausprägungen anwendbar sind. 1 Definition (Electronic Data Interchange I) Unter Electronic Data Interchange versteht man den elektronischen, unternehmensübergreifenden Austausch strukturierter Geschäftsdokumente [14]. Definition (Electronic Data Interchange II) EDI ist die automatisierte Übermittlung strukturierter Daten mittels festgelegter Nachrichtenstandards von einer Computeranwendung in die andere, und zwar mit einem Minimum an manuellen Eingriffen [11]. Fasst man beide Definitionen zusammen, so erhält man die folgende, im weiteren verwendete Definition: 1 Eine Reihe weiterer Definitionen, welche sich allerdings bei genauerer Betrachtung nur in Details unterscheiden, finden sich in [7, 24, 39, 45]. 4

14 2 Gegenüberstellung von EDI und SOA Definition (Electronic Data Interchange) EDI beschreibt zusammenfassend alle elektronischen Verfahren zur automatisierten Übertragung von Geschäftsdokumenten zwischen den Anwendungssystemen unterschiedlicher Organisationen mittels standardisierter Nachrichten. Nachfolgend werden die einzelnen Bestandteile der Definition näher erläutert. elektronische Übertragung: Die Übertragung geschieht auf elektronischem Wege über eine Datenverbindung zwischen den Anwendungssystemen. automatisiert: Die Notwendigkeit für manuelle Eingriffe wird im Idealfall vollständig eliminiert. Geschäftsdokument: Als Geschäftsdokument wird jegliches Dokument bezeichnet, das zum Zwecke der Abwicklung eines Geschäfts zwischen Geschäftspartnern ausgetauscht wird. Als Beispiele sind zu nennen: Angebotsanforderung, Bestellung, Lieferbestätigung, Rechnung, etc. zwischen Organisationen: Die Übertragung geschieht immer zwischen zwei unterschiedlichen, geschäftlich miteinander verkehrenden Organisationen. standardisierte Nachrichten: Die ausgetauschten Nachrichten halten sich hinsichtlich ihres Aufbaus und ihres Inhalts an durch Standards vorgegebene Regeln. Abgrenzung Das Hauptaugenmerk bei der Betrachtung von EDI liegt weniger auf den unzähligen branchenspezifischen oder privatwirtschaftlich entwickelten Formen von EDI, sondern vornehmlich auf dem Bereich des klassischen EDI und den in Europa verbreiteten zugehörigen EDI-Standards wie EDIFACT Funktionsweise Vor der Betrachtung der Funktionsweise im Betrieb werden die notwendigen Schritte zur Vorbereitung und Einrichtung einer EDI-Anbindung aufgezählt. Vorbereitungsphase Geschäftspartner, die EDI verwenden möchten, müssen festlegen, welche geschäftlichen Informationen in Form welcher EDI-Dokumente aus welchem EDI-Standard mit welchen unternehmensspezifischen oder anbindungspezifischen Sondervereinbarungen an welchen Stellen oder zu welchen Zeitpunkten von welchen Geschäftsprozessen 5

15 2 Gegenüberstellung von EDI und SOA über welchen Kommunikationskanal ausgetauscht und welche zusätzliche Maßnahmen zur Sicherung und Validierung des Austauschs getroffen, welche Aktionen im Fehlerfall ergriffen und wie dabei die Zuständigkeiten verteilt werden sollen. Die betroffenen Prozesse müssen dabei aufeinander abgestimmt und dazu üblicherweise geändert werden. Falls Unternehmen A zum Beispiel Bestellungen an Unternehmen B senden möchte und eine Bestellungsbestätigung oder Rechnung innerhalb von 24 Stunden erwartet, Unternehmen B eingegangene Bestellungen aber nur montags verarbeitet und Rechnungen nur freitags versendet, muss mindestens einer der beiden Geschäftsprozesse geändert werden. Einrichtung Sind alle Festlegungen erfolgt, muss die notwendige Infrastruktur eingerichtet werden. Die Anwendungssysteme der beiden Unternehmen müssen entweder um Komponenten zur Erzeugung, evtl. Konvertierung und zum Versand der EDI-Nachrichten erweitert werden, oder es müssen entsprechende Subsysteme angebunden werden. Weiterhin muss entweder ein Kommunikationsdienstleister, z.b. ein Value-Added Network (VAN) mit der Bereitstellung eines Kommunikationskanals beauftragt oder eine eigene Verbindung eingerichtet werden. Vor Inbetriebnahme müssen ausgiebige Testläufe und schließlich die Abnahme erfolgen. Betrieb Im Betrieb können die folgenden Teilschritte im Kommunikationsprozess unterschieden werden (s. Abbildung 2.1): 1. Das Anwendungssystem des Senders erzeugt das anwendungsspezifische Geschäftsdokument, dass die entsprechenden Informationen enthält. 2. Das EDI-Subsystem erzeugt daraus eine entsprechende EDI-Nachricht in einem EDI- Format. 3. Optional wird die EDI-Nachricht von einem Konverter in ein anderes Format konvertiert, bevor sie an das Kommunikationssystem weitergereicht wird. 4. Das Kommunikationssystem sendet die EDI-Nachricht an das empfangende Unternehmen. Der Versand erfolgt direkt an das Unternehmen oder an eine zwischenspeichernde Mailbox. Je nach Kommunikationskanal können hier zusätzliche Schritte wie Ver-/Entschlüsselung, Zusammenfassung, Datensicherung, Konvertierung und ähnliches stattfinden. 5. Das Kommunikationssystem des empfangenden Unternehmens erhält die EDI-Nachricht oder ruft sie von der Mailbox ab, optional wird hier die EDI-Nachricht überprüft 6

16 2 Gegenüberstellung von EDI und SOA Abbildung 2.1: EDI Kommunikationsprozess und/oder eine Empfangsbestätigung an den Sender zurückgeschickt. 6. Optional wird die EDI-Nachricht von einem Konverter in ein anderes Format konvertiert, bevor sie an das EDI-Subsystem weitergereicht wird. 7. Das EDI-Subsystem erzeugt daraus ein entsprechendes, anwendungsspezifisches Geschäftsdokument. 8. Das Geschäftsdokument wird schließlich vom Anwendungssystem des Empfängers verarbeitet, womit der Prozess abgeschlossen ist. Die Unterteilung der einzelnen Komponenten kann im Einzelfall sehr verschieden sein. Oftmals sind die Komponenten EDI-Subsystem, Konverter und Kommunikationssystem in einer integrierten EDI-Lösung zusammengefasst. Mit dem Empfang des Dokuments ist der Prozess aus EDI-Sicht abgeschlossen. Die Versendung eines antwortenden Geschäftsdokuments, beispielsweise einer Bestellungsbestätigung als Antwort auf eine Bestellung, wäre ein davon unabhängiger Prozess EDI-Standards und Übertragungsverfahren EDI-Standards beschreiben Form und Inhalt von EDI-Dokumenten und den Nachrichten, mit denen Dokumente übertragen werden. Nach Dorloff [15] lassen sich elektronische Standards und damit auch EDI-Standards in vier Ebenen unterteilen: Prozesse, Dokumente, Vokabular und Datentypen. Nimmt man als weitere Ebene die Kommunikationsebene hinzu, die unter der Ebene der Datentypen angeordnet ist und auf der die Übertragungsverfahren definiert sind, korrespondiert dieses Ebenenmodell mit dem Modell, das durch Medjahed et al. [30] zur Beschreibung der Ebenen der Interaktion zwischen Unternehmen angeführt wird. Dieses Modell unterscheidet drei Ebenen: die Geschäftsprozessebene, die Inhaltsebene und die Kommunikationsebene. Die von Dorloff aufgeführten Ebenen bis auf die Prozessebene sind dabei als Teilebenen der Inhaltsebene nach Medjahed et al. anzusehen. Abbildung 2.2 illustriert das so kombinierte Ebenenmodell: 7

17 2 Gegenüberstellung von EDI und SOA Abbildung 2.2: Geltungsbereich und Ebenen von EDI Prozesse, im EDI-Sinne also definierte Abfolgen bei der Übertragung von Dokumenten, sind in klassischen EDI-Standards üblicherweise nicht definiert, dasselbe gilt für Übertragungsverfahren. Eine sinnvolle Dokumentfolge ergibt sich aber aus der jeweiligen Funktion der einzelnen Dokumente. So folgt auf eine Bestellung sinnvollerweise eine Bestellbestätigung. Dies ist jedoch nicht vorgeschrieben und Geschäftspartner können bzw. müssen sich auf einen gemeinsamen Prozessablauf einigen. Der Zusammenhang der weiteren Ebenen ist wie folgt: Ein EDI-Dokument besteht aus einer Menge von inhaltlich zusammengehörenden Datenelementen, die je nach Funktion des darzustellenden Geschäftsdokuments dessen Inhalt und Struktur geeignet abbilden. Die Menge aller verfügbaren Datenelemente wird Vokabular genannt und kann in dokumentspezifisches und allgemeines Vokabular unterschieden werden: Das Datenelement Erstellungsdatum und -uhrzeit beispielsweise ist sinnvoller Bestandteil jedes Dokuments, während das Datenelement Rechnungsbetrag nur innerhalb einer Rechnung einen Sinn ergibt. Ein Datenelement kann sich entweder aus mehreren Datentypen zusammensetzen oder aus einem einzelnen Datentyp bestehen. Ein Datentyp schließlich ist atomar und beinhaltet die eigentlichen Nutzdaten. Alle EDI-Standards definieren eine Reihe von Dokumenten in der Regel für jeden Typ von Geschäftsdokument ein entsprechendes EDI-Dokument. Ebenso definieren alle EDI- Standards allgemeines und dokumentspezifisches Vokabular, eine Menge von Datentypen und mindestens einen Zeichensatz. Diese Definitionen sind bei den einzelnen Standards fast immer unterschiedlich, weshalb verschiedene EDI-Standards üblicherweise auf einer oder mehrerer Ebenen zueinander inkompatibel sind Entwicklung der EDI-Standards und Übertragungsverfahren Heute existieren eine Vielzahl von verschiedenen, untereinander größtenteils inkompatiblen EDI-Standards. Die Ursachen dafür lassen sich an der Entwicklungsgeschichte von EDI nachvollziehen, welche hier einmal aus dem Blickwinkel der EDI-Standards und einmal aus 8

18 2 Gegenüberstellung von EDI und SOA dem Blickwinkel der Übertragungsverfahren betrachtet werden soll. Entwicklung der EDI-Standards Die Anfänge von EDI werden auf das Jahr 1960 datiert. Zu dieser Zeit nutzten bereits viele Unternehmen in den USA Computersysteme für die automatisierte Verarbeitung bestimmter Vorgänge wie z. B. der Bestellungsabwicklung. Die Performanz dieser Systeme wurde hauptsächlich limitiert durch die langsame Kommunikation mit Zulieferern und Kunden, welche üblicherweise über Post, Telefon und Telefax lief. Die aufkommende elektronische Kommunikation wurde als Lösung dieses Problems identifiziert [49]. Um 1968 existierten bereits viele Unternehmen, die eigenentwickelte Systemen mit proprietären Formaten für die elektronische Kommunikation mit ihren wichtigsten Zulieferern einsetzten. Das Problem eines fehlenden allgemein verwendbaren Formats wurde von einigen Unternehmen bereits zu dieser Zeit erkannt. Dies führte zur Gründung des TDCC aus einer Gruppe von Eisenbahngesellschaften und Transportunternehmen [43, 49] entsprang den zunächst brancheninternen Konsolidierungsanstrengungen der erste Standard des TDCC, welcher in der Transportbranche eingesetzt wurde. Branchenübergreifende Unternehmen jedoch standen weiterhin vor Problemen. Die Notwendigkeit branchenübergreifender Formatstandards wurde erkannt [7, 43] wurde aus dem inzwischen in EDIA umbenannten TDCC das ANSI ASC X12 (X12)- Commitee gegründet und mit der Entwicklung des X12 benannten Standards beauftragt [10] wurde X12 veröffentlicht [2]. Mit der Veröffentlichung von X12 stiegen Bekanntheitsgrad und Popularität von EDI stark an, weshalb der Beginn der 1980er Jahre in der Literatur vielfach als eigentlicher Entstehungszeitraum von EDI bezeichnet wird. In diesem Jahr wurde in Großbritannien der Standard TRADACOMS veröffentlicht, später von der UN/ECE weiterentwickelt und als GTDI bekannt [51]. Unternehmen, die transatlantische Handelsbeziehungen pflegten, hatten es nun mit zwei überwiegend inkompatiblen Dokumentformaten zu tun. Dies erhöhte die Dringlichkeit der Entwicklung internationaler Standards erhielt die UN/JEDI Working Group von der UN/ECE das Mandat zur Entwicklung des internationalen Standards EDIFACT [51] wurde die erste EDIFACT-Version (im EDIFACT-Jargon Verzeichnis genannt) veröffentlicht und verbreitete sich vor allem in Europa und Asien. EDIFACT zielte von vornherein auf eine möglichst breite Abdeckung aller Branchen und geriet daher sehr umfangreich und komplex. Dies führte dazu, dass sich nach und nach branchenspezifische Subsets von EDI- FACT entwickelten. Diese Subsets sind zwar weiterhin zu EDIFACT, aber untereinander nur noch bedingt kompatibel [46]. Das Fehlen von Standards bezüglich der die EDI-Kommunikation umschließenden und beeinflussenden Prozesse und die erfolgreiche Entwicklung des Internets führten zu Bestrebungen, das Konzept von EDI weiterzuentwickeln, weiter zu fassen und neuen Technologien anzupassen gründete sich das Non-Profit-Konsortium RosettaNet mit dem Ziel, die gemeinschaftliche Entwicklung und den zügigen Einsatz von offenen E-Business Prozessstandards voran- 9

19 2 Gegenüberstellung von EDI und SOA zutreiben [5]. In diesem Jahr wurde ebenfalls die erste Version von XML veröffentlicht. Ein Jahr später gründeten OASIS und UN/CEFACT die Initiative ebxml mit dem Ziel der Bereitstellung einer offenen, XML-basierten Infrastruktur für die weltweite Verwendung von E-Business-Informationen mit den Schwerpunkten Interoperabilität, Sicherheit und Konsistenz [50]. Die von ebxml und RosettaNet definierten Standards umfassen dabei nicht nur Dokumentformate, Nachrichtenformate und Definitionsbibliotheken für betriebswirtschaftliche und technische Begriffe, sondern standardisieren auch den gesamten Kommunikationsprozess. Sie sind heute zwei der gebräuchlichsten nicht-klassischen EDI-Ausprägungen. Die letztendliche Übertragung von EDI-Nachrichten geschieht durch Nutzung eines Übertragungsverfahrens. Hier entstand keine so ausgeprägte Diversifikation wie bei den EDI- Formaten. Heute werden nur wenige verschiedene Verfahren zur Versendung von EDI- Nachrichten verwendet. Auch hier soll die Entstehungsgeschichte die Gründe dafür erläutern. Übertragungsverfahren Die ersten EDI-Übertragungen ab 1960 liefen größtenteils per Modem-Einwahl über Telefonleitungen oder Standleitungen. Die Übertragungen erfolgten direkt über Punkt-zu-Punkt- Verbindungen: sendendes und empfangendes Anwendungssystem mussten dabei gleichzeitig verfügbar sein [49] führten die ersten brancheninternen Konsolidierungen zu von Unternehmen einer Handelsgruppe gemeinschaftlich betriebenen, privaten Rechnernetzen. Auch hier wurde noch überwiegend eine ungepufferte, direkte Übertragungsweise verwendet. Ab etwa 1970 entwickelten sich aus diesen gemeinschaftlich betriebenen EDI-Netzen die ersten Value-Added Networks (VANs): privatwirtschaftliche betriebene, allgemein zugängliche Netzwerke [51]. Im Gegensatz zu vorher waren diese Netzwerke bald untereinander verbunden, so dass es nun möglich wurde, EDI-Nachrichten zwischen Unternehmen aus verschiedenen Handelsgruppen zu übertragen. Mit steigender Größe und Nutzung wurden nun überwiegend über Mailboxen gepufferte Übertragungen angeboten. VANs boten später üblicherweise weitere, zusätzliche Dienste wie Sortierung von Nachrichten, Konvertierung zwischen verschiedenen Nachrichtenformaten, Datenverschlüsselung, Datensicherung, Zusammenfassung von Nachrichten ( batching ) und Überprüfungen auf syntaktische und z. T. sogar inhaltliche Fehler an. Die innerhalb eines VANs eingesetzten Mailboxen sind nicht unbedingt vergleichbar mit dem, was heute in der Regel unter einer Mailbox verstanden wird. Bei der Verwendung von der heute vorherrschenden -Technologie, bei welchem der Versand auf dem SMTP- Protokoll basiert, können üblicherweise keine Garantien bezüglich der Nachrichtenintegrität und -sicherheit gegeben werden. Es ist also nicht sichergestellt, dass eine abgesendete bei dem beabsichtigten Empfänger ankommt, eine empfangene tatsächlich von dem spezifizierten Absender abgeschickt wurde und sie unverändert ist 2. Daher setzte sich innerhalb von VANs eine Alternative zum heute bekannten -System durch: 2 Mittlerweile existieren Technologien wie S/MIME und PGP, die zumindest die Integrität der Nachricht und die Authentizität des Absenders sicherstellen können. 10

20 2 Gegenüberstellung von EDI und SOA das X.400 Message Handling System (X.400), welches bereits von Anfang an entsprechende Sicherheitsmechanismen beinhaltete. Nachteilig daran waren und sind noch heute die hohen Kosten, die durch den Einsatz von X.400 in den VANs entstehen: zusätzlich zu den monatlichen Mietkosten werden Gebühren pro übertragener Nachricht fällig, üblicherweise volumenbasiert. Dennoch sollten VANs lange Zeit das vorherrschende Übertragungsverfahren für klassisches EDI bleiben, da keine wirtschaftlichen Alternativen mit vergleichbaren Eigenschaften und vergleichbarer Sicherheit existierten. Mit dem Siegeszug des Internets entwickelte sich ein großer Bedarf an alternativen Übertragungsverfahren für die klassische Form von EDI. Diese sollten die Sicherheitsanforderungen von EDI erfüllen und das immer günstiger und schneller werdende Internet anstelle der teuren VANs nutzen können. Durchgesetzt hat sich dabei vor allem die Electronic Data Interchange Internet Integration (EDIINT) AS-Protokollfamilie, die ab 2002 von der EDI- INT Working Group des IETF veröffentlicht wurde. Sie beinhaltet bis jetzt drei Standards, die eine sichere Übertragung von EDI-Nachrichten über verschiedene Internetprotokolle ermöglichen [25]. Tabelle 2.1 listet diese Standards auf. Bezeichnung Veröffentlichungsjahr basiert auf AS SMTP AS HTTP AS FTP Tabelle 2.1: EDIINT-Standards Heutiger Stand des klassischen EDI Heute werden vor allem von großen Unternehmen in den USA noch immer VANs und deren X.400-Protokoll verwendet. Branchenschwergewichte wie WalMart setzen auf AS2, das neben X.400 das heute meistgenutzte Übertragungsverfahren beim klassischen EDI ist. Unter den internationalen EDI-Standards haben sich heute in den USA der Standard ANSI ASC X12 und in Europa und Asien branchenspezifische Subsets des EDIFACT-Standards größtenteils durchgesetzt. Eine Auswahl einiger EDIFACT-Subsets findet man in Tabelle 2.2. Subset CEFIC EANCOM EDIBDB EDIFICE EDIFOR EDIFURN EDILEKTRO EDILIBE EDIPAP EDITEC Branche Chemische Industrie Konsumgüterindustrie Baustoffbranche Elektronik und Hochtechnologie Speditionsbranche Möbelbranche Erdgasbranche Elektroindustrie & Elektrogroßhandel Buchhandel papierverarbeitender Sektor Sanitärbranche 11

21 2 Gegenüberstellung von EDI und SOA EDITEX EDITRANS ODETTE IMPA SWIFT Textilindustrie Transportwirtschaft Automobilindustrie Seeschifffahrt Finanzsektor Tabelle 2.2: EDIFACT-Subsets (Auswahl) Besondere Anforderungen bei der Übertragung EDI stellt besondere Anforderungen an die Übertragung von Nachrichten. Da diese Nachrichten üblicherweise einen realen monetären Wert haben, oftmals zeitkritisch sind und automatisiert in großer Anzahl übertragen werden, spielen die Aspekte Verfügbarkeit, Sicherheit und Nachvollziehbarkeit elementare Rollen. In diesem Zusammenhang seien auch die in Deutschland gültigen rechtlichen Bestimmungen bei der elektronischen Übertragung von Rechnungen und anderen Dokumenten mit Belegfunktion genannt. Verfügbarkeitsanforderungen Die Nutzung von EDI-Systemen ermöglicht eine Just-In-Time Produktion mit kürzesten Bestell- und Lieferzeiten. Wenn diese Vorteile ausgenutzt werden, muss das EDI-System eine ausreichend hohe Verfügbarkeit besitzen. Gleiches gilt bei Bestellungen von Aktionsware, die nur kurze Zeit verfügbar ist oder bei der Übertragung von Zahlungsanforderungen mit zeitkritischen Zahlungszielen. Generell lässt sich behaupten, dass die Geschwindigkeitsvorteile von EDI nur dann sicher ausgenutzt werden können, wenn man sich auf eine rechtzeitige Übertragung der gewünschten Nachrichten verlassen kann. Sicherheitsanforderungen EDI-Systeme dürfen die Kommunikation nur mit bekannten Kommunikationspartnern, d. h. Handelspartnern, erlauben. Ohne vorhergehende Signalisierung der Empfangsbereitschaft sollte eine Nachrichtenannahme verweigert werden. Aufgrund der besonderen Sensibilität mancher EDI-Nachrichten dürfen Dritte diese Nachrichten nicht abhören, abfangen, verändern, einspeisen oder wiederholen können. Veränderungen von Nachrichten müssen erkannt werden können und beschädigte Nachrichten müssen erneut versendet werden. Die korrekte Übertragung muss garantiert und ein Empfang darf nicht abgestritten werden können. Es muss festgestellt werden können, ob Nachrichten auch tatsächlich vom angegebenen Absender stammen. Bei besonders kritischen Nachrichten müssen Empfangsbestätigungen angefordert werden können. Manche VANs bieten in diesem Zusammenhang eine Überprüfung von empfangenen Nachrichten auf korrekten Inhalt an, dabei wird beispielsweise die Korrektheit von Identifikatoren wie ILN überprüft oder EAN-Artikelnummern mit dem Artikelstamm des Empfängers verglichen. 12

22 2 Gegenüberstellung von EDI und SOA Nachvollziehbarkeitsanforderungen Die Nachvollziehbarkeit von automatisiert ablaufenden Prozessen ist ein kritischer Faktor. Parsa und Popa [39] führen die Nachvollziehbarkeit in ihrem Ranking der wichtigsten Erfolgsfaktoren beim Einsatz von EDI auf dem ersten Platz. Während des Ablaufs von Prozessen müssen diese überwacht werden können und im Fehlerfall muss nachvollzogen werden können, wie es zu dem Fehler kam. Die spätere Nachvollziehbarkeit von abgeschlossenen Übertragungen spielt bei etwaigen Rechnungsprüfungen eine wesentliche Rolle. Rechtliche Bestimmungen EDI-Systeme müssen in Deutschland den Grundsätzen ordnungsmäßiger DV-gestützter Buchführungssysteme (GoBS) 3 genügen. Die dabei ausgetauschten, finanzrechtlich relevanten Dokumente haben den Grundsätzen zum Datenzugriff und zur Prüfbarkeit digitaler Unterlagen (GDPDU) 4 zu entsprechen. Insbesondere sind bei elektronischer Rechnungsübermittlung beide Seiten dazu verpflichtet, das Verfahren zu protokollieren und zu dokumentieren Vorteile Eine Nutzung von EDI kann für eine Reihe von operationalen, taktischen und strategischen Vorteilen sorgen. Da es sich bei EDI um eine bereits seit langem verfügbare und bekannte Technologie handelt, sollen die Vorteile hier nur kurz aufgezählt werden 5 : operationale Vorteile: geringere Kosten und kürzere Übertragungszeiten als bei papierbasierter Übertragung elektronische Übertragung ermöglicht weitestgehende Automatisierung durch Vermeidung der manuellen (Wieder-)Eingabe von Daten erheblich reduzierte Fehlerrate verbesserte Produktivität und effizienterer Personaleinsatz verbesserte Sicherheit durch Verschlüsselung und Zugriffsschutz taktische Vorteile: verbesserte Lagerverwaltung ermöglicht Just-In-Time Produktion und flexiblere Produktionsplanung verbesserter Vertrieb durch geringere Bestell- und Lieferzeiten vereinfachte Buchführung strategische Vorteile: 3 GoBS, Schreiben des Bundesministeriums der Finanzen an die obersten Finanzbehörden der Länder vom 7. November 1995 IV A 8 S /95 BStBl 1995 I S GDPDU, 146 Abs. 5, 147 Abs. 2, 5, 6, 200 Abs. 1 AO und 14 Abs. 4 UStG 5 Nähere Informationen zu den Vorteilen von EDI finden sich in [7, 28, 37, 40, 43]. 13

23 2 Gegenüberstellung von EDI und SOA beschleunigte Handelsabwicklung engere Bindung zwischen Handelspartnern durch verbesserte Kooperation bei gleichzeitig erschwertem Einstieg von Konkurrenten verbesserte Informationsverfügbarkeit nutzbar in vielen Bereichen: Prozessverbesserungen, Online-Shops, Auftragsverfolgung, Sendungsverfolgung, etc Nachteile Neben den aufgezählten Vorteilen von EDI existieren auch eine Reihe von Nachteilen, welche im Rahmen dieser Arbeit besondere Beachtung erfahren müssen. Speziell die Ursachen der heute am schwersten wiegenden Nachteile sollen identifiziert und untersucht werden. Wie bei jeder Technologie wandeln sich die Nachteile über den Lebenszyklus der Technologie. Während zu Anfang mangelndes Wissen und mangelnde Erfahrung, ungenügende Unterstützung seitens des Managements und geringe Reife beklagt werden, kristallisieren sich die substantiellen Schwachpunkte einer Technologie erst im Laufe der Zeit heraus bzw. werden durch die sich mit der Zeit wandelnden Anforderungen ersichtlich. Nach einem knappen halben Jahrhundert seit den Anfängen von EDI darf behauptet werden, dass diese Technologie in die Jahre gekommen ist. Nicht nur die technische Umsetzung wird als veraltet bezeichnet, insbesondere das Prinzip von EDI ist nicht mehr zeitgemäß. Letztlich lassen sich viele, wenn nicht gar alle heutigen Probleme mit EDI auf diese beiden Faktoren zurückführen. In diesem Abschnitt sollen die häufigsten in der Literatur genannten Nachteile und ihre Ursachen untersucht werden. Sie lassen sich in vier Gruppen zusammenfassen: ungenügende Standardisierung [5, 38, 41] hohe Kosten [5, 38, 41, 43] ungenügende Verbreitung [5, 24, 38] als Integrationsansatz überholt [5, 24, 26, 41] Die Ursachen dieser Nachteile und ihre konkreten Auswirkungen werden im Folgenden untersucht. Ungenügende Standardisierung Der sicherlich prominenteste Nachteil von EDI ist, dass in der Praxis auf allen Ebenen von EDI (s. Abbildung 2.2) sehr viele verschiedene Ausprägungen existieren. Die Kombination der möglichen Ausprägungen auf den einzelnen Ebenen führt zu einer unüberschaubaren Anzahl von zueinander inkompatiblen Ausprägungen von EDI-Schnittstellen. Zurückzuführen ist dies auf die große Anzahl verschiedener EDI-Standards. Diese Anzahl wird noch weiter vergrößert durch die Tatsache, dass sämtliche relevanten Standards einer kontinuierlichen Weiterentwicklung unterliegen. Zusätzlich zum Formatwirrwarr liegen Standards also auch noch in vielen verschiedenen Versionen vor. Insbesondere besteht innerhalb eines Standards üblicherweise keine Eindeutigkeit darin, mit welchen Konstrukten 14

24 2 Gegenüberstellung von EDI und SOA des Standards ein konkreter geschäftlicher Sachverhalt abzubilden ist, da sich ihre Anwendungsmöglichkeiten überschneiden. Unternehmen, die EDI in großem Umfang einsetzen, veröffentlichen daher in der Regel so genannte EDI-Guidelines, die die unternehmensspezifischen Arten und Weisen der Abbildung geschäftlicher Sachverhalte in expliziten Nachrichtenspezifikationen definieren. EDI-Standards bieten darüber hinaus keine Methode zur Erweiterung einzelner Dokumente. In der Praxis werden daher oftmals zusätzliche Sondervereinbarungen zwischen Handelspartnern getroffen, die den Interpretationsspielraum in der Anwendung eines Dokuments oder Konstrukts ausnutzen. Die Auswirkungen sind vielschichtig: So muss bei der Einrichtung von EDI-Anbindungen zwischen zwei Unternehmen die Kompatibilität ihrer EDI-Schnittstellen in mühsamer Handarbeit hergestellt werden. Dazu muss in der Regel eine Konvertierungslösung eingerichtet und konfiguriert werden, die verschiedene EDI-Standards oder verschiedene Interpretationen eines Standards ineinander übersetzen kann und dabei insbesondere alle ausgehandelten Anpassungen und Sondervereinbarungen abdeckt. Ergeben sich im Laufe der Anbindungsnutzung Änderungen, z. B. durch zusätzlich zu übertragende Informationen, müssen viele dieser Schritte zudem wiederholt werden. Dabei kann es passieren, dass kleinere geschäftliche Änderungen zu umfangreichen Änderungen in der EDI-Anbindung führen. Lassen sich die neuen Kommunikationsanforderungen beispielsweise nicht mehr mit den verwendeten Anbindungen abbilden, müssen bestehende Anbindungen modifiziert werden oder durch die Einrichtung zusätzlicher Anbindungen zur Übertragung weiterer Dokumente ergänzt werden. Dies wiederum erfordert eine aufwändige Revision der Konvertierungskonfiguration. Für jeden neuen anzubindenden Geschäftspartner muss dieser Prozess komplett wiederholt werden. Der Wechsel eines Geschäftspartners ist ähnlich aufwändig: Die Wahrscheinlichkeit ist sehr hoch, dass der neue Geschäftspartner andere Anforderungen bezüglich der EDI- Anbindung stellt, so dass wenn überhaupt nur geringe Teile der bestehenden Anbindung übernommen werden können. Damit muss auch hier in vielen Fällen faktisch eine komplett neue Anbindung eingerichtet werden. Badakhchani [5] bezeichnet die mangelnde Standardisierung als den größten Kostentreiber von EDI: [...] one of the major cost overheads of EDI: IT departments of trading partners in the business process have to design, implement, and test a custom business process for each trading partner they interact with. [5] Schmelzer [41] hebt die daraus hervorgehende mangelnde Skalierbarkeit von EDI hervor: [...] even though EDI provides a rigid format for how companies exchange information, the large degree of variability among different applications of EDI leads to significant ambiguity when implementing the standard. Users must resolve these ambiguities in a tedious, manual manner, which can be quite cumbersome to companies that must deal with dozens, hundreds, or even thousands of trading partners. [41] Durch diesen aufwändigen Prozess entstehen hohe Kosten, die sich nur dann in angemesse- 15

25 2 Gegenüberstellung von EDI und SOA ner Zeit amortisieren, wenn die Anbindung nach dem Einrichtungsprozess für längere Zeit, ohne Änderungen und mit hohem Transaktionsaufkommen genutzt wird. Ist eine derartige Nutzung nicht zu genügend großer Wahrscheinlichkeit absehbar, kann dies dazu führen, dass eine geschäftlich eigentlich sinnvolle Veränderung wie beispielsweise der Wechsel zu einem momentan günstigeren Zulieferer nicht umgesetzt wird. Dies wirkt sich auf strategischer Ebene in einer stark eingeschränkten organisatorischen Agilität aus. Ein Teil des Aufwands bei der Einrichtung einer EDI-Anbindung ist nicht vermeidbar, hierzu zählen vor allem die organisatorischen Anstrengungen wie das Abstimmen der Geschäftsprozesse. Die ungenügende Standardisierung von EDI trägt hier aber einen substantiellen Teil dazu bei, der vermeidbar wäre. Hohe Kosten Hohe Kosten entstehen allein schon durch die im vorigen Abschnitt aufgeführten Faktoren. Schwartz [43] nennt konkrete Zahlen für die Einrichtung einer EDI-Anbindung bei der Verwendung von VANs als Kommunikationskanal: [...] it favors the bigger players who can afford the stiff technology investment. Indeed, some analysts say it costs about $50,000 in integration costs to bring a single large supplier onto an already expensive VAN, and at least $10,000 for a small to midsized supplier. [43] Hinzu kommen signifikante Kosten für die Übertragung von EDI-Nachrichten. Nach Schmelzer [41] ist dies ein weiteres Hauptproblem von EDI: [...] A key problem of traditional EDI VANs is that their cost structure made them prohibitively expensive to implement for the majority of businesses, especially as the Internet blossomed as a potential alternative. Only the largest of suppliers could afford the costly setup fees associated with complex EDI software tools and the exorbitant per-transaction fees. As a result of these high costs, many small and medium-size firms simply could not afford to participate in the electronic, automated supply chains of their larger trading partners. [41] Da VANs heute eine der vorherrschenden Übertragungsverfahren von EDI darstellen, sind viele Unternehmen aufgrund von Vorgaben ihrer Handelspartner dazu gezwungen, die Kommunikation über VANs abzuwickeln. Zusammen mit den Initialkosten rechnet sich die Nutzung von EDI daher nur für große bis sehr große Unternehmen, die viele stabile Handelsbeziehungen pflegen und ein hohes Transaktionsaufkommen aufweisen. Ungenügende Verbreitung Aus den oben genannten Gründen ist EDI vornehmlich unter großen Unternehmen und Konzernen verbreitet: 1998 setzten 90% der Fortune 500-Unternehmen in den Vereinigten Staaten EDI ein, bei den übrigen zehn Millionen Unternehmen waren es nur 6% [3]. Setzt man voraus, dass Geschäftsbeziehungen zwischen Unternehmen im B2B-Fall der Pareto- Verteilung entsprechen; ein Unternehmen also zu wenigen größeren und zu vielen kleineren 16

26 2 Gegenüberstellung von EDI und SOA Unternehmen Geschäftsbeziehungen pflegt, kann man folgern, dass, je kleiner ein Unternehmen ist, desto kleiner auch die Mehrheit seiner Geschäftspartner ist. Da die Vorteile von EDI erst dann richtig zum Tragen kommen, wenn die Mehrheit der Geschäftspartner über EDI angebunden ist und dies umso unwahrscheinlicher wird, je kleiner ein Unternehmen ist, kann geschlossen werden, dass EDI sich auch weiterhin nur zwischen großen Unternehmen und Konzernen durchsetzen wird. Unternehmen, die durch Vorgaben größerer Geschäftspartner dazu gezwungen sind, EDI einzusetzen, werden aber bestrebt sein, auch ihre übrigen Geschäftspartner über EDI anzubinden. Je kleiner das Unternehmen, desto geringer ist die Chance, die Geschäftspartner allein aufgrund einer Machtposition zum Einsatz von EDI zu zwingen. Eine weitere Verbreitung kann also nur erfolgreich sein, wenn Kosten und Aufwand sinken und auch kleinere Unternehmen einen Sinn in der Nutzung von EDI sehen. Als Integrationsansatz überholt Die oben genannten Nachteile führen letztlich zu dem Schluss, dass EDI als Integrationsansatz die heutigen Anforderungen nicht mehr erfüllt. EDI ist zu aufwändig, erzeugt durch die inflexible Handhabung zu enge Kopplungen zwischen den angebundenen Unternehmen und ist zu teuer. Die Ursachen dafür liegen zum einen in der Begrenztheit des Geltungsbereichs von EDI und zum anderen in dessen technischer Umsetzung. Medjahed et al. [30] siedeln EDI hauptsächlich auf der Kommunikations- und Inhaltsebene an und sehen EDI-Standards beschränkt auf die Herstellung von Interoperabilität auf der Inhaltsebene (s. Abbildung 2.2). Die zwischen den Ebenen bestehenden Abhängigkeiten wurden bei der Entstehung von EDI nicht berücksichtigt und flossen nicht als Gestaltungskriterien bei der technischen Umsetzung mit ein. Zur Entstehungszeit von EDI richteten sich die Bestrebungen der IT in erster Linie auf eine Automation der Kommunikation. Ziele wie Rationalisierung, Geschwindigkeits- und Qualitätsverbesserung bei der Informationsübertragung zwischen Unternehmen standen im Vordergrund. Bei der technischen Umsetzung gab es viele Herausforderungen zu meistern, etwa die systemunabhängige Definition von Steuerzeichen, oder die effiziente Ausnutzung der knappen Bandbreite, was in einer aus heutiger Sicht kryptischen, knappen Gestaltung der EDI-Dokumentstandards resultierte. Für eine über die Automation der Kommunikation hinausgehende Integration war EDI jedoch nicht gedacht. In der Praxis äußert sich dieser Umstand darin, dass EDI als Basis für die Kommunikation bei der Integration von Geschäftsprozessen nicht besonders gut geeignet ist, da die technische Umsetzung von EDI auf den für die Integration wesentlichen Gebieten wie Flexibilität und Wartbarkeit Schwächen zeigt. Woodside [48] bestätigt dies: While EDI does achieve integration, it is not adequate for enterprise communication. EDI is complex, and does not provide the needed flexibility and maintainability to gain a competitive advantage. [48] Tatsächlich geht EDI nicht sehr weit über das hinaus, was man als eine effiziente Methode zur Vermeidung von menschlicher Intervention beim Informationsaustausch zwischen Un- 17

27 2 Gegenüberstellung von EDI und SOA ternehmen bezeichnen kann. Hill und Scudder [24] sahen dies in ihren Ergebnissen bestätigt: The results suggest that firms view EDI as a tool for improving efficiencies rather than as a tool for facilitating supply chain integration. [24] Zusammenfassung der wesentlichen Nachteile EDI ist ungenügend standardisiert: Es gibt zu viele verschiedene EDI-Standards und innerhalb der Standards zu viel Interpretationsspielraum für die Anwendung der durch einen Standard zur Verfügung gestellten Konstrukte. Daher müssen aufwändige manuelle Anpassungen bei der Abbildung der auszutauschenden Informationen auf EDI-Dokumente und bei der Konvertierung zwischen EDI-Standards durchgeführt werden, um die Kompatibilität der EDI-Schnittstellen zweier Unternehmen herzustellen. Abhängigkeiten zwischen Geschäftsprozessebene, Inhaltsebene und Kommunikationsebene sind bei der Entwicklung von EDI nicht berücksichtigt worden, daher können Änderungen auf einer Ebene zu teilweise erheblichen Änderungen auf anderen Ebenen führen. Dadurch kann sich bei Änderungen ein hoher Aufwand ergeben. Durch alle diese Faktoren entstehen hohe Kosten. Weitere Kosten entstehen bei der Übertragung von EDI-Dokumenten durch die verbreitete Nutzung teurer VANs. Aufwand und Kosten führen zu mangelnder Skalierbarkeit, Inflexibilität und schränken die organisatorische Agilität ein. 18

28 2 Gegenüberstellung von EDI und SOA 2.2 Serviceorientierte Architekturen Für nur wenige Begriffe lassen sich momentan so viele verschiedene und teilweise widersprüchliche Definitionen finden wie für SOA. Dies hat mehrere Ursachen, die im Folgenden dargelegt werden. SOA wurden 1996 vom Marktforschungs- und Beratungsunternehmen Gartner zum ersten Mal in dieser Form bezeichnet und hat sich seit dem mit großer Geschwindigkeit weiterentwickelt. Die kontinuierliche, noch andauernde Entwicklung und die vormalige Abstraktheit sind die beiden erste Umstände, die eine Definition zu dieser Zeit schwierig machten. Was SOA bedeutet, ist mit der Zeit klarer geworden, dennoch existieren noch heute viele Definitionen aus den Anfängen von SOA. Nach vorherrschender Meinung besitzt SOA als Technologie großes Potential. Sie macht komponentenbasierte Softwareentwicklung mit Wiederverwendung für die IT praktikabel, sie lässt die Lücke zwischen Geschäftsprozessen und deren Abbildung auf der IT-Ebene für die Fachabteilungen auf ein Minimum schrumpfen und für die Managementebene ermöglicht sie die kostengünstige Integration von heterogenen Systemlandschaften und Altsystemen. Dies hatte zur Folge, dass SOA aus den verschiedensten Blickwinkeln betrachtet und beschrieben wurde, was ein weiterer Grund für voneinander abweichende Definitionen darstellt. SOA-Umsetzungen auf Basis von Technologien wie CORBA, EJB oder RMI resultierten bereits in technologielastigen Definitionen. Doch vor allem die mittlerweile immer enger werdende Verzahnung von SOA und der vorherrschenden Ausprägung in Form von Webservices ließen die Grenzen zwischen diesen beiden Technologien verschwimmen, was zusätzliche Verwirrung stiftete und zu rein Webservice-basierten Definitionen führte, die die prinzipielle Technologie-Unabhängigkeit von SOA vollkommen ignorierten. Zu guter Letzt nutzten die Marketingabteilungen großer Anwendungssystem- und Middleware-Hersteller diese Verwirrung und die Popularität von SOA aus, um die eigenen Produkte als SOA zu verkaufen und verbreiteten Definitionen, die vor allem auf die eigenen Produkte und deren technologische Herkunft abgestimmt waren. Heute besteht über die Antwort auf die Frage, was unter einer serviceorientierten Architektur (SOA) zu verstehen ist, weitgehend Einigkeit. Im Folgenden werden Definitionen von SOA angegeben und diskutiert. Danach wird dargestellt, wie SOA auf Basis der Webservice- Technologie implementiert werden kann. Abgeschlossen werden soll das Kapitel mit einer Betrachtung der Vor- und Nachteile von SOA Definition Eine Definition des Begriffs Serviceorientierung als grundsätzliche Idee hinter einer SOA scheint als Einstieg naheliegend. Definition (Serviceorientierung) (angelehnt an Erl [17]) Serviceorientierung ist ein Ansatz zur Trennung von Belangen ( separation of concerns ), also zur funktionalen Dekomposition der Logik zur Lösung eines Problems in einzelne, einfacher zu handhabendere Teile: die Services. 19

29 2 Gegenüberstellung von EDI und SOA Der Unterschied zu vorherigen Ansätzen liegt dabei in den Prinzipien, nach denen diese Trennung vorgenommen wird. Die Prinzipien der Serviceorientierung sind: lose Kopplung Services minimieren Abhängigkeiten untereinander. Servicevertrag Services halten sich an eine durch ihre Servicebeschreibung definierte Kommunikationsvereinbarung. Autonomie Services besitzen Kontrolle über die Logik, die sie beinhalten. Abstraktion Die Logik eines Service ist hinter einer Schnittstelle gekapselt. Wiederverwendbarkeit Die Unterteilung der Logik auf Services erfolgt mit Absicht auf Wiederverwendung. Komponierbarkeit Services können koordiniert und zusammengefasst werden zu komponierten Services. Statuslosigkeit Services bewahren nach Möglichkeit keine aktionsspezifischen Informationen auf. Auffindbarkeit Services werden derart beschrieben, dass sie über Discovery-Mechanismen gefunden werden können und ihre Eignung für einen bestimmten Anwendungszweck bewertet werden kann. Eine serviceorientierte Architektur ist also letztlich eine Architektur, deren Komponenten (Services) aus einer nach serviceorientierten Gesichtspunkten erfolgten Dekomposition hervorgegangen sind und die Prinzipien der Serviceorientierung erfüllen. Services sind allerdings nicht die einzigen Komponenten einer SOA. Eine weitere für die Umsetzung der Prinzipien der Serviceorientierung benötigte Komponente ist die Kommunikationskomponente. In einer SOA erfolgt die Kommunikation zwischen den Services über Nachrichten [17]. Definition (Nachrichten) (angelehnt an Erl [17]) Nachrichten transportieren die zwischen den Services ausgetauschten Informationen. Neben diesen Informationen enthalten Nachrichten weiterhin alle Informationen, die notwendig sind, um die Nachricht an den als Empfänger spezifizierten Service weiterzuleiten. Neben den Services und den zwischen ihnen ausgetauschten Nachrichten besteht eine SOA noch aus einigen weiteren Komponenten, die von Krafzig et al. [27] aus einem architektonischen Blickwinkel definiert werden. Dazu definieren die Autoren zunächst, was unter einer Software-Architektur zu verstehen ist: Definition (Software-Architektur) A software architecture is a set of statements that describes software components and assigns the functionality of the system to these components. It describes the technical structure, constraints, and characteristics of the components and the interfaces between them. The architecture is the blueprint for the system and therefore the implicit high-level plan for its construction [27]. Die Komponenten, aus denen sich eine serviceorientierte (Software-)Architektur zusammensetzt, werden dann wie folgt definiert (s. Abbildung 2.3): 20

30 2 Gegenüberstellung von EDI und SOA Definition (Serviceorientierte Architektur I) A Service-Oriented Architecture (SOA) is a software architecture that is based on the key concepts of an application frontend, service, service repository, and service bus. A service consists of a contract, one or more interfaces, and an implementation [27]. Abbildung 2.3: Elemente einer SOA nach Krafzig et al. [27] (übersetzt durch Verfasser) Mit Hilfe dieser Komponenten und ihrer Beziehungen werden in einer SOA die Prinzipien der Serviceorientierung dann folgendermaßen umgesetzt [17, 27]: Definition (Anwendungsschnittstelle) Eine Anwendungsschnittstelle ( application frontend ) fungiert als Schnittstelle zu einer in der SOA implementierten Anwendung. Über sie werden Anwendungsprozesse gestartet, verfolgt, gesteuert und Ergebnisse der Prozesse ausgegeben. Typische Vertreter einer Anwendungsschnittstelle sind GUIs und Stapelverarbeitungsprozesse. Definition (Service) Ein Service ist eine eigenständige, unabhängige Softwarekomponente und besteht aus einer Implementierung ( implementation ), mindestens einer Schnittstelle ( interface ) und einem Servicevertrag ( contract ). Die Implementierung enthält die durch den Service repräsentierte Geschäftslogik nebst zugehöriger Daten und wird über die Schnittstelle abstrahiert. Der Umfang der Geschäftslogik ist dabei so gewählt, dass eine Wiederverwendung unterstützt wird. Services sind nach Möglichkeit statuslos und können zu komponierten Services zusammengefasst werden. Der Servicevertrag (auch Servicebeschreibung genannt) enthält üblicherweise eine formale Beschreibung der Schnittstelle. Zusätzlich können bzw. sollten Beschreibungen der Funktionalität, der Nutzungsweise und der Einschränkungen im Servicevertrag vorkommen, so dass der beschriebene Service über Discovery-Mechanismen aufgefunden werden kann und seine Eignung für einen bestimmten Anwendungszweck bewertet werden kann. Definition (Serviceverzeichnis/-depot) Ein Serviceverzeichnis ( service registry ) speichert die Servicebeschreibungen der einzelnen Services in einer SOA. Die Variante Servicedepot 21

31 2 Gegenüberstellung von EDI und SOA ( service repository ) speichert darüber hinaus auch die Services selbst. Beide Varianten bietet Möglichkeiten zur Auffindung von Services und stellen alle zur Nutzung eines Services benötigten Informationen zu Verfügung, weiterhin können hier zusätzliche Informationen wie physikalischer Ort des Service, Eigner, Nutzungsgebühren etc. vorgehalten werden. Definition (Servicebus) Ein Servicebus ( service bus ) verbindet Services und Anwendungsschnittstellen miteinander über die Weiterleitung von Nachrichten. Dabei überbrückt er heterogene Anbindungen, Programmiersprachen, Ausführungsumgebungen und Betriebssysteme, in dem er verschiedene Methoden der Kommunikation zur Verfügung stellt und ineinander übersetzen kann Webservices als Implementierungsform Die Grundideen und Konzepte von SOA sind ausdrücklich technologieunabhängig. Sie lassen sich prinzipiell in jeder Technologie umsetzen, die die grundlegenden Anforderungen von SOA konzeptionell unterstützen. Nichtsdestotrotz ist die Popularität der SOA-Implementierungen auf Basis von Webservices nicht unbegründet. Webservices bieten momentan die beste konzeptionelle Unterstützung und die fortgeschrittenste technische Unterstützung der Anforderungen von SOA [16, 21, 35]. Aus diesem Grund beschränkt sich diese Arbeit auf den Webservices-Ansatz. Webservices werden vom W3C wie folgt definiert: Definition (Webservice) A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machineprocessable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards [9]. In einer auf Webservices basierenden Implementierung von SOA werden Services in Form von Webservices abgebildet. Der Begriff Service ist im Folgenden also synonym zu Webservice zu verstehen. Die Komponenten einer SOA werden mit den folgenden Technologien aus dem Webservice- Umfeld umgesetzt: Zur Beschreibung eines Webservices über die Definition seiner Schnittstelle wird die Web Service Description Language (WSDL) verwendet [12]. Die Kommunikation mit einem Webservice erfolgt über den Austausch von SOAP-Nachrichten [20]. Als Technologie für die Implementierung eines Serviceverzeichnisses wird in der Literatur üblicherweise Universal Description, Discovery and Integration (UDDI) genannt 6 [13]. Für die Umsetzung eines Servicebusses existieren verschiedenste Ansätze, die sich unter anderem in der verwendeten Nachrichtentechnologie und in ihrer Topologie unterscheiden. Nähere Informationen zu verschiedenen Servicebus-Konzepten finden sich beispielsweise in [42]. Zur Modellierung und Definition von Geschäftsprozessen werden die Technologien Business Process Modelling Notation (BPMN) [33] und Business Process Execution Language (BPEL) [32] eingesetzt. 6 Es gibt allerdings Meinungen, dass UDDI sich nicht durchsetzen wird [29]. 22

32 2 Gegenüberstellung von EDI und SOA Vor- und Nachteile Die Vor- und Nachteile von SOA werden zur Zeit zur Genüge diskutiert. An dieser Stelle sollen nur kurz die wesentlichen Vorteile und Nachteile zusammengefasst werden. Nähere Informationen dazu finden sich beispielsweise in [16, 17, 23, 27, 36]. Vorteile Erl [17] nennt die folgende Vorteile von SOA: Verbesserte Integration und Interoperabilität Eine hohe Standardisierung über alle Ebenen ermöglicht eine verbesserte Interoperabilität und damit eine effektive Integration unabhängig von Technologie und Hersteller. Wiederverwendung Die Anwendung der Prinzipien der Serviceorientierung führen zu einer maximierten Wiederverwendung der entwickelten Services. schlankere Architekturen und Lösungen Der Fokus auf Komponierbarkeit erzeugt weniger Doppelentwicklungen und Spezialfälle. vorteilhafte Ausnutzung von Altsystemen Eine Anbindung über geeignete Adapterservices bindet Altsysteme in die neue Architektur ein und ermöglicht eine evolutionäre Herangehensweise an SOA. Etablierung von XML als Standard-Datenrepräsentation SOA baut in erheblichem Maße auf XML auf. Dies kann als Chance angesehen werden, eine unternehmensweit einheitliche Datenrepräsentation einzuführen. fokussierte Investitionen in Kommunikationsinfrastruktur Die SOA-Kommunikationsinfrastruktur stellt eine unternehmensweit gemeinsame, verteilte und skalierbare Kommunikationsplattform dar. Möglichkeit der Nutzung von best-of-breed -Lösungen SOA erlaubt den Einsatz der am besten geeigneten Lösungen unabhängig von Hersteller oder Implementierungstechnologie. Organisatorische Agilität SOA basiert auf der Annahme eines ständigen Wandels. Die Anpassungsfähigkeit einer SOA ist eine berechenbare und vorhersagbare Größe, was zu zuverlässiger und kostengünstiger Agilität führt. Nachteile Herrmann [23] fasst die Nachteile von SOA gut zusammen: Business IT Alignment Der Mangel an allgemein anerkannten Einführungs- und Umsetzungsmethoden führt zu einer hohen organisatorischen Belastung des Unternehmens. Fachabteilungen und IT müssen sehr eng zusammenarbeiten, um eine ausreichende Abstimmung zwischen Geschäftsprozessen und IT zu erreichen. Qualifikation Es gibt noch viel zu wenig Erfahrung mit der Umsetzung von SOA. Unternehmen müssen sich das dazu notwendige Wissen häufig mühsam selbst erarbeiten. 23

33 2 Gegenüberstellung von EDI und SOA Es fehlt vor allem an qualifizierte SOA-Architekten. Wirtschaftlichen Nutzen erklären Als hauptsächliches Problem wird der schwer darstellbare Return-on-Investment von SOA angesehen. Noch ist SOA nicht allgemein anerkannt als effektiver (oder gar einziger) Weg zur Bewältigung heutiger Anforderungen an Unternehmen. Unterstützung durch Top-Management Noch werden SOA vor allem von IT-Abteilungen getrieben. Eine breit angelegte SOA erfordert aber den uneingeschränkten Rückhalt aus dem Top-Management. SOA-Governance SOA erfordert schon früh eine ausgeprägte Verwaltung des vielschichtigen Zusammenspiels ihrer Elemente. Vor allem in der Anfangsphase entstehende Fehler werden häufig zu spät erkannt und verursachen mit steigender Größe der SOA erhebliche Risiken. Einstiegsprojekte identifizieren Der Ansatz Global denken, lokal handeln lässt sich bei einer Einführung von SOA nur schwer in ein konkretes Projekt übersetzen, denn Kosten und Nutzen einer SOA sind jeweils stark abhängig von der Größe des Projekts. Kleine Projekte können den Nutzen einer SOA so oft nur unzureichend demonstrieren. Semantische Integration Eine rein formale, technische Beschreibung von Services reicht nicht aus, um die Bedeutung von Funktionalität und Daten zu fassen. Eine effektive SOA erfordert die Einbeziehung der Semantik und entsprechende Technologien, die sich noch in der Entwicklung befinden. Komplexität Auch wenn organisatorische Hürden vielfach noch schwerer wiegen, darf die technische Komplexität von SOA nicht unterschätzt werden. Eine sichere, skalierbare, leistungsfähige und verwaltbare SOA stellt hohe Anforderungen an technisches Verständnis. Standards Standardisierung ist ein effektives Mittel gegen Komplexität und heterogene Strukturen. Im SOA- und vor allem im Webservices-Umfeld aber werden zu viele, teilweise konkurrierende und widersprüchliche Standards entwickelt, was auf starkes Engagement einzelner Hersteller in den Standardisierungsgremien zurückzuführen ist, die eigene Interessen durchsetzen. SOA-Komponenten testen Früh veröffentlichte, unreife Produkte von Herstellern erfordern ausgiebiges Testen von SOA-Komponenten. Gerade dies wird aufgrund der komplexen Zusammenspiele in einer SOA aber am häufigsten vernachlässigt. 24

34 2 Gegenüberstellung von EDI und SOA 2.3 Verhältnis zwischen EDI und SOA Auf den ersten Blick erscheinen die Technologien EDI und SOA doch sehr disjunkt. Jedoch kann EDI als Kommunikationstechnologie für verteilte Anwendungen angesehen werden, wenn man von dem speziellen Zweck der Nachrichten absieht. Auch innerhalb von SOA werden Kommunikationstechnologien eingesetzt, die im Falle einer webservicebasierten SOA durch WSDL und SOAP repräsentiert sind. Eine Gegenüberstellung auf der Kommunikationsebene ist also ein einleuchtender Ansatz Differenzierungsaspekte Die Gemeinsamkeiten und Unterschiede der Kommunikation bei EDI und SOA können nach den verschiedensten Aspekten betrachtet werden. Die Paradedisziplinen von EDI und SOA, nämlich Sicherheit und Flexibilität, gehören sicherlich zu den interessanteren Aspekten. Vor dem Hintergrund der Nutzung von EDI und SOA als Integrationsansatz erscheinen auch die Aspekte Heterogenität und Skalierbarkeit relevant. Im Folgenden werden diese Aspekte erörtert Flexibilität Flexibilität beschreibt die Fähigkeit, auf Änderungen reagieren zu können. EDI hat sich als nicht besonders flexibel herausgestellt, aber wie schneidet SOA als Kommunikationsebene im Vergleich ab? In der Praxis treten oft die folgenden Änderungen ein: Wechsel eines Geschäftspartners Änderungen in den auszutauschenden Informationen Änderung des verwendeten EDI-Standards Änderung des verwendeten Übertragungsverfahrens Im Folgenden werden die konkreten Auswirkungen dieser Änderungen bei einem Einsatz von EDI beschrieben und mit den Auswirkungen verglichen, die bei einem Einsatz von SOA als Kommunikationsebene entstünden. Wechsel eines Geschäftspartners Der Wechsel eines Geschäftspartners bringt aufgrund der hohen Varianz in den Ausprägungen der EDI-Schnittstellen mit hoher Wahrscheinlichkeit die Notwendigkeit mit sich, die auszutauschenden Informationen über einen anderen EDI-Standard oder andere EDI- Dokumente und gegebenenfalls auch über ein anderes Übertragungsverfahren zu übertragen. Auf der Kommunikationsebene bedeutet dies, dass die Konfiguration der Anbindung geändert werden muss, um die Datenverbindung herzustellen. Soll intern weiter derselbe EDI-Standard verwendet werden, um kein neues Mapping, also keine neue Abbildung der 25

35 2 Gegenüberstellung von EDI und SOA unternehmensspezifischen Geschäftsdokumente auf entsprechende EDI-Dokumente erstellen zu müssen, muss ein Konverter eingerichtet und konfiguriert werden. Alternativ können die neuen EDI-Dokumente verwendet werden, dann aber muss das Mapping überarbeitet werden. Im Extremfall könnten sogar die Konvertierungskonfiguration und das Mapping bearbeitet werden müssen. In beiden Fällen ist ein Wechsel mit der Überarbeitung mindestens einer manuell zu erstellenden Abbildung verbunden. Bei einem Einsatz von SOA als Kommunikationsebene sei vorausgesetzt, dass die auszutauschenden Informationen in Form von Nachrichten zwischen Kommunikationsservices übertragen werden. Auch hier ist die Wahrscheinlichkeit groß, dass der neue Geschäftspartner anders beschaffene Kommunikationsservices verwendet, um Informationen auszutauschen, jedenfalls solange, bis sich standardisierte Mengen von Services, oder abstrakter ausgedrückt, standardisierte SOA-Funktionalitäten, durchgesetzt haben. In diesem Fall sind die bestehenden Kommunikationsservices entweder mit zusätzlichen Schnittstellen auszustatten oder falls dies nicht ausreichend ist, müssen Adapter-Services erstellt oder erweitert werden. Unterschiedliche Übertragungsprotokolle werden dabei über den Servicebus abstrahiert. Im Vergleich fällt bei dem Einsatz von SOA die Konfigurationsnotwendigkeit der Datenverbindung fort. Doch auch bei einer SOA muss die Interoperabilität auf der Inhaltsebene manuell hergestellt werden. Dennoch scheint SOA flexibler zu sein, da bestehende Services, also auch bestehende Adapter-Services, im Laufe der Zeit mit immer höherer Wahrscheinlichkeit wiederverwendet werden können. Der Aufwand wird also bei jedem neuen Geschäftspartner potentiell geringer. Auch darf behauptet werden, dass aufgrund der Verwendung aktuellerer Technologie die Herstellung der Interoperabilität auf der Inhaltsebene relativ gesehen einfacher ist, als bei EDI, allein schon, weil keine starren EDI-Dokumente eingesetzt werden. Änderungen in den auszutauschenden Informationen Ändern sich die auszutauschenden Informationen, ist dies bei EDI mit hohem Aufwand verbunden: im besten Fall sind die geänderten Informationen weiterhin auf dieselben EDI- Dokumente abbildbar. Dann muss nur das Mapping geändert werden. Im schlechtesten Fall müssen andere EDI-Dokumente eingesetzt werden, was zur Folge hat, dass die Anbindung, die Konfiguration des Konverters und das Mapping überarbeitet werden müssen. Derselbe Fall ist bei einer SOA mit der Änderung der Schnittstellen der Kommunikationsservices oder der Ergänzung der Kommunikationsservices um zusätzliche Schnittstellen abgehandelt. Aus den geänderten WSDL-Beschreibungen werden dann automatisch neue passende SOAP-Nachrichten generiert. Hier ist klar zu sehen, wo das Problem von EDI und die Stärke von SOA liegt. Bedenkt man, dass Änderungen in Daten vermutlich sehr viel häufiger erfolgen als der Wechsel eines Geschäftspartners, ist die Tragweite des Unterschieds in der Flexibilität ersichtlich. Änderung des verwendeten EDI-Standards Bei einer Änderung des verwendeten EDI-Standards werden neue EDI-Dokumente eingesetzt. Daher muss das Mapping und die Konfiguration des Konverters überarbeitet werden. 26

36 2 Gegenüberstellung von EDI und SOA Bei der Verwendung einer SOA werden keine EDI-Standards verwendet, also kann dieser Fall gar nicht erst auftreten. Änderung des Übertragungsverfahren Steigt ein Unternehmen um auf ein neues Übertragungsverfahren, beispielsweise von der Nutzung eins VAN auf eine günstigere Übertragung per AS2, müssen lediglich die Konfigurationen der Anbindungen überarbeitet werden. Dies kann allerdings bedeuten, dass andere Sicherheitsmechanismen eingesetzt werden, welche dann ebenfalls zu konfigurieren sind. Im Falle der Nutzung einer SOA gibt es mehrere Stellen, an denen ein neues Übertragungsverfahren eingesetzt werden könnte: zwischen Services oder zwischen Service und Servicebus. Im schlechtesten Fall wird das neue Übertragungsverfahren weder von den Services noch vom Servicebus unterstützt. Dann ist der Servicebus um entsprechende Funktionalität zu erweitern. Der Servicebus abstrahiert dann den Wechsel des Übertragungsverfahren. Im besten Fall müssen nur die Schnittstellen der Kommunikationsservices um eine zusätzliche Anbindung über das neue Übertragungsverfahren ergänzt werden. Die Herstellung der Datenverbindung erfolgt dann automatisch wie bisher. Zusammenfassend lässt sich behaupten, dass SOA als Kommunikationsebene klar flexibler ist. Nichtsdestotrotz fällt auch bei einem Einsatz von SOA Aufwand an, besonders, wenn die Kompatibilität zwischen Kommunikationsservices hergestellt werden muss. Wie später in Abschnitt geschildert, ist das Problem der Interoperabilität nur von den EDI-Standards zu den Serviceschnittstellen verlagert Sicherheit EDI-Kommunikation ist traditionell sehr sicher. Dies ist nicht weiter verwunderlich, bedenkt man, welchen Zweck EDI von Anfang an hatte: die Übertragung von Geschäftsdokumenten. Dabei spielen alle Dimensionen von Sicherheit wesentliche Rollen (s. auch Abschnitt 2.1.5). Die Sicherheit kann auf Nachrichtenebene durch Verschlüsselung und Signierung erfolgen, obwohl auf dieser Ebene üblicherweise keine Sicherheitsmechanismen implementiert sind. Dies hängt mit der Übertragung der Dokumente zusammen, die in den meisten Fällen durch die Nutzung von VANs erfolgt. Hier geschieht die Übertragung der Nachrichten auf nachvollziehbaren und kontrollierten Wegen, daher kann die Sicherheit und die Zustellung der übertragenen Nachricht vom Anbieter des VANs garantiert werden. Bei der Nutzung von Protokollen aus der EDIINT AS-Familie und einer Übertragung über das Internet wird die Vertraulichkeit, Integrität und Nachvollziehbarkeit der Übertragung durch Verschlüsselung der Nachrichten und durch den Austausch signierter Message Disposition Notifications (MDNs) gewährleistet. Sicherheit in SOA ist ein Gebiet, auf dem sich momentan noch sehr viel entwickelt. Aufgrund der flexiblen Übertragungsmöglichkeiten von Webservice-Nachrichten kann die Sicherheit nicht auf der Basis einer entsprechenden Infrastruktur beruhen, sondern muss auf Nachrichtenebene umgesetzt sein. Für die Implementierung von Sicherheit auf Nachrichtenebene existiert mit der Webservices- 27

37 2 Gegenüberstellung von EDI und SOA Erweiterung WS-Security eine Basis, die mittlerweile breite Anerkennung genießt und Grundlage für viele andere Standards 7 für Webservices-Sicherheit ist [31], dennoch sind nachrichtenbasierte Sicherheitstechnologien im Kontext von SOA im Allgemeinen noch nicht ausgereift: nahezu alle für eine den Sicherheitsanforderungen von EDI-Nachrichten genügenden Übertragung benötigten Standards befinden sich noch im Entwicklungsstadium [22] Heterogenität und Kompatibilität Die Kommunikation bei EDI erfolgt über den Austausch von EDI-Dokumenten. Die Struktur von EDI-Dokumenten wie auch ihr möglicher Inhalt ist durch EDI-Standards festgelegt. Daher ergibt sich nur eine begrenzte wenn auch große Menge von vorgegebenen Dokumenten mit vorgegebener Struktur und vorgegebenem, möglichen Inhalt für jeweils einem speziellen Zweck. Zu übertragende Information muss also immer auf ein bereits existierendes Dokument abgebildet werden, worüber die Heterogenität der unternehmensspezifischen Anwendungssysteme effektiv gekapselt wird. Nachteile ergeben sich dabei durch die fehlende Erweiterbarkeit von EDI-Dokumenten und die Standardvielfalt. Andererseits verhindert das Fehlen einer Erweiterungsmöglichkeit aber eine noch größer werdende Inkompatibilität zwischen verschiedenen EDI-Ausprägungen. Das Problem der Standardvielfalt erfordert in der Regel ohnehin schon eine aufwändige Konvertierung der EDI-Dokumente. Insofern kann die fehlende Erweiterbarkeit von EDI-Dokumenten nicht nur als Nachteil gesehen werden, vielmehr steckt das Nachteilige bereits im Prinzip der Vorgabe von festen Dokumenten. Die Ausprägung der Nachrichten in einer SOA ist abhängig von den Schnittstellen der verwendeten Services. Ein Service definiert über seine in WSDL spezifizierte Schnittstelle die möglichen Nachrichten, die vom Service empfangen und versendet werden können. Auch der Inhalt dieser Nachrichten ist durch die Kombination von WSDL-Beschreibung und den XML-Schema-Beschreibungen der in der WSDL-Beschreibungen referenzierten Datentypen festgelegt. Die zu übertragende Information und die passende Nachricht ergibt sich also automatisch aus der Servicedefinition und daher müssen keine Nachrichten manuell spezifiziert werden. Services können allerdings dennoch nur dann miteinander kommunizieren, wenn ihre Servicedefinitionen kompatible Schnittstellen beschreiben. Die Herstellung der Kompatibilität zwischen Unternehmen auf Basis einer SOA erfordert also beispielsweise die Implementierung zusätzlicher Schnittstellen durch einen Service oder die Erstellung von Adapter- Services, die eine gemeinsame Schnittstelle herstellen, sowie unter Umständen einen Servicebus, der die vielen möglichen Messaging-Konzepte, die SOA anbietet, integriert. Insofern würden die Probleme von EDI, die sich aus der Standardvielfalt ergeben, durch einen Einsatz von SOA als Kommunikationsplattform nicht lösen, sondern nur auf die zugegebenermaßen einfacher behandelbare Serviceebene verschoben. 7 Hier zu zählen beispielsweise die Erweiterungen WS-Policy, WS-Trust und WS-SecureConversation. 28

38 2 Gegenüberstellung von EDI und SOA Skalierbarkeit Skalierbarkeit beschreibt in diesem Zusammenhang die Wachstumsfähigkeit eines Systems und die damit verbundene Entwicklung des Aufwands zur Aufrechterhaltung des Betriebs. Im Rahmen der Kommunikation kann das System in zwei Dimensionen wachsen: mehr Kommunikation und mehr Kommunikationspartner. Wie bereits in Abschnitt dargelegt, ist bei einer Zuname der Kommunikationspartner der hohe Aufwand bei der Einrichtung und der Pflege von EDI-Anbindungen die Ursache für die schlechte Skalierbarkeit einer auf EDI basierenden Kommunikation. Schon lange bevor die durch den hohen Aufwand entstehenden Kosten die durch die Nutzung von EDI eingesparten Kosten kompensieren würden, wäre der Aufwand nicht mehr vertretbar. Die einzige Maßnahme, die bei der Nutzung von EDI dabei helfen kann, auch eine sehr große Anzahl von Anbindungen zu verwalten, ist strikte Standardisierung. Aus diesem Grund führen Unternehmen, die mit hunderten oder tausenden Kunden über EDI-Anbindungen kommunizieren, oftmals eigenen Standards ein und setzen diese rücksichtslos durch: Ein potentieller Geschäftspartner lässt sich entweder auf die vorgegebenen Standards ein oder es kommt keine Anbindung und damit in der Regel auch keine Geschäftsbeziehung zustande. Der letztgenannte Umstand resultiert dabei allein aus der Tatsache, dass keine Ausnahmen bei der technischen Umsetzung der Abwicklung der Geschäftskommunikation gemacht werden dürfen: EDI ist allein schon aufwändig genug, als dass daneben noch die Nutzung einer zweiten Automationstechnologie oder gar eine händische Abwicklung der Geschäftskommunikation möglich wäre. Ein Wachstum im Hinblick auf Kommunikation, also Transaktionen, ist bei EDI allerdings relativ problemlos, da EDI von Beginn an auf möglichst hohen Durchsatz optimiert wurde. Die Skalierbarkeit von SOA ist ein in der Praxis noch recht unerforschtes Thema, da es bis jetzt erst wenig Erfahrungen mit sehr großen oder sehr kommunikationsintensiven SOAen gibt. Was die Zuname der Kommunikation angeht, so kann zumindest in der Theorie die Skalierbarkeit einer SOA einfach durch das redundante Anbieten mehrerer Instanzen eines Services und einer geeigneten Lastverteilung verbessert werden. Dies ist besonders einfach, wenn es gelingt, Services statuslos zu gestalten: hier sind dann keinerlei Abhängigkeiten zu berücksichtigen [34]. Die Grenzen der Skalierbarkeit werden durch die Leistungsfähigkeit der Server gesetzt: die massive Verwendung von XML erzeugt ein hohes Datenaufkommen, was zusammen mit der zusätzlichen Abstraktion in einer SOA zu verminderter Performanz führt. Noch weniger Erfahrungen gibt es auf dem Gebiet von SOA mit sehr vielen Services. Bei der Nutzung von SOA als Kommunikationsebene würde die Anzahl der Kommunikationsbzw. Adapterservices im schlechtesten Falle linear mit der Anzahl der Kommunikationspartner steigen. Bei der Verwaltung großer Mengen von Services sind Komponenten wie ein zentrales Serviceverzeichnis klassische Kandidaten für Kapazitätsengpasse und Single Point of Failures. UDDI begegnet diesem Problem mit einer physikalischen Replikation des Serviceverzeichnisses und kann so ebenfalls mit Lastverteilungsmechanismen skalierbar gehalten werden. 29

39 2 Gegenüberstellung von EDI und SOA 2.4 Nachteile von EDI, die sich durch SOA lösen lassen Die beiden wesentlichen Nachteile von EDI sind die mangelnde Flexibilität und die hohen Kosten (vgl. Abschnitt 2.1.7). Die hohen Kosten setzen sich zusammen aus Kosten für die aufwändige Einrichtung und Pflege von EDI-Anbindungen und Kosten für die Übertragung von EDI-Dokumenten. An der Höhe der Übertragungskosten kann der Einsatz einer SOA nichts ändern, zumindest nicht, solange durch einen Geschäftspartner die Art der Übertragung festgelegt ist. Um die Flexibilität bei der Nutzung von EDI zu erhöhen, gilt es, den Aufwand zu minimieren, der bei Einrichtung und Änderung einer Anbindung entsteht. Weiterhin gilt es, Auswirkungen von Änderungen seitens des Kommunikationspartners zu begrenzen. Weniger Aufwand bedeutet dabei gleichzeitig auch geringere Kosten. Der hohe Aufwand entsteht bei der Abbildung der auszutauschenden Informationen auf EDI-Dokumente und bei Änderungen dieser Abbildung, entweder weil die Informationen oder das verwendete Dokument sich geändert haben. Für die Abbildung wird üblicherweise ein Konverter eingesetzt, mit dem unternehmensinterne Anwendungsformate auf EDI-Dokumente abgebildet oder Dokumententsprechungen verschiedener EDI-Standards ineinander konvertiert werden 8. Der Konverter fungiert dabei als Abstraktionsebene und kann unternehmensinterne Änderungen auf Geschäftsebene und externe Änderungen auf der Kommunikations- und Inhaltsebene zumindest teilweise kompensieren. Auch bei einer Umsetzung von EDI in einer SOA bleibt dieses Prinzip bestehen: letztlich kann auch hier die Abbildung der unternehmensinternen Geschäftsdokumente auf entsprechende EDI-Dokumente nur über eine Art Adapter-Service erfolgen. Dies ist aber nichts anderes als eine serviceorientierte Konvertierungslösung. Da sich die Inflexibilität von EDI auf die Verwendung von EDI-Dokumenten zurückführen lässt, wird dieser Nachteil auch bei einer SOA-basierten Umsetzung von EDI geerbt. Solange die Anbindung des Unternehmens über EDI-Dokumente und entsprechende Übertragungsverfahren erfolgt, liegt der Schlüssel zu gesteigerter Flexibilität daher in der Effizienz der Konvertierungslösung bzw. in der Einfachheit der Konfiguration der Konvertierungslösung Szenarien Grundsätzlich sind beim Einsatz einer SOA drei Szenarien vorstellbar: Ersetzung von EDI: SOA wird unternehmensübergreifend eingesetzt. Beibehaltung von EDI als Schnittstelle: SOA wird unternehmensintern und unternehmensweit eingesetzt. Beibehaltung von EDI als Schnittstelle: SOA wird unternehmensintern eingesetzt, bleibt aber auf eine serviceorientierte Konvertierungslösung beschränkt. 8 Im Falle der Abbildung unternehmensinterner Informationen/Dokumente auf EDI-Dokumente spricht man dann von einem Mapper oder einer Mappinglösung statt von einem Konverter, das Funktionsprinzip ist jedoch identisch. 30

40 2 Gegenüberstellung von EDI und SOA Das erste Szenario ist wohl in naher Zukunft noch wenig realistisch. Dennoch ist der Ansatz interessant und wird im Ausblick (Abschnitt 4.1) aufgegriffen. Das zweite Szenario ist aufgrund der umfangreichen Veränderungen, die eine Einführung von SOA in ein Unternehmen mit sich bringt, nur auf langfristige Sicht realisierbar. Vor der Einführung von SOA sollte ein Plan erstellt werden, der eine schrittweise und pragmatische Einführung vorsieht. Jeder weitere Schritt hin zum letztlich unternehmensweiten Einsatz von SOA sollte dabei durch konkrete Vorteile begründet sein 9. Dies kann bedeuten, dass sich die Einführung einer unternehmensweiten SOA nicht für jedes Unternehmen lohnt. Vor diesem Hintergrund stellt das dritte Szenario einen sinnvollen und mittelfristig realisierbaren Ansatz dar und kann als Einstieg in SOA genutzt werden Eine serviceorientierte Konvertierungslösung Eine Beibehaltung von EDI als Schnittstelle für die Kommunikation zwischen Unternehmen bedeutet, dass die folgenden Nachteile von EDI weiterhin bestehen bleiben: Jede auszutauschende Information muss auch weiterhin auf ein EDI-Dokument abgebildet werden. Die genauen Nachrichtenspezifikationen für die benötigten EDI-Dokumente müssen ausgehandelt werden. Dieser Prozess kann sich bei Änderungen in den auszutauschenden Informationen teilweise wiederholen. Die Übertragung der EDI-Dokumente verursacht weiterhin hohen Kosten, insbesondere bei der Nutzung von VANs. Die serviceorientierte Konvertierungslösung, nachfolgend kurz Konverter genannt, kann diese Nachteile, wie bereits dargelegt, nicht vermeiden, sondern im besten Falle mindern. Dies geschieht durch die Anwendung der folgenden Prinzipien: 1. schnellere Durchführung von Änderungen durch einfachere Konfiguration des Konverters 2. weitmöglichste Automatisierung des Änderungsprozesses auf der Basis von Standardisierung 3. Begrenzung der Auswirkungen von Änderungen durch Abstraktionsebenen Alle diese Prinzipien kommen in einer SOA zur Anwendung: Die für die Konvertierung benötigte Funktionalität wird dazu in Form von Services zur Verfügung gestellt. Standardisierte Serviceschnittstellen ermöglichen eine flexible Komposition der Services zu zusammengesetzten Services und ganzen Konvertierungsprozessen. Über die Zuordnung von Services zu verschiedenen Service-Ebenen werden Abstraktionsebenen modelliert, die die Auswirkungen von Änderungen in der SOA, z. B. Änderungen der Hardware, der angebundenen Systeme oder der verwendeten Technologie und ebenso 9 Eine nähere Beschreibung des pragmatischen Umgangs mit SOA findet sich in [8]. 31

41 2 Gegenüberstellung von EDI und SOA auch Auswirkungen von Änderungen in den verarbeiteten Informationen auf die Services der betroffenen Schicht begrenzen. Die Komposition der Services kann grafisch über eine Modellierung in BPMN erfolgen. Das BPMN-Modell kann automatisch in BPEL übersetzt werden und ermöglicht dadurch zumindest in der Theorie eine schnelle und einfache Konfiguration des Konverters. Die Konfiguration des Konverters spielt bei der Steigerung der Flexibilität letztlich die Schlüsselrolle: Je einfacher die Konfiguration durchgeführt und geändert werden kann und je mehr dabei automatisiert und abstrahiert wird, desto effektiver ist die Minderung der Nachteile von EDI durch den Konverter. Die Vorteile von SOA im Hinblick auf Flexibilität könnten allerdings teilweise oder sogar ganz durch den erhöhten Overhead und die nicht zu vernachlässigende Komplexität einer SOA kompensiert werden. Ob sich durch den Einsatz von SOA eine Steigerung der Flexibilität gegenüber herkömmlichen Konvertern ergibt, ist also abhängig von der Qualität der Umsetzung. Eine generelle Aussage kann hier nicht getroffen werden. 32

42 3 Konzept zur Umsetzung von EDI in SOA In diesem Kapitel wird ein Konzept zur Umsetzung von EDI-Geschäftsprozessen in serviceorientierten Architekturen am Beispiel der EDI-Geschäftsprozesse des Unternehmens NEO Business Partners GmbH vorgestellt. Ausgehend von den Erkenntnissen aus Kapitel 2.3 soll in diesem Konzept untersucht werden, inwieweit der Einsatz einer SOA die aus der Verwendung von EDI resultierenden Nachteile lösen kann. 3.1 Vorstellung des Unternehmens Das Unternehmen NEO Business Partners GmbH (NEO) ist ein mittelständisches Unternehmen mit Hauptniederlassung in Hannover, einer Verwaltungsniederlassung in Stuttgart und insgesamt etwa 45 Mitarbeitern. Das Kerngeschäft von NEO ist die Beratung und Lösungsentwicklung in den Bereichen Vertrieb, Service und Marketing für große mittelständische Unternehmen und Konzerne, die als betriebswirtschaftliches Kernsystem die Produkte R/3 bzw. ERP des Softwareherstellers SAP einsetzen. Im Bereich Mobile Business ist NEO gemessen an der Anzahl der durchgeführten Projekte Marktführer in Europa und in mehreren Segmenten zertifizierter Special-Expertise-Partner der SAP. Ein weiteres, kleineres Betätigungsfeld von NEO ist der Bereich der EDI-Dienstleistungen. Hier werden EDI-Anbindungen zwischen Großhandelsunternehmen und kleineren Zulieferern angeboten. Der Schwerpunkt der Dienstleistung liegt auf einer Konvertierung zwischen verschiedenen, strukturierten Datenformaten. Die Großhandelsunternehmen setzen bei der Automatisierung ihrer Waren- und Finanzwirtschaft klassisches EDI ein: dabei werden die Nachrichten überwiegend im EDIFACT EANCOM Format in der Version D96A über das BusinessMail X System der deutschen Telekom oder über AS2 ausgetauscht. Die Kunden von NEO sind hier die kleineren Zulieferer, für die sich eine derartige EDI- Anbindung nicht lohnt, und die daher die benötigten Daten in strukturierter Form auf elektronische Weise an NEO versenden bzw. von NEO empfangen. Dies geschieht meist manuell oder teilautomatisiert per . Auch Übertragungen per HTTP(S) oder (S)FTP werden von NEO unterstützt. NEO konvertiert die empfangenen Daten dann in das gewünschte EDI-Format und sendet es über X.400 oder AS2 an die Handelspartner der Kunden weiter. In der Rückrichtung erfolgt die Konvertierung der von den Handelspartnern empfangenen EDI-Formate zurück in ein vom Kunden gewünschtes Format. Zur Zeit existieren etwa 220 Anbindungen von 25 Kunden. Die dabei am häufigsten ausgetauschten Geschäftsdokumente sind Rechnungen und Bestellungen. Der gesamte Prozess vom Empfang der Daten über den Konvertierungsprozess bis zum Weiterversand der konvertierten Daten wird von einem selbstentwickelten System namens 1 Dieses System ist noch bekannter unter dem vormaligen Namen Telebox

43 3 Konzept zur Umsetzung von EDI in SOA ECON abgewickelt. Dieses System ist der Betrachtungsgegenstand des Konzepts. 3.2 Methodik und Struktur des Konzepts Bei diesem Konzept wird der Goal-Question-Metric (GQM)-Ansatz angewandt, wodurch sichergestellt werden soll, dass die Aktivitäten innerhalb des Konzepts zielführend sind und der Grad der Zielerreichung messbar ist. GQM ist ein Ansatz zur Bestimmung von Metriken, die für die Messung des Ergebnisses eines Prozesses geeignet sind. Das Prinzip von GQM ist, ausgehend von Messzielen ( Goal ) eine Reihe von Fragen ( Question ) zu erstellen, die auf Qualitätsmerkmale oder Einflussfaktoren von Qualitätsmerkmalen des Ergebnisses abzielen. Durch die Beantwortung der Fragen kann die Qualität des Ergebnisses ermittelt und so überprüft werden, inwieweit die Ziele erreicht wurden. Jeder Frage werden dazu mindestens eine Metrik ( Metric ) zugeordnet, deren Messung eine objektive Beantwortung der Frage ermöglicht. Durch diese Vorgehensweise wird genau die relevante Menge von Metriken bestimmt, die für die Bestimmung des Zielerreichungsgrads nötig sind. Nähere Informationen über GQM finden sich beispielsweise in [6]. Durch die Anwendung des GQM-Ansatzes ergibt sich bereits eine grobe Struktur für das Konzept: Ziele festlegen, Fragen formulieren, Metriken bestimmen, Konzept erstellen, Ergebnis messen und Zielerreichungsgrad ermitteln. Für die Erstellung des Konzepts wurde die klassische Vorgehensweise nach Grochla [18] gewählt, womit sich die Struktur des Konzepts folgendermaßen ergibt: 1. Ziele festlegen 2. Fragen formulieren 3. Metriken bestimmen 4. Konzept erstellen a) Ist-Aufnahme (Prozesse, Systemlandschaft, Anforderungen) b) Ist-Kritik c) Sollkonzeption Lösungsgenerierung d) Sollkonzeption Evaluation 5. Ergebnis messen 6. Zielerreichungsgrad ermitteln Die Punkte Ergebnis messen und Zielerreichungsgrad ermitteln sind nur aus Gründen der Vollständigkeit angegeben: Aufgrund der Komplexität des ECON-Systems und des Umfangs der für eine repräsentative serviceorientierte Umsetzung des ECON-Systems notwendigen Maßnahmen konnte ein funktionsfähiger Prototyp, der die Messung ermöglicht hätte, nicht rechtzeitig fertiggestellt werden. Bei der Festlegung der Ziele und der Ist-Aufnahme wurden übliche Techniken der Anforderungsaufnahme und -analyse eingesetzt: Beobachtung, Interviews, Analyse des Altsystems 34

44 3 Konzept zur Umsetzung von EDI in SOA und zugehöriger Dokumente Messziele Der GQM-Ansatz sieht als erstes vor, konkrete Ziele festzulegen, deren Erreichungsgrad gemessen werden soll. Diese Messziele können aus den Geschäftszielen des Unternehmens abgeleitet werden und/oder sich an bestehenden Problemen orientieren. Die Geschäftsziele von NEO bezüglich des ECON-Systems wurden in einem kurzen Interview mit dem Projektmanager des ECON-Systems erfragt. Eine Zusammenfassung der wesentlichen Aussagen des Interviews ist in Anhang A.1.1 aufgeführt. Geschäftsziele Die aus dem Interview hervorgegangenen Geschäftsziele sind die folgenden: GZ1: Evaluation der Kosten und Nutzen einer Umsetzung des ECON-Systems in einer SOA GZ2: Wissensaufbau Die Erreichung des Geschäftsziel GZ2 (Wissensaufbau) kann dabei als Nebeneffekt der Verfolgung des Geschäftsziels GZ1 angesehen werden und wurde daher nicht weiter berücksichtigt. Aus GZ1 konnten als Messziele abgeleitet werden: Niedrigere Kosten beim Betrieb des ECON-Systems und Höherer Nutzen beim Betrieb des ECON-Systems. Diese Messziele sind allerdings wenig spezifisch. Bei der Durchführung des Interviews wurden jedoch bereits wesentliche Anforderungen genannt, die aus bestehenden Problemen resultierten und so als potentielle Messziele dienen können: Vereinfachte Konfiguration des Konverters Verbesserte Ausfallsicherheit des Systems Verbesserte Nachvollziehbarkeit des Prozesses Verbessertes Monitoring des Prozesses Um einen besseren Einblick in die bestehenden Probleme zu bekommen und so noch weitere Hinweise für geeignete Messziele zu erhalten, wurde ein Interview mit dem für die Bedienung des ECON-Systems zuständigen Mitarbeiter durchgeführt (Zusammenfassung s. Anhang A.1.2). Bei diesem Interview wurde nach weiteren Eigenschaften der Probleme, den möglichen Ursachen der Probleme und auch nach Verbesserungswünschen und Lösungsansätzen gefragt. Das Interview ergab, dass die Unübersichtlichkeit bei der Konfiguration eines der größten bestehenden Probleme ist. Die Unübersichtlichkeit resultiert aus der Tatsache, dass direkt auf den Konfigurationsdateien des Systems gearbeitet wird, ohne ein abstrahierendes Werkzeug dafür zu verwenden. Daraus ergibt sich der Verdacht, dass, bedingt durch die Unübersichtlichkeit dieser Art der Konfiguration, viel Zeit auf die Suche nach einer zu bearbeitenden Stelle entfällt und dies die Dauer einer Konfiguration unnötig verlängert. 35

45 3 Konzept zur Umsetzung von EDI in SOA Dazu wurde in einem weiteren Interview erfragt, wofür die meiste Zeit bei der Arbeit mit dem ECON-System verwendet wird (Zusammenfassung s. Anhang A.1.3). Auf Fehlerkorrekturen, Konfigurationen und Neuanbindungen entfallen danach etwa 90% der Zeit. Da eine vereinfachte Konfiguration auch bei Fehlerkorrekturen den Aufwand erheblich senken würde und Neuanbindungen fast nur aus Konfigurationsaktivitäten bestehen, wurde als wichtigstes Messziel die vereinfachte Konfiguration des Konverters festgelegt. Die Nachvollziehbarkeit des Prozesses ist ein zweiter Einflussfaktor auf den Aufwand bei Fehlerkorrekturen und daher wurde als zweites, niedrig priorisiertes Messziel eine verbesserte Nachvollziehbarkeit des Prozesses ausgewählt 2. Somit ergeben sich die folgenden Messziele: Z1: Vereinfachte Konfiguration des Konverters Z2: Verbesserte Nachvollziehbarkeit des Prozesses Fragen Der GQM-Ansatz sieht nun vor, zu diesen Messzielen einige Fragen zu formulieren, die dabei helfen, geeignete Metriken zu ermitteln. Fragen sollten auf Qualitätsmerkmale des zu messenden Objekts oder deren Einflussfaktoren abzielen. Das nächstliegende Merkmal des Konfigurationsprozesses, das als Indikator für die Komplexität genutzt werden kann, ist die Dauer des Prozesses: Je komplexer eine Konfiguration, desto länger dauert es, bis die Konfiguration erfolgt ist. Ein Vorteil dieses Merkmals ist, das es unabhängig von dem bei der Konfiguration verwendeten Werkzeug ist. Da die zu konzipierende serviceorientierte Lösung einen potentiell völlig anderen Ansatz zur Konfiguration des Konvertierungsprozesses nutzen könnte, dessen Ursachen für mögliche Auswirkungen auf die Komplexität der Konfiguration nicht mit den momentan bestehenden Ursachen vergleichbar sind, bietet sich dieses Merkmal an. Aus diesen Überlegungen resultierten die folgenden Fragen: F1: Wie lange dauert eine Konfiguration im Mittel? (Z1) F2: Wie lange dauert es im Mittel, einen Fehler in der Konfiguration zu finden? (Z1, Z2) F3: Wie lange dauert die Behebung eines Fehlers in der Konfiguration im Mittel? (Z1, Z2) Metriken Die Fragen zielen auf den bereits angesprochenen Verdacht des nachteiligen Verhältnisses zwischen der Zeit, die für die Suche nach einer zu bearbeitenden Stelle in der Konfiguration benötigt wird und der Zeit, die auf die eigentliche Konfigurationsaktivität entfällt. Die Metriken sollten diesen Umstand berücksichtigen, daher wurden die folgenden Metriken bestimmt: M1: Dauer einer Konfiguration (F1, F3) M2: Dauer der Suche nach Fehlern während einer Konfiguration (F2) 2 Mehr als zwei oder höchstens drei Messziele sind nach Assmann et al. [4] nicht zu empfehlen. 36

46 3 Konzept zur Umsetzung von EDI in SOA Mit der Kombination dieser beiden Metriken kann die Gesamtdauer einer Konfiguration als Indikator für ihre Komplexität und der Suchaufwand, der zusätzlich durch das Werkzeug entsteht, ermittelt werden. 3.3 Ist-Aufnahme In diesem Schritt des Konzepts wird der Ist-Zustand der Systeme und Prozesse aufgenommen. Dazu gehören Beschreibungen der Systeme und ihrer Funktionsweisen, Beschreibungen der Prozesse und für den GQM-Ansatz die Messung der Performanz des ECON-Systems bezüglich der festgelegten Metriken. Die Informationen bezüglich der momentanen Situation bei NEO wurden in mehreren Schritten erfasst. Zuerst wurde über einen Zeitraum von insgesamt etwa zwei Wochen verteilt auf zwei Tage pro Woche eine Beobachtung des Systems, dessen Ist-Performanz und der zur Konfiguration und Fehlerbehebung notwendigen Aktionen durchgeführt. Die dabei erfasste Ist-Performanz des Systems konnte jedoch nicht als repräsentativ eingeschätzt werden, da das ECON-System kurz vorher in ein neues Rechenzentrum verlagert wurde und noch teilweise einige Startschwierigkeiten bestanden. Daher wurde ein weiteres Interviews durchgeführt (Zusammenfassung s. Anhang A.1.4). Hierbei wurden Daten über die Performanz des Systems vor dem Umzug in das neue Rechenzentrum erfragt. Die dabei erhaltenen Angaben wurden als Ist-Performanz festgehalten: M1 ECON: Dauer einer Konfiguration: ~105 Minuten M2 ECON: Dauer der Suche nach Fehlern während einer Konfiguration: > 26 Minuten Schließlich wurden anhand der Erkenntnisse aus den vorhergehenden Interviews zur Ermittlung bestehender Probleme diejenigen Bereiche des ECON-Systems analysiert, aus denen die Unzulänglichkeiten resultierten. Dazu wurden insbesondere die für die Konfiguration des ECON-Systems verwendeten Dateien untersucht. Durch kürzere ad-hoc durchgeführte Befragungen wurden Details in den Informationen ergänzt Systembeschreibung In diesem Abschnitt wird das ECON-System vorgestellt. Dabei werden Funktionszweck und Entwicklungsgeschichte, die darin ablaufenden Prozesse und die Konfiguration beschrieben. Funktionszweck Das ECON-System wurde entwickelt zum Zwecke der Verarbeitung und insbesondere Konvertierung von EDI-Nachrichten und EDI-Dokumenten in beliebigen, strukturierten Formaten. Ein ECON-System kann dabei als Framework für diese Verarbeitung angesehen werden. Der Begriff Framework wurde gewählt, weil ein ECON-System in erster Linie Bausteine zur Lösung einzelner Probleme vorgibt und Möglichkeiten zu deren Zusammenschaltung definiert. Dadurch ist es hochgradig konfigurierbar und deckt so prinzipiell jede 37

47 3 Konzept zur Umsetzung von EDI in SOA Konvertierungsanforderung ab. Es arbeitet dateibasiert: Aus einer eingehenden Datei, die im so genannten Rohformat vorliegt, erzeugt es eine oder mehrere Dateien im jeweils gewünschten Zielformat. Die bei NEO eingesetzten ECON-Systeme können in drei grundsätzlich verschiedene Gruppen unterschieden werden: Kommunikationskanal-ECONs, Anbindungs-ECONs und ein einzelner Print-ECON. Überblick über die ECON-Systeme Ein Anbindungs-ECON ist für alle Anbindungen eines bestimmten Kunden zuständig. Pro auszutauschendem Geschäftsdokument und Richtung muss eine Anbindung erstellt werden. Sendet ein Unternehmen also Bestellungen an einen über EDI angebundenen Zulieferer und empfängt von diesem Rechnungen, sind zwei Anbindungen nötig, die jeweils ein bestimmtes Geschäftsdokument in eine bestimmte Richtung übertragen. Eine Anbindung wird durch genau einen ECON-Prozess repräsentiert. Jeder ECON-Prozess besitzt dazu ein Eingangsverzeichnis, über das die Rohdatei eingelesen wird und mindestens ein Ausgangsverzeichnis, in das jeweils eine Zieldatei ausgegeben wird. Zur Zeit sind bei NEO etwa 25 Anbindungs-ECONs in Betrieb. Ein Kommunikationskanal-ECON kümmert sich um den Empfang der eingehenden Daten im Rohformat und um den Versand der ausgehenden Daten im Zielformat über einen bestimmten Kommunikationskanal. NEO unterstützt zur Zeit fünf Kommunikationskanäle: , (S)FTP, HTTP(S), AS2 und X.400, folglich werden fünf Kommunikationskanal-ECONs eingesetzt. Jeder Kommunikationskanal-ECON überwacht das Eingangsverzeichnis seines Kommunikationskanals und die Ausgangsverzeichnisse derjenigen Anbindungen aller Anbindungs-ECONS, die ihre Zieldateien über den entsprechenden Kommunikationskanal weiterversenden. Eine Sonderrolle spielt der so genannte Print-ECON, der lediglich für den Ausdruck von Dokumenten mit Belegfunktion, üblicherweise Rechnungslisten, zuständig ist, die aus den in Abschnitt genannten finanzrechtlichen Gründen in Papierform aufbewahrt oder zwecks dokumentenechter Übertragung per Normalpapier-Telefaxgerät an den jeweiligen Regulierer versendet werden müssen. Jedes ECON-System wird in einer eigenen Java Virtual Machine (JVM) ausgeführt. Alle JVMs laufen innerhalb eines virtualisierten Rechners auf einem einzelnen physikalischen Rechner im Rechenzentrum von NEO. Entwicklung des ECON-Systems Aufgrund von immer wieder neuen Sonderfällen und Ausnahmen in der Ausprägung der zu konvertierenden Dateien wurde das ECON-System kontinuierlich weiterentwickelt. Ursprünglich eingeführte Konzepte wie ein standardisiertes internes ECON-Format, das auf immer gleiche Weise und daher ohne besonderen Konfigurationsaufwand in verschiedene Zielformate konvertiert werden kann, konnten dabei nicht strikt durchgehalten werden: Selbst auf der Ausgangsseite des Konvertierungsprozesses und den dort verwendeten EDI- FACT-Standards, die im Vergleich zu den auf der Eingangsseite verwendeten kundenspe- 38

48 3 Konzept zur Umsetzung von EDI in SOA zifischen Formaten hochgradig standardisiert sind, traten so viele verschiedene Sonderfälle auf, dass diese nicht mehr innerhalb des bestehenden internen ECON-Formates abgedeckt werden konnten. Für diese Anbindungen wurden daher Varianten des internen ECON-Formats eingeführt. Mittlerweile existieren zwischen zwanzig und dreißig verschiedene standardisierte interne ECON-Formate. Diese Umstände führten dazu, dass immer mehr eigentlich standardisierte Komponenten des ECON-Systems konfigurierbar gestaltet werden mussten, was die Komplexität der Konfiguration insgesamt erhöhte. Zusätzlich zu der Vielzahl der zu konfigurierenden Parameter trägt die aus den vielen Umbauten und Weiterentwicklungen resultierende gewachsene Struktur des Systems zu einer hohen Komplexität bei, was insbesondere bei der Fehleranalyse nachteilig ist Konvertierungsprozess In diesem Abschnitt wird der Ablauf eines Konvertierungsprozesses, seine Teilschritte und die darin durchgeführten Aktionen beschrieben. Die Konvertierung einer Datei vom Rohformat in ein Zielformat erfolgt über eine Reihe von Zwischenschritten, da in der Regel keine einfache Übernahme der Rohdaten in das Zielformat möglich ist, sondern die Daten zuerst aufbereitet und bearbeitet, um weitere Daten ergänzt und in manchen Fällen validiert werden müssen. In jedem Schritt werden dazu eine oder mehrere Aktionen auf den Daten oder der gesamten Datei ausgeführt. Typ und Ausprägung einer Aktion, deren Zusammenfassung zu einzelnen Schritten des Prozesses und die Reihenfolge der Schritte sind abhängig von mehreren Faktoren: Welche Daten müssen in welcher Form in der Zieldatei vorhanden sein? Welche Daten sind in welcher Form bereits in der Rohdatei vorhanden? Welche Daten müssen noch zusätzlich erzeugt oder aus Datenbanken abgefragt werden? Diese Daten sind von der Anbindung (z. B. Kunden- und Handelspartnerinformationen), vom Typ des Geschäftsdokuments oder von der jeweiligen Instanz des Geschäftsdokuments abhängig. Darüber hinaus sind weitere Schritte für Datensicherungen und Protokollierungen, Erstellung und Ausdruck von Rechnungslisten und Erstellung von Kundenbelegen nötig. Obwohl die einzelnen Konvertierungsprozesse im Detail höchst unterschiedliche Ausprägungen aufweisen, folgen alle Prozesse einem grundsätzlichen Ablauf. Dieser Ablauf wird nun beschrieben. Der gesamte Prozess kann auf erster Ebene in vier Schritte unterteilt werden: Datei abholen, Datei verarbeiten, Datei versenden und Rechnungsliste ausdrucken. Die vier Schritte werden nun im Detail beschrieben. Datei abholen Ein Konvertierungsprozess beginnt mit der Abholung der Rohdateien über einen Kommunikationskanal, üblicherweise per . Das Eingangsverzeichnis des jeweiligen Kommu- 39

49 3 Konzept zur Umsetzung von EDI in SOA Abbildung 3.1: ECON Prozess erste Ebene Abbildung 3.2: ECON Prozess Schritt Datei abholen 40

50 3 Konzept zur Umsetzung von EDI in SOA nikationskanals wird dazu periodisch von dem zuständigen Kommunikationskanal-ECON abgerufen, der die eingegangenen Rohdateien dann in das Eingangsverzeichnis des zuständigen Anbindungs-ECON ablegt. Die Zuordnung von Rohdateien zu einzelnen Anbindungs-ECONs ist dabei genauso realisiert wie bei einer Konvertierung zwischen zwei verschiedenen Formaten die Zuordnung einzelner Datensegmente in der Rohdatei zu Datensegmenten im Zielformat: über die Mappingkonfiguration des Kommunikationskanal-ECONs. Hier werden Rohdateien anhand bestimmter Eigenschaften wie z. B. des Dateinamens der Rohdatei den zuständigen Anbindungs-ECONs zugeordnet. Weiterhin wird an dieser Stelle unter Berücksichtigung der in Abschnitt genannten Anforderungen jeder Eingang von Rohdateien in einer Datenbank vermerkt, dabei werden Empfänger, Absender und der Zeitpunkt des Empfangs gespeichert. Damit ist die Abholung abgeschlossen und die Ausführung auf dem Kommunikationskanal- ECON beendet. Die weiteren Schritte laufen nun auf dem für die Rohdatei zuständigen Anbindungs-ECON ab. Datei verarbeiten Abbildung 3.3: ECON Prozess Schritt Datei verarbeiten Der Schritt Datei verarbeiten kann wiederum in sechs Schritte unterteilt werden: In XML konvertieren (optional, aber üblicherweise benötigt), Konvertierung vorbereiten, In internes Format konvertieren, In Zielformat konvertieren, In Ausgabeverzeichnis ablegen und Rechnungsliste erstellen. In XML konvertieren Die ersten Schritte auf dem für die Anbindung zuständigen Anbindungs-ECON ist das Umwandeln des Encoding der Rohdatei, falls nötig, und das Erstellen einer XML-Repräsentation der Rohdatei. Üblicherweise kommen Rohdateien im so genannten zeilenorientierten Feste- 41

51 3 Konzept zur Umsetzung von EDI in SOA Abbildung 3.4: ECON Prozess Schritt In XML konvertieren Feldlängen-Format oder im CSV-Format an. Die Umwandlung in eine XML-Repräsentation dient dazu, dass die weiteren Bearbeitungen und Konvertierungen per XSLT erfolgen können. Konvertierung vorbereiten Abbildung 3.5: ECON Prozess Schritt Konvertierung vorbereiten Die Aktionen in diesem Prozessschritt können in drei verschiedene Gruppen unterschieden werden. Aktionen aus den Gruppen treten in der Realität in beliebiger Reihenfolge und oft auch wiederholt auf. Die Aktionen sind üblicherweise in Form von XSLT-Transformationen realisiert. Daten bereinigen und aufbereiten: Hier werden die Rohformat-Daten je nach ihrem Datentyp in die für diesen Datentyp einheitliche XML-Darstellungsweise umgewandelt und dabei von irrelevanten Inhalten wie anhängenden Leerzeichen oder führenden Nullen befreit. Beispielsweise werden Datumsangaben nach deutscher Schreibweise, also TT.MM.JJJJ, in die Darstellung des Datentyps XML Date ( JJJJ-MM-TT ) oder Zahlen, deren Vorzeichen im Rohformat oft an die Zahlen angehängt werden, in entsprechende XML-Darstellungen von positiven bzw. negativen Zahlen umgewandelt. 42

52 3 Konzept zur Umsetzung von EDI in SOA Charakterisierend für diese Aktionen ist, dass nur die syntaktische Darstellungsform bearbeitet wird, die Bedeutung der Daten aber unverändert bleibt. Daten erzeugen: Hier werden Summen, Kumulationen von Mehrwertsteuersätzen, Gesamtrabattwerte und ähnliches errechnet. Weiterhin werden bestimmte Pro-Forma-Werte, die im Rohformat nur als Platzhalter dienen, durch die korrekten Werte ersetzt. Ein Beispiel dafür ist das Ersetzen der ILN des tatsächlichen Empfängers des Geschäftsdokuments, da manche Kunden die korrekte ILN nicht mitsenden. Charakterisierend für diese Aktionen ist, dass aus vorhandenen Daten neue Daten erzeugt oder vorhandene Daten durch neue Daten ersetzt werden. Daten validieren: Hier werden z. B. bei der Verarbeitung von Bestellungen die angegebenen Artikelnummern darauf überprüft, ob diese in den Artikelstammdaten des Empfängers tatsächlich vorhanden sind. Die Artikelstammdaten werden dazu bei NEO vorgehalten. Solche Validierungen sind sehr aufwändig und werden nur auf besonderen Wunsch des Kunden implementiert. Daher kommen solche Aktionen selten vor. Nach Abschluss der Vorbereitungen sind alle Informationen in der Datei vorhanden, die im Zielformat vorhanden sein müssen. In internes Format konvertieren Abbildung 3.6: ECON Prozess Schritt In internes Format konvertieren In diesem Schritt wird die Datei in ein so genanntes internes ECON-Format konvertiert. Dieser Schritt ist historisch bedingt. Das ursprüngliche Ziel war dabei, durch die Konvertierung in ein internes Format flexibler auf Änderungen des Zielformat-Standards reagieren zu können, da aus dem standardisierten internen Format ohne großen Konfigurationsaufwand alle unterstützten Zielformate und alle weiteren notwendigen Dokumente erstellt werden können. Die Konvertierung wird durchgeführt durch eine Reihe von XSLT-Transformationen auf der Datei. 43

53 3 Konzept zur Umsetzung von EDI in SOA Abbildung 3.7: ECON Prozess Schritt In Zielformat konvertieren In Zielformat konvertieren In diesem Schritt wird aus dem internen ECON-Format das endgültige Zielformat erstellt. Dazu wird die Datei zunächst in das Zielformat, üblicherweise EDIFACT EANCOM D96A, konvertiert. Die resultierende Datei ist dann noch immer im XML-Format und wird in einem letzten Schritt in eine Binärdatei serialisiert. In Ausgabeverzeichnis ablegen Hier wird die serialisierte Binärdatei in das Ausgangsverzeichnis des ECON-Prozesses abgelegt. Diese Datei stellt eines der Endergebnisse des Konvertierungsprozesses dar und wird nun üblicherweise per X.400 an den Geschäftspartner des Kunden versendet. Dies geschieht jedoch durch den entsprechenden Kommunikationskanal-ECON. Rechnungsliste erstellen Abbildung 3.8: ECON Prozess Schritt Rechnungsliste erstellen 44

54 3 Konzept zur Umsetzung von EDI in SOA Beim Konvertierungsprozess werden neben der Zieldatei noch zwei weitere Dokumente erstellt. Zum einen muss eine Rechnungsliste ausgedruckt werden, die sämtliche verarbeitete Rechnungen auflistet (s. Abschnitt 2.1.5). Zum anderen erhält der Kunde von NEO per E- Mail diese Rechnungsliste in Form einer PDF-Datei als Bestätigung der korrekten und rechtzeitigen Verarbeitung. Die dazu notwendigen Informationen sind sämtlich in der Datei im internen ECON-Format vorhanden. Sie werden mit Hilfe von XSL-FO-Dateien formatiert und so für den Ausdruck bzw. die Umwandlung in PDF vorbereitet. Der Konvertierungsprozess ist damit abgeschlossen. Datei versenden Abbildung 3.9: ECON Prozess Schritt Datei versenden Die erstellten Dateien im Zielformat werden nun von den entsprechenden Kommunikationskanal-ECONs aus den Prozess-Ausgabeverzeichnissen ausgelesen und anhand der Verzeichnisse und weiterer Daten wie Dateiname etc. den jeweiligen Empfängern zugeordnet. Danach werden die Dateien versendet und die Versendung protokolliert. Rechnungsliste ausdrucken Der Print-ECON nimmt die an ihn gesendete Rechnungsliste entgegen und druckt sie über einen lokalen Drucker aus. Mit dem Versand der ausgedruckten Rechnungsliste über Telefax an den zuständigen Regulierer ist der gesamte Prozess abgeschlossen Konfiguration In diesem Abschnitt wird nun dargelegt, wie ein Prozess auf einem ECON-System konfiguriert wird. Die bei einem Konvertierungsprozess ablaufenden Aktionen stellen die Umsetzung eines so genannten Mappings dar. Andersherum ausgedrückt definiert ein Mapping, wie einzelne Daten im Rohformat bearbeitet, zu neuen Daten kombiniert, welche Daten aus anderen 45

55 3 Konzept zur Umsetzung von EDI in SOA Quellen abgefragt werden müssen und wie diese Daten dann den einzelnen Datensegmenten im Zielformat zugeordnet werden. Die Erstellung eines solchen Mappings wird hier als Konfiguration des ECON-Systems bezeichnet. Im Fall des ECON-Systems kann die Konfiguration in zwei Ebenen unterschieden werden: zum einen in die Ebene der Prozesskonfiguration, auf der die einzelnen Schritte des Prozesses und deren Reihenfolge definiert und zum anderen in die Ebene der Mapping- Konfiguration, auf der die in den einzelnen Schritten konfigurierten Aktionen definiert sind (s. Abbildung 3.10). Abbildung 3.10: ECON Konfigurationsebenen Prozesskonfiguration Die Prozesskonfiguration eines ECON-Prozesses wird in Form eines XML-Dokuments definiert und ist in Transaktionen und darin enthaltenen Komponenten strukturiert. Transaktionen waren ursprünglich tatsächlich als Transaktionen im Sinne einer atomaren Ausführung der enthaltenen Komponenten gedacht, diese Funktionalität wurde aber mangels realer Dringlichkeit nicht implementiert. Komponenten sind die Bausteine des Frameworks, das das ECON-System darstellt. Es existieren verschiedene Typen von Komponenten, die jeweils spezielle Aktionen ausführen können. Dazu enthalten sie Parameter in Form von Konstanten oder dynamisch belegten Variablen. Komponenten unterscheiden sich nach Anzahl ihrer vorhergehenden und nachfolgenden Komponenten in drei verschiedene Klassen: Eine Source-Komponente besitzt keine vorhergehende und mindestens eine nachfolgende Komponente. Eine Pipe-Komponente besitzt mindestens eine vorhergehende und mindestens eine nachfolgende Komponente. Eine Sink- Komponente besitzt mindestens eine vorhergehende und keine nachfolgende Komponente. 46

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

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

Mehr

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

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

Mehr

Oliver Olbrich Das ebxml Projekt Entstand 1999 in einer gemeinsamen Initiative von OASIS (Organisation for the Advancement of Structured Information Standards) und UN/CEAFACT (United Nations Center for

Mehr

Workshop 3. Excel, EDIFACT, ebxml- Was ist state. of the art und wo liegt die Zukunft. 16. September 2002

Workshop 3. Excel, EDIFACT, ebxml- Was ist state. of the art und wo liegt die Zukunft. 16. September 2002 Workshop 3 Excel, EDIFACT, ebxml- Was ist state of the art und wo liegt die Zukunft 16. September 2002 Dipl. Kfm. power2e energy solutions GmbH Wendenstraße 4 20097 Hamburg Telefon (040) 80.80.65.9 0 info@power2e.de

Mehr

Weniger Kosten, mehr Möglichkeiten. Electronic Data Interchange (EDI): Optimierung von Geschäftsprozessen durch beleglosen Datenaustausch

Weniger Kosten, mehr Möglichkeiten. Electronic Data Interchange (EDI): Optimierung von Geschäftsprozessen durch beleglosen Datenaustausch Weniger Kosten, mehr Möglichkeiten Electronic Data Interchange (EDI): Optimierung von Geschäftsprozessen durch beleglosen Datenaustausch Schneller, transparenter, kostengünstiger EDI Was ist EDI und was

Mehr

Integrierte Geschäftskommunikation

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

Mehr

Workflow, Business Process Management, 4.Teil

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

Mehr

Workflow Management: Workflow (1)

Workflow Management: Workflow (1) Workflow Management: Workflow (1) Abgrenzung: Geschäftsprozeß Vorgang (Aktivität) Arbeitsablauf (Workflow) Arbeitsschritt (Work Item) Otto-von-Guericke-Universität Magdeburg Fakultät für Informatik Institut

Mehr

Innovating EDI. Geschäftsprozesse OPTIMIEREN. Datenaustausch DYNAMISIEREN. FLEXIBEL. NACHHALTIG. KOSTENEFFIZIENT. FÜR JEDE UNTERNEHMENSGRÖSSE.

Innovating EDI. Geschäftsprozesse OPTIMIEREN. Datenaustausch DYNAMISIEREN. FLEXIBEL. NACHHALTIG. KOSTENEFFIZIENT. FÜR JEDE UNTERNEHMENSGRÖSSE. Foto thinglass - Fotolia.com Geschäftsprozesse OPTIMIEREN. Datenaustausch DYNAMISIEREN. FLEXIBEL. NACHHALTIG. KOSTENEFFIZIENT. FÜR JEDE UNTERNEHMENSGRÖSSE. Unsere Produkte im Überblick ecosio bietet flexible

Mehr

EDI Datenaustausch und Konvertierung Funktionsumfang & Services

EDI Datenaustausch und Konvertierung Funktionsumfang & Services cleardax EDI Datenaustausch und Konvertierung Funktionsumfang & Services Einleitung Hauptfunktionen Datenaustausch (Anbindungsmöglichkeiten) Konvertierung Mappings Zusatzleistungen und Funktionen cleardax

Mehr

XML Pre- XML Systeme

XML Pre- XML Systeme XML Pre- XML Systeme Abdelmounaim Ramadane Seminar Grundlagen und Anwendungen von XML Universität Dortmund SS 03 Veranstalter: Lars Hildebrand, Thomas Wilke 1 Vortragsüberblick 1. Wirtschaftliche Bedeutung

Mehr

Befragung und empirische Einschätzung der Praxisrelevanz

Befragung und empirische Einschätzung der Praxisrelevanz Befragung und empirische Einschätzung der Praxisrelevanz eines Vorgehensmodells zur Auswahl von CRM-Systemen D I P L O M A R B E I T zur Erlangung des Grades eines Diplom-Ökonomen der Wirtschaftswissenschaftlichen

Mehr

Prinzipiell wird bei IP-basierenden VPNs zwischen zwei unterschiedlichen Ansätzen unterschieden:

Prinzipiell wird bei IP-basierenden VPNs zwischen zwei unterschiedlichen Ansätzen unterschieden: Abkürzung für "Virtual Private Network" ein VPN ist ein Netzwerk bestehend aus virtuellen Verbindungen (z.b. Internet), über die nicht öffentliche bzw. firmeninterne Daten sicher übertragen werden. Die

Mehr

Systembeschreibung. Masterplan Kommunikationsinterface. ASEKO GmbH. Version 1.0 Status: Final

Systembeschreibung. Masterplan Kommunikationsinterface. ASEKO GmbH. Version 1.0 Status: Final Systembeschreibung Masterplan Kommunikationsinterface ASEKO GmbH Version 1.0 Status: Final 0 Inhaltsverzeichnis 1 Einleitung... 2 2 Architektur... 2 2.1 Anbindung an die MKI Lösung... 2 2.2 Inbound Kommunikationsmethoden...

Mehr

Alireza Salemi, Timo Albert. SGML-basierte Datenaustauschformate. Referenten:

Alireza Salemi, Timo Albert. SGML-basierte Datenaustauschformate. Referenten: SGML-basierte Datenaustauschformate Referenten: Alireza Salemi Timo Albert Gliederung Einleitung XML - Kurzeinführung Web Service-Technologien XML-basierte Austauschformate Spezifische Markup-Languages

Mehr

SAP BUSINESS ONE Electronic Data Interchange

SAP BUSINESS ONE Electronic Data Interchange SAP BUSINESS ONE Electronic Data Interchange SAP BUSINESS ONE VON DER KOSTENGÜNSTIGEN LÖSUNG DES BRANCHENFÜHRERS PROFITIEREN SAP Business One ist eine integrierte und kostenorientierte Unternehmenslösung,

Mehr

Vereinbarung über den elektronischen Datenaustausch (EDI)

Vereinbarung über den elektronischen Datenaustausch (EDI) Vereinbarung über den elektronischen Datenaustausch (EDI) RECHTLICHE BESTIMMUNGEN Die Vereinbarung über den elektronischen Datenaustausch (EDI) wird getroffen von und zwischen:, Unterkotzauer Weg 25, 95028

Mehr

Vereinbarung über den elektronischen Datenaustausch (EDI)

Vereinbarung über den elektronischen Datenaustausch (EDI) Vereinbarung über den elektronischen Datenaustausch (EDI) RECHTLICHE BESTIMMUNGEN Die Vereinbarung über den elektronischen Datenaustausch (EDI) wird getroffen von und zwischen: ZVO Energie GmbH und...

Mehr

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

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

Mehr

arlanis Software AG SOA Architektonische und technische Grundlagen Andreas Holubek

arlanis Software AG SOA Architektonische und technische Grundlagen Andreas Holubek arlanis Software AG SOA Architektonische und technische Grundlagen Andreas Holubek Speaker Andreas Holubek VP Engineering andreas.holubek@arlanis.com arlanis Software AG, D-14467 Potsdam 2009, arlanis

Mehr

Spezifikationen und Voraussetzung

Spezifikationen und Voraussetzung Projekt IGH DataExpert Paynet Adapter Spezifikationen Voraussetzungen Datum : 21.07.08 Version : 1.0.0.2 21.07.2008 Seite 1 von 7 Inhaltsverzeichnis 1 Einleitung... 3 2 Architektur... 3 2.1 Grundsätze

Mehr

EDI Richtlinie für Lieferanten. Elektronischer Datenaustausch mit KNV

EDI Richtlinie für Lieferanten. Elektronischer Datenaustausch mit KNV EDI Richtlinie für Lieferanten Elektronischer Datenaustausch mit KNV 1 Inhaltsverzeichnis 1. Vorbemerkung... Seite 3 2. Voraussetzungen... Seite 3 2.1 GLN... Seite 3 2.2 Datenübertragung... Seite 3 2.2.1

Mehr

Welcome to PHOENIX CONTACT

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

Mehr

IT-basierte Erstellung von Nachhaltigkeitsberichten. Diplomarbeit

IT-basierte Erstellung von Nachhaltigkeitsberichten. Diplomarbeit IT-basierte Erstellung von Nachhaltigkeitsberichten Diplomarbeit zur Erlangung des Grades eines Diplom-Ökonomen der Wirtschaftswissenschaftlichen Fakultät der Leibniz Universität Hannover vorgelegt von

Mehr

Integrating Architecture Apps for the Enterprise

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

Mehr

Vereinbarung über den elektronischen Datenaustausch (EDI)

Vereinbarung über den elektronischen Datenaustausch (EDI) Vereinbarung über den elektronischen Datenaustausch (EDI) zwischen Stadtwerke Bebra GmbH, Wiesenweg 1,36179 Bebra. (Name, Adresse) und. (Name, Adresse) - nachfolgend die Vertragspartner genannt Seite 1

Mehr

Vereinbarung über den elektronischen Datenaustausch (EDI) ED Netze GmbH. Schildgasse 20. 79618 Rheinfelden (Baden)

Vereinbarung über den elektronischen Datenaustausch (EDI) ED Netze GmbH. Schildgasse 20. 79618 Rheinfelden (Baden) Vereinbarung über den elektronischen Datenaustausch (EDI) zwischen ED Netze GmbH Schildgasse 20 79618 Rheinfelden (Baden) und - nachfolgend die Vertragspartner genannt - ED Netze GmbH / Stromlieferant

Mehr

Vereinbarung über den elektronischen Datenaustausch (EDI) Energieversorgung Selb-Marktredwitz GmbH. Gebrüder-Netzsch-Str. 14.

Vereinbarung über den elektronischen Datenaustausch (EDI) Energieversorgung Selb-Marktredwitz GmbH. Gebrüder-Netzsch-Str. 14. Vereinbarung über den elektronischen Datenaustausch (EDI) zwischen Energieversorgung Selb-Marktredwitz GmbH Gebrüder-Netzsch-Str. 14 95100 Selb (Netzbetreiber) und (Transportkunde / Netznutzer) - nachfolgend

Mehr

EDI-Rahmenvertrag. Zwischen. im folgenden - Lieferant - genannt. und

EDI-Rahmenvertrag. Zwischen. im folgenden - Lieferant - genannt. und EDI-Rahmenvertrag Zwischen im folgenden - Lieferant - genannt und Pfalzwerke Netzgesellschaft mbh Kurfürstenstrasse 29 67061 Ludwigshafen im folgenden - Netzbetreiber - genannt Seite 2 des EDI-Rahmenvertrages

Mehr

Vereinbarung über den elektronischen Datenaustausch (EDI)

Vereinbarung über den elektronischen Datenaustausch (EDI) Vereinbarung über den elektronischen Datenaustausch (EDI) RECHTLICHE BESTIMMUNGEN Die Vereinbarung über den elektronischen Datenaustausch (EDI) wird getroffen von und zwischen: STADTWERKE HEIDE GmbH und

Mehr

Mustervereinbarung über den elektronischen Datenaustausch (EDI)

Mustervereinbarung über den elektronischen Datenaustausch (EDI) Mustervereinbarung über den elektronischen Datenaustausch (EDI) RECHTLICHE BESTIMMUNGEN Die Vereinbarung über den elektronischen Datenaustausch (EDI) wird getroffen von und zwischen: Energie- und Wassersorgung

Mehr

Vereinbarung über den elektronischen Datenaustausch (EDI)

Vereinbarung über den elektronischen Datenaustausch (EDI) Vereinbarung über den elektronischen Datenaustausch (EDI) RECHTLICHE BESTIMMUNGEN Die Vereinbarung über den elektronischen Datenaustausch (EDI) wird getroffen von und zwischen: enwag energie- und wassergesellschaft

Mehr

Vereinbarung über den elektronischen Datenaustausch (EDI-Vereinbarung)

Vereinbarung über den elektronischen Datenaustausch (EDI-Vereinbarung) Vereinbarung über den elektronischen Datenaustausch (EDI-Vereinbarung) zwischen Stadtwerke Dachau, Brunngartenstr. 3, 85221 Dachau - nachfolgend Netzbetreiber genannt - und... (Name, Adresse) - nachfolgend

Mehr

Vereinbarung über den elektronischen Datenaustausch (EDI)

Vereinbarung über den elektronischen Datenaustausch (EDI) Anlage 3 Vereinbarung über den elektronischen Datenaustausch (EDI) RECHTLICHE BESTIMMUNGEN Die Vereinbarung über den elektronischen Datenaustausch (EDI) wird getroffen von und zwischen: zwischen Stadtwerke

Mehr

Vereinbarung über den elektronischen Datenaustausch (EDI)

Vereinbarung über den elektronischen Datenaustausch (EDI) Anlage 3 Vereinbarung über den elektronischen Datenaustausch (EDI) Stadtwerke Haslach Alte Hausacherstraße 1 77716 Haslach zwischen und - nachfolgend die Vertragspartner genannt Seite 1 von 6 1 Zielsetzung

Mehr

SOA Serviceorientierte Architektur Definition, Marktpotenzial und Perspektiven

SOA Serviceorientierte Architektur Definition, Marktpotenzial und Perspektiven SOA Serviceorientierte Architektur Definition, Marktpotenzial und Perspektiven SO A Fraunhofer-Institut für Softwareund Systemtechnik ISST Dr. Ulrich Springer Dr. Bernhard Holtkamp Dortmund, 20.01.2009

Mehr

Anlage 3 zum Lieferantenrahmenvertrag

Anlage 3 zum Lieferantenrahmenvertrag Anlage 3 zum Lieferantenrahmenvertrag Mustervereinbarung über den elektronischen Datenaustausch (EDI) Artikel 1 Zielsetzung und Geltungsbereich 1.1 Die "EDI-Vereinbarung", nachfolgend "die Vereinbarung"

Mehr

Vereinbarung über den elektronischen Datenaustausch (EDI)

Vereinbarung über den elektronischen Datenaustausch (EDI) Vereinbarung über den elektronischen Datenaustausch (EDI) RECHTLICHE BESTIMMUNGEN Die Vereinbarung über den elektronischen Datenaustausch (EDI) wird getroffen von und zwischen: Stadtwerke Konstanz GmbH

Mehr

Vereinbarung über den elektronischen Datenaustausch (EDI)

Vereinbarung über den elektronischen Datenaustausch (EDI) Vereinbarung über den elektronischen Datenaustausch (EDI) RECHTLICHE BESTIMMUNGEN Die Vereinbarung über den elektronischen Datenaustausch (EDI) wird getroffen von und zwischen: Stadtwerken Fröndenberg

Mehr

Cloud Computing in Industrie 4.0 Anwendungen: Potentiale und Herausforderungen

Cloud Computing in Industrie 4.0 Anwendungen: Potentiale und Herausforderungen Cloud Computing in Industrie 4.0 Anwendungen: Potentiale und Herausforderungen Bachelorarbeit zur Erlangung des akademischen Grades Bachelor of Science (B.Sc.) im Studiengang Wirtschaftsingenieur der Fakultät

Mehr

Neue Technologien im elektronischen Geschäftsdatenaustausch (EDI), Trends und Chancen

Neue Technologien im elektronischen Geschäftsdatenaustausch (EDI), Trends und Chancen Neue Technologien im elektronischen Geschäftsdatenaustausch (EDI), Trends und Chancen Alexander Schaefer September 2008 Vorstellung Alexander Schaefer GF Avenum Technologie GmbH erfolgsbildung.at GmbH

Mehr

Vereinbarung über den elektronischen Datenaustausch (EDI) Stadtwerke Heiligenhaus GmbH. Abtskücher Str. 30. 42579 Heiligenhaus

Vereinbarung über den elektronischen Datenaustausch (EDI) Stadtwerke Heiligenhaus GmbH. Abtskücher Str. 30. 42579 Heiligenhaus Vereinbarung über den elektronischen Datenaustausch (EDI) zwischen Stadtwerke Heiligenhaus GmbH Abtskücher Str. 30 42579 Heiligenhaus und - nachfolgend die Vertragspartner genannt Seite 1 von 6 1 Zielsetzung

Mehr

Spezifikationen und Voraussetzung

Spezifikationen und Voraussetzung Projekt IGH DataExpert Yellowbill Adapter Spezifikationen Voraussetzungen Datum : 22.08.2013 Version : 1.0.0.2 22.08.2013 Seite 1 von 7 Inhaltsverzeichnis 1 Einleitung...3 2 Architektur...3 2.1 Grundsätze

Mehr

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

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

Mehr

Vereinbarung über den elektronischen Datenaustausch (EDI)

Vereinbarung über den elektronischen Datenaustausch (EDI) Vereinbarung über den elektronischen Datenaustausch (EDI) Rechtliche Bestimmungen Die Vereinbarung über den elektronischen Datenaustausch (EDI) wird getroffen von und zwischen: Stromversorgung Zerbst GmbH

Mehr

Vereinbarung über den elektronischen Datenaustausch (EDI)

Vereinbarung über den elektronischen Datenaustausch (EDI) Vereinbarung über den elektronischen Datenaustausch (EDI) zwischen und, Ludwigshafener Straße 4, 65929 Frankfurt am Main - im Folgenden die Parteien genannt - 1 Zielsetzung und Geltungsbereich 1.1 Die

Mehr

Vereinbarung über den elektronischen Datenaustausch (EDI)

Vereinbarung über den elektronischen Datenaustausch (EDI) Vereinbarung über den elektronischen Datenaustausch (EDI) RECHTLICHE BESTIMMUNGEN Die Vereinbarung über den elektronischen Datenaustausch (EDI) wird getroffen von und zwischen: Stadtwerke Torgau GmbH,

Mehr

Analyse kritischer Erfolgsfaktoren für Enterprise Social Networking Anwendungen. Bachelorarbeit

Analyse kritischer Erfolgsfaktoren für Enterprise Social Networking Anwendungen. Bachelorarbeit Analyse kritischer Erfolgsfaktoren für Enterprise Social Networking Anwendungen Bachelorarbeit zur Erlangung des akademischen Grades Bachelor of Science (B.Sc.) im Studiengang Wirtschaftswissenschaften

Mehr

Vereinbarung über den Elektronischen Datenaustausch (EDI)

Vereinbarung über den Elektronischen Datenaustausch (EDI) Vereinbarung über den Elektronischen Datenaustausch (EDI) zwischen und Energie- und Wasserversorgung Bruchsal GmbH Schnabel-Henning-Straße 1a 76646 Bruchsal im Folgenden Parteien genannt EDI Stand 10.2009

Mehr

EDI-Rahmenvereinbarung

EDI-Rahmenvereinbarung EDI-Rahmenvereinbarung über den elektronischen Datenaustausch der RECHTLICHE BESTIMMUNGEN - Die Vereinbarung über den elektronischen Datenaustausch (EDI) wird getroffen zwischen: Sandkaule 2 53111 Bonn

Mehr

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

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

Mehr

EDI Richtlinie für Lieferanten. Elektronischer Datenaustausch mit KNV

EDI Richtlinie für Lieferanten. Elektronischer Datenaustausch mit KNV EDI Richtlinie für Lieferanten Elektronischer Datenaustausch mit KNV 1 Inhaltsverzeichnis 1. Vorbemerkung... Seite 3 2. Voraussetzungen... Seite 3 2.1 GLN... Seite 3 2.2 Datenübertragung... Seite 3 2.2.1

Mehr

Vereinbarung über den elektronischen. Datenaustausch (EDI)

Vereinbarung über den elektronischen. Datenaustausch (EDI) Vereinbarung über den elektronischen Datenaustausch (EDI) zwischen: ENA Energienetze Apolda GmbH Heidenberg 52 99510 Apolda und: Name Netznutzer Straße Ort - nachfolgend die Vertragspartner genannt Lfd.

Mehr

Managed File Transfer in der Kunststoffverarbeitenden Industrie

Managed File Transfer in der Kunststoffverarbeitenden Industrie Managed File Transfer in der Kunststoffverarbeitenden Industrie Sichere Alternativen zu FTP, ISDN und E-Mail Verzahnung von Büro- und Produktionsumgebung Verschlüsselter Dateitransfer in der Fertigung

Mehr

DirectInvoiceControl DE. e-invoice Chancen und Risiken

DirectInvoiceControl DE. e-invoice Chancen und Risiken DirectInvoiceControl DE e-invoice Chancen und Risiken Gliederung 1. 2. 3. 4. 5. Rechtliche Grundlagen seit 1. Juli 2011 Welche Regeln müssen beachtet werden? Prozessbeispiele Fazit und Kosten-Nutzen-Bewertung

Mehr

Vereinbarung über den elektronischen Datenaustausch (EDI)

Vereinbarung über den elektronischen Datenaustausch (EDI) Vereinbarung über den elektronischen Datenaustausch (EDI) RECHTLICHE BESTIMMUNGEN Die Vereinbarung über den elektronischen Datenaustausch (EDI) wird getroffen von und zwischen: Lieferant: und Netzbetreiber:

Mehr

Vereinbarung über den elektronischen Datenaustausch (EDI)

Vereinbarung über den elektronischen Datenaustausch (EDI) Vereinbarung über den elektronischen Datenaustausch (EDI) RECHTLICHE BESTIMMUNGEN Die Vereinbarung über den elektronischen Datenaustausch (EDI) wird getroffen von und zwischen: Stadtwerke Weinheim GmbH

Mehr

Anlage 3 zum Lieferantenrahmenvertrag (Gas) EDI-Vereinbarung. Die Vereinbarung über den elektronischen Datenaustausch (EDI) wird getroffen.

Anlage 3 zum Lieferantenrahmenvertrag (Gas) EDI-Vereinbarung. Die Vereinbarung über den elektronischen Datenaustausch (EDI) wird getroffen. Anlage 3 zum Lieferantenrahmenvertrag (Gas) EDI-Vereinbarung RECHTLICHE BESTIMMUNGEN Die Vereinbarung über den elektronischen Datenaustausch (EDI) wird getroffen zwischen Stadtwerke Speyer GmbH Georg-Peter-Süßstraße

Mehr

Vereinbarung über den elektronischen Datenaustausch (EDI)

Vereinbarung über den elektronischen Datenaustausch (EDI) Vereinbarung über den elektronischen Datenaustausch (EDI) zwischen Appenweierer Str. 54 77704 Oberkirch und (Stempel) nachfolgend Vertragspartner genannt Seite 1 von 5 1. Zielsetzung und Geltungsbereich

Mehr

Vereinbarung über den elektronischen Datenaustausch (EDI)

Vereinbarung über den elektronischen Datenaustausch (EDI) Vereinbarung über den elektronischen Datenaustausch (EDI) RECHTLICHE BESTIMMUNGEN Die Vereinbarung über den elektronischen Datenaustausch (EDI) wird getroffen von und zwischen: und ELE Verteilnetz GmbH

Mehr

IHK Veranstaltung 23.11.2007 / einvoicing über EDI

IHK Veranstaltung 23.11.2007 / einvoicing über EDI IHK Veranstaltung 23.11.2007 / einvoicing über EDI Lars Baumann, NEO Business Partners GmbH Kontakt: Lars.Baumann@neo-partners.com Einführung und Nutzenargumentation NEO Electronic Communication einvoicing

Mehr

Stadtwerke Homburg GmbH Lessingstraße 3 66424 Homburg

Stadtwerke Homburg GmbH Lessingstraße 3 66424 Homburg Vereinbarung über den elektronischen Datenaustausch (EDI) RECHTLICHE BESTIMMUNGEN Die Vereinbarung über den elektronischen Datenaustausch (EDI) wird getroffen von und zwischen: Stadtwerke Homburg GmbH

Mehr

Vereinbarung über den elektronischen Datenaustausch (EDI)

Vereinbarung über den elektronischen Datenaustausch (EDI) Vereinbarung über den elektronischen Datenaustausch (EDI) zwischen Energie- und Wasserversorgung Hamm GmbH, Südring 1/3, 59065 Hamm und XXX -nachfolgend "die Parteien" genannt.- Seite 1 von 6 1 Zielsetzung

Mehr

Anlage 3 Vereinbarung über den elektronischen Datenaustausch (EDI)

Anlage 3 Vereinbarung über den elektronischen Datenaustausch (EDI) Anlage 3 Vereinbarung über den elektronischen Datenaustausch (EDI) RECHTLICHE BESTIMMUNGEN Die Vereinbarung über den elektronischen Datenaustausch (EDI) wird getroffen von und zwischen: Stadtwerke Rinteln

Mehr

Vereinbarung über den elektronischen Datenaustausch (EDI)

Vereinbarung über den elektronischen Datenaustausch (EDI) Vereinbarung über den elektronischen Datenaustausch (EDI) RECHTLICHE BESTIMMUNGEN Die Vereinbarung über den elektronischen Datenaustausch (EDI) wird getroffen von und zwischen: Stadtwerke Greven GmbH Saerbecker

Mehr

ET-Connector Produktreihe

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

Mehr

Basistechnologien: Web-Services

Basistechnologien: Web-Services Alexander Rudolf Cloud-Computing Seminar Hochschule Mannheim WS0910 1/29 Basistechnologien: Web-Services Alexander Rudolf Hochschule Mannheim Fakultät für Informatik alexander.rudolf@stud.hs-mannheim.de

Mehr

Supply Chain Management

Supply Chain Management Guntram Wette Supply Chain Management in kleinen und mittleren Unternehmen Können KMU erfolgreich ein SCM aufbauen? Diplomica Verlag Guntram Wette Supply Chain Management in kleinen und mittleren Unternehmen

Mehr

MUSTERVERTRAG. Mustervereinbarung über den elektronischen Datenaustausch (EDI)

MUSTERVERTRAG. Mustervereinbarung über den elektronischen Datenaustausch (EDI) MUSTERVERTRAG Mustervereinbarung über den elektronischen Datenaustausch (EDI) RECHTLICHE BESTIMMUNGEN Die Vereinbarung über den elektronischen Datenaustausch (EDI) wird getroffen von und zwischen: Stadtwerke

Mehr

Client/Server-Systeme

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

Mehr

Vereinbarung über den elektronischen Datenaustausch (EDI)

Vereinbarung über den elektronischen Datenaustausch (EDI) Vereinbarung über den elektronischen Datenaustausch (EDI) RECHTLICHE BESTIMMUNGEN Die Vereinbarung über den elektronischen Datenaustausch (EDI) wird getroffen von und zwischen Gemeindewerke Niefern-Öschelbronn

Mehr

Die Vereinbarung über den elektronischen Datenaustausch (EDI) wird getroffen von und zwischen:

Die Vereinbarung über den elektronischen Datenaustausch (EDI) wird getroffen von und zwischen: Anlage 3: Vereinbarung über den elektronischen Datenaustausch (EDI) RECHTLICHE BESTIMMUNGEN Die Vereinbarung über den elektronischen Datenaustausch (EDI) wird getroffen von und zwischen: Stadtwerke Erkrath

Mehr

Vereinbarung über den elektronischen Datenaustausch (EDI)

Vereinbarung über den elektronischen Datenaustausch (EDI) Vereinbarung über den elektronischen Datenaustausch (EDI) RECHTLICHE BESTIMMUNGEN Die Vereinbarung über den elektronischen Datenaustausch (EDI) wird getroffen von und zwischen: SWN Stadtwerke Northeim

Mehr

Vereinbarung über den elektronischen Datenaustausch (EDI)

Vereinbarung über den elektronischen Datenaustausch (EDI) Vereinbarung über den elektronischen Datenaustausch (EDI) RECHTLICHE BESTIMMUNGEN Die Vereinbarung über den elektronischen Datenaustausch (EDI) wird getroffen von und zwischen: Stadtwerke Schwedt GmbH

Mehr

Vereinbarung über den elektronischen Datenaustausch (EDI)

Vereinbarung über den elektronischen Datenaustausch (EDI) Vereinbarung über den elektronischen Datenaustausch (EDI) zwischen Energiewerke Zeulenroda GmbH Lohweg 8 07937 Zeulenroda-Triebes und nachfolgend die Parteien genannt Seite 1 von 5 Artikel 1: Zielsetzung

Mehr

Anlage 3 zum Lieferantenrahmenvertrag (Gas) gemäß KoV VIII Vereinbarung über den elektronischen Datenaustausch

Anlage 3 zum Lieferantenrahmenvertrag (Gas) gemäß KoV VIII Vereinbarung über den elektronischen Datenaustausch Anlage 3 zum Lieferantenrahmenvertrag (Gas) gemäß KoV VIII Vereinbarung über den elektronischen Datenaustausch RECHTLICHE BESTIMMUNGEN Die Vereinbarung über den elektronischen Datenaustausch (EDI) wird

Mehr

Vereinbarung über den elektronischen Datenaustausch (EDI)

Vereinbarung über den elektronischen Datenaustausch (EDI) Vereinbarung über den elektronischen Datenaustausch (EDI) zwischen Lieferant Straße Hausnummer PLZ Ort Handelsregister und Cofely Deutschland GmbH Geschäftsbereich Energy Services Gletschersteinstraße

Mehr

Datenkonvertierung & EDI

Datenkonvertierung & EDI Cloud Services Datenkonvertierung & EDI Geschäftsprozesse optimieren Ressourcen entlasten Kosten reduzieren www.signamus.de Geschäftsprozesse optimieren Mit der wachsenden Komplexität moderner Infrastrukturen

Mehr

Elektronische Rechnungen Von Rechtsanwalt Dr. Ivo Geis

Elektronische Rechnungen Von Rechtsanwalt Dr. Ivo Geis Elektronische Rechnungen Von Rechtsanwalt Dr. Ivo Geis Die Rechnung ist Kernelement des Mehrwertsteuersystems in Europa, denn sie gilt als Beleg für das Recht des Käufers zum Vorsteuerabzug. Der wachsende

Mehr

Vereinbarung über den elektronischen Datenaustausch (EDI)

Vereinbarung über den elektronischen Datenaustausch (EDI) Vereinbarung über den elektronischen Datenaustausch (EDI) RECHTLICHE BESTIMMUNGEN Die Vereinbarung über den elektronischen Datenaustausch (EDI) wird getroffen von und zwischen: und EWR Netze GmbH Friedrichstr.

Mehr

Vereinbarung über den elektronischen Datenaustausch (EDI)

Vereinbarung über den elektronischen Datenaustausch (EDI) Vereinbarung über den elektronischen Datenaustausch (EDI) RECHTLICHE BESTIMMUNGEN Die Vereinbarung über den elektronischen Datenaustausch (EDI) wird getroffen zwischen: Muster Energie GmbH Musterring 1

Mehr

Vereinbarung über den elektronischen Datenaustausch (EDI) (Stand: 20110101)

Vereinbarung über den elektronischen Datenaustausch (EDI) (Stand: 20110101) Vereinbarung über den elektronischen Datenaustausch (EDI) (Stand: 20110101) RECHTLICHE BESTIMMUNGEN Die Vereinbarung über den elektronischen Datenaustausch (EDI) wird getroffen von und zwischen: und Energie

Mehr

Vereinbarung über den elektronischen Datenaustausch (EDI)

Vereinbarung über den elektronischen Datenaustausch (EDI) Vereinbarung über den elektronischen Datenaustausch (EDI) Die Vereinbarung über den elektronischen Datenaustausch (EDI) wird getroffen von und zwischen: Energieversorgung Filstal GmbH & Co. KG Großeislinger

Mehr

Vereinbarung über den elektronischen Datenaustausch (EDI)

Vereinbarung über den elektronischen Datenaustausch (EDI) Vereinbarung über den elektronischen Datenaustausch (EDI) RECHTLICHE BESTIMMUNGEN Die Vereinbarung über den elektronischen Datenaustausch (EDI) wird getroffen von und zwischen: Stadtwerke Karlsruhe Netzservice

Mehr

Vereinbarung über den elektronischen Datenaustausch (EDI)

Vereinbarung über den elektronischen Datenaustausch (EDI) Vereinbarung über den elektronischen Datenaustausch (EDI) RECHTLICHE BESTIMMUNGEN Die Vereinbarung über den elektronischen Datenaustausch (EDI) wird getroffen von und zwischen: Stadtwerke Vilshofen GmbH

Mehr

Vereinbarung über den elektronischen Datenaustausch (EDI)

Vereinbarung über den elektronischen Datenaustausch (EDI) Vereinbarung über den elektronischen Datenaustausch (EDI) Rechtliche Bestimmungen Die Vereinbarung über den elektronischen Datenaustausch (EDI) wird getroffen von und zwischen: Zwickauer Energieversorgung

Mehr

Vereinbarung über den elektronischen Datenaustausch (EDI)

Vereinbarung über den elektronischen Datenaustausch (EDI) Vereinbarung über den elektronischen Datenaustausch (EDI) RECHTLICHE BESTIMMUNGEN Die Vereinbarung über den elektronischen Datenaustausch (EDI) wird getroffen von und zwischen: Energieversorgung Marienberg

Mehr