FOM Hochschule für Ökonomie & Management München

Berufsbegleitender StudiengangWirtschaftsinformatik, 4. Semester

Seminararbeit

über das Thema

SWOT-Analyse von ServiceorientierterArchitektur (SOA)

Betreuer: Dipl.-Math. Dipl.-Inform. Hans-Georg Eßer

Autor: Florian HofsässMatrikelnr.: 332025Abgabe: 17. Juli 2015

Inhaltsverzeichnis II

Inhaltsverzeichnis

Abkürzungsverzeichnis III

Abbildungsverzeichnis IV

1 Einleitung 1

1.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1.1 SWOT . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1.2 Web-Services . . . . . . . . . . . . . . . . . . . . . . . . . 21.1.3 Das Konzept Service orientierte Architektur (SOA) . . . . 3

1.2 Abgrenzung und Zielsetzung . . . . . . . . . . . . . . . . . . . . . 41.3 Methodik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 SWOT-Analyse 5

2.1 Stärken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.1.1 Modularität . . . . . . . . . . . . . . . . . . . . . . . . . . 52.1.2 Wiederverwendbarkeit . . . . . . . . . . . . . . . . . . . . 62.1.3 Verwendung von Standards . . . . . . . . . . . . . . . . . 72.1.4 Automatisierung von Geschäftsprozessen . . . . . . . . . 7

2.2 Schwächen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2.1 Qualitätssicherung . . . . . . . . . . . . . . . . . . . . . . 82.2.2 hohe Erstinvestitionen . . . . . . . . . . . . . . . . . . . . 9

2.3 Chancen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.3.1 Umsatz generieren und Kosten senken . . . . . . . . . . . 102.3.2 zunehmende Vernetzung . . . . . . . . . . . . . . . . . . . 11

2.4 Risiken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.4.1 mangelhafte Umsetzung . . . . . . . . . . . . . . . . . . . 112.4.2 Sicherheit und Integrität der Daten . . . . . . . . . . . . . 12

3 Fazit 13

Literaturverzeichnis V

Inhaltsverzeichnis III

Abkürzungsverzeichnis

EPK . . . . . . . . . . ereignisgesteuerte ProzesskettenESB . . . . . . . . . . Enterprise Service BusIT . . . . . . . . . . . . InformationstechnikSCEM . . . . . . . . Supply Chain Event ManagementSOA . . . . . . . . . . Service Orientierte ArchitekturUDDI . . . . . . . . Universal Description, Discovery and Integration

Abbildungsverzeichnis IV

Abbildungsverzeichnis

1 Web-Service Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Enterprise Service Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Ereignisgesteuerte Prozesskette am Bsp. eines Kreditantrags . . . . . . . 8

1 Einleitung 1

1 Einleitung

Walter Simon titelt Ende 2013 „Industrie 4.0 - Fertigung fusioniert mit IT [-]Informations- und Kommunikationstechnik (ITK) sowie das Internet haben dasPotenzial, die Industrie in ein neues Zeitalter zu katapultieren“1. Doch die künfti-gen Produktions- und Wertschöpfungsnetze müssen sich erst noch bilden.Ïndustrie4.0 welche, die Weiterentwicklung der durch Elektronik und IT unterstütztenAutomatisierung und Digitalisierung der Produktion (Industrie 3.0)2, beschreibt.Dabei sollen bei Industrie 4.0 Eingebettete Systeme, Cyber-Physical Systems -ein Verbund von mechanischen und elektronischen Komponenten-, das Internetder Dinge und das Internet der Dienste eine Rolle spielen3 Auch im öffentlichenSektor sind Umstrukturierungen der IT häufig die Folge von neuen Anforderungenan die Systeme, ebenso wie das bei vielen Unternehmen im Rahmen der Rea-lisierung von Industrie 4.0 die Konsequenz sein kann. Allerdings bedarf es beineuen Anforderungen an die komplette IT-Landschaft zuvor einer Planung, wiediese neue Anforderungen erfüllt werden können und wie dies konkret umgesetztwerden soll. Als Kriterien für eine erfolgreiche Umstrukturierung werden bei-spielsweise eine einheitliche IT-Basis-Infrastruktur, einheitliche ERP-Systeme fürSupportprozesse allem voran jedoch eine Abbildung der Geschäftsprozesse auf dieAnwedungs- und Systemstruktur der IT, welche möglichst konform zueinandersind.4 Im Rahmen dessen wird oft serviceorientierte Architektur oder kurz SOAals Lösung vorgeschlagen. Ob SOA die Lösung für solch ein Anforderungsprofilist, beziehungsweise welche Stärken und Schwächen SOA mit sich bringt, soll imRahmen einer SWOT-Analyse beleuchtet werden.

