Aufbau einer SOA auf Basis des Finanzmanagements von Microsoft Dynamics NAV 2009

Inhaltsverzeichnis

Darstellungsverzeichnis

Abkürzungsverzeichnis

1. Einführung
1.1. Einleitung und Problemstellung
1.2. Zielsetzung und Forschungsfrage
1.3. Vorgehensweise und Methoden
1.4. Konzept zur notwendigen Forschungstiefe

2. Eingliederung in bestehendes Wissen
2.1. Dynamics NAV 2009 aus betriebswirtschaftlicher Sicht
2.1.1 ERP Systeme als Lösung in der Informationswirtschaft
2.1.2 Der Kern des ERP Systems Microsoft Dynamics NAV
2.1.3 Conclusio aus betriebswirtschaftlicher Sicht
2.2. SOA und Dynamics NAV 2009 aus technischer Sicht
2.2.1 Die Dynamics NAV 2009 Systemarchitektur
2.2.2 Weitere SOA Komponenten in der Architektur
2.2.3 Technische Voraussetzungen einer SOA
2.2.4 Conclusio aus technischer Sicht
2.3. SOA aus dynamischer Sicht
2.3.1 Vorgehensmodell
2.3.2 Prozessmodellierung und Aufbau der Servicearchitektur
2.3.3 Anpassung des Vorgehensmodells und Umsetzungsprozesse ..
2.3.4 Conclusio aus dynamischer Sicht
2.4. SOA aus Sicht des Finanzmanagements
2.4.1 Kernfunktionen
2.4.2 Die Mehrwertssteuer und die Vorsteuer
2.4.3 Buchungen in die Haupt- und Nebenbücher
2.4.4 Spezielle Anforderungen in den Nebenbüchern
2.4.5 Teilprozesse im Finanzmanagement
2.4.6 Conclusio im Finanzmanagement
2.5. Conclusio und Antwort auf die Sekundärfrage der Eingliederung

3. Aufbau der Servicearchitektur
3.1. Die Softwarearchitektur
3.1.1 Prozessmodellierung
3.1.2 Unterstützung in der Serviceerstellung
3.1.3 Die Workflow Unterstützung ist die Orchestrierung für REST
3.1.4 Lösung von Kommunikationsanforderungen
3.1.5 Das Application Frontend
3.1.6 Die Ressourcenfreigabe über die REST Schnittstelle
3.1.7 Conclusio und Antwort zur Softwarearchitektur
3.2. Der schnell sichtbare Erfolg
3.2.1 Der schnelle Erfolg richtig durchgeführt
3.2.2 Beachtung des Transaktionsrisikos nach HGB
3.2.3 Maßnahmen zur Behandlung des Transaktionsrisikos
3.2.4 Conclusio und Beantwortung der Frage nach schnellem Erfolg
3.3. Informationsgestaltung und Dokumentation
3.3.1 Eindeutige Kennzeichnung der Anforderungen
3.3.2 Die eindeutige ERP Ressourcenkennzeichnung
3.3.3 Zuordnen der Resourcen und Anforderungen zu den Services .
3.3.4 Informationsgestaltungsprozess anhand des Wechselkurs Beispiels
3.3.5 Conclusio und Antwort auf die Frage nach der Dokumentation .
3.4. Potential für wertschöpfende Services
3.4.1 Die vollständige Überführung der Buchhaltung
3.4.2 Finanzinformationen im Projektmanagement
3.4.3 Conclusio und Antwort auf die Frage nach der Wertschöpfung .
3.5. Die Antwort auf die primäre Forschungsfrage

4. Conclusio

Literaturverzeichnis

Darstellungsverzeichnis

Abbildung 1: Der Weg zur Beantwortung der Forschungsfrage

Abbildung 2: Gründe zur Einführung eines ERP Systems

Abbildung 3: Zusätzliche Serviceaspekte führen zu einer SOA

Abbildung 4: Ursache - Wirkprinzip zur Einführung einer SOA

Abbildung 5: Alternative zur Single ESB Lösung nach Harby

Abbildung 6: Betrachtung der Rückwirkungen auf das ERP System

Abbildung 7: Freigabe von ERP Resourcen als Webservice

Abbildung 8: Design einer für einen Webservice zusammengestellten Datenseite

Abbildung 9: Einheitliche Webservice Schnittstelle zur Codierung in Visual Studio

