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

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)

2.2.2 Weitere SOA Komponenten in der Architektur

„In einer SOA müssen Services koordiniert ablaufen und bei Bedarf weitere Services aufrufen können. Hierzu wird häufig das Konzept des >>Service Bus<< (oder auch Enterprise Service Bus, ESB) in den Mittelpunkt gestellt. Ein ESB vernetzt dabei sämtliche technische Beteiligte einer SOA. Möchte ein Servicenutzer mit einem Service-Provider in Kontakt treten, so übernimmt der ESB die gesamten Details der Kommunikation – inklusive notwendiger Zusatzleistungen.“ (Starke 2007, S.34)

Für die Kommunikation mit Services kann im .NET Framework auch die Windows Communication Foundation verwendet werden.

„Mit der Windows Communication Foundation (WCF) wird die zukünftige Technologie für serviceorientierte Architekturen in der Windows-Welt, aufbauend auf der Microsoft-.NET-Plattform, angeboten. Gleichzeitig werden mit der WCF die verschiedenen Microsoft APIs zur Realisierung verteilter Anwendungen zu einem einheitlichen Programmiermodell konsolidiert.“ (Starke 2007, S. 551, korrigiert)

Dem Konzept zur Forschungstiefe folgend fehlt noch die Möglichkeit, den Programmierer in seiner Arbeit über modellgetriebene Entwicklungsansätze zu unterstützen und damit den Entwicklungsprozess zu verbessern (vgl. Kühne 2006, S. 1-2). Bei Verwendung des ESB steht hierzu meist eine Möglichkeit der Orchestrierung, einer graphischen Darstellung und Definition der Serviceabläufe, zur Verfügung.

Für das graphische Definieren von Abläufen hat Microsoft mit der Windows Workflow Foundation (WF) eine Möglichkeit entwickelt, die Programmierer direkt in Visual Studio zu unterstützen ohne ihnen dabei die Möglichkeiten der Programmierung zu nehmen. So können die Ereignisfunktionen über Eigenschaften der Workflowaktivitäten wie Condition und Execute Code beim Erzeugen eines Workflows hinterlegt werden. (vgl. Scribner 2007, S. 17-27)

„Microsoft hat die Notwendigkeit für eine stärkere Betriebssystemunterstützung im Hinblick auf die Koordinierung von Prozessen innerhalb Firmen erkannt und eine phantastische Funktionalität in das Betriebssystem Windows Vista eingebaut – die Windows Workflow Foundation, kurz WF.“ (Scribner 2007, S. 4)

Von Visual Studio und in Zukunft auch von der WF werden nach dem Hinzufügen der Referenzen und Servicereferenzen zum Workflowprojekt die Metadaten automatisch analysiert (vgl. Bayer 2008, S. 83). Dabei werden aus dem Servicevertrag automatisch entsprechend angepasste Aktivitäten erzeugt, die in der Workflowmodellierung verwendet werden können (vgl. MSDN WF4 2009). Microsoft entwickelt im Zuge von .NET 4.0 die WCF und die WF in Richtung Webservice – Unterstützung weiter. Die SOA Investition ist also technologisch gesehen zukunftsgeschützt und wird von Microsoft erweitert (vgl. MSDN .NET4 2010).

Neben diesen neuen Möglichkeiten mit Dynamics NAV 2009 gibt es auch bereits in älteren Versionen von Dynamics NAV die Möglichkeit Dynamics NAV über einen Adapter namens Commerce Gateway an Microsoft BizTalk anzubinden. Diese Anbindung über diesen Adapter funktioniert allerdings ausschließlich mit dem BizTalk Server. Der BizTalk Server stellt alle für eine SOA notwendigen Technologien, wie einen ESB und eine Möglichkeit zur Orchestrierung, zur Verfügung. Im BizTalk Server sind darüberhinausgehende typische Möglichkeiten eines Middleware–Produktes zur Anbindung diverser Systeme und Protokolle enthalten. Die Commerce Gateway Anbindung kommt aus einer Zeit, als Dynamics NAV 2009 auf einer zweischichtigen Architektur aufgebaut war. Diese Anbindung enthält im ERP System entsprechend ausprogrammierte E-Commerce Mechanismen, um die Geschäftsdokumente vor allem aus den Einkaufs- und Verkaufsprozessen mit dem BizTalk Server auszutauschen. Da die Lösung ausschließlich auf den BizTalk Server abzielt, aber vor allem für den Transport der Daten noch zusätzliche proprietäre Technologien wie der Commerce Gateway Broker benötigt werden, zählt diese B2B Anbindung eher zu den Middleware Lösungen mit speziellem Fokus auf den elektronischen Handel, als dass sie der Vision dieser Forschungsarbeit gerecht wird.

„WF kann durchaus in einer Interapplication-Workflow-Konstellation eingesetzt werden, aber dies erfordert zusätzliche Programmlogik und –strukturen, die BizTalk von Haus aus zur Verfügung stellt. Tatsächlich ist das BizTalk-Programmiererteam dabei, den BizTalk-Programmkern auf WF umzustellen, sodass die Microsoft-Produkte in Zukunft auf einer einheitlichen Workflow-Technologie basieren.“ (Scribner 2007, S. 6)

2.2.3 Technische Voraussetzungen einer SOA

Wenn es um die technischen Voraussetzungen einer SOA geht, so ergibt sich eine interessante literarische Diskussion. Roys sieht im Kontext von Dynamics NAV 2009 die neue Serviceanbindung als einen wichtigen Schritt, erachtet aber vier fehlende Abstraktionen für eine SOA als notwendig. Diese sind ein Application Frontend, der Service, ein Service Repository und der Service Bus. (vgl. Roys S. 358)

Mit Ausnahme des ESB sind dabei die Komponenten Services, Application Frontend und UDDI Service Repository mit dem Windows Server und dem ERP System bereits vorhanden. Der ESB wird von Harby als Single Sourcing Konzept kontrovers diskutiert. Harby stellt als Alternative die Service Registry ins Zentrum der Betrachtung. Diverse Service Bus Lösungen können bei Bedarf flexibel nachgerüstet werden wie folgendes Diagramm darstellt. (vgl. Harby 2006)

Abbildung in dieser Leseprobe nicht enthalten

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

Quelle: Harby 2006: ESB Alternative

In eine andere Richtung gedacht sieht Roys das einheitliche Schnittstellenkonzept von Dynamics NAV 2009 zum Zugriff auf die Dynamics NAV Ressourcen über WebServices als unzureichend für eine SOA an (vgl. Roys S. 358). Genau dieses einheitliche Schnittstellenkonzept zum vollständigen Zugriff auf alle Ressourcen stellt aber ein wichtiges Kriterium der „Representational State Transfer“, abgekürzt REST, Architekturalternative dar (vgl. Starke 2007, S. 394). Das Internet basiert auf dieser einfachen Architektur. REST ist ein wichtiges Erfolgskriterium für die schnelle Akzeptanz des Internets. Mit REST werden sämtliche Ressourcen des ERP Systems über eine einheitliche Schnittstelle eingefügt, gelesen, bearbeitet, gelöscht und dabei über die Geschäftslogik geprüft. Ein Prozess kann über einen parameterlosen Funktionsaufruf, also ähnlich dem Klicken auf einen Hyperlink im Internet, angestoßen werden. Dieses Prinzip ist also bestens bekannt und akzeptiert.

[...]