1.1 Definition

1.1.1 SWOT

Bei der SWOT-Analyse handelt es sich um ein Instrument aus dem Bereich derstrategischen Planung von Unternehmen. Dabei ist „SWOT“ ein Akronym fürStrenghts, Weaknesses, Opportunities und Threats, was im Deutschen mit Stärken,Schwächen, Chancen und Risiken gleichzusetzen ist. Die SWOT-Analyse findetvor allem im Rahmen von Positionsanalysen ihre Anwendung, wobei Stärkenund Schwächen auf eigene Fähigkeiten des Unternehmens fokussiert sind undChancen und Risiken das Umfeld des zu analysierenden Subjekts betrachten.Aus dieser Analyse lassen sich anschließend sowohl Strategien als auch konkrete

1Simon (2013).2vgl. Fabian (2014).3vgl. Simon (2013).4vgl. Groppo et al. (2009).

1 Einleitung 2

Maßnahmen ableiten, um unter den gegebenen Bedingungen möglichst erfolgreichsein zu können. Diese Strategien lassen sich in vier Rubriken einteilen. Das sindStrategien aus Strengths und Opportunities, die sogenannte SO-Strategie. DesWeiteren lassen sich aus den entsprechenden Rubriken die ST-, WO- und WT-Strategie ableiten.5

1.1.2 Web-Services

Ganz grundlegend sind Web-Services Softwareprodukte die auf Basis eines ihnenzur Verfügung gestellten Datensatzes eine Dienstleistung gegenüber einem soge-nannten Service-Nehmer erbringen. Ausschlaggebend ist dabei, dass Web-Servicesstets lose gekoppelte und verteilte Dienste sind. Von lose gekoppelt spricht man,wenn der Abhängigkeitsgrad einer Komponenten, hier des einzelnen Web-Services,zur restlichen IT-Landschaft und der konkreten Implementierung sehr gering ist.Ebenso sind die Anzahl der zur Verfügung gestellten Schnittstellen gering um denAbstraktionsgrad möglichst hoch zu halten. Aus der Sicht des Service-Nehmers,dem Teilnehmer der die Dienstleistung in Anspruch nimmt, erscheint ein Servicewie eine Blackbox. Dem Service werden Daten zur Bearbeitung zur Verfügunggestellt und anschließend das Ergebnis zur Verfügung gestellt. Aus der objekt-orientierten Programmierung kennt man dieses Verhalten als Information Hiding.Ein weiteres Merkmal von Web-Services ist die Granularität. Dabei wird bei Web-Services stets darauf geachtet, ausschließlich die Grundfunktion zur Verfügungzu stellen um zu gewährleisten, dass dieser Service möglichst lose gekoppelteingesetzt werden kann.6

Abbildung 1: Web-Service ArchitekturQuelle: vgl. Finger et al. (2009), S. 41

5vgl Springer Gabler (o.D.).6vgl. Hansen et al. (2005a), S. 802 - 804.

1 Einleitung 3

Wie die Abbildung 1 veranschaulicht, sind 3 Teilnehmer an der Nutzung undBereitstellung eines solchen Services beteiligt. Der Verzeichnisdienst macht dieNutzung bzw. das Auffinden der verschiedenen Dienstleistungen über das Internetmöglich.

1.1.3 Das Konzept Service orientierte Architektur (SOA)

Da es sich bei SOA um ein Architekturkonzept von Informationssysteme handelnsoll, wir neben SOA im Folgenden auch das Informationssystem definiert.

1.1.3.1 Informationssysteme

Alper et. al. definieren den Begriff der Informationssysteme als „ein künstliches,konkretes System, das aus maschinellen und menschlichen Elementen bestehtund seine Nutzer mit Informationen versorgt.“7 Abstrahiert betrachtet sind dieAufgaben eines Informationssystems folgende:8

• Übermittlung von Informationen (Überbrückung einer räumlichen Distanzzwischen Kommunikationspartnern)

• Speicherung von Informationen (Überbrückung einer Zeitspanne zwischenErzeugung und Verwendung von Informationen)

• Verarbeitung von Informationen (Inhaltliche Transformation wie bspw. Zu-ordnung, Prüfungen oder Berechnungen)

1.1.3.2 Service orientierte Architektur (SOA)