Abbildung 10: SOA Architektur

Abbildung 11: EPK des SOA Prozesses zur Vermeidung des Transaktionsrisikos

Abbildung 12: Design einer Page für den Wechselkurs Ressourcenzugriff

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1. Einführung

1.1. Einleitung und Problemstellung

Mit der Dynamics NAV Version 2009 hat Microsoft zum ersten Mal für dieses ERP Softwareprodukt die technologische Basis für eine Serviceanbindung dieses ERP Systems geschaffen. Für ein zukunftsweisendes IT System wäre eine serviceorientierte Architektur wünschenswert. Die wichtigste Basis stellt hierfür das Finanzmanagement im ERP System dar. Sebastian Stein und Konstantin Ivanov haben 2007 für die IDS-Scheer ein Vorgehensmodell zur Entwicklung von Geschäftsservices entwickelt. Innerhalb dieses Vorgehensmodelles werden als erste zwei Schritte die „serviceorientierte Geschäftsprozessmodellierung“ und der „Aufbau einer Servicearchitektur“ genannt, welche parallel durchgeführt werden können. Es stellt sich also die Frage wie der Schritt „Aufbau einer Servicearchitektur“ auf Basis des Finanzmanagements angepasst an Dynamics NAV 2009 aussieht, wie eine entsprechende Softwarearchitektur aussehen kann und ob sich Microsoft Dynamics NAV 2009 für den Aufbau einer serviceorientierten Architektur eignet.

1.2. Zielsetzung und Forschungsfrage

Ziel dieser Arbeit ist es, ausgehend von einem Vorgehensmodell von IDS Scheer den Schritt des Aufbauens einer Servicearchitektur an die Eigenheiten von Microsoft Dynamics NAV 2009 anzupassen und anhand des Finanzmanagements zu betrachten. Gleichzeitig soll dabei bereits in diesem ersten Schritt Rücksicht auf die lt. IDS Scheer später zu erfolgenden Schritte in der Informatik genommen werden. Hierfür wird eine erste Vorstellung einer Softwarearchitektur auf Basis von Dynamics NAV 2009 benötigt. Zusätzlich wünschenswert wäre auch die Erzeugung eines sofortigen Mehrwertes um die Akzeptanz eines möglichen Projektes zu steigern. Aus dieser Zielsetzung ergibt sich daher die folgende Forschungsfrage.

Wie sieht der Aufbau einer Servicearchitektur, als parallel zur Geschäftsprozessmodellierung durchführbarer Schritt, in einem ersten Teilbereich des Finanzmanagements von Microsoft Dynamics NAV 2009 aus?

Diese Forschungsfrage beinhaltet mehrere wichtige Teilaspekte aus unterschiedlichen Wissensgebieten. Die Frage nach der Servicearchitektur kommt aus dem Fachbereich der Informatik. Das Kernwissen über das Finanzmanagement vom ERP System Microsoft Dynamics NAV 2009 kommt aus der Betriebswirtschaft. Zur Beantwortung der Frage wie der erste Schritt aussehen kann, muss die bei der Einführung entstehende Dynamik in einem bestehenden Unternehmen betrachtet werden und die Belegschaft aktiv und richtig in das Vorhaben eingebunden werden, um sie auf dem Weg nicht zurückzulassen. Der Weg zur Beantwortung der Forschungsfrage stützt sich damit auf die Beantwortung von Teilfragen aus diesen drei Wissensgebieten wie die folgende Darstellung verdeutlicht.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Der Weg zur Beantwortung der Forschungsfrage Quelle: Eigene Ausarbeitung

Um die Forschungsfrage ausreichend beantworten zu können müssen folgende Sekundärfragen aus diesen drei Wissensgebieten beantwortet werden.

Wie gliedert sich diese Forschungsarbeit in bestehendes Wissen ein?

Warum bietet das Finanzmanagement Potential für wertschöpfende Services zur Erhöhung der Unternehmensflexibilität?

Gibt es im Finanzmanagement eine Möglichkeit einen schnell sichtbaren Erfolg zur Erhöhung der Akzeptanz eines SOA Vorhabens zu erreichen?

Warum eignet sich Microsoft Dynamics NAV 2009 aus Softwarearchitektursicht zur Einführung einer SOA (nicht?) und wie sieht eine entsprechende Softwarearchitektur zur Integration aus?

