Serviceorientierte Architektur

Das Prinzip der serviceorientierten Architektur (SOA) basiert auf einer bestimmten Aufteilung der Programmlogik, die nicht mehr Bestandteil einzelner Programme ist, sondern über mehrere Services verteilt wird. Programme werden so einzeln und unabhängig voneinander definiert.

Allgemeine Informationen zum Thema[Bearbeiten]

Wie bei einer allgemeingültigen Programmiersprache kann man auch mit SOA auf einzelne Module zugreifen und diese miteinander verbinden, solange alle Hersteller das gleiche Sechs-Schichten-Modell verwenden. Dahinter steht der Wunsch nach Vereinfachung der IT-Systemlandschaft im Zusammenhang mit den betrieblichen Prozessen. Wenn die Schnittstellen vorhanden sind, können einmal erstellte Funktionen oder Abläufe immer wieder als Programmierbausteine verwendet werden.

Man kann sich SOA ein wenig wie das Zusammenspiel von Browser und Webserver vorstellen. Durch SOA lassen sich neue Systeme aufbauen und als Bestandteil der bestehenden IT nutzen. SOA kommt insbesondere zum Einsatz, wenn Vorhaben wie Datenintegrationsplattformen Modernisierungs- oder Migrationsprojekte, Output-Management oder die Stammdatenverwaltung optimiert werden sollen. Dabei sollen mit Hilfe der serviceorientierten Architektur die Datenqualität verbessert und eine Zeit- und Kostenersparnis realisiert werden[1].

Vorteile und Nachteile der serviceorientierten Architektur[Bearbeiten]

Durch serviceorientierte Architektur lassen sich Unternehmensprozesse in die Software integrieren, was einen klaren Vorteil darstellt. Vergleichbar mit einem Puzzle lassen sich Einzeldienste zu übergeordneten Einheiten zusammenfügen, sodass sich komplexe Aufgabenstellungen bewerkstelligen lassen. Meist ist die Benutzeroberfläche übersichtlich gestaltet und leicht zu handhaben, die Dienste als solche laufen in der Regel über Webclients, einzelne Verknüpfungen und Zusammenhänge bleiben vor den User im Verborgenen.

Die Nachteile von SOA lagen in der Vergangenheit im wesentlichen bei der Arbeit im Vorfeld. Damit die Software erfolgreich modelliert werden kann, müssen zuvor die Unternehmensprozesse genau definiert werden. Das führt zu einem erheblichen Mehraufwand im Vorfeld und beeinträchtigt die Effizienz der SOA, die ja eigentlich dazu gedacht ist, den manuellen Aufwand zu reduzieren.

Das gezeichnete Bild des Puzzles eignet sich auch, um eine weitere Problematik zu verdeutlichen. Denn wie bei einem Puzzle mit vielen Teilen muss auch bei der SOA jedes Teil zum anderen passen, das Zusammenfügen über die Schnittstellen muss also in jedem Fall bis ins Detail genauso gelingen, wie es notwendig ist. Kommt es hier zu kleinen Fehlern, kann es sein, dass der funktionierende Datenaustausch nicht mehr gewährleistet werden kann. Wird die serviceorientierte Architektur im Zusammenspiel mit einem ERP-System angewendet, geht durch diesen Nachteil eine wesentliche Funktion verloren, nämlich die umfassende Transparenz.

Bleibt die Fehlersuche, die sich nachteilig bei einer SOA auswirken kann. Wenn es zu Fehlern kommt, gestaltet sich die Suche nach der Ursache oft schwierig. Damit einher geht erneut Zeitverlust und manuelle Arbeit, die man sich eigentlich ersparen wollte[2].

Grafische Darstellung der Funktionsweise von SOA[Bearbeiten]

Trotz der beschriebenen Nachteile der serviceorientierten Architektur ist das dahinterstehende Prinzip im Sinne der Nutzer. Denn bevor SOA entwickelt wurde, waren die IT-Landschaften durch unterschiedliche Anwendungen geprägt, die häufig dazu führten, dass Anwendungen - und seien sie noch so sauber aufgebaut –nicht für andere Zwecke eingesetzt werden konnten. Der Grund ist in der Tatsache zu suchen, dass die meisten Projekte nicht zur Wiederverwendung entwickelt werden.

Das liegt daran, dass die Entwicklung entsprechender Komponenten nur schwer zu planen und sehr aufwendig ist. Es kommt sogar immer wieder vor, dass innerhalb eines Projektes Anwendungsteile verworfen werden, weil die zeitlichen Vorgaben zu eng sind. So wird selbst die Wiederverwendung innerhalb einer Anwendung problematisch oder unmöglich, was zu Redundanzen bei den Anwendungslandschaften führt. In der Folge kommt es zu aufwendigen Wartungen, später durchgeführte Neuentwicklungen und Änderungen verlieren an Effizienz.

SOA beim Online-Handel[Bearbeiten]

Die serviceorientierte Architektur kommt häufig beim Online-Handel zum Einsatz. So wird beispielsweise die Bestellung eines Produkts über einen Service spezifiziert, der seinerseits mit dem Bestands-Service kommuniziert und übermittelt bekommt, ob der bestellte Artikel verfügbar ist. Liefer- und Bestelldetails werden über einen weiteren Service abgewickelt, ein zusätzlicher Service ist für den Versand und die Sendungsnummer zuständig. Der gesamte Kaufprozess wird also durch unterschiedliche Services abgewickelt, die miteinander in Kontakt stehen. Die Basis für diese Art der Auftragsbearbeitung bildet die serviceorientierte Architektur[3].

Bedeutung für das Development[Bearbeiten]

Um unternehmensinterne Prozesse zu optimieren, kann die serviceorientierte Architektur sinnvoll und sogar wichtig sein, wie im Beispiel Online-Handel deutlich wurde. Dennoch ist im Vorfeld eine gewissenhafte und genaue Vorbereitung auf das neue System notwendig, um spätere Fehler zu vermeiden. Je nach Branche und Komplexität der firmeninternen Prozesse kann SOA erhebliche Wettbewerbsvorteile bedeuten.

Einzelnachweise[Bearbeiten]

  1. Was ist eigentlich eine Serviceorientierte Architektur techchannel.de. Abgerufen am 16.11.2017
  2. SOA – Serviceorientierte Architektur erp-infoportal.de. Abgerufen am 16.11.2017
  3. definition serviceorientierte architektur soa searchentprisesoftware.de. Abgerufen am 16.11.2017

Weblinks[Bearbeiten]