Unter einer SOA versteht man eine Systemarchitektur eines Informationssystems,die vielfältige, verschiedene und eventuell inkompatible Methoden oder Applika-tionen als wiederverwendbare und offen zugreifbare Dienste repräsentiert und da-durch eine plattform- und sprachenunabhängige nutzung und Wiederverwendungermöglicht9 Dabei gelten Standard, Sicherheit und Einfachheit als Grundlageneiner SOA und Verteiltheit, Lose Kopplung und die Orientierung an Geschäftspro-zessen, basierend auf diesem Fundament, tragende Säulen einer funktionierendenSOA bilden. Vorallem durch die Eigenschaft der Losen Kopplung und der starkenOrientierung an Geschäftsprozessen hebt sich die SOA von bisherigen verteiltenInformationssysteme ab10 Die SOA ist dabei nicht als konkrete Vorgabe zu ei-ner Implementierung zu verstehen sondern eher als grundlegender Architektur-bzw. Designansatz, dessen konkrete Implementierung bei den Nutzern selbst liegt.Grundlegend scheint jedoch die Verwendung eines Enterprise Service Bus (ESB)

7Alpar et al. (2014), S. 24.8vgl. Städter (2015), S. 66.9Dostal (2005), S. 11.

10vgl. Hansen et al. (2005b), S. 782.

1 Einleitung 4

als sinnvoll und erforderlich. Ein ESB fungiert als Integrationsplattform einerSOA und kann über standardisierte Adapter und Schnittstellen die Interoperabilitätzwischen Applikationen und anderen Komponenten herstellen.11 Allerdings sindsich die Autoren nicht einig darüber, ob der ESB bereits ein Teil der SOA odernur eine logische Weiterentwicklung12 Die Funktionsweise eines ESB soll auchin Abbildung Abbildung 2 „Enterprise Service Bus“ auf Seite 4 schematischverdeutlicht werden:

Abbildung 2: Enterprise Service BusQuelle: Mahadevan et al. (2011), S. 31

1.2 Abgrenzung und Zielsetzung

Diese Hausarbeit befasst sich mit der Gegenüberstellung von Stärken, Schwächen,Chancen und Risiken und soll die Möglichkeiten bei der Implementierung einerService orientierten Architektur deutlich machen und die Hürden bzw. Nachteileentgegenstellen. Dabei werden sowohl die Aspekte die Aspekte der Wartbarkeitund Wiederverwendbarkeit wie auch kaufmännische Aspekte wie Kennzahlender Prognosequalität und Kapazität aufgegriffen. Zum Ende der Arbeit soll einResumée gezogen werden, welche Schritte in der Planung besonders ausschlag-gebend für eine erfolgreiche Umstrukturierung hin zu einer Service orientierten

11vgl. Tröger et al. (2011), S. 118.12vgl. Dostal (2005), S. 19.

2 SWOT-Analyse 5

Architektur sind.

1.3 Methodik

Zu Beginn wurde ein Literature Review, eine Sichtung von themenrelevan-ter Literatur, durchgeführt. Dabei lag der Fokus darauf, Arbeiten über SOA-Implementierungen zu finden. Ebenso sollten dabei die verschiedenen Problemeund Vorteile bei den einzelnen Implementierungen herausgearbeitet werden. AlsQuellen wurde die Literatur von SpringerLink, IEEE Xplore, JSTOR und GoogleScholar verwendet. Dabei wurden bevorzugt Ausarbeitungen gewählt, welche überfolgende Keywords oder aus Kombinationen daraus zu finden waren:

• Service orientierte Architektur / SOA• WebServices / Web-Services / Web-Dienste• IT-Umstrukturirung / Geschäftsprozessabbildung

2 SWOT-Analyse

2.1 Stärken

2.1.1 Modularität

"Das Ausmaß, in dem eine Komponente mit anderen Komponenten interagiert,wird durch die Kopplung gemessen"13 beschreibt Hansen und Neumann den Be-griff der Kopplung zwischen Softwarekomponenten. Dabei gibt es im wesentlichenzwei Ausprägungen. Es wird unterschieden zwischen einer engen Kopplung undeiner losen Kopplung. Bei einer engen Kopplung ist die Verzahnung zwischen deneinzelnen Softwarekomponenten stark und eventuelle Änderungen in einer Kompo-nente bedarf aufgrund der engen Verzahnung auch weiterer Bearbeitungen in denanderen Komponenten. Bei der losen Kopplung hingegen steht die Losgelöstheitder einzelnen Komponenten voneinander im Vordergrund. Das heißt die Kompo-nente „benötigen kein gegenseitiges Wissen über die Implementierung“14. Es wirdversucht, die Abhängigkeiten zwischen einander zu minimieren, nach Möglichkeitgar zu eliminieren. Die Folge aus einer losen Kopplung sind im Vergleich zu einerengen Kopplung zwar einerseits Performanceeinbußen, andererseits bleibt die Ar-chitektur dadurch verständlich, nachvollziehbar und stets änderbar. Ein Änderungim logischen Ablauf kann durch gezielte Neustrukturierung der Komponentenund gezielte Änderungen abgebildet werden, was bei einer Architektur mit enger