Wie werden die benötigten Informationen für die Informatik und für die Geschäftsprozessmodellierung anhand eines Beispiels am besten zur Verfügung gestellt?

1.3. Vorgehensweise und Methoden

Ein Großteil der Forschungsarbeit wird über eine Literaturrecherche geleistet. Dabei muss aktuelle systemunabhängige Literatur über serviceorientierte Architekturen mit Literatur und Wissen über Microsoft Dynamics NAV 2009 im Speziellen und die Softwareerstellung mit Microsoft Produkten im Allgemeinen zusammengebracht werden. Aus dieser übergreifenden Betrachtungsweise sollen Schlüsse für die Beantwortung der Forschungsfrage gezogen werden.

Um eine klar nachvollziehbare Argumentation zu gewährleisten wird im Aufbau dieser Arbeit jedes Kapitel oder Unterkapitel am Schluss mit einer Conclusio, die sich auf das jeweilige Kapitel oder Unterkapitel bezieht, geschlossen.

1.4. Konzept zur notwendigen Forschungstiefe

Zur Beantwortung der Fragen bietet sich das statistische Pareto Prinzip an (vgl. PMBOK 2008, S. 211). Dies bedeutet sowohl in den betriebswirtschaftlichen Fragestellungen, als auch für die Beantwortung der Fragestellung zur Vorgehensweise lassen sich die notwendigen 80% für das Ergebnis mit 20% Aufwand gut abdecken. In der Informatik stolpert ein Vorhaben aber oft über jene restlichen 20%, die nicht mehr betrachtet wurden. So kommt es immer wieder vor, dass aus einer Beschreibung eines Features einer bestimmten Software geschlossen wird, dass die Anforderungen erfüllt sind. Diese Annahme ist oft falsch und lässt viele Vorhaben scheitern. Die bessere Vorgehensweise für diese Arbeit ist daher der Weg zurück zur Quelle, welche im Fall der Informatik die Programmierbarkeit mit einer universell einsetzbaren, objektorientierten Programmiersprache wie C# darstellt (vgl. Bayer 2008, S. 231). Ab dem Moment an dem ein Informatiker grundsätzlich alle Möglichkeiten hat und die Spezifikation in einer solchen Programmiersprache implementieren kann, lässt sich dann auch argumentieren, dass damit grundsätzlich auch alle Anforderungen erfüllbar sind. Hierfür muss dann die aufwändige Programmierarbeit nicht mehr durchgeführt werden, da diese zur Beantwortung der Fragestellung keinen nennenswerten Beitrag mehr leistet. Der Weg zum Ziel ist in der Informatik also eine Rückführung auf die Programmierung und eine bestmögliche Unterstützung der Informatiker zur Reduktion der Aufwände.

2. Eingliederung in bestehendes Wissen

2.1. Dynamics NAV 2009 aus betriebswirtschaftlicher Sicht

2.1.1 ERP Systeme als Lösung in der Informationswirtschaft

„Die Unternehmensführung hat die Aufgabe, den Prozeß der betrieblichen Leistungserstellung und -verwertung so zu gestalten, daß das (die) Unternehmensziel(e) auf höchstmöglichem Niveau erreicht wird (werden).“ (Wöhe 2005, S. 62)

Eine wichtige Funktion jeder Unternehmensführung besteht darin, mit Informationen im Unternehmen so umzugehen, dass dies zum langfristigen Erfolg des Unternehmens führt. Informationen sollen den Prozess der Leistungserstellung und den Managementprozess bestmöglich unterstützen (vgl. Wöhe 2005, S. 64). Man spricht bei diesem Kernbereich der Betriebswirtschaft auch von der Informationswirtschaft (vgl. Wöhe 2005, S. 193).

Damit Informationen ihren vollen Nutzen entfalten können, muss ein zugehöriges Informationssystem sowohl vertikal als auch horizontal in der Organisationsstruktur vollintegriert sein (vgl. Wöhe 2005, S.199). In einem vollintegrierten Informationssystem sind die Kosten durch manuelles Übertragen zwischen redundanten Systemen minimiert. Die Nachfrage nach einem solchen Informationssystem kann durch eine Unternehmenssoftware alleine nur teilweise gelöst werden. Dies hat bisher oft zum Einführen diverser Middleware Produkte zur Verbindung diverser Systeme geführt (vgl. Starke 2007, S. 127 - S.129).

