Serviceorientierte Architektur (SOA)
Aus ControllingWiki
Achtung. Sie nutzen eine nicht mehr unterstützte Version des Internet Explorer. Es kann zu Darstellungsfehlern kommen. Bitte ziehen Sie einen Wechsel zu einer neueren Version des Internet Explorer in Erwägung oder wechseln Sie zu einer freien Alternative wie Firefox.Inhaltsverzeichnis
Zusammenfassung
Serviceorientierte Architekturen (SOA) bieten Unternehmen einen Lösungsansatz, ihre Geschäftsprozesse schneller und dynamischer an die sich verändernden Rahmenbedingungen des national und international härter werdenden Wettbewerbs anzupassen. Das Konzept der SOA gilt als IT-Architektur der Zukunft. Das Ziel der SOA besteht darin, reale Geschäftsabläufe in bewegliche Softwaremodule zu übersetzen und intelligent zu verknüpfen. Ergebnis ist eine extrem flexible Architektur mit beträchtlichem Potenzial an Kostenminimierung und Prozessoptimierung. Der Hauptvorteil einer SOA liegt in der modularen Ausrichtung der IT-Architektur, die von konkreten Prozessen im Unternehmen ausgeht und sie realitätsgerecht in einzelnen, wieder verwendbaren Bausteinen abbildet.
Aufbau und Zielsetzung von Serviceorientierten Architekturen
Das Konzept der SOA ermöglicht die Ausrichtung der Infrastruktur des Unternehmens an den Geschäftsprozessen sowie die Möglichkeit der schnellen Anpassung der Infrastruktur an die Veränderungen im Geschäftsumfeld. Bei den SOAs handelt es sich nicht um eine Technologie oder ein Softwareprodukt, sondern um ein technologieunabhängiges Architekturkonzept, das Softwarearchitekturen flexibler macht und hierdurch die Verwendung bereits bestehender Komponenten unterstützt. Diese Komponenten können mit unterschiedlichen Technologien entwickelt worden sein. Die durch SOA entstehende Architektur bestimmt die Funktionen einzelner Komponenten im Gesamtsystem. Kernprinzip ist der Aufbau von Softwaresystemen aus vorher lose gekoppelten Services. Ein Service ist bei SOA eine Softwarekomponente, die eine bestimmte, klar umrissene Funktion verrichtet. Ein Service könnte beispielsweise die Deckungsbeiträge eines Produktes in unterschiedlichen Vertriebsgebieten bereitstellen oder einen Zahlungsvorgang durchführen. Hierbei orientieren sich Services an den Bedürfnissen von Unternehmen und folgen der gedanklichen Logik von Geschäftsabläufen („Deckungsbeiträge eines Produktes in unterschiedlichen Vertriebsgebieten ausgeben“). Damit sind Services die kleinstmöglichen Bausteine, aus denen sich geschäftliche Abläufe sinnvoll zusammensetzen lassen. Services besitzen klar umrissene fachliche Aufgaben und kapseln Daten sowie Anwendungslogik. Im Konzept der SOA geht es darum, aus Services eine gesamte funktionsfähige Architektur zu konstruieren. Damit dies problemlos funktioniert, müssen die Dienste gekapselt sein, um ohne Rücksicht auf eventuelle Abhängigkeiten an anderer Stelle wieder verwendet werden zu können. Unter einer Kapselung versteht man das Gruppieren oder Abschotten von Datenstrukturen, wodurch der direkte Zugriff auf die interne Datenstruktur unterbunden wird und stattdessen über definierte Schnittstellen erfolgt. Diese müssen für die Benutzer der Dienste als Black Box erscheinen. Der Anwender liefert seine Eingabe folglich in einem bestimmten Format und erhält seine Ausgabe im selben Format, ohne dass er etwas über die Abläufe innerhalb des Service wissen muss. Hierdurch kann eine Anpassung des Codes eines Moduls ermöglicht werden, ohne andere Bausteine anpassen zu müssen.
Nutzen von Serviceorientierten Architekturen
Die Abbildung des Geschäftsprozesses geschieht durch die lose Koppelung dieser Services zu einer Softwarearchitektur, die für Übersichtlichkeit und Flexibilität sorgt. Die Flexibilität entsteht durch die Veränderbarkeit des Zusammenspiels der Komponenten. Neue Komponenten können unabhängig von ihrer Technologie in die bestehende Architektur eingebaut werden und alte Komponenten ersetzen oder erweitern. Bisher machen die klassischen Architekturen von Software in Unternehmen Änderungen sehr komplex. Wenn sich etwa die Erfassungsmodalitäten einer gelieferten Ware änderten– weil z.B. die Erfassung durch einen Strichcode erfolgte –, musste ein Entwickler dies bisher direkt im Code der Anwendung anpassen, möglicherweise sogar in mehreren verschiedenen Anwendungen. Daher werden solche Teilfunktionen schon seit längerem in einzelne Module separiert, die man einzeln angleichen kann, und eine Abstimmung mit mehreren Stellen im Unternehmen unnötig wird. Eine konsequente Umstellung der Systemarchitektur auf Services setzt diesen Gedanken fort. Nach Umsetzung der SOA besteht die gesamte IT aus einzelnen, gekapselten Services, die sich einfach austauschen oder modifizieren lassen.
Zur Abbildung der Geschäftsprozesse durch Services ist eine Analyse der betrieblichen Abläufe nötig. Die Implementierung von SOA im Unternehmen reduziert auf diese Weise die Komplexität und deckt Optimierungspotentiale im Ablauf der Prozesse auf. So unterstützt die Implementierung von SOA das Prozess(kosten)management durch eine durchgängige Prozessorientierung. Am Beispiel des Teilprozesses „Vertrieb" können einige Vorteile durch den Einsatz von SOA aufgezeigt werden: Das Vertriebsprogramm greift auf die Daten der Buchhaltung zurück, während in einem weiteren Teilprozess die Buchhaltung mit dem Lagersystem gekoppelt wird. Die Services sind somit eine Art Baukastensystem zur Erstellung von individuell auf die Geschäftsprozesse ausgerichteten Applikationen.
Der modulare Aufbau führt einerseits zur
• Erhöhung der Flexibilität (vor allem durch schnelle Reaktion auf Prozessänderungen und einfache Integration neuer Komponenten) und andererseits zur
• Reduktion der Komplexität (vor allem durch die Kapselung der Funktionalität).
Abb.1: Die Gestaltung der IT-Landschaft
Abbildung 1 zeigt am Beispiel des Vertriebs, dass im Falle von Änderungen, Wartungen oder Ergänzungen an den einzelnen Datenbanken, diese nicht in sämtlichen Komponenten vollzogen werden müssen, da die Datenbanken aufeinander zugreifen können und eine redundante Datenhaltung umgangen wird. Somit kann eine erhebliche Effizienzsteigerung in der IT-Infrastruktur realisiert werden. Nachteilig wirkt sich aus, dass die Bereitstellung der Daten in standardisierter Form mit Performanceeinbußen verbunden sein kann.
Bei der Gestaltung und Implementierung von Geschäftsprozessen wird häufig das Business Process Management (BPM) eingesetzt. Im Rahmen des BPM kann SOA zu einer schnelleren Anpassung der Geschäftsprozesse beitragen, indem die einzelnen Komponenten entlang des Prozesses zusammengesetzt werden.
Fazit und Stand der Umsetzung
Bislang liegen in der Praxis noch wenig Erfahrungen mit SOA vor. Unternehmen, in denen SOA bereits umgesetzt wurde berichten, vor allem von der gestiegenen Flexibilität zu profitieren. Die genannte Möglichkeit der Wiederverwendung von bestehenden Diensten wird nur selten als Hauptnutzen genannt. Dies könnte daran liegen, dass der Nutzeneffekt erst nach längerer Verwertung einer SOA relevant wird. Der entscheidende Vorteil einer SOA liegt in der modularen Ausrichtung dieser Architektur. Diese ermöglicht es, von konkreten Prozessen im Unternehmen auszugehen und sie realitätsgerecht in einzelnen, wieder verwendbaren Bausteinen abzubilden. Hierdurch werden nicht nur die Entwicklungskosten, sondern auch der Aufwand bei der Wartung und der zukünftigen Anpassung reduziert. Dadurch sichert SOA eine flexiblere Gestaltung von Geschäftsprozessen. Grundsätzlich ist jedoch wie für jede IT-Anwendung das Kosten-Nutzen-Verhältnis zu prüfen, und es sind die zu unterstützenden Prozesse sorgfältig auszuwählen.
Quellen
• Dietsch, A., Goetz, T. (2005), Nutzenorientiertes Management einer Serviceorientierten Unternehmensarchitektur., in: Wirtschaftsinformatik 2005.
• Flinspach, T. Melski, A. (2008), Flexibilität ist alles – Eine Fallstudie zu Serviceorientierten Architekturen (SOAs), in: Economag 2008.
• Krafzig, D., Banke, K., Slama, D. (2004), Enterprise SOA – Service-Oriented Architecture Best Practice.
• Reinheimer, S, Lang, F., Purucker, J., Brügmann, H. (2007), 10 Antworten zur SOA, in: Fröschle, H.-P., Reinheimer, S. (Hrsg., 2007), Serviceorientiere Architekturen, Heidelberg 2007, S.7-17.
• Weske, M. (1999), Business-Objekte – Konzepte, Architekturen, Standards, in: Wirtschaftsinformatik 1999.
Ersteinstellende Autoren
Prof. Dr. Klaus Möller
Dr. Tobias Flinspach
Kontaktadresse: Klaus.Moeller@unisg.ch
Homepage: [1] - www.aca.unisg.ch