13Hansen et al. (2005a), S. 225.14Hansen et al. (2005b), S. 784.

2 SWOT-Analyse 6

Kopplung viel Zeit und Folgeaufwand bedeuten würde. Dabei spricht man häufigauch von grob granularen Diensten. Als grob granular können diese bezeichnetwerden, wenn sie ausschließlich ihre vorbestimmten Funktionen erfüllen. Siemüssen „in sich abgeschlossene Dienste (engl.: self-container service)“15 sein,welche für sich alleine funktionstüchtig sind.

2.1.2 Wiederverwendbarkeit

Eine weitere Folge aus der Idee der Modularität ist der Aspekt der Wiederverwend-barkeit. In diesem Zusammenhang unterscheidet man in der Softwareentwicklunggrundlegend zwischen der Entwicklung für Wiederverwendbarkeit und Entwick-lung mittels Wiederverwendbarkeit. Der Mehrwert der Wiederverwendbarkeitwird erst im Bereich der Entwicklung mittels Wiederverwendbarkeit deutlich, dahier Kosten und Zeit gespart werden können.16 Damit dieses Konzept erfolgreichumgesetzt werden kann, ist es allerdings grundlegend erforderlich, dass die loseKopplung der Komponenten stets eingehalten wird. Sobald die einzelnen Servicesnicht vollkommen lose gekoppelt sind, schränkt das die Wiederverwendbarkeitein. Als Beispiel kann man in dem Zusammenhang anführen, dass ein WebSer-vice mit einer Kontonummer und Bankleitzahl bedient wird und als Ergebnis einboolean-Wert zurückgegeben wird, der beschreibt ob diese Bankverbindung valideist oder nicht. Diesen Service kann man in dieser Form ohne weitere Probleme inalle OnlineShops oder sonstigen Abwicklungen einbinden, in denen eine Validie-rung von Kontonummern und Bankleitzahlen erforderlich ist. Wird nun jedochzusätzlich noch eine IBAN generiert und zurückgegeben ist der Mehrzweck zwardurchaus gegeben, da mit einer IBAN besser gearbeitet werden und die Prüfzifferdie Validität der Kontoverbindung impliziert, allerdings ist dieser Service für alleVerwendungen obsolet in denen es tatsächlich ausschließlich um die Validierungvon Kontonummer und Bankleitzahl ging. Sinnvoller wäre die Trennung der bei-den Funktionen in einzelne Services. An diesem Beispiel soll nur im Grobenklar werden, welche Auswirkung eine nicht lose gekoppelte Komponente auf dieWiederverwendbarkeit von Komponenten in der Landschaft der SOA hätte. Inso-fern die Granularität beibehalten wird, ist die Wiederverwendbarkeit jedoch eingroßes Argument für die Service Orientierte Architektur in Zusammenarbeit mitWebServices, da es langfristig hohe Einsparpotentiale und Effizienzsteigerungenmit sich bringt und somit auch die Grundlage sein kann, ein in für die Zukunftvalides System bereitstellen zu können.17