Mit steigender Anzahl von Middleware Produkten und durch das Fortschreiten der IT Technologien sind diese Produkte miteinander oft nicht mehr kompatibel. All diese Anforderungen haben zur Entwicklung von möglichst umfassenden ERP Systemen geführt. ERP Systeme sollen durch die Abbildung von standardisierten Geschäftsprozessen in einer möglichst umfassenden und durch Programmierung auch vom Kunden anpassbaren Software Redundanzen vermeiden und damit zur Rationalisierung im Unternehmen beitragen.

„Als Enterprise Ressource Planning (ERP) bezeichnet man bereichsübergreifende Softwarelösungen, die die operativen Prozesse steuern und auswerten.“ (Wöhe 2005, S. 201)

Die Gründe zur Einführung eines ERP Systems spielen auch bei der Einführung einer SOA wieder eine essentielle Rolle.

„Eine serviceorientierte Architektur (SOA) ist eine Unternehmensarchitektur, deren zentrales Konstruktionsprinzip Services (Dienste) sind. Dienste sind klar gegeneinander abgegrenzte und aus betriebswirtschaftlicher Sicht sinnvolle Funktionen. Sie werden entweder von einer Unternehmenseinheit oder durch externe Partner erbracht.“ (Starke 2007, S. 12)

Mit der folgenden Diagrammart werden in dieser Forschungsarbeit Ursache - Wirkungsprinzipien bis zur Entwicklung einer SOA erarbeitet, wie im Folgenden anhand bestehender Gründe aus dem ERP System dargestellt. Selbstverständlich können auch noch weitere hier nicht angeführte Gründe eine Rolle spielen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Gründe zur Einführung eines ERP Systems Quelle: Eigene Ausarbeitung

Für eine Vollintegration muss ein ERP System nicht nur betriebliche Prozesse und damit betriebswirtschaftliches Wissen mitbringen sondern auch diese Prozesse an die Organisation anpassen. Die Vollintegration wird erst erreicht wenn das ERP System zusammen mit Spezialapplikationen integriert werden kann, insbesondere wenn die zugehörigen Spezialprozesse außerhalb des ERP Systems ablaufen. Genauso muss es auch möglich sein unternehmensexterne Informationsquellen zu integrieren. Eine Lösung hierfür lautet SOA.

In der Praxis wird oft das ERP System solange erweitert, bis es viele der Spezialapplikationen durch proprietäre Schnittstellen integriert. Das ERP System ist dadurch aber nicht automatisch serviceorientiert, da oftmals essentielle Bestandteile wie das Konstruktionsprinzip der Dienste nicht enthalten sind. Zudem steuert das Unternehmen auf eine absolute IT Lieferantenabhängigkeit vom ERP Dienstleister zu und nimmt damit alle Nachteile eines solchen Single Sourcing Konzeptes auf sich (vgl. Schulte 2009, S. 288). Im Endstadium eines solchen Szenarios sind die ablaufenden Prozesse im Gesamtüberblick oft nur noch vom ERP Dienstleister zu durchblicken. Das Unternehmen ist in einem solchen Fall von der ERP Unternehmensberatung vital abhängig.

Anstatt die Prozesse dem ERP Dienstleister zu überlassen, sollte ein Unternehmen die Prozesse aktiv analysieren und modellieren. Die Prozessmodellierung ist sowohl ein wichtiges Kommunikations- und Dokumentationswerkzeug in Form leicht zu verstehender Diagramme, als auch ein wichtiges Instrument zum Controlling der Durchlaufzeiten im Unternehmen. Ein weiterer Vorteil dieser Methode ist, dass regelmäßig zur Umsetzung oder Verbesserung der Prozesse neue technologische Möglichkeiten erfasst werden und ökonomische, ökologische sowie soziologische Chancen und Risiken einfließen können. Die Prozesse werden einem kontinuierlichen Verbesserungsprozess unterstellt, in den auch das Marketing im Sinne der marktorientierten Unternehmensführung direkt Einfluss nehmen kann und soll. Wertvolle Unternehmensprozesse sind kundenorientiert. Das Ursache - Wirkungsgefüge auf dem Weg zur SOA kann um diese zusätzlichen Aspekte erweitert werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Zusätzliche Serviceaspekte führen zu einer SOA Quelle: Eigene Ausarbeitung

