Broschüre SOA – Mehr als nur flexible - Hessen-IT

Transcription

Hessisches Ministerium für Wirtschaft,
Verkehr und Landesentwicklung
www.hessen-it.de
SOA
Mehr als nur flexible Softwarearchitekturen
Band 63
Hessen
IT
SOA
Mehr als nur flexible
Softwarearchitekturen
Hessen-IT Band 63
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,
HA Hessen Agentur GmbH
Hessen-IT
Abraham-Lincoln-Straße 38–42
65189 Wiesbaden
Telefon
Telefax
E-Mail
Internet
0611 774-8481
0611 774-8620
[email protected]
www.hessen-it.de
Redaktionsteam:
Dr. Matthias Donath
Christian Flory
Wolf-Martin Ahrend
Gabriele Gottschalk
Alle Rechte vorbehalten.
Nachdruck, auch auszugsweise, verboten.
© Hessisches Ministerium für Wirtschaft,
Hessen-IT
c/o HA Hessen Agentur GmbH
Wiesbaden 2010
Layout/Satz: WerbeAtelier Theißen, Lohfelden
Titelcollage: WerbeAtelier Theißen unter Verwendung
einer Abbildung von AndyL/istockphoto
Druck: Druckerei ausDRUCK, Kassel
ISBN 978-3-939358-63-3
Bibliografische Informationen der Deutschen
Bibliothek: Die Deutsche Bibliothek verzeichnet
diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten
sind im Internet über http://dnb.ddb.de abrufbar.
Liebe Leserinnen und Leser,
Innovationen sind der Motor für unser Wachstum 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 hochgradig 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 (Services), 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 Softwaresysteme nicht nur übersichtlicher gestalten und Unternehmensstrategien agiler
umsetzen – auch neue, innovative Geschäftsmodelle und Geschäftsfelder werden realisierbar. Deswegen sind serviceorientierte Architekturen und Anwendungen zu Leitansä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-Studie 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 hinweisen. 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
SOA
Einleitung ............................................................................................. 1
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
2
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
3
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
4
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
5
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
6
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
7
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
8
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
9
Glossar ............................................................................................. 112
10
Ihre Partner in Hessen ................................................................... 114
11
Profile der Unternehmen und Institutionen der Autoren ........ 122
12
Aktionslinie Hessen-IT ................................................................... 124
Schriftenreihe Hessen-IT ............................................................... 126
2010
Schriftenreihe Hessen-IT:
Neuerscheinungen
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
2009
Ambient Mobility – Intelligente Produkte und Umgebungen
2008
SOA – Mehr als nur flexible Softwarearchitekturen
Leitfaden zur Patentierung computerimplementierter
Hessen
für mobile Bürger und Unternehmen
Rating für IKT-Unternehmen (2. aktualisierte Auflage, Januar 2009)
Erfindungen (2. aktualisierte Auflage)
Telekommunikationsanbieter in Hessen 2008
IT
Die komplette Schriftenreihe finden Sie im Anhang
oder im Internet unter www.hessen-it.de
(Bestellmöglichkeit und Download als PDF-Datei)
www.hessen-it.de
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önnten, betrachte man nun, welche sinnvollen Transportdienste (transportation 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 Teilprozesse aufgeteilt und diesen werden entsprechende IT-Dienste (Services)
mit dahinter liegenden Backend-Systemen zugeordnet. Die einzelnen
Services sind über standardisierte Schnittstellen lose miteinander gekoppelt, so dass sie flexibel kombinierbar und wieder verwendbar sind und
agile Geschäfte ermöglichen.
Prozesse
Services
Externer
Service-Anbieter
BackendSysteme
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 innovative IKT-basierte Dienste und Produkte. Unternehmen mit einer serviceorientierten Architektur können nicht nur ihre internen Services flexibel
miteinander kombinieren. Sie können auch externe Services besser anund einbinden und damit die Vorteile von Software-as-a-Service (SaaS)
1
Einleitung
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 „Softwareinnovationen 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 hochflexiblen, internetbasierten Unternehmensnetzen und richten ihre Geschäftsmodelle 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 Softwarekomponenten 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 personen- und situationsbezogene Informationen, also Dienstleistungen,
erbringt. Technisch baut das Internet der Dienste auf Services auf, die –
obwohl sie zum Teil von unterschiedlichen Anbietern stammen – miteinander kombiniert und zu komplexeren Services zusammengefügt werden
können. Im Rahmen des Leitprogramms in der IKT-Förderung des Bundesministeriums 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
www.hessen-it.de
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äischen Kommission – prognostiziert ein Wachstum des europäischen SOAMarktes (EU 27) von 38 % in 2010, 31 % in 2011 und 25 % in 2012.
Jährlicher SOA-Markt (Nominalwert auf Basis 2008)
Jahr
2007
2008
2009
2010
2011
2012
EU 27
2057
3534
4838
6678
8808
11002
Jährliches Marktwachstum
Jahr
2007
2008
2009
2010
2011
2012
–
71,8 %
36,9 %
38,1 %
31,9 %
24,9 %
EU 27
Lizenzen und Wartung
Mio. Euro
IT-Dienstleistungen
12000
10000
8000
6000
4000
2000
0
2007
2008
2009
2010
2011
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
3
Einleitung
In dieser Broschüre werden einzelne wichtige Aspekte des Wachstumsmarktes serviceorientierter Architekturen von regionalen Experten erläutert, 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 Unternehmensnetzwerken 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
www.hessen-it.de
1
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 Systemstruktur 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 Unternehmen oder die Organisationseinheit, welche(s) einen oder mehrere Services bereitstellt. Services können sowohl innerhalb eines Unternehmens
oder auch über Unternehmensgrenzen hinweg angeboten werden.
5
SOA-Check 2010: Status quo – Trends – Perspektiven
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 Anbieter 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 SOAParadigmas 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 SoftwareEngineering ist ein Maß für die Abhängigkeiten der beteiligten Komponenten. Das Prinzip der losen Kopplung meint, dass der Abhängigkeitsgrad der beteiligten Komponenten relativ gering ist.
6
www.hessen-it.de
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öchstmaß an Flexibilität und stellt gleichzeitig sicher, dass die Abhängigkeit von
externen Service-Anbietern auf ein Minimum begrenzt wird. Sie ist weitaus 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
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 Zielsetzung 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 derjenigen 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 Mitarbeitern, 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
www.hessen-it.de
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.
Öffentliche Verwaltung 3 %
Handel
3%
Öffentliche Verwaltung
und Gesundheitswesen
Sonstige
3%
Industrie 16 %
Finanzdienstleister 23%
Automobilbau,
Maschinenbau,
Chemie, Öl, Gas,
Pharma
Banken & Finanzen
Umsatz
36% < 100 Mio. €
28% = 100–1.000 Mio. €
36% > 1.000 Mio. €
Dienstleister (ohne Finanzdienstleister) 52%
Informationstechnologie, Unternehmensberatung,
Logistik, Transport, Medien, Verlagswesen,
Unterhaltung, Energieversorgung, Telekommunikation
Mitarbeiter
19% < 100
23% = 100–1.000
58% > 1.000
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)
9
1.4 Ergebnisse
SOA-Marktentwicklung
Im Folgenden werden das Marktverständnis, die Marktreife und die Marktmotivation 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-Architektur, 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 innerhalb 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 Unternehmen 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
www.hessen-it.de
70
60
50
62%
52%
53%
2008
2009
40
30
20
10
0
2010
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)
11
SOA-Einsatz
In diesem Abschnitt werden Möglichkeiten und Bedingungen für den Einsatz 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 %), Kundenservice (7 %) und Einkauf (7 %) ab.
Der Einsatz von SOA in unternehmensübergreifenden Prozessen ist
besonders im Bereich der Kollaboration beim Ein- und Verkauf ausgeprä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 Kollaboration 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
www.hessen-it.de
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.
ja
nein, aber Einsatz geplant
nein, kein Einsatz geplant
100 %
90 %
80 %
16 %
27 %
6%
31 %
70 %
60 %
50 %
16 %
48 %
37 %
42 %
40 %
63 %
30 %
20 %
31 %
36 %
47 %
10 %
0%
2007
2008
2009
2010
Wird in Ihrem Unternehmen eine SOA eingesetzt?
(© 2010 S.A.R.L. Martin)
13
SOA-Governance
Der Governance, d. h. der Kontrolle und Steuerung, servicebasierter Systeme 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 Ergebnissen 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 Methodologie zur SOA-Governance führen die „eigenen SOA-GovernanceMethoden“ mit 26 % vor ITIL (IT Infrastructure Library) mit 21 % und vor
„allgemeinen modifizierten IT-Governance-Methoden“ mit 12 %. COBIT
(Control Objectives 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 Befragten nicht eingesetzt (nach 20 % in 2009). Ebenfalls erfreulich ist die Aussage, dass bereits 48 % der Befragten den Wiederverwendungsgrad von
Services messen. 35 % der Befragten haben bereits eine Referenzarchitektur im Sinne einer globalen Architekturrichtlinie erstellt.
© remirath
14
www.hessen-it.de
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 Unternehmen 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. Deutlich 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.
© heizfrosch – istockphoto
© yurok aleksandrovich – istockphoto
15
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 %.
5%
5%
8%
30%
Chief Information Officer (CIO)
Geschäftsführung
Verantwortlichkeit ist nicht klar geregelt
Chief Process Officer (CPO)
Chief Technology Officer (CTO)
26%
Fachabteilung
26%
Wer finanziert SOA-Initiativen? Verteilung der Sponsoren (© 2010 S.A.R.L. Martin)
16
www.hessen-it.de
1.5 Fazit
Der SOA Check 2010 unterstreicht deutlich: Das Thema „serviceorientierte Architekturen“ kommt im deutschsprachigen Markt gut an und gut
voran. Die Unternehmen haben in den letzten Jahren erhebliche Fortschritte 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 Unternehmen gaben an, dass sie sich bereits in der Endphase der Umsetzung einer
SOA befinden und 52 % sehen sich mitten auf dem Weg. 48 % beschäftigen 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 Einsatz.
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 Kundenzufriedenheit (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 Infrastruktur dazu.
17
SOA-Governance ist als Thema angekommen und wird nun endlich angegangen. 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ältnismäßig hoch erscheinen, ist der Trend hin zu einer geringeren IT-Bedeutung des Themas SOA über die letzten Jahre erkennbar. Das Einbeziehen
der Fachabteilungen in die SOA-Projekte ist bei weitem nicht ausreichend: 20 % der SOA-Projekte sind reine IT-Projekte. Hier liegt ein großes
Verbesserungspotential, das man im Zuge des Fokus auf SOA-Governance 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 Architekturparadigma geworden, welches in einer Vielzahl von Anwendungen
zum Tragen kommt.
18
www.hessen-it.de
2
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 mittlerweile einen Anteil am deutschen Bruttoinlandsprodukt von rund 6 Prozent und bietet 750 000 Arbeitsplätze. Dazu kommen die Wertschöpfung
und die Arbeitsplätze in den Anwenderbranchen: z.B. in Banken und Versicherungen, 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 Dienstleistungen 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 Paradigmenwandel, wie er nur einmal in zehn Jahren stattfindet: von den Anwendungs-Silos hin zur Kollaboration und Flexibilität von IT-Systemen. Diese
innovativen Technologien sind der Motor für die Weiterentwicklung des
© PerlAlexander – istockphoto
Webs und der Wertetreiber der Webciety.
19
SOA@Work: Mehr Agilität und Effizienz
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 Beziehungsmuster 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 Anforderungen an das Unternehmen sind in den Geschäftsprozessen abgebildet, und die werden nun hinterfragt, neu gestaltet oder optimiert. Technologien sollen diese Anstrengungen unterstützen.
Geschäftsabläufe, ganz gleich, ob innerhalb eines Unternehmens oder
über Betriebsgrenzen hinweg, müssen transparent, messbar und nachvollziehbar werden. Dies ist die Voraussetzung für ein agiles, flexibles Unternehmen. Eine serviceorientierte Architektur bildet eine ideale Grundlage
für die durchgängige Prozessgestaltung und ein umfassendes Prozessmanagement.
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 angepasst werden. Dabei hat sich gezeigt, dass schnelle Änderungen nur
schwer möglich sind, solange die Prozesse in herkömmliche IT-Anwendungen eingebettet sind.
20
www.hessen-it.de
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 serviceorientierten 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 erreichen. 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 Gestaltungsprinzip 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 Unternehmens-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 Umsetzung der Services – abteilungsübergreifend und über Wertschöpfungsketten hinweg. Auch die Geschäftsprozessregeln lassen sich in einer SOAUmgebung 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 Ablaufkette zusammen, die dann in der SOA technisch über den Enterprise
Service Bus abgebildet wird.
21
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 abgestimmt werden. Dazu gehören die Konzeption einer Architektur in Form
von strategischen Zielen und entsprechenden Prozessen, die Modellierung 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 einbezogen 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. Prozessexperten, 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äftsperspektive und der IT-Fachmann aus der IT-Perspektive. Die Geschäftsanalysten können in einer solchen, digitalen Umgebung die Prozesse
grafisch modellieren, und die Tools erzeugen daraus Prozessbeschreibungen in Standard-Prozessmodellierungskonventionen und Notationen.
22
www.hessen-it.de
Mit einer integrierten Entwicklungsplattform in einer serviceorientierten
Umgebung werden die Prozessschritte dann in technische Services (Web
Services) umgewandelt und neue Services zusammengebaut (komponiert). Für die Ausführung dieses Prozesses ist eine so genannte BPMEngine 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 entgegenwirken, 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äftsprozessen konfiguriert sind. Die Dienste werden öffentlich gemacht und
können dynamisch zu anderen Prozessen mit anderer Logik zusammengesetzt werden. Auf diese Weise liefert dieser neue Typus einer serviceorientierten Geschäftsanwendung (Service Oriented Business Application
– SOBA) einen prozessgetriebenen Ansatz für das Zusammenstellen eines
logischen Informationsflusses aus heterogenen Datenquellen und ist
© kentoh - Fotolia.com
damit ein erfolgskritischer Treiber für Geschäftsagilität.
23
2.4 Effizienz durch Governance
Schließlich muss es eine Instanz – die Governance – geben, die die
Komponenten der serviceorientierten Architektur wie Services, Prozesse
und Regeln, sowie organisatorische Aspekte begleitet. Eine effiziente
Governance definiert aufbau- und ablauforganisatorische sowie technische 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 Kategorisierung 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 zuzuordnen. 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 Anforderungen an die Komponenten. Das Governance-Repository umfasst ein Informationsmodell oder eine Taxonomie und zusätzlich Audit-Fähigkeiten für
das Verfolgen von Änderungen an den Services, Identity-ManagementFunktionen und eine rollenbasierte Zugriffskontrolle. Es sollte der gesamte
Lebenszyklus einer Komponente als Workflow mit allen Arbeitsschritten
und den beteiligten Rollen darin abgebildet werden (Lifecycle Management). Um eine Synchronisation von Repository und Registry sicherzustellen, 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 Anwender erhalten ein einziges System für die Verwaltung aller Informationen bezüglich der SOA-Komponenten und der Governance-Metadaten.
24
www.hessen-it.de
2.5 Fazit
Die IT-Landschaft vieler Unternehmen basiert heute häufig noch auf ITSilos. Gefragt und gewünscht sind jedoch effiziente Prozesse, die unternehmensü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 serviceorientierten Architekturen. BPM und SOA sind keine rein technische Aufgabe, die durch neue Produkte oder Dienstleistungen gelöst werden können. Das Management von Geschäftsprozessen und serviceorientierten
Architekturen ist von Natur aus eine soziale Aktivität. Ein erfolgreicher Prozess 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 optimalen 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 Beteiligten. Das Ergebnis führte jedoch kaum zu den gewünschten Erfolgen
einer echten, unternehmensübergreifend arbeitenden sozialen Gemeinschaft, 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 Prozesse verbessert werden können.
25
SOA-Starter Kit: Think big, start small, show quick success
3
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 Unternehmensanwendungen hinweg möglichst in Echtzeit zu synchronisieren 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 sichergestellt.
a Entwicklung individueller Anwendungen
Bei der Entwicklung von individuellen Anwendungen sollte von
Beginn an darauf geachtet werden, die enthaltenen Geschäftsfunktionen der Anwendung im Rahmen von Services bereitzustellen, um
durch die lose Kopplung von Modulen die Wartbarkeit und Wiederverwendbarkeit 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.
26
www.hessen-it.de
a Prozessautomatisierung
Durch die Automatisierung von Geschäftsprozessen unter Einbeziehung von Anwendungen, Systemen und Personen lässt sich die Prozessproduktivität verbessern. Die Transparenz der Unternehmensprozesse wird gesteigert und die Agilität der Prozesse wird erhöht.
a Prozessportale
Durch Prozessportale können manuelle und automatisierte Geschäftsprozesse über Anwendungen hinweg angestoßen, betrieben und verfolgt 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 Indikatoren (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 Anforderung einer Business-to-Business Integration geprüft werden. Ziel dieser 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
Ü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 Anforderungen. 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:
SOA erfordert ein
Organisationskonzept
SOA ist ein
Technologiekonzept
SOA Strategie
SOA Architektur
Serviceentwicklung
SOA Maturity Model
SOA Assessment
Enterprise Architecture,
Integrierte Geschäftsprozess- und IT-Architektur
Standards,
Service Orchestrierung
Systeminfrastruktur
Systeminfrastruktur
SOA Governance
Richtlinien
Laufzeitumgebung,
Systemintegration
SOA Organisation
Rollen und Aufgaben
28
SOA ist ein
Architekturkonzept
SOA Methodik
Service-Identifikation,
-Klassifikation und
-Portfoliomanagement
Systemmanagement
SLA, Sicherheit,
Performance
www.hessen-it.de
a Dimension Organisation
SOA erfordert ein Organisationskonzept, um eine strategische
Ausrichtung, einen formalen Handlungsrahmen und eine organisatorische 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 Managementansatz, der in der Unternehmensarchitektur und der technischen IT-Infrastruktur umgesetzt wird.
Ein übergeordnetes Ziel, das jeder SOA-Ansatz verfolgt, ist die Beherrschung der heterogenen Systemlandschaften im Unternehmen. Die Realität zeigt heute vielfach Anwendungslandschaften mit proprietären
Schnittstellen, vielen verschiedenen Plattformen und unübersichtlichen
Interaktionen zwischen diesen Anwendungen und Systemen.
29
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
www.hessen-it.de
3.3 Komponenten
Eine serviceorientierte Architektur kann im einfachsten Fall aus einzelnen
Services bestehen, die lose gekoppelte Funktionalitäten zur Wiederverwendung bereitstellen. Ein Service ist eine spezielle Softwarekomponente
mit einer wohl-definierten Funktionalität, die von anderen Softwarekomponenten 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.
SCM
Check Credit
Service
Webshop
Client
Security
Servicebus
Serviceregistry
Service
Orchestrierung
Monitoring
Um Punkt-zu-Punkt-Verbindungen zwischen einzelnen Services zu vermeiden, kann ein Enterprise Service Bus (ESB) eingesetzt werden. Der Servicebus 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 Security-Richtlinien und stellt Oberflächen für das Monitoring bereit. Somit
übernimmt er das Management der Integrationsinfrastruktur.
31
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öherwertigen (composite) Services kombiniert werden, um z. B. eine Geschäftsfunktion bereitzustellen. Hierfür werden BPM (Business Process Management),
BPEL (Business Process Execution Language) oder klassische Workflowsysteme genutzt.
Eine Service-Registry ist ein Verzeichnis von Serviceinformationen. Es beinhaltet 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
www.hessen-it.de
3.4 Der erste Service
Grad der SOA-Basierung im Unternehmen
Wenn ein Unternehmen eine SOA einsetzen möchte, muss es eine SOAStrategie 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 Unternehmen 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 Anforderungen liefert.
Erfüllungsgrad
SOA lite
Enterprise SOA
33
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-zuPunkt-Verbindungen zwischen einzelnen Applikationen. Das Thema SOAGovernance beschränkt sich auf die Richtlinien für die Schnittstellendefinitionen 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 Integrationsszenarien mit Hilfe von Middleware-Infrastrukturen und SOA-Suiten von
kommerziellen Herstellern umgesetzt. Die Organisation des Unternehmens 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 klassischer Ansatz ist die Durchführung eines SOA-Pilotprojekts:
34
www.hessen-it.de
SOA Pilotprojekt
Ziel
Ergebnisorientierter und pragmatischer
Ansatz für die Evaluierungs- oder
Startup-Phase Ihres SOA-Vorhabens
Nutzen
SOA in der Praxis an Hand eines klar
abgegrenzten Problemfalls kennenlernen
Praxiserfahrung in relevanten Methoden
und geeigneten Werkzeugen sammeln
Erkenntnisse für das weitere Vorgehen in
Ihrem SOA-Vorhaben erarbeiten
SOA Pilotprojekt
Ausarbeitung einer greifbaren Nutzenargumentation in
Richtung Fachbereiche und Management:
Was bringt SOA exakt für uns?
SOA-Pilot als ein sinnvoller erster Schritt in Richtung
Ihres Gesamtvorhabens
Attraktives Kosten-Nutzen-Verhältnis durch
ergebnisorientierte Umsetzung mit kurzer Laufzeit
Klare Fokussierung auf Vorgehensweise und Methodik,
da technische Rahmenbedingungen vorgegeben sind
SOA Starter Kit
Modul 1: Auswahl eines geeigneten SOA-Piloten
Planung
SOA-Pilot
Modul 2: Zieldefinition und Abgrenzung
Modul 3: Ausrichtung der Strategie für SOA-Gesamtvorhaben
optional
Projekt
Roadmap
Modul 4: Erstellung Projekt-Roadmap
Modul 5: Analyse und Modellierung des neuen Anwendungsfalls
optional
Modul 6: Review eines bestehenden Anwendungsfalls
Durchführung
SOA-Pilot
Lauffähige
Services
Modul 7: Service-Modellierung
Modul 8: Service-Implementierung
Modul 9: Service-Rollout
Auswertung
SOA-Pilot
optional
Modul 10: Sammlung Lessons Learned
Modul 11: Ausarbeitung Nutzenargumentation für SOA-Gesamtvorhaben
SOA-Nutzenargumentation
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ützung 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 Unternehmen, ob es weiterhin eine Strategie auf Basis einer serviceorientierten Architektur verfolgen sollte. Insgesamt gilt für das Vorgehen beim Pilotprojekt:
tart small,
s
,
ig
b
k
in
Th
success
k
ic
u
q
w
o
sh
Einbettung des SOA-Piloten in Ihr SOA-Gesamtvorhaben
Sobald das SOA-Pilotprojekt abgeschlossen ist, existiert eine Entscheidungsgrundlage für das weitere Vorgehen. Wenn positiv entschieden wurde
und eine Roadmap erstellt wurde, um die geplante SOA-Strategie umzusetzen, geht es an die Einbindung von SOA in weitere Projekte des Unternehmens. Ein iterativer, der Roadmap folgender Ansatz hat sich klar bewährt:
36
www.hessen-it.de
Gesamtvorhaben
PilotProjekt
Lessons
Learned
SOAProjekt
Lessons
Learned
SOAProjekt
Lessons
Learned
SOA
Starter
Kit
Im Rahmen der weiteren SOA-Projekte baut man die SOA-Architektur mit
immer weiteren Komponenten aus, überprüft und verfeinert die SOAGovernance 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 korrigierend einzugreifen, wenn neue Anforderungen oder Rahmenbedingungen
die Roadmap zur Erreichung der geplanten serviceorientierten Architektur beeinflussen.
3.5 Fazit
Moderne serviceorientierte Architekturen halten in allen Unternehmensformen und -größen Einzug. Erfolge erzielen diejenigen Projekte, die
schnell einen Mehrwert für die Fachbereiche erzeugen und vom Management entsprechend unterstützt werden.
Wer versucht, eine SOA durch ein einzelnes Projekt oder eine neue Technologie 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 Gesamtstrategie des Unternehmens entscheidend. Nur wenn dessen strategische Ziele
und deren konkrete Machbarkeit durch das Pilotprojekt unterstützt werden, leistet SOA einen wichtigen Beitrag zum Unternehmenserfolg.
37
SOA-Kommunikation: „Wie überzeug’ ich meinen Chef?“
4
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 investieren, sollte zuerst einige Voraussetzungen schaffen. Innerhalb der IT-Abteilung 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 involviert 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 veranschaulichen, 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 überzeugen 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 Serviceorientierung auf den eigenen Betrieb und dessen Architektur hat.
38
www.hessen-it.de
Erwartungen
orientiert
an
Service
Kunde
Lieferant
IT-Architektur
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 anderen Seite stellt sich die Frage, wie die Servicedienstleistung vom Lieferanten mit seiner IT-Fabrik erbracht werden kann. Hierbei ist es für ihn wichtig
zu wissen, wie weit die momentane IT von einer serviceorientierten Architektur 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 umgesetzt 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.
39
Eine SOA setzt eine hohe Transparenz und ein gutes Verständnis der
Applikationsarchitektur voraus. Weiterhin benötigt SOA eine redundanzfreie 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.
Komplexität
Erwartungen
Variantenvielfalt
orientiert
an
Kosten
Zeit
Service
Flexibilität
Qualität
Kunde
Lieferant
IT-Architektur
Kundenorientierung
Standardisierung
Effektivität
Enabler
Effizienz
Nutzenpotentiale einer serviceorientierten Architektur
40
www.hessen-it.de
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 Projektdauer 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-toMarket-Zyklen neue Produkte auf den Markt bringen muss. Für ein erfolgreiches unternehmensinternes SOA-Marketing ist es deshalb entscheidend, diejenigen Unternehmensbereiche zu identifizieren, die von einer
serviceorientierten Architektur am meisten profitieren.
41
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 redundanzfrei definiert und ordnet. Diese logische Strukturierung in Bezug auf
Funktionen und Informationen dient als Speicher für Geschäftsanforderungen 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
www.hessen-it.de
Wie in der Abbildung ersichtlich, dient das logische funktionale Domänenmodell als Verbindungsglied zwischen Prozessen und Anwendungsservices. 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 Geschäfts ausgerichtet werden.
Eine ähnliche Systematik bietet sich, wie die Abbildung zeigt, auch zur
Gestaltung der technischen Infrastruktur an, die einen Fachservice unterstützt. Auch hier lässt sich an der Schnittstelle von Applikationen zur technischen 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 unterschiedliche 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 festgelegten Mustern eine maximale Standardisierung bis in die Implementierungswelt 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- / Wirkungsbeziehungen deutlich, die dann ein konsequentes Ausrichten auf die Anforderungen des Geschäfts ermöglichen.
43
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 % reduziert wird, wenn man SOA auf einen IT-Service anwendet.
Business
Capability
Business
Capability
3 other
700.000 €
100.000 €
300.000 €
300.000 €
400.000 €
400.000 €
2 other
100.000 €
400.000 €
ABB costs 500.000 €
200.000 €
100.000 €
2 other
200.000 €
Infrastructure
Capability
Infrastructure
Capability
200.000 €
300.000 €
SOA-basiertes Kosten- und Preismodell
44
300.000 €
www.hessen-it.de
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 Prozessebene sowie auf der Applikations- und Technologieebene. Die durch
ein derartiges Kostenmodell geschaffene Transparenz erlaubt eine Ergebnissicht auf einzelne abgegrenzte Teilbereiche. Optimale, klar abgegrenzte, sehr fokussierte und zielgerichtete SOA-Projekte können so identifiziert und mit begrenztem Aufwand und Risiko umgesetzt werden. Man
muss damit nicht einen generellen SOA-Ansatz für die gesamte Unternehmung 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ßnahmen 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-Anforderungen 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 Wertbeitrag liefert, wird Aufmerksamkeit auf der Geschäftsseite erzeugt und
die Bereitschaft geschaffen, in derartig werthaltige, abgegrenzte Maßnahmen 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
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 Projektes, 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 SOAbasierten 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 Kerntreibern 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
www.hessen-it.de
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 überzeugend 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-getriebenen IT ergriffen werden könnten. Beim Vergleich der Zeiten- und Ressourcenaufwände von beiden IT-Varianten geht es nicht nur um die entstandenen Aufwände, sondern auch um den entgangenen Nutzen auf der
Geschäftsseite durch eine zeitlich verzögerte Unterstützung und Realisierung 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
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 existierenden 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 Umsetzung 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 Bebauungsplan 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 ermitteln. Andererseits wird auch deutlich, welche Anwendungen ersetzt werden 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 temporäre Parallelbetrieb während einer Übergangszeit mit kalkuliert werden.
2010
2011
2012
2013
2014
100
500
600
50
500
600
20
400
500
0
0
0
0
0
0
0
0
0
1.500
200
150
1.000
300
300
80
300
400
80
300
400
1.200
0
3.000
–1.800
2.520
–1.320
780
420
780
420
Umsatzplus
Prozesseffizienz
0
0
0
0
1.000
500
1.500
1.000
2.000
1.200
Gesamt
0
–1.800
180
2.920
3.620
CAPEX (Ist)
OPEX Maintenance (Ist)
OPEX Operations (Ist)
CAPEX (SOA)
OPEX Maintenance (SOA)
OPEX Operations (SOA)
Gesamtkosten / Jahr
Einsparungen IT Kosten zu Ist
Kosten- und Ertragsentwicklung eines fiktiven SOA-Projektes in T €
CAPEX = Capital expenditure, Investitionen
OPEX = Operational expenditures, Betriebskosten
48
www.hessen-it.de
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 werden die Einsparungen berechnet, die in den Jahren 2011 und 2012 negativ
sind, da dort Investitionen für die Einführung der SOA vorgenommen werden, die die momentanen Betriebskosten übersteigen (siehe „Einsparungen 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 Services 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 Timeto-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 Verzinsung zu berücksichtigen – 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
Geschäftsorientierter Nutzen von SOA
Einsparungen in €
4000
Prozessefﬁzienz
Umsatzplus
IT-Einsparungen
3000
2000
1000
0
–1000
2010
2011
2012
2013
2014
–2000
–3000
Zeit
Kumulierte Entwicklung eines fiktiven SOA-Projektes
18000
16000
IT SOA kumuliert, verzinst
IT Bezugslinie kumuliert,
verzinst
14000
12000
10000
8000
6000
4000
2000
20
20
18
20
16
20
14
20
20
20
12
0
10
Kumulierte, verzinste Kosten in €
SOA-Amortisierung: IT-Bereich (ohne Geschäftsbereich)
Zeit
Amortisierung eines fiktiven SOA-Projektes in reiner IT-Perspektive
50
www.hessen-it.de
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 Perspektive 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 abgeleitet werden, die in eine serviceorientierte Architektur überführt werden
müssten. So erfolgt eine strategisch determinierte Auswahl eines Bereiches, der von einer SOA am meisten profitiert. Diese strategisch getriebene Auswahl und Abgrenzung eines Geschäftsbereiches hilft, den Nutzen von SOA geschäftsorientiert darzustellen. Eventuell kann diese monetäre Kalkulation durch weitere qualitative Kennzahlen, die an den involvierten 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 unterstü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
Prozessmodell
Sub-processes
Domänenmodell
Analyse & Design
Construction
Domäne x
Fähigkeiten
Bebauungsplan
Fähigkeiten
ITP
App.1
App.4
App.5
App.7
App. 11
App.14
App.12 App.13
App.15
App.17
App.10
App.16
App.x
Target architecture (Master plan)
As-is Applikationen
App.8
ITF
App.2
ITx
App.3
App.6
App.9
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önnen dann Aussagen getroffen werden, die wie in der folgenden Abbildung visualisiert werden können. Diese eher plakativen Darstellungen
sind einprägsam und reduzieren die Botschaft auf wesentliche, geschäftswirksame Aussagen.
52
www.hessen-it.de
Verringerung der
Variantenvielfalt
Kostensenkung
# Applikationen
280
–68%
–15%
Prozessmodell
Sub-processes
Domänenmodell
Analyse & Design
Construction
Domäne x
Fähigkeiten
Bebauungsplan
Fähigkeiten
100
Ist
ITP
App.1
App.4
App.5
App. 11
App.14
App.12 App.13
App.15
App.17
App.16
App.x
App.7
App.8
ITF
App.2
ITx
App.3
Soll
App.6
App.9
App.10
Target architecture (Master plan)
As-is Applikationen
# Betriebsmodelle
10
Soll
Ist
Soll
Ist
–25%
Core
Host
FrontEndServer
Encaps. 3270/DTA
2
Soll
Clearing-DTA, etc.
FTP/DTA
FTP
Layer
Ist
BackEndServer
HTTPS, etc.
Layer
–83%
Layer
Zentraler Mainframe mit Windows Front-/Back-Ends
Thin
Client
Thin Client
Rumba
Server
ORACLE
WIN 2003
x86
RUV Permanent Proc.
RUV Task
Shared DB2
z/OS parallel Sys plex
IBM zSeries
Server
ORACLE
WIN 2003
x86
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 Vorbereitung 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 Unternehmensarchitektur erarbeitet werden, die für die Identifizierung und
Abgrenzung der für die serviceorientierte Architektur optimalen Geschäftsbereiche 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 Transformation in eine serviceorientierte Architektur ohne Risiko und im geplanten
Zeit- und Kostenrahmen bewerkstelligt werden kann, sollte das SOA-Vorhaben in einer Art und Weise präsentiert werden, die den Chef mit seiner
Sprache abholt und ihm anschaulich und plakativ die wesentlichen Botschaften vermittelt. Nach erfolgtem Entscheid für das SOA-Projekt kann
dann die SOA-Implementierung begonnen werden, um den versprochenen Nutzen wie geplant reibungslos und nachweisbar zu realisieren.
53
SOA-Governance: Warum Investitionen in Menschen wichtiger sind als in Monitoring-Tools
5
SOA-Governance:
Warum Investitionen in Menschen wichtiger
sind als in Monitoring-Tools
Thomas Mironiuk, Intersystems GmbH
Zu Recht wird serviceorientierte Architektur (SOA) heute in einem Atemzug 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 Gartner kreiert wurde, an akuten Kommunikationsproblemen. Geradezu sträflich wurde versäumt, den an den zu optimierenden Prozessen beteiligten
oder von ihnen betroffenen Menschen eine verbindliche und allgemeinverständliche Definition von SOA an die Hand zu geben. Bis heute können
sich Industrie und Wissenschaft nicht einmal auf eine gemeinsame Definition von SOA für die IT einigen. „SOA ist ein Paradigma für die Strukturierung 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
© pressmaster - Fotolia.com
wir SOA.“
54
www.hessen-it.de
5.1 Definition „SOA-Governance”
Die Herausforderung, diesen Missstand auf Unternehmenseben zu beheben, 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 SOAGovernance als: „Definition, Durchsetzung und Steuerung von organisatorischen Regeln, Richtlinien und Standards zur konsequenten Ausrichtung 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, Steuerung 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 Anweisungen 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
Zu einer der ersten Aufgaben der SOA-Governance gehört daher die
Entwicklung eines Governance-Plans, einer Seekarte durch die SOAUntiefen. 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 SOAGovernance auch in Einklang mit den anderen Steuerungsmodulen im
Unternehmen gebracht werden, von Corporate-Governance über BPMGovernance bis zur Data-Governance. Hier sind gegebenenfalls erste
Anpassungen im Nicht-IT-Umfeld notwendig, sollten sich Teile der Regelungen als untauglich oder hinderlich für die erfolgreiche Implementierung 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
www.hessen-it.de
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 Verantwortlichkeiten 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 durcheinander. 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 Verschiebungen 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 betroffenen Mitarbeiter eine Politik allein „zum Wohle des Unternehmens“
durchsetzen zu können, stößt daher schnell an seine Grenzen. Schleppende 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 wesentliche 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
Kommunikation und Vermittlung des Governance-Plans sollten sich daher
nicht auf die rein fachlichen Informationen und Maßnahmen für die IT-Mitarbeiter respektive die Prozessinhaber der Fachabteilungen beschränken.
Zugleich sind ein der Kultur des Unternehmens entsprechendes Anreizoder 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-unterstütztes BPM wird immer wieder nicht nur Abläufe, sondern auch strukturelle Zuständigkeiten verändern. Eine Belegschaft, die darauf vertrauen
kann, dass ihre Interessen bei solchen Planungen berücksichtigt werden,
© Andres Rodriguez - Fotolia.com
steht zukünftigen Änderungen deutlich aufgeschlossener gegenüber.
58
www.hessen-it.de
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 einstellen, Prozesse anhand von Erfahrungen optimiert oder zu Best-Practices
erklärt werden. Insbesondere Fragen der Wiederverwendung von Services (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 informieren.
Umfragen zeigen, dass diejenigen Unternehmen erfolgreicher abschneiden, 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 grundlegenden Aufgaben der SOA-Governance gehört, sich Gedanken zu Lebenszyklen von Services zu machen, Composite Applications zu schaffen oder
Regeln und Strukturen für den Umgang mit von außen eingekauften Services 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
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 Berufsstandes unter sich sind. Im Idealfall reden IT-Spezialisten mit ihren Kollegen 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 ResponseZeiten 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 Menschen an die Geheimsprache der mittelalterlichen Handwerksbünde.
Holen Sie sich soziale Kompetenz ins SOA-Team und betreiben Sie
intern SOA-PR und -Marketing!
60
www.hessen-it.de
Wenn man also verhindern will, dass SOA scheitert, obwohl man technisch 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 bewerten 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 überwinden 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 Component 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 Qualifikationen allein nicht aus. Investitionen in die Softskills des GovernanceTeams sind für den Erfolg der SOA im Unternehmen entschieden wichtiger 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
SOA-Security: Webservices erfordern zusätzliche Sicherheitsmaßnahmen
6
SOA-Security:
Webservices erfordern zusätzliche
Sicherheitsmaßnahmen
Dr. Bruno Quint, Corisecio GmbH
6.1 Grundlagen
Serviceorientierte Architekturen (SOA) entwickeln sich von einem HypeThema zu realen Projekten. Die Idee, Funktionalitäten und Aufgaben als
lose gekoppelte, unabhängige, austauschbare Dienste über standardisierte Schnittstellen anzubieten, ermöglicht Unternehmen flexibler auf
sich ändernde Geschäftsprozesse zu reagieren. Um den Vorteil der Flexibilitä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
62
www.hessen-it.de
Grundsätzlich ist SOA ein Managementkonzept. Es schreibt keine konkrete 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 Schnittstelle 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, welches 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 Verteilung von Systemen und Prozessen aber SOA-spezifische Sicherheitsrisiken, die entsprechend zu berücksichtigen sind.
Wie in monolithischen Systemen müssen auch in SOA-Infrastrukturen
Identitäten und Berechtigungen verwaltet, Benutzer authentisiert, Zugriffsberechtigungen ü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, Backdoors, Netzangriffen (Scanning, Spoofing, etc.) sowie Denial of Service
(DoS) und vielen mehr ausgesetzt.
63
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.
UserID /
Password
Application
Service
Service
Service
Service
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).
64
www.hessen-it.de
Die Realisierung eines Geschäftsprozesses über eine Vielzahl lose gekoppelter Services erfordert zudem mehr Authentisierungs- und Autorisierungsvorgänge, eine jederzeit gewährleistete Vertraulichkeit sowie
eine höhere Integrität als in einem monolithischen System. Ein Prozessdesign über Unternehmensgrenzen hinweg und zwischen unternehmensfremden Teilnehmern verstärkt diese Sicherheitsanforderungen an Services und Lösungen und setzt so genannte Federation-Konzepte voraus.
Technisch gesehen muss dabei die Interoperabilität sichergestellt werden. Zu nennen sind an dieser Stelle bspw. die Umwandlung von Identitä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 SecurityStandards kurz dargestellt werden. Eine einleitende Diskussion über den
Einsatz herkömmlicher Methoden im SOA-Umfeld zeigt die Notwendigkeit neuer Sicherheitslösungen auf.
65
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 ausreichenden 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 aufgegeben 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 Nachricht gesichert wird.
Herkömmliche Firewall-Technologie (Transport Layer Firewalls) kann
lediglich eine Netzwerksicherheit gewährleisten und ist somit zwar notwendig, 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 herkö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 ausreichend. 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
www.hessen-it.de
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 weiterhin 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-Implementierung 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, Netzwerktraffic, Lastverteilung und Skalierung aus. Security-Lösungen für SOAInfrastrukturen erfordern flexible Architekturansätze, die die beschriebenen Aspekte abdecken.
67
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 Sicherheit und Sicherheitsinformationen auf Nachrichtenebene implementiert
werden und somit die Schwächen von Sicherheitsmechanismen auf Transportebene, 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 XMLDokumente 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, XMLSignature und XML-Key Management in SOAP integriert werden
können. Dieser Standard bildet somit die Schnittstelle zwischen
vorhandenen Security-Technologien und dem Web ServiceStandardformat SOAP.
68
www.hessen-it.de
a SAML (Security Assertion Markup Language)
SAML ist ein Standard zum Transport von Authentisierungsund Autorisierungsinformationen innerhalb von Web Services.
Er ermöglicht die Einbringung erweiterter Sicherheitsinformationen 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 Austausch 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 SOAUmgebungen 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 sozusagen „SOA-enabled“ werden.
69
Single Sign On (SSO)
Richtig eingesetzt ermöglichen SSO-Methoden gleichsam erhöhte Sicherheit, 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 SOAfä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 Anmeldungen erfolgen über technische User-Konzepte.
SSO nutzt daher ein Benutzer- und Credentialmapping, um Anwendungen 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 synchronisiert 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 Anmeldeinformationen 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
www.hessen-it.de
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 Nachrichtentransformation 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 werden 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 herkömmlichen Einsatz von WAF. Durch die verteilte Systemstruktur in SOAUmgebungen würde es bedeuten, dass jeder Service durch eine WAF gesichert werden müsste. Dies ist bei einer Vielzahl verteilter Services nicht
kosteneffizient, da für jeden Service-Provider eine dedizierte WAF bereitgestellt 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ücksichtigung 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
6.4 Methoden zur Umsetzung
Unternehmen können viele der bisher beschriebenen Ansätze und insbesondere 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, Sicherheitsmechanismen 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 SecurityDesign, die Einführung sowie die Verteilung und den Betrieb von Security-Mechanismen unterstützt. Ein auf offenen Standards basierendes
Framework in Verbindung beispielsweise mit einem Plugin-Adapter-Konzept 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
www.hessen-it.de
Security als Service
Zudem bietet es sich an, Sicherheitsfunktionalität selbst als Service anzubieten. 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 standardisierte Schnittstellen (Web Services, SOAP) können diese von sämtlichen
Systemen genutzt und anforderungsgerecht skaliert werden. Die Implementierung als Service Provider erlaubt systemweit oder innerhalb von
Domänen Sicherheitsmechanismen, wie beispielsweise Anti Virus, Signatur, 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 Laufzeitumgebungen, 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
Security
Service
Service
Security
Service
Service
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 beispielsweise die in der Policy definierte Verschlüsselung eines Elements
(XML-Encryption) außerhalb der Applikation durchgeführt werden.
Service
Consumer
Service
Domain
Security Service
Der zentralisierte Security Service bietet die Sicherheitsüberprüfung
als Service, z. B. das Scannen nach Viren in Attachments.
74
www.hessen-it.de
Domänenweite Services bieten dafür Sicherheitslösungen, wie beispielsweise 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 Aufgabe. Neben neuen notwendigen Sicherheitsmethoden, die die Sicherheit
auf Nachrichtenebene gewährleisten, bestehen auch bei traditionellen
Techniken (wie z. B. Antivirus-Lösungen) neue Anforderungen. Unternehmen 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 standardisierter WS-Security Mechanismen gelöst werden. Für Bedrohungen wie SQLInjections, 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öglichkeiten. Unternehmen können einen Security Service effizient und anforderungsgerecht entweder lokal außerhalb der Applikation oder auch als
domänenweiten Service implementieren. Eine zentrale Orchestrierungsund Management-Plattform mit breiten Integrationsmöglichkeiten liefert
Unternehmen die Möglichkeit, vorhandene Lösungen (etwa Metadirectories, PKI) weiterhin im SOA-Umfeld zu nutzen. In Verbindung mit
leistungsstarken Modellierungswerkzeugen und vorkonfigurierten Workflows ist die Automatisierung von SOA-Security effizient umzusetzen.
75
SOA goes B2B: Lessons Learned aus der Automobilindustrie
SOA goes B2B:
Lessons Learned aus der Automobilindustrie
7
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 Automobilindustrie verdeutlichen, in der verschiedene Fahrzeugmodelle
baugleiche Komponenten teilen. Bei der konzernübergreifenden Kleinwagenplattform 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 zerlegen. 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.
76
©
An
d
j
rze
ot
-F
ol
ia.
co
m
www.hessen-it.de
B2B-Architekturen als Ansatzpunkt für SOA
Einer der erfolgversprechenden Ansatzpunkte für SOA ist an den Unternehmensgrenzen zu finden. Überall dort, wo die Verzahnung mit Geschäftspartnern 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 überbetriebliche Integrationsbedarf bedingt dadurch, dass Hersteller ihre Wertschöpfungstiefe reduzieren und Zulieferer ganze Produktions- und Entwicklungsumfänge übernehmen. Auf der Vertriebsseite wird die überbetriebliche Integration ebenfalls immer wichtiger, um dem weltweiten Händlernetzwerk Produktinformationen verfügbar zu machen oder OnlineServices 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-Potenzialen für die Koordination entlang der Zulieferkette die Rede sein. Die
vorgestellten SOA-Ideen wurden im Rahmen der Initiative „SOA in Automotive“ 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-Kooperation konkretisiert und anschließend durch einen Piloten erprobt.
77
Heterogenität als Problemstellung der B2B
Unternehmen-zu-Unternehmen (B2B)-Integration war und ist in der Automobilindustrie stark mit dem Einsatz von Electronic Data Interchange (EDI)
verbunden. Obwohl alle Großunternehmen eine EDI-Infrastruktur aufgebaut 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 Zulieferer 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 Recycling – 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
© Shawn Hempel - Fotolia.com
Qualitätskennzahlen abrufen oder Reklamationen bearbeiten können.
78
www.hessen-it.de
Die Portallösungen stellen zwar eine komfortable Lösung für die Betreiber-, nicht aber für die Lieferantenseite dar. Große Zuliefererunternehmen, die ihre internen Prozesse professionell durch IT-Lösungen unterstützen, müssen im Schnitt 30 bis 50 Portale bedienen. Portale sind für sie zeitund kostenaufwändige Mensch-Maschine-Schnittstellen, die einen hohen
Monitoringaufwand und fehleranfällige redundante Datenpflege verursachen. Angesichts der immer weiter steigenden Anzahl von Portalen,
die selbst oft mehrere hundert Anwendungen umfassen, sehen sich die
Zulieferer einem „Portaldschungel“ gegenüber. Im Vergleich zur Popularitä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 überbetriebliche Qualitäts- und Reklamationsmanagement. Entsprechende B2B-Integrationsprojekte 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-BusinessPlattformen. Berücksichtigt man die enorme Komplexität und die Kosten
beim Aufsetzen elektronischer Prozesse, so besteht erheblicher Handlungsbedarf.
79
7.2 SOA-B2B-Architektur: Öffentliche und interne Sicht
Aufbau der serviceorientierten B2B-Zielarchitektur
Die steigende Vielfalt und Heterogenität der elektronischen Integrationsbeziehungen wird in Zukunft nur durch eine sorgfältig geplante B2BArchitektur zu bewältigen sein. Serviceorientierte Architekturen liefern
hier zunächst die technischen Grundlagen für den automatisierten Datenaustausch von strukturierten und unstrukturierten Inhalten in überbetrieblichen Geschäftsbeziehungen. Durch sie lassen sich sowohl die klassische
nachrichtenbasierte Integration, wie im Falle von EDI, als auch eine prozessorientierte 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“ einführen lässt. Vielmehr erfordert SOA grundsätzliche Überlegungen, wie
eine B2B-Architektur auszugestalten ist. Es gilt beispielsweise zu bewerten, welche Funktionalität künftig als Service zu realisieren ist, um so wiederverwendet oder schneller zu neuen Prozessvarianten konfiguriert zu
werden. Es ist auch prinzipiell zu überlegen, wie man über Unternehmensgrenzen ü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 verschiedenen Geschäftspartner hinweg abzustimmen ist und die überbetriebliche Prozessintegration umfasst, betrachtet die interne Sicht die
interne Umsetzung innerhalb eines Unternehmens. So wird der Anforderung Rechnung getragen, dass interne Prozessabläufe und Systemlandschaften verschiedener Partner unabhängig voneinander entworfen und
geändert werden.
80
www.hessen-it.de
Automobilhersteller
Zulieferer
Private
Private
Public
Prozessarchitektur
Prozess
Prozess
Prozessarchitektur
Servicebeschreibung
(SOA-basierte) Integrationsarchitektur
System
Desktopintegration
Serviceverzeichnis
Workflow
Private
WSDL
Semantik
BusinessServices
App.Services
Serviceverzeichnis
(SOA-basierte) Integrationsarchitektur
Desktopintegration
Workflow
BusinessServices
App.Services
Nachrichten
Applikationsarchitektur
Applikationsarchitektur
Infrastrukturarchitektur
Infrastrukturarchitektur
System
Private
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 interagieren. 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) Kunden die „gleiche Sprache“ an den Prozess- und Systemschnittstellen sprechen. M:n-Fähigkeit reduziert die derzeitige Vielfalt überbetrieblicher Prozessvarianten auf ein sinnvolles und beherrschbares Maß und führt dazu,
dass der Abstimmungs- und Integrationsaufwand beim Aufbau elektronischer Kooperationen erheblich sinkt.
81
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 proprietären Technologien wie EDI. Allerdings reichen das von den Herstellern propagierte techniklastige Service-Verständnis und die rein technische Interoperabilität von Web Services nicht aus. Überbetriebliche elektronische Vernetzung funktioniert mit SOA nur, wenn alle Partner Web Services mit gleicher Semantik verwenden, d. h. sich auf ein fachliches Service-Design einigen. Die große Herausforderung liegt dabei in der
betriebswirtschaftlichen Service-Definition sowie in der Verwendung standardisierter Web Service-Signaturen. Idealerweise ergänzen also Fachstandards die technische Standardisierung von Web Services. Im Rahmen
von „SOA in Automotive“ wurde die VDA-Empfehlung 4965 für das technische Änderungsmanagement in m:n-fähige Prozesse und Services überführt. Als Teil der unternehmensübergreifenden Produktentwicklung (Collaborative Engineering) umfasst das Änderungsmanagement die Bewertung und Entscheidung von Änderungsideen sowie die Umsetzung von
Änderungen in gemeinsamen Entwicklungs-, Planungs- und Fertigungsprozessen. 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 zwischenbetriebliche Prozessabläufe und erweitert damit die herkömmliche Standardisierung 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 Prozessdokumentation. Der „ECR Business Service“ setzt die Prozessinteraktion auf Systemebene um. Automobilhersteller und -zulieferer können so ihre Prozesse im
Änderungsmanagement durch Serviceaufrufe elektronisch koppeln.
82
www.hessen-it.de
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 implementiert, wie es angesichts der projektgetriebenen Umsetzung von B2BIntegrationslösungen häufig der Fall ist. Solche Services stellen in B2BArchitekturen insbesondere Basisfunktionalitäten zur Verfügung, wie die
Authentifizierung bzw. Autorisierung von externen Partnern oder die Validierung 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 B2BIntegration und Enterprise Application Integration (EAI) lassen sich überbetriebliche 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 Reportingsysteme (Data Warehouses) eingebunden werden. SOA erlaubt insbesondere 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
Diese Aspekte wurden in der Zielarchitektur aus „SOA in Automotive“ für
das technische Änderungsmanagement weiter ausgearbeitet: Im Unternehmen wurde dabei von der bestehenden Landschaft aus zumeist heterogenen Anwendungssystemen ausgegangen, die für die fachliche Verarbeitung von Änderungsanträgen zuständig sind. Diese Systeme werden
in der Schicht der domänenspezifischen Anwendungsdienste (Application 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 werden 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. MenschMaschine- und Maschine-Maschine-Schnittstellen mit der gleichen Integrationsinfrastruktur 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 Schlussfolgerungen in Bezug auf die Potenziale, aber auch auf die Herausforderungen 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 Änderungsmanagementsystemen, anstatt sie zusätzlich in Lieferantenportalen zu erfassen.
Dadurch entfällt Aufwand für die Informationsbereitstellung, der im konkreten Fall auf 0,75 Tage geschätzt wurde. Andere Formen der elektronischen Integration (z. B. EDI in Form von bilateralen Punkt-zu-Punkt-Verbindungen und standardisierter Nachrichtenaustausch ohne Prozessstandardisierung) weisen zwar ähnliche Vorteile wie der servicebasierte Ansatz
84
www.hessen-it.de
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 Prozessintegration. 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 auszugehen, so dass sich eine servicebasierte Kopplung von Geschäftsprozessen in Zukunft wesentlich kostengünstiger realisieren lässt. Gegenüber reinen Nachrichtenstandards und Schnittstellendefinitionen (z. B. in EDI- oder
XML-Syntax) ermöglichen serviceorientierte Ansätze eine stärkere fachliche 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 Services realisiert werden. Durch eine servicebasierte Kooperationsarchitektur
lassen sich folglich Integrationsbeziehungen mit mehreren Partnern und
über mehrere Prozesse hinweg auf Basis einer einheitlichen Integrationsarchitektur umsetzen und gleichzeitig flexibel und skalierbarer gestalten.
85
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 Unternehmen innerhalb von wenigen Tagen implementieren lassen. Auch die
unternehmensübergreifende Interoperabilität wird weitgehend problemlos 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 Realisierung 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 Fehlerbehandlungsmechanismen für fehlgeschlagene Serviceaufrufe, z. B. durch Benachrichtigung des Serviceaufrufenden, Mechanismen zur technischen Transformationen (z. B. mit XSLT) oder semantische Mappings (z. B. Purchase
Orders von RosettaNet nach SAP).
Auf der Basis der in den Unternehmen eingesetzten Middlewareplattformen lassen sich B2B Web Services innerhalb von wenigen
Tagen realisieren.
86
www.hessen-it.de
Allerdings machen die Erfahrungen aus „SOA in Automotive“ auch deutlich, dass es noch einige Hürden auf dem Weg hin zu einer serviceorientierten B2B-Architektur gibt – auch, wenn man die menschlichen Voraussetzungen 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 Anwendungssytemen ü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 Änderungsmanagement verhindert. Im Projekt zeigte sich, dass die eingesetzten Änderungsmanagementsysteme – auch die Standardsoftwarepakete –
bisher nicht über eine geeignete Serviceschnittstelle verfügten. Ein SOAEnabling wäre zwar bei allen Projektpartnern möglich gewesen, sie wurde
jedoch wegen des erheblichen Aufwands in diesem Projekt nicht durchgefü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-Integrationsprojekten beobachtet werden kann. Wenn sich serviceorientierte Architekturen 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 Automotive“ 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 akzeptierte Prozess- und Servicedefinitionen zu definieren und zu implementieren, um so die Potenziale der Serviceorientierung in der B2B-Integration in vollem Umfang zu nutzen.
87
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ösungen 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 Gegensatz zu nachrichtenbasierten (EDI-) Ansätzen sind sie in der Lage, komplexere (Multi-Step) Prozesse abzubilden. Sie sind daher geeignet,
weniger hochvolumige und strukturierte Prozesse zu unterstützen.
a Prozessplattformen entkoppeln die Prozess- von der Anwendungslogik. Mittels Orchestrierung (innerbetrieblich) bzw. Choreographie
(überbetrieblich) von Web Services verschalten sie lediglich Anwendungsfunktionen und beschleunigen so die Umsetzung neuer Prozessvarianten. 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 Weiterverarbeitung 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 zentral bereitgestellt und in verschiedenen Kooperationsbeziehungen
wieder verwendet werden. Diese Services können auch auf einfache
Weise von externen Spezialisten bezogen werden.
88
www.hessen-it.de
Aktuelle Herausforderungen in
B2B-Netzwerken
Was bringt SOA?
Wo liegen Herausforderungen
bei der SOA?
Starker Zuwachs digitaler Prozesse
von der Produktentwicklung über
die Produktion bis hin zu Garantie,
Service und Entsorgung
m:n-Fähigkeit in überbetrieblichen Prozessen:
Fachliche Service-Spezifikation
(„Semantik“): z. B. Ergänzung von
Fachstandards (VDA, Odette, …)
durch Spezifikation von (Web)
Services und deren Choreographie
Vielfalt der Partner, Prozessvarianten und eingesetzten Technologien
a Nutzung offener, kostengünstiger und weit verbreiteter
Internet-Technologien
a Geringerer Abstimmungs- und
Integrationsaufwand durch
Services als wohldefinierte
Schnittstellen für externe Partner
a Dokumentation der Services in
einem Service-Repository mit
externen Sichten
Realisierung von B2B-Integration
als Einzellösung auf Anforderung
eines Fachbereiches oder Partners
Vielfalt der e-Business-Plattformen
(Portale, XML-Nachrichtenaustausch, EDI, …)
Aufwände für die Anbindung
interner Systeme an unterschiedliche e-Business-Plattformen
Skalierbare, flexible e-BusinessPlattform im Unternehmen
a Konvergenz der Plattformen
für B2B-Integration (B2Bi) und
Enterprise Application Integration (EAI)
a Unterstützung sämtlicher
Varianten der B2B-Integration:
nachrichtenbasiert (EDI, XML),
prozessorientiert (Workflows),
benutzerorientiert (Portale)
Überbetriebliche (Referenz-)Prozesse als Grundlage der elektronischen Integration: „Public
Processes“, z. B. in der Produktentwicklung, im Qualitäts- oder
Reklamationsmanagement
Konzeption einer SOA-basierten
B2B-Zielarchitektur für das
Unternehmen
Schrittweise Umsetzung im
Sinne der B2B-Zielarchitektur
SOA-Enabling der
Anwendungssysteme
a Wiederverwendung von BasisServices (z. B. Authentifizierung,
Validierung)
a Workflows zur Weiterverarbeitung von externen Serviceaufrufen und Integration in die entsprechenden internen Backendsysteme
a Änderbarkeit und Anpassungsfähigkeit an partnerspezifische
Anforderungen (Datenformate,
Prozessvarianten)
SOA als Grundlage zukunftsfähiger B2B-Architekturen
89
SOA-Perspektiven: Geschäftsmodelle und Innovationen für das Internet der Dienste
8
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 Herausforderungen 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
tendenziell 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öpfungsketten 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).
90
www.hessen-it.de
Hartverdrahtete
Wertschöpfungsketten
Spezialisierung
und
Konsolidierung
Agile Service
Value Networks
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 Netzwerken Geschäftsprozesse agil und dynamisch zusammenfügen kann. Die
Softwarebranche ist selbst ein Pionier in diesem Bereich. Die Unternehmen 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 verknüpfter Servicenetzwerke wird die Entwicklung einer Infrastruktur erwartet, die auch als das „Internet der Dienste“ charakterisiert wird.
91
Revolution des Softwarevertriebes: Software-as-a-Service
Neben der SOA-Entwicklung, die vornehmlich in Unternehmen Wirkung
erzeugt, sind diverse weitere bedeutsam, die eine Revolution unternehmensübergreifender Leistungsprozesse möglich machen sollen. Allgemein lassen sich diese unter dem Begriff „X-as-a-Service“ zusammenfassen. 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ückgeführt werden. Zum einen sorgen fallende Transaktions- und Kommunikationskosten dafür, dass Anbieter Software betriebsfertig über das Internet
anbieten und so Skaleneffekte nutzen können. In Verbindung mit den sinkenden Kosten bietet sich nun die Möglichkeit, bisher weniger erschlossene
Märkte zu bedienen. Im Vergleich zu traditioneller Software bezahlen Kunden 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äftsanwendungen aufgrund ihres Preises und ihrer Komplexität oftmals nur für große
Unternehmen interessant waren, besteht nun die Möglichkeit, nutzungsbasiert oder auf periodischer Basis auch kleine und mittelständische Unternehmen (KMU) zu bedienen und so den oftmals gesättigten Markt der Großunternehmen 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. Bedarfsschwankungen einfacher ausgeglichen werden können. Beispielsweise werden OnDemand-Applikationen als Mittelstandslösung angeboten, die ab 133 Euro
monatlich bezogen werden kann (Stand 2009).
92
www.hessen-it.de
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 vielmehr 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 Orchestrierung und den Aufruf mehrerer vorhandener Dienste. Diese können
von unterschiedlichen Parteien kommerziell angeboten werden und letztendlich 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 Nutzung 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
Grad der Interaktion
Ein (dominierender)
Anbieter
Viele Anbieter
Aggretiertes Angebot
einfacher Dienste über
einen Marktplatz.
Funktionale Integration
wird nicht unterstützt.
Integriertes Angebot
komplexer Dienste,
die aus einfachen oder
komplexen Teildiensten
bestehen und über
einen Marktplatz
vertrieben werden.
Angebot einfacher
Dienste durch einzelnes
Unternehmen.
Angebot komplexer
Dienste durch einzelnes
Unternehmen.
1 3
2 4
Grad der Komplexität
Einfacher Dienst
Komplexer Dienst
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 Kooperationsgrades über Unternehmensgrenzen hinweg.
94
www.hessen-it.de
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 Amazons 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 kommerziellen 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
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äftsanwendungen revolutionierten. Einzelkomponenten dieser Anwendungen
können dynamisch zu nutzerspezifischen Prozessen modelliert werden.
Einen Schritt weiter in Richtung des vierten Quadranten geht AppExchange, der von Salesforce.com betriebene Marktplatz für On-DemandServices. 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 integrierbar 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 Abrechnungskomponente für alle angebotenen zusammengesetzten Services.
96
www.hessen-it.de
Generell zielte SaaS bisher vor allem auf die kostengünstige Bereitstellung 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 angebotenen 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äftslösungen komplexe Geschäftsprozesse unterstützen. Durch die Orchestrierung modularer Teildienste findet nicht nur eine organisationsübergreifende Zusammenarbeit in Service-Netzwerken statt (vgl. Abbildung
auf S. 91). Durch die freie Kombinierbarkeit der Teildienste können Konsumenten 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-Anwendungen unterstützt werden.
Quadrant 4:
Komplexe Dienstkonfiguration durch
Wertschöpfungsnetze
Auch wenn das Salesforce-Angebot schon ein sehr umfassendes Lösungsspektrum umfasst, besteht weiterhin Forschungsbedarf im Bereich komplexer 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
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 Wissensund Dienstleistungsgesellschaft zu entwickeln. Um Wissen im Internet
besser verfügbar zu machen, werden in unterschiedlichen Forschungsprojekten (Use Cases), die jeweils von renommierten deutschen Technologieunternehmen geführt werden, anwendungsorientierte Basistechnologien 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 bearbeitet. Insgesamt befassen sich etwa 55 Wissenschaftlerinnen und
Wissenschaftler mit TEXO. TEXO zielt auf den Entwurf und die prototypische 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
www.hessen-it.de
Externe
Innovation
!
W
)
W Initiierung
@
W
Innovation
%
W
Angebot
Dienstleistungslebenszyklus
Feedback
Matchmaking
$
W
Nutzung
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 auftreten oder kompatible, modulare Dienste zu komplexen Diensten zusammenfügen. So können bereits existierende Dienste von unterschiedlichsten Anbietern kombiniert werden. Durch eine solche Reallokation entstehen neue, innovative Anwendungen. Die TEXO Services Management
Platform tritt sowohl als Koordinator als auch als Integrator und Schnittstelle auf, um alle beteiligten Parteien zusammenzubringen. Es werden
sowohl Geschäftsanwendungen als auch deren Realisierung durch technische Dienste betrachtet. Die TEXO Service Management Platform eröffnet damit kleinen und mittelständischen Dienstleistern neue Märkte und
ermöglicht es Dienstkonsumenten, ihre Software dynamisch an Veränderungen anzupassen.
99
8.3 Marktpotenzial serviceorientierter IKT
Das Marktpotenzial, das serviceorientierten Ansätzen zugesprochen wird,
ist sehr bedeutsam und wird später noch konkreter illustriert. Im Vordergrund der weiteren Ausführungen steht aber die Frage, welchen Einfluss
diese auf die Geschäftsmodelle der Anbieter haben werden. Internetbasierte 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 Umsetzungsvision 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 Businessund 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
www.hessen-it.de
KMU sind laut der Sandhill Group und McKinsey dabei die Kernzielgruppe. Nach einer Studie in den USA geben heute kleine Unternehmen
mit weniger als 100 Mitarbeitern bereits 26 % ihres Budgets für OnDemand-Software aus. Dabei sind nach einer Gartner-Studie die beliebtesten Funktionen Customer Relationship Management (CRM), Enterprise
Resource Planning (ERP), Supply Chain Management (SCM), Storage und
Kollaborationsanwendungen – insgesamt meist Funktionen, die typischerweise 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 Computing 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 Anbieterseite 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ürden darstellen. Ist der Schritt zur Nutzung gegangen, besteht die Kernherausforderung 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
Für bereits etablierte Anbieter von Unternehmenssoftware ist eine Änderung 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äulen „Lizenzgebühren“, „Customizing / Consulting“ sowie regelmäßig wiederkehrenden Wartung („Maintenance“).
Bei SaaS-Geschäftsmodellen sieht sich der Anbieter weiterhin initialen
Kosten für Entwicklung, Marketing etc. ausgesetzt, Umsätze werden allerdings erst nach und nach durch nutzungsbedingte oder monatlich
berechnete Gebühren generiert, wobei zudem laufende Bereitstellungskosten (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ösungsintegration mit bestehender Infrastruktur wohl in vielen Fällen trotzdem
erforderlich und insbesondere bei komplexeren SaaS-Anwendungen weiterhin 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ösquellen 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
www.hessen-it.de
8.4 Geschäftsmodelle für das Internet der Dienste
Welche neuen Geschäftsmodelle sind nun in einer offenen Serviceplattform, wie sie das TEXO-Konsortium anstrebt, denkbar? Potenziell natürlich
unendlich viele. Zur Illustration seien einige skizziert, wobei wir vereinfachend die Annahme treffen, dass die gesamte Infrastruktur von einem
Anbieter betrieben wird. Die andere Extremform ist die eines rein dezentralen 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 Kundennutzen“ sowie „Art und Ursprung der Erträge“.
Grundsätzlich gehören die Akteure einer solchen Plattform fünf grundlegenden Rollen an: Plattformbetreiber, Servicekonsument, Serviceanbieter, Communitymitglied und Serviceinnovator. Die beiden letztgenannten
Rollen werden im Folgenden vernachlässigt, da sie spezielle Rollen darstellen, die größtenteils in Überlappungen mit den drei erstgenannten
Rollen auftreten dürften. Die Abbildung unten zeigt, welche Infrastrukturdienste 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
%
W
)
W
!
W
@
W
#
W
$
W
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 Gegebenheiten sensibilisiert – und das Servicemarketing unterstützen. In der Matchmakingphase (3) können sowohl ökonomische, rechtliche als auch technische Dienste angeboten werden. Beispielsweise könnten allgemeine
Geschäftsbedingungen (AGBs) von Anbieter und Konsument abgeglichen
und ggf. angepasst werden. Semantische Technologien und Service Repositories 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
104
www.hessen-it.de
erbrachten Dienste. Außerdem können die Angebote potentiell über mehrere 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 Integrationsdienste von plattformexternen Dienstleistern angeboten werden. Gleiches 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 Serviceanbietern 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 unterschiedlichen komplexen Diensten auch Kundenbedürfnisse befriedigen,
© Dan Collier - Fotolia.com
die fernab der Massenbedürfnisse liegen.
105
Nutzen für Servicekonsumenten
Der generierte Nutzen für den Servicekonsumenten lässt sich grob in sieben 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 Nutzenversprechen eines SOA-Einführungsprojekts.
a Flexibilität: Auf dem Servicemarktplatz werden nicht nur komplementä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 Anbieterwechsel („Switching Costs“). Im Allgemeinen ist ein Konsument Umstellungskosten bei einem Anbieterwechsel ausgesetzt, wenn eine Investition, die bezüglich des bestehenden Anbieters erbracht werden musste,
für einen neuen Anbieter erneut aufgebracht werden müsste. Im traditionellen 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ängigkeiten („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 monatlicher Basis („Subscription Fee“) abgerechnet. Ist der Kunde nun unzufrieden, 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 gemeinsamer 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-Studie von 2007 finden 42 % SaaS-interessierte Unternehmen momentan
keine passenden On-Demand-Anwendungen.
106
www.hessen-it.de
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 Servicekonsument 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) unterstützt die zentrale Monitoringkomponente der Plattform und bietet
dem Servicekonsumenten einen zentralen Ansprechpartner („one-faceto-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 zentralen Servicemarktplatz („Single-Point-of-Access“) müsste der Konsument nun selbst Kompensationszahlungen des betreffenden Anbieters einfordern. Je mehr Anbieter am Dienst beteiligt sind, umso komplexer die Verrechnung unzureichend erbrachter Dienste und die
Ermittlung des Verursachers.
107
a Wiederverwendbarkeit: Wenn der Kunde auf der Serviceplattform
keine passenden Applikationen findet, bietet die Plattform ein Framework (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 Serviceanbieter 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ändische 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 Marktplatzbetreiber sowohl Hard- und Software, als auch die Infrastruktur
liefern, verringert sich in der Regel die Zeit, bis die Applikation einsatzfähig ist („Time-to-Market“).
imagesource
108
www.hessen-it.de
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-Anwendungen 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. Übergreifend ü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ünstig angeboten werden und liefert die nötige Flexibilität, um Customizing-Wünsche der Servicekonsumenten befriedigen zu können. Während 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 komplexer 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 Infrastrukturservices reduzieren den Aufwand für Dienstanbieter. Die eigene
Infrastruktur kann somit minimal gehalten werden, die Plattform übernimmt Aufgaben, die für Serviceanbieter bisher als „notwendiges
Übel“ Overhead produziert haben. Beispielsweise können unter anderem Abrechnungsfunktionen, Monitoring, rechtliche Unterstützung,
(dynamische) Preisfindung etc. zentral angeboten werden.
109
a Wiederverwendbarkeit: Durch die hohe Marktabdeckung einer Serviceplattform können profitabel Nischendienstleistungen angeboten
werden. So kann ein Anbieter günstig, beispielsweise durch Wiederverwendung vorhandener Komponenten und das Angebot von nutzungsbasierter 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 Multimandantenprinzips 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 fehlende Customization bei SaaS-Anwendungen. Kosteneinsparungen
sind auch durch Einsparungen im Marketingbereich möglich, da sich
Marketingmaßnahmen durch die Plattform direkt auf Serviceanbieter
© Charon | Dreamstime.com
auswirken können.
110
www.hessen-it.de
8.5 Fazit
Der Wandel zur Dienstleistungsgesellschaft ist aufwendig und vielschichtig – Beispiele für die Vielfalt der im Zuge der Dienstorientierung entstehen technischen Neuerungen sowie die wirtschaftlichen Risiken, aber
auch Handlungsoptionen wurden hier illustriert.
Ausgehend von der heutigen Situation, das heißt dem Angebot individueller 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, Infrastrukturdiensten, 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 Anwendungen zu Salesforce bereitstellen. Das Unternehmen hat insgesamt
ca. 47 000 registrierte Kunden (Stand 25. Januar 2010).
Unternehmen haben heute die Chance, von solchen Vorreitern oder von
existierenden wegweisenden Forschungsarbeiten zu lernen und die Perspektive zu prüfen, eigene Services künftig auf dem tatsächlich globalen
Markt zur Verfügung zu stellen oder Dienste von Dritten in ihre Infrastruktur zu integrieren. Sie können dabei vor allem von offenen Innovationsprozessen, 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
Glossar
9
Glossar
Business Process Execution Language
(BPEL)
BPEL ist eine XML-basierte Beschreibungssprache, mit der sich ein fachlicher Prozess
spezifizieren lässt. Mit einem BPEL-Editor
wird von der Überführung des fachlichen
Prozesses ein grafisches IT-Prozessmodell
erstellt. Dieses Modell enthält die Perspektiven der Fach- und der IT-Seite.
Enterprise Service Bus (ESB)
Der „ESB“ (Gartner 2002) bildet eine Integrationsinfrastruktur, die z. B. einem Unternehmen einen Service über einen Datenbus
zur Verfügung stellt. Ein ESB wird gemeinsam von Service-Gebern und -Nehmern
genutzt, so dass unzählige Punkt-zu-PunktVerbindungen vermieden werden.
Governance
Business Process Management (BPM)
BPM ist ein ganzheitlicher Ansatz zum
Management des Lebenszyklusses von Prozessen, der zur Prozessoptimierung eingesetzt werden kann. BPM und SOA ergänzen
sich wechselseitig. Denn einerseits sollte
ein Prozess, bevor er informationstechnisch
abgebildet wird, zunächst analysiert und
optimiert werden. Andererseits stellt SOA
eine IT-Architektur dar, die eine flexible Prozessgestaltung und -verbesserung unterstützt.
112
SOA-Governance (franz. gouverner, verwalten, leiten, erziehen) bezeichnet die soziale,
IT- und geschäftsbezogene Steuerung und
Kontrolle eines SOA-Prozesses. Sie umfasst
diesbezügliche Aktivitäten, Entscheidungen, Rollen und Verantwortlichkeiten.
Orchestrierung
Der Prozess oder Zustand einer losen Verkopplung von Services z. B. mittels BPEL
wird Orchestrierung genannt. Durch die
Verkopplung wird ein neuer übergeordneter Service mit erweiterten Funktionen
oder eine neue Anwendung erzeugt.
www.hessen-it.de
Registry
Service
Ein Verzeichnis oder Katalog verfügbarer
Services mit nur wenigen Metadaten wie
etwa einer Schnittstellenbeschreibung wird
Registry genannt. Einem Branchen-Telefonbuch ähnlich gehen daraus im Wesentlichen nur die Adresse und wenige Zusatzinformationen hervor.
Ein Service (Dienst) ist die zentrale Grundkomponente einer SOA. Er stellt eine eigenständige und unabhängige funktionale
Einheit dar. Wird ein Service mit einer standardisierten Schnittstelle über Web Services
mit anderen Services verknüpft, entsteht
eine serviceorientierte Architektur.
Repository
Web Service
Das Repository dient – stärker als das
Registry – als Instrument der SOA-Governance zur Steuerung und Kontrolle von
Services. Es speichert und kategorisiert die
Services mit ihren zugehörigen Aspekten.
Werden Registry und Repository zu einer
integrierten Einheit zusammengefasst,
werden sie als „Repistry“ bezeichnet.
Unter Web Service kann man lose gekoppelte, wieder verwendbare Softwarekomponenten verstehen, die unter Verwendung
von Internetstandards aufgerufen werden
können und über den Austausch von XMLbasierten Nachrichten miteinander kommunizieren. Web Services sind der zentrale
Standard zur Realisierung von ServiceSchnittstellen und zur Kopplung von
Services.
113
Ihre Partner in Hessen
10
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ändigkeit. Weitere Informationen über mögliche SOA-Partner mit Sitz in Hessen erhalten Sie
im Internet unter www.kompetenzatlas-hessen.de.
Accelsis Technologies GmbH
arlanis Software AG
Mannheimer Straße 97
60327 Frankfurt am Main
Mergenthalerallee 77
65760 Eschborn
Andreas Holubek
Telefon 069 241829-0
Telefax 069 241829-29
[email protected]
Frank Joecks
Telefon 06196 470520
Telefax 06196 470549
[email protected]
www.arlanis.com
www.accelsis.biz
ATE Software GmbH
Accenture GmbH
Bockenheimer Anlage 4
60322 Frankfurt Main
Campus Kronberg 1
61476 Kronberg im Taunus
Telefon 06173 94-99
Telefax 06173 94-98
[email protected]
Thomas Erbrich
Telefon 069 9150119-0
Telefax 069 9150119-1
[email protected]
www.accenture.com
www.ate-software.net
Accurat Informatik GmbH
Avanade Deutschland GmbH
Im Gefierth 13c
63303 Dreieich
Campus Kronberg 7
61476 Kronberg
Telefon 06103 3807-0
Telefax 06103 3807-124
[email protected]
Telefon 06173 94 63800
Telefax 06173 94 63999
[email protected]
www.accurat.de
www.avanade.de
ALTRAN Deutschland Holding GmbH
Schillerstraße 20
Telefon 069 219767-70
Telefax 069 219767-76
[email protected]
www.altran.de
114
uns
Dann senden Sie
Fehlt Ihr Eintrag?
de
fo@hessen-it.
Ihre Angaben an in
www.hessen-it.de
Axway GmbH
Mainzer Landstraße 61
Telefon 069 244 508-0
Telefax 069 244 508-21
[email protected]
www.axway.de
BLAUERLOTOS GmbH & Co. KG
CAST e.V. – Competence Center for
Applied Security Technology
Geschäftsführung
Fraunhoferstraße 5
64283 Darmstadt
Claudia Prediger
Telefon 06151 155-529
Telefax 06151 155-499
[email protected]
www.cast-forum.de
Am Felsenkeller 8a
63505 Langenselbold
Telefon 06184 937221
Telefax 06184 937481
[email protected]
www.blauerlotos.com
CA Deutschland GmbH
Marienburgstraße 35
64297 Darmstadt
Telefon 06151 949-0
Telefax 06151 949-600
[email protected]
www.ca.com/de
CASED – Center for Advanced Security
Research Darmstadt
Direktor
Mornewegstraße 32
64293 Darmstadt
Prof. Dr. Johannes Buchmann
Telefon 06151 16-50777
Telefax 06151 16-6036
[email protected]
www.cased.de
Geschäftsführung
Fraunhoferstraße 5
64283 Darmstadt
Prof. Dr. Andreas Heinemann
Telefon 0621 4105-1170
Telefax 06151 155-499
[email protected]
www.cast-forum.de
Corisecio GmbH
Uhlandstraße 9
64297 Darmstadt
Telefon 06151 95130-11
Telefax 06151 95130-66
[email protected]
www.corisecio.com
CSC in Deutschland
Abraham-Lincoln-Park 1
65189 Wiesbaden
Telefon 0611 142-0
Kundeninfo 0611 142-22222
Telefax 0611 142-22000
[email protected]
www.csc.com/de
Software-Cluster Koordinierungsstelle
Mornewegstraße 32
64293 Darmstadt
Gino Brunetti
Telefon 06151 16-70821
Telefax 06151 16-55136
[email protected]
www.cased.de
Daenet GmbH
Hanauer Landstraße 204
Telefon 069 242408-0
Telefax 069 242408-25
[email protected]
www.daenet.de
115
DB Systel GmbH
Kleyerstraße 27
Gunnar Rühl
Telefon 069 265-17800
Telefax 069 265-18420
[email protected]
www.dbsystel.de
European Business School
Institute of Research on Information Systems IRIS
Rheingaustraße 1
65375 Oestrich-Winkel
Dr. Christine Legner
Telefon 06723 991-251
Telefax 06723 991-255
[email protected]
www.ebs.edu/iris
Detecon International GmbH
Frankfurter Straße 27
65760 Eschborn
Dieter Wendel
Telefon 06196 903-255
Telefax 06196 903-496
[email protected]
www.detecon.com
Fachhochschule Gießen-Friedberg
Wiesenstraße 14
35390 Gießen
Prof. Dr. Thomas Letschert
Telefon 0641 309-2388
Telefax 0641 309-2908
[email protected]
www.mni.fh-giessen.de
Devoteam Danet GmbH
Gutenbergstraße 10
64331 Weiterstadt
Telefon 06151 868-0
[email protected]
www.devoteam.de
EDAG GmbH & Co. KGaA
Reesbergstraße 1
36039 Fulda
IT Services
FORTENO GmbH
Taunusstraße 66
65183 Wiesbaden
Telefon 0611 58069-10
Telefax 0611 58069-77
[email protected]
www.forteno.com
Frankfurt School of
Finance & Management
Raoul Flügel
Telefon 0661 6000-596
Telefax 0661 6000-113204
[email protected]
Wirtschaftsinformatik
Management Research Centre
Sonnemannstraße 9-11
www.edag.com
Prof. Dr. Matthias Goeken (JP)
Telefon 069 154008-746
Telefax 069 154008-4746
[email protected]
Epicor Software Deutschland GmbH
Hanauer Landstraße 291a
Telefon 069 800 766-00
Telefax 069 800 766-05
[email protected]
www.epicor.de
www.frankfurt-school.de
Prof. Dr. Peter Rossbach
Telefon 069 154008-739
Telefax 069 154008-4739
[email protected]
www.frankfurt-school.de
116
www.hessen-it.de
Fraunhofer-Institut für Sichere
Informationstechnologie (SIT)
Hochschule Fulda
Institutsleitung
Rheinstraße 75
64293 Darmstadt
Angewandte Mathematik,
Kryptographie, IT-Sicherheit
Marquardstraße 35
36039 Fulda
Prof. Dr. Claudia Eckert
Telefon 06151 869-285
Telefax 06151 869-127
[email protected]
Prof. Dr. Ulrich Bühler
Telefon 0661 9640-325
Telefax 0661 9640-349
[email protected]
www.sit.fraunhofer.de
www.informatik.hs-fulda.de
Gartner Deutschland GmbH
Lyoner Straße 20
60528 Frankfurt
Telefon 069 669084-0
Telefax 069 6662809
[email protected]
www.gartner.com
HA Hessen-Agentur GmbH
Hochschule RheinMain
Design Informatik Medien
Labor für Verteilte Systeme
Kurt-Schumacher-Ring 18
65197 Wiesbaden
Prof. Dr. Reinhold Kröger
Telefon 0611 9495-1207, -1202
Telefax 0611 9495-1210
[email protected]
wwwvs.cs.hs-rm.de
siehe Hessen-IT
Hochschule Darmstadt
Hessen-IT
Aktionslinie für den hessischen
IKT-Markt des Hessischen Ministeriums
für Wirtschaft, Verkehr und Landesentwicklung (HMWVL)
c/o HA Hessen Agentur GmbH
Abraham-Lincoln-Straße 38–42
65189 Wiesbaden
Wolf-Martin Ahrend
Telefon 0611 774-8299
Telefax 0611 774-8620
[email protected]
www.hessen-it.de
Dr. Matthias Donath
Telefon 0611 774-8963
Telefax 0611 774-8620
[email protected]
Informatik
Schöfferstraße 8b
64295 Darmstadt
Prof. Dr. Bernhard Humm
Telefon 06151 16-8494
Telefax 06151 16-8935
[email protected]
www.fbi.h-da.de
Informatik, Institut für Angewandte
Informatik Darmstadt (aiDa)
Schöfferstraße 8b
64295 Darmstadt
Prof. Dr. Hans-Peter Wiedling
Telefon 06151 16-8441
Telefax 06151 16-8935
[email protected]
www.aida.h-da.de
www.hessen-it.de
HTTC – Hessisches Telemedia
Technologie Komptenz-Center e.V.
siehe SOA Competence Center im HTTC e.V.
117
IDC Central Europe GmbH
Intersystems GmbH
Hanauer Landstraße 135-137
60314 Frankfurt
Hilpertstraße 20a
64295 Darmstadt
Telefon 069-90502-0
Telefax 069-90502-100
[email protected]
Thomas Mironiuk
Telefon 06151 1747-0
Telefax 06151 1747-11
[email protected]
www.idc.com
www.intersystems.de
infodienst GmbH
Schützenrain 9
61231 Bad Nauheim
Telefon 06034 92314
Telefax 06034 92301
[email protected]
www.4soa.de
Informatica GmbH
Lyoner Straße 15
60528 Frankfurt
Telefon 069 928809-0
Telefax 069928809-500
[email protected]
www.informatica.com/de
Information Builders (Deutschland) GmbH
Mergenthalerallee 35
65760 Eschborn
Anja Griebel
Intraprend Gesellschaft für Intranet
Anwendungsentwicklung mbH
Borsigstraße 18
65205 Wiesbaden
Telefon 06122 533959
Telefax 06122 533963
[email protected]
www.cierp3.de
iPIsec Ltd.
Auguste-Viktoria-Straße 3
61231 Bad Nauheim
Wolfgang Geisel
Telefon 06032 93897-12
Telefax 06032 93897-15
[email protected]
www.ipisec.com
Johann Wolfgang Goethe-Universität
Telefon 06196 77576-0
Telefax 06196 77576-99
[email protected]
Institut für Wirtschaftsinformatik
Grüneburgplatz 1
www.informationbuilders.de
Prof. Dr. Wolfgang König
Telefon 069 798-34001
Telefax 069 798-33910
[email protected]
intelligent views gmbH
Julius-Reiber-Straße 17
64293 Darmstadt
www.wiwi.uni-frankfurt.de
Claudia Baumer
Telefon 06151 5006-423
Telefax 06151 5006-138
[email protected]
Datenbanken und Informationssysteme (DBIS)
Robert-Mayer-Straße 10
www.i-views.de
Prof. Dr.-Ing. Roberto V. Zicari
Telefon 069 798-28212
Telefax 069 798-28123
[email protected]
www.dbis.informatik.uni-frankfurt.de
118
www.hessen-it.de
Justus-Liebig-Universität Gießen
Institut für Informatik
Arndtstraße 2
35392 Gießen
Prof. Dr. Martin Kutrib
Telefon 0641 99-32140
Telefax 0641 99-32149
[email protected]
Opitz Consulting Bad Homburg GmbH
Kaiser-Friedrich-Promenade 93-95
61348 Bad Homburg v. d. H.
Markus Ganss
Telefon 06172 66260-0
Telefax 06172 66260-4500
[email protected]
www.opitz-consulting.de
www.informatik.uni-giessen.de
PA Consulting Group Deutschland GmbH
Logica Deutschland GmbH & Co. KG
Rheinstraße 95
64295 Darmstadt
Telefon 06151 36860-0
Telefax 06151 36860-222
Am Limespark 2
65843 Sulzbach (Taunus)
Telefon 06196 7742-0
Telefax 06196 7742-555
www.logica.com
msgGillardon AG
Mergenthalerallee 55-59
65760 Eschborn
Dr. Nicolas Repp
Telefon 06196 7750-0
Telefax 06196 7750-5410
[email protected]
www.msg-gillardon.de
Lufthansa Systems AG
Am Weiher 24
65451 Kelsterbach
Telefon 069 696-90000
Telefax 069 696-95959
[email protected]
www.LHsystems.com
OctaVIA AG
Marie-Calm-Straße 1-5
34131 Kassel
Telefon 0561 31000-0
Telefax 0561 31000-31
[email protected]
Eschersheimer Landstraße 223
Telefon 069 71702-0
Telefax 069 71702-263
[email protected]
www.paconsulting.com
Philipps-Universität Marburg
Fachbereich Mathematik und Informatik
Hans-Meerwein-Straße 3
35032 Marburg
Prof. Dr. Bernd Freisleben
Telefon 06421 2821-568
Telefax 06421 2821-573
[email protected]
www.informatik.uni-marburg.de
Rücker AG
Kreuzberger Ring 40
65205 Wiesbaden
Telefon 0611 73 75-0
Telefax 0611 73 75-102
[email protected]
www.ruecker.de
Saugatuck Technologies Inc.
Bluecherstraße 4
65343 Eltville
Frank P. Sempert
Telefon 06123 630285
Telefax 06123 630362
[email protected]
www.saugatech.com
www.octavia.de
119
SAP Research CEC Darmstadt
SP Integration GmbH
Bleichstraße 8
64283 Darmstadt
Otto-Volger-Straße 5a
65843 Sulzbach / Taunus
Dr. Knut Manske
Telefon 06227 7-68844
Telefax 06227 78-44632
[email protected]
Telefon 06196 76430-0
Telefax 06196 76430-11
[email protected]
www.sp-integration.de
www.sap.com/research
Sylphen GmbH & Co. KG
Software AG
Uhlandstraße 12
64297 Darmstadt
Daniel Adelhardt
Telefon 06151 92-1403
Telefax 06151 92-11 91
[email protected]
www.softwareag.com
SOA Competence Center im HTTC e.V.
Rundeturmstraße 10
64283 Darmstadt
Dr.-Ing. Julian Eckert
Telefon 06151 16-3742
Telefax 06151 16-6152
[email protected]
www.httc.de
Stefan Schulte
Telefon 06151 16-6187
Telefax 06151 16-6152
[email protected]
www.httc.de
Liebigstraße 14
35390 Gießen
Ralph Boßler
Telefon 0641-94468-0
[email protected]
www.sylphen.com
Syngenio AG
Schiersteiner Straße 86
65187 Wiesbaden
Stefan Scheid
Telefon 0611 450415-0
Telefax 0611 450415-22
[email protected]
www.syngenio.de
T-Systems International GmbH
Otto-Röhm Straße 71c
64293 Darmstadt
Bernard Tsai
Telefon 06151 886-1757
Telefax 06151 886-9515
[email protected]
www.t-systems.de
Software & Support Verlag GmbH
Geleitsstraße 14
Mirko Schrempp
Telefon 069 630089-38
Telefax 069 630089-89
[email protected]
www.software-support.biz
120
Tieto Deutschland GmbH
Düsseldorfer Straße 40
65760 Eschborn
Telefon 06196 9329-0
Telefax 06196 9329-898
http://tieto.de
www.hessen-it.de
Technische Universität Darmstadt
Information Systems / Wirtschaftsinformatik
Hochschulstraße 1
64289 Darmstadt
Prof. Dr. Peter Buxmann
Telefon 06151 16-4826
Telefax 06151 16-5162
[email protected]
Universität Kassel
Kommunikationstechnik
Wilhelmshöher Allee 73
34121 Kassel
Prof. Dr.-Ing. Klaus David
Telefon 0561 804-6314
Telefax 0561 804-6360
[email protected]
www.is.tu-darmstadt.de
www.comtec.eecs.uni-kassel.de
Multimedia Communications Lab
Rundeturmstraße 10
64283 Darmstadt
Verteilte Systeme
Wilhelmshöher Allee 73
34121 Kassel
Prof. Dr.-Ing. Ralf Steinmetz
Telefon 06151 16-6151
Telefax 06151 16-6152
[email protected]
www.kom.tu-darmstadt.de
Prof. Dr. Kurt Geihs
Telefon 0561 804-6275
Telefax 0561 804-6277
[email protected]
www.vs.uni-kassel.de
Unisys Deutschland GmbH
Am Unisys-Park 1
65843 Sulzbach
Telefon 06196 99-0
Telefax 06196 99-1570
[email protected]
www.unisys.de
121
Profile der Unternehmen und Institutionen der Autoren in der Reihenfolge des Erscheinens
11
Profile der Unternehmen und Institutionen der
Autoren in der Reihenfolge des Erscheinens
SOA Competence Center im httc e.V.
Software AG
Das SOA Competence Center (SCC) ist ein
Geschäftsbereich des Hessischen Telemedia Technologie Kompetenz-Centers e.V. in
Darmstadt (httc e.V.). Das SCC berät Unternehmen und Organisationen im Rahmen
von Software-Architekturprojekten im
Kontext serviceorientierter Architekturen.
Die Leistungen des SCC richten sich an
Unternehmen, die SOA planen, einführen,
optimieren und als Infrastruktur anbieten.
Software AG ist ein weltweit führendes
Unternehmen im Bereich Business Process
Excellence. Der Unternehmensumsatz
beläuft sich auf mehr als 1 Milliarde Euro
(2009), mehr als 6000 Mitarbeiter gehören
zum Unternehmen, und es beliefert über
10 000 Kunden in 70 Ländern weltweit. Das
Unternehmen hat seinen Hauptsitz in
Deutschland und ist an der Frankfurter
Wertpapierbörse notiert.
www.httc.de
www.softwareag.com
Dr. Wolfgang Martin Team
Opitz Consulting Bad Homburg GmbH
Dr. Wolfgang Martin ist ein unabhängiger
Analyst und europäischer Experte auf den
Gebieten Business Intelligence / Corporate
Performance Management (BI / CPM), Business Process Management, Enterprise Information Management (Business Integration),
Service Oriented Architecture (SOA) und
Customer Relationship Management (CRM)
OPITZ CONSULTING ist ein Projektspezialist
im Java-, SOA- und Oracle-Markt. Das Unternehmen unterstützt bei der Erstellung einer
IT-Strategie und berät bei dem Prozessdesign und der Aufnahme der Anforderungen.
Es konzipiert und realisiert kundenspezifische IT-Lösungen, gewährleistet einen hochverfügbaren Betrieb und bildet Mitarbeiter
in Schulungszentren aus. OPITZ CONSULTING wurde 1990 gegründet und beschäftigt über 400 Mitarbeiter an Standorten in
Deutschland, Polen und der Schweiz.
www.wolfgang-martin-team.net
www.opitz-consulting.com
122
www.hessen-it.de
Detecon International GmbH
European Business School
Detecon International ist ein weltweit führendes Unternehmen für integrierte Management- und Technologieberatung entlang der
gesamten Wertschöpfungskette der Kunden.
Detecon International entstand 2002 aus der
Fusion der beiden Beratungshäuser DETECON und Diebold und ist ein Tochterunternehmen der T-Systems.
Die European Business School (EBS) ist
Deutschlands älteste private wissenschaftliche Hochschule mit hervorragendem
nationalen und internationalen Ruf. Im
Bereich Wirtschaftsinformatik bietet sie
praxisnahe Studienangebote (Bachelor-,
Master- und Executive-Programme) und
Forschung zu aktuellen Fragen des strategischen IT-Managements an.
www.detecon.com
www.ebs.edu/iris
Intersystems GmbH
InterSystems ist ein mehr als 30 Jahre
erfolgreicher Softwarehersteller im Bereich
objektorientierte Datenbanken, Kommunikationsserver, Integrationsplattformen und
Lösungen für das Gesundheitswesen.
www.intersystems.de
Corisecio GmbH
CORISECIO ist ein führender Hersteller von
automatisierten Security-Produkten für
SOA-Infrastrukturen. Basierend auf der
eigenen Open Platform sind EnterpriseLösungen für SOA Security und SAP sowie
Mobile Security und Database Encryption
erfolgreich in mehr als 50 Ländern im Einsatz. CORISECIO hat ihren Hauptsitz in
Darmstadt und wird durch Vertriebspartner
weltweit unterstützt.
FZI Forschungszentrum Informatik
Das FZI Forschungszentrum Informatik Karlsruhe hilft – als unabhängige Forschungseinrichtung des Landes Baden-Württemberg – Unternehmen und öffentlichen Einrichtungen, gemeinsam Innovationen zu
entwickeln. Informatik als Schlüssel zu
neuen Technologien steht im Mittelpunkt
von Anwendungsforschung, Entwicklung
und Technologietransfer.
www.fzi.de
www.corisecio.com
123
Die Aktionslinie Hessen-IT
12
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 Informationen und Services zum Online-Markt, zu E- und M-Commerce, zu Softwareund Telekommunikationsanbietern sowie über Telearbeit. Angesprochen
werden auf der einen Seite die fast 10.000 hessischen Unternehmen, die
Produkte oder Dienstleistungen auf dem Informations- und Kommunikationstechnologiemarkt anbieten, auf der anderen Seite die kleinen und
mittleren Anwender-Unternehmen.
Anbieter-Datenbanken erleichtern die Suche nach geeigneten Dienstleistern bei der Durchführung von IT-Projekten. Gleichzeitig fungieren diese
Datenbanken für Anbieter als Informations- und Kommunikationsplattform, auf der sich diese den Anwendern und potenziellen Kunden präsentieren 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-CommerceZentren 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.
124
www.hessen-it.de
Einen Überblick über diese Netzwerke und Treffen sowie Terminankündigungen 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 ausrichtet.
Das Projektteam von Hessen-IT steht Ihnen jederzeit gerne als Ansprechpartner zur Verfügung. Besuchen Sie unsere Website unter
www.hessen-it.de
125
Schriftenreihe Hessen-IT
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)
126
2003
Online-Anbieter in Hessen (Band 2)
2002
E-Shops in Hessen (Band 28)
2000
Der Telekommunikationsmarkt in Hessen (Band 21)
www.hessen-it.de
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 computerimplementierter 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
Schriftenreihe Hessen-IT
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
ISBN 978-3-939358-63-3

Broschüre SOA – Mehr als nur flexible - Hessen-IT

Transcription

Documents pareils

Die Rolle von Stammdaten-Management in einer SOA Die Rolle von

Full Text

Diplomarbeit / Master-Thesis Thema: Analyse von

SOA - Hochschule Furtwangen

CRM - Wolfgang Martin Team

Kosteneffizienz durch Innovation von

RTAPLS 7.2 - Systembeschreibung

Pressemitteilung - LOTTO