15Hansen et al. (2005b), S. 783.16Tr\IeC {\"o}ger.2011.17vgl. Hansen et al. (2005a), S. 225.

2 SWOT-Analyse 7

2.1.3 Verwendung von Standards

Damit sowohl eigene Services angeboten und gefunden werden können, sowiefremde Services in Anspruch genommen werden können, ist es von zentralerBedeutung sich auf eine einheitliche Sprache zu einigen. Diese einheitliche Spra-che wurde bereits durch Abbildung 1 „Web-Service Architektur“ auf Seite 2erwähnt. Es wird deutlich, dass es standardisierte Kommunikationsmittel zur Su-che über den Verzeichnisdienst, sowie zum Veröffentlichen im Verzeichnisdienstwie auch zur Kommunikation zwischen Dienst-Anbieter (Service-Provider) undDienst-Abnehmer (Service-Client) gibt. Die grundlegend Forderung ist dabei,„dass alle Schnittstellen in maschinenlesbarer Form geschrieben sind“18. Einewichtige Voraussetzung hierfür ist, dass eben genante offenen Standards genutztwerden, damit Service Clients fremde Services verstehen und verwenden können.Gleichzeitig ist die Verwendung von Standards die Grundlage für eine breiteAkzeptanz der Service-Landschaft und damit auch einem breiteren Angebot vonServices. Zusätzlich zu genannten Vorteilen sind vorliegende Standards auch aufKostenebene sehr interessant. Die Folgekosten für aufwendige Implementierungenbleiben durch die gegebenen Standards weitestgehend aus. Auch Troger und Altheben in ihrer Arbeit deutlich die geringeren Systemintegrationskosten durchSchnittstellenstandardisierung innerhalb einer SOA hervor.19

2.1.4 Automatisierung von Geschäftsprozessen

Ein weiterer Vorteil durch die flexible Architektur der SOA ist die MöglichkeitGeschäftsprozesse sehr geschäftsnah und vorallem effizienter implementieren zukönnen.20 Da die Arbeit mit Services meist von Ereignissen gesteuert wird, sprichtman hier auch von ereignisgesteuerten Prozessketten oder auch von Event-drivenArchitecture21 welche die Abbildung 3 „Ereignisgesteuerte Prozesskette am Bsp.eines Kreditantrags“ auf Seite 8 beispielhaft zeigt. Solche ereignisegesteuertenProzessketten (EPK) lassen sich gut durch Komponenten einer SOA abbilden. Bei-spielsweise das Prüfen eines Kreditantrages. Daher bietet sich die SOA geradezudazu an, einmal modellierte Abläufe über sie zu lösen und damit zu automatisieren.Eventuelle Anpassungen in der Geschäftsprozesslogik, werden neu modelliertund werden dank der losen Kopplung und der Wiederverwendbarkeit verhältnis-mäßig einfach umgesetzt. Diese Möglichkeit der SOA, ist eines der Argumente,warum viele Unternehmen von Out-of-the-Box verteilten Informationssystemen,also nicht individualisierten Informationssystemen, auf die SOA umsteigen wol-18Dostal (2005), S. 9.19vgl. Tröger et al. (2011), S. 122.20vgl. Tröger et al. (2011), S. 121.21vgl. Dostal (2005), S. 10.

2 SWOT-Analyse 8

Abbildung 3: Ereignisgesteuerte Prozesskette am Bsp. eines KreditantragsQuelle: Eigene Darstellung mit Hilfe von http://www.bicdesign-free.com/webedition/

len, da sich ihre eigenen Geschäftsprozesse gut und verhältnismäßig einfach inder Implementierung abbilden lassen. Auch Tröger et. al. führt die zunehmendeMitarbeiterproduktivität durch die Prozessautomatisierung -und Unterstützung alsquantitative Nutzenkategorie in seiner Arbeit auf22

2.2 Schwächen

2.2.1 Qualitätssicherung

Ein Nachteil in einer Service orientierten Architektur und der damit vielen einzel-nen lose gekoppelten Komponenten ist aus dem Gesichtspunkt der Qualitätssiche-rung die Bereitstellung durch verschiedene Anbieter, verschiedene Versionen der

22Tr\IeC {\"o}ger.2011.

2 SWOT-Analyse 9

einzelnen Service allem voran jedoch die Tatsache, dass die einzelnen Servicesin dieser individuellen Zusammenstellung noch im Rahmen von Qualitätssiche-rung getestet wurden. So sagt Herr Jürgen Unterreitmayer von der imbus AG,ein Unternehmen für Software-Tests und Qualitätssicherung, dass das Geld dassman sich für die Entwicklung durch Wiederverwendbarkeit spare, auf der ande-ren Seite für Qualitätssicherung und Softwaretests investiert werden muss. DerGrund für den hohen Aufwand erkennt man bei der Annahme, dass bereits einSystem, als SOA implementiert, getestet wurde und für funktionstüchtig befundenwurde. Sobald beispielsweise von extern eingebundene Services in neuer Versionvorliegen, gilt die eigene SOA in dieser Zusammenstellung bereits als ungetestet,da die Komponente in neuer Version nicht als getestet eingestuft werden kann.Genau genommen müsste nach regelmäßiger Aktualisierung von externen Servicesoder neu eingebundenen Services eine neue Qualitätssicherung stattfinden, waspraktisch kaum durchführbar ist, da hohe Budgets hierfür benötigt werden würdenund auch der zeitliche Aufwand kaum angemessen scheint. Hier liegt dann ehereine Klassifizierung der Anbieter in qualitätsgesichert und nicht qualitätsgesi-chert als passendes Instrument näher. Dennoch ist der Aufwand und die damitverbundenen Kosten für Softwaretests durch neu eingebundene Komponente oderveränderte Komponenten deutlich höher, als das bei abgeschlossenen betrieblichenInformationssystemen der Fall ist.23

2.2.2 hohe Erstinvestitionen

Während in Abschnitt 2.1 „Stärken“ auf Seite 5 schon auf die zahlreichen Vorteileeiner SOA eingegangen wurde, muss hier auch gesagt werden, dass mit den Grund-voraussetzungen, die für die Möglichkeit von Modularität, Wiederverwendbarkeitund loser Kopplung, geschaffen werden müssen, auch Kosten verbunden sind. Diedamit anfallenden Kosten übersteigen in der Regel die Entwicklungskosten ausder bisherigen Entwicklung von Informationssystemen. Die Gründe hierfür sindbei genauer Betrachtung logisch und voraussehbar. Während eine SOA mit zuneh-mender Verwendung dadurch kostengünstig und effizient wird, dass die einzelnenModule wiederverwendet werden können, ist der Aufwand und damit auch dieEntwicklungszeit und folgerichtig die Kosten für Entwickler und Infrastrukturhöher, wenn die Module neu entworfen werden müssen und mehr Kriterien alszuvor eingehalten werden müssen. Wie Becker aus Expertenbefragungen in Er-fahrung bringt, wird nach Angaben der Befragten der größte Teil des Budgetsin Infrakstruktur wie einen ESB, ergänzende Werkzeuge und Entwicklungszeitinvestiert. Vor allem zu Beginn der Entwicklung, sei der Aufwand verhältnismäßig

23vgl. Unterreitmayer (2015), (Personal Communication).

2 SWOT-Analyse 10

hoch, da die Abbildung von Geschäftsprozessen auf die SOA-Landschaft sehrinvidivuell und damit auch zeitintensiv ist. Ebenso muss bei der Entwicklungeinzelner Module sehr genaue auf neue Guidelines wie lose Kopplung, grobeGranularität und standardisierte Schnittstellen geachtet werden. Hinzu kommenim Vorfeld eine saubere Modellierung der Kerngeschäftsprozesse notwendig, umdiese Geschäftsprozesse in der SOA richtig abbilden zu können. Das Entwickelnder einzelnen Module unter neuen Gesichtspunkten bzw. das adaptieren aus bishe-rigen Systeme in die neue Architektur sind vergleichsweise teuer.24 Ein weitereKostenblock ist die Qualitätssicherung. Da die Qualitätssicherung, also das Testender Softwarekomponenten auf Fehler, bei einer SOA aufwendiger ist als bei her-kömmlichen Informationssystemen (siehe Abschnitt 2.2.1 „Qualitätssicherung“auf Seite 8), werden die Kosten für die Qualitätssicherung auch höher ausfallen.

2.3 Chancen

2.3.1 Umsatz generieren und Kosten senken

Mit zunehmender Laufzeit einer SOA-Implementierung ergeben sich hieraushäufig bilateral positive monetäre Effekte.

2.3.1.1 Kosten senken Einerseits ermöglicht die SOA durch Wiederverwendbar-keit (siehe Abschnitt 2.1.2 „Wiederverwendbarkeit“ auf Seite 6) Entwicklungszeiteinzusparen, da -bis auf kleine Anpassungen- die einzelnen Module nicht neuentwicklet werden müssen, sondern in vorliegender Funktion eingebunden werdenkönnen. Die hier eingesparte Entwicklungszeit kann in neue Projekte o.ä. investiertwerden und reduziert damit die Kosten für Entwickler.

2.3.1.2 Umsatz generieren Andererseits entsteht durch das Entwickeln und be-reitstellen einzelner Services über einen Verzeichnisdienst (meist Universal Des-cription, Discovery and Integration (UDDI)) (siehe Abschnitt 1.1.2 „Web-Services“auf Seite 2) auch die Möglichkeit Umsätze zu erzielen, insofern dieser Servicevon anderen Client in Anspruch genommen wird. Hier sind je nach Kooperati-onsgrad verschiedene Abrechnungsmodelle möglich. Häufig wird in Form vonpay per Use abgerechnet. Das bedeutet, dass der Service Client nur pro genutzterEinheit zahlen muss. Dem entgegen stehen häufig pauschale Bezahlmodalitäten,die eher als Flatrate bekannt sind. Je nach Zweck der Implementierung wird dieInanspruchnahme auch mit Abtretungen an Lizenzrechten abgegolten. Dies istbeispielsweise dann der Fall, wenn die Implementierung eines Services, explizit

24vgl. Becker (2011), S. 159.

2 SWOT-Analyse 11

für den Verkauf oder die Vermarktung eines bestimmten Produktes eingesetztwird.25

2.3.2 zunehmende Vernetzung

Ein weitere Chance auf die vor allem Tröger et. al. eingeht sind ist die einfachereVernetzung von verschiedenen Systemen entlang der Supply Chain. Angelehnt andas Event-gesteuerte Verfahren von SOA (siehe Abschnitt 2.1.4 „Automatisierungvon Geschäftsprozessen“ auf Seite 7) wird eine unternehmensübergreifende SOA,bzw eine SOA mit „zahlreiche[n] standardisierten[n] SCEM-relevanter Informati-onsdienste[n]“26 als Supply Chain Event Management (SCEM) bezeichnet. Vonder zunehmenden Vernetzung entlang der Lieferkette könnten sich vorallem Kos-ten in Bereichen wie Planung und Logistik einsparen lassen und die Abstimmungzueinander verbessert werden. Ebenso könnten die Durchlaufzeiten reduziert wer-den, da für die Produktion relevante Informationen bereits über das SCEM-Systemzur Verfügung stehen. Auch bei Änderungen, die entlang der Lieferkette umgesetztwerden müssen, beispielsweise Änderung von gesetzlichen Vorgaben im BereichDatenschutz, könnte zeiteffizienter umgesetzt werden, da viele Informationenim Idealfall vom Ursprung des SCEM durchgeleitet werden. Somit muss dieAnpassung für dieses Informationspaket lediglich zu Beginn der Supply Chainangepasst werden. Letztlich spricht Tröger et. al. auch Qualitätsverbesserung an,die durch die höhere relevante Informatonsverfügbarkeit erreicht werden könnte.Theoretisch gesehen ist es sicherlich valide, dass wenn ein Zulieferer alle Informa-tionen zum Produkt über SCEM mit anliefert, ein neuer Qualitätsstandard erreichtwerden könnte. Fraglich ist hingegen jedoch, ob sich Zulieferer darauf einlassenwürden, wenn angenommen werden kann, dass nicht alle angelieferten Produkteeinwandfrei sind.27

2.4 Risiken

2.4.1 mangelhafte Umsetzung

Eines der größten Risiken scheinen Fehler in der grundlegenden Planung undder damit verbundenen Anpassung der Organisationsprozesse zu sein. Währendbei SOA auf Einfachheit und Wiederverwendbarkeit abgezielt wird, waren die-se Grundsätze meisten Unternehmen kein Kritierium für die Bildung von Ge-schäftsprozessen. Es wurde eher angestrebt, dass die einzelnen Geschäftsprozesse

25vgl. Becker (2011), S. 54.26Tr\IeC {\"o}ger.2011.27Tr\IeC {\"o}ger.2011.

2 SWOT-Analyse 12

fachlich sinnvoll, relevant, wirtschaftlich und gut verständlich sind. Die Wirt-schaftlichkeit eines Prozesse erhöht sich, ohne Berücksichtigung von SOA, meistdann umso integrierter er ist. Das bedeutet umso verzahnter einzelne Schritteeines Geschäftsprozesse sind umso effizienter wird dieser auch.28iese Grundi-dee konkurriert jedoch so stark mit der Architekturidee von SOA, dass diesebeiden Voraussetzungen nicht vereinbar sind (siehe Abschnitt 1.1.3 „Das Kon-zept Service orientierte Architektur (SOA)“ auf Seite 3). Folglich müssen dieOrganisationsprozesse für eine SOA Steuerung entsprechend angepasst werden.Aus der Literaturanalyse von Becker ging hervor, dass aus 27 relevanten Werkenin 19 aufgegriffen wird, dass die „Anpassung der Organisations(-prozesse) zurSOA Steuerung)“29ine Herausforderung sei.30 In 10 von 27 Werken wurde auchService-Design als Herausforderung angegeben. Service-Design (siehe Abbildung1 „Web-Service Architektur“ auf Seite 2) beschreibt die grundlegende Gestal-tung eines Services unter den Gesichtspunkten der losen Kopplung, damit dieserentsprechend wiederverwendbar ist und bleibt. In der Regel sind diese Kriterienfür die Entwickler kaum bekannte Kritieren und benötigen somit einerseits mehrEntwicklungszeit, andererseits besteht die Gefahr, dass der einzelne Service nichtstandardisiert genug ist und so nur eingeschränkt wiederverwendbar ist. Die Folgebei erneuter Verwendung wäre wohl, dass weitere Entwicklungszeit in diesesModul investiert werden müsste und somit den eigentlichen Vorteil von SOAschmälert. Treten solche Probleme häufiger auf, wäre der Mehrwert von SOA - jenach Ausmaß der Fehler - gefährdet.31 Folglich sind genannte Punkte tatsächlichRisiken für Unternehmen, da alle genannten zu deutlich höheren Kosten in derNacharbeit führen würden und damit die Wirtschaftlichkeit der SOA, die vor allemdurch Wiederverwendbarkeit erreicht werden soll, gefährdet.

2.4.2 Sicherheit und Integrität der Daten

Ein weiterer Aspekt der beachtet werden muss ist die Sicherheit. Während inherkömmlichen Informationssysteme die Daten die gemietete Cloud oder gar dieeigene Infrastruktur nicht verlassen haben, ist dies, zumindest teilweise, in einerSOA ständig der Fall. Da die Services über das Internet bereit gestellt werden,werden alle für die Verarbeitung nötigen Daten eben auch über dieses übertra-gen. Somit müssen für die Übertragung folgende 4 Grundsätze der Sicherheiteingehalten werden:

•

28D.29e.30vgl. Becker (2011), S. 123.31vgl. Becker (2011), S. 123.

3 Fazit 13

3 Fazit

zielführend zielhemmendin

tern

eFa

ktor

en Stärken

• Modularität• Wiederverwendbarkeit• Verwendung von Stan-

dards• Automatisierung von

Geschäftsprozessen

Schwächen

• Qualitätssicherung• hohe Erstinvestitionen

Um

wel

tfak

tore

n

Chancen

• Umsatz generieren undKosten senken

• zunehmende Vernetzung

Risiken

• mangelhafte Umsetzung• Sicherheit und Integrität

der Daten

Literaturverzeichnis V

Literaturverzeichnis

[1] Alpar, Paul et al. (2014): Anwendungsorientierte Wirtschaftsinformatik:Strategische Planung, Entwicklung und Nutzung von Informationssystemen,7., aktual. u. erw. Aufl., Springer Vieweg, Wiesbaden, ISBN:9783658005207.

[2] Becker, Alexander (2011): Nutzenpotenziale und HerausforderungenService-orientierter Architekturen: Techn. Univ., Diss.–Darmstadt, 2010, 1.Aufl., Gabler Verlag / Springer Fachmedien Wiesbaden GmbH Wiesbaden,Wiesbaden, ISBN: 978-3-8349-2946-4.

[3] Dostal, Wolfgang (2005): Service-orientierte Architekturen mit WebServices: Konzepte - Standards - Praxis, 1. Aufl., Elsevier Spektrum Akad.Verl., München, ISBN: 3-8274-1457-1.

[4] Fabian, Jan-Henning (2014): ABB-Technologietag 2014 - Die Zukunft derAutomatisierung, hrsg. von Technologietag im Forschungszentrum,LadenburgURL: http://files.vogel.de/vogelonline/vogelonline/files/6393.pdf.

[5] Finger, Patrick; Zeppenfeld, Klaus (2009): SOA und WebServices, Springer,Berlin, ISBN: 9783540769910.

[6] Groppo, Giovanni; Heck, Uwe (2009): „Strategische Neuausrichtung der ITin der öffentlichen Verwaltung: Ein Erfolgsfaktor zur Umsetzung derVerwaltungsmodernisierung“. In: Verwaltung und Management.

[7] Hansen, Hans Robert; Neumann, Gustaf; Hansen-Neumann (2005):Wirtschaftsinformatik I: Grundlagen und Anwendungen, 9., neu bearb.Aufl., Lucius & Lucius, Stuttgart, ISBN: 3-8252-2669-7.

[8] Hansen, Hans Robert; Neumann, Gustaf; Hansen-Neumann (2005):Wirtschaftsinformatik II: Informationstechnik, 9., neu bearb. Aufl., Lucius& Lucius, Stuttgart, ISBN: 3-8252-2670-0.

[9] Mahadevan, Lakshman; Kettinger, William J. (2011): „Service OrientedArchitecture as a Dynamic Enabler of Customer Prioritization“. In:e-Service Journal.

[10] Simon, Walter (2013): Tektonische Verschiebungen in der Arbeitswelt:Industrie 4.0 - Fertigung fusioniert mit IT , hrsg. von Computerwoche,URL: http://www.computerwoche.de/a/industrie-4-0-fertigung-fusioniert-mit-it,2544586.

Literaturverzeichnis VI

[11] Springer Gabler: SWOT-Analyse,URL:http://wirtschaftslexikon.gabler.de/Archiv/326727/swot-analyse-v3.html.

[12] Städter, Thomas: „IT-Infrastruktur“, Vorlesungsskript, München: FOMHochschule für Ökonomie und Management, 2015.

[13] Tröger, Ralph; Alt, Rainer (2011): „Serviceorientiertes Supply Chain EventManagement (SCEM) — Nutzen und Architektur für globale Lieferkettenam Beispiel der Modeindustrie“. In: Die Unternehmung.

[14] Unterreitmayer, Jürgen (2015): Persönliches Gespräch überQualitätssicherung bei Services Orientierter Architektur.