2.1.2 Der Kern des ERP Systems Microsoft Dynamics NAV 2009

Da ERP Systeme den Anspruch erheben in möglichst allen Unternehmen wie z.B. Handelsbetrieben, Fertigungsbetrieben oder auch Dienstleistungsbetrieben optimal die Leistungserstellung zu unterstützen, passt der Gesamtleistungsumfang einer solchen Software nie auf ein einzelnes Unternehmen. Das ERP System Dynamics NAV 2009 löst dies durch einen modularen Aufbau des gesamten Systems. (vgl. Luszczak 2009, S. 19)

Werden die Gemeinsamkeiten der so unterschiedlichen Unternehmen betrachtet, so kristallisieren sich einige Kernmodule heraus. Die Kernprozesse aus den Bereichen Verkauf, Finanzmanagement, Einkauf und Lagerlogistik werden von sehr vielen Unternehmen benötigt und werden folglich auch als Dynamics NAV 2009 Standard oder auch als Grundsystem bezeichnet (vgl. Luszczak 2009, S. 19-20). Die Lagerlogistik bettet sich dabei in das Supply Chain Management Modul ein, um den modernen Aspekt, ein Unternehmen nicht für sich alleine zu betrachten, gerecht zu werden (vgl. Schulte 2009, S.13- 17).

„Als Ergänzung zum Dynamics NAV-Grundsystem stehen zudem zahlreiche zertifizierte Zusatz- und Branchenlösungen von Microsoft-Partnerunternehmen zur Verfügung, die nahtlos in das Standardsystem integriert sind und die spezifischen Anforderungen einzelner Branchen bereits im Standard abbilden.“ (Luszczak 2009, S. 19-20)

Hinsichtlich einer SOA ist die mit Dynamics NAV 2009 im Systemkern neu eingeführte Webservice Unterstützung von besonderem Interesse (vgl. Roys 2008, S. 312-322).

„Webdienste stellen eine weit verbreitete Standard-Schnittstelle für die reibungsfreie Kommunikation zwischen IT-Systemen dar. Mithilfe der Webdienste können externe Systeme auf Funktionen der Anwendungslogik zugreifen, die am Dynamics NAV-Server ausgeführt wird - beispielsweise zur Anbindung fremder ERP-Systeme. Im Gegensatz zu direkten Datenbankzugriffen erfolgt bei der Nutzung von Webdiensten dieselbe Prüfung von Eingabefehlern, Datenintegrität und Berechtigungseinstellungen wie bei der manuellen Dateneingabe in einer Seite von Dynamics NAV.“ (Luszczak 2009, S. 26)

Der unterstützte Prozessumfang von Dynamics NAV 2009 ist ideal für Unternehmen in der Größe von Klein- und Mittelbetrieben. Große Unternehmen und internationale Großkonzerne verwenden gerne Microsoft Dynamics AX oder SAP. Eine SOA für Dynamics NAV 2009 sollte dies berücksichtigen und sowohl finanziell als auch im Implementierungsumfang klein starten können.

2.1.3 Conclusio aus betriebswirtschaftlicher Sicht

Eine Integration mit monolithisch aufgebauten Softwareapplikationen ist denkbar schwierig bis unmöglich. Da nur vollintegrierte Informationssysteme die Probleme in der Informationswirtschaft lösen können und Dynamics NAV 2009 durch seinen modularen Aufbau sowohl die vertikale als auch die horizontale Integration bestmöglich unterstützt, ist Dynamics NAV 2009 eine denkbare betriebswirtschaftliche Lösung für das Informationsmanagement von Klein- und Mittelbetrieben. Durch die neu eingeführte Webservice Unterstützung ist dieses ERP System eine funktionierende Basis für eine SOA. Als Ergebnis einer Prozessmodellierung ergeben sich mit einer SOA neue Möglichkeiten wie z.B. mobiler Zugriff oder Integration von Geschäftspartnern.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Ursache - Wirkprinzip zur Einführung einer SOA Quelle: Eigene Ausarbeitung

Die vorliegende betriebswirtschaftliche Conclusio stützt sich an dieser Stelle in den technischen Aspekten auf grundlegende Features aus einer Literaturrecherche zu Microsoft Dynamics NAV 2009. Gemäß dem eingeführten Konzept zur Forschungstiefe müssen die technischen Aspekte bis auf die Ebene der Programmierung betrachtet werden, um zu einer technischen Conclusio zu gelangen.

