Post on 22-Jul-2020
transcript
Hessisches Ministerium für Wirtschaft, Verkehr und Landesentwicklung
www.hessen-it.de
Hessen IT
Band 63
SOAMehr als nur flexible Softwarearchitekturen
Benjamin Blau
Tobias Conte
Dr. Julian Eckert
Norbert Eder
Markus Ganß
Dr. Ralf Helbig
Dr. Carsten Holtmann
Dr. Christine Legner
Dr. Wolfgang Martin
Thomas Mironiuk
Dr. Bruno Quint
Dr. Nicolas Repp
Hessisches Ministerium für Wirtschaft,
Verkehr und Landesentwicklung
SOAMehr als nur flexible Softwarearchitekturen
Hessen-IT Band 63
HA Hessen Agentur GmbHHessen-ITAbraham-Lincoln-Straße 38–4265189 Wiesbaden
Telefon 0611 774-8481Telefax 0611 774-8620E-Mail info@hessen-it.deInternet www.hessen-it.de
Redaktionsteam: Dr. Matthias DonathChristian FloryWolf-Martin AhrendGabriele Gottschalk
Alle Rechte vorbehalten.Nachdruck, auch auszugsweise, verboten.
© Hessisches Ministerium für Wirtschaft, Verkehr und Landesentwicklung Hessen-ITc/o HA Hessen Agentur GmbHWiesbaden 2010
Layout/Satz: WerbeAtelier Theißen, LohfeldenTitelcollage: WerbeAtelier Theißen unter Verwendungeiner Abbildung von AndyL/istockphotoDruck: Druckerei ausDRUCK, Kassel
ISBN 978-3-939358-63-3
Bibliografische Informationen der Deutschen Bibliothek: Die Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen National -bibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.ddb.de abrufbar.
Liebe Leserinnen und Leser,
Innovationen sind der Motor für unser Wachs tum und unseren
Wohlstand in der Zukunft. Im globalen Wettbewerb müssen die
westlichen Industrieländer ihre Wirtschaftsgüter nicht nur schneller
anbieten, sie müssen auch neuartige, qualitativ hochwertige und
technisch fortschrittliche Angebote entwickeln.
Informations- und Kommunikationstechnologien (IKT) haben dabei für Unternehmen
eine Schlüsselfunktion. Denn sie unterstützen beides: effiziente interne Prozesse und
zukunftsorientierte, IKT-basierte Dienste und Produkte. Voraussetzung hierfür ist der
Einsatz von hoch gradig flexiblen Software- und IKT-Systemen in den Unternehmen.
Diese Flexibilität lässt sich mit so genannten serviceorientierten Architekturen (SOA)
erzielen. Das SOA-Prinzip strukturiert ein Softwaresystem (Architektur) gemäß seiner
einzelnen funktionalen Dienste (Servi ces), welche die IKT für den Geschäftsprozess
erbringt. Durch eine Unterteilung des Softwaresystems in lose gekoppelte Module, die
sich variabel und mehrfach kombinieren lassen, werden dynamisch veränderbare und
vielfältig gestaltbare IKT-Systeme möglich. Entsprechend lassen sich komplexe Soft-
waresysteme nicht nur übersichtlicher gestalten und Unternehmensstrategien agiler
umsetzen – auch neue, innovative Geschäftsmodelle und Geschäftsfelder werden reali-
sierbar. Deswegen sind serviceorientierte Architekturen und Anwendungen zu Leitan-
sätzen in der Softwareentwicklung geworden. Sie nutzen großen Unternehmen und
bieten auch mittleren und kleinen Firmen beträchtliche Chancen.
Die Softwareregion Rhein-Main-Neckar hat sich als „Silicon Valley Europas“ (Truffle-Stu-
die 2010) zu einem Kompetenzzentrum für SOA entwickelt. Mit diesem Leitfaden, der
Beiträge regionaler Experten enthält, möchten wir Ihnen einen praxisnahen Zugang zum
vielschichtigen Thema SOA eröffnen und auf die Stärke des SOA-Standortes Hessen hin-
weisen. Nehmen Sie Kontakt mit den aufgeführten Experten auf oder wenden Sie sich
einfach an das Projektteam von Hessen-IT. Für die serviceorientierten Aktivitäten Ihres
Unternehmens wünsche ich Ihnen viel Erfolg!
Dieter Posch, Hessischer Minister für Wirtschaft, Verkehr und Landesentwicklung
Einleitung ............................................................................................. 1
SOA-Check 2010: Status quo – Trends – Perspektiven ................ 5
1.1 SOA-Grundlagen ................................................................................. 5
1.2 SOA-Vorteile ......................................................................................... 7
1.3 SOA-Marktbefragung .......................................................................... 8
1.4 Ergebnisse .......................................................................................... 10
1.5 Fazit ..................................................................................................... 17
SOA@Work: Mehr Agilität und Effizienz ...................................... 19
2.1 Agile Unternehmen sind die Ziele .................................................. 20
2.2 Flexible Prozesse sind die Lösung .................................................. 21
2.3 BPM und SOA aufeinander abstimmen ......................................... 22
2.4 Effizienz durch Governance ............................................................. 24
2.5 Fazit ..................................................................................................... 25
SOA-Starter Kit: Think big, start small, show quick success ..... 26
3.1 Einsatzbereiche ................................................................................. 26
3.2 Dimensionen und Ziele .................................................................... 28
3.3 Komponenten .................................................................................... 31
3.4 Der erste Service ............................................................................... 33
3.5 Fazit ..................................................................................................... 37
SOA-Kommunikation: „Wie überzeug’ ich meinen Chef?“ ...... 38
4.1 Die optimale Initiative ....................................................................... 38
4.2 Geschäftsanforderungen .................................................................. 42
4.3 Argumentationsstrategie .................................................................. 44
4.4 Vorteile kommunizieren .................................................................... 47
4.5 Fazit ..................................................................................................... 53
SOA-Governance: Warum Investitionen in Menschen
wichtiger sind als in Monitoring-Tools .......................................... 54
5.1 Definition „SOA-Governance“ ......................................................... 55
5.2 Soziale Auswirkungen ....................................................................... 57
5.3 Governance realisieren ..................................................................... 59
5.4 Governance kommunizieren ............................................................ 60
5.5 Fazit ..................................................................................................... 61
1
2
4
3
5
SOA
SOA-Security: Webservices erfordern zusätzliche
Sicherheitsmaßnahmen .................................................................. 62
6.1 Grundlagen ........................................................................................ 62
6.2 Sicherheitsanforderungen ............................................................... 63
6.3 Sicherheitsmechanismen ................................................................. 66
6.4 Methoden der Umsetzung ............................................................... 72
6.5 Fazit ..................................................................................................... 75
SOA goes B2B: Lessons Learned aus der Automobilindustrie .. 76
7.1 SOA und B2B ..................................................................................... 76
7.2 SOA-B2B-Architektur: Öffentliche und interne Sicht .................... 80
7.3 SOA vs. herkömmliche B2B-Integration ......................................... 84
7.4 Reifegrad und Herausforderungen ................................................. 86
7.5 Fazit ..................................................................................................... 88
SOA-Perspektiven: Geschäftsmodelle und Innovationen
für das Internet der Dienste ........................................................... 90
8.1 Internet der Dienste .......................................................................... 90
8.2 Forschungsprojekt TEXO ................................................................. 98
8.3 Marktpotential serviceorientierter IKT .......................................... 100
8.4 Geschäftsmodelle für das Internet der Dienste .......................... 103
8.5 Fazit ................................................................................................... 111
Glossar ............................................................................................. 112
Ihre Partner in Hessen ................................................................... 114
Profile der Unternehmen und Institutionen der Autoren ........ 122
Aktionslinie Hessen-IT ................................................................... 124
Schriftenreihe Hessen-IT ............................................................... 126
7
8
6
9
10
12
11
Die komplette Schriftenreihe finden Sie im Anhang oder im Internet unter www.hessen-it.de(Bestellmöglichkeit und Download als PDF-Datei)
Schriftenreihe Hessen-IT:Neuerscheinungen
Hessen IT
2008
Leitfaden zur Patentierung computer implementierter
Erfindungen (2. aktualisierte Auflage)
Telekommunikationsanbieter in Hessen 2008
2009
Ambient Mobility – Intelligente Produkte und Umgebungen
für mobile Bürger und Unternehmen
Rating für IKT-Unternehmen (2. aktualisierte Auflage, Januar 2009)
2010
Ambient Mobility – Intelligent Products and Environments
for Mobile Citizens and Businesses
Die Gamesbranche – ein ernstzunehmender Wachstumsmarkt
(2. aktualisierte Auflage)
Notleidende Projekte – Eine Hilfestellung für IT-Projekte
in sieben Akten
Satellitennavigation in Hessen – Ideen über All
SOA – Mehr als nur flexible Softwarearchitekturen
Einleitung
Am 12. April 1996 hat das Marktforschungsunternehmen Gartner in
zwei „Research Notes“ den Begriff der „serviceorientierten Architektur“
(Service Oriented Architecture) erstmals verwendet und damit eine neue
Sichtweise geprägt. Habe man früher – so Gartner in einem Vergleich zur
Luftfahrtindustrie – geschaut, welche Flugzeugarten gebaut werden könn-
ten, betrachte man nun, welche sinnvollen Transportdienste (transporta-
tion services) man anbieten kann. Nicht mehr die Technologie steht im
Vordergrund, sondern das Geschäft, in dessen Dienst sie steht. Um eine
größere Flexibilität zu erreichen, wird das Geschäft in einzelne Teilpro-
zesse aufgeteilt und diesen werden entsprechende IT-Dienste (Services)
mit dahinter liegenden Backend-Systemen zugeordnet. Die einzelnen
Services sind über standardisierte Schnittstellen lose miteinander gekop-
pelt, so dass sie flexibel kombinierbar und wieder verwendbar sind und
agile Geschäfte ermöglichen.
3-Ebenen-Modell einer serviceorientierten Architektur
Heute, 14 Jahre nach seiner Einführung, hat das SOA-Prinzip nichts von
seiner Aktualität verloren. Im Gegenteil, je größer der Wettbewerbsdruck,
desto wichtiger werden flexible Geschäfts- und IKT-Prozesse sowie inno-
vative IKT-basierte Dienste und Produkte. Unternehmen mit einer service-
orientierten Architektur können nicht nur ihre internen Services flexibel
miteinander kombinieren. Sie können auch externe Services besser an-
und einbinden und damit die Vorteile von Software-as-a-Service (SaaS)
Prozesse
Services
Externer Service-Anbieter Backend-
Systeme
1
www.hessen-it.de
besser nutzen. Beim SaaS-Ansatz wird Software als mietbarer Dienst über
das Netz bezogen bzw. betrieben. Unternehmen können sich damit
besser auf Ihre Kernkompetenzen konzentrieren und andere Prozesse an
Dienstleister bzw. Services übertragen, die darauf spezialisiert sind.
Wertschöpfung entsteht noch stärker im Verbund.
Diese Strategie ist eng mit dem Ziel des BMBF-Spitzenclusters „Software -
innovationen für das digitale Unternehmen“ mit Sitz in Darmstadt verknüpft.
Das Software-Cluster möchte Unternehmen durch den Einsatz von so
genannter emergenter Software die Entwicklung zu vollständig digitalen
Unternehmen ermöglichen. Digitale Unternehmen arbeiten in hochflexib -
len, internetbasierten Unternehmensnetzen und richten ihre Geschäfts -
modelle und -prozesse dynamisch darauf aus. Alle Daten über Prozesse,
Betriebsmittel und Ressourcen in der realen Unternehmenswelt sollen
ihnen jederzeit in genauer zeitlicher und räumlicher Auflösung zur Planung,
Steuerung und Optimierung zur Verfügung stehen. Das kann nur erreicht
werden, wenn emergente Software eine Vielzahl von Softwarekomponen-
ten unterschiedlicher Hersteller dynamisch und flexibel kombinieren kann.
Auch das so genannte Internet der Dienste (Internet of Services) setzt bei
serviceorientierten Architekturen und Anwendungen an. Hierbei handelt
es sich um die Weiterentwicklung des bestehenden Internets zu einem
Netzwerk, dass nicht nur allgemeine Informationen, sondern auch perso-
nen- und situationsbezogene Informationen, also Dienstleistungen,
erbringt. Technisch baut das Internet der Dienste auf Services auf, die –
obwohl sie zum Teil von unterschiedlichen Anbietern stammen – miteinan-
der kombiniert und zu komplexeren Services zusammengefügt werden
können. Im Rahmen des Leitprogramms in der IKT-Förderung des Bun-
desministeriums für Wirtschaft und Technologie (BMWi) THESEUS soll das
Projekt TEXO, an dem eine Reihe von hessischen Partnern beteiligt sind,
genau in diese Richtung führen (siehe S. 98).
2
Einleitung
Angesichts all dieser Entwicklungen verwundert es nicht, dass der Markt
von und um serviceorientierte(n) Architekturen ein beständig signifikantes
Wachstum vollzieht. Eine Studie der Analysten- und Beratungsgesellschaft
Pierre Audin Consultants (PAC) vom 30. Juli 2009 – unter Mitwirkung von
IDATE, Fraunhofer ISI und London Economics im Auftrag der Europäi-
schen Kommission – prognostiziert ein Wachstum des europäischen SOA-
Marktes (EU 27) von 38 % in 2010, 31 % in 2011 und 25 % in 2012.
Prognose SOA-Marktentwicklung in EU 27
Quelle: PAC, D2 – The European Software Industry, Economic and Social Impact
of Software & Software-Based Services, 30. Juli 2009
Jährlicher SOA-Markt (Nominalwert auf Basis 2008)
Jahr
EU 27
Jahr
EU 27
2007
2057
2007
–
2008
3534
2008
71,8 %
2009
4838
2009
36,9 %
2010
6678
2010
38,1 %
2011
8808
2011
31,9 %
2012
11002
2012
24,9 %
Jährliches Marktwachstum
Mio. Euro
2007
0
2000
4000
6000
8000
10000
12000
2008 2009 2010 2011 2012
Lizenzen und Wartung IT-Dienstleistungen
3
www.hessen-it.de
In dieser Broschüre werden einzelne wichtige Aspekte des Wachstums-
marktes serviceorientierter Architekturen von regionalen Experten erläu-
tert, um Entwicklungen in diesem Bereich begleitend voran zu treiben.
Zunächst werden wesentliche Grundlagen und Vorteile des SOA-Ansatzes
vermittelt, verbunden mit Umfrageergebnissen und Empfehlungen zum
SOA-Einsatz. Der zweite Beitrag stellt umfassend das SOA-Potenzial für
mehr Agilität und Effizienz heraus, bevor im dritten Beitrag Ansatzpunkte
für neue SOA-Initiativen geschildert werden. Wie das dafür benötigte
Budget betriebsintern verargumentiert und erworben werden kann, zeigt
Beitrag vier. SOA-Governance und SOA-Security sind Aspekte, die für den
Erfolg von SOA-Projekten von zentraler Bedeutung sind. Sie werden in
den Beiträgen 5 und 6 aufgegriffen. Mit Beitrag 7 folgt ein Praxiseinblick,
der zeigt, dass SOA auch heute schon überbetriebliche Prozesse in Unter-
nehmensnetzwerken optimieren kann. Der achte und letzte Beitrag gibt
schließlich einen Ausblick auf aktuelle und künftige Entwicklungen, die
durch den Einsatz serviceorientierter IKT realisiert werden.
4
Einleitung
SOA-Check 2010: Status quo – Trends – Perspektiven
Dr. Julian Eckert, SOA Competence Center im httc e.V.
Dr. Nicolas Repp, SOA Competence Center im httc e.V. (ehem.)
Dr. Wolfgang Martin, Wolfgang Martin Team
1.1 SOA-Grundlagen
Unter dem Begriff der „serviceorientierten Architektur“ (SOA) versteht
man ein Architekturparadigma, welches auf Services als Grundbausteinen
basiert. Unter einem Service (Dienst) wird hierbei eine abgeschlossene,
unabhängige funktionale Einheit verstanden, die eine klar definierte
Geschäftsfunktionalität anbietet. Ein Service kann vollständig manuell
erbracht werden, aber auch als funktionale Einheit automatisiert in Form
von Software realisiert werden. Im weiteren Verlauf beschränken wir uns
auf die Anwendung einer SOA bei komplexen Softwaresystemen.
Anders als klassische Softwarearchitekturen, die eine komplette System-
struktur beschreiben, beschränkt sich eine SOA auf den Bereich der
Bereitstellung fachlicher Dienste und Funktionalitäten in Form von
Services – vornehmlich zum Zwecke der Anwendungsintegration und der
Einbindung von externen Services.
Charakterisiert wird eine SOA typischerweise durch drei Rollen:
1. Service-Anbieter
Als Service-Anbieter bezeichnet man in diesem Zusammenhang das Unter-
nehmen oder die Organisationseinheit, welche(s) einen oder mehrere Ser-
vices bereitstellt. Services können sowohl innerhalb eines Unternehmens
oder auch über Unternehmensgrenzen hinweg angeboten werden.
1
5
www.hessen-it.de
2. Service-Nutzer
Der Nutzer der Services wird Service-Nutzer genannt.
3. Intermediär
Optional ist die Rolle des Intermediärs, welcher auch als „Service-Broker“
bezeichnet wird. Ein Intermediär bietet Services verschiedener Anbieter
an und kann darüber hinaus zusätzliche Funktionen, wie beispielsweise
die Abrechnung der Service-Nutzung, übernehmen.
Die Kommunikation zwischen den beteiligten Akteuren (Anbieter, Nutzer
und Intermediär) basiert auf dem Austausch von Nachrichten. Der Anbie-
ter stellt die Implementierung eines Dienstes zur Verfügung und ver -
öffentlicht dessen Beschreibung (z. B. Funktion, Leistungsmerkmale) sowie
eine Schnittstellenbeschreibung in einem Verzeichnis, das von Kunden
durchsucht werden kann. Aufgrund der Beschreibungen ist der Kunde in
der Lage, einen passenden Service auszusuchen, aufzurufen und zu
nutzen. Anbieter und Nutzer können auch miteinander in Kontakt treten.
Zur technischen Realisierung von Softwaresystemen auf Basis des SOA-
Paradigmas haben Web Services an Bedeutung gewonnen. Unter einem
Web Service versteht man hier lose gekoppelte, wieder verwendbare
Softwarekomponenten, die unter Verwendung von Internetstandards
aufgerufen werden können und über den Austausch von XML-basierten
Nachrichten miteinander kommunizieren.
Kernidee des Service-Prinzips ist die lose Kopplung von Services an die
sie nutzenden Applikationen. Die Kopplung im Sinne des Software-
Engine ering ist ein Maß für die Abhängigkeiten der beteiligten Kompo-
nenten. Das Prinzip der losen Kopplung meint, dass der Abhängigkeits-
grad der beteiligten Komponenten relativ gering ist.
6
SOA-Check 2010: Status quo – Trends – Perspektiven
1.2 SOA-Vorteile
Die lose Kopplung der Komponenten erzeugt den Vorteil, dass Services
sehr leicht durch andere Services zur Laufzeit ersetzt werden können, was
die Flexibilität und Agilität der Anwendungen verbessert. Unterstützt wird
dieser Aspekt durch die Ortstransparenz von Services: Verzeichnisdienste
machen den Speicherort transparent. So können Services unabhängig
von ihrem tatsächlichen Ausführungsort dynamisch gefunden und genutzt
werden. Gewissermaßen wird er damit virtualisiert. Was die so genannte
Virtualisierung für die Hardware bedeutet, ist SOA für die Software.
Ein weiterer Vorteil der serviceorientierten Architektur besteht darin, dass
durch das Beziehen einzelner Prozessbausteine von externen Anbietern
eine Kostenreduktion erreicht werden kann, während die Steuerung des
Prozesses im Unternehmen verbleibt. Eine SOA ermöglicht ein Höchst-
maß an Flexibilität und stellt gleichzeitig sicher, dass die Abhängigkeit von
externen Service-Anbietern auf ein Minimum begrenzt wird. Sie ist weit-
aus flexibler als traditionelles Business Process Outsourcing (BPO), das auf
die Auslagerung eines vollständigen Geschäftsprozesses an externe
Dienstleister abzielt. Denn eine SOA ermöglicht ein servicebasiertes BPO,
d. h. Services können dynamisch zur Laufzeit auch von externen Providern
bezogen werden. SOA passt bestens zu SaaS (Software-as-a-Service). SOA
ist die Architektur, SaaS ein Liefermodell für externe und interne Services.
Während mit dem traditionellen BPO nur strategische Entscheidungen
mit Langzeitwirkung möglich waren, können mit dem SOA-Paradigma
auch operative Outsourcing-Entscheidungen getroffen werden, die nur
von kurzer Dauer sind.
7
www.hessen-it.de
1.3 SOA-Marktbefragung
Für den SOA Check 2010 wurden 64 Personen in Unternehmen aus
Deutschland, der Schweiz und Österreich befragt, die sich mit dem
Thema SOA in den jeweiligen Unternehmen beschäftigen. Die Zielset-
zung der Befragung war, die Entwicklung von SOA im Markt gegenüber
den Vorjahren zu dokumentieren. Ferner sollte bei Unternehmen, die eine
SOA-Einführung planen, herausgefunden werden, was deren Ziele und
Erwartungen sind, wie deren Planung für die SOA-Einführung aussieht
und welche Änderungen sich gegenüber den Vorjahren ergeben haben.
Die Zusammensetzung der Stichprobe der Befragung entspricht derjeni-
gen der beiden Vorjahre, womit eine Vergleichbarkeit hergestellt wurde.
36 % der Befragten kommen aus Unternehmen mit bis zu 100 Millionen
Euro Umsatz, 28 % der Befragten aus Unternehmen mit 100 Millionen bis
1 Milliarde Euro Umsatz und 36 % aus Unternehmen mit mehr als einer
Milliarde Euro Umsatz. Aufgeschlüsselt nach der Anzahl der Mitarbeiter
stammen 19 % der Befragten aus Unternehmen mit weniger als 100 Mit -
arbeitern, 23% aus Unternehmen mit 100 bis 1000 Mitarbeitern und 58 %
aus Unternehmen mit mehr als 1000 Mitarbeitern. Das Profil der Befragung
unterstreicht wie in 2009, 2008 und 2007 die Vermutung, dass das Thema
SOA zunächst einmal die großen Unternehmen angeht. Der Anteil der
Befragten aus mittelständischen Unternehmen in 2010 zeigt aber wie
bereits in den beiden Vorjahren, dass SOA auch im Mittelstand ein Thema
ist.
8
SOA-Check 2010: Status quo – Trends – Perspektiven
Die Befragung erfolgte sowohl online unter www.soa-check.eu als auch per
Fragebogen, wobei die Befragung anonymisiert durchgeführt wurde. Um
eine hohe Datenqualität zu gewährleisten, wurden fehlerhafte oder nicht
vollständig ausgefüllte Fragebögen nicht in die Auswertung einbezogen.
Aufgrund der relativ kleinen Stichprobe erhebt diese Marktbefragung
keineswegs den Anspruch repräsentativ zu sein. Die Ergebnisse sind als
ein Trend zu interpretieren, können aber als Anhaltspunkte für eigene
Entscheidungen und Planungen in Sachen SOA genutzt werden.
SOA Check – die Befragung
Online-basierte Befragung im Zeitraum von 02.11.2009 – 08.02.2010
Stichprobe: 64 Personen (© 2010 S.A.R.L. Martin)
Umsatz36% < 100 Mio. €
28% = 100–1.000 Mio. €
36% > 1.000 Mio. €
Mitarbeiter19% < 100
23% = 100–1.000
58% > 1.000
Finanzdienstleister 23%Banken & Finanzen
Dienstleister (ohne Finanzdienstleister) 52%Informationstechnologie, Unternehmensberatung, Logistik, Transport, Medien, Verlagswesen, Unterhaltung, Energieversorgung, Telekommunikation
Automobilbau,Industrie 16 %
Handel3%
Maschinenbau,Chemie, Öl, Gas,Pharma
Öffentliche Verwaltung Öffentliche Verwaltung 3 %
Sonstige3%
und Gesundheitswesen
9
www.hessen-it.de
1.4 Ergebnisse
SOA-Marktentwicklung
Im Folgenden werden das Marktverständnis, die Marktreife und die Markt-
motivation einer SOA erläutert. Das Verständnis einer serviceorientierten
Architektur ähnelt demjenigen der Vorjahre. 69 % (67 % in 2009, 66% in
2008) der Befragten verstehen eine SOA als Unternehmens- oder IT-Archi-
tektur, während 28 % (31 % in 2009 und 28% in 2008) SOA ausschließlich
als Technologie oder Produkte ansehen. SOA wird von insgesamt 71 % als
reines IT-Thema betrachtet (74% in 2009). Die Bedeutung von SOA inner-
halb eines Unternehmens ist für 61% (53 % in 2009 und 52 % in 2008) der
Befragten sehr groß oder mindestens von großer Bedeutung. 26 % (33 % in
2009 und 34 % in 2008) sehen eine mittlere Bedeutung des Themas für ihr
Unternehmen.
Die zunehmende Marktreife wird durch die Antworten auf die Frage
bestätigt, wie lange sich ein Unternehmen bereits mit dem Thema SOA
beschäftigt. 48 % (38 % in 2009 und 33 % in 2008) der Befragten geben an,
dass sie sich seit über zwei Jahren mit dem Thema SOA befassen. Dabei
haben unabhängig von der Unternehmensgröße 52% aller befragten
Unternehmen mehr als 4 Mitarbeiter, die sich mit dem Thema SOA
beschäftigen. In 2009 waren das nur 42%. Entsprechend hat die Anzahl
kleinerer Teams mit bis zu einer Person von 25% in 2009 auf jetzt 18%
abgenommen.
Warum beschäftigen sich Unternehmen überhaupt mit dem Thema, was
sind die Treiber, die strategischen Ziele? Schwerpunkte der Motivation
von Unternehmen bilden die angestrebte höhere Flexibilität mit 29 %, die
Optimierung der Prozesse mit 21 %, eine Verkürzung der Time-to-Market
mit 16 %, die Steigerung des Innovationsgrades mit 10 %, die Steigerung
der Kundenzufriedenheit mit 5%, die Senkung der Kosten mit 5% sowie
die Steigerung der Produktivität mit 2%. Der Einsatz von SOA in Unterneh-
men ist gegenüber dem Vorjahr gestiegen. 63 % (47 % in 2009) setzen
eine SOA schon ein, 31 % (37 % in 2009) sind in der Planung und nur noch
6% (16% in 2009) bleibt ohne SOA-Einsatzplanung.
10
SOA-Check 2010: Status quo – Trends – Perspektiven
Prozentualer Anteil der Befragten in den Jahren 2008 bis 2010,
für die die Bedeutung von SOA innerhalb des Unternehmens von
sehr großer oder großer Bedeutung ist. (© 2010 S.A.R.L. Martin)
20080
10
20
30
40
50
60
70
2009 2010
52% 53%
62%
11
www.hessen-it.de
SOA-Einsatz
In diesem Abschnitt werden Möglichkeiten und Bedingungen für den Ein-
satz einer SOA im Unternehmen analysiert. Hierzu wurden nur Teilnehmer
befragt, die eine SOA bereits einsetzen oder ihren Einsatz planen. Die
Frage nach den Unternehmensbereichen mit der höchsten Bedeutung für
SOA bestätigt die Ergebnisse des Vorjahres. Mit 25% (21 und 19% in den
Vorjahren) wird die IT als Hauptbereich für den SOA-Einsatz identifiziert.
Das unterstreicht die IT-Lastigkeit in der Wahrnehmung des Themas SOA.
Das Thema Produktion folgt hiernach mit 11% (7 % in 2009, 6% in den
Vorjahren), und löst die zweiten Plätze des Vorjahres Vertrieb (10%), Kun-
denservice (7%) und Einkauf (7%) ab.
Der Einsatz von SOA in unternehmensübergreifenden Prozessen ist
besonders im Bereich der Kollaboration beim Ein- und Verkauf ausge-
prägt. Die Kollaboration mit Kunden wird mit 36% (nach 29% in 2009,
30% in 2008 und 32% in 2007) bewertet, diejenige mit Lieferanten mit
23% (nach 23% in 2009, 24% in 2008 und 26% in 2007), die Kollabora-
tion mit der Öffentlichkeit mit 13% (nach 13% in 2009 und 2008 sowie
11% in 2007) und mit sonstigen Händlern mit 10% (nach 14% in 2009,
11% in 2008 und 19% in 2007).
12
SOA-Check 2010: Status quo – Trends – Perspektiven
Auch im SOA Check 2010 zeigt sich der Trend , SOA stark IT-lastig zu
beschreiben. Mit rund 25% (21% in 2009 und 19% in den Vorjahren)
wird die IT als Hauptbereich für den SOA-Einsatz identifiziert, gefolgt
von den Bereichen Produktion, Vertrieb und Logistik.
Wird in Ihrem Unternehmen eine SOA eingesetzt?
(© 2010 S.A.R.L. Martin)
31 % 36 % 47 %63 %
42 %48 %
37 %31 %
27 %16 % 16 %
6 %
0 %
10 %
20 %
30 %
40 %
50 %
60 %
70 %
80 %
90 %
100 %
2007 2008 2009 2010
ja nein, aber Einsatz geplant nein, kein Einsatz geplant
13
www.hessen-it.de
SOA-Governance
Der Governance, d. h. der Kontrolle und Steuerung, servicebasierter Sys-
teme kommt in der Praxis eine immer größere Bedeutung zu. Die Fragen
wurden nur von Teilnehmern der Studie beantwortet, die bereits eine
SOA einsetzen oder ihren Einsatz planen. Im Vergleich zu den Ergebnis-
sen des Vorjahres sind die aktuellen Ergebnisse positiv zu bewerten. 37 %
(nach nur 28% in 2009 und 20 % in 2008) beschäftigen sich mit dem
Thema SOA-Governance bzw. nutzen diese bereits. Nur noch 41 % (nach
66 % in 2009 und 55 % in 2008) geben an, dass eine SOA-Governance in
Planung sei. 22 % sagen allerdings (nach 6 % in 2009 und 24 % in 2008),
dass eine SOA-Governance nicht geplant ist. Bei der eingesetzten Metho-
dologie zur SOA-Governance führen die „eigenen SOA-Governance-
Methoden“ mit 26 % vor ITIL (IT Infrastructure Library) mit 21 % und vor
„allgemeinen modifizierten IT-Governance-Methoden“ mit 12 %. COBIT
(Control Objec tives for Information and Related Technology) kam nur auf
5 %. Der Einsatz von Service Level Agreements (SLAs) zur vertraglichen
Definition von Anforderungen an Services wird nur von 21 % der Befrag-
ten nicht eingesetzt (nach 20 % in 2009). Ebenfalls erfreulich ist die Aus-
sage, dass bereits 48 % der Befragten den Wiederverwendungsgrad von
Services messen. 35 % der Befragten haben bereits eine Referenzarchitek-
tur im Sinne einer globalen Architekturrichtlinie erstellt.
14
SOA-Check 2010: Status quo – Trends – Perspektiven
© remirath
SOA-Projekte
Auch die Fragen zu bestehenden SOA-Projekten und ihrer Projektstruktur
wurden nur von Teilnehmern beantwortet, die bereits eine SOA einsetzen
oder ihren Einsatz planen. Die durchschnittliche Zielerreichung der im
SOA-Projekt definierten Ziele liegt in der aktuellen Befragung bei rund
76%. Das ist an sich kein gutes Ergebnis – im Vergleich zu den Vorjahren
ist aber eine positive Entwicklung feststellbar. 14 % der befragten Unter-
nehmen haben bereits über 10 SOA-basierte Prozesse im Einsatz und
24% bereits mehr als 40 Services. Der hauptverantwortliche Projektleiter
stammt bei 48 % der Befragten immer noch aus dem IT-Bereich (2009:
54%). Der IT-Bereich bleibt der Treiber und Macher in Sachen SOA. Deut-
lich zugelegt haben die internen Fachanwender /Berater, die, nach nur
14% in 2009, bei 26 % der Befragten die Projektleitung innehatten. Das
spricht für einen reifenden Markt. Enttäuschend ist aber der Einfluss auf
Seiten der Organisation, denn Prozess- und Service-Denken erfordern
auch neue Rollen und neue Verantwortlichkeiten, sowohl in den IT- als
auch in den Fachabteilungen. In 46 % der Fälle hat die SOA-Initiative
innerhalb der IT-Abteilung keine neuen Arbeitsbereiche hervorgebracht.
Ähnlich unverändert zeigen sich die Fachabteilungen: in 54% der Fälle
sind hier keine zusätzlichen Rollen und Verantwortlichkeiten entstanden.
15
www.hessen-it.de
© heizfrosch – istockphoto © yurok aleksandrovich – istockphoto
SOA-Organisation
Welche Organisationseinheiten setzen eine SOA um? In 48% (44% in
2009 und 51% in 2008) der Fälle übernimmt dies die interne IT-Abteilung,
in 11% (14% in 2009 und 0% in 2008) sind es Softwareanbieter. SOA wird
in 20% der Fälle als reines IT-Projekt implementiert. In 26 % der Fälle
stimmt sich die IT-Abteilung zusätzlich mit einer Fachabteilung ab, ohne
aber gemeinsam am Thema zu arbeiten.
Beim Sponsorship setzt sich hingegen der Trend zum Besseren fort. Es
gibt eine leichte Steigerung beim CPO (Chief Process Officer) von 5%
(2007 und 2008) über 8% (2009) auf 9% und eine Steigerung bei der
Geschäftsführung von 13% über 16% und 26% auf jetzt 31%. Der Anteil
von CIOs (Chief Information Officer) als Sponsor hat sich stabilisiert bei
34% von 58% (2007) über 40% (2008) und 30% (2009). Die Zahl der
„nicht klar geregelten“ Sponsorships hat zum ersten Male abgenommen
von 21% über 23% und 26% auf jetzt nur noch 14%.
Wer finanziert SOA-Initiativen? Verteilung der Sponsoren (© 2010 S.A.R.L. Martin)
Chief Information Officer (CIO)30%
5%5%
8%
26%
26%
Geschäftsführung
Verantwortlichkeit ist nicht klar geregelt
Chief Process Officer (CPO)
Chief Technology Officer (CTO)
Fachabteilung
16
SOA-Check 2010: Status quo – Trends – Perspektiven
1.5 Fazit
Der SOA Check 2010 unterstreicht deutlich: Das Thema „serviceorien-
tierte Architekturen“ kommt im deutschsprachigen Markt gut an und gut
voran. Die Unternehmen haben in den letzten Jahren erhebliche Fort-
schritte gemacht. Der Einsatz von SOA in den befragten Unternehmen ist
gegenüber 2009 gestiegen. 63 % (47 % in 2009) setzen eine SOA schon
ein, 31 % (37 % in 2009) sind in der Planung und nur ein Rest von 6 %
bleibt ohne SOA-Einsatzplanung.
Das Thema SOA bleibt bei den meisten Unternehmen also gesetzt und
man schreitet in der Umsetzung weiter fort. 9 % der befragten Unterneh-
men gaben an, dass sie sich bereits in der Endphase der Umsetzung einer
SOA befinden und 52 % sehen sich mitten auf dem Weg. 48 % beschäfti-
gen sich seit über zwei Jahren mit SOA. 14 % der Unternehmen, die SOA
betreiben, haben bereits mehr als 10 SOA-basierte Prozesse und über
24 % dieser Unternehmen haben sogar schon mehr als 40 Services im Ein-
satz.
Die Einschätzung der Bedeutung einer SOA ist im deutschsprachigen
Raum nicht mehr vom Hype gekennzeichnet. Sie ist nun realistisch, bleibt
aber immer noch zu IT-lastig. Durch diese IT-geprägte Sicht wird leider der
Blick auf weitergehende SOA-Potentiale für Themen wie beispielsweise
Compliance und Risiko-Management verstellt (siehe hierzu auch Kapitel
4.4, S. 47ff., in dem erläutert wird, dass der volle Nutzen von SOA erst in
einer IT-übergreifenden Betrachtung deutlich wird). Der Nutzen einer
SOA wird in 2010 ähnlich bewertet wie in den beiden Vorjahren: höhere
Flexibilität (29 %), Optimierung der Prozesse (21 %), Time-to-Market (16 %),
Steigerung des Innovationsgrades (10 %), Steigerung der Kundenzufrie-
denheit (5%) und Senkung der Kosten (5%) spielen die wichtigsten
Rollen. Betrachtet man die Anwendungen, wird schnell klar, dass der
Top-Down-Ansatz (SOA-basierte Geschäftsprozesse) weiter auf dem
Vormarsch ist. BPM ist der Business Case für SOA, SOA ist „nur“ die Infra-
struktur dazu.
17
www.hessen-it.de
SOA-Governance ist als Thema angekommen und wird nun endlich ange-
gangen. Hier gab es einen deutlichen Fortschritt gegenüber den beiden
Vorjahren: 37 % der Befragten gaben an bereits eine SOA-Governance
umgesetzt zu haben (gegenüber 28% und 20 %). Auch die Bedeutung
von Service Level Agreements wird zunehmend besser verstanden: Nur
noch 21 % der Befragten verwenden keine SLAs. Der Methoden- und
Werkzeugeinsatz kommt auch voran, aber das Schaffen neuer Rollen und
Arbeitsbereiche setzt erst sehr zögerlich in den IT- und Fachbereichen ein.
Die Zielerreichung bei SOA-Projekten hat zugenommen. Durchschnittlich
werden 76 % der Ziele erreicht. Der Treiber für SOA ist immer noch die
IT-Abteilung. In 48 % der Fälle kommt der Projektleiter aus dem IT-Bereich,
in 44 % der Fälle wird die Implementierung ausschließlich durch die
interne IT-Abteilung gemacht. Auch wenn diese Anteile noch verhältnis-
mäßig hoch erscheinen, ist der Trend hin zu einer geringeren IT-Bedeu-
tung des Themas SOA über die letzten Jahre erkennbar. Das Einbeziehen
der Fachabteilungen in die SOA-Projekte ist bei weitem nicht ausrei-
chend: 20 % der SOA-Projekte sind reine IT-Projekte. Hier liegt ein großes
Verbesserungspotential, das man im Zuge des Fokus auf SOA-Gover-
nance angehen kann.
Der SOA Check 2010 zeigt, dass sich der in 2009 analysierte Trend
auch in 2010 fortsetzt. Das Thema SOA ist bei den Unternehmen
gesetzt und wurde mittlerweile in den Standard-Lösungskatalog
der Unternehmen übernommen. Den „Hype“ der Vorjahre konnte
das SOA-Paradigma ablegen – aus SOA ist ein reifes Architektur -
paradigma geworden, welches in einer Vielzahl von Anwendungen
zum Tragen kommt.
18
SOA-Check 2010: Status quo – Trends – Perspektiven
SOA@Work: Mehr Agilität und Effizienz
Norbert Eder, Software AG
Das Internet ist ein prägender Faktor unserer Zeit. Die Welt entwickelt sich
zur Netzgesellschaft und erhöht als Webciety unseren Lebensstandard.
Die Informations- und Kommunikationstechnologie (IKT)-Branche hat mitt-
lerweile einen Anteil am deutschen Bruttoinlandsprodukt von rund 6 Pro-
zent und bietet 750000 Arbeitsplätze. Dazu kommen die Wertschöpfung
und die Arbeitsplätze in den Anwender branchen: z.B. in Banken und Ver-
sicherungen, in der öffentlichen Hand und der Industrie.
Die Digitalisierung der Wirtschaft hat viele Prozesse dramatisch schneller,
billiger und effizienter gemacht und unzählige neue Produkte und Dienst-
leistungen geschaffen. Hinter diesen digitalen Transaktionen und der
digital erhöhten Produktivität steckt Technologie. Erst durch Technologie
wird die digitale Gesellschaft überhaupt möglich.
In der Informationstechnologie (IT) stehen wir vor einem Paradigmen -
wandel, wie er nur einmal in zehn Jahren stattfindet: von den Anwen-
dungs-Silos hin zur Kollaboration und Flexibilität von IT-Systemen. Diese
innovativen Technologien sind der Motor für die Weiterentwicklung des
Webs und der Wertetreiber der Webciety.
2
19
www.hessen-it.de
© P
erlA
lexa
nder
–is
tock
ph
oto
2.1 Agile Unternehmen sind die Ziele
Im 21. Jahrhundert agieren Unternehmen in einem rauen Geschäftsklima.
Sie müssen sich dem Druck durch scharfen Wettbewerb, zunehmende
Globalisierung und Konsolidierung stellen und auf neue Beziehungs -
muster reagieren, wie etwa Co-opetition, also in einer Firma gleichzeitig
einen Partner und Konkurrenten zu haben. Um diese Herausforderungen
meistern zu können, ist ein Umdenken nötig. Eine hohe Innovations- und
Reaktionsfähigkeit zur langfristigen Generierung von Erträgen ist das
Gebot der Stunde. Dafür ist agiles, flexibles Handeln gefragt. Diese An -
forderungen an das Unternehmen sind in den Geschäftsprozessen abge-
bildet, und die werden nun hinterfragt, neu gestaltet oder optimiert. Tech-
nologien sollen diese Anstrengungen unterstützen.
Geschäftsabläufe, ganz gleich, ob innerhalb eines Unternehmens oder
über Betriebsgrenzen hinweg, müssen transparent, messbar und nachvoll-
ziehbar werden. Dies ist die Voraussetzung für ein agiles, flexibles Unter-
nehmen. Eine serviceorientierte Architektur bildet eine ideale Grundlage
für die durchgängige Prozessgestaltung und ein umfassendes Prozess -
management.
In diesem Umfeld vertrauen Unternehmen heute zunehmend auf das so
genannte Business Process Management (BPM). Eine Studie der Software
AG hat herausgefunden, dass jedes fünfte deutsche Unternehmen der
IT-gestützten Verwaltung von Geschäftsprozessen eine hohe Priorität
einräumt. Das Managementkonzept BPM etabliert eine prozesszentrische
Sichtweise auf das Geschäft und stellt das Messen der Leistung in den
Mittelpunkt. Es umfasst zudem Methoden, Werkzeuge und Technologien,
die verwendet werden, um Betriebsabläufe zu entwerfen, auszuführen, zu
analysieren und zu kontrollieren. Technologien für Prozessmanagement
(BPM-Systeme) müssen auch die Änderung und Optimierung der
Geschäftsabläufe unterstützen, denn Wettbewerbsvorteile entstehen nur
dann, wenn die Prozesse auch fortlaufend an neue Anforderungen ange-
passt werden. Dabei hat sich gezeigt, dass schnelle Änderungen nur
schwer möglich sind, solange die Prozesse in herkömmliche IT-Anwen-
dungen eingebettet sind.
20
SOA@Work: Mehr Agilität und Effizienz
2.2 Flexible Prozesse sind die Lösung
Die Lösung für solche Probleme besteht in einer gesteigerten Flexibilität:
Systeme zur Prozessautomatisierung auf der Basis einer serviceorientier-
ten Architektur (SOA) bieten einen Ausweg, indem sie die Prozessschicht
von den darunter liegenden Anwendungen und der Infrastruktur trennen,
so dass die Geschäftsanwender ihre Prozesse kontrollieren und direkt
ändern können.
Statt fest codierter, starrer Prozessabläufe setzen diese Systeme auf das
Prinzip der Komposition von IT-Fähigkeiten und Informationen, auch als
„Services“ oder „Dienste“ bekannt, um die benötigte Flexibilität zu errei-
chen. Die Verantwortlichen in den Unternehmen erkennen zunehmend
die Vorteile einer SOA. Denn 60 Prozent der befragten Firmen verwenden
bereits eine serviceorientierte Architektur als Grundlage für BPM, wie die
Umfrage der Software AG ergab.
Serviceorientierte Architekturen gelten als das herausragende Gestal-
tungsprinzip zeitgemäßer Softwarelandschaften. Sie bieten eine bessere
Integration auf der Basis von Standards mit verteilten, lose gekoppelten
und nach Bedarf mehrfach verwendbaren Komponenten, welche über
Services miteinander interagieren.
SOA und BPM bilden komplementäre Aspekte, die für eine flexible Unter-
nehmens-IT notwendig sind. Während eine SOA die technologische
Grundlage für das BPM und die Governance bildet (siehe 2.4), liefert BPM
als Geschäftsprozessmanagement den fachlichen Rahmen für die Umset-
zung der Services – abteilungsübergreifend und über Wertschöpfungsket-
ten hinweg. Auch die Geschäftsprozessregeln lassen sich in einer SOA-
Umgebung als technische Services bzw. Web Services bereitstellen und
somit an verschiedenen Stellen im Prozessablauf wiederverwenden. Im
Rahmen von BPM stellt die Fachabteilung Komponenten zu einer Ablauf-
kette zusammen, die dann in der SOA technisch über den Enterprise
Service Bus abgebildet wird.
21
www.hessen-it.de
2.3 BPM und SOA aufeinander abstimmen
Obwohl sich SOA und BPM ergänzen, müssen die Managementaufgaben
und -prinzipien des BPM mit den technischen Prinzipien der SOA abge-
stimmt werden. Dazu gehören die Konzeption einer Architektur in Form
von strategischen Zielen und entsprechenden Prozessen, die Model -
lierung dieser Prozesse als IT-Komponenten und das Aufsetzen einer
Governance inklusive der Definition von Rollen und Verantwortlichkeiten.
Die erste erfolgskritische Aufgabe besteht darin, die für die definierten
Geschäftsziele richtigen Prozesse festzulegen. In einer SOA sind sie der
Ausgangspunkt dafür, Services wiederverwendbar zu machen. Praktiker
wissen: Gerade die Phase des Identifizierens und Modellierens von
Prozessen, die automatisiert und ins Geschäftsprozess-Management ein-
bezogen werden sollen, ist schwierig, weil sie eine enge Zusammenarbeit
zwischen den Fachanwendern, Geschäftsanalysten und der IT-Abteilung
erfordert. Für diese Kollaboration muss eine einheitliche IT-unterstützte
Plattform vorhanden sein, auf der alle Beteiligten miteinander am Design
oder Re-Design von Geschäftsprozessen arbeiten können. Prozessexper-
ten, Geschäftsanalysten und IT-Entwickler sind dann in der Lage, sich wie
in einem virtuellen Meeting über die Prozesse zu einigen, anstatt wie
früher das Design auf dem Papier zu dokumentieren und der IT-Abteilung
zur Umsetzung zu übergeben. Der Vorteil einer digitalen Plattform besteht
darin, dass die Beteiligten den Prozess gleichzeitig aus ihrer jeweiligen
Perspektive sehen können, also z. B. der Analyst aus der Geschäfts -
perspektive und der IT-Fachmann aus der IT-Perspektive. Die Geschäfts-
analysten können in einer solchen, digitalen Umgebung die Prozesse
grafisch modellieren, und die Tools erzeugen daraus Prozessbeschreibun-
gen in Standard-Prozessmodellierungskonventionen und Notationen.
22
SOA@Work: Mehr Agilität und Effizienz
Mit einer integrierten Entwicklungsplattform in einer serviceorientierten
Umgebung werden die Prozessschritte dann in technische Services (Web
Services) umgewandelt und neue Services zusammengebaut (kompo-
niert). Für die Ausführung dieses Prozesses ist eine so genannte BPM-
Engine zuständig. In einer herkömmlichen Architektur werden die
Engines lediglich statische Versionen eines Prozesses ausführen können
und damit der geforderten Flexibilität und Agilität eines Geschäfts ent -
gegenwirken, indem sie dem Unternehmen vorschreiben, wie der Prozess
abzulaufen hat. In einer SOA sind die vorhandenen Daten und die
Funktionalität in Services vorhanden. Diese fügen Unternehmensfachleute
zu so genannten Composite Applications zusammen. Das sind agile
Geschäftsprozesse, die auf der Grundlage von definierten Geschäfts -
prozessen konfiguriert sind. Die Dienste werden öffentlich gemacht und
können dynamisch zu anderen Prozessen mit anderer Logik zusammen-
gesetzt werden. Auf diese Weise liefert dieser neue Typus einer service -
orientierten Geschäftsanwendung (Service Oriented Business Application
– SOBA) einen prozessgetriebenen Ansatz für das Zusammenstellen eines
logischen Informationsflusses aus heterogenen Datenquellen und ist
damit ein erfolgskritischer Treiber für Geschäftsagilität.
23
www.hessen-it.de
© k
ento
h -
Foto
lia.c
om
2.4 Effizienz durch Governance
Schließlich muss es eine Instanz – die Governance – geben, die die
Kom ponenten der serviceorientierten Architektur wie Services, Prozesse
und Regeln, sowie organisatorische Aspekte begleitet. Eine effiziente
Governance definiert aufbau- und ablauforganisatorische sowie techni-
sche Regeln für den gesamten Lebenszyklus einer solchen Landschaft. Zu
den organisatorischen Aspekten gehört beispielsweise das Festlegen der
fachlichen und technischen Verantwortung für einen Service (Ownership).
Ferner werden Rollen definiert, die festlegen, wer für bestimmte Bereiche
verantwortlich ist. Governance lässt sich durch den Einsatz einer Registry in
enger Kombination mit einem Repository für den gesamten Lebenszyklus
der Services umsetzen. Die Registry liefert gleichermaßen eine Kategori-
sierung und eine Organisation der Services. Nutzer können neue Services
im Katalog publizieren und nach vorhandenen suchen. Die Komponenten
können mehrfach kategorisiert werden, um Services einer bestimmten
Service-Domäne, einer fachlichen Funktion oder einem Prozess zuzuord-
nen. So entsteht eine vollständige Dokumentation der Architektur.
Das Repository reichert die Informationen in der Registry um Metadaten
an, also um beschreibende Daten etwa zu Schnittstellen oder Anforderun-
gen an die Komponenten. Das Governance-Repository umfasst ein Infor-
mationsmodell oder eine Taxonomie und zusätzlich Audit-Fähigkeiten für
das Verfolgen von Änderungen an den Services, Identity-Management-
Funktionen und eine rollenbasierte Zugriffskontrolle. Es sollte der gesamte
Lebenszyklus einer Komponente als Workflow mit allen Arbeitsschritten
und den beteiligten Rollen darin abgebildet werden (Lifecycle Manage-
ment). Um eine Synchronisation von Repository und Registry sicherzu -
stellen, empfiehlt es sich, die beiden in einem einheitlichen, auf Standards
beruhenden Informationsmodell mit einem zugehörigen Datenspeicher
zusammen zu führen. Damit sind Governance-bezogene Metadaten und
das Informationsmodell konsistent in einem Speicher vereint, und die An -
wender erhalten ein einziges System für die Verwaltung aller Informatio-
nen bezüglich der SOA-Komponenten und der Governance-Metadaten.
24
SOA@Work: Mehr Agilität und Effizienz
2.5 Fazit
Die IT-Landschaft vieler Unternehmen basiert heute häufig noch auf IT-
Silos. Gefragt und gewünscht sind jedoch effiziente Prozesse, die unter-
nehmensübergreifend wirksam werden und sowohl Zulieferer als auch
Geschäftspartner einbinden. Unternehmen erkennen immer mehr:
Erstklassige Prozesse sind genau so wichtig wie erstklassige
Produkte, und innovative Prozesse sind die Grundlage für
erstklassige Geschäftserfolge.
Genau darum geht es beim Business Process Management und bei service-
orientierten Architekturen. BPM und SOA sind keine rein technische Auf-
gabe, die durch neue Produkte oder Dienstleistungen gelöst werden kön-
nen. Das Management von Geschäftsprozessen und serviceorientierten
Architekturen ist von Natur aus eine soziale Aktivität. Ein erfolgreicher Pro-
zess sollte jeden Beteiligten berücksichtigen. Idealerweise kollaborieren
alle Ebenen gleichberechtigt, vom Angestellten bis zum Vorstand, um
einem Projekt und den damit verbundenen Geschäftsprozessen den opti-
malen Mix aus Wissen, Erfahrung und persönlichem Einsatz in kürzester Zeit
und zu den geringst möglichen Kosten zuteil werden zu lassen. Bisherige
Lösungen konzentrierten sich vielfach auf die Installation verschiedener, nur
wenig kompatibler Tools durch IT-Abteilungen auf den Desktops der Betei-
ligten. Das Ergebnis führte jedoch kaum zu den gewünschten Erfolgen
einer echten, unternehmensübergreifend arbeitenden sozialen Gemein-
schaft, deren Teilnehmer gleichermaßen Interesse am Projekterfolg haben.
Die optimierte interne und externe Kollaboration von Experten und die
damit entstehenden „fließenden“ Teams, die über Unternehmensgrenzen
hinweg gemeinsam ohne Reibungsverluste an BPM- und SOA-Projekten
arbeiten, werden in Zukunft darüber entscheiden, ob und inwieweit Pro-
zesse verbessert werden können.
25
www.hessen-it.de
SOA-Starter Kit: Think big, start small, show quick success
Markus Ganß, Opitz Consulting Bad Homburg GmbH
3.1 Einsatzbereiche
Als IT-Architektur und Managementkonzept bedeutet eine SOA in vielen
Einsatzbereichen die richtige Wahl. Grundsätzlich sprechen nicht die
Unternehmensform oder -größe für oder gegen den Einsatz einer
SOA, sondern allein die Herausforderungen eines Unternehmens und
die daraus abgeleiteten Anforderungen. Bei folgenden Aufgaben und
Lösungsansätzen sollte der Einsatz einer serviceorientierten Architektur
geprüft und bewertet werden:
a Integrationsszenarien
Ein typisches Ziel von Integrationsszenarien ist es, Daten über Unter-
nehmensanwendungen hinweg möglichst in Echtzeit zu synchronisie-
ren und konsistente Zustände zu bewahren. Im Rahmen einer SOA
kann mit einem Enterprise Service Bus (ESB) die Kommunikation
zwischen Systemen koordiniert werden. So wird die Konsistenz und
Genauigkeit von Daten auch über Systemgrenzen hinweg sicher -
gestellt.
a Entwicklung individueller Anwendungen
Bei der Entwicklung von individuellen Anwendungen sollte von
Beginn an darauf geachtet werden, die enthaltenen Geschäftsfunktio-
nen der Anwendung im Rahmen von Services bereitzustellen, um
durch die lose Kopplung von Modulen die Wartbarkeit und Wieder-
verwendbarkeit der Anwendung und ihrer Module zu erhöhen. Dabei
muss die zusätzliche Investition bei der Erstellung der Anwendung
natürlich über eine ROI-Berechnung gerechtfertigt sein.
3
26
SOA-Starter Kit: Think big, start small, show quick success
a Prozessautomatisierung
Durch die Automatisierung von Geschäftsprozessen unter Einbezie-
hung von Anwendungen, Systemen und Personen lässt sich die Pro-
zessproduktivität verbessern. Die Transparenz der Unternehmenspro-
zesse wird gesteigert und die Agilität der Prozesse wird erhöht.
a Prozessportale
Durch Prozessportale können manuelle und automatisierte Geschäfts-
prozesse über Anwendungen hinweg angestoßen, betrieben und ver-
folgt werden. Auch hierdurch wird die Produktivität und Transparenz
der Prozesse erhöht.
a Business Activity Monitoring
Das Business Activity Monitoring sammelt zur Laufzeit der Prozesse
die Prozessdaten und berechnet in Echtzeit die Key Performance Indi-
katoren (KPI). Auf dieser Basis können dann Prozessoptimierungen
durchgeführt werden. Die Daten werden integriert in so genannten
Dashboards dargestellt und dienen zur verbesserten und zeitnahen
Entscheidungsfindung.
a Business-to-Business Integration
Die Einführung einer SOA sollte auf jeden Fall auch bei der Anforde-
rung einer Business-to-Business Integration geprüft werden. Ziel die-
ser Integration ist es, Geschäftspartner in die Geschäftsprozesse des
Unternehmens zu integrieren. So können die Kosten innerhalb der
Wertschöpfungskette eines Unternehmens gesenkt werden.
27
www.hessen-it.de
Über diese genannten Bereiche hinaus finden sich in vielen Unternehmen
weitere Anforderungen und Ansatzpunkte, die mit einer SOA unterstützt
werden können. Dabei bedarf es einer individuellen Analyse der Anforde-
rungen. Weitere klassische Indikatoren für den möglichen Einsatz einer
SOA sind folgende Aspekte:
a Verteilte Systeme
a Verteilte Verantwortung (bereichsübergreifend)
a Heterogene Systemlandschaft
Es gibt auch Anforderungen, die durch eine SOA nicht optimal abgedeckt
werden können. Beispiele hierfür sind:
a Der Austausch großer Datenmengen, z. B. über Datenbankreplikationen
a Die Anbindung von Anwendungen auf lokalen Clients
3.2 Dimensionen und Ziele
Im Rahmen einer serviceorientierten Architektur sind drei verschiedene
Betrachtungs- und Handlungsdimensionen zu beachten:
SysteminfrastrukturLaufzeitumgebung,Systemintegration
ServiceentwicklungStandards, Service Orchestrierung
Systemmanagement SLA, Sicherheit,Performance
SOA ist einTechnologiekonzept
SOA ArchitekturEnterprise Architecture,Integrierte Geschäfts-prozess- und IT-Architektur
SOA Methodik Service-Identifikation,-Klassifikation und-Portfoliomanagement
SOA ist einArchitekturkonzept
SysteminfrastrukturSOA GovernanceRichtlinien
SOA StrategieSOA Maturity ModelSOA Assessment
SOA Organisation Rollen und Aufgaben
SOA erfordert einOrganisationskonzept
28
SOA-Starter Kit: Think big, start small, show quick success
a Dimension Organisation
SOA erfordert ein Organisationskonzept, um eine strategische
Ausrichtung, einen formalen Handlungsrahmen und eine organisa -
torische Gestaltung bzw. Implementierung bereitzustellen.
a Dimension Architektur
SOA ist Teil einer Unternehmensarchitektur (Enterprise Architecture),
in der u. a. die Geschäftsprozess- und IT-Infrastrukturen abgebildet
und zueinander in Beziehung gesetzt werden. Darüber hinaus bietet
eine SOA Methodikansätze zur Identifikation, Klassifikation und zum
Management von Services.
a Dimension Technologie
SOA ist ein Technologiekonzept, das eine Systeminfrastruktur und ein
Systemmanagement bereitstellt, um serviceorientierte Anwendungen
implementieren und betreiben zu können.
Diese drei Dimensionsebenen machen deutlich: SOA ist mehr als nur das
nächste Infrastrukturprojekt – es ist ein fachlich orientierter Management-
ansatz, der in der Unternehmensarchitektur und der technischen IT-Infra-
struktur umgesetzt wird.
Ein übergeordnetes Ziel, das jeder SOA-Ansatz verfolgt, ist die Beherr-
schung der heterogenen Systemlandschaften im Unternehmen. Die Rea-
lität zeigt heute vielfach Anwendungslandschaften mit proprietären
Schnittstellen, vielen verschiedenen Plattformen und unübersichtlichen
Interaktionen zwischen diesen Anwendungen und Systemen.
29
www.hessen-it.de
Weitere Ziele bilden die Lösung von Herausforderungen, die mit der
Heterogenität eines IT-Systems oft in unmittelbarem Zusammenhang
stehen, wie etwa:
a kaum Wiederverwendung
a kurze Technologiezyklen / keine Adaption neuer Technologien /
eingeschränkte Innovationsfähigkeit
a keine bzw. undokumentierte Schnittstellen
a verteilte Anwendungslogik in grafischen
Benutzeroberflächen und in der Middleware
a keine B2B- / B2C- / Multikanalfähigkeit
a hohe IT-Kosten
a geringe Umsetzungsgeschwindigkeit / fehlende Flexibilität
Zu Visionen und Strategien, die bei der Einführung einer SOA eine Rolle
spielen können, gehören:
a Kopplung von Geschäftsprozessen und IT-Prozessen
(Business-IT Alignment)
a Interoperabilität von Standardsoftware
bzw. individuellen Kernapplikationen
a Prozesscontrolling und -optimierung
a Komplexität reduzieren und Transparenz schaffen
30
SOA-Starter Kit: Think big, start small, show quick success
3.3 Komponenten
Eine serviceorientierte Architektur kann im einfachsten Fall aus einzelnen
Services bestehen, die lose gekoppelte Funktionalitäten zur Wiederver-
wendung bereitstellen. Ein Service ist eine spezielle Softwarekomponente
mit einer wohl-definierten Funktionalität, die von anderen Softwarekom-
ponenten lokal oder über ein Netzwerk mit einer zuvor fest definierten
Schnittstelle genutzt werden kann. Funktionalität bezeichnet dabei die
Fähigkeit einer Komponente, eine oder mehrere Aufgabe(n) zu lösen.
Um Punkt-zu-Punkt-Verbindungen zwischen einzelnen Services zu vermei-
den, kann ein Enterprise Service Bus (ESB) eingesetzt werden. Der Ser-
vicebus ist eine logische Architektur, die konform zu den SOA-Prinzipien
eine Integrationsinfrastruktur bereitstellt. Ein ESB bietet zum Beispiel
Möglichkeiten, über Adaptoren andere Standardanwendungen (SCM,
CRM, ERP) anzusprechen. Er garantiert zudem die Einhaltung von Secu-
rity-Richtlinien und stellt Oberflächen für das Monitoring bereit. Somit
übernimmt er das Management der Integrationsinfrastruktur.
ServiceOrchestrierungServiceregistry
SCM Check CreditService
WebshopClient
Monitoring
Servicebus
Security
31
www.hessen-it.de
Zu den typischen Aufgaben eines ESB gehören:
a Transformation der verschiedenen Protokolle
und Nachrichtenformate (Meditation)
a Routing von Nachrichten
a Bereitstellung von Adaptoren zur Anbindung verschiedener Systeme
a Verbergen der eigentlichen Service Provider
vor den Service Consumern (Service-Virtualisierung)
a Monitoring
a Security
Einzelne Services können über eine Serviceorchestrierung zu höherwerti-
gen (composite) Services kombiniert werden, um z. B. eine Geschäftsfunk-
tion bereitzustellen. Hierfür werden BPM (Business Process Management),
BPEL (Business Process Execution Language) oder klassische Workflow -
systeme genutzt.
Eine Service-Registry ist ein Verzeichnis von Serviceinformationen. Es bein-
haltet alle Informationen, um einen Service zu finden und zu nutzen. Das
Registry kann noch Informationen zum Servicevertrag beinhalten. Typische
Inhalte einer Service-Registry sind Angaben in folgenden Bereichen:
a Servicevertrag
a Serviceschnittstelle
a Sicherheit (verwendetes Sicherheitssystem, Rechte etc.)
a Leistungsmerkmale (Performanz, Skalierbarkeit etc.)
a Ansprechpartner
a Fachliche Fragen und Änderungswünsche,
welche die Geschäftslogik betreffen
a Technische Fragen und Änderungswünsche,
welche die Implementierung betreffen
a Informationen über den Ort, an dem der Service
zurzeit bereitgestellt ist (oder über einen ESB-Endpunkt)
32
SOA-Starter Kit: Think big, start small, show quick success
3.4 Der erste Service
Grad der SOA-Basierung im Unternehmen
Wenn ein Unternehmen eine SOA einsetzen möchte, muss es eine SOA-
Strategie entwickeln. Die Einführung einer SOA erfolgt über einzelne
Projekte und sollte daher im Rahmen einer Roadmap definiert werden.
Die ersten SOA-Projekte enthalten meistens noch nicht alle Komponenten
einer unternehmensweiten SOA (Enterprise SOA) und manche Unterneh-
men müssen und wollen diese Ausbaustufe auch gar nicht erreichen.
Vielfach ist schon eine SOA in kleinerem Umfang (SOA lite) die richtige
Wahl, weil sie adäquate Lösungen für die gestellten Aufgaben und An -
forderungen liefert.
Erfüllungsgrad
SOA lite Enterprise SOA
33
www.hessen-it.de
Eine SOA lite setzt bereits erste leichtgewichtige Web Services ein, bei
denen eindeutige Schnittstellendefinitionen erstellt werden. Oft findet
man in dieser Ausbaustufe noch keinen ESB, sondern benutzt Punkt-zu-
Punkt-Verbindungen zwischen einzelnen Applikationen. Das Thema SOA-
Governance beschränkt sich auf die Richtlinien für die Schnittstellen -
definitionen und eventuell auf Namenskonventionen. Auf dieser Ebene
setzt man häufig Open Source-Werkzeuge für die technische Einführung
der SOA ein.
Eine Enterprise SOA bildet die strategische Plattform für die Architektur
der Unternehmensanwendungen. Es werden komplexe Integrations -
szenarien mit Hilfe von Middleware-Infrastrukturen und SOA-Suiten von
kommerziellen Herstellern umgesetzt. Die Organisation des Unterneh-
mens ist hier durch die SOA-Governance verändert und neue Rollen,
Verantwortlichkeiten und Prozesse sind etabliert.
Das Ziel einer SOA-Einführung besteht darin, den für die
individuelle Situation eines Unternehmens adäquaten
Erfüllungsgrad zu finden und nicht darin, den höchstmöglichen
Erfüllungsgrad zu erreichen.
Ist Ihr Unternehmen auf die Einführung einer SOA vorbereitet?
Wenn ein Unternehmen eine serviceorientierte Architektur einführen
möchte, sollte dies zunächst in kleinen Schritten geschehen. Ein klassi-
scher Ansatz ist die Durchführung eines SOA-Pilotprojekts:
34
SOA-Starter Kit: Think big, start small, show quick success
ZielSOA Pilotprojekt
SOA Pilotprojekt
SOA Starter Kit
Ergebnisorientierter und pragmatischerAnsatz für die Evaluierungs- oderStartup-Phase Ihres SOA-Vorhabens
NutzenSOA in der Praxis an Hand eines klarabgegrenzten Problemfalls kennenlernen
Praxiserfahrung in relevanten Methodenund geeigneten Werkzeugen sammeln
Erkenntnisse für das weitere Vorgehen inIhrem SOA-Vorhaben erarbeiten
Ausarbeitung einer greifbaren Nutzenargumentation inRichtung Fachbereiche und Management: Was bringt SOA exakt für uns?
SOA-Pilot als ein sinnvoller erster Schritt in RichtungIhres Gesamtvorhabens
Attraktives Kosten-Nutzen-Verhältnis durchergebnisorientierte Umsetzung mit kurzer Laufzeit
Klare Fokussierung auf Vorgehensweise und Methodik,da technische Rahmenbedingungen vorgegeben sind
AuswertungSOA-Pilot
SOA-Nutzen-argumentation
Modul 10: Sammlung Lessons Learned
Modul 11: Ausarbeitung Nutzenargumentation für SOA-Gesamtvorhaben
PlanungSOA-Pilot
ProjektRoadmap
Modul 1: Auswahl eines geeigneten SOA-Piloten
Modul 2: Zieldefinition und Abgrenzung
Modul 4: Erstellung Projekt-Roadmap
Modul 3: Ausrichtung der Strategie für SOA-Gesamtvorhaben optional
DurchführungSOA-Pilot
LauffähigeServices
Modul 5: Analyse und Modellierung des neuen Anwendungsfalls
Modul 6: Review eines bestehenden Anwendungsfalls
Modul 7: Service-Modellierung
Modul 8: Service-Implementierung
Modul 9: Service-Rollout
optional
optional
www.hessen-it.de
Eigenschaften des ersten Services und dessen Umsetzung
Services, die als SOA-Pilotprojekt umgesetzt werden, sollten folgende
Eigenschaften besitzen:
a Hohe Sichtbarkeit
a Managementunterstützung
a Klar abgegrenzter Problemfall
a Geringer Abstimmungsaufwand
a Nicht geschäftskritisch
Die hohe Sichtbarkeit erleichtert die Nutzenargumentation im Anschluss an
das SOA-Pilotprojekt. Sie fördert die notwendige Managementunterstüt-
zung für das weitere SOA-Vorhaben. Der oder die Service(s) sollte(n) einen
klar abgegrenzten Problemfall beschreiben, um zu Beginn einen möglichst
geringen Abstimmungsaufwand zu ermöglichen. Es ist sinnvoll, anfangs
einen nicht-kritischen Geschäftsfall zu implementieren, um sich hierdurch
nicht einer unnötigen Drucksituationen auszusetzen. Die Ergebnisse des
SOA-Pilotprojekts dienen als Entscheidungsgrundlage für das Unterneh-
men, ob es weiterhin eine Strategie auf Basis einer serviceorientierten Archi-
tektur verfolgen sollte. Insgesamt gilt für das Vorgehen beim Pilotprojekt:
Einbettung des SOA-Piloten in Ihr SOA-Gesamtvorhaben
Sobald das SOA-Pilotprojekt abgeschlossen ist, existiert eine Entschei-
dungsgrundlage für das weitere Vorgehen. Wenn positiv entschieden wurde
und eine Roadmap erstellt wurde, um die geplante SOA-Strategie umzuset-
zen, geht es an die Einbindung von SOA in weitere Projekte des Unterneh-
mens. Ein iterativer, der Roadmap folgender Ansatz hat sich klar bewährt:
Think big, start small,
show quick success
36
SOA-Starter Kit: Think big, start small, show quick success
Im Rahmen der weiteren SOA-Projekte baut man die SOA-Architektur mit
immer weiteren Komponenten aus, überprüft und verfeinert die SOA-
Governance und integriert SOA im Rahmen des Change Managements in
das Unternehmen. Wichtig ist immer wieder, das Erreichte zu überprüfen,
den Erfolg anhand von definierten Indikatoren zu bewerten und korrigie-
rend einzugreifen, wenn neue Anforderungen oder Rahmenbedingungen
die Roadmap zur Erreichung der geplanten serviceorientierten Architek-
tur beeinflussen.
3.5 Fazit
Moderne serviceorientierte Architekturen halten in allen Unternehmens-
formen und -größen Einzug. Erfolge erzielen diejenigen Projekte, die
schnell einen Mehrwert für die Fachbereiche erzeugen und vom Manage-
ment entsprechend unterstützt werden.
Wer versucht, eine SOA durch ein einzelnes Projekt oder eine neue Tech-
nologie einzuführen, gerät meistens in eine Sackgasse. Es gibt nur wenige
SOA-Initiativen, die mit diesen Ansätzen dauerhaft erfolgreich waren.
Deswegen ist die Einbettung des SOA-Pilotprojekts in die Gesamtstrate-
gie des Unternehmens entscheidend. Nur wenn dessen strategische Ziele
und deren konkrete Machbarkeit durch das Pilotprojekt unterstützt wer-
den, leistet SOA einen wichtigen Beitrag zum Unternehmenserfolg.
Gesamtvorhaben
SOAStarter
Kit
Lessons
Learned
Lessons
Learned
SOA-Projekt
Lessons
Learned
Lessons
Learned
Pilot-Projekt
Lessons
Learned
Lessons
Learned
SOA-Projekt
37
www.hessen-it.de
SOA-Kommunikation: „Wie überzeug’ ich meinen Chef?“
PD Dr. Ralf Helbig, Detecon International GmbH
Wer seinen Chef überzeugen möchte, in eine SOA-Initiative zu investie-
ren, sollte zuerst einige Voraussetzungen schaffen. Innerhalb der IT-Abtei-
lung ist zunächst ein gemeinsames Verständnis von SOA zu erzeugen und
Einigung zu erzielen, welchen Nutzen SOA für das Unternehmen haben
kann. Hierbei ist es unerlässlich, den Nutzen aus der Geschäftsperspektive
zu betrachten. Das heißt, es muss deutlich werden, welche Kosten invol-
viert sind, ob und in welchem Ausmaß Einsparungen realisiert werden
können und worin der geschäftliche Nutzen von SOA darüber hinaus
besteht. Erst dann wird es wichtig, dem Management zu veranschauli-
chen, wie SOA funktioniert und wie man die monetären und qualitativen
Vorteile von SOA der Fachseite und dem Chef vermitteln kann, so dass
dieser eine Bereitschaft für Investitionen zeigt.
4.1 Die optimale SOA-Initiative
Serviceorientierung benötigt einen Kunden, der Services anfragt, und
einen Lieferanten, der auf einen funktionierenden Betrieb zugreifen kann.
Es macht keinen Sinn, Entscheidungsträger allgemein von SOA über -
zeugen zu wollen, ohne dass sie den konkreten Nutzen vor Augen haben.
Im ersten Schritt ist es daher wichtig zu verstehen, wer die Kunden von
Services sind und welche Anforderungen sie an diese stellen. Im zweiten
Schritt ist dann zu untersuchen, welche Auswirkungen eine Serviceorien-
tierung auf den eigenen Betrieb und dessen Architektur hat.
4
38
SOA-Kommunikation: „Wie überzeug’ ich meinen Chef?“
Der Service zwischen Kunde und Lieferant
Die Abbildung zeigt zwei Elemente einer serviceorientierten Architektur.
Auf der einen Seite sind Kunden, die Erwartungen an IT-Dienstleistungen
haben, die mehr oder weniger konkret artikuliert werden. Auf der ande-
ren Seite stellt sich die Frage, wie die Servicedienstleistung vom Lieferan-
ten mit seiner IT-Fabrik erbracht werden kann. Hierbei ist es für ihn wichtig
zu wissen, wie weit die momentane IT von einer serviceorientierten Archi-
tektur entfernt ist.
Der Nutzen einer serviceorientierten Architektur besteht vor allem in der
erhöhten Flexibilität der IT, die dann entsteht, wenn sie erst einmal umge-
setzt ist. Die Migration von einer herkömmlichen Architektur zu einer SOA
bzw. deren Aufbau ist aber in der Regel aufwendig, da viele Vorarbeiten
und Analysen notwendig sind. Daher ist es von Vorteil, einzelne Bereiche
zu identifizieren, die von den Vorteilen einer SOA maximal profitieren.
IT-ArchitekturLieferant
orientiert an
Erwartungen
Kunde
Service
39
www.hessen-it.de
Eine SOA setzt eine hohe Transparenz und ein gutes Verständnis der
Applikationsarchitektur voraus. Weiterhin benötigt SOA eine redundanz-
freie Strukturierung der benötigten geschäftsfachlichen und technischen
Fähigkeiten sowie der Informationsobjekte. Wenn diese Voraussetzungen
erfüllt sind, können
a Redundanzen schnell erkannt werden,
a (dadurch) unnötige Komplexität reduziert werden,
a IT-Kosten transparent gemacht werden
a und eine Standardisierung vorangetrieben werden.
So stellt eine serviceorientierte Architektur auf der einen Seite maximale
Effektivität sicher, indem sie die angebotenen fachlichen und technischen
Services optimal auf die Kundenerfordernisse abstimmt. Auf der anderen
Seite leistet sie höchste Effizienz durch eine überlappungsfreie und
redundanzfreie Definition der Services, welche die Voraussetzung für eine
effiziente Produktion bildet.
Nutzenpotentiale einer serviceorientierten Architektur
IT-ArchitekturLieferant
orientiert an
Erwartungen
Kunde
Service
Komplexität
Variantenvielfalt
Kosten
Zeit
Flexibilität
Qualität
Kundenorientierung
Standardisierung
EffizienzEffektivitätEnabler
40
SOA-Kommunikation: „Wie überzeug’ ich meinen Chef?“
Die Abbildung verdeutlicht diesen angesprochenen Zusammenhang und
benennt wesentliche allgemeine Nutzenpunkte, die durch SOA erzielt
werden können – wie die bereits erwähnte Reduzierung der Komplexität
durch eine Verringerung der Variantenvielfalt und der Redundanzen, die
Einsparung von Kosten und Zeit und die damit einhergehende erhöhte
Flexibilität, wenn SOA realisiert ist. Auch die Qualität kann durch SOA
mittels einer konsequent, am Kunden ausgerichteten Standardisierung
gesteigert werden.
Diese genannten Vorteile einer serviceorientierten Architektur dürften zu
allgemein sein, um Ihren Chef zu überzeugen. Deswegen sollten sie für
bestimmte Geschäftsbereiche konkretisiert und auf den greifbaren bzw.
monetären Nutzen heruntergebrochen werden. Beispielhafte Ergebnisse
könnten sein, dass die Projektkosten um ein Viertel reduziert und die Pro-
jektdauer verkürzt werden.
Es ist wichtig zu prüfen, welche Ziele auf der Fachseite bestehen und ob
diese von einer SOA profitieren. SOA nutzt einem stabilen Geschäft, das
kaum Änderungen unterliegt, weniger als einem, das mit kurzen Time-to-
Market-Zyklen neue Produkte auf den Markt bringen muss. Für ein erfolg-
reiches unternehmensinternes SOA-Marketing ist es deshalb entschei-
dend, diejenigen Unternehmensbereiche zu identifizieren, die von einer
serviceorientierten Architektur am meisten profitieren.
41
www.hessen-it.de
4.2 Geschäftsanforderungen
Für das Aufsetzen einer SOA ist es notwendig, Beziehungen transparent
zu machen. In Unternehmen werden zwar häufig Prozesse modelliert, in
der Regel existiert aber kein systematisches, zentrales Ordnen von
Geschäftsanforderungen. Genau dies ist aber die Voraussetzung für die
Identifikation von Fachservices und für das Erkennen von potenziellen
Kandidaten für eine Wiederverwendbarkeit. Es wird ein logisches Modell
benötigt, das die für ein erfolgreiches Betreiben eines Unternehmens
erforderlichen Fähigkeiten und Funktionen überschneidungs- und redun-
danzfrei definiert und ordnet. Diese logische Strukturierung in Bezug auf
Funktionen und Informationen dient als Speicher für Geschäftsanforde-
rungen und hilft, die Geschäftsanforderungen – also die Nachfrage – in
darauf abgestimmte IT-Dienstleistungen – also in ein passendes Angebot
– zu übersetzen.
Aufbau einer SOA-getriebenen Unternehmensarchitektur mit
einem logischen funktionalen Domänenmodell zur Übersetzung der
Geschäftsanforderungen sowie einem logischen technischen Domänenmodell
zur Strukturierung der Applikationsanforderungen
42
SOA-Kommunikation: „Wie überzeug’ ich meinen Chef?“
Wie in der Abbildung ersichtlich, dient das logische funktionale Domä-
nenmodell als Verbindungsglied zwischen Prozessen und Anwendungs-
services. Durch die Zuordnung der Fähigkeiten und IT-Funktionen zu
Prozessen entsteht ein Baukastensystem. Dieses ermöglicht:
a die Prozesse zusammenzufügen und zu orchestrieren,
a die Anforderungen aus den Prozessen zu systematisieren,
konsolidieren und in die IT zu kanalisieren,
a Hoheiten über Daten zu definieren sowie
a Schnittstellen effizient zu systematisieren und zu organisieren.
Das Leistungsportfolio der IT mit seinen Applikationen und Services kann
über das Domänenmodell optimiert und auf die Erfordernisse des Ge -
schäfts ausgerichtet werden.
Eine ähnliche Systematik bietet sich, wie die Abbildung zeigt, auch zur
Gestaltung der technischen Infrastruktur an, die einen Fachservice unter-
stützt. Auch hier lässt sich an der Schnittstelle von Applikationen zur tech-
nischen Infrastruktur eine Übersetzungsebene einziehen. Diese ordnet
die prinzipiell benötigten, technischen Fähigkeiten in technischen Domä-
nen. Sie dienen als Speicher für die Anforderungen der Applikationen
und helfen logische Kombinationsmuster zu definieren, die unterschiedli-
che Applikationsarchitekturen unterstützen. Auch hier dienen die Muster
dazu, eine strategische Ausrichtung der technischen Infrastruktur auf die
eher nicht-funktionalen Erfordernisse des Geschäfts zu erreichen. Darüber
hinaus wird durch die logische Betrachtung mit der Orientierung an fest-
gelegten Mustern eine maximale Standardisierung bis in die Implemen-
tierungswelt hinein erreicht. So werden durch maximale Transparenz in
der jeweiligen Architekturebene Hebel für eine sinnvolle, am Geschäft
ausgerichtete Standardisierung und Effizienzsteigerung identifiziert. Darü-
ber hinaus werden durch die Transparenz der Beziehungen zwischen den
Architekturebenen über die logischen Modelle Ursache- / Wirkungsbezie-
hungen deutlich, die dann ein konsequentes Ausrichten auf die Anforde-
rungen des Geschäfts ermöglichen.
43
www.hessen-it.de
4.3 Argumentationsstrategie
Für ein wirksames internes Marketing einer SOA-Initiative ist es wichtig,
sich zuvor Verbündete vor allem auf der Geschäftsseite zu suchen. Hierfür
ist es hilfreich, nicht gleich für das gesamte Unternehmen, sondern gezielt
für einzelne Bereiche den konkreten Nutzen konsequent qualitativ und
vor allem monetär zu spezifizieren. Der monetäre Nutzen kann durch
Architekturmodelle ermittelt werden, die es ermöglichen, verschiedene
Kostenblöcke der IT einzelnen Produkten zuzuordnen. Für eine solche
Analyse muss SOA auf einzelne IT-Services bezogen werden. So kann
berechnet werden, dass z. B. die Time-to-Market-Spanne um 50 % redu-
ziert wird, wenn man SOA auf einen IT-Service anwendet.
SOA-basiertes Kosten- und Preismodell
BusinessCapability
700.000 €
BusinessCapability
100.000 €
InfrastructureCapability
200.000 €
InfrastructureCapability
300.000 €
3 other
300.000 €
300.000 €
400.000 €
300.000 € 100.000 €400.000 €
400.000 €
2 other2 otherABB costs 500.000 €
200.000 €200.000 € 100.000 €
44
SOA-Kommunikation: „Wie überzeug’ ich meinen Chef?“
Ein Kosten- und Preismodell wie in dieser Abbildung dargestellt basiert auf
den Verknüpfungsinformationen zuvor beschriebener Modelle. Dadurch
können Kosten der IT auf Funktionen, die für das Geschäft verständlich
sind, zusammengefasst und dargestellt werden. Dies steigert die monetäre
Transparenz über die Wirkung von Änderungen auf der Produkt- und Pro-
zessebene sowie auf der Applikations- und Technologieebene. Die durch
ein derartiges Kostenmodell geschaffene Transparenz erlaubt eine Ergeb-
nissicht auf einzelne abgegrenzte Teilbereiche. Optimale, klar abge-
grenzte, sehr fokussierte und zielgerichtete SOA-Projekte können so iden-
tifiziert und mit begrenztem Aufwand und Risiko umgesetzt werden. Man
muss damit nicht einen generellen SOA-Ansatz für die gesamte Unterneh-
mung mit relativ unspezifischen Investitionen verkaufen, sondern kann
ganz fokussiert „SOA-profitable“ Bereiche identifizieren, in denen SOA mit
der beschriebenen Kosten- und Nutzen-Transparenz nachweislich den
maximalen Nutzen produziert. Mit diesen kleineren, fokussierten Maßnah-
men ist die Schwelle für die Genehmigung von Mitteln geringer, weil diese
dann nachweislich profitabel eingesetzt werden.
Indem man die SOA auf einen konkreten Geschäftsbereich anwendet,
wird ein ansonsten vager Nutzen für die Geschäftsleitung konkretisiert
und greifbar. Wenn beispielsweise ein Geschäftsbereich wie Sales oder
Billing identifiziert wird, der mit sehr kurzen Time-to-Market-Anforderun-
gen konfrontiert ist, fällt es nicht schwer, den Nutzen überzeugend zu
kommunizieren und Verbündete zu gewinnen.
Durch die Verknüpfung strategischer Ziele des Unternehmens mit denen
einzelner Stakeholder, zu denen SOA nachweislich einen direkten Wert-
beitrag liefert, wird Aufmerksamkeit auf der Geschäftsseite erzeugt und
die Bereitschaft geschaffen, in derartig werthaltige, abgegrenzte Maßnah-
men mit überschaubaren Risiken zu investieren. Hat man einen solchen
Nutzen aufgezeigt, quantifiziert und überzeugend vermittelt, ist es bei der
Umsetzung dieser Maßnahme wichtig, die Realisierung dieses Nutzens
bei der Implementierung nachzuweisen.
45
www.hessen-it.de
Dieser Ansatz birgt aber auch Gefahren: Eine Investitionszusage in eine
SOA-Initiative ist mit ihm zwar leichter zu erreichen, das bedeutet aber
nicht automatisch einen Durchbruch für eine unternehmensweite SOA.
Denn er erfordert eine sehr gute Vorbereitung und die Gewissheit, dass
der versprochene Nutzen auch nachweisbar erbracht werden kann. Ein
Misslingen oder auch eine signifikante zeitliche Verzögerung des Projek-
tes, die der Serviceorientierung zugeschrieben werden kann, bedeutet in
der Regel die Aufgabe des SOA-Prinzips im laufenden Projekt und auf
lange Zeit hin das Ende jeder weiteren SOA-Initiative. Sowohl bei der
Identifikation und der Auswahl des SOA-affinen Bereichs als auch bei dem
Nutzenversprechen und der geplanten Umsetzung ist größte Sorgfalt
geboten, weil die Initiative und der zu erbringenden Nachweis eines SOA-
basierten Nutzens von allen Seiten neugierig beobachtet wird.
Mit SOA kann man nur mit einer effizienten, Fakten-basierten und an den
Bedürfnissen der Stakeholder orientierten Kommunikation erfolgreich
sein. Diese sollte auf einer transparenten und steuerbaren Architektur
basieren, die gezielte SOA-Eingriffe ermöglicht und den entstandenen
Nutzen quantifizieren lässt. Mithilfe von wohldefinierten, aus den Kerntrei-
bern des Geschäfts abgeleiteten KPIs (Key Performance Indicators) kann
der Erfolgsbeitrag von SOA in dem betrachteten Projekt nachgewiesen
und an den Sponsor kommuniziert werden.
46
SOA-Kommunikation: „Wie überzeug’ ich meinen Chef?“
4.4 Vorteile kommunizieren
In der IT ist meistens ein multivariates Zielsystem zu beachten. Das heißt,
es handelt sich nicht um eine eindimensionale Optimierung, wie z. B. nur
nach Kostenzielen, sondern um eine Mischung diverser, unterschiedlich
gewichteter, teilweise konkurrierender Ziele, die zusammen betrachtet
werden müssen. Außerdem ist nicht nur eine Ist- mit einer Zielsituation zu
vergleichen, sondern auch die Migration dorthin. Denn selbst wenn das
angestrebte Ziel ein Optimum darstellt und die gesetzten Ziele bestens
erfüllt, scheidet die Lösung aus, wenn der Weg dorthin zu viele Risiken
oder Kosten verursacht. Das Aufzeigen des Wertbeitrages führt oft zu
komplexen Argumentationen, die für ein Management nicht über -
zeugend genug sind. Deswegen müssen die wesentlichen Vorteile mit
Bezug zur Strategie möglichst mit einem quantifizierbaren Nutzen für das
Geschäft herausgearbeitet und evtl. mithilfe anschaulicher Metaphern
verdeutlicht werden.
Da der Nutzen von SOA nicht unmittelbar und direkt auf das Geschäft
wirkt, ist es wichtig, ausgehend von strategischen Treibern, die auf ein
Geschäftsfeld wirken, eine Ursache- /Wirkungskette aufzubauen. Hierzu
ist es nützlich, mit strategischen Aussagen realistische begründete
Geschäftsszenarien zu erstellen, die künftig wahrscheinliche Situationen
plakativ beschreiben. Daraus sollten Auswirkungen bzw. resultierende
Anforderungen an die IT abgeleitet werden. Die spannende Frage ist
dann, welche Maßnahmen mit welchem Ressourcen- und Zeitaufwand in
der existierenden und, im Vergleich dazu, in einer imaginären SOA-getrie-
benen IT ergriffen werden könnten. Beim Vergleich der Zeiten- und Res-
sourcenaufwände von beiden IT-Varianten geht es nicht nur um die ent-
standenen Aufwände, sondern auch um den entgangenen Nutzen auf der
Geschäftsseite durch eine zeitlich verzögerte Unterstützung und Realisie-
rung des Geschäftsvorteils. Sowohl der Aufwand als auch der entgangene
Nutzen ist also für beide IT-Varianten abzuschätzen und miteinander zu
vergleichen.
47
www.hessen-it.de
Dieser berechnete Nutzen kann so noch nicht als Business Case für den
SOA-Piloten verwendet werden, weil die Kosten für die Migration der exis-
tierenden IT auf eine serviceorientierte Architektur noch mitberechnet
werden müssen. Zur Berechnung dieser Kosten müssen die bestehenden
Abhängigkeiten, die im betrachteten Kontext bestehen, sowie die daraus
resultierenden Aufwände für eine Transformation ableitbar sein. Diese
setzt eine Transparenz voraus, wie sie nur durch die konsequente Umset-
zung einer Unternehmensarchitektur möglich ist. Denn in der Regel muss
abgegrenzt werden, welche Prozesse und damit verbunden Fähigkeiten
von einem beschriebenen Geschäftsszenario betroffen sind. Ein Bebau-
ungsplan zeigt dann sofort auf, welche Applikationen diese Fähigkeiten
unterstützen. Wenn darüber hinaus die Betriebsmodelle und Server
bekannt sind, auf denen diese Applikationen betrieben werden, können
diese Informationen genutzt werden, um die aktuellen Kosten zu ermit-
teln. Andererseits wird auch deutlich, welche Anwendungen ersetzt wer-
den müssen, um entsprechende Fachservices neu aufzubauen. Daraus
müssen Kosten für die Entwicklung bzw. Beschaffung der benötigten
Fachservices ermittelt und sowohl die Datenmigration wie auch der tem-
poräre Parallelbetrieb während einer Übergangszeit mit kalkuliert werden.
Kosten- und Ertragsentwicklung eines fiktiven SOA-Projektes in T€
CAPEX = Capital expenditure, Investitionen
OPEX = Operational expenditures, Betriebskosten
2010 2011 2012 2013 2014
CAPEX (Ist) 100 50 20 0 0OPEX Maintenance (Ist) 500 500 400 0 0OPEX Operations (Ist) 600 600 500 0 0
CAPEX (SOA) 0 1.500 1.000 80 80OPEX Maintenance (SOA) 0 200 300 300 300OPEX Operations (SOA) 0 150 300 400 400
Gesamtkosten/Jahr 1.200 3.000 2.520 780 780Einsparungen IT Kosten zu Ist 0 –1.800 –1.320 420 420
Umsatzplus 0 0 1.000 1.500 2.000Prozesseffizienz 0 0 500 1.000 1.200
Gesamt 0 –1.800 180 2.920 3.620
48
SOA-Kommunikation: „Wie überzeug’ ich meinen Chef?“
Die Tabelle zeigt ein Beispiel für die mögliche Kostenentwicklung in einer
begrenzten SOA-Initiative. Darin sind die parallel anfallenden Kosten der
laufenden Systeme und der neu zu implementierenden SOA-basierten
Systeme in den Jahren 2011 und 2012 berücksichtigt. Bei den IT-seitig
erzielten Einsparungen werden die im Jahre 2010 berechneten 1,2 Mio
Euro als Ausgangskosten verwendet, die als Vergleich konstant über die
weiteren Jahre extrapoliert werden (siehe „Gesamtkosten /Jahr“). So wer-
den die Einsparungen berechnet, die in den Jahren 2011 und 2012 negativ
sind, da dort Investitionen für die Einführung der SOA vorgenommen wer-
den, die die momentanen Betriebskosten übersteigen (siehe „Einsparun-
gen IT-Kosten zu Ist“). Im Jahre 2013 werden erste Einsparungen erzielt, da
die Betriebskosten im Zielsystem geringer ausfallen. Hierunter fallen auch
Effekte, wie die Verringerung von Projektkosten zur Erweiterung der Ser-
vices oder die geringeren Kosten zur Implementierung von Änderungen.
Darüber hinaus werden die Auswirkungen der SOA auf die Geschäftsseite
kalkuliert. Der Umsatz kann gesteigert werden, da durch kürzere Time-
to-Market-Realisierungen neue Produkte eher an den Markt gebracht
werden können, wodurch Marktvorteile entstehen, die in messbaren
Umsatz- und damit in Gewinnsteigerungen resultieren. Ebenso können
Kosten auf der Fachseite eingespart werden, weil die Prozesse schneller
angepasst und effizienter gestaltet werden können (siehe Abbildung
nächste Seite). Hieraus ergibt sich, dass – ohne eine entsprechende Ver-
zinsung zu berücksich tigen – der Nutzen die Kosten bereits im zweiten
Jahr übersteigt. Eine Amortisierung der Investition ist danach bereits nach
drei Jahren erreicht. Das ist eine Perspektive, die auch von einem Chef
nicht ignoriert werden kann und ihn überzeugen dürfte.
49
www.hessen-it.de
Kumulierte Entwicklung eines fiktiven SOA-Projektes
Amortisierung eines fiktiven SOA-Projektes in reiner IT-Perspektive
Eins
par
ung
en in
€
Zeit
Geschäftsorientierter Nutzen von SOA
–3000
–2000
–1000
0
1000
2000
4000
3000
20112010 2012 2013 2014
ProzesseffizienzUmsatzplusIT-Einsparungen
18000
16000
14000
12000
10000
8000
6000
4000
2000
Zeit
SOA-Amortisierung: IT-Bereich (ohne Geschäftsbereich)
IT SOA kumuliert, verzinstIT Bezugslinie kumuliert,verzinst
Kum
ulie
rte,
ver
zins
te K
ost
en in
€
20102012
20142016
20182020
0
50
SOA-Kommunikation: „Wie überzeug’ ich meinen Chef?“
Betrachtet man die kumulierte Kostenentwicklung eines SOA-Projektes
lediglich in der IT-Perspektive und projiziert man die aktuellen, jährlichen
Kosten konstant in die Zukunft, so erhält man bei einer Verzinsung von
acht Prozent erst eine Amortisation nach ca. zehn Jahren. Diese Perspek-
tive wird keinen Chef zu einer Investition veranlassen.
Eine rein IT-bezogene Betrachtung des SOA-Nutzens ist in vielen
Fällen nicht überzeugend. Der Geschäftsnutzen ist unbedingt mit
zu berücksichtigen.
SOA sollte man deshalb grundsätzlich mit Bezug zum erzeugten
Geschäftsnutzen darstellen und kommunizieren. Dabei ist es hilfreich, die
strategischen Treiber, die auf ein Geschäftsfeld wirken, zu kennen, und
daraus diejenigen zu identifizieren, die durch SOA positiv beeinflusst
werden. Es sollten diejenigen Prozesse herausgesucht werden, die diese
Treiber am stärksten fördern, und damit die Fähigkeiten, die von diesen
benötigt werden. Daraus können die involvierten Applikationen abge -
leitet werden, die in eine serviceorientierte Architektur überführt werden
müssten. So erfolgt eine strategisch determinierte Auswahl eines Berei-
ches, der von einer SOA am meisten profitiert. Diese strategisch getrie-
bene Auswahl und Abgrenzung eines Geschäftsbereiches hilft, den Nut-
zen von SOA geschäftsorientiert darzustellen. Eventuell kann diese mone-
täre Kalkulation durch weitere qualitative Kennzahlen, die an den invol-
vierten strategischen Treibern orientiert sind, ergänzt werden.
Die folgende Abbildung zeigt in diesem Zusammenhang einen Ausschnitt
aus der beschriebenen Ursache- /Wirkungskette – von den bereits aus
strategischen Gesichtspunkten selektierten Prozessen über die sie unter-
stützenden Fähigkeiten zu den Applikationen. Hieraus kann sowohl die
bestehende Situation wie auch die künftig gewünschte, serviceorientierte
Ausrichtung der Anwendungsarchitektur entnommen werden.
51
www.hessen-it.de
Ursache- / Wirkungszusammenhänge zwischen Prozessen (oben)
über Domänen / Fähigkeiten (Mitte) und Applikationen (unten)
Anhand derartiger Darstellungen kann kommuniziert werden, wie die
Komplexität durch SOA reduziert, die Qualität gezielt verbessert und
dadurch die Kosten nachvollziehbar gesenkt werden können. Damit kön-
nen dann Aussagen getroffen werden, die wie in der folgenden Abbil-
dung visualisiert werden können. Diese eher plakativen Darstellungen
sind einprägsam und reduzieren die Botschaft auf wesentliche, geschäfts-
wirksame Aussagen.
Sub-processes
Prozessmodell
Analyse & Design
Fähigkeiten
Domänenmodell
Fähigkeiten
ITP
ITF
ITx
App.2
App.3
App.1 App.4 App.5
App.6
App.7
App.8
App.9
App.10
App.12
App. 11
App.13
App.16
App.15
App.14
App.x
App.17
Bebauungsplan
As-is Applikationen Target architecture (Master plan)
Domäne x Construction
App.16
App.15
App.14 App.7
App.8
App.9
App.10
App. 11
App.2
App.1 App.4
52
SOA-Kommunikation: „Wie überzeug’ ich meinen Chef?“
Kosteneinsparungsnutzen von SOA, beispielhaft illustriert
4.5 Fazit
Bevor SOA der Geschäftsleitung oder den Entscheidungsträgern eines
Unternehmens präsentiert werden kann ist eine gute, gründliche Vorberei-
tung erforderlich. Die Zusammenhänge zwischen den verschiedenen
Geschäftsfeldern müssen erörtert und verstanden werden. Dies ist in der
Regel durch eine gute Architekturarbeit zu erreichen. Es sollte eine Unter-
nehmensarchitektur erarbeitet werden, die für die Identifizierung und
Abgrenzung der für die serviceorientierte Architektur optimalen Ge -
schäfts bereiche von erheblichem Nutzen ist und somit für die benötigte
Transparenz sorgt. Mit ihr kann die Migration zur neuen SOA-Welt exakt
geplant und der durch SOA zu realisierende Nutzen genau abgeschätzt
und quantifiziert werden. Wenn im ausgewählten Bereich die Transforma-
tion in eine serviceorientierte Architektur ohne Risiko und im geplanten
Zeit- und Kostenrahmen bewerkstelligt werden kann, sollte das SOA-Vor-
haben in einer Art und Weise präsentiert werden, die den Chef mit seiner
Sprache abholt und ihm anschaulich und plakativ die wesentlichen Bot-
schaften vermittelt. Nach erfolgtem Entscheid für das SOA-Projekt kann
dann die SOA-Implementierung begonnen werden, um den versproche-
nen Nutzen wie geplant reibungslos und nachweisbar zu realisieren.
KostensenkungVerringerung der Variantenvielfalt
IstSoll
IstSoll
280
100
10
2
Ist Soll
Ist Soll
–68%
–83%
–25%
–15%# Applikationen
# BetriebsmodelleLa
yer
Laye
rLa
yer
Core
Sub-processes
Prozessmodell
Analyse & Design
Fähigkeiten
Domänenmodell
Fähigkeiten
ITP
ITF
ITx
App.2
App.3
App.1 App.4 App.5
App.6
App.7
App.8
App.9
App.10
App.12
App. 11
App.13
App.16
App.15
App.14
App.x
App.17
Bebauungsplan
As-is Applikationen Target architecture (Master plan)
Domäne x Construction
App.16
App.15
App.14 App.7
App.8
App.9
App.10
App. 11
App.2
App.1 App.4
Thin Client
Thin Client
Rumba
ServerORACLE
WIN 2003x86
ServerORACLE
WIN 2003x86
RUV Permanent Proc.RUV Task
Shared DB2z/OS parallel Sys plex
IBM zSeries
Front-End-
Server
Back-End-
Server
Host
Clearing-DTA, etc.
FTP
FTP/DTA
HTTPS, etc.Encaps. 3270/DTA
Zentraler Mainframe mit Windows Front-/Back-Ends
53
www.hessen-it.de
SOA-Governance: Warum Investitionen in Menschen wichtigersind als in Monitoring-Tools
Thomas Mironiuk, Intersystems GmbH
Zu Recht wird serviceorientierte Architektur (SOA) heute in einem Atem-
zug mit Business Prozess Management (BPM) genannt, war sie doch von
Anfang an als Methode zur Prozessoptimierung gedacht. Wie so viele
sinnvolle Ansätze aus der IT leidet sie allerdings, seit der Begriff von Gart-
ner kreiert wurde, an akuten Kommunikationsproblemen. Geradezu sträf-
lich wurde versäumt, den an den zu optimierenden Prozessen beteiligten
oder von ihnen betroffenen Menschen eine verbindliche und allgemein-
verständliche Definition von SOA an die Hand zu geben. Bis heute können
sich Industrie und Wissenschaft nicht einmal auf eine gemeinsame Defini-
tion von SOA für die IT einigen. „SOA ist ein Paradigma für die Strukturie-
rung und Nutzung verteilter Funktionalität, die von unterschiedlichen
Besitzern verantwortet wird.“, lautet die Definition der Organization for the
Advancement of Structured Information Standards (OASIS). Sicherlich
richtig, aber lebensfern. Jenseits der Kreise, die sich mit IT-Infrastrukturen
im Unternehmen beschäftigen, dürfte man viel eher den Satz zu hören
bekommen: „Gestern wurden Mitarbeiter wegrationalisiert, heute machen
wir SOA.“
5
54
SOA-Governance: Warum Investitionen in Menschen wichtiger sind als in Monitoring-Tools
© p
ress
mas
ter
- Fo
tolia
.co
m
5.1 Definition „SOA-Governance”
Die Herausforderung, diesen Missstand auf Unternehmenseben zu behe-
ben, fällt in den Aufgabenbereich der SOA-Governance, der Kontrolle
und Steuerung von serviceorientierten Prozessen. Das Problem hierbei ist
nur, dass die Vorstellung aller Beteiligten, was genau SOA-Governance
sein soll, noch unpräziser ausfällt als bei SOA selbst. 2008 definierte der
Branchenverband BITKOM in einem SOA-Leitfaden den Begriff der SOA-
Governance als: „Definition, Durchsetzung und Steuerung von organisa-
torischen Regeln, Richtlinien und Standards zur konsequenten Ausrich-
tung der Services und Geschäftsprozesse an der Unternehmensstrategie
durch geeignete Steuerungs- und Kontrollmaßnahmen. IT-Governance im
konventionellen Sinne befasst sich hingegen mit der Organisation, Steue-
rung und Kontrolle der IT und der IT-Prozesse. Diese Aufgabe wird jedoch
immer noch zu technisch gesehen. Durch die Einführung einer SOA rückt
der Fokus auf Services und Geschäftsprozesse auch in den Mittelpunkt
der IT-Governance“.
Mittlerweile wird der Begriff „Governance“ ähnlich inflationär gebraucht
wie der Begriff Management, weil sich damit herrlich verschleiern lässt,
dass derjenige, der ihn nutzt, nur eine verschwommene Vorstellung von
dem hat, was zu tun ist. Und wie bei des Kaisers neuen Kleidern traut man
sich nicht nachzufragen – zu groß die Angst, Unkenntnis einzugestehen.
Neusprachlich leitet sich der Begriff vom französischen Wort „gouverner“
ab, was so viel wie verwalten, leiten oder erziehen heißt. Sicherlich alles
Tätigkeiten, die im Rahmen von Governance anfallen. Folgt man dem
Wort aber zu seinen historischen Wurzeln, findet man das griechische
„kybernan“, was bedeutet, das Steuerruder zu führen. Alle, die an der
SOA-Governance beteiligt sind, sollten sich diesem Ursprung verpflichtet
fühlen, denn die Aufgabe, die ihnen bevorsteht, besteht darin, die Anwei-
sungen des Kapitäns bzw. CEOs in einen schnellen, aber sicheren Kurs für
Schiff und Mannschaft umzusetzen. Dabei geht es dann eben nicht darum
zu verwalten, sondern zu führen.
55
www.hessen-it.de
Zu einer der ersten Aufgaben der SOA-Governance gehört daher die
Entwicklung eines Governance-Plans, einer Seekarte durch die SOA-
Untiefen. Dies bedarf natürlich einiger Vorbereitungen. Da ist zunächst
das Bekenntnis von Geschäfts- und IT-Leitung einzuholen, SOA zu einem
langfristigen integralen Bestandteil der IT-Strategie des Unternehmens zu
machen. Trotzdem sollten die ersten Projekte so angelegt sein, dass sich
kurzfristig sichtbare Vorteile ergeben, um die generelle Akzeptanz von
SOA für die Zukunft zu fördern. Das wahre Potenzial spielt eine solche
Architektur aber erst dann aus, wenn der Pool an verfügbaren Services
echte Mehrwertanwendungen erlaubt und Prozesse problemlos neu
angelegt oder verändert werden können. SOA ist kein Sprint, sondern ein
Weg, und der, so Kafka, entsteht dadurch, dass man ihn geht.
Desweiteren sollten die an der SOA-Governance Beteiligten eine ehrliche
Bestandsaufnahme der Ressourcen und Fähigkeiten durchführen und
dann festlegen, welche Ziele SOA für das Unternehmen erreichen soll.
Der „Alles-Ansatz“, Kosten senken, Flexibilität erhöhen und Mehrwerte
schaffen, eignet sich zwar hervorragend, um Erfolge zu vermelden, wo
positive Ergebnisse trotz vollständigen Scheiterns der ursprünglichen
Mission zu Buche schlagen wie bei Christoph Kolumbus, nicht aber für ein
qualifiziertes Measuring und Controlling. Unbedingt muss die SOA-
Governance auch in Einklang mit den anderen Steuerungsmodulen im
Unternehmen gebracht werden, von Corporate-Governance über BPM-
Governance bis zur Data-Governance. Hier sind gegebenenfalls erste
Anpassungen im Nicht-IT-Umfeld notwendig, sollten sich Teile der Rege-
lungen als untauglich oder hinderlich für die erfolgreiche Implemen -
tierung einer SOA im Unternehmen erweisen.
Ist er erst einmal erstellt, enthält der SOA-Governance-Plan dann alle
Informationen, um neue Mitglieder im Governance-Team umfänglich über
Ziel, Ressourcen, Hierarchien, Policies und Kommunikationsmaßnahmen
zu informieren. Zudem gibt er formale Strukturen, zum Beispiel in Form
von Abzeichnungsbögen vor, um die Integrität der Dokumentation zu
sichern.
56
SOA-Governance: Warum Investitionen in Menschen wichtiger sind als in Monitoring-Tools
5.2 Soziale Auswirkungen
Die im Pan verzeichneten Ressourcen umfassen nicht nur Gebäude und
die IT-Infrastruktur, sondern vor allem Mitarbeiter. Team-Rollen und Ver-
antwortlichkeiten sowie die damit einhergehenden individuellen Rollen
und Pflichten sind essenzieller Bestandteil eines jeden Governance-Plans.
Dabei darf getrost davon ausgegangen werden, dass die neuen Teams
wenig mit den alten Abteilungsstrukturen zu tun haben. Noch bevor SOA
mit neuen oder veränderten Prozessen im Makrokosmos Unternehmen für
Unruhe sorgt, wirbelt sie den Mikrokosmos der IT-Abteilung durchein -
ander. Holt man neue Leute für das SOA-Projekt, geht auf Leitungsebene
der Machtkampf um Personalstellen los, während gestandene Mitarbeiter
sich in ihrer Wertschätzung zurückgesetzt fühlen. Hat man alle benötigten
Qualifikationen schon im Unternehmen, kommt es unweigerlich zu Ver-
schiebungen innerhalb der Leitungshierarchie, während sich gleichzeitig
Karriereziele und Aufstiegspfade verändern oder gar verschwinden.
Wer glaubt, ohne entsprechende Optionen und Angebote für die betrof-
fenen Mitarbeiter eine Politik allein „zum Wohle des Unternehmens“
durchsetzen zu können, stößt daher schnell an seine Grenzen. Schlep-
pende Umsetzung und innere Kündigung sind noch die harmlosesten
Folgen. Wenn erhoffte Beförderungen nicht mehr möglich sind oder
Arbeitszeit und Arbeitsort zu privaten Problemen führen, verliert das
Unternehmen unter Umständen für den Erfolg der SOA-Strategie wesent-
liche Mitarbeiter. Erfahrung mit der Unternehmensstruktur und -kultur
kann nicht einfach durch fachliche Kompetenz eines neuen Mitarbeiters
ersetzt werden, von der Projektverzögerung ganz zu schweigen.
57
www.hessen-it.de
Kommunikation und Vermittlung des Governance-Plans sollten sich daher
nicht auf die rein fachlichen Informationen und Maßnahmen für die IT-Mit-
arbeiter respektive die Prozessinhaber der Fachabteilungen beschränken.
Zugleich sind ein der Kultur des Unternehmens entsprechendes Anreiz-
oder Belohnungssystem zu schaffen und Karrierealternativen aufzuzeigen.
Bei der Formulierung dieses Angebots für die Beschäftigten handelt es sich
zugleich um die Generalprobe für das Gesamtunternehmen. SOA-unter-
stütztes BPM wird immer wieder nicht nur Abläufe, sondern auch struktu-
relle Zuständigkeiten verändern. Eine Belegschaft, die darauf vertrauen
kann, dass ihre Interessen bei solchen Planungen berücksichtigt werden,
steht zukünftigen Änderungen deutlich aufgeschlossener gegenüber.
58
SOA-Governance: Warum Investitionen in Menschen wichtiger sind als in Monitoring-Tools
© A
ndre
s R
od
rig
uez
- Fo
tolia
.co
m
5.3 Governance realisieren
Steht der Plan, gilt es ihn in die Tat umzusetzen. Dabei zeigt sich sehr
schnell, dass SOA-Governance ein fließender Prozess ist. Das SOA Center
of Excellence (COE) wird im Laufe der Zeit neue Mitglieder bekommen,
Hard- und Software werden sich auf neue Technologien und Produkte ein-
stellen, Prozesse anhand von Erfahrungen optimiert oder zu Best-Practices
erklärt werden. Insbesondere Fragen der Wiederverwendung von Ser-
vices (service reuse), der Kostenverteilung und eines Anreizsystems für
den Reuse sowie der Art und Vergütung von Service-Level-Agreements
(SLA) sind nicht immer schon im Vorfeld eindeutig festzulegen. Nach den
ersten SOA-Teilprojekten können dann sukzessive Maßnahmen in die
Wege geleitet werden, die gezielt nach Aktivposten suchen und solche
verwalten, Monitoring-Tools implementieren und Mitarbeiter auf allen
Ebenen über neue Prozesse und erwartetes Verhalten schulen und infor-
mieren.
Umfragen zeigen, dass diejenigen Unternehmen erfolgreicher abschnei-
den, die ihre für SOA benötigte Software gezielt nach deren Fähigkeiten
auswählen, als solche, die sich blind auf eine Suite verlassen. Trotzdem
sind Fragen der richtigen Infrastruktur oder Entwicklungsumgebung, nach
Herstellerunabhängigkeit und Standards leichter zu lösen als solche, die
Jobprofile und Personalüberlegungen beinhalten. Zu den grundlegen-
den Aufgaben der SOA-Governance gehört, sich Gedanken zu Lebens -
zyklen von Services zu machen, Composite Applications zu schaffen oder
Regeln und Strukturen für den Umgang mit von außen eingekauften Ser-
vices zu definieren und für deren Einhaltung zu sorgen. Die hierzu benö-
tigten Mittel wie Excellence-Center oder Service-Level-Agreements sind
bewährte Elemente innerhalb der IT. Dies ist Segen und Fluch zugleich.
59
www.hessen-it.de
5.4 Governance kommunizieren
Da SOA-Governance bewusst die Fachabteilungen in die Prozesse mit
einbezieht, ist die IT gezwungen, mit Nichtfachleuten über Fachbegriffe zu
reden. Plötzlich muss die Kommunikation ohne Meta-Wissen auskommen,
es verlieren die stillschweigenden Voraussetzungen und Übereinkünfte
ihre Wirkung, die immer dann in Kraft sind, wenn Fachleute eines Berufs-
standes unter sich sind. Im Idealfall reden IT-Spezialisten mit ihren Kolle-
gen aus den Fachabteilungen so, wie es Verbraucherschützer inzwischen
von Kundenberatern in Banken fordern: „Setzen Sie nichts voraus.“ Um
verständlich zu werden, müssen vor allem Zahlen in einen Kontext
gebracht werden, den die Fachabteilungen verstehen. Was bedeutet ein
vereinbarter Service-Level? Warum machen Millisekunden bei Response-
Zeiten einen Unterschied? Was verbirgt sich hinter Service-Versionen?
Wem das zu banal klingt, der stelle sich einfach nur vor, er wäre von jetzt
auf gleich auf das Handelsparkett der Deutschen Börse in Frankfurt
gestellt. Die Sprache in der IT entwickelt sich mindestens so rasch weiter
wie die Technologie selbst und erinnert manchen branchenfremden Men-
schen an die Geheimsprache der mittelalterlichen Handwerksbünde.
Holen Sie sich soziale Kompetenz ins SOA-Team und betreiben Sie
intern SOA-PR und -Marketing!
60
SOA-Governance: Warum Investitionen in Menschen wichtiger sind als in Monitoring-Tools
Wenn man also verhindern will, dass SOA scheitert, obwohl man tech-
nisch alles richtig macht, gilt es zwei Dinge zu beherzigen: Zum einen ist
rechtzeitig soziale Kompetenz ins SOA-Governance-Team zu holen, um
die Auswirkungen von Prozessänderungen auf die Mitarbeiter zu bewer-
ten und gegebenenfalls abfangen zu können. Zum anderen darf man sich
nicht zu schade für interne PR und internes Marketing sein. Keine gute
Idee verkauft sich von alleine und eine SOA schon gar nicht. Während es
außerhalb der IT-Abteilung Verlustängste und Widerstände zu über -
winden gilt, muss innerhalb womöglich gegen den „Alles schon mal
dagewesen“-Faktor angekämpft werden. SOA ist zugegebenermaßen
lediglich der aktuellste einer ganzen Reihe von Ansätzen, IT-Abläufe und
Unternehmensprozesse zu harmonisieren. DCOM (Distributed Com -
ponent Object Model), DCE (Distributed Computing Environment) und
CORBA (Common Object Request Broker Architecture) kamen alle mit
ähnlich vollmundigen Versprechungen daher, um dann wieder in der
Versenkung zu verschwinden.
5.5 Fazit
Um SOA-Governance erfolgreich umzusetzen, reichen fachliche Qualifi -
kationen allein nicht aus. Investitionen in die Softskills des Governance-
Teams sind für den Erfolg der SOA im Unternehmen entschieden wich -
tiger als die Anschaffung etwa eines Monitoring-Tools. Ohne solche
Software lässt sich eine SOA zur Not realisieren, aber ohne die Fähigkeit,
die Belegschaft für SOA zu begeistern, ist das Scheitern von Anfang an
vorprogrammiert.
61
www.hessen-it.de
SOA-Security: Webservices erfordern zusätzlicheSicherheitsmaßnahmen
Dr. Bruno Quint, Corisecio GmbH
6.1 Grundlagen
Serviceorientierte Architekturen (SOA) entwickeln sich von einem Hype-
Thema zu realen Projekten. Die Idee, Funktionalitäten und Aufgaben als
lose gekoppelte, unabhängige, austauschbare Dienste über standardi-
sierte Schnittstellen anzubieten, ermöglicht Unternehmen flexibler auf
sich ändernde Geschäftsprozesse zu reagieren. Um den Vorteil der Flexi-
bilität und die damit verbundene Kostenersparnis zu erreichen, müssen
einzelne Services bestimmten Anforderungen genügen. In der Literatur
existiert eine Vielzahl von Kriterien an Services – die verbreiteten sind:
a Standardisierte Service-Schnittstellen
– um die Interoperabilität sicherzustellen
a Lose Kopplung
– ein Minimum an Abhängigkeiten muss die Modellierbarkeit
verschiedener Services zu einem Geschäftsprozess erlauben
a Funktionsabstraktion
– fordert eine Kapselung von Funktionen
a Wiederverwendbarkeit
– ist eine Grundanforderung zur Erreichung von Kostenersparnissen
a Service-Autonomie
– ermöglicht das (weitgehend) autarke Agieren von Services
a Vorratsdatenfreiheit des Services (Statelessness)
– persistente Daten werden nur gespeichert,
wenn sie explizit Dienstleistungsbestandteil des Service sind
a Auffindbarkeit des Services
– über definierte Repositories
a Orchestrierbarkeit der Services
– um einzelne Services zu einem Gesamtprozess zu verbinden
6
62
SOA-Security: Webservices erfordern zusätzliche Sicherheitsmaßnahmen
Grundsätzlich ist SOA ein Managementkonzept. Es schreibt keine kon-
krete technische Realisierung oder bestimmte Methoden vor. Allerdings
haben sich Web Services (basierend auf SOAP/XML) zur Realisierung
durchgesetzt. Ein Web Service ist eine auf XML (eXtensible Markup
Language) und SOAP (Simple Object Access Protocol) basierende
Anwendung, die definierte Methoden über eine standardisierte Schnitt-
stelle anbietet und über eine URI (Uniform Resource Identifier) eindeutig
identifizierbar macht. Als Kommunikationsprotokoll dient SOAP (W3C),
mit dem Daten zwischen Systemen ausgetauscht werden können. SOAP
verwendet XML zur Datenrepräsentation sowie (in den meisten Fällen)
TCP/IP für den Transport.
Zu einer SOA-Infrastruktur gehört weiterhin ein Service Repository, wel-
ches meist über UDDI (Universal Description, Discovery and Integration)
und WSDL (Web Services Description Language) realisiert wird.
6.2 Sicherheitsanforderungen
Im Grunde gelten für SOA die gleichen Sicherheitsanforderungen wie für
herkömmliche monolithische Systeme. Zusätzlich existieren durch die Ver-
teilung von Systemen und Prozessen aber SOA-spezifische Sicherheits -
risiken, die entsprechend zu berücksichtigen sind.
Wie in monolithischen Systemen müssen auch in SOA-Infrastrukturen
Identitäten und Berechtigungen verwaltet, Benutzer authentisiert, Zugriffs-
berechtigungen überprüft, Zugriffe und Zugriffsversuche aufgezeichnet
und Daten mittels kryptografischer Methoden signiert (Integrität) oder
verschlüsselt (Vertraulichkeit) werden. Gerade in verteilten Umgebungen
werden zudem systemweite Sicherheitsrichtlinien (Policies) benötigt,
deren Einhaltung (Compliance) es permanent zu überwachen gilt.
Die Bedrohungspotentiale lassen sich grob in zwei Kategorien einteilen.
Zum einen wird eine SOA-Infrastruktur basierend auf einem Netzwerk /
IT-System allgemeinen Gefahren wie Malware, Buffer Overflows, Back-
doors, Netzangriffen (Scanning, Spoofing, etc.) sowie Denial of Service
(DoS) und vielen mehr ausgesetzt.
63
www.hessen-it.de
Der Grundgedanke von SOA wirft zum anderen weitere Anforderungen
und Bedrohungspotentiale auf, die durch die Integration verteilter und
teilweise heterogener Systeme insbesondere zu beachten sind. So
müssen Replay-Attacks, Service-Kompromittierung sowie unberechtigte
Service-Nutzung durch adäquate Mechanismen verhindert werden.
In herkömmlichen IT-Infrastrukturen wird die Anmeldung des
Benutzers zu Beginn einmal durchgeführt und dann läuft der Geschäftsprozess
in diesem Kontext sicher in der Applikation ab (siehe oben).
In verteilten Service-Infrastrukturen werden Nachrichten (Web Services) zwischen
benötigten Service Applikationen versendet. Der Sicherheitskontext zwischen dem
anfragenden und dem liefernden Service muss über zusätzliche Mechanismen
bereitgestellt werden (siehe unten).
UserID /
Password
Service
Service
Application
Service
Service
64
SOA-Security: Webservices erfordern zusätzliche Sicherheitsmaßnahmen
Die Realisierung eines Geschäftsprozesses über eine Vielzahl lose ge -
koppelter Services erfordert zudem mehr Authentisierungs- und Autori-
sierungsvorgänge, eine jederzeit gewährleistete Vertraulichkeit sowie
eine höhere Integrität als in einem monolithischen System. Ein Prozess -
design über Unternehmensgrenzen hinweg und zwischen unternehmens-
fremden Teilnehmern verstärkt diese Sicherheitsanforderungen an Servi -
ces und Lösungen und setzt so genannte Federation-Konzepte voraus.
Technisch gesehen muss dabei die Interoperabilität sichergestellt wer-
den. Zu nennen sind an dieser Stelle bspw. die Umwandlung von Identi -
täten und deren Formate, der Einsatz von Industriestandards und die
Gewährleistung der Wiederverwendbarkeit von Security-Diensten.
Die herkömmlichen Sicherheitsanforderungen müssen
um diverse SOA-spezifische Ausprägungen erweitert werden.
Im folgenden Abschnitt sollen die Sicherheitsmechanismen und Security-
Standards kurz dargestellt werden. Eine einleitende Diskussion über den
Einsatz herkömmlicher Methoden im SOA-Umfeld zeigt die Notwendig-
keit neuer Sicherheitslösungen auf.
65
www.hessen-it.de
6.3 Sicherheitsmechanismen
Schwächen herkömmlicher Ansätze
Wie zuvor aufgezeigt, stellt eine serviceorientierte Architektur zusätzliche,
neue Anforderungen an die Informationssicherheit in den Unternehmen.
Herkömmliche Schutzmaßnahmen auf Transport- und Applikationsebene
stoßen beim Einsatz in SOA an ihre Grenzen und bieten keinen aus -
reichenden Schutz. So ist die Absicherung von Web Services mittels TLS
(Transport Layer Security) oder SSL (Secure Sockets Layer) unzureichend.
Schließlich bietet TLS/SSL lediglich eine Sicherheit auf Transport-Ebene
für eine definierte Punkt-zu-Punkt-Verbindung. Die Sicherheit kann nach
dem Eingang im Zielsystem nicht mehr gewährleistet werden und der
Sicherheitskontext geht verloren. In einem nachrichtenbasierten Workflow
über mehrere Knoten und Teilnehmer bedeutet dies, dass beispielsweise
nicht mehr sicher nachvollzogen werden kann, wer eine Bestellung auf -
gegeben hat oder wer von welcher Stelle als vertrauenswürdig bestätigt
wurde. Zudem sind geforderte Security-Operationen auf Elementebene
(bspw. für Signatur und Verschlüsselung der Kreditkarteninformationen)
mit TLS nicht zu realisieren, da lediglich der Transport der gesamten Nach-
richt gesichert wird.
Herkömmliche Firewall-Technologie (Transport Layer Firewalls) kann
lediglich eine Netzwerksicherheit gewährleisten und ist somit zwar not-
wendig, aber keineswegs ausreichend. Eine Inspektion der Nachrichten
auf Schadsoftware ist ebenso wenig möglich wie die Überprüfung der
Gültigkeit von Inhalt oder Absender. Die Weiterentwicklung von her-
kömmlichen Firewalls zu XML-Firewalls erlaubt zwar ein Durchsuchen
(Parsen) der Nachrichten und rudimentäre Content-Inspection, diese sind
aber für einen Einsatz zur Durchsetzung einer Security Policy nicht aus -
reichend. Neben der Administrations- und Kostenproblematik, vor jeden
Service eine XML-Firewall zu platzieren, stoßen diese Technologien
spätestens bei transformierten Nachrichten (durch Verschlüsselung,
Signatur oder Security Token) an ihre Grenzen.
66
SOA-Security: Webservices erfordern zusätzliche Sicherheitsmaßnahmen
Traditionellerweise wird ein Teil der Sicherheit (wie Authentisierung und
Autorisierung) innerhalb der Applikation umgesetzt. Dies ist aber in einer
SOA-Umgebung bereits aufgrund der Inflexibilität problematisch. Bei
neuen Security-Anforderungen müsste jede betroffene Applikation ge -
ändert werden. Eine zentrale Administration fehlt. Notwendig wäre weiter-
hin die Implementierung der Security-Funktionalität in jeder Applikation
und jedem Service. Das Grundprinzip der losen Kopplung und die damit
verbundene Flexibilität würde durch eine starre Security-Implementie-
rung verloren gehen. Der Anpassungsaufwand für die Security-Lösung
würde ein flexibles Design von Geschäftsprozessen stark einschränken.
Eine mögliche Alternative bietet ein streng zentraler Architekturansatz.
Dabei wird die Security-Logik aus der Applikation herausgenommen und
in einem zentralen Server vorgehalten. Simple Agenten außerhalb der
Applikation fragen den zentralen Server zur Umsetzung der Policy bei
jedem Aufruf an. Ein solcher Ansatz ist nur bedingt geeignet. Zwar ist die
Beherrschbarkeit und Administration gewährleistet. Jedoch wirkt sich
diese Struktur nachteilig auf Aspekte wie Ausfallsicherheit, Netzwerk -
traffic, Lastverteilung und Skalierung aus. Security-Lösungen für SOA-
Infrastrukturen erfordern flexible Architekturansätze, die die beschrie -
benen Aspekte abdecken.
67
www.hessen-it.de
Sicherheitsstandards
Um die Schwächen herkömmlicher Sicherheitsmechanismen zu beheben
und SOA-spezifische Anforderungen zu erfüllen, existieren zahlreiche
Techniken und Methoden, die speziell für den Einsatz in nachrichten- und
dienstorientierten Infrastrukturen entwickelt wurden. Insbesondere die
von den Standardisierungsgremien (W3C und OASIS) verabschiedeten
Standards bieten Basistechnologien, die neben der Sicherheit auch die
Interoperabilität gewährleisten. Allen gemein ist dabei, dass die Sicher-
heit und Sicherheitsinformationen auf Nachrichtenebene implementiert
werden und somit die Schwächen von Sicherheitsmechanismen auf Trans-
portebene, wie z. B. SSL/TLS überwunden werden.
Aufgrund der Vielzahl von Sicherheitsstandards und -methoden
werden an dieser Stelle nur die wichtigsten kurz vorgestellt:
a XML-Encryption
Diese Spezifikation legt fest, wie und in welcher Form XML-
Dokumente innerhalb der XML-Syntax verschlüsselt werden.
a XML-Signature
Die XML-Digital-Signature-Specification legt die Regeln und die
Syntax fest, mit denen digitale Unterschriften für XML-Elemente
erzeugt werden.
a Web Service (WS)-Security
Grundidee des von Microsoft, IBM und Verisign entwickelten
Standards war es, eine Spezifikation zu erstellen, die zeigt, wie
die vorhandenen Basistechnologien XML-Encryption, XML-
Signa ture und XML-Key Management in SOAP integriert werden
können. Dieser Standard bildet somit die Schnittstelle zwischen
vorhandenen Security-Technologien und dem Web Service-
Standardformat SOAP.
68
SOA-Security: Webservices erfordern zusätzliche Sicherheitsmaßnahmen
a SAML (Security Assertion Markup Language)
SAML ist ein Standard zum Transport von Authentisierungs-
und Autorisierungsinformationen innerhalb von Web Services.
Er ermöglicht die Einbringung erweiterter Sicherheitsinforma -
tionen in SOAP-Dokumente als auch die Realisierung von
Single Sign On (SSO)-Szenarien.
a XKMS – XML Key Management Specification
Die XKMS-Spezifikation beschreibt Möglichkeiten für den Aus-
tausch und die Überprüfung von Zertifikaten innerhalb einer PKI.
Durch die Standardisierung wird zudem die Kompatibilität
verschiedener PKI sichergestellt.
Des Weiteren sei an dieser Stelle auf die Spezifikationen von
WS-Trust, WS-Policy sowie WS-Federation verwiesen.
Nicht-standardisierte Sicherheitsmechanismen
Neben standardisierten Sicherheitsmechanismen müssen auch in SOA-
Umgebungen herkömmliche Bedrohungen wie Netzattacken abgewehrt
werden. Wie im Abschnitt 6.2 dargelegt, sind an die Umsetzung und
Implementierung von SOA-Lösungen besondere Anforderungen gestellt,
die die traditionellen Umsetzungen nicht erfüllen. Diese müssen sozu -
sagen „SOA-enabled“ werden.
69
www.hessen-it.de
Single Sign On (SSO)
Richtig eingesetzt ermöglichen SSO-Methoden gleichsam erhöhte Sicher-
heit, niedrigere Verwaltungskosten sowie verbesserte Benutzbarkeit. In
SOA-Szenarien mit einer Vielzahl integrierter Systeme und Services mit
dementsprechend vielen Policy Enforcement Points kann ein SSO-System
diese Vorteile voll und ganz ausspielen. Voraussetzung ist aber ein SOA-
fähiges SSO-Konzept. In realen SOA-Szenarien authentifiziert sich ein
Nutzer nicht direkt an den jeweiligen Backendsystemen, sondern an
zentraler Stelle, meistens an einer Portalanwendung. Alle weiteren An -
meldungen erfolgen über technische User-Konzepte.
SSO nutzt daher ein Benutzer- und Credentialmapping, um Anwendun-
gen mit unterschiedlichen Authentisierungsinformationen zu bedienen.
Zudem besteht die Möglichkeit zur Schaffung einer zentralen Entität.
Dafür müssen Entitäten aus verschiedenen Quellen (Meta Directories,
Datenbanken, etc.) angebunden, ausgelesen, importiert und synchroni-
siert werden. Werkzeuge, die manuell oder über automatisierte Läufe ein
Mapping (Beziehung schaffen) zwischen gleichen Entitäten erlauben,
helfen bei der Umsetzung und Pflege. Die Authentisierungsdaten können
dann über verschiedene Mechanismen (z. B. Agentensysteme) an die
angebundenen Systeme geliefert werden. Gerade bei der Anbindung
von Legacy-Systemen ist es vielfach erforderlich, die Anmeldeinformatio-
nen zusätzlich in ein anderes Format zu transformieren. Dabei kann eine
Anmeldung auf Nachrichtenebene (im Gegensatz zu sitzungsbasierten
Systemen) von Agenten ausgeführt werden und eine Anmeldung in
Formaten der Legacy-Anwendungen ist möglich.
70
SOA-Security: Webservices erfordern zusätzliche Sicherheitsmaßnahmen
Web Application Firewall (WAF)
Eine WAF-Technologie ist notwendig, aber nicht hinreichend, um Services
sowie den Nachrichtenaustausch umfassend abzusichern. So ist der Schutz
vor SQL-Injections, Brute Force, Denial of Service-Attacken durch eine
WAF zu gewährleisten. Dennoch stoßen herkömmliche Web Application
Firewalls bei der Behandlung von Web Services schnell an ihre Grenzen.
Gerade bei verschlüsselten SOAP-Nachrichten sind diese Lösungen nicht
in der Lage, Angriffe zu identifizieren bzw. abzuwehren. Durch Nachrich-
tentransformation und das Hinzufügen weiterer Sicherheitsmerkmale auf
Nachrichtenebene gestaltet sich auch die Schema-Validierung schwierig.
Ausschließlich die Datentypen/Requests, die von einer WAF überprüft wer-
den können, dürfen an diese übergeben werden. Andere Aufgaben, wie
beispielsweise Content Inspection von verschlüsselten Nachrichten und die
Überprüfung der Signatur müssen von der Lösung selbst durchgeführt bzw.
an andere Lösungen zur Prüfung weitergeleitet werden. Die Übergabe von
mutmaßlich ungültigen Daten (bspw. verschlüsselte SOAP-Nachrichten)
würde zu einem Fehler führen und das Ergebnis wäre nicht verlässlich.
Zudem besteht eine Kosten- und Administrationsproblematik beim her-
kömmlichen Einsatz von WAF. Durch die verteilte Systemstruktur in SOA-
Umgebungen würde es bedeuten, dass jeder Service durch eine WAF gesi-
chert werden müsste. Dies ist bei einer Vielzahl verteilter Services nicht
kosteneffizient, da für jeden Service-Provider eine dedizierte WAF bereit -
gestellt werden müsste. SOA-Lösungen müssen einen Service bereitstellen,
der eine WAF für mehrere Services (in einer Domäne etc.) nutzbar macht.
Anti Virus (AV)
Viren und Malware müssen selbstverständlich auch in einer SOA Berück-
sichtigung finden. SOA-spezifische Anforderungen an die AV-Lösung sind
bspw. die Überprüfung von SOAP-Attachments. Des Weiteren gelten für
Anti Virus-Lösungen ähnliche Rahmenbedingungen wie im Abschnitt Web
Application Firewall beschrieben. Insbesondere Lizenz- und Betriebskosten
lassen sich durch zentrale Anti Virus-Services deutlich senken. Beim Einsatz
von Agenten ergeben sich Vorteile durch die Möglichkeit der Modellierung
von Virus-Prüfungen innerhalb einer gesamten Security-Logik.
71
www.hessen-it.de
6.4 Methoden zur Umsetzung
Unternehmen können viele der bisher beschriebenen Ansätze und ins -
besondere offene Sicherheitsstandards manuell implementieren und
umsetzen. Die WS-Security-Spezifikationen der Standards sind öffentlich
zugänglich, und Entwickler können sie in die Applikationen integrieren.
Problematisch wird ein solcher Ansatz allerdings bei einer Vielzahl von
Services und eingebundenen Applikationen. Der Programmieraufwand
bei technischen oder organisatorischen Prozessänderungen ist dann nicht
mehr wirtschaftlich – schließlich muss der Sicherheitsteil jeder Applikation
neu angepasst und getestet werden. Ein solches Vorgehen steht im
Gegensatz zu den ursprünglichen SOA-Prinzipien und würde die Vorteile
einer flexiblen Infrastruktur zunichte machen. Ein weiterer Nachteil einer
manuellen Umsetzung ist sicherlich die fehlende Beherrschbarkeit des
Gesamtsystems, weil keine zentrale Administration und auch nur
schlechte Möglichkeiten des Reportings und Audits vorhanden sind.
Das bedeutet, Anwender müssen in der Lage sein, Sicherheitsmechanis-
men ebenso flexibel zu modellieren, zu managen und auszurollen wie die
serviceorientierte Infrastruktur selbst. Zur Umsetzung solcher und weiterer
Anforderungen bietet sich ein Framework-Ansatz an, der das Security-
Design, die Einführung sowie die Verteilung und den Betrieb von Secu-
rity-Mechanismen unterstützt. Ein auf offenen Standards basierendes
Framework in Verbindung beispielsweise mit einem Plugin-Adapter-Kon-
zept ist in der Lage, die benötigte Flexibilität der Sicherheitsmechanismen
umzusetzen. Security-Funktionalität, Standards und Erweiterungen (wie
Integrationsfunktionen) werden über Plug In-Adapter geladen und stehen
systemweit zur Verfügung.
72
SOA-Security: Webservices erfordern zusätzliche Sicherheitsmaßnahmen
Security als Service
Zudem bietet es sich an, Sicherheitsfunktionalität selbst als Service anzu-
bieten. Dabei wird die Funktionalität SOA-konform in Services gekapselt
und zur Verfügung gestellt. Dies kann zentrale Administrationsdienste
umfassen, beispielsweise Identity-Management oder -Modellierung,
ebenso wie die Umsetzung am Policy Enforcement Point (zum Beispiel
Verschlüsselungen, Authentifizierung).
Als Service können auch Dienste für die Nutzung von herkömmlichen
Security-Lösungen in SOA-Umgebungen realisiert werden. Über standar-
disierte Schnittstellen (Web Services, SOAP) können diese von sämtlichen
Systemen genutzt und anforderungsgerecht skaliert werden. Die Imple-
mentierung als Service Provider erlaubt systemweit oder innerhalb von
Domänen Sicherheitsmechanismen, wie beispielsweise Anti Virus, Signa-
tur, Public Key Infrastruktur, zu nutzen.
Architekturansätze
Ein Ansatz für ein Sicherheits-Framework benötigt zentrale Komponenten,
wie zum Beispiel eine Administration, aber auch lokale Laufzeitumgebun-
gen, in denen Sicherheitslösungen lokal umgesetzt werden. In verteilten
Umgebungen ist ein zentrales Management der Sicherheitsinfrastruktur
notwendig. Es bedarf einer systemweiten Security Policy, die verteilt und
umgesetzt werden muss. Besondere Beachtung sollte dabei der Integration
bestehender Systeme geschenkt werden, um vorhandene Benutzer, Rollen
und Rechte oder auch Zertifikate im SOA-Kontext nutzbar zu machen.
Der Architekturansatz einer lokalen Sicherheitslaufzeitumgebung hat
einen großen Einfluss auf die Anwendbarkeit von Sicherheitslösungen in
einer SOA. Die Umsetzung kann durch verschiedene Architekturansätze
erfolgen: Es lässt sich zwischen lokalen und domänenweiten Security
Services unterscheiden. Lokale Services setzen Sicherheitsfunktionen
außerhalb der Applikationen und Services um.
73
www.hessen-it.de
Die lokale Security-Laufzeitumgebung übernimmt den unveränderten Web Service
der Applikation und sichert diesen on-the-fly nach vorgegebenen Security-Regeln
ab. Auf der Empfängerseite überprüft der Security Service den empfangenen,
gesicherten Web Service und stellt den Urzustand wieder her.
Die lokalen Laufzeitumgebungen agieren somit als automatisierte Proxies,
um Sicherheitsfunktionalität aus der Applikation zu nehmen. So kann bei-
spielsweise die in der Policy definierte Verschlüsselung eines Elements
(XML-Encryption) außerhalb der Applikation durchgeführt werden.
Der zentralisierte Security Service bietet die Sicherheitsüberprüfung
als Service, z. B. das Scannen nach Viren in Attachments.
ServiceService SecurityService
SecurityService
ServiceServiceConsumer
DomainSecurity Service
74
SOA-Security: Webservices erfordern zusätzliche Sicherheitsmaßnahmen
Domänenweite Services bieten dafür Sicherheitslösungen, wie beispiels-
weise Virenscanner als Sicherheitsdienst an. Der Vorteil dieser Konzepte
ist die einfache Implementierung, der Nachteil liegt in einer schlechten
Performance. Diese Implementierung eignet sich daher für zeitunkritische
Prozesse oder Sicherheitslösungen, in denen der Performance-Nachteil
gegenüber dem eigentlichen Scan-Prozess zu vernachlässigen ist oder
durch Hardwareinvestitionen ausgeglichen werden kann.
6.5 Fazit
Die Implementierung einer sicheren SOA-Infrastruktur ist keine triviale Auf-
gabe. Neben neuen notwendigen Sicherheitsmethoden, die die Sicher heit
auf Nachrichtenebene gewährleisten, bestehen auch bei traditionellen
Techniken (wie z. B. Antivirus-Lösungen) neue Anforderungen. Unterneh-
men benötigen leistungsstarke Werkzeuge, mit denen diese und weitere
Anforderungen wie Policy-Administration, Workflows für Verteilung und
Orchestrierung automatisiert umgesetzt werden müssen.
Sicherheitsanforderungen wie Authentizität, Vertraulichkeit, Integrität und
Verbindlichkeit können mit der konsequenten Anwendung standardisier-
ter WS-Security Mechanismen gelöst werden. Für Bedrohungen wie SQL-
Injections, DoS-Attacken im SOA-Umfeld sollte eine servicekonforme
Nutzung vorhandener Lösungen möglich sein.
Ein Ansatz mit einem Security-as-a-Service-Konzept bietet diese Möglich-
keiten. Unternehmen können einen Security Service effizient und anforde-
rungsgerecht entweder lokal außerhalb der Applikation oder auch als
domänenweiten Service implementieren. Eine zentrale Orchestrierungs-
und Management-Plattform mit breiten Integrationsmöglichkeiten liefert
Unternehmen die Möglichkeit, vorhandene Lösungen (etwa Metadirec -
tories, PKI) weiterhin im SOA-Umfeld zu nutzen. In Verbindung mit
leistungsstarken Modellierungswerkzeugen und vorkonfigurierten Work-
flows ist die Automatisierung von SOA-Security effizient umzusetzen.
75
www.hessen-it.de
SOA goes B2B: Lessons Learned aus der Automobilindustrie
Dr. Christine Legner, European Business School
7.1 SOA und B2B
SOA – aber wie?
Die Kernidee einer service-orientierten Architektur (SOA) ist leicht erklärt
– sie lässt sich am besten anhand von Plattformstrategien in der Auto -
mobilindustrie verdeutlichen, in der verschiedene Fahrzeugmodelle
baugleiche Komponenten teilen. Bei der konzernübergreifenden Klein -
wagenplattform mit den Modellen Citroën C1, Peugeot 107 und Toyota
Aygo beträgt der Anteil an Gleichteilen ungefähr 60 %. So einleuchtend
die Kernidee einer SOA jedoch ist, so herausfordernd sind die Fragen,
denen sich IT-Verantwortliche derzeit stellen müssen: Was heisst SOA
denn konkret? Und wo fängt man am besten an? Aus Risiko- und Kosten-
überlegungen ist es sicherlich nicht zu empfehlen, bewährte IT-Systeme
mit SOA komplett umzukrempeln oder gar vollständig in Services zu zer-
legen. Es gilt also, die Bereiche zu identifizieren, in denen die gewachsen
Systemlandschaften an ihre Grenzen geraten. Mögliche Symptome dafür
sind ein „Wildwuchs“ an Systemen, welche die steigenden Anforderungen
der Fachbereiche nicht mehr erfüllen können.
7
76
SOA goes B2B: Lessons Learned aus der Automobilindustrie
© Andrzej -
Fotolia.com
B2B-Architekturen als Ansatzpunkt für SOA
Einer der erfolgversprechenden Ansatzpunkte für SOA ist an den Unter-
nehmensgrenzen zu finden. Überall dort, wo die Verzahnung mit Ge schäfts -
partnern enger wird, steigt der Bedarf an elektronischer Kommunikation
und Prozessintegration über die Unternehmensgrenzen hinweg. Amazon
gehört zu den erfolgreichen Beispielen, die durch SOA und Web Services
ihr Partnernetzwerk enger an sich binden und neue Einnahmequellen
erschließen. In der Automobilindustrie lassen sich solche Ansatzpunkte
für SOA ebenfalls ausmachen: Im Zuliefernetzwerk steigt der überbetrieb-
liche Integrationsbedarf bedingt dadurch, dass Hersteller ihre Wertschöp-
fungstiefe reduzieren und Zulieferer ganze Produktions- und Entwick-
lungsumfänge übernehmen. Auf der Vertriebsseite wird die überbetrieb-
liche Integration ebenfalls immer wichtiger, um dem weltweiten Händler-
netzwerk Produktinformationen verfügbar zu machen oder Online-
Services zur Werkstattunterstützung anzubieten. In beiden Bereichen wird
massiv in IT investiert, was sich in den entsprechenden Projektportfolios
der Automobilunternehmen zeigt. Gleichzeitig wird auch deutlich, dass
individuelle Punkt-zu-Punkt-Schnittstellen an ihre Grenzen stoßen. Das
bedeutet, dass in Zukunft leistungsfähigere Integrationsarchitekturen
aufgebaut werden müssen. Im Folgenden wird vor allem von SOA-Poten-
zialen für die Koordination entlang der Zulieferkette die Rede sein. Die
vorgestellten SOA-Ideen wurden im Rahmen der Initiative „SOA in Auto-
motive“ erarbeitet. Neben einem Forscherteam waren verschiedene
Automobilhersteller und -zulieferer (u. a. BMW, Hella KgaA, Magna Steyr,
Siemens VDO, ZF), die Branchenplattform SupplyOn sowie weitere
Technologieanbieter (u. a. SAP, IBM, BEA) beteiligt. Das SOA-Konzept
wurde in Form einer Zielarchitektur für die servicebasierte B2B-Koope -
ration konkretisiert und anschließend durch einen Piloten erprobt.
77
www.hessen-it.de
Heterogenität als Problemstellung der B2B
Unternehmen-zu-Unternehmen (B2B)-Integration war und ist in der Auto-
mobilindustrie stark mit dem Einsatz von Electronic Data Interchange (EDI)
verbunden. Obwohl alle Großunternehmen eine EDI-Infrastruktur auf -
gebaut haben und diese immer noch erweitern, bleibt deren Anwendung
auf wenige stark strukturierte Geschäftsdokumente in der Logistik, wie z. B.
Lieferabrufe, Lieferavis und Bestellung, beschränkt. Hersteller und Zuliefe-
rer nutzen zunehmend die vielfältigen Möglichkeiten des Internets, um
den Koordinationsbedarf entlang des kompletten Produktlebenszyklus –
vom ersten Fahrzeugkonzept über Produktentwicklung und Produktion bis
hin zur Produktnutzungsphase mit anschließender Entsorgung und Recyc-
ling – zu decken. An erster Stelle sind hier die Lieferantenportale – wie z. B.
BMW Group Partner Portal oder VWGroupSupply.com – zu nennen. Diese
haben sich zu sehr mächtigen Plattformen entwickelt und integrieren oft
zahlreiche interne Applikationen, über die Geschäftspartner z. B. aktuelle
Qualitätskennzahlen abrufen oder Reklamationen bearbeiten können.
78
SOA goes B2B: Lessons Learned aus der Automobilindustrie
© S
haw
n H
emp
el -
Foto
lia.c
om
Die Portallösungen stellen zwar eine komfortable Lösung für die Betrei-
ber-, nicht aber für die Lieferantenseite dar. Große Zuliefererunterneh-
men, die ihre internen Prozesse professionell durch IT-Lösungen unterstüt-
zen, müssen im Schnitt 30 bis 50 Portale bedienen. Portale sind für sie zeit-
und kostenaufwändige Mensch-Maschine-Schnittstellen, die einen hohen
Monitoringaufwand und fehleranfällige redundante Datenpflege ver -
ursachen. Angesichts der immer weiter steigenden Anzahl von Portalen,
die selbst oft mehrere hundert Anwendungen umfassen, sehen sich die
Zu lieferer einem „Portaldschungel“ gegenüber. Im Vergleich zur Populari-
tät der Portale konnte sich der XML-basierte Nachrichtenaustausch in der
Automobilindustrie bisher noch vergleichsweise wenig durchsetzen. Eine
Ausnahme ist der auf XML basierende QDX-Standard für das überbetrieb-
liche Qualitäts- und Reklamationsmanagement. Entsprechende B2B-Inte-
grationsprojekte werden in der Regel als Einzelprojekt auf Anforderung
eines Fachbereiches oder eines externen Partners realisiert. Diese
Projekte erfordern erhebliches Integrationswissen und die Realisierung
von Schnittstellen. Zusätzlich sind partnerspezifische Anforderungen zu
berücksichtigen, so z. B. die Vorgaben eines Automobilherstellers an seine
Zulieferer in Bezug auf Datenformate und -qualität.
Eine aktuelle Studie von Supply On zeigt einen stark anwachsenden Anteil
digitaler Prozesse – bei zunehmender Vielfalt der eingesetzten e-Business-
Plattformen. Berücksichtigt man die enorme Komplexität und die Kosten
beim Aufsetzen elektronischer Prozesse, so besteht erheblicher Hand-
lungsbedarf.
79
www.hessen-it.de
7.2 SOA-B2B-Architektur: Öffentliche und interne Sicht
Aufbau der serviceorientierten B2B-Zielarchitektur
Die steigende Vielfalt und Heterogenität der elektronischen Integrations-
beziehungen wird in Zukunft nur durch eine sorgfältig geplante B2B-
Architektur zu bewältigen sein. Serviceorientierte Architekturen liefern
hier zunächst die technischen Grundlagen für den automatisierten Daten-
austausch von strukturierten und unstrukturierten Inhalten in überbetrieb-
lichen Geschäftsbeziehungen. Durch sie lassen sich sowohl die klassische
nachrichtenbasierte Integration, wie im Falle von EDI, als auch eine prozess -
orientierte Integration über Workflows und der Austausch von schwach
strukturierten Dokumenten oder deren Anzeige in Portalen realisieren. Sie
eignen sich daher auch für den Einsatz in weniger hochvolumigen und
strukturierten Kooperationsprozessen, wie z. B. in der Produktentwicklung
oder im Qualitätsmanagement.
SOA ist jedoch noch lange kein Produkt, dass sich „out-of-the-box“ ein -
führen lässt. Vielmehr erfordert SOA grundsätzliche Überlegungen, wie
eine B2B-Architektur auszugestalten ist. Es gilt beispielsweise zu bewer-
ten, welche Funktionalität künftig als Service zu realisieren ist, um so wie-
derverwendet oder schneller zu neuen Prozessvarianten konfiguriert zu
werden. Es ist auch prinzipiell zu überlegen, wie man über Unternehmens-
grenzen über Services interagiert und welche Services ein Partner nutzen
darf. Diese Überlegungen wurden im Rahmen von „SOA in Automotive“ in
einer Zielarchitektur konkretisiert (vgl. Abbildung unten). Ein wichtiges
Hilfsmittel ist die Unterscheidung in eine öffentliche Sicht („Public“) und in
eine interne Sicht („Private“). Während die öffentliche Sicht über die ver-
schiedenen Geschäftspartner hinweg abzustimmen ist und die über -
betriebliche Prozessintegration umfasst, betrachtet die interne Sicht die
interne Umsetzung innerhalb eines Unternehmens. So wird der Anforde-
rung Rechnung getragen, dass interne Prozessabläufe und Systemland-
schaften verschiedener Partner unabhängig voneinander entworfen und
geändert werden.
80
SOA goes B2B: Lessons Learned aus der Automobilindustrie
Abbildung : Serviceorientierte B2B-Architektur
Öffentliche Sicht: SOA ermöglicht m:n-Fähigkeit
Zentrale Bestandteile einer SOA sind (Web) Services, die gekapselte
Geschäftslogik als selbstbeschreibender Service zur Verfügung stellen.
Nutzt man Services in Beziehungen mit externen Geschäftspartnern, so
können diese schnell und ohne großen bilateralen Abstimmungs- und
Realisierungsaufwand über wohldefinierte Schnittstellen elektronisch inte-
ragieren. Eine SOA hat damit das Potenzial, die Vielfalt und Heterogenität
in B2B-Integrationsbeziehungen einzudämmen. Voraussetzung dafür ist
m:n-Fähigkeit, d. h. dass beliebige (m) Lieferanten mit beliebigen (n) Kun-
den die „gleiche Sprache“ an den Prozess- und Systemschnittstellen spre-
chen. M:n-Fähigkeit reduziert die derzeitige Vielfalt überbetrieblicher Pro-
zessvarianten auf ein sinnvolles und beherrschbares Maß und führt dazu,
dass der Abstimmungs- und Integrationsaufwand beim Aufbau elektroni-
scher Kooperationen erheblich sinkt.
Automobilhersteller Zulieferer
ProzessarchitekturProzessarchitektur
Desktop-integration
Business-ServicesApp.-Services
Nach-richten
Service-beschrei-
bungWSDL
Semantik
Service-verzeichnis
Service-verzeichnisWorkflow
Desktop-integration
Business-Services
App.-Services
Workflow
Applikationsarchitektur
Infrastrukturarchitektur
Applikationsarchitektur
Infrastrukturarchitektur
(SOA-basierte) Integrationsarchitektur (SOA-basierte) Integrationsarchitektur
PrivatePrivate
Proze
ssSy
stem
Proze
ssSy
stem
PrivatePrivate
Public
81
www.hessen-it.de
Die Web Service-Standards, die einer SOA zugrunde liegen, nutzen
offene Internet-Standards (XML, SOAP, WSDL) und sichern so eine höhere
Plattformunabhängigkeit und Interoperabilität. Sie liefern dadurch bereits
einen erheblichen Mehrwert gegenüber früheren, sehr viel stärker pro-
prietären Technologien wie EDI. Allerdings reichen das von den Herstel-
lern propagierte techniklastige Service-Verständnis und die rein techni-
sche Interoperabilität von Web Services nicht aus. Überbetriebliche elek-
tronische Vernetzung funktioniert mit SOA nur, wenn alle Partner Web Ser-
vices mit gleicher Semantik verwenden, d. h. sich auf ein fachliches Ser-
vice-Design einigen. Die große Herausforderung liegt dabei in der
betriebswirtschaftlichen Service-Definition sowie in der Verwendung stan-
dardisierter Web Service-Signaturen. Idealerweise ergänzen also Fach-
standards die technische Standardisierung von Web Services. Im Rahmen
von „SOA in Automotive“ wurde die VDA-Empfehlung 4965 für das tech-
nische Änderungsmanagement in m:n-fähige Prozesse und Services über-
führt. Als Teil der unternehmensübergreifenden Produktentwicklung (Col-
laborative Engineering) umfasst das Änderungsmanagement die Bewer-
tung und Entscheidung von Änderungsideen sowie die Umsetzung von
Änderungen in gemeinsamen Entwicklungs-, Planungs- und Fertigungs-
prozessen. Dazu wurde ein „ECR Public Process“ (ECR = Engineering
Change Request) als ereignisgesteuerte Prozesskette mit Erweiterungen
in ARIS dokumentiert. Diese umfassende Dokumentation des öffentlichen
Prozesses schafft ein gemeinsames Verständnis über zwischenbetriebli-
che Prozessabläufe und erweitert damit die herkömmliche Standardisie-
rung um den Prozesskontext. Gleichzeitig bietet der „Public Process“ den
Geschäftspartnern klar definierte Anbindungspunkte für ihre jeweiligen
internen Prozesse („Private Processes“) und ihre interne Prozessdokumen-
tation. Der „ECR Business Service“ setzt die Prozessinteraktion auf System-
ebene um. Automobilhersteller und -zulieferer können so ihre Prozesse im
Änderungsmanagement durch Serviceaufrufe elektronisch koppeln.
82
SOA goes B2B: Lessons Learned aus der Automobilindustrie
Interne Sicht:
SOA erleichert die Anbindung an überbetriebliche Prozesse
Während SOA also Geschäftspartnern ermöglicht, über wohldefinierte
Schnittstellen zu interagieren, adressieren serviceorientierte Ansätze noch
weitere Schwachpunkte der bisherigen B2B-Integrationslösungen. In
einer SOA wird Funktionalität, die in vielen B2B-Integrationsprojekten
benötigt wird, als Service realisiert. Sie wird also nicht redundant imple-
mentiert, wie es angesichts der projektgetriebenen Umsetzung von B2B-
Integrationslösungen häufig der Fall ist. Solche Services stellen in B2B-
Architekturen insbesondere Basisfunktionalitäten zur Verfügung, wie die
Authentifizierung bzw. Autorisierung von externen Partnern oder die Vali-
dierung von XML-Nachrichten. Neben der Wiederverwendung erleichtert
SOA generell auch das Anbinden der internen Prozesse und Systeme an
die externen Schnittstellen. Durch Konvergenz der Plattformen für B2B-
Integration und Enterprise Application Integration (EAI) lassen sich über-
betriebliche Serviceaufrufe eng mit den internen Workflows koppeln, die
eine Weiterverarbeitung und Integration in die entsprechenden internen
Backendsysteme sicherstellen. Im Vergleich zu den traditionellen Formen
der B2B-Integration können nicht nur die Transaktionssysteme (Enterprise
Resource Planning- oder Supply Chain Management-Systeme), sondern
auch Dokumenten- bzw. Content Management Systeme und Reporting-
systeme (Data Warehouses) eingebunden werden. SOA erlaubt insbeson-
dere ein verbessertes Prozesshandling, -Routing und -Monitoring.
Auch die individuelle Anpassung an partnerspezifische Besonderheiten,
wie z. B. Prozessvarianten oder Nachrichtenformate, fällt sehr viel leichter.
Diese wird es – auch wenn die fachliche Standardisierung Fortschritte
macht – sicherlich weiterhin geben.
83
www.hessen-it.de
Diese Aspekte wurden in der Zielarchitektur aus „SOA in Automotive“ für
das technische Änderungsmanagement weiter ausgearbeitet: Im Unter-
nehmen wurde dabei von der bestehenden Landschaft aus zumeist hete-
rogenen Anwendungssystemen ausgegangen, die für die fachliche Verar-
beitung von Änderungsanträgen zuständig sind. Diese Systeme werden
in der Schicht der domänenspezifischen Anwendungsdienste (Applica-
tion Service) als Web Services bereitgestellt, um eine prozessorientierte
Integration zu ermöglichen. Darüber hinaus werden Hilfsdienste, so
genannte Utility Services, entwickelt, die mehrfach benötigte domänen-
übergreifende Funktionalität realisieren. Innerhalb eines Workflows wer-
den die vorhandenen Dienste aufgerufen und miteinander verschaltet.
Mit Hilfe einer Frontend-Integration kann auch die Benutzer-Interaktion in
die Prozesse mit einbezogen werden. Damit lassen sich z. B. Mensch-
Maschine- und Maschine-Maschine-Schnittstellen mit der gleichen Inte-
grationsinfrastruktur realisieren.
7.3 SOA vs. herkömmliche B2B-Integration
Die hier skizzierte SOA für eine überbetriebliche Vernetzung ist derzeit
noch eine Vision. Allerdings konnte sie im Projekt „SOA in Automotive“
bereits für die Zusammenarbeit zwischen Automobilherstellern und –
zulieferern durchgespielt werden. Dies erlaubt mindestens einige Schluss-
folgerungen in Bezug auf die Potenziale, aber auch auf die Herausforde-
rungen bei der Umsetzung in Produktivumgebungen.
Vergleicht man den servicebasierten Ansatz mit einer Realisierung über
Lieferantenportale, so liegt der Nutzen einer SOA in der Vermeidung von
Medienbrüchen und manueller Informationsbereitstellung sowie weniger
Schulungsaufwand für die Nutzer. Im Beispiel bearbeiten die Mitarbeiter
auf Zulieferseite Änderungsanträge in den bestehenden Änderungsmana-
gementsystemen, anstatt sie zusätzlich in Lieferantenportalen zu erfassen.
Dadurch entfällt Aufwand für die Informationsbereitstellung, der im kon-
kreten Fall auf 0,75 Tage geschätzt wurde. Andere Formen der elektroni-
schen Integration (z. B. EDI in Form von bilateralen Punkt-zu-Punkt-Verbin-
dungen und standardisierter Nachrichtenaustausch ohne Prozessstandar-
disierung) weisen zwar ähnliche Vorteile wie der servicebasierte Ansatz
84
SOA goes B2B: Lessons Learned aus der Automobilindustrie
bzgl. des Koordinationsaufwands in den Geschäftsprozessen auf. Jedoch
liegt im Vergleich zu diesen der Mehrwert des servicebasierten Ansatzes in
geringeren Aufwendungen für den Aufbau der elektronischen Prozessinte-
gration. Hierbei kann die Realisierung des „ECR Business Service“ auf
bestehenden Infrastruktur- und Middlewarekomponenten erfolgen, die
bereits für die innerbetriebliche Integration genutzt werden. Es ist folglich
keine parallele B2B-Infrastruktur, wie z. B. im Fall von EDI, erforderlich.
Auch aufgrund der gegenwärtigen Anstrengungen aller Softwareanbieter
ist von einem schnellen SOA-Enabling bei Standardsoftwarepaketen aus-
zugehen, so dass sich eine servicebasierte Kopplung von Geschäftsprozes-
sen in Zukunft wesentlich kostengünstiger realisieren lässt. Gegenüber rei-
nen Nachrichtenstandards und Schnittstellendefinitionen (z. B. in EDI- oder
XML-Syntax) ermöglichen serviceorientierte Ansätze eine stärkere fachli-
che Spezifikation von Services, die nicht nur die Nachrichten (Semantik)
selbst, sondern auch die Prozessinteraktion (Pragmatik) abdeckt. Weiterhin
sieht ein gutes Service-Design zusätzliche Erweiterungskonzepte auf der
Nachrichtenebene vor, so dass partnerspezifische Anpassungen einfacher
realisiert werden können. Außerdem können häufig benötigte Funktionen
für die prozessübergreifende Integration (z. B. Logging, Authentifizierung)
in einer serviceorientierten Architektur als wieder verwendbare Utility Ser-
vices realisiert werden. Durch eine servicebasierte Kooperationsarchitektur
lassen sich folglich Integrationsbeziehungen mit mehreren Partnern und
über mehrere Prozesse hinweg auf Basis einer einheitlichen Integrations-
architektur umsetzen und gleichzeitig flexibel und skalierbarer gestalten.
85
www.hessen-it.de
7.4 Reifegrad und Herausforderungen
SOA-Konzepte und Web Service-Technologien haben mittlerweile die
notwendige Reife für den produktiven Praxiseinsatz in B2B-Kooperationen
erreicht. Die Erfahrungen aus „SOA in Automotive“ zeigen, dass Web
Services sich auf Basis der bestehenden Middlewareplattformen in Unter-
nehmen innerhalb von wenigen Tagen implementieren lassen. Auch die
unternehmensübergreifende Interoperabilität wird weitgehend problem-
los erreicht. Einen großen Anteil daran haben die sog. WS-I Profile, die
frühere Interoperabilitätsprobleme zwischen verschiedenen Herstellern
beseitigt haben und Interpretationsspielräume der WS-Standards effektiv
eingrenzen. Sie decken auch weitergehende Anforderungen im Bereich
Sicherheit (mit dem WS-I Basic Security Profile) und Zuverlässigkeit
(WS-I Reliable Secure Profile) ab. Die heutigen Middlewareplattformen
beinhalten bereits eine komplette technische Infrastruktur zur Realisie-
rung einer SOA. Kernelement bildet der Service Bus, der Serviceaufrufe
an den richtigen Serviceanbieter weiterleitet und diese Weiterleitung
auch garantiert. Des Weiteren realisiert der Service Bus Fehlerbehand-
lungsmechanismen für fehlgeschlagene Serviceaufrufe, z. B. durch Benach -
richtigung des Serviceaufrufenden, Mechanismen zur technischen Trans-
formationen (z. B. mit XSLT) oder semantische Mappings (z. B. Purchase
Orders von RosettaNet nach SAP).
Auf der Basis der in den Unternehmen eingesetzten Middleware-
plattformen lassen sich B2B Web Services innerhalb von wenigen
Tagen realisieren.
86
SOA goes B2B: Lessons Learned aus der Automobilindustrie
Allerdings machen die Erfahrungen aus „SOA in Automotive“ auch deut-
lich, dass es noch einige Hürden auf dem Weg hin zu einer serviceorien-
tierten B2B-Architektur gibt – auch, wenn man die menschlichen Voraus-
setzungen und das Change Management zunächst noch unberücksichtigt
lässt. Eine wichtige Voraussetzung für die erfolgreiche Umsetzung einer
SOA ist der Zugriff auf die benötigte Funktionalität in den Anwendungs-
sytemen über geeignete Servicesschnittstellen. Fehlen diese, so müssen
im Rahmen eines SOA-Enabling entsprechende Serviceschnittstellen
zunächst realisiert werden. Im konkreten Beispiel stellte dies den größten
Aufwandstreiber für eine durchgängige B2B-Lösung, und manchmal
sogar ein unüberwindbares Hindernis, dar und hat letztendlich auch eine
kurzfristige Umsetzung der Zielarchitektur im überbetrieblichen Ände-
rungsmanagement verhindert. Im Projekt zeigte sich, dass die eingesetz-
ten Änderungsmanagementsysteme – auch die Standardsoftwarepakete –
bisher nicht über eine geeignete Serviceschnittstelle verfügten. Ein SOA-
Enabling wäre zwar bei allen Projektpartnern möglich gewesen, sie wurde
jedoch wegen des erheblichen Aufwands in diesem Projekt nicht durch-
geführt. Zu betonen ist, dass dieser Aufwand prinzipiell bei jeglicher
elektronischen Kopplung von Applikationen besteht und damit nicht
SOA-spezifisch ist, sondern in ähnlicher Form bei vielen B2B-Integrations-
projekten beobachtet werden kann. Wenn sich serviceorientierte Archi-
tekturen weiter durchsetzen, wird sich dieser Aufwand jedoch nach und
nach reduzieren, da Anwendungssysteme künftig ihre Funktionalität als
Service bereitstellen. Allerdings zeigt die Erfahrung aus „SOA for Automo-
tive“ auch, dass B2B-Integration nur dann reibungslos funktioniert, wenn
einheitliche fachliche Service-Spezifikationen („Semantik“) existieren und
die öffentlichen Prozesse spezifiziert sind. An dieser Stelle besteht aktuell
dringender Handlungsbedarf. Es ist also notwendig, branchenweit akzep-
tierte Prozess- und Servicedefinitionen zu definieren und zu implemen -
tieren, um so die Potenziale der Serviceorientierung in der B2B-Inte -
gration in vollem Umfang zu nutzen.
87
www.hessen-it.de
7.5 Fazit
Die zunehmende Reife serviceorientierter Architekturen ermöglicht es,
leistungsfähige Prozessplattformen für die B2B-Integration zu realisieren.
Diese sind in der Lage, die bestehenden und künftigen Anforderungen
abzudecken und bergen im Vergleich zu den existierenden Einzellösun-
gen erhebliche Vorteile:
a Prozessplattformen unterstützen die verschiedenen B2B-Kanäle
(Maschine-Maschine und Mensch-Maschine) dadurch, dass der Zugriff
auf Services sowohl über ein Portal als auch über einen plattform- und
organisationsübergreifenden Web Service-Aufruf erfolgen kann.
a Durch Nutzung von XML und Web Services können Prozessplattformen
ein breites Spektrum an Integrationsszenarien abdecken. Im Gegen-
satz zu nachrichtenbasierten (EDI-) Ansätzen sind sie in der Lage, kom-
plexere (Multi-Step) Prozesse abzubilden. Sie sind daher geeignet,
weniger hochvolumige und strukturierte Prozesse zu unterstützen.
a Prozessplattformen entkoppeln die Prozess- von der Anwendungslo-
gik. Mittels Orchestrierung (innerbetrieblich) bzw. Choreographie
(überbetrieblich) von Web Services verschalten sie lediglich Anwen-
dungsfunktionen und beschleunigen so die Umsetzung neuer Pro-
zessvarianten. Ein Prozessvorlagen-Repository enthält Templates für
„Public Processes“, die partnerspezifisch angepasst werden können.
a Durch Konvergenz der Plattformen für B2B-Integration (B2Bi) und
Enterprise Application Integration (EAI) lassen sich überbetriebliche
Serviceaufrufe eng mit den internen Workflows koppeln, die eine Wei-
terverarbeitung und Integration in die entsprechenden internen
Backendsysteme sicherstellen. Letztere umfassen Transaktionssysteme
(ERP, SCM, …) ebenso wie Dokumenten- bzw. Content Management
Systeme und Managementinformationssysteme (Data Warehouses).
a Basis-Services für die überbetriebliche Prozessintegration, wie z. B.
Authentifizierung von Geschäftspartnern, Logging, usw., können zen-
tral bereitgestellt und in verschiedenen Kooperationsbeziehungen
wieder verwendet werden. Diese Services können auch auf einfache
Weise von externen Spezialisten bezogen werden.
88
SOA goes B2B: Lessons Learned aus der Automobilindustrie
SOA als Grundlage zukunftsfähiger B2B-Architekturen
89
www.hessen-it.de
Aktuelle Herausforderungen inB2B-Netzwerken
Was bringt SOA? Wo liegen Herausforde rungen bei der SOA?
Starker Zuwachs digitaler Prozessevon der Produktentwicklung überdie Produktion bis hin zu Garantie,Service und Entsorgung
Vielfalt der Partner, Prozessvarian-ten und eingesetzten Technolo-gien
m:n-Fähigkeit in über -betrieblichen Prozessen:
a Nutzung offener, kostengüns -tiger und weit verbreiteter Internet-Technologien
a Geringerer Abstimmungs- undIntegrationsaufwand durch Services als wohl definierteSchnitt stellen für externe Partner
a Dokumentation der Servi ces ineinem Service-Repository mitexternen Sichten
Fachliche Service-Spezifikation(„Semantik“): z. B. Ergänzung vonFachstandards (VDA, Odette, …)durch Spezifikation von (Web) Services und deren Choreographie
Überbetriebliche (Referenz-)Pro-zesse als Grundlage der elektro -nischen Integration: „Public Pro cesses“, z. B. in der Produkt-entwicklung, im Qualitäts- oder Reklamationsmanagement
Realisierung von B2B-Integrationals Einzellösung auf Anforderungeines Fachbereiches oder Partners
Vielfalt der e-Business-Plattformen(Portale, XML-Nachrichtenaus-tausch, EDI, …)
Aufwände für die Anbindung interner Systeme an unterschied -liche e-Business-Plattformen
Skalierbare, flexible e-Business-Plattform im Unternehmen
a Konvergenz der Plattformen für B2B-Integration (B2Bi) undEnterprise Application Inte -gration (EAI)
a Unterstützung sämtlicher Varianten der B2B-Integration: nachrichtenbasiert (EDI, XML),prozessorientiert (Workflows),benutzerorientiert (Portale)
a Wiederverwendung von Basis-Services (z. B. Authentifizierung,Validierung)
a Workflows zur Weiterverarbei-tung von externen Serviceauf -rufen und Integration in die ent-sprechenden internen Backend-systeme
a Änderbarkeit und Anpassungs -fähigkeit an partnerspezifischeAnforderungen (Datenformate,Prozessvarianten)
Konzeption einer SOA-basiertenB2B-Zielarchitektur für das Unternehmen
Schrittweise Umsetzung im Sinne der B2B-Zielarchitektur
SOA-Enabling der Anwendungssysteme
SOA-Perspektiven: Geschäftsmodelle und Innovationen für das Internet der Dienste
Tobias Conte, Dr. Carsten Holtmann, Benjamin Blau
FZI Forschungszentrum Informatik
8.1 Internet der Dienste
Unternehmen müssen kontinuierlich Antworten auf die Herausforde -
rungen ihrer jeweiligen Umwelt finden – in der Art, wie sie das tun und wie
sie ihre Wertschöpfungsbeziehungen organisieren lassen sich Muster
erkennen: In den 70er und 80er Jahren waren Wertschöpfungsaktivitäten
tenden ziell eher „hart verdrahtet“. Unternehmen strebten es an, möglichst
viele der notwendigen Aktivitäten selbst und integriert anzubieten. Dies
wurde als Ära der vertikalen Integration bekannt. Ende der 80er Jahre
begann man dann, sich stärker zu spezialisieren. Einzelne Prozesse
wurden über Unternehmensgrenzen hinweg ausgelagert und Wertschöp-
fungsketten und -beziehungen begannen, feingranularer zu werden.
Heute und voraussichtlich in der Zukunft schreitet dieser Trend weiter fort:
Unternehmen fokussieren sich auf die Spezialaktivitäten, in denen sie
echte Kernkompetenzen besitzen und global wettbewerbsfähig sind, in
anderen Bereichen stützt man sich auf die Kompetenzen von Partnern.
Unternehmen versuchen, ökosystemartige Umgebungen verbundener
Partner um sich zu gruppieren und die Wertschöpfung erfolgt damit
weniger in definierten Ketten als vielmehr in Netzen, den so genannten
„Service Value Networks“ (siehe Abbildung).
8
90
SOA-Perspektiven: Geschäftsmodelle und Innovationen für das Internet der Dienste
Von hartverdrahteten Wertschöpfungsketten zu
agilen Service Value Networks
Notwendig wird diese flexible Zusammenarbeit u. a. durch den globalen
Wettbewerbsdruck, ermöglicht wird sie durch die serviceorientierten
IT-Paradigmen. Die Idee ist, dass man auf dieser Basis innerhalb von Netz-
werken Geschäftsprozesse agil und dynamisch zusammenfügen kann. Die
Softwarebranche ist selbst ein Pionier in diesem Bereich. Die Unterneh-
men wandeln ihre Softwareprodukte nicht nur in Software-as-a-Service
(SaaS)-Angebote um, sie beginnen auch damit, in Service Value Networks
gemeinsam mit spezialisierten Partnern komplexe Dienste anzubieten.
Aus der Gesamtheit solcher und ähnlicher, teilweise untereinander ver-
knüpfter Servicenetzwerke wird die Entwicklung einer Infrastruktur erwar-
tet, die auch als das „Internet der Dienste“ charakterisiert wird.
HartverdrahteteWertschöpfungs-
ketten
Spezialisierungund
Konsolidierung
Agile ServiceValue Networks
91
www.hessen-it.de
Revolution des Softwarevertriebes: Software-as-a-Service
Neben der SOA-Entwicklung, die vornehmlich in Unternehmen Wirkung
erzeugt, sind diverse weitere bedeutsam, die eine Revolution unterneh-
mensübergreifender Leistungsprozesse möglich machen sollen. Allge-
mein lassen sich diese unter dem Begriff „X-as-a-Service“ zusammenfas-
sen. Das „X“ kann dabei für Software, Infrastruktur und Plattform stehen,
wobei erstere hier im Vordergrund steht.
Bei Software-as-a-Service (SaaS) handelt es sich um ein Vertriebsmodell,
mit welchem Anwendungen vom Service-Anbieter gehostet werden und
über ein elektronisches Netzwerk wie das Internet den Konsumenten nach
dem Prinzip „one-to-many“ zur Verfügung gestellt werden. „One-to-many“
bezeichnet dabei die Softwarenutzung durch mehrere Unternehmen
parallel (Multiagentenfähigkeit) jeweils über das Internet. Eigentümer der
Software bleibt in diesem Falle der Anbieter. Er ist es auch, der die
Anwendung betreibt und zentral aktualisiert.
Die Entwicklung hin zu SaaS kann auf einige Treiber und Gründe zurückge-
führt werden. Zum einen sorgen fallende Transaktions- und Kommunikati-
onskosten dafür, dass Anbieter Software betriebsfertig über das Internet
anbieten und so Skaleneffekte nutzen können. In Verbindung mit den sin-
kenden Kosten bietet sich nun die Möglichkeit, bisher weniger erschlossene
Märkte zu bedienen. Im Vergleich zu traditioneller Software bezahlen Kun-
den typischerweise keine einmalige Lizenzgebühr plus Wartungsgebühren,
sondern eine Nutzungsgebühr pro Einzelnutzung („pay-per-use“) oder auf
Periodenbasis („Subscription Fee“). Diese Preise beinhalten auch die vom
Anbieter durchgeführten Updates. Während lizenzbasierte Geschäftsanwen-
dungen aufgrund ihres Preises und ihrer Komplexität oftmals nur für große
Unternehmen interessant waren, besteht nun die Möglichkeit, nutzungsba-
siert oder auf periodischer Basis auch kleine und mittelständische Unterneh-
men (KMU) zu bedienen und so den oftmals gesättigten Markt der Großun-
ternehmen zu erweitern. Für KMU werden On-Demand-Lösungen attraktiv,
da sie bei Bedarf genutzt werden können, hohe Upfront-Investitionen für
einmalige Lizenzen der Vergangenheit angehören bzw. Bedarfsschwankun-
gen einfacher aus geglichen werden können. Beispielsweise werden On-
Demand-Appli kationen als Mittelstandslösung angeboten, die ab 133 Euro
monatlich bezogen werden kann (Stand 2009).
92
SOA-Perspektiven: Geschäftsmodelle und Innovationen für das Internet der Dienste
Entwicklungsstufen: Eine einfache Typologie
Der Begriff „Internet der Dienste“ wurde bisher in der akademischen Welt
noch nicht erschöpfend definiert, Impulse kommen hauptsächlich aus der
industrienahen Forschung. Das Internet der Dienste folgt – einfach
gesprochen – dem Gedanken, dass im künftigen Internet nicht nur primär
Inhalte in Form von Webseiten verfügbar sein werden, sondern dass viel-
mehr Dienste (wie bspw. Google Maps) nutzbar sind, die Unternehmen
und Privatanwendern Informationen zielgerichtet und damit personalisiert
aufbereiten. Diese Dienste werden miteinander kombinierbar sein und
können so zu komplexen Diensten zusammengefügt werden. Komplexe
(oder zusammengesetzte) Dienste beinhalten typischerweise die Orches-
trierung und den Aufruf mehrerer vorhandener Dienste. Diese können
von unterschiedlichen Parteien kommerziell angeboten werden und letzt-
endlich einen Geschäftsprozess abbilden.
Definition „Internet der Dienste“
Das Internet der Dienste ist ein globales Netzwerk, welches das
Design, das Auffinden, das Kombinieren, den Handel und die Nut-
zung interoperabler, elektronischer Services im Web ermöglicht.
(angelehnt an Papazoglou 2007)
Erste Schritte hin zu einem Internet der Dienste sind mit den allgemein
bekannten Entwicklungen zu SaaS bereits getan, weitere weniger
bekannte und komplexere Entwicklungen sind bereits zu beobachten und
lassen sich mit der folgenden Typologie abgrenzen.
93
www.hessen-it.de
Typologie von Business Services
Die bekannten Phänomene können in vier Quadranten klassifiziert
werden, die sich anhand der Dimensionen aufspannen lassen:
a Interaktionsgrad bei Erstellung und Angebot des Dienstes
a Komplexitätsgrad des Dienstes / der Komposition
Die Typologie grenzt demnach die Dienste nicht hinsichtlich ihres Typs
„X-as-a-Service“ ab, sondern anhand ihrer Komplexität und ihres Koopera-
tionsgrades über Unternehmensgrenzen hinweg.
Grad der Komplexität
Gra
d d
er In
tera
ktio
n 1 32 4
Ein
(do
min
iere
nder
)A
nbie
ter
Vie
le A
nbie
ter
Einfacher Dienst Komplexer Dienst
Aggretiertes Angeboteinfacher Dienste übereinen Marktplatz.Funktionale Integrationwird nicht unterstützt.
Angebot einfacher Dienste durch einzelnes Unternehmen.
Angebot komplexer Dienste durch einzelnesUnternehmen.
Integriertes Angebotkomplexer Dienste, die aus einfachen oder komplexen Teildiensten bestehen und über einen Marktplatz vertrieben werden.
94
SOA-Perspektiven: Geschäftsmodelle und Innovationen für das Internet der Dienste
Quadrant 1: Einfache Dienste durch einzelne Anbieter
Die Vielfalt von als SaaS angebotenen einfachen Web Services ist heute
schon riesig. Paradebeispiele sind die von Google offerierten Dienste wie
z. B. GoogleMaps (http://maps.google.com), einem Kartendienst, der mit
wenigen Zeilen Code in Webseiten und Mash-Ups integriert werden kann,
oder Google Docs (http://docs.google.com) als sozusagen „webbasierte
Office-Lösung“. Weitere Beispiele für einfache Web Services sind Ama-
zons Simple Storage Service (S3) (http://aws.amazon.com/s3) und die Elastic
Compute Cloud (EC2) (http://aws.amazon.com/ec2). Während S3 und EC2
kostenpflichtig sind, bietet Google seine GoogleMaps-Applikation
kostenfrei an. Auch Unternehmen können sich kostenlos auf GoogleMaps
eintragen.
Quadrant 2: Einfache Dienste von Anbieterverbünden
Des weiteren entwickeln sich Web Service-Marktplätze wie Strikeiron
(www.strikeiron.com) oder Xignite (http://xignite.com). Sie stellen anderen
Service Providern eine Plattform zur Verfügung, auf der sie ihre kommerziel-
len Dienste über einen gemeinsamen Kanal vertreiben können. Solche
Marktplätze bieten heute lediglich recht rudimentäre Infrastrukturdienste
an. Bis auf einen Katalog der angebotenen Dienste, einem thematischen
Clustering und einer Suchfunktion werden keine zusätzlichen, technisch
ausgefeilten Infrastrukturdienste angeboten. Funktionale Integration wird
beispielsweise ebenso wenig angeboten wie ein gemeinsames Monitoring.
95
www.hessen-it.de
Quadrant 3: Komplexere Dienstkonfigurationen
durch einzelne Anbieter
Es sind aber nicht nur einfache Dienste, die on-demand zur Verfügung
gestellt werden. Auch Mehrwertdienste, die komplexe Geschäftsprozesse
unterstützen, werden bereits über das Netz angeboten. Beispiele hierfür sind
Salesforce.com (www.salesforce.com) und Netsuite Inc. (www.netsuite.com), die
mit ihren vollständig webbasierten CRM-Lösungen den Markt der Geschäfts-
anwendungen revolutionierten. Einzelkomponenten dieser Anwendungen
können dynamisch zu nutzerspezifischen Prozessen modelliert werden.
Einen Schritt weiter in Richtung des vierten Quadranten geht AppEx-
change, der von Salesforce.com betriebene Marktplatz für On-Demand-
Services. Die Idee von AppExchange (www.salesforce.com/appexchange) ist
es, komplementäre Angebote um Salesforce CRM herum zu gruppieren,
um die eigene Werthaltigkeit zu erhöhen. Hier werden nicht nur eigene,
sondern vor allem Applikationen von Drittanbietern (Partner und freie
Softwareentwickler) angeboten. Die offerierten Dienste sind voll integrier-
bar in Salesforce CRM. Jedoch handelt es sich dabei um Services, die auf
eine Kernanwendung ausgerichtet sind und daher alle auf der Plattform
force.com basieren. Dadurch wird die Integration beträchtlich erleichtert.
Die von AppExchange angebotenen Infrastrukturdienste sind demnach
zwar durch einen Plattformdienst erweitert, jedoch gibt es auch hier kein
gemeinsames Monitoring oder eine gemeinsame Abrechnungskompo-
nente für alle angebotenen zusammengesetzten Services.
96
SOA-Perspektiven: Geschäftsmodelle und Innovationen für das Internet der Dienste
Generell zielte SaaS bisher vor allem auf die kostengünstige Bereitstel-
lung von isoliert stehenden Geschäftsanwendungen ab. Anbieter dieses
oftmals „SaaS 1.0“ genannten Konzepts warben meist mit schneller
Einführung und niedriger Total Cost of Ownership (TCO). Seit wenigen
Jahren zeichnet sich allerdings eine Entwicklung in Richtung „SaaS 2.0“
ab, die man unter anderem in der Evolution des von Salesforce.com ange-
botenen Portfolios beobachten kann. 1999 startete das Unternehmen mit
seiner isoliert stehenden Geschäftslösung Salesforce CRM. Seitdem hat
Salesforce.com ein Ökosystem an Partnern um sich gruppiert, das das
Kernprodukt mit komplementären Angeboten erweitert, die seit 2005 auf
AppExchange angeboten werden. Diese Entwicklung spiegelt SaaS 2.0
wider. Software-as-a-Service-Lösungen sollen als integrierte Geschäfts -
lösungen komplexe Geschäftsprozesse unterstützen. Durch die Orches-
trierung modularer Teildienste findet nicht nur eine organisationsüber-
greifende Zusammenarbeit in Service-Netzwerken statt (vgl. Abbildung
auf S. 91). Durch die freie Kombinierbarkeit der Teildienste können Konsu-
menten die komplexen Dienste deutlich flexibler an ihre Bedürfnisse
anpassen, als dies bei allein stehenden SaaS 1.0- Anwendungen möglich
ist. Auch nahtlose Integration in Legacysysteme soll in SaaS 2.0-Anwen-
dungen unterstützt werden.
Quadrant 4: Komplexe Dienstkonfiguration durch
Wertschöpfungs netze
Auch wenn das Salesforce-Angebot schon ein sehr umfassendes Lösungs -
spektrum umfasst, besteht weiterhin Forschungsbedarf im Bereich kom-
plexer Services, die von unterschiedlichen, gleichberechtigten Anbietern
dynamisch zusammengesetzt werden können. Dieser vierte Quadrant
wird derzeit von dem Projekt THESEUS/TEXO adressiert. Hier geht es um
die Bereitstellung einer offenen Plattform, auf der Diensteanbieter und
-konsumenten zusammentreffen und komplexe wie auch einfache
Dienstleistungen handeln können.
97
www.hessen-it.de
8.2 Forschungsprojekt TEXO
TEXO ist Teil des Dachprojekts THESEUS (http://theseus-programm.de), das
vom Bundesministerium für Wirtschaft und Technologie (BMWi) gefördert
wird. Ziel ist es, eine neue internetbasierte Infrastruktur für die Wissens-
und Dienstleistungsgesellschaft zu entwickeln. Um Wissen im Internet
besser verfügbar zu machen, werden in unterschiedlichen Forschungs-
projekten (Use Cases), die jeweils von renommierten deutschen Techno-
logieunternehmen geführt werden, anwendungsorientierte Basistech -
nologien entwickelt und evaluiert. Es werden nicht nur neue Werkzeuge
und Dienste erwartet, sondern auch Fortschritte im Hinblick auf deren
wirtschaftliche Verwendung.
Das Forschungsprojekt TEXO wird von SAP geführt und mit 11 weiteren
Partnern aus Industrie, Forschungseinrichtungen und Universitäten be -
arbeitet. Insgesamt befassen sich etwa 55 Wissenschaftlerinnen und
Wissenschaftler mit TEXO. TEXO zielt auf den Entwurf und die prototypi-
sche Umsetzung einer sozio-technischen Infrastruktur, innerhalb welcher
komplexe, zusammengesetzte (elektronische) Dienste über das Internet
gehandelt werden können. TEXO wird also den vierten Quadranten der
oben aufgezeigten Typologie zum Leben erwecken und dabei alle Phasen
des Dienstleistungslebenszyklus unterstützen (vgl. Abbildung auf S. 99):
a Bevor Teilnehmer des Internet der Dienste einen Dienst anbieten
oder nutzen können, erfolgt die Initiierung im Netzwerk.
a Die Innovationsphase enthält die Bereiche Ideengeneration,
deren Bewertung, Marktanalysen und Entwicklung.
a Danach erfolgt mit der Angebotsphase die
Kommerzialisierung eines Dienstes.
a Die darauf folgende Matchmakingphase
kann in Marketing und Sales unterteilt werden.
a Nach dem Matchmaking, in der Angebot und Nachfrage
zusammengeführt und ggf. Preise und weitere
Diensteigenschaften verhandelt wurden,
a folgt die Nutzungsphase, auf die letztendlich die Feedbackphase
folgt. Das Feedback der Beteiligten stößt wiederum die
Innovationsphase neu an.
98
SOA-Perspektiven: Geschäftsmodelle und Innovationen für das Internet der Dienste
Dienstleistungslebenszyklus
Eine solche Infrastruktur wird mit der TEXO Services Management
Platform bereitgestellt werden. In hochgradig modularen, dynamischen
Umgebungen wie dem Internet der Dienste spielen Intermediäre, die
Angebot und Nachfrage zusammenbringen, eine wichtige Rolle. Service
Broker erzeugen einen ökonomischen Wert, indem sie als Infomediär auf-
treten oder kompatible, modulare Dienste zu komplexen Diensten zusam-
menfügen. So können bereits existierende Dienste von unterschiedlich -
sten Anbietern kombiniert werden. Durch eine solche Reallokation entste-
hen neue, innovative Anwendungen. Die TEXO Services Management
Platform tritt sowohl als Koordinator als auch als Integrator und Schnitt-
stelle auf, um alle beteiligten Parteien zusammenzubringen. Es werden
sowohl Geschäftsanwendungen als auch deren Realisierung durch tech-
nische Dienste betrachtet. Die TEXO Service Management Platform eröff-
net damit kleinen und mittelständischen Dienstleistern neue Märkte und
ermöglicht es Dienstkonsumenten, ihre Software dynamisch an Verände-
rungen anzupassen.
ExterneInnovation
Initiierung Innovation Angebot
W!W) W@
W$
W%
Match-making
Nutzung
Feedback
Dienstleistungs-lebenszyklus
99
www.hessen-it.de
8.3 Marktpotenzial serviceorientierter IKT
Das Marktpotenzial, das serviceorientierten Ansätzen zugesprochen wird,
ist sehr bedeutsam und wird später noch konkreter illustriert. Im Vorder-
grund der weiteren Ausführungen steht aber die Frage, welchen Einfluss
diese auf die Geschäftsmodelle der Anbieter haben werden. Internetba-
sierte Geschäftsmodelle gelten als einer der meist diskutierten, jedoch
noch immer nicht im Detail verstandenen Aspekte im E-Business. Das gilt
insbesondere für lose gekoppelte Geschäftsnetzwerke.
Im Folgenden werden wir nach einem kurzen Blick auf einige Marktzahlen
zur Entwicklung serviceorientierter Ansätze eine ausgewählte Umset-
zungsvision des Internet der Dienste präsentieren und die Chancen und
Risiken für die Beteiligten beispielhaft umreißen.
Die Prognosen von Marktanalysten, die in den vergangenen Jahren für
serviceorientierte IKT verfügbar sind versprechen nahezu konsistent ein
enormes Potenzial und lassen die Serviceorientierung in der Presse als
einen der derzeit wichtigsten IKT-Trends erscheinen: 31 % der Business-
und IT-Manager halten SaaS bzw. SaaS-Plattformen sogar für den derzeit
wichtigsten Trend der Softwarebranche (Quelle: Studie der Sand Hill
Group und der McKinsey&Company in Enterprise Software Customer
Survey 2008).
Weltweit werden laut Gartner im Jahre 2011 mehr als 25 % des Umsatzes
bei Geschäftsanwendungen durch SaaS erzielt werden. Konkret wird die
Entwicklung von 2006 14,7 %, über 2007 16,0 % auf geschätzte 26,3 %
2011 ansteigen. Für Deutschland prognostiziert die Experton Group für
2010 einen Gesamtumsatz von 577 Mio. Euro, das entspricht einem
Zuwachs von 113 % im Vergleich zu 2007.
100
SOA-Perspektiven: Geschäftsmodelle und Innovationen für das Internet der Dienste
KMU sind laut der Sandhill Group und McKinsey dabei die Kernziel-
gruppe. Nach einer Studie in den USA geben heute kleine Unternehmen
mit weniger als 100 Mitarbeitern bereits 26 % ihres Budgets für On-
Demand-Software aus. Dabei sind nach einer Gartner-Studie die belieb-
testen Funktionen Customer Relationship Management (CRM), Enterprise
Resource Planning (ERP), Supply Chain Management (SCM), Storage und
Kollaborationsanwendungen – insgesamt meist Funktionen, die typischer-
weise nicht den Kern des eigentlichen Geschäfts der Anwender darstellen
dürften.
Ähnliche relative und deutlich höhere absolute Dimensionen lassen sich
für die gesamte XaaS bzw. Cloud Computing-Entwicklung finden. Merrill
Lynch (Quelle: The Cloud Wars, 2008) prognostiziert, dass Cloud Compu-
ting im Jahre 2011 einen Anteil von ca. 12 % des gesamten, weltweiten
Softwareumsatzes erreichen kann. Hier ist nicht nur der Markt der
Geschäftsanwendungen, sondern der gesamte Softwaremarkt die Basis
für die Berechnung. Insgesamt berechnet Merril Lynch einen Umsatz von
744 Mrd. US Dollar für Software, davon fallen 237 Mrd. US Dollar auf
Geschäftsanwendungen. Der Umsatz von Cloud Computing wird dabei
auf 95 Mrd. US Dollar geschätzt.
Wichtiger als die Marktprognosen sind an dieser Stelle aber die dazu zu
überwindenden Hindernisse. Sowohl auf Kunden- wie auch auf Anbieter-
seite ist ein Wandel zu vollziehen. Beim Kunden sind die meist zitierten
Bedenken, die aus dem Weg zu räumen sind, heute offensichtlich immer
noch in den Bereichen Security und Netz- /Systemverfügbarkeit zu finden.
Bedenken bzgl. Integration, wirklicher Reduktion der TCO und fehlender
Funktionalität dürften laut einer Forrester-Studie jedoch ebenso große Hür-
den darstellen. Ist der Schritt zur Nutzung gegangen, besteht die Kern -
herausforderung für den Kunden darin, die neu gewonnene Flexibilität
dann auch zu nutzen und kommerziell zum Effekt zu bringen – technische
und wirtschaftliche Change-Prozesse müssen hier also eng abgestimmt sein.
101
www.hessen-it.de
Für bereits etablierte Anbieter von Unternehmenssoftware ist eine Ände-
rung hin zu On-Demand-Delivery ein wohl noch substantiellerer Schritt,
da er das Geschäftsmodell radikal tangiert: Bisherige lizenzorientierte
Geschäfts- bzw. konkreter: Ertragsmodelle basierten zumeist auf den Säu-
len „Lizenzgebühren“, „Customizing/Consulting“ sowie regelmäßig wie-
derkehrenden Wartung („Maintenance“).
Bei SaaS-Geschäftsmodellen sieht sich der Anbieter weiterhin initialen
Kosten für Entwicklung, Marketing etc. ausgesetzt, Umsätze werden aller-
dings erst nach und nach durch nutzungsbedingte oder monatlich
berechnete Gebühren generiert, wobei zudem laufende Bereitstellungs-
kosten (für z. B. Serverkapazität) existieren. Das heißt letztendlich, dass
durch das Mietmodell von SaaS während der Wachstumsphase eines
SaaS-Geschäfts Erträge typischerweise deutlich langsamer, dafür aber
kontinuierlicher erzielt werden. Richtet sich das Angebot tendenziell eher
an KMU, wäre im Vergleich zu großen Unternehmen ein Mehraufwand
nötig, wenn Vertrieb und Bereitstellung nicht (z. B. durch gemeinsame
Plattformen, siehe hinten) effizienter organisiert werden können.
Der Bedarf für Customizing und Consulting auf Kundenseite könnte im
SaaS-Modell beschränkter sein, da die Implementierung bzw. Installation
beim Kunden wegfällt. Andererseits ist die Personalisierung und Lösungs-
integration mit bestehender Infrastruktur wohl in vielen Fällen trotzdem
erforderlich und insbesondere bei komplexeren SaaS-Anwendungen wei-
terhin zu erwarten. Beispielsweise arbeitet Salesforce.com mit einer Vielzahl
an Consulting-Partnern zusammen, da Schulungen bzgl. der Funktionalität
und weiterer Dienste wie force.com vom Kunden stark nachgefragt werden.
Da Professional Services wie Beratung und Anpassung im traditionellen
Lizenzgeschäft oftmals größere Erträge bringen als die Lizenzen selbst,
müssen die möglichen Konsequenzen in allen drei bisherigen Erlösquel-
len möglichst individuell exakt antizipiert werden, da die Umstellung auf
ein SaaS-Angebot umfassende Auswirkungen auf die Anbieter hat. Darü-
ber hinaus sind die Wechselwirkungen mit den Unternehmenspartnern
für die Angebotsmodelle der oben eingeführten Quadranten 2, 3 und 4
von großer Bedeutung (vgl. Abbildung auf S. 94).
102
SOA-Perspektiven: Geschäftsmodelle und Innovationen für das Internet der Dienste
8.4 Geschäftsmodelle für das Internet der Dienste
Welche neuen Geschäftsmodelle sind nun in einer offenen Serviceplatt-
form, wie sie das TEXO-Konsortium anstrebt, denkbar? Potenziell natürlich
unendlich viele. Zur Illustration seien einige skizziert, wobei wir vereinfa-
chend die Annahme treffen, dass die gesamte Infrastruktur von einem
Anbieter betrieben wird. Die andere Extremform ist die eines rein dezen-
tralen Ansatzes, ein Kontinuum dazwischen ist ebenso denkbar.
Um ein Geschäftsmodell vereinfacht zu beschreiben, greifen wir auf die
Geschäftsmodelldefinition von Stähler (2001) zurück. Sie enthält die
Elemente „Architektur der Wertschöpfung“ unter Berücksichtigung der
beteiligten „Agenten“, eine Beschreibung des „generierten Kunden -
nutzen“ sowie „Art und Ursprung der Erträge“.
Grundsätzlich gehören die Akteure einer solchen Plattform fünf grund -
legenden Rollen an: Plattformbetreiber, Servicekonsument, Serviceanbie-
ter, Communitymitglied und Serviceinnovator. Die beiden letztgenannten
Rollen werden im Folgenden vernachlässigt, da sie spezielle Rollen dar-
stellen, die größtenteils in Überlappungen mit den drei erstgenannten
Rollen auftreten dürften. Die Abbildung unten zeigt, welche Infrastruktur-
dienste auf der Plattform (Servicemarktplatz) vom Betreiber zur Verfügung
gestellt werden könnten, um den eigentlichen Serviceanbietern und
-konsumenten eine geeignete Infrastruktur zur Unterstützung aller Phasen
des Lebenszyklus zu ermöglichen (die Zahlen beziehen sich jeweils auf
die jeweiligen Phasen im Dienstleistungslebenszyklus).
103
www.hessen-it.de
Infrastrukturdienste auf der Serviceplattform
Für die Initiierungsphase (0) bietet die Plattform ein Identitätsmanagement
und gibt grundlegende Standards vor. Innovationsdienste erleichtern
Innovatoren (1) die Neuentwicklung und Evolution von Diensten. In der
Angebotsphase (2) werden vorrangig Dienste zur Verfügung gestellt, die
das Service Engineering – z. B. ein Plattformservice, der Serviceanbieter bei
der Implementierung ihrer Dienste unterstützt, ein Infrastrukturdienst
sowie ein juristischer Dienst, der Serviceanbieter für rechtliche Gegeben-
heiten sensibilisiert – und das Servicemarketing unterstützen. In der Match-
makingphase (3) können sowohl ökonomische, rechtliche als auch techni-
sche Dienste angeboten werden. Beispielsweise könnten allgemeine
Geschäftsbedingungen (AGBs) von Anbieter und Konsument abgeglichen
und ggf. angepasst werden. Semantische Technologien und Service Repo-
sitories unterstützen die Komposition von Teildiensten zu komplexen
Diensten. Außerdem können dynamische Preis- und Allokationsdienste
den aus ökonomischer Sicht effizienten Dienst ermitteln und dessen Preis
festlegen. Monitoringdienste überwachen in der Nutzungsphase (4) die
W!W)
W@
W$
W%
W#
104
SOA-Perspektiven: Geschäftsmodelle und Innovationen für das Internet der Dienste
erbrachten Dienste. Außerdem können die Angebote potentiell über meh-
rere Kanäle auf unterschiedlichsten Endgeräten angeboten werden. Im
Anschluss an die Nutzung werden dann Services für Abrechnung und
Bezahlung der genutzten Dienste bereitgestellt. Dienste, die Communities
unterstützen, sollen abschließend qualitativ hochwertiges Feedback (5)
ermöglichen und damit neue Serviceinnovation anstoßen (1).
Des weiteren können verwandte Beratungsleistungen wie Marktanalysen,
Schulungen, Nachfrageaggregation und weiterführende Integrations-
dienste von plattformexternen Dienstleistern angeboten werden. Glei-
ches gilt für IaaS-Dienste. Speicherplatz und Rechenleistung muss nicht
notwendigerweise von der Plattform bereitgestellt werden. Auch hier
erwarten wir die Herausbildung spezialisierter Partner, die Serviceanbie-
tern entsprechende Leistungen anbieten werden.
Durch die Flexibilität einer Serviceplattform können profitabel
Nischendienstleistungen angeboten werden. So kann ein Anbieter
durch Re-Konfiguration vorhandener Komponenten in unterschied-
lichen komplexen Diensten auch Kundenbedürfnisse befriedigen,
die fernab der Massenbedürfnisse liegen.
105
www.hessen-it.de
© D
an C
olli
er -
Foto
lia.c
om
Nutzen für Servicekonsumenten
Der generierte Nutzen für den Servicekonsumenten lässt sich grob in sie-
ben Kategorien einteilen: erhöhte Flexibilität, Qualitätssteigerung,
Anwendungsintegration, Komplexitätsreduktion, Wiederverwendbarkeit,
Kostenreduktion und schnelle Anpassung. Der postulierte Nutzen einer
Serviceplattform ist demnach eng verwandt mit den generellen Nutzen-
versprechen eines SOA-Einführungsprojekts.
a Flexibilität: Auf dem Servicemarktplatz werden nicht nur komplemen-
täre, sondern auch gleichartige Services angeboten. Im Zusammenspiel
mit der leichteren Integrierbarkeit der Dienste kann der Kunde hier
vereinfacht zwischen Anbietern wechseln („switch on the fly“). Dadurch
sinken für den Kunden insgesamt die Umstellungskosten bei Anbieter-
wechsel („Switching Costs“). Im Allgemeinen ist ein Konsument Umstel-
lungskosten bei einem Anbieterwechsel ausgesetzt, wenn eine Investi-
tion, die bezüglich des bestehenden Anbieters erbracht werden musste,
für einen neuen Anbieter erneut aufgebracht werden müsste. Im tradi-
tionellen Lizenzgeschäft mit hohen Initialkosten und langfristigen
Wartungsverträgen findet sich der Kunde sehr schnell in einer solchen
Situation wieder. Dies führt letztendlich dazu, dass starke Abhängigkei-
ten („Lock-In-Situationen“) entstehen, die den Kunden daran hindern,
Serviceanbieter zu wechseln, obwohl andere für ihn vorteilhafter wären.
SaaS-Anwendungen werden entweder nutzungsbasiert oder auf monat -
licher Basis („Subscription Fee“) abgerechnet. Ist der Kunde nun unzu-
frieden, ist es für ihn beträchtlich einfacher und kostengünstiger, den
Anbieter zu wechseln. Durch das Angebot gleichartiger, konkurrierender
Dienste auf der Plattform wird dieser Effekt noch verstärkt. Es fallen zwar
weiterhin Integrationskosten an, diese schlagen aber wegen gemeinsa-
mer Standards bei einem Anbieterwechsel nicht zwangsläufig doppelt
zu Buche. Des weiteren wird durch den Marktplatz, der eine weite Masse
an Kunden erreicht, das Anbieten von Nischenprodukten profitabel.
So können deutlich mehr Unternehmen mit spezifischen Anwendungen
versorgt werden. Damit könnte die gegenwärtige Situation vieler
Konsumenten beträchtlich verbessert werden – laut einer Forrester-Stu-
die von 2007 finden 42 % SaaS-interessierte Unternehmen momentan
keine passenden On-Demand-Anwendungen.
106
SOA-Perspektiven: Geschäftsmodelle und Innovationen für das Internet der Dienste
a Qualitätssteigerung: Geringere Switching Costs und Lock-In-Effekte
erhöhen den Druck auf die Anbieter, was wiederum die Qualität der
Dienste erhöht. Um sich zu differenzieren, müssen Anbieter nicht nur
kompetitive Preise bieten, sondern vor allem über die Servicequalität
Kunden binden. Servicequalität gilt mittlerweile als der wichtigste
Abgrenzungsfaktor.
a Anwendungsintegration: Die Möglichkeit der On-Premise-Integration
der Dienste erhöht Flexibilität. Diese Eigenschaft, die als eine der
Alleinstellungsmerkmale der TEXO Service Management Platform gilt,
kann von Integrationsdiensten auf der Plattform sowie von externen
Partnern unterstützt werden.
a Komplexitätsreduktion: Der Betrieb der Hard- und Software sowie
der Infrastruktur verlagert sich vom Kunden auf die Dienstanbieter
bzw. den Plattformbetreiber. Dies verringert die Komplexität und den
Ressourceneinsatz auf Kundenseite beträchtlich. Auch Updates und
Upgrades werden zentral durchgeführt. So spart der Servicekonsu-
ment nicht nur den Aufwand, sondern kann auch sichergehen, dass an
allen Arbeitsplätzen dieselbe Version verfügbar ist. Auch im Falle von
Nichterfüllung vereinbarter Service Level Agreements (SLAs) unter-
stützt die zentrale Monitoringkomponente der Plattform und bietet
dem Servicekonsumenten einen zentralen Ansprechpartner („one-face-
to-the-customer“). Besteht ein komplexer Dienst beispielsweise aus
drei Teildiensten, muss man sich als Konsument auf die Zuverlässigkeit
von drei Anbietern verlassen können, es gibt drei unterschiedliche
SLAs. Fällt nun ein Teilservice aus, entfaltet der komplexe Service gar
keinen bzw. nicht den vollen Nutzen für den Kunden. Ohne einen zen-
tralen Servicemarktplatz („Single-Point-of-Access“) müsste der Konsu-
ment nun selbst Kompensationszahlungen des betreffenden Anbie-
ters einfordern. Je mehr Anbieter am Dienst beteiligt sind, umso kom-
plexer die Verrechnung unzureichend erbrachter Dienste und die
Ermittlung des Verursachers.
107
www.hessen-it.de
a Wiederverwendbarkeit: Wenn der Kunde auf der Serviceplattform
keine passenden Applikationen findet, bietet die Plattform ein Frame-
work (PaaS) an, mit dessen Hilfe eigene Anwendungen implementiert
werden können. Die selbst implementierten Dienste kann der Kunde
wiederum auf dem Marktplatz anbieten und somit selbst zum Service-
anbieter werden.
a Kostenreduktion: Durch die Möglichkeit, Geschäftsanwendungen
nutzungsbasiert beziehen zu können, müssen Unternehmen nur noch
ihre tatsächliche Nutzung bezahlen. Gerade für kleine und mittelstän-
dische Unternehmen (KMU) war es bisher oftmals unwirtschaftlich,
lizenzbasierte Anwendungen zu betreiben, wenn sie nur wenige Male
zum Einsatz kommen. Durch das On-Demand-Modell ändert sich
diese Situation – KMU können bei Bedarf auf benötigte hochwertige
Applikationen zugreifen. Dies kann nicht nur Kosten reduzieren,
sondern auch die Qualität erhöhen.
a Schnellere Einsatzfähigkeit: Da die SaaS-Anbieter bzw. der Markt-
platzbetreiber sowohl Hard- und Software, als auch die Infrastruktur
liefern, verringert sich in der Regel die Zeit, bis die Applikation ein-
satzfähig ist („Time-to-Market“).
108
SOA-Perspektiven: Geschäftsmodelle und Innovationen für das Internet der Dienste
imag
eso
urce
Nutzen für Service Provider
Auch für Serviceanbieter ergeben sich zahlreiche Anreize, Anwendungen
auf der Serviceplattform bereitzustellen.
a Flexibilität: Aufgrund der Multimandatenfähigkeit von SaaS-Anwen-
dungen können Anbieter mehrere Tausend Servicekonsumenten mit
derselben Instanz der Applikation bedienen. Durch Rekonfiguration
einzelner Services (vgl. SOA-Paradigma) können Anwendungen
schnell skaliert, geändert, versioniert und aktualisiert werden. Über-
greifend über mehrere Serviceanbieter unterstützt die Plattform so
Agilität und Innovation. Damit zusammenhängend kann die n-te
Anwendung in Kombination mit n-1 vorhandenen Services sehr güns-
tig angeboten werden und liefert die nötige Flexibilität, um Customi-
zing-Wünsche der Servicekonsumenten befriedigen zu können. Wäh-
rend SaaS 1.0 bezüglich Kundenbezogenheit noch recht unflexibel
war, können mit so genannten kompositen Applikationen (Composite
Apps) durch Kooperation von Anbietern komplementärer Dienste
innerhalb der Serviceplattform spezifische Kundenwünsche befriedigt
werden. Dabei kann es sich beispielsweise um die Abbildung komple-
xer Geschäftsprozesse handeln. So können sich Dienstanbieter auf
spezielle Funktionalitäten spezialisieren, bleiben dadurch schlank und
agil, und kooperieren mit Partnern bei der Erstellung komplexer
Dienste.
a Komplexitätsreduktion: Die auf der Plattform angebotenen Infrastruk-
turservices reduzieren den Aufwand für Dienstanbieter. Die eigene
Infrastruktur kann somit minimal gehalten werden, die Plattform über-
nimmt Aufgaben, die für Serviceanbieter bisher als „notwendiges
Übel“ Overhead produziert haben. Beispielsweise können unter ande-
rem Abrechnungsfunktionen, Monitoring, rechtliche Unterstützung,
(dynamische) Preisfindung etc. zentral angeboten werden.
109
www.hessen-it.de
a Wiederverwendbarkeit: Durch die hohe Marktabdeckung einer Ser-
viceplattform können profitabel Nischendienstleistungen angeboten
werden. So kann ein Anbieter günstig, beispielsweise durch Wieder-
verwendung vorhandener Komponenten und das Angebot von nut-
zungsbasierter Abrechnung auch Nachfrage befriedigen, die fernab
der Massenbedürfnisse liegen. Man spricht hierbei vom so genannten
„Long Tail“.
a Kostenreduktion und Skaleneffekte: Die potentiell große Menge an
Servicekonsumenten begünstigt Skalenerträge. Aufgrund des Multi-
mandantenprinzips lassen sich viele Kunden mit nur einer Instanz der
Anwendung bedienen. Wie oben erwähnt, lassen sich durch flexible
Rekonfiguration von Services kostengünstig angepasste komplexe
Dienste erzeugen. Diese werden massiv von Kunden nachgefragt.
Nach einer Forrester-Studie bemängeln 55 % der Befragten eine feh-
lende Customization bei SaaS-Anwendungen. Kosteneinsparungen
sind auch durch Einsparungen im Marketingbereich möglich, da sich
Marketingmaßnahmen durch die Plattform direkt auf Serviceanbieter
auswirken können.
110
SOA-Perspektiven: Geschäftsmodelle und Innovationen für das Internet der Dienste
© C
har
on
| Dre
amst
ime.
com
8.5 Fazit
Der Wandel zur Dienstleistungsgesellschaft ist aufwendig und vielschich-
tig – Beispiele für die Vielfalt der im Zuge der Dienstorientierung entste-
hen technischen Neuerungen sowie die wirtschaftlichen Risiken, aber
auch Handlungsoptionen wurden hier illustriert.
Ausgehend von der heutigen Situation, das heißt dem Angebot individu-
eller SaaS-Angebote sowie dem Trend hin zu Service Value Networks
sehen wir eine Verlagerung in Richtung eines vernetzten „IT-Ökosystems“.
Diese Zukunftsvision des Internet der Dienste beinhaltet XaaS-Lösungen
mit Fokus auf vernetzten Diensten, Integration, Plattformen, Infrastruktur-
diensten, Brokern etc. In ersten einfachen Ausbaustufen hat das Internet
der Dienste tragfähige Geschäftsmodelle hervorgebracht, die bereits
konkrete Nachfrage bedienen: Der Umsatz von salesforce.com betrug im
Jahre 2008 250 Mio. US Dollar. AppExchange beheimatet mittlerweile
ca. 450 unabhängige Anbieter, die dort ca. 800 komplementäre Anwen-
dungen zu Salesforce bereitstellen. Das Unternehmen hat insgesamt
ca. 47000 registrierte Kunden (Stand 25. Januar 2010).
Unternehmen haben heute die Chance, von solchen Vorreitern oder von
existierenden wegweisenden Forschungsarbeiten zu lernen und die Per-
spektive zu prüfen, eigene Services künftig auf dem tatsächlich globalen
Markt zur Verfügung zu stellen oder Dienste von Dritten in ihre Infrastruk-
tur zu integrieren. Sie können dabei vor allem von offenen Innovations-
prozessen, also der engen Zusammenarbeit mit Lieferanten und Kunden
sowie dem Kreis der Partner profitieren. Innovation findet dabei schon
lange nicht mehr nur über die Technik statt – der zielgerichtetere Einsatz
von Wissen, die intelligenteren Prozesse oder eben das schlagkräftigere
Geschäftsmodell können ebenso differenzierend wirken.
111
www.hessen-it.de
Glossar9
112
Glossar
Business Process Execution Language(BPEL)
BPEL ist eine XML-basierte Beschreibungs-sprache, mit der sich ein fachlicher Prozessspezifizieren lässt. Mit einem BPEL-Editorwird von der Überführung des fachlichenProzesses ein grafisches IT-Prozessmodellerstellt. Dieses Modell enthält die Perspek -tiven der Fach- und der IT-Seite.
Business Process Management (BPM)
BPM ist ein ganzheitlicher Ansatz zumManagement des Lebenszyklusses von Pro-zessen, der zur Prozessoptimierung einge-setzt werden kann. BPM und SOA ergänzensich wechselseitig. Denn einerseits sollteein Prozess, bevor er informationstechnischabgebildet wird, zunächst analysiert undoptimiert werden. Andererseits stellt SOAeine IT-Architektur dar, die eine flexible Pro-zessgestaltung und -verbesserung unter-stützt.
Enterprise Service Bus (ESB)
Der „ESB“ (Gartner 2002) bildet eine Inte -grationsinfrastruktur, die z. B. einem Unter-nehmen einen Service über einen Datenbuszur Verfügung stellt. Ein ESB wird gemein-sam von Service-Gebern und -Nehmerngenutzt, so dass unzählige Punkt-zu-Punkt-Verbindungen vermieden werden.
Governance
SOA-Governance (franz. gouverner, verwal-ten, leiten, erziehen) bezeichnet die soziale,IT- und geschäftsbezogene Steuerung undKontrolle eines SOA-Prozesses. Sie umfasstdiesbezügliche Aktivitäten, Entscheidun-gen, Rollen und Verantwortlichkeiten.
Orchestrierung
Der Prozess oder Zustand einer losen Ver-kopplung von Services z. B. mittels BPELwird Orchestrierung genannt. Durch dieVerkopplung wird ein neuer übergeord -neter Service mit erweiterten Funktionenoder eine neue Anwendung erzeugt.
Registry
Ein Verzeichnis oder Katalog verfügbarer Services mit nur wenigen Metadaten wieetwa einer Schnittstellenbeschreibung wirdRegistry genannt. Einem Branchen-Telefon-buch ähnlich gehen daraus im Wesent -lichen nur die Adresse und wenige Zusatz-informationen hervor.
Repository
Das Repository dient – stärker als das Registry – als Instrument der SOA-Gover-nance zur Steuerung und Kontrolle von Services. Es speichert und kategorisiert dieServices mit ihren zugehörigen Aspekten.Werden Registry und Repository zu einerintegrierten Einheit zusammengefasst, werden sie als „Repistry“ bezeichnet.
Service
Ein Service (Dienst) ist die zentrale Grund-komponente einer SOA. Er stellt eine eigen-ständige und unabhängige funktionale Einheit dar. Wird ein Service mit einer stan-dardisierten Schnittstelle über Web Servicesmit anderen Services verknüpft, entstehteine serviceorientierte Architektur.
Web Service
Unter Web Service kann man lose gekop-pelte, wieder verwendbare Softwarekompo-nenten verstehen, die unter Verwendungvon Internetstandards aufgerufen werdenkönnen und über den Austausch von XML-basierten Nachrichten miteinander kommu-nizieren. Web Services sind der zentraleStandard zur Realisierung von Service-Schnittstellen und zur Kopplung von Services.
113
www.hessen-it.de
114
Ihre Partner in Hessen
Fehlt Ihr Eintrag? Dann senden Sie uns
Ihre Angaben an info@hessen-it.de
Ihre Partner in Hessen
Hier finden Sie eine Auswahl an hessischen Unternehmen, Wissenschafts- und
Forschungseinrichtungen sowie anderen Akteuren mit Kompetenzen im Bereich von
serviceorientierten Architekturen. Die Listung erhebt keinen Anspruch auf Vollständig-
keit. Weitere Informationen über mögliche SOA-Partner mit Sitz in Hessen erhalten Sie
im Internet unter www.kompetenzatlas-hessen.de.
10
Accelsis Technologies GmbH
Mergenthalerallee 7765760 Eschborn
Frank JoecksTelefon 06196 470520Telefax 06196 470549 frank.joecks@accelsis.biz
www.accelsis.biz
Accenture GmbH
Campus Kronberg 1 61476 Kronberg im Taunus
Telefon 06173 94-99Telefax 06173 94-98accenture.direct.ela@accenture.com
www.accenture.com
Accurat Informatik GmbHIm Gefierth 13c63303 Dreieich
Telefon 06103 3807-0Telefax 06103 3807-124info@accurat.de
www.accurat.de
ALTRAN Deutschland Holding GmbH Schillerstraße 20 60313 Frankfurt am Main
Telefon 069 219767-70 Telefax 069 219767-76 info@altran.de
www.altran.de
arlanis Software AGMannheimer Straße 9760327 Frankfurt am Main
Andreas HolubekTelefon 069 241829-0Telefax 069 241829-29info@arlanis.com
www.arlanis.com
ATE Software GmbH Bockenheimer Anlage 460322 Frankfurt Main
Thomas ErbrichTelefon 069 9150119-0 Telefax 069 9150119-1info@ate-software.net
www.ate-software.net
Avanade Deutschland GmbHCampus Kronberg 761476 Kronberg
Telefon 06173 94 63800Telefax 06173 94 63999germany@avanade.com
www.avanade.de
Axway GmbHMainzer Landstraße 61 60329 Frankfurt am Main
Telefon 069 244 508-0Telefax 069 244 508-21contactgermany@axway.com
www.axway.de
BLAUERLOTOS GmbH & Co. KGAm Felsenkeller 8a63505 Langenselbold
Telefon 06184 937221Telefax 06184 937481wasewitz@blauerlotos.com
www.blauerlotos.com
CA Deutschland GmbHMarienburgstraße 3564297 Darmstadt
Telefon 06151 949-0Telefax 06151 949-600info@ca.com
www.ca.com/de
CASED – Center for Advanced SecurityResearch Darmstadt
DirektorMornewegstraße 3264293 Darmstadt
Prof. Dr. Johannes BuchmannTelefon 06151 16-50777Telefax 06151 16-6036buchmann@cdc.informatik.tu-darmstadt.de
www.cased.de
Software-Cluster KoordinierungsstelleMornewegstraße 3264293 Darmstadt
Gino BrunettiTelefon 06151 16-70821Telefax 06151 16-55136gino.brunetti@cased.de
www.cased.de
CAST e.V. – Competence Center forApplied Security Technology
GeschäftsführungFraunhoferstraße 564283 Darmstadt
Claudia PredigerTelefon 06151 155-529Telefax 06151 155-499claudia.prediger@cast-forum.de
www.cast-forum.de
GeschäftsführungFraunhoferstraße 564283 Darmstadt
Prof. Dr. Andreas HeinemannTelefon 0621 4105-1170Telefax 06151 155-499andreas.heinemann@cast-forum.de
www.cast-forum.de
Corisecio GmbHUhlandstraße 964297 Darmstadt
Telefon 06151 95130-11Telefax 06151 95130-66info@corisecio.com
www.corisecio.com
CSC in DeutschlandAbraham-Lincoln-Park 165189 Wiesbaden
Telefon 0611 142-0Kundeninfo 0611 142-22222 Telefax 0611 142-22000deutschland@csc.com
www.csc.com/de
Daenet GmbHHanauer Landstraße 20460314 Frankfurt am Main
Telefon 069 242408-0Telefax 069 242408-25info@daenet.de
www.daenet.de
115
www.hessen-it.de
DB Systel GmbHKleyerstraße 2760326 Frankfurt am Main
Gunnar RühlTelefon 069 265-17800Telefax 069 265-18420gunnar.ruehl@deutschebahn.com
www.dbsystel.de
Detecon International GmbHFrankfurter Straße 2765760 Eschborn
Dieter WendelTelefon 06196 903-255Telefax 06196 903-496dieter.wendel@detecon.com
www.detecon.com
Devoteam Danet GmbHGutenbergstraße 1064331 Weiterstadt
Telefon 06151 868-0info@devoteam.de
www.devoteam.de
EDAG GmbH & Co. KGaAReesbergstraße 136039 FuldaIT Services
Raoul FlügelTelefon 0661 6000-596Telefax 0661 6000-113204raoul.fluegel@edag.de
www.edag.com
Epicor Software Deutschland GmbHHanauer Landstraße 291a60314 Frankfurt am Main
Telefon 069 800 766-00Telefax 069 800 766-05info.germany@epicor.com
www.epicor.de
European Business School Institute of Research on Information Systems IRISRheingaustraße 165375 Oestrich-Winkel
Dr. Christine LegnerTelefon 06723 991-251Telefax 06723 991-255christine.legner@ebs.edu
www.ebs.edu/iris
Fachhochschule Gießen-FriedbergWiesenstraße 1435390 Gießen
Prof. Dr. Thomas LetschertTelefon 0641 309-2388Telefax 0641 309-2908thomas.letschert@mni.fh-giessen.de
www.mni.fh-giessen.de
FORTENO GmbHTaunusstraße 66 65183 Wiesbaden
Telefon 0611 58069-10 Telefax 0611 58069-77 info@forteno.com
www.forteno.com
Frankfurt School ofFinance & Management
WirtschaftsinformatikManagement Research Centre Sonnemannstraße 9-1160314 Frankfurt am Main
Prof. Dr. Matthias Goeken (JP)Telefon 069 154008-746 Telefax 069 154008-4746m.goeken@frankfurt-school.de
www.frankfurt-school.de
Prof. Dr. Peter RossbachTelefon 069 154008-739 Telefax 069 154008-4739 p.rossbach@frankfurt-school.de
www.frankfurt-school.de
116
Ihre Partner in Hessen
Fraunhofer-Institut für Sichere Informationstechnologie (SIT)
InstitutsleitungRheinstraße 7564293 Darmstadt
Prof. Dr. Claudia EckertTelefon 06151 869-285Telefax 06151 869-127claudia.eckert@sit.fraunhofer.de
www.sit.fraunhofer.de
Gartner Deutschland GmbHLyoner Straße 2060528 Frankfurt
Telefon 069 669084-0Telefax 069 6662809gartner.deutschland@gartner.com
www.gartner.com
HA Hessen-Agentur GmbHsiehe Hessen-IT
Hessen-ITAktionslinie für den hessischen IKT-Markt des Hessischen Ministeriumsfür Wirtschaft, Verkehr und Landes-entwicklung (HMWVL) c/o HA Hessen Agentur GmbH Abraham-Lincoln-Straße 38–42 65189 Wiesbaden
Wolf-Martin AhrendTelefon 0611 774-8299Telefax 0611 774-8620wolf-martin.ahrend@hessen-agentur.de
www.hessen-it.de
Dr. Matthias DonathTelefon 0611 774-8963Telefax 0611 774-8620matthias.donath@hessen-agentur.de
www.hessen-it.de
Hochschule FuldaAngewandte Mathematik, Kryptographie, IT-SicherheitMarquardstraße 3536039 Fulda
Prof. Dr. Ulrich BühlerTelefon 0661 9640-325Telefax 0661 9640-349u.buehler@informatik.hs-fulda.de
www.informatik.hs-fulda.de
Hochschule RheinMainDesign Informatik MedienLabor für Verteilte SystemeKurt-Schumacher-Ring 1865197 Wiesbaden
Prof. Dr. Reinhold KrögerTelefon 0611 9495-1207, -1202Telefax 0611 9495-1210reinhold.kroeger@hs-rm.de
wwwvs.cs.hs-rm.de
Hochschule DarmstadtInformatikSchöfferstraße 8b64295 Darmstadt
Prof. Dr. Bernhard HummTelefon 06151 16-8494Telefax 06151 16-8935b.humm@fbi.h-da.de
www.fbi.h-da.de
Informatik, Institut für Angewandte Informatik Darmstadt (aiDa)Schöfferstraße 8b64295 Darmstadt
Prof. Dr. Hans-Peter WiedlingTelefon 06151 16-8441Telefax 06151 16-8935h.wiedling@fbi.h-da.de
www.aida.h-da.de
HTTC – Hessisches Telemedia Techno logie Komptenz-Center e.V.
siehe SOA Competence Center im HTTC e.V.
117
www.hessen-it.de
IDC Central Europe GmbHHanauer Landstraße 135-13760314 Frankfurt
Telefon 069-90502-0Telefax 069-90502-100info_ce@idc.com
www.idc.com
infodienst GmbHSchützenrain 961231 Bad Nauheim
Telefon 06034 92314Telefax 06034 92301bbuss@4soa.de
www.4soa.de
Informatica GmbHLyoner Straße 1560528 Frankfurt
Telefon 069 928809-0Telefax 069928809-500info-de@informatica.com
www.informatica.com/de
Information Builders (Deutschland) GmbHMergenthalerallee 3565760 EschbornAnja Griebel
Telefon 06196 77576-0Telefax 06196 77576-99anja_griebel@ibi.com
www.informationbuilders.de
intelligent views gmbHJulius-Reiber-Straße 1764293 Darmstadt
Claudia BaumerTelefon 06151 5006-423Telefax 06151 5006-138c.baumer@i-views.de
www.i-views.de
Intersystems GmbHHilpertstraße 20a64295 Darmstadt
Thomas MironiukTelefon 06151 1747-0Telefax 06151 1747-11thomas.mironiuk@intersystems.com
www.intersystems.de
Intraprend Gesellschaft für IntranetAnwendungsentwicklung mbH
Borsigstraße 1865205 Wiesbaden
Telefon 06122 533959Telefax 06122 533963info@intraprend.de
www.cierp3.de
iPIsec Ltd.Auguste-Viktoria-Straße 361231 Bad Nauheim
Wolfgang GeiselTelefon 06032 93897-12Telefax 06032 93897-15wgeisel@i-pi-sec.de
www.ipisec.com
Johann Wolfgang Goethe-UniversitätInstitut für Wirtschaftsinformatik Grüneburgplatz 1 60323 Frankfurt am Main
Prof. Dr. Wolfgang König Telefon 069 798-34001 Telefax 069 798-33910 wkoenig@wiwi.uni-frankfurt.de
www.wiwi.uni-frankfurt.de
Datenbanken und Informationssysteme (DBIS)Robert-Mayer-Straße 1060054 Frankfurt am Main
Prof. Dr.-Ing. Roberto V. ZicariTelefon 069 798-28212Telefax 069 798-28123zicari@cs.uni-frankfurt.de
www.dbis.informatik.uni-frankfurt.de
118
Ihre Partner in Hessen
Justus-Liebig-Universität GießenInstitut für InformatikArndtstraße 235392 Gießen
Prof. Dr. Martin Kutrib Telefon 0641 99-32140Telefax 0641 99-32149kutrib@informatik.uni-giessen.de
www.informatik.uni-giessen.de
Logica Deutschland GmbH & Co. KG
Rheinstraße 9564295 DarmstadtTelefon 06151 36860-0Telefax 06151 36860-222
Am Limespark 265843 Sulzbach (Taunus)Telefon 06196 7742-0Telefax 06196 7742-555www.logica.com
msgGillardon AGMergenthalerallee 55-59 65760 Eschborn
Dr. Nicolas ReppTelefon 06196 7750-0Telefax 06196 7750-5410nicolas.repp@msg-gillardon.de
www.msg-gillardon.de
Lufthansa Systems AGAm Weiher 2465451 Kelsterbach
Telefon 069 696-90000Telefax 069 696-95959info@LHsystems.com
www.LHsystems.com
OctaVIA AGMarie-Calm-Straße 1-5 34131 Kassel
Telefon 0561 31000-0 Telefax 0561 31000-31 info@octavia.de
www.octavia.de
Opitz Consulting Bad Homburg GmbHKaiser-Friedrich-Promenade 93-9561348 Bad Homburg v. d. H.
Markus GanssTelefon 06172 66260-0Telefax 06172 66260-4500markus.ganss@opitz-consulting.de
www.opitz-consulting.de
PA Consulting Group Deutschland GmbHEschersheimer Landstraße 22360320 Frankfurt am Main
Telefon 069 71702-0Telefax 069 71702-263info@paconsulting.com
www.paconsulting.com
Philipps-Universität MarburgFachbereich Mathematik und InformatikHans-Meerwein-Straße 335032 Marburg
Prof. Dr. Bernd FreislebenTelefon 06421 2821-568Telefax 06421 2821-573freisleb@informatik.uni-marburg.de
www.informatik.uni-marburg.de
Rücker AGKreuzberger Ring 4065205 Wiesbaden
Telefon 0611 73 75-0Telefax 0611 73 75-102info@ruecker.de
www.ruecker.de
Saugatuck Technologies Inc.Bluecherstraße 465343 Eltville
Frank P. SempertTelefon 06123 630285Telefax 06123 630362frank.sempert@saugatech.com
www.saugatech.com
119
www.hessen-it.de
SAP Research CEC DarmstadtBleichstraße 8 64283 Darmstadt
Dr. Knut ManskeTelefon 06227 7-68844Telefax 06227 78-44632knut.manske@sap.com
www.sap.com/research
Software AGUhlandstraße 1264297 Darmstadt
Daniel Adelhardt Telefon 06151 92-1403Telefax 06151 92-11 91daniel.adelhardt@softwareag.com
www.softwareag.com
SOA Competence Center im HTTC e.V. Rundeturmstraße 1064283 Darmstadt
Dr.-Ing. Julian EckertTelefon 06151 16-3742Telefax 06151 16-6152julian.eckert@httc.de
www.httc.de
Stefan SchulteTelefon 06151 16-6187Telefax 06151 16-6152stefan.schulte@httc.de
www.httc.de
Software & Support Verlag GmbHGeleitsstraße 1460599 Frankfurt am Main
Mirko SchremppTelefon 069 630089-38Telefax 069 630089-89mschrempp@sandsmedia.com
www.software-support.biz
SP Integration GmbHOtto-Volger-Straße 5a 65843 Sulzbach/Taunus
Telefon 06196 76430-0Telefax 06196 76430-11info@sp-integration.de
www.sp-integration.de
Sylphen GmbH & Co. KGLiebigstraße 1435390 Gießen
Ralph BoßlerTelefon 0641-94468-0rbossler@sylphen.com
www.sylphen.com
Syngenio AGSchiersteiner Straße 8665187 Wiesbaden
Stefan ScheidTelefon 0611 450415-0Telefax 0611 450415-22stefan.scheid@syngenio.de
www.syngenio.de
T-Systems International GmbHOtto-Röhm Straße 71c64293 Darmstadt
Bernard TsaiTelefon 06151 886-1757Telefax 06151 886-9515bernard.tsai@t-systems.com
www.t-systems.de
Tieto Deutschland GmbHDüsseldorfer Straße 4065760 Eschborn
Telefon 06196 9329-0Telefax 06196 9329-898
http://tieto.de
120
Ihre Partner in Hessen
Technische Universität Darmstadt
Information Systems / WirtschaftsinformatikHochschulstraße 164289 Darmstadt
Prof. Dr. Peter Buxmann Telefon 06151 16-4826Telefax 06151 16-5162buxmann@is.tu-darmstadt.de
www.is.tu-darmstadt.de
Multimedia Communications LabRundeturmstraße 1064283 Darmstadt
Prof. Dr.-Ing. Ralf SteinmetzTelefon 06151 16-6151Telefax 06151 16-6152ralf.steinmetz@kom.tu-darmstadt.de
www.kom.tu-darmstadt.de
Unisys Deutschland GmbHAm Unisys-Park 165843 Sulzbach
Telefon 06196 99-0Telefax 06196 99-1570infodeutschland@de.unisys.com
www.unisys.de
Universität KasselKommunikationstechnikWilhelmshöher Allee 7334121 Kassel
Prof. Dr.-Ing. Klaus DavidTelefon 0561 804-6314Telefax 0561 804-6360david@uni-kassel.de
www.comtec.eecs.uni-kassel.de
Verteilte SystemeWilhelmshöher Allee 7334121 Kassel
Prof. Dr. Kurt GeihsTelefon 0561 804-6275Telefax 0561 804-6277geihs@uni-kassel.de
www.vs.uni-kassel.de
121
www.hessen-it.de
Profile der Unternehmen und Institutionen derAutoren in der Reihenfolge des Erscheinens11
122
Profile der Unternehmen und Institutionen der Autoren in der Reihenfolge des Erscheinens
SOA Competence Center im httc e.V.
Das SOA Competence Center (SCC) ist einGeschäftsbereich des Hessischen Teleme-dia Technologie Kompetenz-Centers e.V. inDarmstadt (httc e.V.). Das SCC berät Unter-nehmen und Organisationen im Rahmenvon Software-Architekturprojekten im Kontext serviceorientierter Architekturen.Die Leistungen des SCC richten sich anUnternehmen, die SOA planen, einführen,optimieren und als Infrastruktur anbieten.
www.httc.de
Dr. Wolfgang Martin Team
Dr. Wolfgang Martin ist ein unabhängigerAnalyst und europäischer Experte auf denGebieten Business Intelligence / CorporatePerformance Management (BI / CPM), Busi-ness Process Management, Enterprise Infor-mation Management (Business Integration),Service Oriented Architecture (SOA) undCustomer Relationship Management (CRM)
www.wolfgang-martin-team.net
Software AG
Software AG ist ein weltweit führendesUnternehmen im Bereich Business ProcessExcellence. Der Unternehmensumsatzbeläuft sich auf mehr als 1 Milliarde Euro(2009), mehr als 6000 Mitarbeiter gehörenzum Unternehmen, und es beliefert über10 000 Kunden in 70 Ländern weltweit. DasUnternehmen hat seinen Hauptsitz inDeutschland und ist an der FrankfurterWertpapierbörse notiert.
www.softwareag.com
Opitz Consulting Bad Homburg GmbH
OPITZ CONSULTING ist ein Projektspezialistim Java-, SOA- und Oracle-Markt. Das Unter -nehmen unterstützt bei der Erstellung einerIT-Strategie und berät bei dem Prozessde-sign und der Aufnahme der Anforderungen.Es konzipiert und realisiert kundenspezifi-sche IT-Lösungen, gewährleistet einen hoch-verfügbaren Betrieb und bildet Mitarbeiterin Schulungszentren aus. OPITZ CONSUL-TING wurde 1990 gegründet und beschäf-tigt über 400 Mitarbeiter an Standorten inDeutschland, Polen und der Schweiz.
www.opitz-consulting.com
Detecon International GmbH
Detecon International ist ein weltweit führen -des Unternehmen für integrierte Manage-ment- und Technologieberatung entlang dergesamten Wertschöpfungskette der Kunden.Detecon International entstand 2002 aus derFusion der beiden Beratungshäuser DETE-CON und Diebold und ist ein Tochterunter-nehmen der T-Systems.
www.detecon.com
Intersystems GmbH
InterSystems ist ein mehr als 30 Jahreerfolgreicher Softwarehersteller im Bereichobjektorientierte Datenbanken, Kommuni-kationsserver, Integrationsplattformen undLösungen für das Gesundheitswesen.
www.intersystems.de
Corisecio GmbH
CORISECIO ist ein führender Hersteller vonautomatisierten Security-Produkten fürSOA-Infrastrukturen. Basierend auf dereigenen Open Platform sind Enterprise-Lösungen für SOA Security und SAP sowieMobile Security und Database Encryptionerfolgreich in mehr als 50 Ländern im Ein-satz. CORISECIO hat ihren Hauptsitz inDarmstadt und wird durch Vertriebspartnerweltweit unterstützt.
www.corisecio.com
European Business School
Die European Business School (EBS) istDeutschlands älteste private wissenschaft -liche Hochschule mit hervorragendemnationalen und internationalen Ruf. ImBereich Wirtschaftsinformatik bietet sie praxisnahe Studienangebote (Bachelor-,Master- und Executive-Programme) undForschung zu aktuellen Fragen des strate -gischen IT-Managements an.
www.ebs.edu/iris
FZI Forschungszentrum Informatik
Das FZI Forschungszentrum Informatik Karls-ruhe hilft – als unabhängige Forschungs -einrichtung des Landes Baden-Württem-berg – Unternehmen und öffent lichen Ein-richtungen, gemeinsam Innova tionen zuentwickeln. Informatik als Schlüssel zuneuen Technologien steht im Mittelpunktvon Anwendungsforschung, Entwicklungund Technologietransfer.
www.fzi.de
123
www.hessen-it.de
Die Aktionslinie Hessen-IT
Hessen-IT ist die Aktionslinie des Hessischen Ministeriums für Wirtschaft,
Verkehr und Landesentwicklung für den gesamten Informations- und
Kommunikationstechnologiemarkt in Hessen. Hessen-IT bietet Informatio-
nen und Services zum Online-Markt, zu E- und M-Commerce, zu Software-
und Telekommunikationsanbietern sowie über Telearbeit. Angesprochen
werden auf der einen Seite die fast 10.000 hessischen Unternehmen, die
Produkte oder Dienstleistungen auf dem Informations- und Kommunikati-
onstechnologiemarkt anbieten, auf der anderen Seite die kleinen und
mittleren Anwender-Unternehmen.
Anbieter-Datenbanken erleichtern die Suche nach geeigneten Dienstleis-
tern bei der Durchführung von IT-Projekten. Gleichzeitig fungieren diese
Datenbanken für Anbieter als Informations- und Kommunikationsplatt-
form, auf der sich diese den Anwendern und potenziellen Kunden präsen-
tieren können.
Newsticker, E-Mail- und Print-Newsletter berichten regelmäßig über den
IKT-Markt in Hessen. Zahlreiche Schriftenreihen und Veröffentlichungen
ergänzen das Informationsangebot der Website. Die Broschüren können
bequem online bestellt oder heruntergeladen werden.
Hessen-IT hat verschiedene Netzwerke und Branchentreffs initiiert, in
denen sich teils nichtkommerzielle Initiativen, teils kommerzielle Anbieter
zusammengeschlossen haben. Regionale Multimedia- und E-Commerce-
Zentren sowie IHKs, Handwerkskammern und andere regionale Akteure
arbeiten zusammen an dem Ziel, Hessens starke Stellung im deutschen
und europäischen IKT-Markt weiter zu sichern und auf dem Weg in die
Informationsgesellschaft weiter voran zu bringen.
12
124
Die Aktionslinie Hessen-IT
Einen Überblick über diese Netzwerke und Treffen sowie Terminankündi-
gungen zu Veranstaltungen, an denen Hessen-IT beteiligt ist, finden Sie im
Online-Terminkalender auf der Website. Auch bei internationalen Messen
wie der CeBIT oder bei regionalen Veranstaltungen in ganz Hessen sind
kompetente Ansprechpartner der Aktionslinie präsent. Hinzu kommen
Seminare und Workshops, die Hessen-IT zu verschiedenen Themen aus-
richtet.
Das Projektteam von Hessen-IT steht Ihnen jederzeit gerne als Ansprech-
partner zur Verfügung. Besuchen Sie unsere Website unter
www.hessen-it.de
125
www.hessen-it.de
Schriftenreihe Hessen-IT (vormals Hessen-Media)
Bestellmöglichkeit und Download als PDF-Datei finden
Sie im Internet unter www.hessen-it.de
Wir über uns
2001 Hessen-infoline-Netzwerk (Band 26)
Projektdokumentation (Band 1)
Bildung und Wissenschaft
2002 Telemedizin in Hessen–Beiträge aus dem Universitätsklinikum Gießen (Band 24)
2001 Entwicklung und Einsatz elektronischer Medien als Lehr- und Lernmittel
an hessischen Hochschulen (Band 27)
Kompetenzzentren und Onlinedienste im Schulwesen
– Beispiele für Hessen-Media Projekte (Band 25)
2000 Die virtuelle Universität (Band 15)
E-Government
2002 Auf dem Weg zu E-Government – Hessens Kommunen im Internet (Band 37)
Wirtschaftsförderung und Standortmarketing im Internet (Band 36)
Marktstudien IT-Standort Hessen
2008 Telekommunikationsanbieter in Hessen 2008 (Band 60)
2006 IKT-Markt in Hessen (Band 58)
2004 Softwareanbieter in Hessen 2004 (Band 50)
Telekommunikationsanbieter in Hessen 2004 (Band 49)
2003 Online-Anbieter in Hessen (Band 2)
2002 E-Shops in Hessen (Band 28)
2000 Der Telekommunikationsmarkt in Hessen (Band 21)
126
Schriftenreihe Hessen-IT
Leitfäden für IT-Anwendungen
2010 Notleidende Projekte – Eine Hilfestellung für IT-Projekte in sieben Akten
(Band 64)
Die Gamesbranche – ein ernstzunehmender Wachstumsmarkt
(Band 59, 2. aktualisierte Auflage)
SOA – Mehr als nur flexible Softwarearchitekturen (Band 63)
Satellitennavigation in Hessen – Ideen über All (Band 65)
Ambient Mobility – Intelligent Products and Environments for Mobile
Citizens and Businesses (Band 62)
2009 Ambient Mobility – Intelligente Produkte und Umgebungen
für mobile Bürger und Unternehmen (Band 61)
Rating für IKT-Unternehmen (Band 53, 2. aktualisierte Auflage)
2008 Leitfaden zur Patentierung computer implementierter Erfindungen
(Band 51, 2. aktualisierte Auflage)
2007 Web 2.0 – Neue erfolgreiche Kommunikationsstrategien
für kleine und mittlere Unternehmen (Band 57)
Die Gamesbranche – ein ernstzunehmender Wachstumsmarkt (Band 59)
In modernen Märkten überleben – Kooperationen
mittelständischer Softwareunternehmen in Hessen (Band 44, 2. Auflage)
2006 Internet-Marketing nicht nur für kleine und mittlere Unternehmen (Band 52)
Basel II – Rating für IT-Unternehmen (Band 53)
RFID – Geschäftsprozesse mit Funktechnologie unterstützen (Band 54)
Anti-Spam – Ein Leitfaden über und gegen unverlangte E-Mail-Werbung
(Band 55)
VoIP – Telefonieren über das Internet (Band 56)
Leitfaden Webdesign – Internetpräsenzen besser planen und gestalten
(Band 7, 5. Auflage)
2005 Recht im Internet (Band 33, 2. Auflage)
Gefunden werden im Internet (Band 32, 2. Auflage)
2004 Wettbewerbsvorteile durch barrierefreie Internetauftritte (Band 48)
Domainregistrierung international (Band 47)
Wireless-LAN: Stand und Entwicklungspotenzial, Nutzungsansätze für KMU
(Band 46)
127
www.hessen-it.de
2003 E-Business-Konzepte für den Mittelstand (Band 45)
Leitfaden „In modernen Märkten überleben“ (Band 44)
Projektleitfaden „Software-Ergonomie“ (Band 43)
„Digitale Signatur“, Leitfaden zum Einsatz digitaler Signaturen (Band 42)
Die Bedeutung der E-Logistik für den Mittelstand (Band 41)
Management von Kundenbeziehungen im Internet (Band 40)
Leitfaden „Webdesign – Internetpräsenzen besser planen und gestalten“ (Band 7)
2002 IT-Sicherheit für den Mittelstand (Band 38)
E-Paymentsysteme – Bezahlen im Internet (Band 35)
ASP: Mehr als nur Mietsoftware (Band 34)
Recht im Internet (Band 33)
Gefunden werden im Internet (Band 32)
E-Learning für KMU – Neue Medien in der betrieblichen
Aus- und Weiterbildung (Band 31)
Telehaus Wetter – ein TeleServiceZentrum (Band 30)
2001 Kasseler Praxis-Dialog Tele@rbeit – Analysen · Erfahrungen · Positionen
(Band 29)
2000 Leitfaden „Webdesign international“ (Band 22)
E-Shop-Software (Band 20)
Hessische Handwerker entdecken das Internet (Band 19)
Leitfaden zur Anwendung eines Ratingsystems für IT-Unternehmen in Hessen
(Band 18)
Software-Dialog Hessen (3) (Band 17)
Leitfaden „E-Shop“ (Band 16)
128
Schriftenreihe Hessen-IT
ISBN 978-3-939358-63-3