2.2. SOA und Dynamics NAV 2009 aus technischer Sicht

2.2.1 Die Dynamics NAV 2009 Systemarchitektur

In modernen Datenbanksystemen ist die Grundlage zur Integration über Rechner- und Systemgrenzen hinweg ein Dreischichtenmodell als Softwarearchitektur. Bei jedem Integrationsgedanken darf nicht außer Acht gelassen werden, dass die Geschäftslogik eines Datenbanksystems eingehalten werden muss und daher nicht umgangen werden darf. Um auch die Rechnergrenzen überwinden zu können, werden Transportebenen zwischen den drei Schichten für die Datenspeicherung, die Geschäftslogik und die Darstellung benötigt. (vgl. Geisler 2007, S. 75-79)

Die Geschäftslogik definiert Dynamics NAV 2009 durch die im ERP System integrierten Prozesse. Für ein konsistentes sicheres System ist es daher unbedingt erforderlich, dass dies der einzige Ort bleibt, an dem diese Geschäftslogik des ERP Systems vorzufinden ist. Jede andere Vorgehensweise führt zu höheren Aufwänden beim Dienstleistungspartner und im Betrieb.

Dynamics NAV 2009 stellt mit dieser neuen Version einen in das Produkt integrierten Mechanismus zur Verfügung, um Funktionen und Daten der Geschäftslogik über Webservices zu veröffentlichen. Die Dynamics NAV 2009 Systemarchitektur basiert dabei auf vielen von der Microsoft Visual Studio Programmierumgebung direkt unterstützten Technologien. Die Web Service Description Language (WSDL) beschreibt die Schnittstelle (vgl. W3C WSDL 2001). Das Simple Object Access Protokoll (SOAP) dient zum Datenaustausch (vgl. W3C SOAP 2000). Dieses verwendet intern das Internet - Transportprotokoll HTTP (vgl. NWG RFC 2616 1999). Zur Registrierung und Suche nach Diensten wird der Universal Description, Discovery and Integration (UDDI) Standard verwendet (vgl. OASIS 2010). Die beschriebenen Standards basieren auf dem „Extensible Markup Language“ (XML) Standard (vgl. W3C XML 2008). Dieser stellt sicher, dass die Daten von Maschinen und Menschen leicht gelesen werden können (vgl. Bayer 2008, S. 1031). Der Stapel an angeführten frei verfügbaren Technologien ist ein Standbein für den Aufbau dieser SOA (vgl. Starke 2007, S. 489-490).

Mit Microsoft Windows Vista wurde auch ein neues Programmiermodell inkl. API namens .NET Framework für die Programmierung veröffentlicht, um unter anderem die neuen Funktionalitäten mit XML und die Verwendung von Webservices für die Windows Programmierung zu vereinfachen (vgl. Starke 2007, S. 551). „Wenn Sie z.B. mit Visual Studio einen Webdienst referenzieren (über eine Webdienst-Referenz), liest Visual Studio das zu dem Webdienst gehörende WSDL-Dokument aus und erzeugt daraus eine Proxy-Klasse, die die Regeln des Datenvertrags einhält.“ (Bayer 2008, S. 1019)

Der Proxy ist ein Stück einer Software, der als Vermittler dient. Im obigen Fall, der Webservice Technologie, vermittelt dieser Proxy zwischen der objektorientierten Programmierung der Klassen im .NET Framework und dem ERP Gegenpartner über das Internet, sodass die Programmierung vereinfacht wird und die darunterliegende Technologie gekapselt, also verdeckt wird.

„Der etwas abstrakte Begriff »Datenvertrag« (Data contract) gehört zu dem Programmiermuster »Contract First Design«. Dieses Programmiermuster erleichtert den Datenaustausch zwischen zwei Systemen. Dabei wird vor der eigentlichen Programmierung ein »Vertrag« erstellt, der bestimmt, wie die Daten ausgetauscht werden.“ (Bayer 2008, S. 1019)

Als Mapping wird das nach Möglichkeit verlustfreie Umsetzen der softwareinternen Darstellung einer Information, welche in Form verschiedener Datentypen vorliegen kann, bezeichnet.

„SOAP ist ein spezieller XML-Dialekt, der in Zusammenhang mit Webdiensten verwendet wird.“ (Bayer 2008, S. 1015)

[...]