Hessen Trade & Invest GmbH - Hessisches Ministerium für … · 2013-06-06 · HA Hessen Agentur GmbH Hessen-IT Abraham-Lincoln-Straße 3 8–42 65189 Wiesbaden Telefon 0611 77 4-

Hessisches Ministerium für Wirtschaft, Verkehr und Landesentwicklung

www.hessen-it.de

Hessen IT

Band 63

SOAMehr als nur flexible Softwarearchitekturen

Benjamin Blau

Tobias Conte

Dr. Julian Eckert

Norbert Eder

Markus Ganß

Dr. Ralf Helbig

Dr. Carsten Holtmann

Dr. Christine Legner

Dr. Wolfgang Martin

Thomas Mironiuk

Dr. Bruno Quint

Dr. Nicolas Repp

Hessisches Ministerium für Wirtschaft,

Verkehr und Landesentwicklung

SOAMehr als nur flexible Softwarearchitekturen

Hessen-IT Band 63

HA Hessen Agentur GmbHHessen-ITAbraham-Lincoln-Straße 38–4265189 Wiesbaden

Telefon 0611 774-8481Telefax 0611 774-8620E-Mail [email protected] www.hessen-it.de

Redaktionsteam: Dr. Matthias DonathChristian FloryWolf-Martin AhrendGabriele Gottschalk

Alle Rechte vorbehalten.Nachdruck, auch auszugsweise, verboten.

© Hessisches Ministerium für Wirtschaft, Verkehr und Landesentwicklung Hessen-ITc/o HA Hessen Agentur GmbHWiesbaden 2010

Layout/Satz: WerbeAtelier Theißen, LohfeldenTitelcollage: WerbeAtelier Theißen unter Verwendungeiner Abbildung von AndyL/istockphotoDruck: Druckerei ausDRUCK, Kassel

ISBN 978-3-939358-63-3

Bibliografische Informationen der Deutschen Bibliothek: Die Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen National -bibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.ddb.de abrufbar.

Liebe Leserinnen und Leser,

Innovationen sind der Motor für unser Wachs tum und unseren

Wohlstand in der Zukunft. Im globalen Wettbewerb müssen die

westlichen Industrieländer ihre Wirtschaftsgüter nicht nur schneller

anbieten, sie müssen auch neuartige, qualitativ hochwertige und

technisch fortschrittliche Angebote entwickeln.

Informations- und Kommunikationstechnologien (IKT) haben dabei für Unternehmen

eine Schlüsselfunktion. Denn sie unterstützen beides: effiziente interne Prozesse und

zukunftsorientierte, IKT-basierte Dienste und Produkte. Voraussetzung hierfür ist der

Einsatz von hoch gradig flexiblen Software- und IKT-Systemen in den Unternehmen.

Diese Flexibilität lässt sich mit so genannten serviceorientierten Architekturen (SOA)

erzielen. Das SOA-Prinzip strukturiert ein Softwaresystem (Architektur) gemäß seiner

einzelnen funktionalen Dienste (Servi ces), welche die IKT für den Geschäftsprozess

erbringt. Durch eine Unterteilung des Softwaresystems in lose gekoppelte Module, die

sich variabel und mehrfach kombinieren lassen, werden dynamisch veränderbare und

vielfältig gestaltbare IKT-Systeme möglich. Entsprechend lassen sich komplexe Soft-

waresysteme nicht nur übersichtlicher gestalten und Unternehmensstrategien agiler

umsetzen – auch neue, innovative Geschäftsmodelle und Geschäftsfelder werden reali-

sierbar. Deswegen sind serviceorientierte Architekturen und Anwendungen zu Leitan-

sätzen in der Softwareentwicklung geworden. Sie nutzen großen Unternehmen und

bieten auch mittleren und kleinen Firmen beträchtliche Chancen.

Die Softwareregion Rhein-Main-Neckar hat sich als „Silicon Valley Europas“ (Truffle-Stu-

die 2010) zu einem Kompetenzzentrum für SOA entwickelt. Mit diesem Leitfaden, der

Beiträge regionaler Experten enthält, möchten wir Ihnen einen praxisnahen Zugang zum

vielschichtigen Thema SOA eröffnen und auf die Stärke des SOA-Standortes Hessen hin-

weisen. Nehmen Sie Kontakt mit den aufgeführten Experten auf oder wenden Sie sich

einfach an das Projektteam von Hessen-IT. Für die serviceorientierten Aktivitäten Ihres

Unternehmens wünsche ich Ihnen viel Erfolg!

Dieter Posch, Hessischer Minister für Wirtschaft, Verkehr und Landesentwicklung

Einleitung ............................................................................................. 1

SOA-Check 2010: Status quo – Trends – Perspektiven ................ 5

1.1 SOA-Grundlagen ................................................................................. 5

1.2 SOA-Vorteile ......................................................................................... 7

1.3 SOA-Marktbefragung .......................................................................... 8

1.4 Ergebnisse .......................................................................................... 10

1.5 Fazit ..................................................................................................... 17

SOA@Work: Mehr Agilität und Effizienz ...................................... 19

2.1 Agile Unternehmen sind die Ziele .................................................. 20

2.2 Flexible Prozesse sind die Lösung .................................................. 21

2.3 BPM und SOA aufeinander abstimmen ......................................... 22

2.4 Effizienz durch Governance ............................................................. 24

2.5 Fazit ..................................................................................................... 25

SOA-Starter Kit: Think big, start small, show quick success ..... 26

3.1 Einsatzbereiche ................................................................................. 26

3.2 Dimensionen und Ziele .................................................................... 28

3.3 Komponenten .................................................................................... 31

3.4 Der erste Service ............................................................................... 33

3.5 Fazit ..................................................................................................... 37

SOA-Kommunikation: „Wie überzeug’ ich meinen Chef?“ ...... 38

4.1 Die optimale Initiative ....................................................................... 38

4.2 Geschäftsanforderungen .................................................................. 42

4.3 Argumentationsstrategie .................................................................. 44

4.4 Vorteile kommunizieren .................................................................... 47

4.5 Fazit ..................................................................................................... 53

SOA-Governance: Warum Investitionen in Menschen

wichtiger sind als in Monitoring-Tools .......................................... 54

5.1 Definition „SOA-Governance“ ......................................................... 55

5.2 Soziale Auswirkungen ....................................................................... 57

5.3 Governance realisieren ..................................................................... 59

5.4 Governance kommunizieren ............................................................ 60

5.5 Fazit ..................................................................................................... 61

1

2

4

3

5

SOA

SOA-Security: Webservices erfordern zusätzliche

Sicherheitsmaßnahmen .................................................................. 62

6.1 Grundlagen ........................................................................................ 62

6.2 Sicherheitsanforderungen ............................................................... 63

6.3 Sicherheitsmechanismen ................................................................. 66

6.4 Methoden der Umsetzung ............................................................... 72

6.5 Fazit ..................................................................................................... 75

SOA goes B2B: Lessons Learned aus der Automobilindustrie .. 76

7.1 SOA und B2B ..................................................................................... 76

7.2 SOA-B2B-Architektur: Öffentliche und interne Sicht .................... 80

7.3 SOA vs. herkömmliche B2B-Integration ......................................... 84

7.4 Reifegrad und Herausforderungen ................................................. 86

7.5 Fazit ..................................................................................................... 88

SOA-Perspektiven: Geschäftsmodelle und Innovationen

für das Internet der Dienste ........................................................... 90

8.1 Internet der Dienste .......................................................................... 90

8.2 Forschungsprojekt TEXO ................................................................. 98

8.3 Marktpotential serviceorientierter IKT .......................................... 100

8.4 Geschäftsmodelle für das Internet der Dienste .......................... 103

8.5 Fazit ................................................................................................... 111

Glossar ............................................................................................. 112

Ihre Partner in Hessen ................................................................... 114

Profile der Unternehmen und Institutionen der Autoren ........ 122

Aktionslinie Hessen-IT ................................................................... 124

Schriftenreihe Hessen-IT ............................................................... 126

7

8

6

9

10

12

11

Die komplette Schriftenreihe finden Sie im Anhang oder im Internet unter www.hessen-it.de(Bestellmöglichkeit und Download als PDF-Datei)

Schriftenreihe Hessen-IT:Neuerscheinungen

Hessen IT

2008

Leitfaden zur Patentierung computer implementierter

Erfindungen (2. aktualisierte Auflage)

Telekommunikationsanbieter in Hessen 2008

2009

Ambient Mobility – Intelligente Produkte und Umgebungen

für mobile Bürger und Unternehmen

Rating für IKT-Unternehmen (2. aktualisierte Auflage, Januar 2009)

2010

Ambient Mobility – Intelligent Products and Environments

for Mobile Citizens and Businesses

Die Gamesbranche – ein ernstzunehmender Wachstumsmarkt

(2. aktualisierte Auflage)

Notleidende Projekte – Eine Hilfestellung für IT-Projekte

in sieben Akten

Satellitennavigation in Hessen – Ideen über All

SOA – Mehr als nur flexible Softwarearchitekturen

Einleitung

Am 12. April 1996 hat das Marktforschungsunternehmen Gartner in

zwei „Research Notes“ den Begriff der „serviceorientierten Architektur“

(Service Oriented Architecture) erstmals verwendet und damit eine neue

Sichtweise geprägt. Habe man früher – so Gartner in einem Vergleich zur

Luftfahrtindustrie – geschaut, welche Flugzeugarten gebaut werden könn-

ten, betrachte man nun, welche sinnvollen Transportdienste (transporta-

tion services) man anbieten kann. Nicht mehr die Technologie steht im

Vordergrund, sondern das Geschäft, in dessen Dienst sie steht. Um eine

größere Flexibilität zu erreichen, wird das Geschäft in einzelne Teilpro-

zesse aufgeteilt und diesen werden entsprechende IT-Dienste (Services)

mit dahinter liegenden Backend-Systemen zugeordnet. Die einzelnen

Services sind über standardisierte Schnittstellen lose miteinander gekop-

pelt, so dass sie flexibel kombinierbar und wieder verwendbar sind und

agile Geschäfte ermöglichen.

3-Ebenen-Modell einer serviceorientierten Architektur

Heute, 14 Jahre nach seiner Einführung, hat das SOA-Prinzip nichts von

seiner Aktualität verloren. Im Gegenteil, je größer der Wettbewerbsdruck,

desto wichtiger werden flexible Geschäfts- und IKT-Prozesse sowie inno-

vative IKT-basierte Dienste und Produkte. Unternehmen mit einer service-

orientierten Architektur können nicht nur ihre internen Services flexibel

miteinander kombinieren. Sie können auch externe Services besser an-

und einbinden und damit die Vorteile von Software-as-a-Service (SaaS)

Prozesse

Services

Externer Service-Anbieter Backend-

Systeme

1

www.hessen-it.de

besser nutzen. Beim SaaS-Ansatz wird Software als mietbarer Dienst über

das Netz bezogen bzw. betrieben. Unternehmen können sich damit

besser auf Ihre Kernkompetenzen konzentrieren und andere Prozesse an

Dienstleister bzw. Services übertragen, die darauf spezialisiert sind.

Wertschöpfung entsteht noch stärker im Verbund.

Diese Strategie ist eng mit dem Ziel des BMBF-Spitzenclusters „Software -

innovationen für das digitale Unternehmen“ mit Sitz in Darmstadt verknüpft.

Das Software-Cluster möchte Unternehmen durch den Einsatz von so

genannter emergenter Software die Entwicklung zu vollständig digitalen

Unternehmen ermöglichen. Digitale Unternehmen arbeiten in hochflexib -

len, internetbasierten Unternehmensnetzen und richten ihre Geschäfts -

modelle und -prozesse dynamisch darauf aus. Alle Daten über Prozesse,

Betriebsmittel und Ressourcen in der realen Unternehmenswelt sollen

ihnen jederzeit in genauer zeitlicher und räumlicher Auflösung zur Planung,

Steuerung und Optimierung zur Verfügung stehen. Das kann nur erreicht

werden, wenn emergente Software eine Vielzahl von Softwarekomponen-

ten unterschiedlicher Hersteller dynamisch und flexibel kombinieren kann.

Auch das so genannte Internet der Dienste (Internet of Services) setzt bei

serviceorientierten Architekturen und Anwendungen an. Hierbei handelt

es sich um die Weiterentwicklung des bestehenden Internets zu einem

Netzwerk, dass nicht nur allgemeine Informationen, sondern auch perso-

nen- und situationsbezogene Informationen, also Dienstleistungen,

erbringt. Technisch baut das Internet der Dienste auf Services auf, die –

obwohl sie zum Teil von unterschiedlichen Anbietern stammen – miteinan-

der kombiniert und zu komplexeren Services zusammengefügt werden

können. Im Rahmen des Leitprogramms in der IKT-Förderung des Bun-

desministeriums für Wirtschaft und Technologie (BMWi) THESEUS soll das

Projekt TEXO, an dem eine Reihe von hessischen Partnern beteiligt sind,

genau in diese Richtung führen (siehe S. 98).

2

Einleitung

Angesichts all dieser Entwicklungen verwundert es nicht, dass der Markt

von und um serviceorientierte(n) Architekturen ein beständig signifikantes

Wachstum vollzieht. Eine Studie der Analysten- und Beratungsgesellschaft

Pierre Audin Consultants (PAC) vom 30. Juli 2009 – unter Mitwirkung von

IDATE, Fraunhofer ISI und London Economics im Auftrag der Europäi-

schen Kommission – prognostiziert ein Wachstum des europäischen SOA-

Marktes (EU 27) von 38 % in 2010, 31 % in 2011 und 25 % in 2012.

Prognose SOA-Marktentwicklung in EU 27

Quelle: PAC, D2 – The European Software Industry, Economic and Social Impact

of Software & Software-Based Services, 30. Juli 2009

Jährlicher SOA-Markt (Nominalwert auf Basis 2008)

Jahr

EU 27

Jahr

EU 27

2007

2057

2007

–

2008

3534

2008

71,8 %

2009

4838

2009

36,9 %

2010

6678

2010

38,1 %

2011

8808

2011

31,9 %

2012

11002

2012

24,9 %

Jährliches Marktwachstum

Mio. Euro

2007

0

2000

4000

6000

8000

10000

12000

2008 2009 2010 2011 2012

Lizenzen und Wartung IT-Dienstleistungen

3

www.hessen-it.de

In dieser Broschüre werden einzelne wichtige Aspekte des Wachstums-

marktes serviceorientierter Architekturen von regionalen Experten erläu-

tert, um Entwicklungen in diesem Bereich begleitend voran zu treiben.

Zunächst werden wesentliche Grundlagen und Vorteile des SOA-Ansatzes

vermittelt, verbunden mit Umfrageergebnissen und Empfehlungen zum

SOA-Einsatz. Der zweite Beitrag stellt umfassend das SOA-Potenzial für

mehr Agilität und Effizienz heraus, bevor im dritten Beitrag Ansatzpunkte

für neue SOA-Initiativen geschildert werden. Wie das dafür benötigte

Budget betriebsintern verargumentiert und erworben werden kann, zeigt

Beitrag vier. SOA-Governance und SOA-Security sind Aspekte, die für den

Erfolg von SOA-Projekten von zentraler Bedeutung sind. Sie werden in

den Beiträgen 5 und 6 aufgegriffen. Mit Beitrag 7 folgt ein Praxiseinblick,

der zeigt, dass SOA auch heute schon überbetriebliche Prozesse in Unter-

nehmensnetzwerken optimieren kann. Der achte und letzte Beitrag gibt

schließlich einen Ausblick auf aktuelle und künftige Entwicklungen, die

durch den Einsatz serviceorientierter IKT realisiert werden.

4

Einleitung

SOA-Check 2010: Status quo – Trends – Perspektiven

Dr. Julian Eckert, SOA Competence Center im httc e.V.

Dr. Nicolas Repp, SOA Competence Center im httc e.V. (ehem.)

Dr. Wolfgang Martin, Wolfgang Martin Team

1.1 SOA-Grundlagen

Unter dem Begriff der „serviceorientierten Architektur“ (SOA) versteht

man ein Architekturparadigma, welches auf Services als Grundbausteinen

basiert. Unter einem Service (Dienst) wird hierbei eine abgeschlossene,

unabhängige funktionale Einheit verstanden, die eine klar definierte

Geschäftsfunktionalität anbietet. Ein Service kann vollständig manuell

erbracht werden, aber auch als funktionale Einheit automatisiert in Form

von Software realisiert werden. Im weiteren Verlauf beschränken wir uns

auf die Anwendung einer SOA bei komplexen Softwaresystemen.

Anders als klassische Softwarearchitekturen, die eine komplette System-

struktur beschreiben, beschränkt sich eine SOA auf den Bereich der

Bereitstellung fachlicher Dienste und Funktionalitäten in Form von

Services – vornehmlich zum Zwecke der Anwendungsintegration und der

Einbindung von externen Services.

Charakterisiert wird eine SOA typischerweise durch drei Rollen:

1. Service-Anbieter

Als Service-Anbieter bezeichnet man in diesem Zusammenhang das Unter-

nehmen oder die Organisationseinheit, welche(s) einen oder mehrere Ser-

vices bereitstellt. Services können sowohl innerhalb eines Unternehmens

oder auch über Unternehmensgrenzen hinweg angeboten werden.

1

5

www.hessen-it.de

2. Service-Nutzer

Der Nutzer der Services wird Service-Nutzer genannt.

3. Intermediär

Optional ist die Rolle des Intermediärs, welcher auch als „Service-Broker“

bezeichnet wird. Ein Intermediär bietet Services verschiedener Anbieter

an und kann darüber hinaus zusätzliche Funktionen, wie beispielsweise

die Abrechnung der Service-Nutzung, übernehmen.

Die Kommunikation zwischen den beteiligten Akteuren (Anbieter, Nutzer

und Intermediär) basiert auf dem Austausch von Nachrichten. Der Anbie-

ter stellt die Implementierung eines Dienstes zur Verfügung und ver -

öffentlicht dessen Beschreibung (z. B. Funktion, Leistungsmerkmale) sowie

eine Schnittstellenbeschreibung in einem Verzeichnis, das von Kunden

durchsucht werden kann. Aufgrund der Beschreibungen ist der Kunde in

der Lage, einen passenden Service auszusuchen, aufzurufen und zu

nutzen. Anbieter und Nutzer können auch miteinander in Kontakt treten.

Zur technischen Realisierung von Softwaresystemen auf Basis des SOA-

Paradigmas haben Web Services an Bedeutung gewonnen. Unter einem

Web Service versteht man hier lose gekoppelte, wieder verwendbare

Softwarekomponenten, die unter Verwendung von Internetstandards

aufgerufen werden können und über den Austausch von XML-basierten

Nachrichten miteinander kommunizieren.

Kernidee des Service-Prinzips ist die lose Kopplung von Services an die

sie nutzenden Applikationen. Die Kopplung im Sinne des Software-

Engine ering ist ein Maß für die Abhängigkeiten der beteiligten Kompo-

nenten. Das Prinzip der losen Kopplung meint, dass der Abhängigkeits-

grad der beteiligten Komponenten relativ gering ist.

6


1.2 SOA-Vorteile

Die lose Kopplung der Komponenten erzeugt den Vorteil, dass Services

sehr leicht durch andere Services zur Laufzeit ersetzt werden können, was

die Flexibilität und Agilität der Anwendungen verbessert. Unterstützt wird

dieser Aspekt durch die Ortstransparenz von Services: Verzeichnisdienste

machen den Speicherort transparent. So können Services unabhängig

von ihrem tatsächlichen Ausführungsort dynamisch gefunden und genutzt

werden. Gewissermaßen wird er damit virtualisiert. Was die so genannte

Virtualisierung für die Hardware bedeutet, ist SOA für die Software.

Ein weiterer Vorteil der serviceorientierten Architektur besteht darin, dass

durch das Beziehen einzelner Prozessbausteine von externen Anbietern

eine Kostenreduktion erreicht werden kann, während die Steuerung des

Prozesses im Unternehmen verbleibt. Eine SOA ermöglicht ein Höchst-

maß an Flexibilität und stellt gleichzeitig sicher, dass die Abhängigkeit von

externen Service-Anbietern auf ein Minimum begrenzt wird. Sie ist weit-

aus flexibler als traditionelles Business Process Outsourcing (BPO), das auf

die Auslagerung eines vollständigen Geschäftsprozesses an externe

Dienstleister abzielt. Denn eine SOA ermöglicht ein servicebasiertes BPO,

d. h. Services können dynamisch zur Laufzeit auch von externen Providern

bezogen werden. SOA passt bestens zu SaaS (Software-as-a-Service). SOA

ist die Architektur, SaaS ein Liefermodell für externe und interne Services.

Während mit dem traditionellen BPO nur strategische Entscheidungen

mit Langzeitwirkung möglich waren, können mit dem SOA-Paradigma

auch operative Outsourcing-Entscheidungen getroffen werden, die nur

von kurzer Dauer sind.

7

www.hessen-it.de

1.3 SOA-Marktbefragung

Für den SOA Check 2010 wurden 64 Personen in Unternehmen aus

Deutschland, der Schweiz und Österreich befragt, die sich mit dem

Thema SOA in den jeweiligen Unternehmen beschäftigen. Die Zielset-

zung der Befragung war, die Entwicklung von SOA im Markt gegenüber

den Vorjahren zu dokumentieren. Ferner sollte bei Unternehmen, die eine

SOA-Einführung planen, herausgefunden werden, was deren Ziele und

Erwartungen sind, wie deren Planung für die SOA-Einführung aussieht

und welche Änderungen sich gegenüber den Vorjahren ergeben haben.

Die Zusammensetzung der Stichprobe der Befragung entspricht derjeni-

gen der beiden Vorjahre, womit eine Vergleichbarkeit hergestellt wurde.

36 % der Befragten kommen aus Unternehmen mit bis zu 100 Millionen

Euro Umsatz, 28 % der Befragten aus Unternehmen mit 100 Millionen bis

1 Milliarde Euro Umsatz und 36 % aus Unternehmen mit mehr als einer

Milliarde Euro Umsatz. Aufgeschlüsselt nach der Anzahl der Mitarbeiter

stammen 19 % der Befragten aus Unternehmen mit weniger als 100 Mit -

arbeitern, 23% aus Unternehmen mit 100 bis 1000 Mitarbeitern und 58 %

aus Unternehmen mit mehr als 1000 Mitarbeitern. Das Profil der Befragung

unterstreicht wie in 2009, 2008 und 2007 die Vermutung, dass das Thema

SOA zunächst einmal die großen Unternehmen angeht. Der Anteil der

Befragten aus mittelständischen Unternehmen in 2010 zeigt aber wie

bereits in den beiden Vorjahren, dass SOA auch im Mittelstand ein Thema

ist.

8


Die Befragung erfolgte sowohl online unter www.soa-check.eu als auch per

Fragebogen, wobei die Befragung anonymisiert durchgeführt wurde. Um

eine hohe Datenqualität zu gewährleisten, wurden fehlerhafte oder nicht

vollständig ausgefüllte Fragebögen nicht in die Auswertung einbezogen.

Aufgrund der relativ kleinen Stichprobe erhebt diese Marktbefragung

keineswegs den Anspruch repräsentativ zu sein. Die Ergebnisse sind als

ein Trend zu interpretieren, können aber als Anhaltspunkte für eigene

Entscheidungen und Planungen in Sachen SOA genutzt werden.

SOA Check – die Befragung

Online-basierte Befragung im Zeitraum von 02.11.2009 – 08.02.2010

Stichprobe: 64 Personen (© 2010 S.A.R.L. Martin)

Umsatz36% < 100 Mio. €

28% = 100–1.000 Mio. €

36% > 1.000 Mio. €

Mitarbeiter19% < 100

23% = 100–1.000

58% > 1.000

Finanzdienstleister 23%Banken & Finanzen

Dienstleister (ohne Finanzdienstleister) 52%Informationstechnologie, Unternehmensberatung, Logistik, Transport, Medien, Verlagswesen, Unterhaltung, Energieversorgung, Telekommunikation

Automobilbau,Industrie 16 %

Handel3%

Maschinenbau,Chemie, Öl, Gas,Pharma

Öffentliche Verwaltung Öffentliche Verwaltung 3 %

Sonstige3%

und Gesundheitswesen

9

www.hessen-it.de

1.4 Ergebnisse

SOA-Marktentwicklung

Im Folgenden werden das Marktverständnis, die Marktreife und die Markt-

motivation einer SOA erläutert. Das Verständnis einer serviceorientierten

Architektur ähnelt demjenigen der Vorjahre. 69 % (67 % in 2009, 66% in

2008) der Befragten verstehen eine SOA als Unternehmens- oder IT-Archi-

tektur, während 28 % (31 % in 2009 und 28% in 2008) SOA ausschließlich

als Technologie oder Produkte ansehen. SOA wird von insgesamt 71 % als

reines IT-Thema betrachtet (74% in 2009). Die Bedeutung von SOA inner-

halb eines Unternehmens ist für 61% (53 % in 2009 und 52 % in 2008) der

Befragten sehr groß oder mindestens von großer Bedeutung. 26 % (33 % in

2009 und 34 % in 2008) sehen eine mittlere Bedeutung des Themas für ihr

Unternehmen.

Die zunehmende Marktreife wird durch die Antworten auf die Frage

bestätigt, wie lange sich ein Unternehmen bereits mit dem Thema SOA

beschäftigt. 48 % (38 % in 2009 und 33 % in 2008) der Befragten geben an,

dass sie sich seit über zwei Jahren mit dem Thema SOA befassen. Dabei

haben unabhängig von der Unternehmensgröße 52% aller befragten

Unternehmen mehr als 4 Mitarbeiter, die sich mit dem Thema SOA

beschäftigen. In 2009 waren das nur 42%. Entsprechend hat die Anzahl

kleinerer Teams mit bis zu einer Person von 25% in 2009 auf jetzt 18%

abgenommen.

Warum beschäftigen sich Unternehmen überhaupt mit dem Thema, was

sind die Treiber, die strategischen Ziele? Schwerpunkte der Motivation

von Unternehmen bilden die angestrebte höhere Flexibilität mit 29 %, die

Optimierung der Prozesse mit 21 %, eine Verkürzung der Time-to-Market

mit 16 %, die Steigerung des Innovationsgrades mit 10 %, die Steigerung

der Kundenzufriedenheit mit 5%, die Senkung der Kosten mit 5% sowie

die Steigerung der Produktivität mit 2%. Der Einsatz von SOA in Unterneh-

men ist gegenüber dem Vorjahr gestiegen. 63 % (47 % in 2009) setzen

eine SOA schon ein, 31 % (37 % in 2009) sind in der Planung und nur noch

6% (16% in 2009) bleibt ohne SOA-Einsatzplanung.

10


Prozentualer Anteil der Befragten in den Jahren 2008 bis 2010,

für die die Bedeutung von SOA innerhalb des Unternehmens von

sehr großer oder großer Bedeutung ist. (© 2010 S.A.R.L. Martin)

20080

10

20

30

40

50

60

70

2009 2010

52% 53%

62%

11

www.hessen-it.de

SOA-Einsatz

In diesem Abschnitt werden Möglichkeiten und Bedingungen für den Ein-

satz einer SOA im Unternehmen analysiert. Hierzu wurden nur Teilnehmer

befragt, die eine SOA bereits einsetzen oder ihren Einsatz planen. Die

Frage nach den Unternehmensbereichen mit der höchsten Bedeutung für

SOA bestätigt die Ergebnisse des Vorjahres. Mit 25% (21 und 19% in den

Vorjahren) wird die IT als Hauptbereich für den SOA-Einsatz identifiziert.

Das unterstreicht die IT-Lastigkeit in der Wahrnehmung des Themas SOA.

Das Thema Produktion folgt hiernach mit 11% (7 % in 2009, 6% in den

Vorjahren), und löst die zweiten Plätze des Vorjahres Vertrieb (10%), Kun-

denservice (7%) und Einkauf (7%) ab.

Der Einsatz von SOA in unternehmensübergreifenden Prozessen ist

besonders im Bereich der Kollaboration beim Ein- und Verkauf ausge-

prägt. Die Kollaboration mit Kunden wird mit 36% (nach 29% in 2009,

30% in 2008 und 32% in 2007) bewertet, diejenige mit Lieferanten mit

23% (nach 23% in 2009, 24% in 2008 und 26% in 2007), die Kollabora-

tion mit der Öffentlichkeit mit 13% (nach 13% in 2009 und 2008 sowie

11% in 2007) und mit sonstigen Händlern mit 10% (nach 14% in 2009,

11% in 2008 und 19% in 2007).

12


Auch im SOA Check 2010 zeigt sich der Trend , SOA stark IT-lastig zu

beschreiben. Mit rund 25% (21% in 2009 und 19% in den Vorjahren)

wird die IT als Hauptbereich für den SOA-Einsatz identifiziert, gefolgt

von den Bereichen Produktion, Vertrieb und Logistik.

Wird in Ihrem Unternehmen eine SOA eingesetzt?

(© 2010 S.A.R.L. Martin)

31 % 36 % 47 %63 %

42 %48 %

37 %31 %

27 %16 % 16 %

6 %

0 %

10 %

20 %

30 %

40 %

50 %

60 %

70 %

80 %

90 %

100 %

2007 2008 2009 2010

ja nein, aber Einsatz geplant nein, kein Einsatz geplant

13

www.hessen-it.de

SOA-Governance

Der Governance, d. h. der Kontrolle und Steuerung, servicebasierter Sys-

teme kommt in der Praxis eine immer größere Bedeutung zu. Die Fragen

wurden nur von Teilnehmern der Studie beantwortet, die bereits eine

SOA einsetzen oder ihren Einsatz planen. Im Vergleich zu den Ergebnis-

sen des Vorjahres sind die aktuellen Ergebnisse positiv zu bewerten. 37 %

(nach nur 28% in 2009 und 20 % in 2008) beschäftigen sich mit dem

Thema SOA-Governance bzw. nutzen diese bereits. Nur noch 41 % (nach

66 % in 2009 und 55 % in 2008) geben an, dass eine SOA-Governance in

Planung sei. 22 % sagen allerdings (nach 6 % in 2009 und 24 % in 2008),

dass eine SOA-Governance nicht geplant ist. Bei der eingesetzten Metho-

dologie zur SOA-Governance führen die „eigenen SOA-Governance-

Methoden“ mit 26 % vor ITIL (IT Infrastructure Library) mit 21 % und vor

„allgemeinen modifizierten IT-Governance-Methoden“ mit 12 %. COBIT

(Control Objec tives for Information and Related Technology) kam nur auf

5 %. Der Einsatz von Service Level Agreements (SLAs) zur vertraglichen

Definition von Anforderungen an Services wird nur von 21 % der Befrag-

ten nicht eingesetzt (nach 20 % in 2009). Ebenfalls erfreulich ist die Aus-

sage, dass bereits 48 % der Befragten den Wiederverwendungsgrad von

Services messen. 35 % der Befragten haben bereits eine Referenzarchitek-

tur im Sinne einer globalen Architekturrichtlinie erstellt.

14


© remirath

SOA-Projekte

Auch die Fragen zu bestehenden SOA-Projekten und ihrer Projektstruktur

wurden nur von Teilnehmern beantwortet, die bereits eine SOA einsetzen

oder ihren Einsatz planen. Die durchschnittliche Zielerreichung der im

SOA-Projekt definierten Ziele liegt in der aktuellen Befragung bei rund

76%. Das ist an sich kein gutes Ergebnis – im Vergleich zu den Vorjahren

ist aber eine positive Entwicklung feststellbar. 14 % der befragten Unter-

nehmen haben bereits über 10 SOA-basierte Prozesse im Einsatz und

24% bereits mehr als 40 Services. Der hauptverantwortliche Projektleiter

stammt bei 48 % der Befragten immer noch aus dem IT-Bereich (2009:

54%). Der IT-Bereich bleibt der Treiber und Macher in Sachen SOA. Deut-

lich zugelegt haben die internen Fachanwender /Berater, die, nach nur

14% in 2009, bei 26 % der Befragten die Projektleitung innehatten. Das

spricht für einen reifenden Markt. Enttäuschend ist aber der Einfluss auf

Seiten der Organisation, denn Prozess- und Service-Denken erfordern

auch neue Rollen und neue Verantwortlichkeiten, sowohl in den IT- als

auch in den Fachabteilungen. In 46 % der Fälle hat die SOA-Initiative

innerhalb der IT-Abteilung keine neuen Arbeitsbereiche hervorgebracht.

Ähnlich unverändert zeigen sich die Fachabteilungen: in 54% der Fälle

sind hier keine zusätzlichen Rollen und Verantwortlichkeiten entstanden.

15

www.hessen-it.de

© heizfrosch – istockphoto © yurok aleksandrovich – istockphoto

SOA-Organisation

Welche Organisationseinheiten setzen eine SOA um? In 48% (44% in

2009 und 51% in 2008) der Fälle übernimmt dies die interne IT-Abteilung,

in 11% (14% in 2009 und 0% in 2008) sind es Softwareanbieter. SOA wird

in 20% der Fälle als reines IT-Projekt implementiert. In 26 % der Fälle

stimmt sich die IT-Abteilung zusätzlich mit einer Fachabteilung ab, ohne

aber gemeinsam am Thema zu arbeiten.

Beim Sponsorship setzt sich hingegen der Trend zum Besseren fort. Es

gibt eine leichte Steigerung beim CPO (Chief Process Officer) von 5%

(2007 und 2008) über 8% (2009) auf 9% und eine Steigerung bei der

Geschäftsführung von 13% über 16% und 26% auf jetzt 31%. Der Anteil

von CIOs (Chief Information Officer) als Sponsor hat sich stabilisiert bei

34% von 58% (2007) über 40% (2008) und 30% (2009). Die Zahl der

„nicht klar geregelten“ Sponsorships hat zum ersten Male abgenommen

von 21% über 23% und 26% auf jetzt nur noch 14%.

Wer finanziert SOA-Initiativen? Verteilung der Sponsoren (© 2010 S.A.R.L. Martin)

Chief Information Officer (CIO)30%

5%5%

8%

26%

26%

Geschäftsführung

Verantwortlichkeit ist nicht klar geregelt

Chief Process Officer (CPO)

Chief Technology Officer (CTO)

Fachabteilung

16


1.5 Fazit

Der SOA Check 2010 unterstreicht deutlich: Das Thema „serviceorien-

tierte Architekturen“ kommt im deutschsprachigen Markt gut an und gut

voran. Die Unternehmen haben in den letzten Jahren erhebliche Fort-

schritte gemacht. Der Einsatz von SOA in den befragten Unternehmen ist

gegenüber 2009 gestiegen. 63 % (47 % in 2009) setzen eine SOA schon

ein, 31 % (37 % in 2009) sind in der Planung und nur ein Rest von 6 %

bleibt ohne SOA-Einsatzplanung.

Das Thema SOA bleibt bei den meisten Unternehmen also gesetzt und

man schreitet in der Umsetzung weiter fort. 9 % der befragten Unterneh-

men gaben an, dass sie sich bereits in der Endphase der Umsetzung einer

SOA befinden und 52 % sehen sich mitten auf dem Weg. 48 % beschäfti-

gen sich seit über zwei Jahren mit SOA. 14 % der Unternehmen, die SOA

betreiben, haben bereits mehr als 10 SOA-basierte Prozesse und über

24 % dieser Unternehmen haben sogar schon mehr als 40 Services im Ein-

satz.

Die Einschätzung der Bedeutung einer SOA ist im deutschsprachigen

Raum nicht mehr vom Hype gekennzeichnet. Sie ist nun realistisch, bleibt

aber immer noch zu IT-lastig. Durch diese IT-geprägte Sicht wird leider der

Blick auf weitergehende SOA-Potentiale für Themen wie beispielsweise

Compliance und Risiko-Management verstellt (siehe hierzu auch Kapitel

4.4, S. 47ff., in dem erläutert wird, dass der volle Nutzen von SOA erst in

einer IT-übergreifenden Betrachtung deutlich wird). Der Nutzen einer

SOA wird in 2010 ähnlich bewertet wie in den beiden Vorjahren: höhere

Flexibilität (29 %), Optimierung der Prozesse (21 %), Time-to-Market (16 %),

Steigerung des Innovationsgrades (10 %), Steigerung der Kundenzufrie-

denheit (5%) und Senkung der Kosten (5%) spielen die wichtigsten

Rollen. Betrachtet man die Anwendungen, wird schnell klar, dass der

Top-Down-Ansatz (SOA-basierte Geschäftsprozesse) weiter auf dem

Vormarsch ist. BPM ist der Business Case für SOA, SOA ist „nur“ die Infra-

struktur dazu.

17

www.hessen-it.de

SOA-Governance ist als Thema angekommen und wird nun endlich ange-

gangen. Hier gab es einen deutlichen Fortschritt gegenüber den beiden

Vorjahren: 37 % der Befragten gaben an bereits eine SOA-Governance

umgesetzt zu haben (gegenüber 28% und 20 %). Auch die Bedeutung

von Service Level Agreements wird zunehmend besser verstanden: Nur

noch 21 % der Befragten verwenden keine SLAs. Der Methoden- und

Werkzeugeinsatz kommt auch voran, aber das Schaffen neuer Rollen und

Arbeitsbereiche setzt erst sehr zögerlich in den IT- und Fachbereichen ein.

Die Zielerreichung bei SOA-Projekten hat zugenommen. Durchschnittlich

werden 76 % der Ziele erreicht. Der Treiber für SOA ist immer noch die

IT-Abteilung. In 48 % der Fälle kommt der Projektleiter aus dem IT-Bereich,

in 44 % der Fälle wird die Implementierung ausschließlich durch die

interne IT-Abteilung gemacht. Auch wenn diese Anteile noch verhältnis-

mäßig hoch erscheinen, ist der Trend hin zu einer geringeren IT-Bedeu-

tung des Themas SOA über die letzten Jahre erkennbar. Das Einbeziehen

der Fachabteilungen in die SOA-Projekte ist bei weitem nicht ausrei-

chend: 20 % der SOA-Projekte sind reine IT-Projekte. Hier liegt ein großes

Verbesserungspotential, das man im Zuge des Fokus auf SOA-Gover-

nance angehen kann.

Der SOA Check 2010 zeigt, dass sich der in 2009 analysierte Trend

auch in 2010 fortsetzt. Das Thema SOA ist bei den Unternehmen

gesetzt und wurde mittlerweile in den Standard-Lösungskatalog

der Unternehmen übernommen. Den „Hype“ der Vorjahre konnte

das SOA-Paradigma ablegen – aus SOA ist ein reifes Architektur -

paradigma geworden, welches in einer Vielzahl von Anwendungen

zum Tragen kommt.

18


SOA@Work: Mehr Agilität und Effizienz

Norbert Eder, Software AG

Das Internet ist ein prägender Faktor unserer Zeit. Die Welt entwickelt sich

zur Netzgesellschaft und erhöht als Webciety unseren Lebensstandard.

Die Informations- und Kommunikationstechnologie (IKT)-Branche hat mitt-

lerweile einen Anteil am deutschen Bruttoinlandsprodukt von rund 6 Pro-

zent und bietet 750000 Arbeitsplätze. Dazu kommen die Wertschöpfung

und die Arbeitsplätze in den Anwender branchen: z.B. in Banken und Ver-

sicherungen, in der öffentlichen Hand und der Industrie.

Die Digitalisierung der Wirtschaft hat viele Prozesse dramatisch schneller,

billiger und effizienter gemacht und unzählige neue Produkte und Dienst-

leistungen geschaffen. Hinter diesen digitalen Transaktionen und der

digital erhöhten Produktivität steckt Technologie. Erst durch Technologie

wird die digitale Gesellschaft überhaupt möglich.

In der Informationstechnologie (IT) stehen wir vor einem Paradigmen -

wandel, wie er nur einmal in zehn Jahren stattfindet: von den Anwen-

dungs-Silos hin zur Kollaboration und Flexibilität von IT-Systemen. Diese

innovativen Technologien sind der Motor für die Weiterentwicklung des

Webs und der Wertetreiber der Webciety.

2

19

www.hessen-it.de

© P

erlA

lexa

nder

–is

tock

ph

oto

2.1 Agile Unternehmen sind die Ziele

Im 21. Jahrhundert agieren Unternehmen in einem rauen Geschäftsklima.

Sie müssen sich dem Druck durch scharfen Wettbewerb, zunehmende

Globalisierung und Konsolidierung stellen und auf neue Beziehungs -

muster reagieren, wie etwa Co-opetition, also in einer Firma gleichzeitig

einen Partner und Konkurrenten zu haben. Um diese Herausforderungen

meistern zu können, ist ein Umdenken nötig. Eine hohe Innovations- und

Reaktionsfähigkeit zur langfristigen Generierung von Erträgen ist das

Gebot der Stunde. Dafür ist agiles, flexibles Handeln gefragt. Diese An -

forderungen an das Unternehmen sind in den Geschäftsprozessen abge-

bildet, und die werden nun hinterfragt, neu gestaltet oder optimiert. Tech-

nologien sollen diese Anstrengungen unterstützen.

Geschäftsabläufe, ganz gleich, ob innerhalb eines Unternehmens oder

über Betriebsgrenzen hinweg, müssen transparent, messbar und nachvoll-

ziehbar werden. Dies ist die Voraussetzung für ein agiles, flexibles Unter-

nehmen. Eine serviceorientierte Architektur bildet eine ideale Grundlage

für die durchgängige Prozessgestaltung und ein umfassendes Prozess -

management.

In diesem Umfeld vertrauen Unternehmen heute zunehmend auf das so

genannte Business Process Management (BPM). Eine Studie der Software

AG hat herausgefunden, dass jedes fünfte deutsche Unternehmen der

IT-gestützten Verwaltung von Geschäftsprozessen eine hohe Priorität

einräumt. Das Managementkonzept BPM etabliert eine prozesszentrische

Sichtweise auf das Geschäft und stellt das Messen der Leistung in den

Mittelpunkt. Es umfasst zudem Methoden, Werkzeuge und Technologien,

die verwendet werden, um Betriebsabläufe zu entwerfen, auszuführen, zu

analysieren und zu kontrollieren. Technologien für Prozessmanagement

(BPM-Systeme) müssen auch die Änderung und Optimierung der

Geschäftsabläufe unterstützen, denn Wettbewerbsvorteile entstehen nur

dann, wenn die Prozesse auch fortlaufend an neue Anforderungen ange-

passt werden. Dabei hat sich gezeigt, dass schnelle Änderungen nur

schwer möglich sind, solange die Prozesse in herkömmliche IT-Anwen-

dungen eingebettet sind.

20


2.2 Flexible Prozesse sind die Lösung

Die Lösung für solche Probleme besteht in einer gesteigerten Flexibilität:

Systeme zur Prozessautomatisierung auf der Basis einer serviceorientier-

ten Architektur (SOA) bieten einen Ausweg, indem sie die Prozessschicht

von den darunter liegenden Anwendungen und der Infrastruktur trennen,

so dass die Geschäftsanwender ihre Prozesse kontrollieren und direkt

ändern können.

Statt fest codierter, starrer Prozessabläufe setzen diese Systeme auf das

Prinzip der Komposition von IT-Fähigkeiten und Informationen, auch als

„Services“ oder „Dienste“ bekannt, um die benötigte Flexibilität zu errei-

chen. Die Verantwortlichen in den Unternehmen erkennen zunehmend

die Vorteile einer SOA. Denn 60 Prozent der befragten Firmen verwenden

bereits eine serviceorientierte Architektur als Grundlage für BPM, wie die

Umfrage der Software AG ergab.

Serviceorientierte Architekturen gelten als das herausragende Gestal-

tungsprinzip zeitgemäßer Softwarelandschaften. Sie bieten eine bessere

Integration auf der Basis von Standards mit verteilten, lose gekoppelten

und nach Bedarf mehrfach verwendbaren Komponenten, welche über

Services miteinander interagieren.

SOA und BPM bilden komplementäre Aspekte, die für eine flexible Unter-

nehmens-IT notwendig sind. Während eine SOA die technologische

Grundlage für das BPM und die Governance bildet (siehe 2.4), liefert BPM

als Geschäftsprozessmanagement den fachlichen Rahmen für die Umset-

zung der Services – abteilungsübergreifend und über Wertschöpfungsket-

ten hinweg. Auch die Geschäftsprozessregeln lassen sich in einer SOA-

Umgebung als technische Services bzw. Web Services bereitstellen und

somit an verschiedenen Stellen im Prozessablauf wiederverwenden. Im

Rahmen von BPM stellt die Fachabteilung Komponenten zu einer Ablauf-

kette zusammen, die dann in der SOA technisch über den Enterprise

Service Bus abgebildet wird.

21

www.hessen-it.de

2.3 BPM und SOA aufeinander abstimmen

Obwohl sich SOA und BPM ergänzen, müssen die Managementaufgaben

und -prinzipien des BPM mit den technischen Prinzipien der SOA abge-

stimmt werden. Dazu gehören die Konzeption einer Architektur in Form

von strategischen Zielen und entsprechenden Prozessen, die Model -

lierung dieser Prozesse als IT-Komponenten und das Aufsetzen einer

Governance inklusive der Definition von Rollen und Verantwortlichkeiten.

Die erste erfolgskritische Aufgabe besteht darin, die für die definierten

Geschäftsziele richtigen Prozesse festzulegen. In einer SOA sind sie der

Ausgangspunkt dafür, Services wiederverwendbar zu machen. Praktiker

wissen: Gerade die Phase des Identifizierens und Modellierens von

Prozessen, die automatisiert und ins Geschäftsprozess-Management ein-

bezogen werden sollen, ist schwierig, weil sie eine enge Zusammenarbeit

zwischen den Fachanwendern, Geschäftsanalysten und der IT-Abteilung

erfordert. Für diese Kollaboration muss eine einheitliche IT-unterstützte

Plattform vorhanden sein, auf der alle Beteiligten miteinander am Design

oder Re-Design von Geschäftsprozessen arbeiten können. Prozessexper-

ten, Geschäftsanalysten und IT-Entwickler sind dann in der Lage, sich wie

in einem virtuellen Meeting über die Prozesse zu einigen, anstatt wie

früher das Design auf dem Papier zu dokumentieren und der IT-Abteilung

zur Umsetzung zu übergeben. Der Vorteil einer digitalen Plattform besteht

darin, dass die Beteiligten den Prozess gleichzeitig aus ihrer jeweiligen

Perspektive sehen können, also z. B. der Analyst aus der Geschäfts -

perspektive und der IT-Fachmann aus der IT-Perspektive. Die Geschäfts-

analysten können in einer solchen, digitalen Umgebung die Prozesse

grafisch modellieren, und die Tools erzeugen daraus Prozessbeschreibun-

gen in Standard-Prozessmodellierungskonventionen und Notationen.

22


Mit einer integrierten Entwicklungsplattform in einer serviceorientierten

Umgebung werden die Prozessschritte dann in technische Services (Web

Services) umgewandelt und neue Services zusammengebaut (kompo-

niert). Für die Ausführung dieses Prozesses ist eine so genannte BPM-

Engine zuständig. In einer herkömmlichen Architektur werden die

Engines lediglich statische Versionen eines Prozesses ausführen können

und damit der geforderten Flexibilität und Agilität eines Geschäfts ent -

gegenwirken, indem sie dem Unternehmen vorschreiben, wie der Prozess

abzulaufen hat. In einer SOA sind die vorhandenen Daten und die

Funktionalität in Services vorhanden. Diese fügen Unternehmensfachleute

zu so genannten Composite Applications zusammen. Das sind agile

Geschäftsprozesse, die auf der Grundlage von definierten Geschäfts -

prozessen konfiguriert sind. Die Dienste werden öffentlich gemacht und

können dynamisch zu anderen Prozessen mit anderer Logik zusammen-

gesetzt werden. Auf diese Weise liefert dieser neue Typus einer service -

orientierten Geschäftsanwendung (Service Oriented Business Application

– SOBA) einen prozessgetriebenen Ansatz für das Zusammenstellen eines

logischen Informationsflusses aus heterogenen Datenquellen und ist

damit ein erfolgskritischer Treiber für Geschäftsagilität.

23

www.hessen-it.de

© k

ento

h -

Foto

lia.c

om

2.4 Effizienz durch Governance

Schließlich muss es eine Instanz – die Governance – geben, die die

Kom ponenten der serviceorientierten Architektur wie Services, Prozesse

und Regeln, sowie organisatorische Aspekte begleitet. Eine effiziente

Governance definiert aufbau- und ablauforganisatorische sowie techni-

sche Regeln für den gesamten Lebenszyklus einer solchen Landschaft. Zu

den organisatorischen Aspekten gehört beispielsweise das Festlegen der

fachlichen und technischen Verantwortung für einen Service (Ownership).

Ferner werden Rollen definiert, die festlegen, wer für bestimmte Bereiche

verantwortlich ist. Governance lässt sich durch den Einsatz einer Registry in

enger Kombination mit einem Repository für den gesamten Lebenszyklus

der Services umsetzen. Die Registry liefert gleichermaßen eine Kategori-

sierung und eine Organisation der Services. Nutzer können neue Services

im Katalog publizieren und nach vorhandenen suchen. Die Komponenten

können mehrfach kategorisiert werden, um Services einer bestimmten

Service-Domäne, einer fachlichen Funktion oder einem Prozess zuzuord-

nen. So entsteht eine vollständige Dokumentation der Architektur.

Das Repository reichert die Informationen in der Registry um Metadaten

an, also um beschreibende Daten etwa zu Schnittstellen oder Anforderun-

gen an die Komponenten. Das Governance-Repository umfasst ein Infor-

mationsmodell oder eine Taxonomie und zusätzlich Audit-Fähigkeiten für

das Verfolgen von Änderungen an den Services, Identity-Management-

Funktionen und eine rollenbasierte Zugriffskontrolle. Es sollte der gesamte

Lebenszyklus einer Komponente als Workflow mit allen Arbeitsschritten

und den beteiligten Rollen darin abgebildet werden (Lifecycle Manage-

ment). Um eine Synchronisation von Repository und Registry sicherzu -

stellen, empfiehlt es sich, die beiden in einem einheitlichen, auf Standards

beruhenden Informationsmodell mit einem zugehörigen Datenspeicher

zusammen zu führen. Damit sind Governance-bezogene Metadaten und

das Informationsmodell konsistent in einem Speicher vereint, und die An -

wender erhalten ein einziges System für die Verwaltung aller Informatio-

nen bezüglich der SOA-Komponenten und der Governance-Metadaten.

24


2.5 Fazit

Die IT-Landschaft vieler Unternehmen basiert heute häufig noch auf IT-

Silos. Gefragt und gewünscht sind jedoch effiziente Prozesse, die unter-

nehmensübergreifend wirksam werden und sowohl Zulieferer als auch

Geschäftspartner einbinden. Unternehmen erkennen immer mehr:

Erstklassige Prozesse sind genau so wichtig wie erstklassige

Produkte, und innovative Prozesse sind die Grundlage für

erstklassige Geschäftserfolge.

Genau darum geht es beim Business Process Management und bei service-

orientierten Architekturen. BPM und SOA sind keine rein technische Auf-

gabe, die durch neue Produkte oder Dienstleistungen gelöst werden kön-

nen. Das Management von Geschäftsprozessen und serviceorientierten

Architekturen ist von Natur aus eine soziale Aktivität. Ein erfolgreicher Pro-

zess sollte jeden Beteiligten berücksichtigen. Idealerweise kollaborieren

alle Ebenen gleichberechtigt, vom Angestellten bis zum Vorstand, um

einem Projekt und den damit verbundenen Geschäftsprozessen den opti-

malen Mix aus Wissen, Erfahrung und persönlichem Einsatz in kürzester Zeit

und zu den geringst möglichen Kosten zuteil werden zu lassen. Bisherige

Lösungen konzentrierten sich vielfach auf die Installation verschiedener, nur

wenig kompatibler Tools durch IT-Abteilungen auf den Desktops der Betei-

ligten. Das Ergebnis führte jedoch kaum zu den gewünschten Erfolgen

einer echten, unternehmensübergreifend arbeitenden sozialen Gemein-

schaft, deren Teilnehmer gleichermaßen Interesse am Projekterfolg haben.

Die optimierte interne und externe Kollaboration von Experten und die

damit entstehenden „fließenden“ Teams, die über Unternehmensgrenzen

hinweg gemeinsam ohne Reibungsverluste an BPM- und SOA-Projekten

arbeiten, werden in Zukunft darüber entscheiden, ob und inwieweit Pro-

zesse verbessert werden können.

25

www.hessen-it.de

SOA-Starter Kit: Think big, start small, show quick success

Markus Ganß, Opitz Consulting Bad Homburg GmbH

3.1 Einsatzbereiche

Als IT-Architektur und Managementkonzept bedeutet eine SOA in vielen

Einsatzbereichen die richtige Wahl. Grundsätzlich sprechen nicht die

Unternehmensform oder -größe für oder gegen den Einsatz einer

SOA, sondern allein die Herausforderungen eines Unternehmens und

die daraus abgeleiteten Anforderungen. Bei folgenden Aufgaben und

Lösungsansätzen sollte der Einsatz einer serviceorientierten Architektur

geprüft und bewertet werden:

a Integrationsszenarien

Ein typisches Ziel von Integrationsszenarien ist es, Daten über Unter-

nehmensanwendungen hinweg möglichst in Echtzeit zu synchronisie-

ren und konsistente Zustände zu bewahren. Im Rahmen einer SOA

kann mit einem Enterprise Service Bus (ESB) die Kommunikation

zwischen Systemen koordiniert werden. So wird die Konsistenz und

Genauigkeit von Daten auch über Systemgrenzen hinweg sicher -

gestellt.

a Entwicklung individueller Anwendungen

Bei der Entwicklung von individuellen Anwendungen sollte von

Beginn an darauf geachtet werden, die enthaltenen Geschäftsfunktio-

nen der Anwendung im Rahmen von Services bereitzustellen, um

durch die lose Kopplung von Modulen die Wartbarkeit und Wieder-

verwendbarkeit der Anwendung und ihrer Module zu erhöhen. Dabei

muss die zusätzliche Investition bei der Erstellung der Anwendung

natürlich über eine ROI-Berechnung gerechtfertigt sein.

3

26


a Prozessautomatisierung

Durch die Automatisierung von Geschäftsprozessen unter Einbezie-

hung von Anwendungen, Systemen und Personen lässt sich die Pro-

zessproduktivität verbessern. Die Transparenz der Unternehmenspro-

zesse wird gesteigert und die Agilität der Prozesse wird erhöht.

a Prozessportale

Durch Prozessportale können manuelle und automatisierte Geschäfts-

prozesse über Anwendungen hinweg angestoßen, betrieben und ver-

folgt werden. Auch hierdurch wird die Produktivität und Transparenz

der Prozesse erhöht.

a Business Activity Monitoring

Das Business Activity Monitoring sammelt zur Laufzeit der Prozesse

die Prozessdaten und berechnet in Echtzeit die Key Performance Indi-

katoren (KPI). Auf dieser Basis können dann Prozessoptimierungen

durchgeführt werden. Die Daten werden integriert in so genannten

Dashboards dargestellt und dienen zur verbesserten und zeitnahen

Entscheidungsfindung.

a Business-to-Business Integration

Die Einführung einer SOA sollte auf jeden Fall auch bei der Anforde-

rung einer Business-to-Business Integration geprüft werden. Ziel die-

ser Integration ist es, Geschäftspartner in die Geschäftsprozesse des

Unternehmens zu integrieren. So können die Kosten innerhalb der

Wertschöpfungskette eines Unternehmens gesenkt werden.

27

www.hessen-it.de

Über diese genannten Bereiche hinaus finden sich in vielen Unternehmen

weitere Anforderungen und Ansatzpunkte, die mit einer SOA unterstützt

werden können. Dabei bedarf es einer individuellen Analyse der Anforde-

rungen. Weitere klassische Indikatoren für den möglichen Einsatz einer

SOA sind folgende Aspekte:

a Verteilte Systeme

a Verteilte Verantwortung (bereichsübergreifend)

a Heterogene Systemlandschaft

Es gibt auch Anforderungen, die durch eine SOA nicht optimal abgedeckt

werden können. Beispiele hierfür sind:

a Der Austausch großer Datenmengen, z. B. über Datenbankreplikationen

a Die Anbindung von Anwendungen auf lokalen Clients

3.2 Dimensionen und Ziele

Im Rahmen einer serviceorientierten Architektur sind drei verschiedene

Betrachtungs- und Handlungsdimensionen zu beachten:

SysteminfrastrukturLaufzeitumgebung,Systemintegration

ServiceentwicklungStandards, Service Orchestrierung

Systemmanagement SLA, Sicherheit,Performance

SOA ist einTechnologiekonzept

SOA ArchitekturEnterprise Architecture,Integrierte Geschäfts-prozess- und IT-Architektur

SOA Methodik Service-Identifikation,-Klassifikation und-Portfoliomanagement

SOA ist einArchitekturkonzept

SysteminfrastrukturSOA GovernanceRichtlinien

SOA StrategieSOA Maturity ModelSOA Assessment

SOA Organisation Rollen und Aufgaben

SOA erfordert einOrganisationskonzept

28


a Dimension Organisation

SOA erfordert ein Organisationskonzept, um eine strategische

Ausrichtung, einen formalen Handlungsrahmen und eine organisa -

torische Gestaltung bzw. Implementierung bereitzustellen.

a Dimension Architektur

SOA ist Teil einer Unternehmensarchitektur (Enterprise Architecture),

in der u. a. die Geschäftsprozess- und IT-Infrastrukturen abgebildet

und zueinander in Beziehung gesetzt werden. Darüber hinaus bietet

eine SOA Methodikansätze zur Identifikation, Klassifikation und zum

Management von Services.

a Dimension Technologie

SOA ist ein Technologiekonzept, das eine Systeminfrastruktur und ein

Systemmanagement bereitstellt, um serviceorientierte Anwendungen

implementieren und betreiben zu können.

Diese drei Dimensionsebenen machen deutlich: SOA ist mehr als nur das

nächste Infrastrukturprojekt – es ist ein fachlich orientierter Management-

ansatz, der in der Unternehmensarchitektur und der technischen IT-Infra-

struktur umgesetzt wird.

Ein übergeordnetes Ziel, das jeder SOA-Ansatz verfolgt, ist die Beherr-

schung der heterogenen Systemlandschaften im Unternehmen. Die Rea-

lität zeigt heute vielfach Anwendungslandschaften mit proprietären

Schnittstellen, vielen verschiedenen Plattformen und unübersichtlichen

Interaktionen zwischen diesen Anwendungen und Systemen.

29

www.hessen-it.de

Weitere Ziele bilden die Lösung von Herausforderungen, die mit der

Heterogenität eines IT-Systems oft in unmittelbarem Zusammenhang

stehen, wie etwa:

a kaum Wiederverwendung

a kurze Technologiezyklen / keine Adaption neuer Technologien /

eingeschränkte Innovationsfähigkeit

a keine bzw. undokumentierte Schnittstellen

a verteilte Anwendungslogik in grafischen

Benutzeroberflächen und in der Middleware

a keine B2B- / B2C- / Multikanalfähigkeit

a hohe IT-Kosten

a geringe Umsetzungsgeschwindigkeit / fehlende Flexibilität

Zu Visionen und Strategien, die bei der Einführung einer SOA eine Rolle

spielen können, gehören:

a Kopplung von Geschäftsprozessen und IT-Prozessen

(Business-IT Alignment)

a Interoperabilität von Standardsoftware

bzw. individuellen Kernapplikationen

a Prozesscontrolling und -optimierung

a Komplexität reduzieren und Transparenz schaffen

30


3.3 Komponenten

Eine serviceorientierte Architektur kann im einfachsten Fall aus einzelnen

Services bestehen, die lose gekoppelte Funktionalitäten zur Wiederver-

wendung bereitstellen. Ein Service ist eine spezielle Softwarekomponente

mit einer wohl-definierten Funktionalität, die von anderen Softwarekom-

ponenten lokal oder über ein Netzwerk mit einer zuvor fest definierten

Schnittstelle genutzt werden kann. Funktionalität bezeichnet dabei die

Fähigkeit einer Komponente, eine oder mehrere Aufgabe(n) zu lösen.

Um Punkt-zu-Punkt-Verbindungen zwischen einzelnen Services zu vermei-

den, kann ein Enterprise Service Bus (ESB) eingesetzt werden. Der Ser-

vicebus ist eine logische Architektur, die konform zu den SOA-Prinzipien

eine Integrationsinfrastruktur bereitstellt. Ein ESB bietet zum Beispiel

Möglichkeiten, über Adaptoren andere Standardanwendungen (SCM,

CRM, ERP) anzusprechen. Er garantiert zudem die Einhaltung von Secu-

rity-Richtlinien und stellt Oberflächen für das Monitoring bereit. Somit

übernimmt er das Management der Integrationsinfrastruktur.

ServiceOrchestrierungServiceregistry

SCM Check CreditService

WebshopClient

Monitoring

Servicebus

Security

31

www.hessen-it.de

Zu den typischen Aufgaben eines ESB gehören:

a Transformation der verschiedenen Protokolle

und Nachrichtenformate (Meditation)

a Routing von Nachrichten

a Bereitstellung von Adaptoren zur Anbindung verschiedener Systeme

a Verbergen der eigentlichen Service Provider

vor den Service Consumern (Service-Virtualisierung)

a Monitoring

a Security

Einzelne Services können über eine Serviceorchestrierung zu höherwerti-

gen (composite) Services kombiniert werden, um z. B. eine Geschäftsfunk-

tion bereitzustellen. Hierfür werden BPM (Business Process Management),

BPEL (Business Process Execution Language) oder klassische Workflow -

systeme genutzt.

Eine Service-Registry ist ein Verzeichnis von Serviceinformationen. Es bein-

haltet alle Informationen, um einen Service zu finden und zu nutzen. Das

Registry kann noch Informationen zum Servicevertrag beinhalten. Typische

Inhalte einer Service-Registry sind Angaben in folgenden Bereichen:

a Servicevertrag

a Serviceschnittstelle

a Sicherheit (verwendetes Sicherheitssystem, Rechte etc.)

a Leistungsmerkmale (Performanz, Skalierbarkeit etc.)

a Ansprechpartner

a Fachliche Fragen und Änderungswünsche,

welche die Geschäftslogik betreffen

a Technische Fragen und Änderungswünsche,

welche die Implementierung betreffen

a Informationen über den Ort, an dem der Service

zurzeit bereitgestellt ist (oder über einen ESB-Endpunkt)

32


3.4 Der erste Service

Grad der SOA-Basierung im Unternehmen

Wenn ein Unternehmen eine SOA einsetzen möchte, muss es eine SOA-

Strategie entwickeln. Die Einführung einer SOA erfolgt über einzelne

Projekte und sollte daher im Rahmen einer Roadmap definiert werden.

Die ersten SOA-Projekte enthalten meistens noch nicht alle Komponenten

einer unternehmensweiten SOA (Enterprise SOA) und manche Unterneh-

men müssen und wollen diese Ausbaustufe auch gar nicht erreichen.

Vielfach ist schon eine SOA in kleinerem Umfang (SOA lite) die richtige

Wahl, weil sie adäquate Lösungen für die gestellten Aufgaben und An -

forderungen liefert.

Erfüllungsgrad

SOA lite Enterprise SOA

33

www.hessen-it.de

Eine SOA lite setzt bereits erste leichtgewichtige Web Services ein, bei

denen eindeutige Schnittstellendefinitionen erstellt werden. Oft findet

man in dieser Ausbaustufe noch keinen ESB, sondern benutzt Punkt-zu-

Punkt-Verbindungen zwischen einzelnen Applikationen. Das Thema SOA-

Governance beschränkt sich auf die Richtlinien für die Schnittstellen -

definitionen und eventuell auf Namenskonventionen. Auf dieser Ebene

setzt man häufig Open Source-Werkzeuge für die technische Einführung

der SOA ein.

Eine Enterprise SOA bildet die strategische Plattform für die Architektur

der Unternehmensanwendungen. Es werden komplexe Integrations -

szenarien mit Hilfe von Middleware-Infrastrukturen und SOA-Suiten von

kommerziellen Herstellern umgesetzt. Die Organisation des Unterneh-

mens ist hier durch die SOA-Governance verändert und neue Rollen,

Verantwortlichkeiten und Prozesse sind etabliert.

Das Ziel einer SOA-Einführung besteht darin, den für die

individuelle Situation eines Unternehmens adäquaten

Erfüllungsgrad zu finden und nicht darin, den höchstmöglichen

Erfüllungsgrad zu erreichen.

Ist Ihr Unternehmen auf die Einführung einer SOA vorbereitet?

Wenn ein Unternehmen eine serviceorientierte Architektur einführen

möchte, sollte dies zunächst in kleinen Schritten geschehen. Ein klassi-

scher Ansatz ist die Durchführung eines SOA-Pilotprojekts:

34


ZielSOA Pilotprojekt

SOA Pilotprojekt

SOA Starter Kit

Ergebnisorientierter und pragmatischerAnsatz für die Evaluierungs- oderStartup-Phase Ihres SOA-Vorhabens

NutzenSOA in der Praxis an Hand eines klarabgegrenzten Problemfalls kennenlernen

Praxiserfahrung in relevanten Methodenund geeigneten Werkzeugen sammeln

Erkenntnisse für das weitere Vorgehen inIhrem SOA-Vorhaben erarbeiten

Ausarbeitung einer greifbaren Nutzenargumentation inRichtung Fachbereiche und Management: Was bringt SOA exakt für uns?

SOA-Pilot als ein sinnvoller erster Schritt in RichtungIhres Gesamtvorhabens

Attraktives Kosten-Nutzen-Verhältnis durchergebnisorientierte Umsetzung mit kurzer Laufzeit

Klare Fokussierung auf Vorgehensweise und Methodik,da technische Rahmenbedingungen vorgegeben sind

AuswertungSOA-Pilot

SOA-Nutzen-argumentation

Modul 10: Sammlung Lessons Learned

Modul 11: Ausarbeitung Nutzenargumentation für SOA-Gesamtvorhaben

PlanungSOA-Pilot

ProjektRoadmap

Modul 1: Auswahl eines geeigneten SOA-Piloten

Modul 2: Zieldefinition und Abgrenzung

Modul 4: Erstellung Projekt-Roadmap

Modul 3: Ausrichtung der Strategie für SOA-Gesamtvorhaben optional

DurchführungSOA-Pilot

LauffähigeServices

Modul 5: Analyse und Modellierung des neuen Anwendungsfalls

Modul 6: Review eines bestehenden Anwendungsfalls

Modul 7: Service-Modellierung

Modul 8: Service-Implementierung

Modul 9: Service-Rollout

optional

optional

www.hessen-it.de

Eigenschaften des ersten Services und dessen Umsetzung

Services, die als SOA-Pilotprojekt umgesetzt werden, sollten folgende

Eigenschaften besitzen:

a Hohe Sichtbarkeit

a Managementunterstützung

a Klar abgegrenzter Problemfall

a Geringer Abstimmungsaufwand

a Nicht geschäftskritisch

Die hohe Sichtbarkeit erleichtert die Nutzenargumentation im Anschluss an

das SOA-Pilotprojekt. Sie fördert die notwendige Managementunterstüt-

zung für das weitere SOA-Vorhaben. Der oder die Service(s) sollte(n) einen

klar abgegrenzten Problemfall beschreiben, um zu Beginn einen möglichst

geringen Abstimmungsaufwand zu ermöglichen. Es ist sinnvoll, anfangs

einen nicht-kritischen Geschäftsfall zu implementieren, um sich hierdurch

nicht einer unnötigen Drucksituationen auszusetzen. Die Ergebnisse des

SOA-Pilotprojekts dienen als Entscheidungsgrundlage für das Unterneh-

men, ob es weiterhin eine Strategie auf Basis einer serviceorientierten Archi-

tektur verfolgen sollte. Insgesamt gilt für das Vorgehen beim Pilotprojekt:

Einbettung des SOA-Piloten in Ihr SOA-Gesamtvorhaben

Sobald das SOA-Pilotprojekt abgeschlossen ist, existiert eine Entschei-

dungsgrundlage für das weitere Vorgehen. Wenn positiv entschieden wurde

und eine Roadmap erstellt wurde, um die geplante SOA-Strategie umzuset-

zen, geht es an die Einbindung von SOA in weitere Projekte des Unterneh-

mens. Ein iterativer, der Roadmap folgender Ansatz hat sich klar bewährt:

Think big, start small,

show quick success

36


Im Rahmen der weiteren SOA-Projekte baut man die SOA-Architektur mit

immer weiteren Komponenten aus, überprüft und verfeinert die SOA-

Governance und integriert SOA im Rahmen des Change Managements in

das Unternehmen. Wichtig ist immer wieder, das Erreichte zu überprüfen,

den Erfolg anhand von definierten Indikatoren zu bewerten und korrigie-

rend einzugreifen, wenn neue Anforderungen oder Rahmenbedingungen

die Roadmap zur Erreichung der geplanten serviceorientierten Architek-

tur beeinflussen.

3.5 Fazit

Moderne serviceorientierte Architekturen halten in allen Unternehmens-

formen und -größen Einzug. Erfolge erzielen diejenigen Projekte, die

schnell einen Mehrwert für die Fachbereiche erzeugen und vom Manage-

ment entsprechend unterstützt werden.

Wer versucht, eine SOA durch ein einzelnes Projekt oder eine neue Tech-

nologie einzuführen, gerät meistens in eine Sackgasse. Es gibt nur wenige

SOA-Initiativen, die mit diesen Ansätzen dauerhaft erfolgreich waren.

Deswegen ist die Einbettung des SOA-Pilotprojekts in die Gesamtstrate-

gie des Unternehmens entscheidend. Nur wenn dessen strategische Ziele

und deren konkrete Machbarkeit durch das Pilotprojekt unterstützt wer-

den, leistet SOA einen wichtigen Beitrag zum Unternehmenserfolg.

Gesamtvorhaben

SOAStarter

Kit

Lessons

Learned

Lessons

Learned

SOA-Projekt

Lessons

Learned

Lessons

Learned

Pilot-Projekt

Lessons

Learned

Lessons

Learned

SOA-Projekt

37

www.hessen-it.de

SOA-Kommunikation: „Wie überzeug’ ich meinen Chef?“

PD Dr. Ralf Helbig, Detecon International GmbH

Wer seinen Chef überzeugen möchte, in eine SOA-Initiative zu investie-

ren, sollte zuerst einige Voraussetzungen schaffen. Innerhalb der IT-Abtei-

lung ist zunächst ein gemeinsames Verständnis von SOA zu erzeugen und

Einigung zu erzielen, welchen Nutzen SOA für das Unternehmen haben

kann. Hierbei ist es unerlässlich, den Nutzen aus der Geschäftsperspektive

zu betrachten. Das heißt, es muss deutlich werden, welche Kosten invol-

viert sind, ob und in welchem Ausmaß Einsparungen realisiert werden

können und worin der geschäftliche Nutzen von SOA darüber hinaus

besteht. Erst dann wird es wichtig, dem Management zu veranschauli-

chen, wie SOA funktioniert und wie man die monetären und qualitativen

Vorteile von SOA der Fachseite und dem Chef vermitteln kann, so dass

dieser eine Bereitschaft für Investitionen zeigt.

4.1 Die optimale SOA-Initiative

Serviceorientierung benötigt einen Kunden, der Services anfragt, und

einen Lieferanten, der auf einen funktionierenden Betrieb zugreifen kann.

Es macht keinen Sinn, Entscheidungsträger allgemein von SOA über -

zeugen zu wollen, ohne dass sie den konkreten Nutzen vor Augen haben.

Im ersten Schritt ist es daher wichtig zu verstehen, wer die Kunden von

Services sind und welche Anforderungen sie an diese stellen. Im zweiten

Schritt ist dann zu untersuchen, welche Auswirkungen eine Serviceorien-

tierung auf den eigenen Betrieb und dessen Architektur hat.

4

38


Der Service zwischen Kunde und Lieferant

Die Abbildung zeigt zwei Elemente einer serviceorientierten Architektur.

Auf der einen Seite sind Kunden, die Erwartungen an IT-Dienstleistungen

haben, die mehr oder weniger konkret artikuliert werden. Auf der ande-

ren Seite stellt sich die Frage, wie die Servicedienstleistung vom Lieferan-

ten mit seiner IT-Fabrik erbracht werden kann. Hierbei ist es für ihn wichtig

zu wissen, wie weit die momentane IT von einer serviceorientierten Archi-

tektur entfernt ist.

Der Nutzen einer serviceorientierten Architektur besteht vor allem in der

erhöhten Flexibilität der IT, die dann entsteht, wenn sie erst einmal umge-

setzt ist. Die Migration von einer herkömmlichen Architektur zu einer SOA

bzw. deren Aufbau ist aber in der Regel aufwendig, da viele Vorarbeiten

und Analysen notwendig sind. Daher ist es von Vorteil, einzelne Bereiche

zu identifizieren, die von den Vorteilen einer SOA maximal profitieren.

IT-ArchitekturLieferant

orientiert an

Erwartungen

Kunde

Service

39

www.hessen-it.de

Eine SOA setzt eine hohe Transparenz und ein gutes Verständnis der

Applikationsarchitektur voraus. Weiterhin benötigt SOA eine redundanz-

freie Strukturierung der benötigten geschäftsfachlichen und technischen

Fähigkeiten sowie der Informationsobjekte. Wenn diese Voraussetzungen

erfüllt sind, können

a Redundanzen schnell erkannt werden,

a (dadurch) unnötige Komplexität reduziert werden,

a IT-Kosten transparent gemacht werden

a und eine Standardisierung vorangetrieben werden.

So stellt eine serviceorientierte Architektur auf der einen Seite maximale

Effektivität sicher, indem sie die angebotenen fachlichen und technischen

Services optimal auf die Kundenerfordernisse abstimmt. Auf der anderen

Seite leistet sie höchste Effizienz durch eine überlappungsfreie und

redundanzfreie Definition der Services, welche die Voraussetzung für eine

effiziente Produktion bildet.

Nutzenpotentiale einer serviceorientierten Architektur

IT-ArchitekturLieferant

orientiert an

Erwartungen

Kunde

Service

Komplexität

Variantenvielfalt

Kosten

Zeit

Flexibilität

Qualität

Kundenorientierung

Standardisierung

EffizienzEffektivitätEnabler

40


Die Abbildung verdeutlicht diesen angesprochenen Zusammenhang und

benennt wesentliche allgemeine Nutzenpunkte, die durch SOA erzielt

werden können – wie die bereits erwähnte Reduzierung der Komplexität

durch eine Verringerung der Variantenvielfalt und der Redundanzen, die

Einsparung von Kosten und Zeit und die damit einhergehende erhöhte

Flexibilität, wenn SOA realisiert ist. Auch die Qualität kann durch SOA

mittels einer konsequent, am Kunden ausgerichteten Standardisierung

gesteigert werden.

Diese genannten Vorteile einer serviceorientierten Architektur dürften zu

allgemein sein, um Ihren Chef zu überzeugen. Deswegen sollten sie für

bestimmte Geschäftsbereiche konkretisiert und auf den greifbaren bzw.

monetären Nutzen heruntergebrochen werden. Beispielhafte Ergebnisse

könnten sein, dass die Projektkosten um ein Viertel reduziert und die Pro-

jektdauer verkürzt werden.

Es ist wichtig zu prüfen, welche Ziele auf der Fachseite bestehen und ob

diese von einer SOA profitieren. SOA nutzt einem stabilen Geschäft, das

kaum Änderungen unterliegt, weniger als einem, das mit kurzen Time-to-

Market-Zyklen neue Produkte auf den Markt bringen muss. Für ein erfolg-

reiches unternehmensinternes SOA-Marketing ist es deshalb entschei-

dend, diejenigen Unternehmensbereiche zu identifizieren, die von einer

serviceorientierten Architektur am meisten profitieren.

41

www.hessen-it.de

4.2 Geschäftsanforderungen

Für das Aufsetzen einer SOA ist es notwendig, Beziehungen transparent

zu machen. In Unternehmen werden zwar häufig Prozesse modelliert, in

der Regel existiert aber kein systematisches, zentrales Ordnen von

Geschäftsanforderungen. Genau dies ist aber die Voraussetzung für die

Identifikation von Fachservices und für das Erkennen von potenziellen

Kandidaten für eine Wiederverwendbarkeit. Es wird ein logisches Modell

benötigt, das die für ein erfolgreiches Betreiben eines Unternehmens

erforderlichen Fähigkeiten und Funktionen überschneidungs- und redun-

danzfrei definiert und ordnet. Diese logische Strukturierung in Bezug auf

Funktionen und Informationen dient als Speicher für Geschäftsanforde-

rungen und hilft, die Geschäftsanforderungen – also die Nachfrage – in

darauf abgestimmte IT-Dienstleistungen – also in ein passendes Angebot

– zu übersetzen.

Aufbau einer SOA-getriebenen Unternehmensarchitektur mit

einem logischen funktionalen Domänenmodell zur Übersetzung der

Geschäftsanforderungen sowie einem logischen technischen Domänenmodell

zur Strukturierung der Applikationsanforderungen

42


Wie in der Abbildung ersichtlich, dient das logische funktionale Domä-

nenmodell als Verbindungsglied zwischen Prozessen und Anwendungs-

services. Durch die Zuordnung der Fähigkeiten und IT-Funktionen zu

Prozessen entsteht ein Baukastensystem. Dieses ermöglicht:

a die Prozesse zusammenzufügen und zu orchestrieren,

a die Anforderungen aus den Prozessen zu systematisieren,

konsolidieren und in die IT zu kanalisieren,

a Hoheiten über Daten zu definieren sowie

a Schnittstellen effizient zu systematisieren und zu organisieren.

Das Leistungsportfolio der IT mit seinen Applikationen und Services kann

über das Domänenmodell optimiert und auf die Erfordernisse des Ge -

schäfts ausgerichtet werden.

Eine ähnliche Systematik bietet sich, wie die Abbildung zeigt, auch zur

Gestaltung der technischen Infrastruktur an, die einen Fachservice unter-

stützt. Auch hier lässt sich an der Schnittstelle von Applikationen zur tech-

nischen Infrastruktur eine Übersetzungsebene einziehen. Diese ordnet

die prinzipiell benötigten, technischen Fähigkeiten in technischen Domä-

nen. Sie dienen als Speicher für die Anforderungen der Applikationen

und helfen logische Kombinationsmuster zu definieren, die unterschiedli-

che Applikationsarchitekturen unterstützen. Auch hier dienen die Muster

dazu, eine strategische Ausrichtung der technischen Infrastruktur auf die

eher nicht-funktionalen Erfordernisse des Geschäfts zu erreichen. Darüber

hinaus wird durch die logische Betrachtung mit der Orientierung an fest-

gelegten Mustern eine maximale Standardisierung bis in die Implemen-

tierungswelt hinein erreicht. So werden durch maximale Transparenz in

der jeweiligen Architekturebene Hebel für eine sinnvolle, am Geschäft

ausgerichtete Standardisierung und Effizienzsteigerung identifiziert. Darü-

ber hinaus werden durch die Transparenz der Beziehungen zwischen den

Architekturebenen über die logischen Modelle Ursache- / Wirkungsbezie-

hungen deutlich, die dann ein konsequentes Ausrichten auf die Anforde-

rungen des Geschäfts ermöglichen.

43

www.hessen-it.de

4.3 Argumentationsstrategie

Für ein wirksames internes Marketing einer SOA-Initiative ist es wichtig,

sich zuvor Verbündete vor allem auf der Geschäftsseite zu suchen. Hierfür

ist es hilfreich, nicht gleich für das gesamte Unternehmen, sondern gezielt

für einzelne Bereiche den konkreten Nutzen konsequent qualitativ und

vor allem monetär zu spezifizieren. Der monetäre Nutzen kann durch

Architekturmodelle ermittelt werden, die es ermöglichen, verschiedene

Kostenblöcke der IT einzelnen Produkten zuzuordnen. Für eine solche

Analyse muss SOA auf einzelne IT-Services bezogen werden. So kann

berechnet werden, dass z. B. die Time-to-Market-Spanne um 50 % redu-

ziert wird, wenn man SOA auf einen IT-Service anwendet.

SOA-basiertes Kosten- und Preismodell

BusinessCapability

700.000 €

BusinessCapability

100.000 €

InfrastructureCapability

200.000 €

InfrastructureCapability

300.000 €

3 other

300.000 €

300.000 €

400.000 €

300.000 € 100.000 €400.000 €

400.000 €

2 other2 otherABB costs 500.000 €

200.000 €200.000 € 100.000 €

44


Ein Kosten- und Preismodell wie in dieser Abbildung dargestellt basiert auf

den Verknüpfungsinformationen zuvor beschriebener Modelle. Dadurch

können Kosten der IT auf Funktionen, die für das Geschäft verständlich

sind, zusammengefasst und dargestellt werden. Dies steigert die monetäre

Transparenz über die Wirkung von Änderungen auf der Produkt- und Pro-

zessebene sowie auf der Applikations- und Technologieebene. Die durch

ein derartiges Kostenmodell geschaffene Transparenz erlaubt eine Ergeb-

nissicht auf einzelne abgegrenzte Teilbereiche. Optimale, klar abge-

grenzte, sehr fokussierte und zielgerichtete SOA-Projekte können so iden-

tifiziert und mit begrenztem Aufwand und Risiko umgesetzt werden. Man

muss damit nicht einen generellen SOA-Ansatz für die gesamte Unterneh-

mung mit relativ unspezifischen Investitionen verkaufen, sondern kann

ganz fokussiert „SOA-profitable“ Bereiche identifizieren, in denen SOA mit

der beschriebenen Kosten- und Nutzen-Transparenz nachweislich den

maximalen Nutzen produziert. Mit diesen kleineren, fokussierten Maßnah-

men ist die Schwelle für die Genehmigung von Mitteln geringer, weil diese

dann nachweislich profitabel eingesetzt werden.

Indem man die SOA auf einen konkreten Geschäftsbereich anwendet,

wird ein ansonsten vager Nutzen für die Geschäftsleitung konkretisiert

und greifbar. Wenn beispielsweise ein Geschäftsbereich wie Sales oder

Billing identifiziert wird, der mit sehr kurzen Time-to-Market-Anforderun-

gen konfrontiert ist, fällt es nicht schwer, den Nutzen überzeugend zu

kommunizieren und Verbündete zu gewinnen.

Durch die Verknüpfung strategischer Ziele des Unternehmens mit denen

einzelner Stakeholder, zu denen SOA nachweislich einen direkten Wert-

beitrag liefert, wird Aufmerksamkeit auf der Geschäftsseite erzeugt und

die Bereitschaft geschaffen, in derartig werthaltige, abgegrenzte Maßnah-

men mit überschaubaren Risiken zu investieren. Hat man einen solchen

Nutzen aufgezeigt, quantifiziert und überzeugend vermittelt, ist es bei der

Umsetzung dieser Maßnahme wichtig, die Realisierung dieses Nutzens

bei der Implementierung nachzuweisen.

45

www.hessen-it.de

Dieser Ansatz birgt aber auch Gefahren: Eine Investitionszusage in eine

SOA-Initiative ist mit ihm zwar leichter zu erreichen, das bedeutet aber

nicht automatisch einen Durchbruch für eine unternehmensweite SOA.

Denn er erfordert eine sehr gute Vorbereitung und die Gewissheit, dass

der versprochene Nutzen auch nachweisbar erbracht werden kann. Ein

Misslingen oder auch eine signifikante zeitliche Verzögerung des Projek-

tes, die der Serviceorientierung zugeschrieben werden kann, bedeutet in

der Regel die Aufgabe des SOA-Prinzips im laufenden Projekt und auf

lange Zeit hin das Ende jeder weiteren SOA-Initiative. Sowohl bei der

Identifikation und der Auswahl des SOA-affinen Bereichs als auch bei dem

Nutzenversprechen und der geplanten Umsetzung ist größte Sorgfalt

geboten, weil die Initiative und der zu erbringenden Nachweis eines SOA-

basierten Nutzens von allen Seiten neugierig beobachtet wird.

Mit SOA kann man nur mit einer effizienten, Fakten-basierten und an den

Bedürfnissen der Stakeholder orientierten Kommunikation erfolgreich

sein. Diese sollte auf einer transparenten und steuerbaren Architektur

basieren, die gezielte SOA-Eingriffe ermöglicht und den entstandenen

Nutzen quantifizieren lässt. Mithilfe von wohldefinierten, aus den Kerntrei-

bern des Geschäfts abgeleiteten KPIs (Key Performance Indicators) kann

der Erfolgsbeitrag von SOA in dem betrachteten Projekt nachgewiesen

und an den Sponsor kommuniziert werden.

46


4.4 Vorteile kommunizieren

In der IT ist meistens ein multivariates Zielsystem zu beachten. Das heißt,

es handelt sich nicht um eine eindimensionale Optimierung, wie z. B. nur

nach Kostenzielen, sondern um eine Mischung diverser, unterschiedlich

gewichteter, teilweise konkurrierender Ziele, die zusammen betrachtet

werden müssen. Außerdem ist nicht nur eine Ist- mit einer Zielsituation zu

vergleichen, sondern auch die Migration dorthin. Denn selbst wenn das

angestrebte Ziel ein Optimum darstellt und die gesetzten Ziele bestens

erfüllt, scheidet die Lösung aus, wenn der Weg dorthin zu viele Risiken

oder Kosten verursacht. Das Aufzeigen des Wertbeitrages führt oft zu

komplexen Argumentationen, die für ein Management nicht über -

zeugend genug sind. Deswegen müssen die wesentlichen Vorteile mit

Bezug zur Strategie möglichst mit einem quantifizierbaren Nutzen für das

Geschäft herausgearbeitet und evtl. mithilfe anschaulicher Metaphern

verdeutlicht werden.

Da der Nutzen von SOA nicht unmittelbar und direkt auf das Geschäft

wirkt, ist es wichtig, ausgehend von strategischen Treibern, die auf ein

Geschäftsfeld wirken, eine Ursache- /Wirkungskette aufzubauen. Hierzu

ist es nützlich, mit strategischen Aussagen realistische begründete

Geschäftsszenarien zu erstellen, die künftig wahrscheinliche Situationen

plakativ beschreiben. Daraus sollten Auswirkungen bzw. resultierende

Anforderungen an die IT abgeleitet werden. Die spannende Frage ist

dann, welche Maßnahmen mit welchem Ressourcen- und Zeitaufwand in

der existierenden und, im Vergleich dazu, in einer imaginären SOA-getrie-

benen IT ergriffen werden könnten. Beim Vergleich der Zeiten- und Res-

sourcenaufwände von beiden IT-Varianten geht es nicht nur um die ent-

standenen Aufwände, sondern auch um den entgangenen Nutzen auf der

Geschäftsseite durch eine zeitlich verzögerte Unterstützung und Realisie-

rung des Geschäftsvorteils. Sowohl der Aufwand als auch der entgangene

Nutzen ist also für beide IT-Varianten abzuschätzen und miteinander zu

vergleichen.

47

www.hessen-it.de

Dieser berechnete Nutzen kann so noch nicht als Business Case für den

SOA-Piloten verwendet werden, weil die Kosten für die Migration der exis-

tierenden IT auf eine serviceorientierte Architektur noch mitberechnet

werden müssen. Zur Berechnung dieser Kosten müssen die bestehenden

Abhängigkeiten, die im betrachteten Kontext bestehen, sowie die daraus

resultierenden Aufwände für eine Transformation ableitbar sein. Diese

setzt eine Transparenz voraus, wie sie nur durch die konsequente Umset-

zung einer Unternehmensarchitektur möglich ist. Denn in der Regel muss

abgegrenzt werden, welche Prozesse und damit verbunden Fähigkeiten

von einem beschriebenen Geschäftsszenario betroffen sind. Ein Bebau-

ungsplan zeigt dann sofort auf, welche Applikationen diese Fähigkeiten

unterstützen. Wenn darüber hinaus die Betriebsmodelle und Server

bekannt sind, auf denen diese Applikationen betrieben werden, können

diese Informationen genutzt werden, um die aktuellen Kosten zu ermit-

teln. Andererseits wird auch deutlich, welche Anwendungen ersetzt wer-

den müssen, um entsprechende Fachservices neu aufzubauen. Daraus

müssen Kosten für die Entwicklung bzw. Beschaffung der benötigten

Fachservices ermittelt und sowohl die Datenmigration wie auch der tem-

poräre Parallelbetrieb während einer Übergangszeit mit kalkuliert werden.

Kosten- und Ertragsentwicklung eines fiktiven SOA-Projektes in T€

CAPEX = Capital expenditure, Investitionen

OPEX = Operational expenditures, Betriebskosten

2010 2011 2012 2013 2014

CAPEX (Ist) 100 50 20 0 0OPEX Maintenance (Ist) 500 500 400 0 0OPEX Operations (Ist) 600 600 500 0 0

CAPEX (SOA) 0 1.500 1.000 80 80OPEX Maintenance (SOA) 0 200 300 300 300OPEX Operations (SOA) 0 150 300 400 400

Gesamtkosten/Jahr 1.200 3.000 2.520 780 780Einsparungen IT Kosten zu Ist 0 –1.800 –1.320 420 420

Umsatzplus 0 0 1.000 1.500 2.000Prozesseffizienz 0 0 500 1.000 1.200

Gesamt 0 –1.800 180 2.920 3.620

48


Die Tabelle zeigt ein Beispiel für die mögliche Kostenentwicklung in einer

begrenzten SOA-Initiative. Darin sind die parallel anfallenden Kosten der

laufenden Systeme und der neu zu implementierenden SOA-basierten

Systeme in den Jahren 2011 und 2012 berücksichtigt. Bei den IT-seitig

erzielten Einsparungen werden die im Jahre 2010 berechneten 1,2 Mio

Euro als Ausgangskosten verwendet, die als Vergleich konstant über die

weiteren Jahre extrapoliert werden (siehe „Gesamtkosten /Jahr“). So wer-

den die Einsparungen berechnet, die in den Jahren 2011 und 2012 negativ

sind, da dort Investitionen für die Einführung der SOA vorgenommen wer-

den, die die momentanen Betriebskosten übersteigen (siehe „Einsparun-

gen IT-Kosten zu Ist“). Im Jahre 2013 werden erste Einsparungen erzielt, da

die Betriebskosten im Zielsystem geringer ausfallen. Hierunter fallen auch

Effekte, wie die Verringerung von Projektkosten zur Erweiterung der Ser-

vices oder die geringeren Kosten zur Implementierung von Änderungen.

Darüber hinaus werden die Auswirkungen der SOA auf die Geschäftsseite

kalkuliert. Der Umsatz kann gesteigert werden, da durch kürzere Time-

to-Market-Realisierungen neue Produkte eher an den Markt gebracht

werden können, wodurch Marktvorteile entstehen, die in messbaren

Umsatz- und damit in Gewinnsteigerungen resultieren. Ebenso können

Kosten auf der Fachseite eingespart werden, weil die Prozesse schneller

angepasst und effizienter gestaltet werden können (siehe Abbildung

nächste Seite). Hieraus ergibt sich, dass – ohne eine entsprechende Ver-

zinsung zu berücksich tigen – der Nutzen die Kosten bereits im zweiten

Jahr übersteigt. Eine Amortisierung der Investition ist danach bereits nach

drei Jahren erreicht. Das ist eine Perspektive, die auch von einem Chef

nicht ignoriert werden kann und ihn überzeugen dürfte.

49

www.hessen-it.de

Kumulierte Entwicklung eines fiktiven SOA-Projektes

Amortisierung eines fiktiven SOA-Projektes in reiner IT-Perspektive

Eins

par

ung

en in

€

Zeit

Geschäftsorientierter Nutzen von SOA

–3000

–2000

–1000

0

1000

2000

4000

3000

20112010 2012 2013 2014

ProzesseffizienzUmsatzplusIT-Einsparungen

18000

16000

14000

12000

10000

8000

6000

4000

2000

Zeit

SOA-Amortisierung: IT-Bereich (ohne Geschäftsbereich)

IT SOA kumuliert, verzinstIT Bezugslinie kumuliert,verzinst

Kum

ulie

rte,

ver

zins

te K

ost

en in

€

20102012

20142016

20182020

0

50


Betrachtet man die kumulierte Kostenentwicklung eines SOA-Projektes

lediglich in der IT-Perspektive und projiziert man die aktuellen, jährlichen

Kosten konstant in die Zukunft, so erhält man bei einer Verzinsung von

acht Prozent erst eine Amortisation nach ca. zehn Jahren. Diese Perspek-

tive wird keinen Chef zu einer Investition veranlassen.

Eine rein IT-bezogene Betrachtung des SOA-Nutzens ist in vielen

Fällen nicht überzeugend. Der Geschäftsnutzen ist unbedingt mit

zu berücksichtigen.

SOA sollte man deshalb grundsätzlich mit Bezug zum erzeugten

Geschäftsnutzen darstellen und kommunizieren. Dabei ist es hilfreich, die

strategischen Treiber, die auf ein Geschäftsfeld wirken, zu kennen, und

daraus diejenigen zu identifizieren, die durch SOA positiv beeinflusst

werden. Es sollten diejenigen Prozesse herausgesucht werden, die diese

Treiber am stärksten fördern, und damit die Fähigkeiten, die von diesen

benötigt werden. Daraus können die involvierten Applikationen abge -

leitet werden, die in eine serviceorientierte Architektur überführt werden

müssten. So erfolgt eine strategisch determinierte Auswahl eines Berei-

ches, der von einer SOA am meisten profitiert. Diese strategisch getrie-

bene Auswahl und Abgrenzung eines Geschäftsbereiches hilft, den Nut-

zen von SOA geschäftsorientiert darzustellen. Eventuell kann diese mone-

täre Kalkulation durch weitere qualitative Kennzahlen, die an den invol-

vierten strategischen Treibern orientiert sind, ergänzt werden.

Die folgende Abbildung zeigt in diesem Zusammenhang einen Ausschnitt

aus der beschriebenen Ursache- /Wirkungskette – von den bereits aus

strategischen Gesichtspunkten selektierten Prozessen über die sie unter-

stützenden Fähigkeiten zu den Applikationen. Hieraus kann sowohl die

bestehende Situation wie auch die künftig gewünschte, serviceorientierte

Ausrichtung der Anwendungsarchitektur entnommen werden.

51

www.hessen-it.de

Ursache- / Wirkungszusammenhänge zwischen Prozessen (oben)

über Domänen / Fähigkeiten (Mitte) und Applikationen (unten)

Anhand derartiger Darstellungen kann kommuniziert werden, wie die

Komplexität durch SOA reduziert, die Qualität gezielt verbessert und

dadurch die Kosten nachvollziehbar gesenkt werden können. Damit kön-

nen dann Aussagen getroffen werden, die wie in der folgenden Abbil-

dung visualisiert werden können. Diese eher plakativen Darstellungen

sind einprägsam und reduzieren die Botschaft auf wesentliche, geschäfts-

wirksame Aussagen.

Sub-processes

Prozessmodell

Analyse & Design

Fähigkeiten

Domänenmodell

Fähigkeiten

ITP

ITF

ITx

App.2

App.3

App.1 App.4 App.5

App.6

App.7

App.8

App.9

App.10

App.12

App. 11

App.13

App.16

App.15

App.14

App.x

App.17

Bebauungsplan

As-is Applikationen Target architecture (Master plan)

Domäne x Construction

App.16

App.15

App.14 App.7

App.8

App.9

App.10

App. 11

App.2

App.1 App.4

52


Kosteneinsparungsnutzen von SOA, beispielhaft illustriert

4.5 Fazit

Bevor SOA der Geschäftsleitung oder den Entscheidungsträgern eines

Unternehmens präsentiert werden kann ist eine gute, gründliche Vorberei-

tung erforderlich. Die Zusammenhänge zwischen den verschiedenen

Geschäftsfeldern müssen erörtert und verstanden werden. Dies ist in der

Regel durch eine gute Architekturarbeit zu erreichen. Es sollte eine Unter-

nehmensarchitektur erarbeitet werden, die für die Identifizierung und

Abgrenzung der für die serviceorientierte Architektur optimalen Ge -

schäfts bereiche von erheblichem Nutzen ist und somit für die benötigte

Transparenz sorgt. Mit ihr kann die Migration zur neuen SOA-Welt exakt

geplant und der durch SOA zu realisierende Nutzen genau abgeschätzt

und quantifiziert werden. Wenn im ausgewählten Bereich die Transforma-

tion in eine serviceorientierte Architektur ohne Risiko und im geplanten

Zeit- und Kostenrahmen bewerkstelligt werden kann, sollte das SOA-Vor-

haben in einer Art und Weise präsentiert werden, die den Chef mit seiner

Sprache abholt und ihm anschaulich und plakativ die wesentlichen Bot-

schaften vermittelt. Nach erfolgtem Entscheid für das SOA-Projekt kann

dann die SOA-Implementierung begonnen werden, um den versproche-

nen Nutzen wie geplant reibungslos und nachweisbar zu realisieren.

KostensenkungVerringerung der Variantenvielfalt

IstSoll

IstSoll

280

100

10

2

Ist Soll

Ist Soll

–68%

–83%

–25%

–15%# Applikationen

# BetriebsmodelleLa

yer

Laye

rLa

yer

Core

Sub-processes

Prozessmodell

Analyse & Design

Fähigkeiten

Domänenmodell

Fähigkeiten

ITP

ITF

ITx

App.2

App.3

App.1 App.4 App.5

App.6

App.7

App.8

App.9

App.10

App.12

App. 11

App.13

App.16

App.15

App.14

App.x

App.17

Bebauungsplan

As-is Applikationen Target architecture (Master plan)

Domäne x Construction

App.16

App.15

App.14 App.7

App.8

App.9

App.10

App. 11

App.2

App.1 App.4

Thin Client

Thin Client

Rumba

ServerORACLE

WIN 2003x86

ServerORACLE

WIN 2003x86

RUV Permanent Proc.RUV Task

Shared DB2z/OS parallel Sys plex

IBM zSeries

Front-End-

Server

Back-End-

Server

Host

Clearing-DTA, etc.

FTP

FTP/DTA

HTTPS, etc.Encaps. 3270/DTA

Zentraler Mainframe mit Windows Front-/Back-Ends

53

www.hessen-it.de

SOA-Governance: Warum Investitionen in Menschen wichtigersind als in Monitoring-Tools

Thomas Mironiuk, Intersystems GmbH

Zu Recht wird serviceorientierte Architektur (SOA) heute in einem Atem-

zug mit Business Prozess Management (BPM) genannt, war sie doch von

Anfang an als Methode zur Prozessoptimierung gedacht. Wie so viele

sinnvolle Ansätze aus der IT leidet sie allerdings, seit der Begriff von Gart-

ner kreiert wurde, an akuten Kommunikationsproblemen. Geradezu sträf-

lich wurde versäumt, den an den zu optimierenden Prozessen beteiligten

oder von ihnen betroffenen Menschen eine verbindliche und allgemein-

verständliche Definition von SOA an die Hand zu geben. Bis heute können

sich Industrie und Wissenschaft nicht einmal auf eine gemeinsame Defini-

tion von SOA für die IT einigen. „SOA ist ein Paradigma für die Strukturie-

rung und Nutzung verteilter Funktionalität, die von unterschiedlichen

Besitzern verantwortet wird.“, lautet die Definition der Organization for the

Advancement of Structured Information Standards (OASIS). Sicherlich

richtig, aber lebensfern. Jenseits der Kreise, die sich mit IT-Infrastrukturen

im Unternehmen beschäftigen, dürfte man viel eher den Satz zu hören

bekommen: „Gestern wurden Mitarbeiter wegrationalisiert, heute machen

wir SOA.“

5

54

SOA-Governance: Warum Investitionen in Menschen wichtiger sind als in Monitoring-Tools

© p

ress

mas

ter

- Fo

tolia

.co

m

5.1 Definition „SOA-Governance”

Die Herausforderung, diesen Missstand auf Unternehmenseben zu behe-

ben, fällt in den Aufgabenbereich der SOA-Governance, der Kontrolle

und Steuerung von serviceorientierten Prozessen. Das Problem hierbei ist

nur, dass die Vorstellung aller Beteiligten, was genau SOA-Governance

sein soll, noch unpräziser ausfällt als bei SOA selbst. 2008 definierte der

Branchenverband BITKOM in einem SOA-Leitfaden den Begriff der SOA-

Governance als: „Definition, Durchsetzung und Steuerung von organisa-

torischen Regeln, Richtlinien und Standards zur konsequenten Ausrich-

tung der Services und Geschäftsprozesse an der Unternehmensstrategie

durch geeignete Steuerungs- und Kontrollmaßnahmen. IT-Governance im

konventionellen Sinne befasst sich hingegen mit der Organisation, Steue-

rung und Kontrolle der IT und der IT-Prozesse. Diese Aufgabe wird jedoch

immer noch zu technisch gesehen. Durch die Einführung einer SOA rückt

der Fokus auf Services und Geschäftsprozesse auch in den Mittelpunkt

der IT-Governance“.

Mittlerweile wird der Begriff „Governance“ ähnlich inflationär gebraucht

wie der Begriff Management, weil sich damit herrlich verschleiern lässt,

dass derjenige, der ihn nutzt, nur eine verschwommene Vorstellung von

dem hat, was zu tun ist. Und wie bei des Kaisers neuen Kleidern traut man

sich nicht nachzufragen – zu groß die Angst, Unkenntnis einzugestehen.

Neusprachlich leitet sich der Begriff vom französischen Wort „gouverner“

ab, was so viel wie verwalten, leiten oder erziehen heißt. Sicherlich alles

Tätigkeiten, die im Rahmen von Governance anfallen. Folgt man dem

Wort aber zu seinen historischen Wurzeln, findet man das griechische

„kybernan“, was bedeutet, das Steuerruder zu führen. Alle, die an der

SOA-Governance beteiligt sind, sollten sich diesem Ursprung verpflichtet

fühlen, denn die Aufgabe, die ihnen bevorsteht, besteht darin, die Anwei-

sungen des Kapitäns bzw. CEOs in einen schnellen, aber sicheren Kurs für

Schiff und Mannschaft umzusetzen. Dabei geht es dann eben nicht darum

zu verwalten, sondern zu führen.

55

www.hessen-it.de

Zu einer der ersten Aufgaben der SOA-Governance gehört daher die

Entwicklung eines Governance-Plans, einer Seekarte durch die SOA-

Untiefen. Dies bedarf natürlich einiger Vorbereitungen. Da ist zunächst

das Bekenntnis von Geschäfts- und IT-Leitung einzuholen, SOA zu einem

langfristigen integralen Bestandteil der IT-Strategie des Unternehmens zu

machen. Trotzdem sollten die ersten Projekte so angelegt sein, dass sich

kurzfristig sichtbare Vorteile ergeben, um die generelle Akzeptanz von

SOA für die Zukunft zu fördern. Das wahre Potenzial spielt eine solche

Architektur aber erst dann aus, wenn der Pool an verfügbaren Services

echte Mehrwertanwendungen erlaubt und Prozesse problemlos neu

angelegt oder verändert werden können. SOA ist kein Sprint, sondern ein

Weg, und der, so Kafka, entsteht dadurch, dass man ihn geht.

Desweiteren sollten die an der SOA-Governance Beteiligten eine ehrliche

Bestandsaufnahme der Ressourcen und Fähigkeiten durchführen und

dann festlegen, welche Ziele SOA für das Unternehmen erreichen soll.

Der „Alles-Ansatz“, Kosten senken, Flexibilität erhöhen und Mehrwerte

schaffen, eignet sich zwar hervorragend, um Erfolge zu vermelden, wo

positive Ergebnisse trotz vollständigen Scheiterns der ursprünglichen

Mission zu Buche schlagen wie bei Christoph Kolumbus, nicht aber für ein

qualifiziertes Measuring und Controlling. Unbedingt muss die SOA-

Governance auch in Einklang mit den anderen Steuerungsmodulen im

Unternehmen gebracht werden, von Corporate-Governance über BPM-

Governance bis zur Data-Governance. Hier sind gegebenenfalls erste

Anpassungen im Nicht-IT-Umfeld notwendig, sollten sich Teile der Rege-

lungen als untauglich oder hinderlich für die erfolgreiche Implemen -

tierung einer SOA im Unternehmen erweisen.

Ist er erst einmal erstellt, enthält der SOA-Governance-Plan dann alle

Informationen, um neue Mitglieder im Governance-Team umfänglich über

Ziel, Ressourcen, Hierarchien, Policies und Kommunikationsmaßnahmen

zu informieren. Zudem gibt er formale Strukturen, zum Beispiel in Form

von Abzeichnungsbögen vor, um die Integrität der Dokumentation zu

sichern.

56


5.2 Soziale Auswirkungen

Die im Pan verzeichneten Ressourcen umfassen nicht nur Gebäude und

die IT-Infrastruktur, sondern vor allem Mitarbeiter. Team-Rollen und Ver-

antwortlichkeiten sowie die damit einhergehenden individuellen Rollen

und Pflichten sind essenzieller Bestandteil eines jeden Governance-Plans.

Dabei darf getrost davon ausgegangen werden, dass die neuen Teams

wenig mit den alten Abteilungsstrukturen zu tun haben. Noch bevor SOA

mit neuen oder veränderten Prozessen im Makrokosmos Unternehmen für

Unruhe sorgt, wirbelt sie den Mikrokosmos der IT-Abteilung durchein -

ander. Holt man neue Leute für das SOA-Projekt, geht auf Leitungsebene

der Machtkampf um Personalstellen los, während gestandene Mitarbeiter

sich in ihrer Wertschätzung zurückgesetzt fühlen. Hat man alle benötigten

Qualifikationen schon im Unternehmen, kommt es unweigerlich zu Ver-

schiebungen innerhalb der Leitungshierarchie, während sich gleichzeitig

Karriereziele und Aufstiegspfade verändern oder gar verschwinden.

Wer glaubt, ohne entsprechende Optionen und Angebote für die betrof-

fenen Mitarbeiter eine Politik allein „zum Wohle des Unternehmens“

durchsetzen zu können, stößt daher schnell an seine Grenzen. Schlep-

pende Umsetzung und innere Kündigung sind noch die harmlosesten

Folgen. Wenn erhoffte Beförderungen nicht mehr möglich sind oder

Arbeitszeit und Arbeitsort zu privaten Problemen führen, verliert das

Unternehmen unter Umständen für den Erfolg der SOA-Strategie wesent-

liche Mitarbeiter. Erfahrung mit der Unternehmensstruktur und -kultur

kann nicht einfach durch fachliche Kompetenz eines neuen Mitarbeiters

ersetzt werden, von der Projektverzögerung ganz zu schweigen.

57

www.hessen-it.de

Kommunikation und Vermittlung des Governance-Plans sollten sich daher

nicht auf die rein fachlichen Informationen und Maßnahmen für die IT-Mit-

arbeiter respektive die Prozessinhaber der Fachabteilungen beschränken.

Zugleich sind ein der Kultur des Unternehmens entsprechendes Anreiz-

oder Belohnungssystem zu schaffen und Karrierealternativen aufzuzeigen.

Bei der Formulierung dieses Angebots für die Beschäftigten handelt es sich

zugleich um die Generalprobe für das Gesamtunternehmen. SOA-unter-

stütztes BPM wird immer wieder nicht nur Abläufe, sondern auch struktu-

relle Zuständigkeiten verändern. Eine Belegschaft, die darauf vertrauen

kann, dass ihre Interessen bei solchen Planungen berücksichtigt werden,

steht zukünftigen Änderungen deutlich aufgeschlossener gegenüber.

58


© A

ndre

s R

od

rig

uez

- Fo

tolia

.co

m

5.3 Governance realisieren

Steht der Plan, gilt es ihn in die Tat umzusetzen. Dabei zeigt sich sehr

schnell, dass SOA-Governance ein fließender Prozess ist. Das SOA Center

of Excellence (COE) wird im Laufe der Zeit neue Mitglieder bekommen,

Hard- und Software werden sich auf neue Technologien und Produkte ein-

stellen, Prozesse anhand von Erfahrungen optimiert oder zu Best-Practices

erklärt werden. Insbesondere Fragen der Wiederverwendung von Ser-

vices (service reuse), der Kostenverteilung und eines Anreizsystems für

den Reuse sowie der Art und Vergütung von Service-Level-Agreements

(SLA) sind nicht immer schon im Vorfeld eindeutig festzulegen. Nach den

ersten SOA-Teilprojekten können dann sukzessive Maßnahmen in die

Wege geleitet werden, die gezielt nach Aktivposten suchen und solche

verwalten, Monitoring-Tools implementieren und Mitarbeiter auf allen

Ebenen über neue Prozesse und erwartetes Verhalten schulen und infor-

mieren.

Umfragen zeigen, dass diejenigen Unternehmen erfolgreicher abschnei-

den, die ihre für SOA benötigte Software gezielt nach deren Fähigkeiten

auswählen, als solche, die sich blind auf eine Suite verlassen. Trotzdem

sind Fragen der richtigen Infrastruktur oder Entwicklungsumgebung, nach

Herstellerunabhängigkeit und Standards leichter zu lösen als solche, die

Jobprofile und Personalüberlegungen beinhalten. Zu den grundlegen-

den Aufgaben der SOA-Governance gehört, sich Gedanken zu Lebens -

zyklen von Services zu machen, Composite Applications zu schaffen oder

Regeln und Strukturen für den Umgang mit von außen eingekauften Ser-

vices zu definieren und für deren Einhaltung zu sorgen. Die hierzu benö-

tigten Mittel wie Excellence-Center oder Service-Level-Agreements sind

bewährte Elemente innerhalb der IT. Dies ist Segen und Fluch zugleich.

59

www.hessen-it.de

5.4 Governance kommunizieren

Da SOA-Governance bewusst die Fachabteilungen in die Prozesse mit

einbezieht, ist die IT gezwungen, mit Nichtfachleuten über Fachbegriffe zu

reden. Plötzlich muss die Kommunikation ohne Meta-Wissen auskommen,

es verlieren die stillschweigenden Voraussetzungen und Übereinkünfte

ihre Wirkung, die immer dann in Kraft sind, wenn Fachleute eines Berufs-

standes unter sich sind. Im Idealfall reden IT-Spezialisten mit ihren Kolle-

gen aus den Fachabteilungen so, wie es Verbraucherschützer inzwischen

von Kundenberatern in Banken fordern: „Setzen Sie nichts voraus.“ Um

verständlich zu werden, müssen vor allem Zahlen in einen Kontext

gebracht werden, den die Fachabteilungen verstehen. Was bedeutet ein

vereinbarter Service-Level? Warum machen Millisekunden bei Response-

Zeiten einen Unterschied? Was verbirgt sich hinter Service-Versionen?

Wem das zu banal klingt, der stelle sich einfach nur vor, er wäre von jetzt

auf gleich auf das Handelsparkett der Deutschen Börse in Frankfurt

gestellt. Die Sprache in der IT entwickelt sich mindestens so rasch weiter

wie die Technologie selbst und erinnert manchen branchenfremden Men-

schen an die Geheimsprache der mittelalterlichen Handwerksbünde.

Holen Sie sich soziale Kompetenz ins SOA-Team und betreiben Sie

intern SOA-PR und -Marketing!

60


Wenn man also verhindern will, dass SOA scheitert, obwohl man tech-

nisch alles richtig macht, gilt es zwei Dinge zu beherzigen: Zum einen ist

rechtzeitig soziale Kompetenz ins SOA-Governance-Team zu holen, um

die Auswirkungen von Prozessänderungen auf die Mitarbeiter zu bewer-

ten und gegebenenfalls abfangen zu können. Zum anderen darf man sich

nicht zu schade für interne PR und internes Marketing sein. Keine gute

Idee verkauft sich von alleine und eine SOA schon gar nicht. Während es

außerhalb der IT-Abteilung Verlustängste und Widerstände zu über -

winden gilt, muss innerhalb womöglich gegen den „Alles schon mal

dagewesen“-Faktor angekämpft werden. SOA ist zugegebenermaßen

lediglich der aktuellste einer ganzen Reihe von Ansätzen, IT-Abläufe und

Unternehmensprozesse zu harmonisieren. DCOM (Distributed Com -

ponent Object Model), DCE (Distributed Computing Environment) und

CORBA (Common Object Request Broker Architecture) kamen alle mit

ähnlich vollmundigen Versprechungen daher, um dann wieder in der

Versenkung zu verschwinden.

5.5 Fazit

Um SOA-Governance erfolgreich umzusetzen, reichen fachliche Qualifi -

kationen allein nicht aus. Investitionen in die Softskills des Governance-

Teams sind für den Erfolg der SOA im Unternehmen entschieden wich -

tiger als die Anschaffung etwa eines Monitoring-Tools. Ohne solche

Software lässt sich eine SOA zur Not realisieren, aber ohne die Fähigkeit,

die Belegschaft für SOA zu begeistern, ist das Scheitern von Anfang an

vorprogrammiert.

61

www.hessen-it.de

SOA-Security: Webservices erfordern zusätzlicheSicherheitsmaßnahmen

Dr. Bruno Quint, Corisecio GmbH

6.1 Grundlagen

Serviceorientierte Architekturen (SOA) entwickeln sich von einem Hype-

Thema zu realen Projekten. Die Idee, Funktionalitäten und Aufgaben als

lose gekoppelte, unabhängige, austauschbare Dienste über standardi-

sierte Schnittstellen anzubieten, ermöglicht Unternehmen flexibler auf

sich ändernde Geschäftsprozesse zu reagieren. Um den Vorteil der Flexi-

bilität und die damit verbundene Kostenersparnis zu erreichen, müssen

einzelne Services bestimmten Anforderungen genügen. In der Literatur

existiert eine Vielzahl von Kriterien an Services – die verbreiteten sind:

a Standardisierte Service-Schnittstellen

– um die Interoperabilität sicherzustellen

a Lose Kopplung

– ein Minimum an Abhängigkeiten muss die Modellierbarkeit

verschiedener Services zu einem Geschäftsprozess erlauben

a Funktionsabstraktion

– fordert eine Kapselung von Funktionen

a Wiederverwendbarkeit

– ist eine Grundanforderung zur Erreichung von Kostenersparnissen

a Service-Autonomie

– ermöglicht das (weitgehend) autarke Agieren von Services

a Vorratsdatenfreiheit des Services (Statelessness)

– persistente Daten werden nur gespeichert,

wenn sie explizit Dienstleistungsbestandteil des Service sind

a Auffindbarkeit des Services

– über definierte Repositories

a Orchestrierbarkeit der Services

– um einzelne Services zu einem Gesamtprozess zu verbinden

6

62

SOA-Security: Webservices erfordern zusätzliche Sicherheitsmaßnahmen

Grundsätzlich ist SOA ein Managementkonzept. Es schreibt keine kon-

krete technische Realisierung oder bestimmte Methoden vor. Allerdings

haben sich Web Services (basierend auf SOAP/XML) zur Realisierung

durchgesetzt. Ein Web Service ist eine auf XML (eXtensible Markup

Language) und SOAP (Simple Object Access Protocol) basierende

Anwendung, die definierte Methoden über eine standardisierte Schnitt-

stelle anbietet und über eine URI (Uniform Resource Identifier) eindeutig

identifizierbar macht. Als Kommunikationsprotokoll dient SOAP (W3C),

mit dem Daten zwischen Systemen ausgetauscht werden können. SOAP

verwendet XML zur Datenrepräsentation sowie (in den meisten Fällen)

TCP/IP für den Transport.

Zu einer SOA-Infrastruktur gehört weiterhin ein Service Repository, wel-

ches meist über UDDI (Universal Description, Discovery and Integration)

und WSDL (Web Services Description Language) realisiert wird.

6.2 Sicherheitsanforderungen

Im Grunde gelten für SOA die gleichen Sicherheitsanforderungen wie für

herkömmliche monolithische Systeme. Zusätzlich existieren durch die Ver-

teilung von Systemen und Prozessen aber SOA-spezifische Sicherheits -

risiken, die entsprechend zu berücksichtigen sind.

Wie in monolithischen Systemen müssen auch in SOA-Infrastrukturen

Identitäten und Berechtigungen verwaltet, Benutzer authentisiert, Zugriffs-

berechtigungen überprüft, Zugriffe und Zugriffsversuche aufgezeichnet

und Daten mittels kryptografischer Methoden signiert (Integrität) oder

verschlüsselt (Vertraulichkeit) werden. Gerade in verteilten Umgebungen

werden zudem systemweite Sicherheitsrichtlinien (Policies) benötigt,

deren Einhaltung (Compliance) es permanent zu überwachen gilt.

Die Bedrohungspotentiale lassen sich grob in zwei Kategorien einteilen.

Zum einen wird eine SOA-Infrastruktur basierend auf einem Netzwerk /

IT-System allgemeinen Gefahren wie Malware, Buffer Overflows, Back-

doors, Netzangriffen (Scanning, Spoofing, etc.) sowie Denial of Service

(DoS) und vielen mehr ausgesetzt.

63

www.hessen-it.de

Der Grundgedanke von SOA wirft zum anderen weitere Anforderungen

und Bedrohungspotentiale auf, die durch die Integration verteilter und

teilweise heterogener Systeme insbesondere zu beachten sind. So

müssen Replay-Attacks, Service-Kompromittierung sowie unberechtigte

Service-Nutzung durch adäquate Mechanismen verhindert werden.

In herkömmlichen IT-Infrastrukturen wird die Anmeldung des

Benutzers zu Beginn einmal durchgeführt und dann läuft der Geschäftsprozess

in diesem Kontext sicher in der Applikation ab (siehe oben).

In verteilten Service-Infrastrukturen werden Nachrichten (Web Services) zwischen

benötigten Service Applikationen versendet. Der Sicherheitskontext zwischen dem

anfragenden und dem liefernden Service muss über zusätzliche Mechanismen

bereitgestellt werden (siehe unten).

UserID /

Password

Service

Service

Application

Service

Service

64


Die Realisierung eines Geschäftsprozesses über eine Vielzahl lose ge -

koppelter Services erfordert zudem mehr Authentisierungs- und Autori-

sierungsvorgänge, eine jederzeit gewährleistete Vertraulichkeit sowie

eine höhere Integrität als in einem monolithischen System. Ein Prozess -

design über Unternehmensgrenzen hinweg und zwischen unternehmens-

fremden Teilnehmern verstärkt diese Sicherheitsanforderungen an Servi -

ces und Lösungen und setzt so genannte Federation-Konzepte voraus.

Technisch gesehen muss dabei die Interoperabilität sichergestellt wer-

den. Zu nennen sind an dieser Stelle bspw. die Umwandlung von Identi -

täten und deren Formate, der Einsatz von Industriestandards und die

Gewährleistung der Wiederverwendbarkeit von Security-Diensten.

Die herkömmlichen Sicherheitsanforderungen müssen

um diverse SOA-spezifische Ausprägungen erweitert werden.

Im folgenden Abschnitt sollen die Sicherheitsmechanismen und Security-

Standards kurz dargestellt werden. Eine einleitende Diskussion über den

Einsatz herkömmlicher Methoden im SOA-Umfeld zeigt die Notwendig-

keit neuer Sicherheitslösungen auf.

65

www.hessen-it.de

6.3 Sicherheitsmechanismen

Schwächen herkömmlicher Ansätze

Wie zuvor aufgezeigt, stellt eine serviceorientierte Architektur zusätzliche,

neue Anforderungen an die Informationssicherheit in den Unternehmen.

Herkömmliche Schutzmaßnahmen auf Transport- und Applikationsebene

stoßen beim Einsatz in SOA an ihre Grenzen und bieten keinen aus -

reichenden Schutz. So ist die Absicherung von Web Services mittels TLS

(Transport Layer Security) oder SSL (Secure Sockets Layer) unzureichend.

Schließlich bietet TLS/SSL lediglich eine Sicherheit auf Transport-Ebene

für eine definierte Punkt-zu-Punkt-Verbindung. Die Sicherheit kann nach

dem Eingang im Zielsystem nicht mehr gewährleistet werden und der

Sicherheitskontext geht verloren. In einem nachrichtenbasierten Workflow

über mehrere Knoten und Teilnehmer bedeutet dies, dass beispielsweise

nicht mehr sicher nachvollzogen werden kann, wer eine Bestellung auf -

gegeben hat oder wer von welcher Stelle als vertrauenswürdig bestätigt

wurde. Zudem sind geforderte Security-Operationen auf Elementebene

(bspw. für Signatur und Verschlüsselung der Kreditkarteninformationen)

mit TLS nicht zu realisieren, da lediglich der Transport der gesamten Nach-

richt gesichert wird.

Herkömmliche Firewall-Technologie (Transport Layer Firewalls) kann

lediglich eine Netzwerksicherheit gewährleisten und ist somit zwar not-

wendig, aber keineswegs ausreichend. Eine Inspektion der Nachrichten

auf Schadsoftware ist ebenso wenig möglich wie die Überprüfung der

Gültigkeit von Inhalt oder Absender. Die Weiterentwicklung von her-

kömmlichen Firewalls zu XML-Firewalls erlaubt zwar ein Durchsuchen

(Parsen) der Nachrichten und rudimentäre Content-Inspection, diese sind

aber für einen Einsatz zur Durchsetzung einer Security Policy nicht aus -

reichend. Neben der Administrations- und Kostenproblematik, vor jeden

Service eine XML-Firewall zu platzieren, stoßen diese Technologien

spätestens bei transformierten Nachrichten (durch Verschlüsselung,

Signatur oder Security Token) an ihre Grenzen.

66


Traditionellerweise wird ein Teil der Sicherheit (wie Authentisierung und

Autorisierung) innerhalb der Applikation umgesetzt. Dies ist aber in einer

SOA-Umgebung bereits aufgrund der Inflexibilität problematisch. Bei

neuen Security-Anforderungen müsste jede betroffene Applikation ge -

ändert werden. Eine zentrale Administration fehlt. Notwendig wäre weiter-

hin die Implementierung der Security-Funktionalität in jeder Applikation

und jedem Service. Das Grundprinzip der losen Kopplung und die damit

verbundene Flexibilität würde durch eine starre Security-Implementie-

rung verloren gehen. Der Anpassungsaufwand für die Security-Lösung

würde ein flexibles Design von Geschäftsprozessen stark einschränken.

Eine mögliche Alternative bietet ein streng zentraler Architekturansatz.

Dabei wird die Security-Logik aus der Applikation herausgenommen und

in einem zentralen Server vorgehalten. Simple Agenten außerhalb der

Applikation fragen den zentralen Server zur Umsetzung der Policy bei

jedem Aufruf an. Ein solcher Ansatz ist nur bedingt geeignet. Zwar ist die

Beherrschbarkeit und Administration gewährleistet. Jedoch wirkt sich

diese Struktur nachteilig auf Aspekte wie Ausfallsicherheit, Netzwerk -

traffic, Lastverteilung und Skalierung aus. Security-Lösungen für SOA-

Infrastrukturen erfordern flexible Architekturansätze, die die beschrie -

benen Aspekte abdecken.

67

www.hessen-it.de

Sicherheitsstandards

Um die Schwächen herkömmlicher Sicherheitsmechanismen zu beheben

und SOA-spezifische Anforderungen zu erfüllen, existieren zahlreiche

Techniken und Methoden, die speziell für den Einsatz in nachrichten- und

dienstorientierten Infrastrukturen entwickelt wurden. Insbesondere die

von den Standardisierungsgremien (W3C und OASIS) verabschiedeten

Standards bieten Basistechnologien, die neben der Sicherheit auch die

Interoperabilität gewährleisten. Allen gemein ist dabei, dass die Sicher-

heit und Sicherheitsinformationen auf Nachrichtenebene implementiert

werden und somit die Schwächen von Sicherheitsmechanismen auf Trans-

portebene, wie z. B. SSL/TLS überwunden werden.

Aufgrund der Vielzahl von Sicherheitsstandards und -methoden

werden an dieser Stelle nur die wichtigsten kurz vorgestellt:

a XML-Encryption

Diese Spezifikation legt fest, wie und in welcher Form XML-

Dokumente innerhalb der XML-Syntax verschlüsselt werden.

a XML-Signature

Die XML-Digital-Signature-Specification legt die Regeln und die

Syntax fest, mit denen digitale Unterschriften für XML-Elemente

erzeugt werden.

a Web Service (WS)-Security

Grundidee des von Microsoft, IBM und Verisign entwickelten

Standards war es, eine Spezifikation zu erstellen, die zeigt, wie

die vorhandenen Basistechnologien XML-Encryption, XML-

Signa ture und XML-Key Management in SOAP integriert werden

können. Dieser Standard bildet somit die Schnittstelle zwischen

vorhandenen Security-Technologien und dem Web Service-

Standardformat SOAP.

68


a SAML (Security Assertion Markup Language)

SAML ist ein Standard zum Transport von Authentisierungs-

und Autorisierungsinformationen innerhalb von Web Services.

Er ermöglicht die Einbringung erweiterter Sicherheitsinforma -

tionen in SOAP-Dokumente als auch die Realisierung von

Single Sign On (SSO)-Szenarien.

a XKMS – XML Key Management Specification

Die XKMS-Spezifikation beschreibt Möglichkeiten für den Aus-

tausch und die Überprüfung von Zertifikaten innerhalb einer PKI.

Durch die Standardisierung wird zudem die Kompatibilität

verschiedener PKI sichergestellt.

Des Weiteren sei an dieser Stelle auf die Spezifikationen von

WS-Trust, WS-Policy sowie WS-Federation verwiesen.

Nicht-standardisierte Sicherheitsmechanismen

Neben standardisierten Sicherheitsmechanismen müssen auch in SOA-

Umgebungen herkömmliche Bedrohungen wie Netzattacken abgewehrt

werden. Wie im Abschnitt 6.2 dargelegt, sind an die Umsetzung und

Implementierung von SOA-Lösungen besondere Anforderungen gestellt,

die die traditionellen Umsetzungen nicht erfüllen. Diese müssen sozu -

sagen „SOA-enabled“ werden.

69

www.hessen-it.de

Single Sign On (SSO)

Richtig eingesetzt ermöglichen SSO-Methoden gleichsam erhöhte Sicher-

heit, niedrigere Verwaltungskosten sowie verbesserte Benutzbarkeit. In

SOA-Szenarien mit einer Vielzahl integrierter Systeme und Services mit

dementsprechend vielen Policy Enforcement Points kann ein SSO-System

diese Vorteile voll und ganz ausspielen. Voraussetzung ist aber ein SOA-

fähiges SSO-Konzept. In realen SOA-Szenarien authentifiziert sich ein

Nutzer nicht direkt an den jeweiligen Backendsystemen, sondern an

zentraler Stelle, meistens an einer Portalanwendung. Alle weiteren An -

meldungen erfolgen über technische User-Konzepte.

SSO nutzt daher ein Benutzer- und Credentialmapping, um Anwendun-

gen mit unterschiedlichen Authentisierungsinformationen zu bedienen.

Zudem besteht die Möglichkeit zur Schaffung einer zentralen Entität.

Dafür müssen Entitäten aus verschiedenen Quellen (Meta Directories,

Datenbanken, etc.) angebunden, ausgelesen, importiert und synchroni-

siert werden. Werkzeuge, die manuell oder über automatisierte Läufe ein

Mapping (Beziehung schaffen) zwischen gleichen Entitäten erlauben,

helfen bei der Umsetzung und Pflege. Die Authentisierungsdaten können

dann über verschiedene Mechanismen (z. B. Agentensysteme) an die

angebundenen Systeme geliefert werden. Gerade bei der Anbindung

von Legacy-Systemen ist es vielfach erforderlich, die Anmeldeinformatio-

nen zusätzlich in ein anderes Format zu transformieren. Dabei kann eine

Anmeldung auf Nachrichtenebene (im Gegensatz zu sitzungsbasierten

Systemen) von Agenten ausgeführt werden und eine Anmeldung in

Formaten der Legacy-Anwendungen ist möglich.

70


Web Application Firewall (WAF)

Eine WAF-Technologie ist notwendig, aber nicht hinreichend, um Services

sowie den Nachrichtenaustausch umfassend abzusichern. So ist der Schutz

vor SQL-Injections, Brute Force, Denial of Service-Attacken durch eine

WAF zu gewährleisten. Dennoch stoßen herkömmliche Web Application

Firewalls bei der Behandlung von Web Services schnell an ihre Grenzen.

Gerade bei verschlüsselten SOAP-Nachrichten sind diese Lösungen nicht

in der Lage, Angriffe zu identifizieren bzw. abzuwehren. Durch Nachrich-

tentransformation und das Hinzufügen weiterer Sicherheitsmerkmale auf

Nachrichtenebene gestaltet sich auch die Schema-Validierung schwierig.

Ausschließlich die Datentypen/Requests, die von einer WAF überprüft wer-

den können, dürfen an diese übergeben werden. Andere Aufgaben, wie

beispielsweise Content Inspection von verschlüsselten Nachrichten und die

Überprüfung der Signatur müssen von der Lösung selbst durchgeführt bzw.

an andere Lösungen zur Prüfung weitergeleitet werden. Die Übergabe von

mutmaßlich ungültigen Daten (bspw. verschlüsselte SOAP-Nachrichten)

würde zu einem Fehler führen und das Ergebnis wäre nicht verlässlich.

Zudem besteht eine Kosten- und Administrationsproblematik beim her-

kömmlichen Einsatz von WAF. Durch die verteilte Systemstruktur in SOA-

Umgebungen würde es bedeuten, dass jeder Service durch eine WAF gesi-

chert werden müsste. Dies ist bei einer Vielzahl verteilter Services nicht

kosteneffizient, da für jeden Service-Provider eine dedizierte WAF bereit -

gestellt werden müsste. SOA-Lösungen müssen einen Service bereitstellen,

der eine WAF für mehrere Services (in einer Domäne etc.) nutzbar macht.

Anti Virus (AV)

Viren und Malware müssen selbstverständlich auch in einer SOA Berück-

sichtigung finden. SOA-spezifische Anforderungen an die AV-Lösung sind

bspw. die Überprüfung von SOAP-Attachments. Des Weiteren gelten für

Anti Virus-Lösungen ähnliche Rahmenbedingungen wie im Abschnitt Web

Application Firewall beschrieben. Insbesondere Lizenz- und Betriebskosten

lassen sich durch zentrale Anti Virus-Services deutlich senken. Beim Einsatz

von Agenten ergeben sich Vorteile durch die Möglichkeit der Modellierung

von Virus-Prüfungen innerhalb einer gesamten Security-Logik.

71

www.hessen-it.de

6.4 Methoden zur Umsetzung

Unternehmen können viele der bisher beschriebenen Ansätze und ins -

besondere offene Sicherheitsstandards manuell implementieren und

umsetzen. Die WS-Security-Spezifikationen der Standards sind öffentlich

zugänglich, und Entwickler können sie in die Applikationen integrieren.

Problematisch wird ein solcher Ansatz allerdings bei einer Vielzahl von

Services und eingebundenen Applikationen. Der Programmieraufwand

bei technischen oder organisatorischen Prozessänderungen ist dann nicht

mehr wirtschaftlich – schließlich muss der Sicherheitsteil jeder Applikation

neu angepasst und getestet werden. Ein solches Vorgehen steht im

Gegensatz zu den ursprünglichen SOA-Prinzipien und würde die Vorteile

einer flexiblen Infrastruktur zunichte machen. Ein weiterer Nachteil einer

manuellen Umsetzung ist sicherlich die fehlende Beherrschbarkeit des

Gesamtsystems, weil keine zentrale Administration und auch nur

schlechte Möglichkeiten des Reportings und Audits vorhanden sind.

Das bedeutet, Anwender müssen in der Lage sein, Sicherheitsmechanis-

men ebenso flexibel zu modellieren, zu managen und auszurollen wie die

serviceorientierte Infrastruktur selbst. Zur Umsetzung solcher und weiterer

Anforderungen bietet sich ein Framework-Ansatz an, der das Security-

Design, die Einführung sowie die Verteilung und den Betrieb von Secu-

rity-Mechanismen unterstützt. Ein auf offenen Standards basierendes

Framework in Verbindung beispielsweise mit einem Plugin-Adapter-Kon-

zept ist in der Lage, die benötigte Flexibilität der Sicherheitsmechanismen

umzusetzen. Security-Funktionalität, Standards und Erweiterungen (wie

Integrationsfunktionen) werden über Plug In-Adapter geladen und stehen

systemweit zur Verfügung.

72


Security als Service

Zudem bietet es sich an, Sicherheitsfunktionalität selbst als Service anzu-

bieten. Dabei wird die Funktionalität SOA-konform in Services gekapselt

und zur Verfügung gestellt. Dies kann zentrale Administrationsdienste

umfassen, beispielsweise Identity-Management oder -Modellierung,

ebenso wie die Umsetzung am Policy Enforcement Point (zum Beispiel

Verschlüsselungen, Authentifizierung).

Als Service können auch Dienste für die Nutzung von herkömmlichen

Security-Lösungen in SOA-Umgebungen realisiert werden. Über standar-

disierte Schnittstellen (Web Services, SOAP) können diese von sämtlichen

Systemen genutzt und anforderungsgerecht skaliert werden. Die Imple-

mentierung als Service Provider erlaubt systemweit oder innerhalb von

Domänen Sicherheitsmechanismen, wie beispielsweise Anti Virus, Signa-

tur, Public Key Infrastruktur, zu nutzen.

Architekturansätze

Ein Ansatz für ein Sicherheits-Framework benötigt zentrale Komponenten,

wie zum Beispiel eine Administration, aber auch lokale Laufzeitumgebun-

gen, in denen Sicherheitslösungen lokal umgesetzt werden. In verteilten

Umgebungen ist ein zentrales Management der Sicherheitsinfrastruktur

notwendig. Es bedarf einer systemweiten Security Policy, die verteilt und

umgesetzt werden muss. Besondere Beachtung sollte dabei der Integration

bestehender Systeme geschenkt werden, um vorhandene Benutzer, Rollen

und Rechte oder auch Zertifikate im SOA-Kontext nutzbar zu machen.

Der Architekturansatz einer lokalen Sicherheitslaufzeitumgebung hat

einen großen Einfluss auf die Anwendbarkeit von Sicherheitslösungen in

einer SOA. Die Umsetzung kann durch verschiedene Architekturansätze

erfolgen: Es lässt sich zwischen lokalen und domänenweiten Security

Services unterscheiden. Lokale Services setzen Sicherheitsfunktionen

außerhalb der Applikationen und Services um.

73

www.hessen-it.de

Die lokale Security-Laufzeitumgebung übernimmt den unveränderten Web Service

der Applikation und sichert diesen on-the-fly nach vorgegebenen Security-Regeln

ab. Auf der Empfängerseite überprüft der Security Service den empfangenen,

gesicherten Web Service und stellt den Urzustand wieder her.

Die lokalen Laufzeitumgebungen agieren somit als automatisierte Proxies,

um Sicherheitsfunktionalität aus der Applikation zu nehmen. So kann bei-

spielsweise die in der Policy definierte Verschlüsselung eines Elements

(XML-Encryption) außerhalb der Applikation durchgeführt werden.

Der zentralisierte Security Service bietet die Sicherheitsüberprüfung

als Service, z. B. das Scannen nach Viren in Attachments.

ServiceService SecurityService

SecurityService

ServiceServiceConsumer

DomainSecurity Service

74


Domänenweite Services bieten dafür Sicherheitslösungen, wie beispiels-

weise Virenscanner als Sicherheitsdienst an. Der Vorteil dieser Konzepte

ist die einfache Implementierung, der Nachteil liegt in einer schlechten

Performance. Diese Implementierung eignet sich daher für zeitunkritische

Prozesse oder Sicherheitslösungen, in denen der Performance-Nachteil

gegenüber dem eigentlichen Scan-Prozess zu vernachlässigen ist oder

durch Hardwareinvestitionen ausgeglichen werden kann.

6.5 Fazit

Die Implementierung einer sicheren SOA-Infrastruktur ist keine triviale Auf-

gabe. Neben neuen notwendigen Sicherheitsmethoden, die die Sicher heit

auf Nachrichtenebene gewährleisten, bestehen auch bei traditionellen

Techniken (wie z. B. Antivirus-Lösungen) neue Anforderungen. Unterneh-

men benötigen leistungsstarke Werkzeuge, mit denen diese und weitere

Anforderungen wie Policy-Administration, Workflows für Verteilung und

Orchestrierung automatisiert umgesetzt werden müssen.

Sicherheitsanforderungen wie Authentizität, Vertraulichkeit, Integrität und

Verbindlichkeit können mit der konsequenten Anwendung standardisier-

ter WS-Security Mechanismen gelöst werden. Für Bedrohungen wie SQL-

Injections, DoS-Attacken im SOA-Umfeld sollte eine servicekonforme

Nutzung vorhandener Lösungen möglich sein.

Ein Ansatz mit einem Security-as-a-Service-Konzept bietet diese Möglich-

keiten. Unternehmen können einen Security Service effizient und anforde-

rungsgerecht entweder lokal außerhalb der Applikation oder auch als

domänenweiten Service implementieren. Eine zentrale Orchestrierungs-

und Management-Plattform mit breiten Integrationsmöglichkeiten liefert

Unternehmen die Möglichkeit, vorhandene Lösungen (etwa Metadirec -

tories, PKI) weiterhin im SOA-Umfeld zu nutzen. In Verbindung mit

leistungsstarken Modellierungswerkzeugen und vorkonfigurierten Work-

flows ist die Automatisierung von SOA-Security effizient umzusetzen.

75

www.hessen-it.de

SOA goes B2B: Lessons Learned aus der Automobilindustrie

Dr. Christine Legner, European Business School

7.1 SOA und B2B

SOA – aber wie?

Die Kernidee einer service-orientierten Architektur (SOA) ist leicht erklärt

– sie lässt sich am besten anhand von Plattformstrategien in der Auto -

mobilindustrie verdeutlichen, in der verschiedene Fahrzeugmodelle

baugleiche Komponenten teilen. Bei der konzernübergreifenden Klein -

wagenplattform mit den Modellen Citroën C1, Peugeot 107 und Toyota

Aygo beträgt der Anteil an Gleichteilen ungefähr 60 %. So einleuchtend

die Kernidee einer SOA jedoch ist, so herausfordernd sind die Fragen,

denen sich IT-Verantwortliche derzeit stellen müssen: Was heisst SOA

denn konkret? Und wo fängt man am besten an? Aus Risiko- und Kosten-

überlegungen ist es sicherlich nicht zu empfehlen, bewährte IT-Systeme

mit SOA komplett umzukrempeln oder gar vollständig in Services zu zer-

legen. Es gilt also, die Bereiche zu identifizieren, in denen die gewachsen

Systemlandschaften an ihre Grenzen geraten. Mögliche Symptome dafür

sind ein „Wildwuchs“ an Systemen, welche die steigenden Anforderungen

der Fachbereiche nicht mehr erfüllen können.

7

76


© Andrzej -

Fotolia.com

B2B-Architekturen als Ansatzpunkt für SOA

Einer der erfolgversprechenden Ansatzpunkte für SOA ist an den Unter-

nehmensgrenzen zu finden. Überall dort, wo die Verzahnung mit Ge schäfts -

partnern enger wird, steigt der Bedarf an elektronischer Kommunikation

und Prozessintegration über die Unternehmensgrenzen hinweg. Amazon

gehört zu den erfolgreichen Beispielen, die durch SOA und Web Services

ihr Partnernetzwerk enger an sich binden und neue Einnahmequellen

erschließen. In der Automobilindustrie lassen sich solche Ansatzpunkte

für SOA ebenfalls ausmachen: Im Zuliefernetzwerk steigt der überbetrieb-

liche Integrationsbedarf bedingt dadurch, dass Hersteller ihre Wertschöp-

fungstiefe reduzieren und Zulieferer ganze Produktions- und Entwick-

lungsumfänge übernehmen. Auf der Vertriebsseite wird die überbetrieb-

liche Integration ebenfalls immer wichtiger, um dem weltweiten Händler-

netzwerk Produktinformationen verfügbar zu machen oder Online-

Services zur Werkstattunterstützung anzubieten. In beiden Bereichen wird

massiv in IT investiert, was sich in den entsprechenden Projektportfolios

der Automobilunternehmen zeigt. Gleichzeitig wird auch deutlich, dass

individuelle Punkt-zu-Punkt-Schnittstellen an ihre Grenzen stoßen. Das

bedeutet, dass in Zukunft leistungsfähigere Integrationsarchitekturen

aufgebaut werden müssen. Im Folgenden wird vor allem von SOA-Poten-

zialen für die Koordination entlang der Zulieferkette die Rede sein. Die

vorgestellten SOA-Ideen wurden im Rahmen der Initiative „SOA in Auto-

motive“ erarbeitet. Neben einem Forscherteam waren verschiedene

Automobilhersteller und -zulieferer (u. a. BMW, Hella KgaA, Magna Steyr,

Siemens VDO, ZF), die Branchenplattform SupplyOn sowie weitere

Technologieanbieter (u. a. SAP, IBM, BEA) beteiligt. Das SOA-Konzept

wurde in Form einer Zielarchitektur für die servicebasierte B2B-Koope -

ration konkretisiert und anschließend durch einen Piloten erprobt.

77

www.hessen-it.de

Heterogenität als Problemstellung der B2B

Unternehmen-zu-Unternehmen (B2B)-Integration war und ist in der Auto-

mobilindustrie stark mit dem Einsatz von Electronic Data Interchange (EDI)

verbunden. Obwohl alle Großunternehmen eine EDI-Infrastruktur auf -

gebaut haben und diese immer noch erweitern, bleibt deren Anwendung

auf wenige stark strukturierte Geschäftsdokumente in der Logistik, wie z. B.

Lieferabrufe, Lieferavis und Bestellung, beschränkt. Hersteller und Zuliefe-

rer nutzen zunehmend die vielfältigen Möglichkeiten des Internets, um

den Koordinationsbedarf entlang des kompletten Produktlebenszyklus –

vom ersten Fahrzeugkonzept über Produktentwicklung und Produktion bis

hin zur Produktnutzungsphase mit anschließender Entsorgung und Recyc-

ling – zu decken. An erster Stelle sind hier die Lieferantenportale – wie z. B.

BMW Group Partner Portal oder VWGroupSupply.com – zu nennen. Diese

haben sich zu sehr mächtigen Plattformen entwickelt und integrieren oft

zahlreiche interne Applikationen, über die Geschäftspartner z. B. aktuelle

Qualitätskennzahlen abrufen oder Reklamationen bearbeiten können.

78


© S

haw

n H

emp

el -

Foto

lia.c

om

Die Portallösungen stellen zwar eine komfortable Lösung für die Betrei-

ber-, nicht aber für die Lieferantenseite dar. Große Zuliefererunterneh-

men, die ihre internen Prozesse professionell durch IT-Lösungen unterstüt-

zen, müssen im Schnitt 30 bis 50 Portale bedienen. Portale sind für sie zeit-

und kostenaufwändige Mensch-Maschine-Schnittstellen, die einen hohen

Monitoringaufwand und fehleranfällige redundante Datenpflege ver -

ursachen. Angesichts der immer weiter steigenden Anzahl von Portalen,

die selbst oft mehrere hundert Anwendungen umfassen, sehen sich die

Zu lieferer einem „Portaldschungel“ gegenüber. Im Vergleich zur Populari-

tät der Portale konnte sich der XML-basierte Nachrichtenaustausch in der

Automobilindustrie bisher noch vergleichsweise wenig durchsetzen. Eine

Ausnahme ist der auf XML basierende QDX-Standard für das überbetrieb-

liche Qualitäts- und Reklamationsmanagement. Entsprechende B2B-Inte-

grationsprojekte werden in der Regel als Einzelprojekt auf Anforderung

eines Fachbereiches oder eines externen Partners realisiert. Diese

Projekte erfordern erhebliches Integrationswissen und die Realisierung

von Schnittstellen. Zusätzlich sind partnerspezifische Anforderungen zu

berücksichtigen, so z. B. die Vorgaben eines Automobilherstellers an seine

Zulieferer in Bezug auf Datenformate und -qualität.

Eine aktuelle Studie von Supply On zeigt einen stark anwachsenden Anteil

digitaler Prozesse – bei zunehmender Vielfalt der eingesetzten e-Business-

Plattformen. Berücksichtigt man die enorme Komplexität und die Kosten

beim Aufsetzen elektronischer Prozesse, so besteht erheblicher Hand-

lungsbedarf.

79

www.hessen-it.de

7.2 SOA-B2B-Architektur: Öffentliche und interne Sicht

Aufbau der serviceorientierten B2B-Zielarchitektur

Die steigende Vielfalt und Heterogenität der elektronischen Integrations-

beziehungen wird in Zukunft nur durch eine sorgfältig geplante B2B-

Architektur zu bewältigen sein. Serviceorientierte Architekturen liefern

hier zunächst die technischen Grundlagen für den automatisierten Daten-

austausch von strukturierten und unstrukturierten Inhalten in überbetrieb-

lichen Geschäftsbeziehungen. Durch sie lassen sich sowohl die klassische

nachrichtenbasierte Integration, wie im Falle von EDI, als auch eine prozess -

orientierte Integration über Workflows und der Austausch von schwach

strukturierten Dokumenten oder deren Anzeige in Portalen realisieren. Sie

eignen sich daher auch für den Einsatz in weniger hochvolumigen und

strukturierten Kooperationsprozessen, wie z. B. in der Produktentwicklung

oder im Qualitätsmanagement.

SOA ist jedoch noch lange kein Produkt, dass sich „out-of-the-box“ ein -

führen lässt. Vielmehr erfordert SOA grundsätzliche Überlegungen, wie

eine B2B-Architektur auszugestalten ist. Es gilt beispielsweise zu bewer-

ten, welche Funktionalität künftig als Service zu realisieren ist, um so wie-

derverwendet oder schneller zu neuen Prozessvarianten konfiguriert zu

werden. Es ist auch prinzipiell zu überlegen, wie man über Unternehmens-

grenzen über Services interagiert und welche Services ein Partner nutzen

darf. Diese Überlegungen wurden im Rahmen von „SOA in Automotive“ in

einer Zielarchitektur konkretisiert (vgl. Abbildung unten). Ein wichtiges

Hilfsmittel ist die Unterscheidung in eine öffentliche Sicht („Public“) und in

eine interne Sicht („Private“). Während die öffentliche Sicht über die ver-

schiedenen Geschäftspartner hinweg abzustimmen ist und die über -

betriebliche Prozessintegration umfasst, betrachtet die interne Sicht die

interne Umsetzung innerhalb eines Unternehmens. So wird der Anforde-

rung Rechnung getragen, dass interne Prozessabläufe und Systemland-

schaften verschiedener Partner unabhängig voneinander entworfen und

geändert werden.

80


Abbildung : Serviceorientierte B2B-Architektur

Öffentliche Sicht: SOA ermöglicht m:n-Fähigkeit

Zentrale Bestandteile einer SOA sind (Web) Services, die gekapselte

Geschäftslogik als selbstbeschreibender Service zur Verfügung stellen.

Nutzt man Services in Beziehungen mit externen Geschäftspartnern, so

können diese schnell und ohne großen bilateralen Abstimmungs- und

Realisierungsaufwand über wohldefinierte Schnittstellen elektronisch inte-

ragieren. Eine SOA hat damit das Potenzial, die Vielfalt und Heterogenität

in B2B-Integrationsbeziehungen einzudämmen. Voraussetzung dafür ist

m:n-Fähigkeit, d. h. dass beliebige (m) Lieferanten mit beliebigen (n) Kun-

den die „gleiche Sprache“ an den Prozess- und Systemschnittstellen spre-

chen. M:n-Fähigkeit reduziert die derzeitige Vielfalt überbetrieblicher Pro-

zessvarianten auf ein sinnvolles und beherrschbares Maß und führt dazu,

dass der Abstimmungs- und Integrationsaufwand beim Aufbau elektroni-

scher Kooperationen erheblich sinkt.

Automobilhersteller Zulieferer

ProzessarchitekturProzessarchitektur

Desktop-integration

Business-ServicesApp.-Services

Nach-richten

Service-beschrei-

bungWSDL

Semantik

Service-verzeichnis

Service-verzeichnisWorkflow

Desktop-integration

Business-Services

App.-Services

Workflow

Applikationsarchitektur

Infrastrukturarchitektur

Applikationsarchitektur

Infrastrukturarchitektur

(SOA-basierte) Integrationsarchitektur (SOA-basierte) Integrationsarchitektur

PrivatePrivate

Proze

ssSy

stem

Proze

ssSy

stem

PrivatePrivate

Public

81

www.hessen-it.de

Die Web Service-Standards, die einer SOA zugrunde liegen, nutzen

offene Internet-Standards (XML, SOAP, WSDL) und sichern so eine höhere

Plattformunabhängigkeit und Interoperabilität. Sie liefern dadurch bereits

einen erheblichen Mehrwert gegenüber früheren, sehr viel stärker pro-

prietären Technologien wie EDI. Allerdings reichen das von den Herstel-

lern propagierte techniklastige Service-Verständnis und die rein techni-

sche Interoperabilität von Web Services nicht aus. Überbetriebliche elek-

tronische Vernetzung funktioniert mit SOA nur, wenn alle Partner Web Ser-

vices mit gleicher Semantik verwenden, d. h. sich auf ein fachliches Ser-

vice-Design einigen. Die große Herausforderung liegt dabei in der

betriebswirtschaftlichen Service-Definition sowie in der Verwendung stan-

dardisierter Web Service-Signaturen. Idealerweise ergänzen also Fach-

standards die technische Standardisierung von Web Services. Im Rahmen

von „SOA in Automotive“ wurde die VDA-Empfehlung 4965 für das tech-

nische Änderungsmanagement in m:n-fähige Prozesse und Services über-

führt. Als Teil der unternehmensübergreifenden Produktentwicklung (Col-

laborative Engineering) umfasst das Änderungsmanagement die Bewer-

tung und Entscheidung von Änderungsideen sowie die Umsetzung von

Änderungen in gemeinsamen Entwicklungs-, Planungs- und Fertigungs-

prozessen. Dazu wurde ein „ECR Public Process“ (ECR = Engineering

Change Request) als ereignisgesteuerte Prozesskette mit Erweiterungen

in ARIS dokumentiert. Diese umfassende Dokumentation des öffentlichen

Prozesses schafft ein gemeinsames Verständnis über zwischenbetriebli-

che Prozessabläufe und erweitert damit die herkömmliche Standardisie-

rung um den Prozesskontext. Gleichzeitig bietet der „Public Process“ den

Geschäftspartnern klar definierte Anbindungspunkte für ihre jeweiligen

internen Prozesse („Private Processes“) und ihre interne Prozessdokumen-

tation. Der „ECR Business Service“ setzt die Prozessinteraktion auf System-

ebene um. Automobilhersteller und -zulieferer können so ihre Prozesse im

Änderungsmanagement durch Serviceaufrufe elektronisch koppeln.

82


Interne Sicht:

SOA erleichert die Anbindung an überbetriebliche Prozesse

Während SOA also Geschäftspartnern ermöglicht, über wohldefinierte

Schnittstellen zu interagieren, adressieren serviceorientierte Ansätze noch

weitere Schwachpunkte der bisherigen B2B-Integrationslösungen. In

einer SOA wird Funktionalität, die in vielen B2B-Integrationsprojekten

benötigt wird, als Service realisiert. Sie wird also nicht redundant imple-

mentiert, wie es angesichts der projektgetriebenen Umsetzung von B2B-

Integrationslösungen häufig der Fall ist. Solche Services stellen in B2B-

Architekturen insbesondere Basisfunktionalitäten zur Verfügung, wie die

Authentifizierung bzw. Autorisierung von externen Partnern oder die Vali-

dierung von XML-Nachrichten. Neben der Wiederverwendung erleichtert

SOA generell auch das Anbinden der internen Prozesse und Systeme an

die externen Schnittstellen. Durch Konvergenz der Plattformen für B2B-

Integration und Enterprise Application Integration (EAI) lassen sich über-

betriebliche Serviceaufrufe eng mit den internen Workflows koppeln, die

eine Weiterverarbeitung und Integration in die entsprechenden internen

Backendsysteme sicherstellen. Im Vergleich zu den traditionellen Formen

der B2B-Integration können nicht nur die Transaktionssysteme (Enterprise

Resource Planning- oder Supply Chain Management-Systeme), sondern

auch Dokumenten- bzw. Content Management Systeme und Reporting-

systeme (Data Warehouses) eingebunden werden. SOA erlaubt insbeson-

dere ein verbessertes Prozesshandling, -Routing und -Monitoring.

Auch die individuelle Anpassung an partnerspezifische Besonderheiten,

wie z. B. Prozessvarianten oder Nachrichtenformate, fällt sehr viel leichter.

Diese wird es – auch wenn die fachliche Standardisierung Fortschritte

macht – sicherlich weiterhin geben.

83

www.hessen-it.de

Diese Aspekte wurden in der Zielarchitektur aus „SOA in Automotive“ für

das technische Änderungsmanagement weiter ausgearbeitet: Im Unter-

nehmen wurde dabei von der bestehenden Landschaft aus zumeist hete-

rogenen Anwendungssystemen ausgegangen, die für die fachliche Verar-

beitung von Änderungsanträgen zuständig sind. Diese Systeme werden

in der Schicht der domänenspezifischen Anwendungsdienste (Applica-

tion Service) als Web Services bereitgestellt, um eine prozessorientierte

Integration zu ermöglichen. Darüber hinaus werden Hilfsdienste, so

genannte Utility Services, entwickelt, die mehrfach benötigte domänen-

übergreifende Funktionalität realisieren. Innerhalb eines Workflows wer-

den die vorhandenen Dienste aufgerufen und miteinander verschaltet.

Mit Hilfe einer Frontend-Integration kann auch die Benutzer-Interaktion in

die Prozesse mit einbezogen werden. Damit lassen sich z. B. Mensch-

Maschine- und Maschine-Maschine-Schnittstellen mit der gleichen Inte-

grationsinfrastruktur realisieren.

7.3 SOA vs. herkömmliche B2B-Integration

Die hier skizzierte SOA für eine überbetriebliche Vernetzung ist derzeit

noch eine Vision. Allerdings konnte sie im Projekt „SOA in Automotive“

bereits für die Zusammenarbeit zwischen Automobilherstellern und –

zulieferern durchgespielt werden. Dies erlaubt mindestens einige Schluss-

folgerungen in Bezug auf die Potenziale, aber auch auf die Herausforde-

rungen bei der Umsetzung in Produktivumgebungen.

Vergleicht man den servicebasierten Ansatz mit einer Realisierung über

Lieferantenportale, so liegt der Nutzen einer SOA in der Vermeidung von

Medienbrüchen und manueller Informationsbereitstellung sowie weniger

Schulungsaufwand für die Nutzer. Im Beispiel bearbeiten die Mitarbeiter

auf Zulieferseite Änderungsanträge in den bestehenden Änderungsmana-

gementsystemen, anstatt sie zusätzlich in Lieferantenportalen zu erfassen.

Dadurch entfällt Aufwand für die Informationsbereitstellung, der im kon-

kreten Fall auf 0,75 Tage geschätzt wurde. Andere Formen der elektroni-

schen Integration (z. B. EDI in Form von bilateralen Punkt-zu-Punkt-Verbin-

dungen und standardisierter Nachrichtenaustausch ohne Prozessstandar-

disierung) weisen zwar ähnliche Vorteile wie der servicebasierte Ansatz

84


bzgl. des Koordinationsaufwands in den Geschäftsprozessen auf. Jedoch

liegt im Vergleich zu diesen der Mehrwert des servicebasierten Ansatzes in

geringeren Aufwendungen für den Aufbau der elektronischen Prozessinte-

gration. Hierbei kann die Realisierung des „ECR Business Service“ auf

bestehenden Infrastruktur- und Middlewarekomponenten erfolgen, die

bereits für die innerbetriebliche Integration genutzt werden. Es ist folglich

keine parallele B2B-Infrastruktur, wie z. B. im Fall von EDI, erforderlich.

Auch aufgrund der gegenwärtigen Anstrengungen aller Softwareanbieter

ist von einem schnellen SOA-Enabling bei Standardsoftwarepaketen aus-

zugehen, so dass sich eine servicebasierte Kopplung von Geschäftsprozes-

sen in Zukunft wesentlich kostengünstiger realisieren lässt. Gegenüber rei-

nen Nachrichtenstandards und Schnittstellendefinitionen (z. B. in EDI- oder

XML-Syntax) ermöglichen serviceorientierte Ansätze eine stärkere fachli-

che Spezifikation von Services, die nicht nur die Nachrichten (Semantik)

selbst, sondern auch die Prozessinteraktion (Pragmatik) abdeckt. Weiterhin

sieht ein gutes Service-Design zusätzliche Erweiterungskonzepte auf der

Nachrichtenebene vor, so dass partnerspezifische Anpassungen einfacher

realisiert werden können. Außerdem können häufig benötigte Funktionen

für die prozessübergreifende Integration (z. B. Logging, Authentifizierung)

in einer serviceorientierten Architektur als wieder verwendbare Utility Ser-

vices realisiert werden. Durch eine servicebasierte Kooperationsarchitektur

lassen sich folglich Integrationsbeziehungen mit mehreren Partnern und

über mehrere Prozesse hinweg auf Basis einer einheitlichen Integrations-

architektur umsetzen und gleichzeitig flexibel und skalierbarer gestalten.

85

www.hessen-it.de

7.4 Reifegrad und Herausforderungen

SOA-Konzepte und Web Service-Technologien haben mittlerweile die

notwendige Reife für den produktiven Praxiseinsatz in B2B-Kooperationen

erreicht. Die Erfahrungen aus „SOA in Automotive“ zeigen, dass Web

Services sich auf Basis der bestehenden Middlewareplattformen in Unter-

nehmen innerhalb von wenigen Tagen implementieren lassen. Auch die

unternehmensübergreifende Interoperabilität wird weitgehend problem-

los erreicht. Einen großen Anteil daran haben die sog. WS-I Profile, die

frühere Interoperabilitätsprobleme zwischen verschiedenen Herstellern

beseitigt haben und Interpretationsspielräume der WS-Standards effektiv

eingrenzen. Sie decken auch weitergehende Anforderungen im Bereich

Sicherheit (mit dem WS-I Basic Security Profile) und Zuverlässigkeit

(WS-I Reliable Secure Profile) ab. Die heutigen Middlewareplattformen

beinhalten bereits eine komplette technische Infrastruktur zur Realisie-

rung einer SOA. Kernelement bildet der Service Bus, der Serviceaufrufe

an den richtigen Serviceanbieter weiterleitet und diese Weiterleitung

auch garantiert. Des Weiteren realisiert der Service Bus Fehlerbehand-

lungsmechanismen für fehlgeschlagene Serviceaufrufe, z. B. durch Benach -

richtigung des Serviceaufrufenden, Mechanismen zur technischen Trans-

formationen (z. B. mit XSLT) oder semantische Mappings (z. B. Purchase

Orders von RosettaNet nach SAP).

Auf der Basis der in den Unternehmen eingesetzten Middleware-

plattformen lassen sich B2B Web Services innerhalb von wenigen

Tagen realisieren.

86


Allerdings machen die Erfahrungen aus „SOA in Automotive“ auch deut-

lich, dass es noch einige Hürden auf dem Weg hin zu einer serviceorien-

tierten B2B-Architektur gibt – auch, wenn man die menschlichen Voraus-

setzungen und das Change Management zunächst noch unberücksichtigt

lässt. Eine wichtige Voraussetzung für die erfolgreiche Umsetzung einer

SOA ist der Zugriff auf die benötigte Funktionalität in den Anwendungs-

sytemen über geeignete Servicesschnittstellen. Fehlen diese, so müssen

im Rahmen eines SOA-Enabling entsprechende Serviceschnittstellen

zunächst realisiert werden. Im konkreten Beispiel stellte dies den größten

Aufwandstreiber für eine durchgängige B2B-Lösung, und manchmal

sogar ein unüberwindbares Hindernis, dar und hat letztendlich auch eine

kurzfristige Umsetzung der Zielarchitektur im überbetrieblichen Ände-

rungsmanagement verhindert. Im Projekt zeigte sich, dass die eingesetz-

ten Änderungsmanagementsysteme – auch die Standardsoftwarepakete –

bisher nicht über eine geeignete Serviceschnittstelle verfügten. Ein SOA-

Enabling wäre zwar bei allen Projektpartnern möglich gewesen, sie wurde

jedoch wegen des erheblichen Aufwands in diesem Projekt nicht durch-

geführt. Zu betonen ist, dass dieser Aufwand prinzipiell bei jeglicher

elektronischen Kopplung von Applikationen besteht und damit nicht

SOA-spezifisch ist, sondern in ähnlicher Form bei vielen B2B-Integrations-

projekten beobachtet werden kann. Wenn sich serviceorientierte Archi-

tekturen weiter durchsetzen, wird sich dieser Aufwand jedoch nach und

nach reduzieren, da Anwendungssysteme künftig ihre Funktionalität als

Service bereitstellen. Allerdings zeigt die Erfahrung aus „SOA for Automo-

tive“ auch, dass B2B-Integration nur dann reibungslos funktioniert, wenn

einheitliche fachliche Service-Spezifikationen („Semantik“) existieren und

die öffentlichen Prozesse spezifiziert sind. An dieser Stelle besteht aktuell

dringender Handlungsbedarf. Es ist also notwendig, branchenweit akzep-

tierte Prozess- und Servicedefinitionen zu definieren und zu implemen -

tieren, um so die Potenziale der Serviceorientierung in der B2B-Inte -

gration in vollem Umfang zu nutzen.

87

www.hessen-it.de

7.5 Fazit

Die zunehmende Reife serviceorientierter Architekturen ermöglicht es,

leistungsfähige Prozessplattformen für die B2B-Integration zu realisieren.

Diese sind in der Lage, die bestehenden und künftigen Anforderungen

abzudecken und bergen im Vergleich zu den existierenden Einzellösun-

gen erhebliche Vorteile:

a Prozessplattformen unterstützen die verschiedenen B2B-Kanäle

(Maschine-Maschine und Mensch-Maschine) dadurch, dass der Zugriff

auf Services sowohl über ein Portal als auch über einen plattform- und

organisationsübergreifenden Web Service-Aufruf erfolgen kann.

a Durch Nutzung von XML und Web Services können Prozessplattformen

ein breites Spektrum an Integrationsszenarien abdecken. Im Gegen-

satz zu nachrichtenbasierten (EDI-) Ansätzen sind sie in der Lage, kom-

plexere (Multi-Step) Prozesse abzubilden. Sie sind daher geeignet,

weniger hochvolumige und strukturierte Prozesse zu unterstützen.

a Prozessplattformen entkoppeln die Prozess- von der Anwendungslo-

gik. Mittels Orchestrierung (innerbetrieblich) bzw. Choreographie

(überbetrieblich) von Web Services verschalten sie lediglich Anwen-

dungsfunktionen und beschleunigen so die Umsetzung neuer Pro-

zessvarianten. Ein Prozessvorlagen-Repository enthält Templates für

„Public Processes“, die partnerspezifisch angepasst werden können.

a Durch Konvergenz der Plattformen für B2B-Integration (B2Bi) und

Enterprise Application Integration (EAI) lassen sich überbetriebliche

Serviceaufrufe eng mit den internen Workflows koppeln, die eine Wei-

terverarbeitung und Integration in die entsprechenden internen

Backendsysteme sicherstellen. Letztere umfassen Transaktionssysteme

(ERP, SCM, …) ebenso wie Dokumenten- bzw. Content Management

Systeme und Managementinformationssysteme (Data Warehouses).

a Basis-Services für die überbetriebliche Prozessintegration, wie z. B.

Authentifizierung von Geschäftspartnern, Logging, usw., können zen-

tral bereitgestellt und in verschiedenen Kooperationsbeziehungen

wieder verwendet werden. Diese Services können auch auf einfache

Weise von externen Spezialisten bezogen werden.

88


SOA als Grundlage zukunftsfähiger B2B-Architekturen

89

www.hessen-it.de

Aktuelle Herausforderungen inB2B-Netzwerken

Was bringt SOA? Wo liegen Herausforde rungen bei der SOA?

Starker Zuwachs digitaler Prozessevon der Produktentwicklung überdie Produktion bis hin zu Garantie,Service und Entsorgung

Vielfalt der Partner, Prozessvarian-ten und eingesetzten Technolo-gien

m:n-Fähigkeit in über -betrieblichen Prozessen:

a Nutzung offener, kostengüns -tiger und weit verbreiteter Internet-Technologien

a Geringerer Abstimmungs- undIntegrationsaufwand durch Services als wohl definierteSchnitt stellen für externe Partner

a Dokumentation der Servi ces ineinem Service-Repository mitexternen Sichten

Fachliche Service-Spezifikation(„Semantik“): z. B. Ergänzung vonFachstandards (VDA, Odette, …)durch Spezifikation von (Web) Services und deren Choreographie

Überbetriebliche (Referenz-)Pro-zesse als Grundlage der elektro -nischen Integration: „Public Pro cesses“, z. B. in der Produkt-entwicklung, im Qualitäts- oder Reklamationsmanagement

Realisierung von B2B-Integrationals Einzellösung auf Anforderungeines Fachbereiches oder Partners

Vielfalt der e-Business-Plattformen(Portale, XML-Nachrichtenaus-tausch, EDI, …)

Aufwände für die Anbindung interner Systeme an unterschied -liche e-Business-Plattformen

Skalierbare, flexible e-Business-Plattform im Unternehmen

a Konvergenz der Plattformen für B2B-Integration (B2Bi) undEnterprise Application Inte -gration (EAI)

a Unterstützung sämtlicher Varianten der B2B-Integration: nachrichtenbasiert (EDI, XML),prozessorientiert (Workflows),benutzerorientiert (Portale)

a Wiederverwendung von Basis-Services (z. B. Authentifizierung,Validierung)

a Workflows zur Weiterverarbei-tung von externen Serviceauf -rufen und Integration in die ent-sprechenden internen Backend-systeme

a Änderbarkeit und Anpassungs -fähigkeit an partnerspezifischeAnforderungen (Datenformate,Prozessvarianten)

Konzeption einer SOA-basiertenB2B-Zielarchitektur für das Unternehmen

Schrittweise Umsetzung im Sinne der B2B-Zielarchitektur

SOA-Enabling der Anwendungssysteme

SOA-Perspektiven: Geschäftsmodelle und Innovationen für das Internet der Dienste

Tobias Conte, Dr. Carsten Holtmann, Benjamin Blau

FZI Forschungszentrum Informatik

8.1 Internet der Dienste

Unternehmen müssen kontinuierlich Antworten auf die Herausforde -

rungen ihrer jeweiligen Umwelt finden – in der Art, wie sie das tun und wie

sie ihre Wertschöpfungsbeziehungen organisieren lassen sich Muster

erkennen: In den 70er und 80er Jahren waren Wertschöpfungsaktivitäten

tenden ziell eher „hart verdrahtet“. Unternehmen strebten es an, möglichst

viele der notwendigen Aktivitäten selbst und integriert anzubieten. Dies

wurde als Ära der vertikalen Integration bekannt. Ende der 80er Jahre

begann man dann, sich stärker zu spezialisieren. Einzelne Prozesse

wurden über Unternehmensgrenzen hinweg ausgelagert und Wertschöp-

fungsketten und -beziehungen begannen, feingranularer zu werden.

Heute und voraussichtlich in der Zukunft schreitet dieser Trend weiter fort:

Unternehmen fokussieren sich auf die Spezialaktivitäten, in denen sie

echte Kernkompetenzen besitzen und global wettbewerbsfähig sind, in

anderen Bereichen stützt man sich auf die Kompetenzen von Partnern.

Unternehmen versuchen, ökosystemartige Umgebungen verbundener

Partner um sich zu gruppieren und die Wertschöpfung erfolgt damit

weniger in definierten Ketten als vielmehr in Netzen, den so genannten

„Service Value Networks“ (siehe Abbildung).

8

90


Von hartverdrahteten Wertschöpfungsketten zu

agilen Service Value Networks

Notwendig wird diese flexible Zusammenarbeit u. a. durch den globalen

Wettbewerbsdruck, ermöglicht wird sie durch die serviceorientierten

IT-Paradigmen. Die Idee ist, dass man auf dieser Basis innerhalb von Netz-

werken Geschäftsprozesse agil und dynamisch zusammenfügen kann. Die

Softwarebranche ist selbst ein Pionier in diesem Bereich. Die Unterneh-

men wandeln ihre Softwareprodukte nicht nur in Software-as-a-Service

(SaaS)-Angebote um, sie beginnen auch damit, in Service Value Networks

gemeinsam mit spezialisierten Partnern komplexe Dienste anzubieten.

Aus der Gesamtheit solcher und ähnlicher, teilweise untereinander ver-

knüpfter Servicenetzwerke wird die Entwicklung einer Infrastruktur erwar-

tet, die auch als das „Internet der Dienste“ charakterisiert wird.

HartverdrahteteWertschöpfungs-

ketten

Spezialisierungund

Konsolidierung

Agile ServiceValue Networks

91

www.hessen-it.de

Revolution des Softwarevertriebes: Software-as-a-Service

Neben der SOA-Entwicklung, die vornehmlich in Unternehmen Wirkung

erzeugt, sind diverse weitere bedeutsam, die eine Revolution unterneh-

mensübergreifender Leistungsprozesse möglich machen sollen. Allge-

mein lassen sich diese unter dem Begriff „X-as-a-Service“ zusammenfas-

sen. Das „X“ kann dabei für Software, Infrastruktur und Plattform stehen,

wobei erstere hier im Vordergrund steht.

Bei Software-as-a-Service (SaaS) handelt es sich um ein Vertriebsmodell,

mit welchem Anwendungen vom Service-Anbieter gehostet werden und

über ein elektronisches Netzwerk wie das Internet den Konsumenten nach

dem Prinzip „one-to-many“ zur Verfügung gestellt werden. „One-to-many“

bezeichnet dabei die Softwarenutzung durch mehrere Unternehmen

parallel (Multiagentenfähigkeit) jeweils über das Internet. Eigentümer der

Software bleibt in diesem Falle der Anbieter. Er ist es auch, der die

Anwendung betreibt und zentral aktualisiert.

Die Entwicklung hin zu SaaS kann auf einige Treiber und Gründe zurückge-

führt werden. Zum einen sorgen fallende Transaktions- und Kommunikati-

onskosten dafür, dass Anbieter Software betriebsfertig über das Internet

anbieten und so Skaleneffekte nutzen können. In Verbindung mit den sin-

kenden Kosten bietet sich nun die Möglichkeit, bisher weniger erschlossene

Märkte zu bedienen. Im Vergleich zu traditioneller Software bezahlen Kun-

den typischerweise keine einmalige Lizenzgebühr plus Wartungsgebühren,

sondern eine Nutzungsgebühr pro Einzelnutzung („pay-per-use“) oder auf

Periodenbasis („Subscription Fee“). Diese Preise beinhalten auch die vom

Anbieter durchgeführten Updates. Während lizenzbasierte Geschäftsanwen-

dungen aufgrund ihres Preises und ihrer Komplexität oftmals nur für große

Unternehmen interessant waren, besteht nun die Möglichkeit, nutzungsba-

siert oder auf periodischer Basis auch kleine und mittelständische Unterneh-

men (KMU) zu bedienen und so den oftmals gesättigten Markt der Großun-

ternehmen zu erweitern. Für KMU werden On-Demand-Lösungen attraktiv,

da sie bei Bedarf genutzt werden können, hohe Upfront-Investitionen für

einmalige Lizenzen der Vergangenheit angehören bzw. Bedarfsschwankun-

gen einfacher aus geglichen werden können. Beispielsweise werden On-

Demand-Appli kationen als Mittelstandslösung angeboten, die ab 133 Euro

monatlich bezogen werden kann (Stand 2009).

92


Entwicklungsstufen: Eine einfache Typologie

Der Begriff „Internet der Dienste“ wurde bisher in der akademischen Welt

noch nicht erschöpfend definiert, Impulse kommen hauptsächlich aus der

industrienahen Forschung. Das Internet der Dienste folgt – einfach

gesprochen – dem Gedanken, dass im künftigen Internet nicht nur primär

Inhalte in Form von Webseiten verfügbar sein werden, sondern dass viel-

mehr Dienste (wie bspw. Google Maps) nutzbar sind, die Unternehmen

und Privatanwendern Informationen zielgerichtet und damit personalisiert

aufbereiten. Diese Dienste werden miteinander kombinierbar sein und

können so zu komplexen Diensten zusammengefügt werden. Komplexe

(oder zusammengesetzte) Dienste beinhalten typischerweise die Orches-

trierung und den Aufruf mehrerer vorhandener Dienste. Diese können

von unterschiedlichen Parteien kommerziell angeboten werden und letzt-

endlich einen Geschäftsprozess abbilden.

Definition „Internet der Dienste“

Das Internet der Dienste ist ein globales Netzwerk, welches das

Design, das Auffinden, das Kombinieren, den Handel und die Nut-

zung interoperabler, elektronischer Services im Web ermöglicht.

(angelehnt an Papazoglou 2007)

Erste Schritte hin zu einem Internet der Dienste sind mit den allgemein

bekannten Entwicklungen zu SaaS bereits getan, weitere weniger

bekannte und komplexere Entwicklungen sind bereits zu beobachten und

lassen sich mit der folgenden Typologie abgrenzen.

93

www.hessen-it.de

Typologie von Business Services

Die bekannten Phänomene können in vier Quadranten klassifiziert

werden, die sich anhand der Dimensionen aufspannen lassen:

a Interaktionsgrad bei Erstellung und Angebot des Dienstes

a Komplexitätsgrad des Dienstes / der Komposition

Die Typologie grenzt demnach die Dienste nicht hinsichtlich ihres Typs

„X-as-a-Service“ ab, sondern anhand ihrer Komplexität und ihres Koopera-

tionsgrades über Unternehmensgrenzen hinweg.

Grad der Komplexität

Gra

d d

er In

tera

ktio

n 1 32 4

Ein

(do

min

iere

nder

)A

nbie

ter

Vie

le A

nbie

ter

Einfacher Dienst Komplexer Dienst

Aggretiertes Angeboteinfacher Dienste übereinen Marktplatz.Funktionale Integrationwird nicht unterstützt.

Angebot einfacher Dienste durch einzelnes Unternehmen.

Angebot komplexer Dienste durch einzelnesUnternehmen.

Integriertes Angebotkomplexer Dienste, die aus einfachen oder komplexen Teildiensten bestehen und über einen Marktplatz vertrieben werden.

94


Quadrant 1: Einfache Dienste durch einzelne Anbieter

Die Vielfalt von als SaaS angebotenen einfachen Web Services ist heute

schon riesig. Paradebeispiele sind die von Google offerierten Dienste wie

z. B. GoogleMaps (http://maps.google.com), einem Kartendienst, der mit

wenigen Zeilen Code in Webseiten und Mash-Ups integriert werden kann,

oder Google Docs (http://docs.google.com) als sozusagen „webbasierte

Office-Lösung“. Weitere Beispiele für einfache Web Services sind Ama-

zons Simple Storage Service (S3) (http://aws.amazon.com/s3) und die Elastic

Compute Cloud (EC2) (http://aws.amazon.com/ec2). Während S3 und EC2

kostenpflichtig sind, bietet Google seine GoogleMaps-Applikation

kostenfrei an. Auch Unternehmen können sich kostenlos auf GoogleMaps

eintragen.

Quadrant 2: Einfache Dienste von Anbieterverbünden

Des weiteren entwickeln sich Web Service-Marktplätze wie Strikeiron

(www.strikeiron.com) oder Xignite (http://xignite.com). Sie stellen anderen

Service Providern eine Plattform zur Verfügung, auf der sie ihre kommerziel-

len Dienste über einen gemeinsamen Kanal vertreiben können. Solche

Marktplätze bieten heute lediglich recht rudimentäre Infrastrukturdienste

an. Bis auf einen Katalog der angebotenen Dienste, einem thematischen

Clustering und einer Suchfunktion werden keine zusätzlichen, technisch

ausgefeilten Infrastrukturdienste angeboten. Funktionale Integration wird

beispielsweise ebenso wenig angeboten wie ein gemeinsames Monitoring.

95

www.hessen-it.de

Quadrant 3: Komplexere Dienstkonfigurationen

durch einzelne Anbieter

Es sind aber nicht nur einfache Dienste, die on-demand zur Verfügung

gestellt werden. Auch Mehrwertdienste, die komplexe Geschäftsprozesse

unterstützen, werden bereits über das Netz angeboten. Beispiele hierfür sind

Salesforce.com (www.salesforce.com) und Netsuite Inc. (www.netsuite.com), die

mit ihren vollständig webbasierten CRM-Lösungen den Markt der Geschäfts-

anwendungen revolutionierten. Einzelkomponenten dieser Anwendungen

können dynamisch zu nutzerspezifischen Prozessen modelliert werden.

Einen Schritt weiter in Richtung des vierten Quadranten geht AppEx-

change, der von Salesforce.com betriebene Marktplatz für On-Demand-

Services. Die Idee von AppExchange (www.salesforce.com/appexchange) ist

es, komplementäre Angebote um Salesforce CRM herum zu gruppieren,

um die eigene Werthaltigkeit zu erhöhen. Hier werden nicht nur eigene,

sondern vor allem Applikationen von Drittanbietern (Partner und freie

Softwareentwickler) angeboten. Die offerierten Dienste sind voll integrier-

bar in Salesforce CRM. Jedoch handelt es sich dabei um Services, die auf

eine Kernanwendung ausgerichtet sind und daher alle auf der Plattform

force.com basieren. Dadurch wird die Integration beträchtlich erleichtert.

Die von AppExchange angebotenen Infrastrukturdienste sind demnach

zwar durch einen Plattformdienst erweitert, jedoch gibt es auch hier kein

gemeinsames Monitoring oder eine gemeinsame Abrechnungskompo-

nente für alle angebotenen zusammengesetzten Services.

96


Generell zielte SaaS bisher vor allem auf die kostengünstige Bereitstel-

lung von isoliert stehenden Geschäftsanwendungen ab. Anbieter dieses

oftmals „SaaS 1.0“ genannten Konzepts warben meist mit schneller

Einführung und niedriger Total Cost of Ownership (TCO). Seit wenigen

Jahren zeichnet sich allerdings eine Entwicklung in Richtung „SaaS 2.0“

ab, die man unter anderem in der Evolution des von Salesforce.com ange-

botenen Portfolios beobachten kann. 1999 startete das Unternehmen mit

seiner isoliert stehenden Geschäftslösung Salesforce CRM. Seitdem hat

Salesforce.com ein Ökosystem an Partnern um sich gruppiert, das das

Kernprodukt mit komplementären Angeboten erweitert, die seit 2005 auf

AppExchange angeboten werden. Diese Entwicklung spiegelt SaaS 2.0

wider. Software-as-a-Service-Lösungen sollen als integrierte Geschäfts -

lösungen komplexe Geschäftsprozesse unterstützen. Durch die Orches-

trierung modularer Teildienste findet nicht nur eine organisationsüber-

greifende Zusammenarbeit in Service-Netzwerken statt (vgl. Abbildung

auf S. 91). Durch die freie Kombinierbarkeit der Teildienste können Konsu-

menten die komplexen Dienste deutlich flexibler an ihre Bedürfnisse

anpassen, als dies bei allein stehenden SaaS 1.0- Anwendungen möglich

ist. Auch nahtlose Integration in Legacysysteme soll in SaaS 2.0-Anwen-

dungen unterstützt werden.

Quadrant 4: Komplexe Dienstkonfiguration durch

Wertschöpfungs netze

Auch wenn das Salesforce-Angebot schon ein sehr umfassendes Lösungs -

spektrum umfasst, besteht weiterhin Forschungsbedarf im Bereich kom-

plexer Services, die von unterschiedlichen, gleichberechtigten Anbietern

dynamisch zusammengesetzt werden können. Dieser vierte Quadrant

wird derzeit von dem Projekt THESEUS/TEXO adressiert. Hier geht es um

die Bereitstellung einer offenen Plattform, auf der Diensteanbieter und

-konsumenten zusammentreffen und komplexe wie auch einfache

Dienstleistungen handeln können.

97

www.hessen-it.de

8.2 Forschungsprojekt TEXO

TEXO ist Teil des Dachprojekts THESEUS (http://theseus-programm.de), das

vom Bundesministerium für Wirtschaft und Technologie (BMWi) gefördert

wird. Ziel ist es, eine neue internetbasierte Infrastruktur für die Wissens-

und Dienstleistungsgesellschaft zu entwickeln. Um Wissen im Internet

besser verfügbar zu machen, werden in unterschiedlichen Forschungs-

projekten (Use Cases), die jeweils von renommierten deutschen Techno-

logieunternehmen geführt werden, anwendungsorientierte Basistech -

nologien entwickelt und evaluiert. Es werden nicht nur neue Werkzeuge

und Dienste erwartet, sondern auch Fortschritte im Hinblick auf deren

wirtschaftliche Verwendung.

Das Forschungsprojekt TEXO wird von SAP geführt und mit 11 weiteren

Partnern aus Industrie, Forschungseinrichtungen und Universitäten be -

arbeitet. Insgesamt befassen sich etwa 55 Wissenschaftlerinnen und

Wissenschaftler mit TEXO. TEXO zielt auf den Entwurf und die prototypi-

sche Umsetzung einer sozio-technischen Infrastruktur, innerhalb welcher

komplexe, zusammengesetzte (elektronische) Dienste über das Internet

gehandelt werden können. TEXO wird also den vierten Quadranten der

oben aufgezeigten Typologie zum Leben erwecken und dabei alle Phasen

des Dienstleistungslebenszyklus unterstützen (vgl. Abbildung auf S. 99):

a Bevor Teilnehmer des Internet der Dienste einen Dienst anbieten

oder nutzen können, erfolgt die Initiierung im Netzwerk.

a Die Innovationsphase enthält die Bereiche Ideengeneration,

deren Bewertung, Marktanalysen und Entwicklung.

a Danach erfolgt mit der Angebotsphase die

Kommerzialisierung eines Dienstes.

a Die darauf folgende Matchmakingphase

kann in Marketing und Sales unterteilt werden.

a Nach dem Matchmaking, in der Angebot und Nachfrage

zusammengeführt und ggf. Preise und weitere

Diensteigenschaften verhandelt wurden,

a folgt die Nutzungsphase, auf die letztendlich die Feedbackphase

folgt. Das Feedback der Beteiligten stößt wiederum die

Innovationsphase neu an.

98


Dienstleistungslebenszyklus

Eine solche Infrastruktur wird mit der TEXO Services Management

Platform bereitgestellt werden. In hochgradig modularen, dynamischen

Umgebungen wie dem Internet der Dienste spielen Intermediäre, die

Angebot und Nachfrage zusammenbringen, eine wichtige Rolle. Service

Broker erzeugen einen ökonomischen Wert, indem sie als Infomediär auf-

treten oder kompatible, modulare Dienste zu komplexen Diensten zusam-

menfügen. So können bereits existierende Dienste von unterschiedlich -

sten Anbietern kombiniert werden. Durch eine solche Reallokation entste-

hen neue, innovative Anwendungen. Die TEXO Services Management

Platform tritt sowohl als Koordinator als auch als Integrator und Schnitt-

stelle auf, um alle beteiligten Parteien zusammenzubringen. Es werden

sowohl Geschäftsanwendungen als auch deren Realisierung durch tech-

nische Dienste betrachtet. Die TEXO Service Management Platform eröff-

net damit kleinen und mittelständischen Dienstleistern neue Märkte und

ermöglicht es Dienstkonsumenten, ihre Software dynamisch an Verände-

rungen anzupassen.

ExterneInnovation

Initiierung Innovation Angebot

W!W) W@

W$

W%

Match-making

Nutzung

Feedback

Dienstleistungs-lebenszyklus

99

www.hessen-it.de

8.3 Marktpotenzial serviceorientierter IKT

Das Marktpotenzial, das serviceorientierten Ansätzen zugesprochen wird,

ist sehr bedeutsam und wird später noch konkreter illustriert. Im Vorder-

grund der weiteren Ausführungen steht aber die Frage, welchen Einfluss

diese auf die Geschäftsmodelle der Anbieter haben werden. Internetba-

sierte Geschäftsmodelle gelten als einer der meist diskutierten, jedoch

noch immer nicht im Detail verstandenen Aspekte im E-Business. Das gilt

insbesondere für lose gekoppelte Geschäftsnetzwerke.

Im Folgenden werden wir nach einem kurzen Blick auf einige Marktzahlen

zur Entwicklung serviceorientierter Ansätze eine ausgewählte Umset-

zungsvision des Internet der Dienste präsentieren und die Chancen und

Risiken für die Beteiligten beispielhaft umreißen.

Die Prognosen von Marktanalysten, die in den vergangenen Jahren für

serviceorientierte IKT verfügbar sind versprechen nahezu konsistent ein

enormes Potenzial und lassen die Serviceorientierung in der Presse als

einen der derzeit wichtigsten IKT-Trends erscheinen: 31 % der Business-

und IT-Manager halten SaaS bzw. SaaS-Plattformen sogar für den derzeit

wichtigsten Trend der Softwarebranche (Quelle: Studie der Sand Hill

Group und der McKinsey&Company in Enterprise Software Customer

Survey 2008).

Weltweit werden laut Gartner im Jahre 2011 mehr als 25 % des Umsatzes

bei Geschäftsanwendungen durch SaaS erzielt werden. Konkret wird die

Entwicklung von 2006 14,7 %, über 2007 16,0 % auf geschätzte 26,3 %

2011 ansteigen. Für Deutschland prognostiziert die Experton Group für

2010 einen Gesamtumsatz von 577 Mio. Euro, das entspricht einem

Zuwachs von 113 % im Vergleich zu 2007.

100


KMU sind laut der Sandhill Group und McKinsey dabei die Kernziel-

gruppe. Nach einer Studie in den USA geben heute kleine Unternehmen

mit weniger als 100 Mitarbeitern bereits 26 % ihres Budgets für On-

Demand-Software aus. Dabei sind nach einer Gartner-Studie die belieb-

testen Funktionen Customer Relationship Management (CRM), Enterprise

Resource Planning (ERP), Supply Chain Management (SCM), Storage und

Kollaborationsanwendungen – insgesamt meist Funktionen, die typischer-

weise nicht den Kern des eigentlichen Geschäfts der Anwender darstellen

dürften.

Ähnliche relative und deutlich höhere absolute Dimensionen lassen sich

für die gesamte XaaS bzw. Cloud Computing-Entwicklung finden. Merrill

Lynch (Quelle: The Cloud Wars, 2008) prognostiziert, dass Cloud Compu-

ting im Jahre 2011 einen Anteil von ca. 12 % des gesamten, weltweiten

Softwareumsatzes erreichen kann. Hier ist nicht nur der Markt der

Geschäftsanwendungen, sondern der gesamte Softwaremarkt die Basis

für die Berechnung. Insgesamt berechnet Merril Lynch einen Umsatz von

744 Mrd. US Dollar für Software, davon fallen 237 Mrd. US Dollar auf

Geschäftsanwendungen. Der Umsatz von Cloud Computing wird dabei

auf 95 Mrd. US Dollar geschätzt.

Wichtiger als die Marktprognosen sind an dieser Stelle aber die dazu zu

überwindenden Hindernisse. Sowohl auf Kunden- wie auch auf Anbieter-

seite ist ein Wandel zu vollziehen. Beim Kunden sind die meist zitierten

Bedenken, die aus dem Weg zu räumen sind, heute offensichtlich immer

noch in den Bereichen Security und Netz- /Systemverfügbarkeit zu finden.

Bedenken bzgl. Integration, wirklicher Reduktion der TCO und fehlender

Funktionalität dürften laut einer Forrester-Studie jedoch ebenso große Hür-

den darstellen. Ist der Schritt zur Nutzung gegangen, besteht die Kern -

herausforderung für den Kunden darin, die neu gewonnene Flexibilität

dann auch zu nutzen und kommerziell zum Effekt zu bringen – technische

und wirtschaftliche Change-Prozesse müssen hier also eng abgestimmt sein.

101

www.hessen-it.de

Für bereits etablierte Anbieter von Unternehmenssoftware ist eine Ände-

rung hin zu On-Demand-Delivery ein wohl noch substantiellerer Schritt,

da er das Geschäftsmodell radikal tangiert: Bisherige lizenzorientierte

Geschäfts- bzw. konkreter: Ertragsmodelle basierten zumeist auf den Säu-

len „Lizenzgebühren“, „Customizing/Consulting“ sowie regelmäßig wie-

derkehrenden Wartung („Maintenance“).

Bei SaaS-Geschäftsmodellen sieht sich der Anbieter weiterhin initialen

Kosten für Entwicklung, Marketing etc. ausgesetzt, Umsätze werden aller-

dings erst nach und nach durch nutzungsbedingte oder monatlich

berechnete Gebühren generiert, wobei zudem laufende Bereitstellungs-

kosten (für z. B. Serverkapazität) existieren. Das heißt letztendlich, dass

durch das Mietmodell von SaaS während der Wachstumsphase eines

SaaS-Geschäfts Erträge typischerweise deutlich langsamer, dafür aber

kontinuierlicher erzielt werden. Richtet sich das Angebot tendenziell eher

an KMU, wäre im Vergleich zu großen Unternehmen ein Mehraufwand

nötig, wenn Vertrieb und Bereitstellung nicht (z. B. durch gemeinsame

Plattformen, siehe hinten) effizienter organisiert werden können.

Der Bedarf für Customizing und Consulting auf Kundenseite könnte im

SaaS-Modell beschränkter sein, da die Implementierung bzw. Installation

beim Kunden wegfällt. Andererseits ist die Personalisierung und Lösungs-

integration mit bestehender Infrastruktur wohl in vielen Fällen trotzdem

erforderlich und insbesondere bei komplexeren SaaS-Anwendungen wei-

terhin zu erwarten. Beispielsweise arbeitet Salesforce.com mit einer Vielzahl

an Consulting-Partnern zusammen, da Schulungen bzgl. der Funktionalität

und weiterer Dienste wie force.com vom Kunden stark nachgefragt werden.

Da Professional Services wie Beratung und Anpassung im traditionellen

Lizenzgeschäft oftmals größere Erträge bringen als die Lizenzen selbst,

müssen die möglichen Konsequenzen in allen drei bisherigen Erlösquel-

len möglichst individuell exakt antizipiert werden, da die Umstellung auf

ein SaaS-Angebot umfassende Auswirkungen auf die Anbieter hat. Darü-

ber hinaus sind die Wechselwirkungen mit den Unternehmenspartnern

für die Angebotsmodelle der oben eingeführten Quadranten 2, 3 und 4

von großer Bedeutung (vgl. Abbildung auf S. 94).

102


8.4 Geschäftsmodelle für das Internet der Dienste

Welche neuen Geschäftsmodelle sind nun in einer offenen Serviceplatt-

form, wie sie das TEXO-Konsortium anstrebt, denkbar? Potenziell natürlich

unendlich viele. Zur Illustration seien einige skizziert, wobei wir vereinfa-

chend die Annahme treffen, dass die gesamte Infrastruktur von einem

Anbieter betrieben wird. Die andere Extremform ist die eines rein dezen-

tralen Ansatzes, ein Kontinuum dazwischen ist ebenso denkbar.

Um ein Geschäftsmodell vereinfacht zu beschreiben, greifen wir auf die

Geschäftsmodelldefinition von Stähler (2001) zurück. Sie enthält die

Elemente „Architektur der Wertschöpfung“ unter Berücksichtigung der

beteiligten „Agenten“, eine Beschreibung des „generierten Kunden -

nutzen“ sowie „Art und Ursprung der Erträge“.

Grundsätzlich gehören die Akteure einer solchen Plattform fünf grund -

legenden Rollen an: Plattformbetreiber, Servicekonsument, Serviceanbie-

ter, Communitymitglied und Serviceinnovator. Die beiden letztgenannten

Rollen werden im Folgenden vernachlässigt, da sie spezielle Rollen dar-

stellen, die größtenteils in Überlappungen mit den drei erstgenannten

Rollen auftreten dürften. Die Abbildung unten zeigt, welche Infrastruktur-

dienste auf der Plattform (Servicemarktplatz) vom Betreiber zur Verfügung

gestellt werden könnten, um den eigentlichen Serviceanbietern und

-konsumenten eine geeignete Infrastruktur zur Unterstützung aller Phasen

des Lebenszyklus zu ermöglichen (die Zahlen beziehen sich jeweils auf

die jeweiligen Phasen im Dienstleistungslebenszyklus).

103

www.hessen-it.de

Infrastrukturdienste auf der Serviceplattform

Für die Initiierungsphase (0) bietet die Plattform ein Identitätsmanagement

und gibt grundlegende Standards vor. Innovationsdienste erleichtern

Innovatoren (1) die Neuentwicklung und Evolution von Diensten. In der

Angebotsphase (2) werden vorrangig Dienste zur Verfügung gestellt, die

das Service Engineering – z. B. ein Plattformservice, der Serviceanbieter bei

der Implementierung ihrer Dienste unterstützt, ein Infrastrukturdienst

sowie ein juristischer Dienst, der Serviceanbieter für rechtliche Gegeben-

heiten sensibilisiert – und das Servicemarketing unterstützen. In der Match-

makingphase (3) können sowohl ökonomische, rechtliche als auch techni-

sche Dienste angeboten werden. Beispielsweise könnten allgemeine

Geschäftsbedingungen (AGBs) von Anbieter und Konsument abgeglichen

und ggf. angepasst werden. Semantische Technologien und Service Repo-

sitories unterstützen die Komposition von Teildiensten zu komplexen

Diensten. Außerdem können dynamische Preis- und Allokationsdienste

den aus ökonomischer Sicht effizienten Dienst ermitteln und dessen Preis

festlegen. Monitoringdienste überwachen in der Nutzungsphase (4) die

W!W)

W@

W$

W%

W#

104


erbrachten Dienste. Außerdem können die Angebote potentiell über meh-

rere Kanäle auf unterschiedlichsten Endgeräten angeboten werden. Im

Anschluss an die Nutzung werden dann Services für Abrechnung und

Bezahlung der genutzten Dienste bereitgestellt. Dienste, die Communities

unterstützen, sollen abschließend qualitativ hochwertiges Feedback (5)

ermöglichen und damit neue Serviceinnovation anstoßen (1).

Des weiteren können verwandte Beratungsleistungen wie Marktanalysen,

Schulungen, Nachfrageaggregation und weiterführende Integrations-

dienste von plattformexternen Dienstleistern angeboten werden. Glei-

ches gilt für IaaS-Dienste. Speicherplatz und Rechenleistung muss nicht

notwendigerweise von der Plattform bereitgestellt werden. Auch hier

erwarten wir die Herausbildung spezialisierter Partner, die Serviceanbie-

tern entsprechende Leistungen anbieten werden.

Durch die Flexibilität einer Serviceplattform können profitabel

Nischendienstleistungen angeboten werden. So kann ein Anbieter

durch Re-Konfiguration vorhandener Komponenten in unterschied-

lichen komplexen Diensten auch Kundenbedürfnisse befriedigen,

die fernab der Massenbedürfnisse liegen.

105

www.hessen-it.de

© D

an C

olli

er -

Foto

lia.c

om

Nutzen für Servicekonsumenten

Der generierte Nutzen für den Servicekonsumenten lässt sich grob in sie-

ben Kategorien einteilen: erhöhte Flexibilität, Qualitätssteigerung,

Anwendungsintegration, Komplexitätsreduktion, Wiederverwendbarkeit,

Kostenreduktion und schnelle Anpassung. Der postulierte Nutzen einer

Serviceplattform ist demnach eng verwandt mit den generellen Nutzen-

versprechen eines SOA-Einführungsprojekts.

a Flexibilität: Auf dem Servicemarktplatz werden nicht nur komplemen-

täre, sondern auch gleichartige Services angeboten. Im Zusammenspiel

mit der leichteren Integrierbarkeit der Dienste kann der Kunde hier

vereinfacht zwischen Anbietern wechseln („switch on the fly“). Dadurch

sinken für den Kunden insgesamt die Umstellungskosten bei Anbieter-

wechsel („Switching Costs“). Im Allgemeinen ist ein Konsument Umstel-

lungskosten bei einem Anbieterwechsel ausgesetzt, wenn eine Investi-

tion, die bezüglich des bestehenden Anbieters erbracht werden musste,

für einen neuen Anbieter erneut aufgebracht werden müsste. Im tradi-

tionellen Lizenzgeschäft mit hohen Initialkosten und langfristigen

Wartungsverträgen findet sich der Kunde sehr schnell in einer solchen

Situation wieder. Dies führt letztendlich dazu, dass starke Abhängigkei-

ten („Lock-In-Situationen“) entstehen, die den Kunden daran hindern,

Serviceanbieter zu wechseln, obwohl andere für ihn vorteilhafter wären.

SaaS-Anwendungen werden entweder nutzungsbasiert oder auf monat -

licher Basis („Subscription Fee“) abgerechnet. Ist der Kunde nun unzu-

frieden, ist es für ihn beträchtlich einfacher und kostengünstiger, den

Anbieter zu wechseln. Durch das Angebot gleichartiger, konkurrierender

Dienste auf der Plattform wird dieser Effekt noch verstärkt. Es fallen zwar

weiterhin Integrationskosten an, diese schlagen aber wegen gemeinsa-

mer Standards bei einem Anbieterwechsel nicht zwangsläufig doppelt

zu Buche. Des weiteren wird durch den Marktplatz, der eine weite Masse

an Kunden erreicht, das Anbieten von Nischenprodukten profitabel.

So können deutlich mehr Unternehmen mit spezifischen Anwendungen

versorgt werden. Damit könnte die gegenwärtige Situation vieler

Konsumenten beträchtlich verbessert werden – laut einer Forrester-Stu-

die von 2007 finden 42 % SaaS-interessierte Unternehmen momentan

keine passenden On-Demand-Anwendungen.

106


a Qualitätssteigerung: Geringere Switching Costs und Lock-In-Effekte

erhöhen den Druck auf die Anbieter, was wiederum die Qualität der

Dienste erhöht. Um sich zu differenzieren, müssen Anbieter nicht nur

kompetitive Preise bieten, sondern vor allem über die Servicequalität

Kunden binden. Servicequalität gilt mittlerweile als der wichtigste

Abgrenzungsfaktor.

a Anwendungsintegration: Die Möglichkeit der On-Premise-Integration

der Dienste erhöht Flexibilität. Diese Eigenschaft, die als eine der

Alleinstellungsmerkmale der TEXO Service Management Platform gilt,

kann von Integrationsdiensten auf der Plattform sowie von externen

Partnern unterstützt werden.

a Komplexitätsreduktion: Der Betrieb der Hard- und Software sowie

der Infrastruktur verlagert sich vom Kunden auf die Dienstanbieter

bzw. den Plattformbetreiber. Dies verringert die Komplexität und den

Ressourceneinsatz auf Kundenseite beträchtlich. Auch Updates und

Upgrades werden zentral durchgeführt. So spart der Servicekonsu-

ment nicht nur den Aufwand, sondern kann auch sichergehen, dass an

allen Arbeitsplätzen dieselbe Version verfügbar ist. Auch im Falle von

Nichterfüllung vereinbarter Service Level Agreements (SLAs) unter-

stützt die zentrale Monitoringkomponente der Plattform und bietet

dem Servicekonsumenten einen zentralen Ansprechpartner („one-face-

to-the-customer“). Besteht ein komplexer Dienst beispielsweise aus

drei Teildiensten, muss man sich als Konsument auf die Zuverlässigkeit

von drei Anbietern verlassen können, es gibt drei unterschiedliche

SLAs. Fällt nun ein Teilservice aus, entfaltet der komplexe Service gar

keinen bzw. nicht den vollen Nutzen für den Kunden. Ohne einen zen-

tralen Servicemarktplatz („Single-Point-of-Access“) müsste der Konsu-

ment nun selbst Kompensationszahlungen des betreffenden Anbie-

ters einfordern. Je mehr Anbieter am Dienst beteiligt sind, umso kom-

plexer die Verrechnung unzureichend erbrachter Dienste und die

Ermittlung des Verursachers.

107

www.hessen-it.de

a Wiederverwendbarkeit: Wenn der Kunde auf der Serviceplattform

keine passenden Applikationen findet, bietet die Plattform ein Frame-

work (PaaS) an, mit dessen Hilfe eigene Anwendungen implementiert

werden können. Die selbst implementierten Dienste kann der Kunde

wiederum auf dem Marktplatz anbieten und somit selbst zum Service-

anbieter werden.

a Kostenreduktion: Durch die Möglichkeit, Geschäftsanwendungen

nutzungsbasiert beziehen zu können, müssen Unternehmen nur noch

ihre tatsächliche Nutzung bezahlen. Gerade für kleine und mittelstän-

dische Unternehmen (KMU) war es bisher oftmals unwirtschaftlich,

lizenzbasierte Anwendungen zu betreiben, wenn sie nur wenige Male

zum Einsatz kommen. Durch das On-Demand-Modell ändert sich

diese Situation – KMU können bei Bedarf auf benötigte hochwertige

Applikationen zugreifen. Dies kann nicht nur Kosten reduzieren,

sondern auch die Qualität erhöhen.

a Schnellere Einsatzfähigkeit: Da die SaaS-Anbieter bzw. der Markt-

platzbetreiber sowohl Hard- und Software, als auch die Infrastruktur

liefern, verringert sich in der Regel die Zeit, bis die Applikation ein-

satzfähig ist („Time-to-Market“).

108


imag

eso

urce

Nutzen für Service Provider

Auch für Serviceanbieter ergeben sich zahlreiche Anreize, Anwendungen

auf der Serviceplattform bereitzustellen.

a Flexibilität: Aufgrund der Multimandatenfähigkeit von SaaS-Anwen-

dungen können Anbieter mehrere Tausend Servicekonsumenten mit

derselben Instanz der Applikation bedienen. Durch Rekonfiguration

einzelner Services (vgl. SOA-Paradigma) können Anwendungen

schnell skaliert, geändert, versioniert und aktualisiert werden. Über-

greifend über mehrere Serviceanbieter unterstützt die Plattform so

Agilität und Innovation. Damit zusammenhängend kann die n-te

Anwendung in Kombination mit n-1 vorhandenen Services sehr güns-

tig angeboten werden und liefert die nötige Flexibilität, um Customi-

zing-Wünsche der Servicekonsumenten befriedigen zu können. Wäh-

rend SaaS 1.0 bezüglich Kundenbezogenheit noch recht unflexibel

war, können mit so genannten kompositen Applikationen (Composite

Apps) durch Kooperation von Anbietern komplementärer Dienste

innerhalb der Serviceplattform spezifische Kundenwünsche befriedigt

werden. Dabei kann es sich beispielsweise um die Abbildung komple-

xer Geschäftsprozesse handeln. So können sich Dienstanbieter auf

spezielle Funktionalitäten spezialisieren, bleiben dadurch schlank und

agil, und kooperieren mit Partnern bei der Erstellung komplexer

Dienste.

a Komplexitätsreduktion: Die auf der Plattform angebotenen Infrastruk-

turservices reduzieren den Aufwand für Dienstanbieter. Die eigene

Infrastruktur kann somit minimal gehalten werden, die Plattform über-

nimmt Aufgaben, die für Serviceanbieter bisher als „notwendiges

Übel“ Overhead produziert haben. Beispielsweise können unter ande-

rem Abrechnungsfunktionen, Monitoring, rechtliche Unterstützung,

(dynamische) Preisfindung etc. zentral angeboten werden.

109

www.hessen-it.de

a Wiederverwendbarkeit: Durch die hohe Marktabdeckung einer Ser-

viceplattform können profitabel Nischendienstleistungen angeboten

werden. So kann ein Anbieter günstig, beispielsweise durch Wieder-

verwendung vorhandener Komponenten und das Angebot von nut-

zungsbasierter Abrechnung auch Nachfrage befriedigen, die fernab

der Massenbedürfnisse liegen. Man spricht hierbei vom so genannten

„Long Tail“.

a Kostenreduktion und Skaleneffekte: Die potentiell große Menge an

Servicekonsumenten begünstigt Skalenerträge. Aufgrund des Multi-

mandantenprinzips lassen sich viele Kunden mit nur einer Instanz der

Anwendung bedienen. Wie oben erwähnt, lassen sich durch flexible

Rekonfiguration von Services kostengünstig angepasste komplexe

Dienste erzeugen. Diese werden massiv von Kunden nachgefragt.

Nach einer Forrester-Studie bemängeln 55 % der Befragten eine feh-

lende Customization bei SaaS-Anwendungen. Kosteneinsparungen

sind auch durch Einsparungen im Marketingbereich möglich, da sich

Marketingmaßnahmen durch die Plattform direkt auf Serviceanbieter

auswirken können.

110


© C

har

on

| Dre

amst

ime.

com

8.5 Fazit

Der Wandel zur Dienstleistungsgesellschaft ist aufwendig und vielschich-

tig – Beispiele für die Vielfalt der im Zuge der Dienstorientierung entste-

hen technischen Neuerungen sowie die wirtschaftlichen Risiken, aber

auch Handlungsoptionen wurden hier illustriert.

Ausgehend von der heutigen Situation, das heißt dem Angebot individu-

eller SaaS-Angebote sowie dem Trend hin zu Service Value Networks

sehen wir eine Verlagerung in Richtung eines vernetzten „IT-Ökosystems“.

Diese Zukunftsvision des Internet der Dienste beinhaltet XaaS-Lösungen

mit Fokus auf vernetzten Diensten, Integration, Plattformen, Infrastruktur-

diensten, Brokern etc. In ersten einfachen Ausbaustufen hat das Internet

der Dienste tragfähige Geschäftsmodelle hervorgebracht, die bereits

konkrete Nachfrage bedienen: Der Umsatz von salesforce.com betrug im

Jahre 2008 250 Mio. US Dollar. AppExchange beheimatet mittlerweile

ca. 450 unabhängige Anbieter, die dort ca. 800 komplementäre Anwen-

dungen zu Salesforce bereitstellen. Das Unternehmen hat insgesamt

ca. 47000 registrierte Kunden (Stand 25. Januar 2010).

Unternehmen haben heute die Chance, von solchen Vorreitern oder von

existierenden wegweisenden Forschungsarbeiten zu lernen und die Per-

spektive zu prüfen, eigene Services künftig auf dem tatsächlich globalen

Markt zur Verfügung zu stellen oder Dienste von Dritten in ihre Infrastruk-

tur zu integrieren. Sie können dabei vor allem von offenen Innovations-

prozessen, also der engen Zusammenarbeit mit Lieferanten und Kunden

sowie dem Kreis der Partner profitieren. Innovation findet dabei schon

lange nicht mehr nur über die Technik statt – der zielgerichtetere Einsatz

von Wissen, die intelligenteren Prozesse oder eben das schlagkräftigere

Geschäftsmodell können ebenso differenzierend wirken.

111

www.hessen-it.de

Glossar9

112

Glossar

Business Process Execution Language(BPEL)

BPEL ist eine XML-basierte Beschreibungs-sprache, mit der sich ein fachlicher Prozessspezifizieren lässt. Mit einem BPEL-Editorwird von der Überführung des fachlichenProzesses ein grafisches IT-Prozessmodellerstellt. Dieses Modell enthält die Perspek -tiven der Fach- und der IT-Seite.

Business Process Management (BPM)

BPM ist ein ganzheitlicher Ansatz zumManagement des Lebenszyklusses von Pro-zessen, der zur Prozessoptimierung einge-setzt werden kann. BPM und SOA ergänzensich wechselseitig. Denn einerseits sollteein Prozess, bevor er informationstechnischabgebildet wird, zunächst analysiert undoptimiert werden. Andererseits stellt SOAeine IT-Architektur dar, die eine flexible Pro-zessgestaltung und -verbesserung unter-stützt.

Enterprise Service Bus (ESB)

Der „ESB“ (Gartner 2002) bildet eine Inte -grationsinfrastruktur, die z. B. einem Unter-nehmen einen Service über einen Datenbuszur Verfügung stellt. Ein ESB wird gemein-sam von Service-Gebern und -Nehmerngenutzt, so dass unzählige Punkt-zu-Punkt-Verbindungen vermieden werden.

Governance

SOA-Governance (franz. gouverner, verwal-ten, leiten, erziehen) bezeichnet die soziale,IT- und geschäftsbezogene Steuerung undKontrolle eines SOA-Prozesses. Sie umfasstdiesbezügliche Aktivitäten, Entscheidun-gen, Rollen und Verantwortlichkeiten.

Orchestrierung

Der Prozess oder Zustand einer losen Ver-kopplung von Services z. B. mittels BPELwird Orchestrierung genannt. Durch dieVerkopplung wird ein neuer übergeord -neter Service mit erweiterten Funktionenoder eine neue Anwendung erzeugt.

Registry

Ein Verzeichnis oder Katalog verfügbarer Services mit nur wenigen Metadaten wieetwa einer Schnittstellenbeschreibung wirdRegistry genannt. Einem Branchen-Telefon-buch ähnlich gehen daraus im Wesent -lichen nur die Adresse und wenige Zusatz-informationen hervor.

Repository

Das Repository dient – stärker als das Registry – als Instrument der SOA-Gover-nance zur Steuerung und Kontrolle von Services. Es speichert und kategorisiert dieServices mit ihren zugehörigen Aspekten.Werden Registry und Repository zu einerintegrierten Einheit zusammengefasst, werden sie als „Repistry“ bezeichnet.

Service

Ein Service (Dienst) ist die zentrale Grund-komponente einer SOA. Er stellt eine eigen-ständige und unabhängige funktionale Einheit dar. Wird ein Service mit einer stan-dardisierten Schnittstelle über Web Servicesmit anderen Services verknüpft, entstehteine serviceorientierte Architektur.

Web Service

Unter Web Service kann man lose gekop-pelte, wieder verwendbare Softwarekompo-nenten verstehen, die unter Verwendungvon Internetstandards aufgerufen werdenkönnen und über den Austausch von XML-basierten Nachrichten miteinander kommu-nizieren. Web Services sind der zentraleStandard zur Realisierung von Service-Schnittstellen und zur Kopplung von Services.

113

www.hessen-it.de

114

Ihre Partner in Hessen

Fehlt Ihr Eintrag? Dann senden Sie uns

Ihre Angaben an [email protected]


Hier finden Sie eine Auswahl an hessischen Unternehmen, Wissenschafts- und

Forschungseinrichtungen sowie anderen Akteuren mit Kompetenzen im Bereich von

serviceorientierten Architekturen. Die Listung erhebt keinen Anspruch auf Vollständig-

keit. Weitere Informationen über mögliche SOA-Partner mit Sitz in Hessen erhalten Sie

im Internet unter www.kompetenzatlas-hessen.de.

10

Accelsis Technologies GmbH

Mergenthalerallee 7765760 Eschborn

Frank JoecksTelefon 06196 470520Telefax 06196 470549 [email protected]

www.accelsis.biz

Accenture GmbH

Campus Kronberg 1 61476 Kronberg im Taunus

Telefon 06173 94-99Telefax 06173 [email protected]

www.accenture.com

Accurat Informatik GmbHIm Gefierth 13c63303 Dreieich


www.accurat.de

ALTRAN Deutschland Holding GmbH Schillerstraße 20 60313 Frankfurt am Main

Telefon 069 219767-70 Telefax 069 219767-76 [email protected]

www.altran.de

arlanis Software AGMannheimer Straße 9760327 Frankfurt am Main

Andreas HolubekTelefon 069 241829-0Telefax 069 [email protected]

www.arlanis.com

ATE Software GmbH Bockenheimer Anlage 460322 Frankfurt Main

Thomas ErbrichTelefon 069 9150119-0 Telefax 069 [email protected]

www.ate-software.net

Avanade Deutschland GmbHCampus Kronberg 761476 Kronberg

Telefon 06173 94 63800Telefax 06173 94 [email protected]

www.avanade.de

Axway GmbHMainzer Landstraße 61 60329 Frankfurt am Main

Telefon 069 244 508-0Telefax 069 244 [email protected]

www.axway.de

BLAUERLOTOS GmbH & Co. KGAm Felsenkeller 8a63505 Langenselbold

Telefon 06184 937221Telefax 06184 [email protected]

www.blauerlotos.com

CA Deutschland GmbHMarienburgstraße 3564297 Darmstadt


www.ca.com/de

CASED – Center for Advanced SecurityResearch Darmstadt

DirektorMornewegstraße 3264293 Darmstadt

Prof. Dr. Johannes BuchmannTelefon 06151 16-50777Telefax 06151 [email protected]

www.cased.de

Software-Cluster KoordinierungsstelleMornewegstraße 3264293 Darmstadt

Gino BrunettiTelefon 06151 16-70821Telefax 06151 [email protected]

www.cased.de

CAST e.V. – Competence Center forApplied Security Technology

GeschäftsführungFraunhoferstraße 564283 Darmstadt

Claudia PredigerTelefon 06151 155-529Telefax 06151 [email protected]

www.cast-forum.de

GeschäftsführungFraunhoferstraße 564283 Darmstadt

Prof. Dr. Andreas HeinemannTelefon 0621 4105-1170Telefax 06151 [email protected]

www.cast-forum.de

Corisecio GmbHUhlandstraße 964297 Darmstadt


www.corisecio.com

CSC in DeutschlandAbraham-Lincoln-Park 165189 Wiesbaden

Telefon 0611 142-0Kundeninfo 0611 142-22222 Telefax 0611 [email protected]

www.csc.com/de

Daenet GmbHHanauer Landstraße 20460314 Frankfurt am Main


www.daenet.de

115

www.hessen-it.de

DB Systel GmbHKleyerstraße 2760326 Frankfurt am Main

Gunnar RühlTelefon 069 265-17800Telefax 069 [email protected]

www.dbsystel.de

Detecon International GmbHFrankfurter Straße 2765760 Eschborn

Dieter WendelTelefon 06196 903-255Telefax 06196 [email protected]

www.detecon.com

Devoteam Danet GmbHGutenbergstraße 1064331 Weiterstadt

Telefon 06151 [email protected]

www.devoteam.de

EDAG GmbH & Co. KGaAReesbergstraße 136039 FuldaIT Services

Raoul FlügelTelefon 0661 6000-596Telefax 0661 [email protected]

www.edag.com

Epicor Software Deutschland GmbHHanauer Landstraße 291a60314 Frankfurt am Main


www.epicor.de

European Business School Institute of Research on Information Systems IRISRheingaustraße 165375 Oestrich-Winkel

Dr. Christine LegnerTelefon 06723 991-251Telefax 06723 [email protected]

www.ebs.edu/iris

Fachhochschule Gießen-FriedbergWiesenstraße 1435390 Gießen

Prof. Dr. Thomas LetschertTelefon 0641 309-2388Telefax 0641 [email protected]

www.mni.fh-giessen.de

FORTENO GmbHTaunusstraße 66 65183 Wiesbaden


www.forteno.com

Frankfurt School ofFinance & Management

WirtschaftsinformatikManagement Research Centre Sonnemannstraße 9-1160314 Frankfurt am Main

Prof. Dr. Matthias Goeken (JP)Telefon 069 154008-746 Telefax 069 [email protected]

www.frankfurt-school.de

Prof. Dr. Peter RossbachTelefon 069 154008-739 Telefax 069 154008-4739 [email protected]

www.frankfurt-school.de

116


Fraunhofer-Institut für Sichere Informationstechnologie (SIT)

InstitutsleitungRheinstraße 7564293 Darmstadt

Prof. Dr. Claudia EckertTelefon 06151 869-285Telefax 06151 [email protected]

www.sit.fraunhofer.de

Gartner Deutschland GmbHLyoner Straße 2060528 Frankfurt


www.gartner.com

HA Hessen-Agentur GmbHsiehe Hessen-IT

Hessen-ITAktionslinie für den hessischen IKT-Markt des Hessischen Ministeriumsfür Wirtschaft, Verkehr und Landes-entwicklung (HMWVL) c/o HA Hessen Agentur GmbH Abraham-Lincoln-Straße 38–42 65189 Wiesbaden

Wolf-Martin AhrendTelefon 0611 774-8299Telefax 0611 [email protected]

www.hessen-it.de

Dr. Matthias DonathTelefon 0611 774-8963Telefax 0611 [email protected]

www.hessen-it.de

Hochschule FuldaAngewandte Mathematik, Kryptographie, IT-SicherheitMarquardstraße 3536039 Fulda

Prof. Dr. Ulrich BühlerTelefon 0661 9640-325Telefax 0661 [email protected]

www.informatik.hs-fulda.de

Hochschule RheinMainDesign Informatik MedienLabor für Verteilte SystemeKurt-Schumacher-Ring 1865197 Wiesbaden

Prof. Dr. Reinhold KrögerTelefon 0611 9495-1207, -1202Telefax 0611 [email protected]

wwwvs.cs.hs-rm.de

Hochschule DarmstadtInformatikSchöfferstraße 8b64295 Darmstadt

Prof. Dr. Bernhard HummTelefon 06151 16-8494Telefax 06151 [email protected]

www.fbi.h-da.de

Informatik, Institut für Angewandte Informatik Darmstadt (aiDa)Schöfferstraße 8b64295 Darmstadt

Prof. Dr. Hans-Peter WiedlingTelefon 06151 16-8441Telefax 06151 [email protected]

www.aida.h-da.de

HTTC – Hessisches Telemedia Techno logie Komptenz-Center e.V.

siehe SOA Competence Center im HTTC e.V.

117

www.hessen-it.de

IDC Central Europe GmbHHanauer Landstraße 135-13760314 Frankfurt

Telefon 069-90502-0Telefax [email protected]

www.idc.com

infodienst GmbHSchützenrain 961231 Bad Nauheim


www.4soa.de

Informatica GmbHLyoner Straße 1560528 Frankfurt

Telefon 069 928809-0Telefax [email protected]

www.informatica.com/de

Information Builders (Deutschland) GmbHMergenthalerallee 3565760 EschbornAnja Griebel


www.informationbuilders.de

intelligent views gmbHJulius-Reiber-Straße 1764293 Darmstadt

Claudia BaumerTelefon 06151 5006-423Telefax 06151 [email protected]

www.i-views.de

Intersystems GmbHHilpertstraße 20a64295 Darmstadt

Thomas MironiukTelefon 06151 1747-0Telefax 06151 [email protected]

www.intersystems.de

Intraprend Gesellschaft für IntranetAnwendungsentwicklung mbH

Borsigstraße 1865205 Wiesbaden


www.cierp3.de

iPIsec Ltd.Auguste-Viktoria-Straße 361231 Bad Nauheim

Wolfgang GeiselTelefon 06032 93897-12Telefax 06032 [email protected]

www.ipisec.com

Johann Wolfgang Goethe-UniversitätInstitut für Wirtschaftsinformatik Grüneburgplatz 1 60323 Frankfurt am Main

Prof. Dr. Wolfgang König Telefon 069 798-34001 Telefax 069 798-33910 [email protected]

www.wiwi.uni-frankfurt.de

Datenbanken und Informationssysteme (DBIS)Robert-Mayer-Straße 1060054 Frankfurt am Main

Prof. Dr.-Ing. Roberto V. ZicariTelefon 069 798-28212Telefax 069 [email protected]

www.dbis.informatik.uni-frankfurt.de

118


Justus-Liebig-Universität GießenInstitut für InformatikArndtstraße 235392 Gießen

Prof. Dr. Martin Kutrib Telefon 0641 99-32140Telefax 0641 [email protected]

www.informatik.uni-giessen.de

Logica Deutschland GmbH & Co. KG

Rheinstraße 9564295 DarmstadtTelefon 06151 36860-0Telefax 06151 36860-222

Am Limespark 265843 Sulzbach (Taunus)Telefon 06196 7742-0Telefax 06196 7742-555www.logica.com

msgGillardon AGMergenthalerallee 55-59 65760 Eschborn

Dr. Nicolas ReppTelefon 06196 7750-0Telefax 06196 [email protected]

www.msg-gillardon.de

Lufthansa Systems AGAm Weiher 2465451 Kelsterbach


www.LHsystems.com

OctaVIA AGMarie-Calm-Straße 1-5 34131 Kassel


www.octavia.de

Opitz Consulting Bad Homburg GmbHKaiser-Friedrich-Promenade 93-9561348 Bad Homburg v. d. H.

Markus GanssTelefon 06172 66260-0Telefax 06172 [email protected]

www.opitz-consulting.de

PA Consulting Group Deutschland GmbHEschersheimer Landstraße 22360320 Frankfurt am Main


www.paconsulting.com

Philipps-Universität MarburgFachbereich Mathematik und InformatikHans-Meerwein-Straße 335032 Marburg

Prof. Dr. Bernd FreislebenTelefon 06421 2821-568Telefax 06421 [email protected]

www.informatik.uni-marburg.de

Rücker AGKreuzberger Ring 4065205 Wiesbaden


www.ruecker.de

Saugatuck Technologies Inc.Bluecherstraße 465343 Eltville

Frank P. SempertTelefon 06123 630285Telefax 06123 [email protected]

www.saugatech.com

119

www.hessen-it.de

SAP Research CEC DarmstadtBleichstraße 8 64283 Darmstadt

Dr. Knut ManskeTelefon 06227 7-68844Telefax 06227 [email protected]

www.sap.com/research

Software AGUhlandstraße 1264297 Darmstadt

Daniel Adelhardt Telefon 06151 92-1403Telefax 06151 92-11 [email protected]

www.softwareag.com

SOA Competence Center im HTTC e.V. Rundeturmstraße 1064283 Darmstadt

Dr.-Ing. Julian EckertTelefon 06151 16-3742Telefax 06151 [email protected]

www.httc.de

Stefan SchulteTelefon 06151 16-6187Telefax 06151 [email protected]

www.httc.de

Software & Support Verlag GmbHGeleitsstraße 1460599 Frankfurt am Main

Mirko SchremppTelefon 069 630089-38Telefax 069 [email protected]

www.software-support.biz

SP Integration GmbHOtto-Volger-Straße 5a 65843 Sulzbach/Taunus


www.sp-integration.de

Sylphen GmbH & Co. KGLiebigstraße 1435390 Gießen

Ralph BoßlerTelefon [email protected]

www.sylphen.com

Syngenio AGSchiersteiner Straße 8665187 Wiesbaden

Stefan ScheidTelefon 0611 450415-0Telefax 0611 [email protected]

www.syngenio.de

T-Systems International GmbHOtto-Röhm Straße 71c64293 Darmstadt

Bernard TsaiTelefon 06151 886-1757Telefax 06151 [email protected]

www.t-systems.de

Tieto Deutschland GmbHDüsseldorfer Straße 4065760 Eschborn

Telefon 06196 9329-0Telefax 06196 9329-898

http://tieto.de

120


Technische Universität Darmstadt

Information Systems / WirtschaftsinformatikHochschulstraße 164289 Darmstadt

Prof. Dr. Peter Buxmann Telefon 06151 16-4826Telefax 06151 [email protected]

www.is.tu-darmstadt.de

Multimedia Communications LabRundeturmstraße 1064283 Darmstadt

Prof. Dr.-Ing. Ralf SteinmetzTelefon 06151 16-6151Telefax 06151 [email protected]

www.kom.tu-darmstadt.de

Unisys Deutschland GmbHAm Unisys-Park 165843 Sulzbach


www.unisys.de

Universität KasselKommunikationstechnikWilhelmshöher Allee 7334121 Kassel

Prof. Dr.-Ing. Klaus DavidTelefon 0561 804-6314Telefax 0561 [email protected]

www.comtec.eecs.uni-kassel.de

Verteilte SystemeWilhelmshöher Allee 7334121 Kassel

Prof. Dr. Kurt GeihsTelefon 0561 804-6275Telefax 0561 [email protected]

www.vs.uni-kassel.de

121

www.hessen-it.de

Profile der Unternehmen und Institutionen derAutoren in der Reihenfolge des Erscheinens11

122

Profile der Unternehmen und Institutionen der Autoren in der Reihenfolge des Erscheinens

SOA Competence Center im httc e.V.

Das SOA Competence Center (SCC) ist einGeschäftsbereich des Hessischen Teleme-dia Technologie Kompetenz-Centers e.V. inDarmstadt (httc e.V.). Das SCC berät Unter-nehmen und Organisationen im Rahmenvon Software-Architekturprojekten im Kontext serviceorientierter Architekturen.Die Leistungen des SCC richten sich anUnternehmen, die SOA planen, einführen,optimieren und als Infrastruktur anbieten.

www.httc.de

Dr. Wolfgang Martin Team

Dr. Wolfgang Martin ist ein unabhängigerAnalyst und europäischer Experte auf denGebieten Business Intelligence / CorporatePerformance Management (BI / CPM), Busi-ness Process Management, Enterprise Infor-mation Management (Business Integration),Service Oriented Architecture (SOA) undCustomer Relationship Management (CRM)

www.wolfgang-martin-team.net

Software AG

Software AG ist ein weltweit führendesUnternehmen im Bereich Business ProcessExcellence. Der Unternehmensumsatzbeläuft sich auf mehr als 1 Milliarde Euro(2009), mehr als 6000 Mitarbeiter gehörenzum Unternehmen, und es beliefert über10 000 Kunden in 70 Ländern weltweit. DasUnternehmen hat seinen Hauptsitz inDeutschland und ist an der FrankfurterWertpapierbörse notiert.

www.softwareag.com

Opitz Consulting Bad Homburg GmbH

OPITZ CONSULTING ist ein Projektspezialistim Java-, SOA- und Oracle-Markt. Das Unter -nehmen unterstützt bei der Erstellung einerIT-Strategie und berät bei dem Prozessde-sign und der Aufnahme der Anforderungen.Es konzipiert und realisiert kundenspezifi-sche IT-Lösungen, gewährleistet einen hoch-verfügbaren Betrieb und bildet Mitarbeiterin Schulungszentren aus. OPITZ CONSUL-TING wurde 1990 gegründet und beschäf-tigt über 400 Mitarbeiter an Standorten inDeutschland, Polen und der Schweiz.

www.opitz-consulting.com

Detecon International GmbH

Detecon International ist ein weltweit führen -des Unternehmen für integrierte Manage-ment- und Technologieberatung entlang dergesamten Wertschöpfungskette der Kunden.Detecon International entstand 2002 aus derFusion der beiden Beratungshäuser DETE-CON und Diebold und ist ein Tochterunter-nehmen der T-Systems.

www.detecon.com

Intersystems GmbH

InterSystems ist ein mehr als 30 Jahreerfolgreicher Softwarehersteller im Bereichobjektorientierte Datenbanken, Kommuni-kationsserver, Integrationsplattformen undLösungen für das Gesundheitswesen.

www.intersystems.de

Corisecio GmbH

CORISECIO ist ein führender Hersteller vonautomatisierten Security-Produkten fürSOA-Infrastrukturen. Basierend auf dereigenen Open Platform sind Enterprise-Lösungen für SOA Security und SAP sowieMobile Security und Database Encryptionerfolgreich in mehr als 50 Ländern im Ein-satz. CORISECIO hat ihren Hauptsitz inDarmstadt und wird durch Vertriebspartnerweltweit unterstützt.

www.corisecio.com

European Business School

Die European Business School (EBS) istDeutschlands älteste private wissenschaft -liche Hochschule mit hervorragendemnationalen und internationalen Ruf. ImBereich Wirtschaftsinformatik bietet sie praxisnahe Studienangebote (Bachelor-,Master- und Executive-Programme) undForschung zu aktuellen Fragen des strate -gischen IT-Managements an.

www.ebs.edu/iris

FZI Forschungszentrum Informatik

Das FZI Forschungszentrum Informatik Karls-ruhe hilft – als unabhängige Forschungs -einrichtung des Landes Baden-Württem-berg – Unternehmen und öffent lichen Ein-richtungen, gemeinsam Innova tionen zuentwickeln. Informatik als Schlüssel zuneuen Technologien steht im Mittelpunktvon Anwendungsforschung, Entwicklungund Technologietransfer.

www.fzi.de

123

www.hessen-it.de

Die Aktionslinie Hessen-IT

Hessen-IT ist die Aktionslinie des Hessischen Ministeriums für Wirtschaft,

Verkehr und Landesentwicklung für den gesamten Informations- und

Kommunikationstechnologiemarkt in Hessen. Hessen-IT bietet Informatio-

nen und Services zum Online-Markt, zu E- und M-Commerce, zu Software-

und Telekommunikationsanbietern sowie über Telearbeit. Angesprochen

werden auf der einen Seite die fast 10.000 hessischen Unternehmen, die

Produkte oder Dienstleistungen auf dem Informations- und Kommunikati-

onstechnologiemarkt anbieten, auf der anderen Seite die kleinen und

mittleren Anwender-Unternehmen.

Anbieter-Datenbanken erleichtern die Suche nach geeigneten Dienstleis-

tern bei der Durchführung von IT-Projekten. Gleichzeitig fungieren diese

Datenbanken für Anbieter als Informations- und Kommunikationsplatt-

form, auf der sich diese den Anwendern und potenziellen Kunden präsen-

tieren können.

Newsticker, E-Mail- und Print-Newsletter berichten regelmäßig über den

IKT-Markt in Hessen. Zahlreiche Schriftenreihen und Veröffentlichungen

ergänzen das Informationsangebot der Website. Die Broschüren können

bequem online bestellt oder heruntergeladen werden.

Hessen-IT hat verschiedene Netzwerke und Branchentreffs initiiert, in

denen sich teils nichtkommerzielle Initiativen, teils kommerzielle Anbieter

zusammengeschlossen haben. Regionale Multimedia- und E-Commerce-

Zentren sowie IHKs, Handwerkskammern und andere regionale Akteure

arbeiten zusammen an dem Ziel, Hessens starke Stellung im deutschen

und europäischen IKT-Markt weiter zu sichern und auf dem Weg in die

Informationsgesellschaft weiter voran zu bringen.

12

124

Die Aktionslinie Hessen-IT

Einen Überblick über diese Netzwerke und Treffen sowie Terminankündi-

gungen zu Veranstaltungen, an denen Hessen-IT beteiligt ist, finden Sie im

Online-Terminkalender auf der Website. Auch bei internationalen Messen

wie der CeBIT oder bei regionalen Veranstaltungen in ganz Hessen sind

kompetente Ansprechpartner der Aktionslinie präsent. Hinzu kommen

Seminare und Workshops, die Hessen-IT zu verschiedenen Themen aus-

richtet.

Das Projektteam von Hessen-IT steht Ihnen jederzeit gerne als Ansprech-

partner zur Verfügung. Besuchen Sie unsere Website unter

www.hessen-it.de

125

www.hessen-it.de

Schriftenreihe Hessen-IT (vormals Hessen-Media)

Bestellmöglichkeit und Download als PDF-Datei finden

Sie im Internet unter www.hessen-it.de

Wir über uns

2001 Hessen-infoline-Netzwerk (Band 26)

Projektdokumentation (Band 1)

Bildung und Wissenschaft

2002 Telemedizin in Hessen–Beiträge aus dem Universitätsklinikum Gießen (Band 24)

2001 Entwicklung und Einsatz elektronischer Medien als Lehr- und Lernmittel

an hessischen Hochschulen (Band 27)

Kompetenzzentren und Onlinedienste im Schulwesen

– Beispiele für Hessen-Media Projekte (Band 25)

2000 Die virtuelle Universität (Band 15)

E-Government

2002 Auf dem Weg zu E-Government – Hessens Kommunen im Internet (Band 37)

Wirtschaftsförderung und Standortmarketing im Internet (Band 36)

Marktstudien IT-Standort Hessen

2008 Telekommunikationsanbieter in Hessen 2008 (Band 60)

2006 IKT-Markt in Hessen (Band 58)

2004 Softwareanbieter in Hessen 2004 (Band 50)

Telekommunikationsanbieter in Hessen 2004 (Band 49)

2003 Online-Anbieter in Hessen (Band 2)

2002 E-Shops in Hessen (Band 28)

2000 Der Telekommunikationsmarkt in Hessen (Band 21)

126

Schriftenreihe Hessen-IT

Leitfäden für IT-Anwendungen

2010 Notleidende Projekte – Eine Hilfestellung für IT-Projekte in sieben Akten

(Band 64)

Die Gamesbranche – ein ernstzunehmender Wachstumsmarkt

(Band 59, 2. aktualisierte Auflage)

SOA – Mehr als nur flexible Softwarearchitekturen (Band 63)

Satellitennavigation in Hessen – Ideen über All (Band 65)

Ambient Mobility – Intelligent Products and Environments for Mobile

Citizens and Businesses (Band 62)

2009 Ambient Mobility – Intelligente Produkte und Umgebungen

für mobile Bürger und Unternehmen (Band 61)

Rating für IKT-Unternehmen (Band 53, 2. aktualisierte Auflage)

2008 Leitfaden zur Patentierung computer implementierter Erfindungen

(Band 51, 2. aktualisierte Auflage)

2007 Web 2.0 – Neue erfolgreiche Kommunikationsstrategien

für kleine und mittlere Unternehmen (Band 57)

Die Gamesbranche – ein ernstzunehmender Wachstumsmarkt (Band 59)

In modernen Märkten überleben – Kooperationen

mittelständischer Softwareunternehmen in Hessen (Band 44, 2. Auflage)

2006 Internet-Marketing nicht nur für kleine und mittlere Unternehmen (Band 52)

Basel II – Rating für IT-Unternehmen (Band 53)

RFID – Geschäftsprozesse mit Funktechnologie unterstützen (Band 54)

Anti-Spam – Ein Leitfaden über und gegen unverlangte E-Mail-Werbung

(Band 55)

VoIP – Telefonieren über das Internet (Band 56)

Leitfaden Webdesign – Internetpräsenzen besser planen und gestalten

(Band 7, 5. Auflage)

2005 Recht im Internet (Band 33, 2. Auflage)

Gefunden werden im Internet (Band 32, 2. Auflage)

2004 Wettbewerbsvorteile durch barrierefreie Internetauftritte (Band 48)

Domainregistrierung international (Band 47)

Wireless-LAN: Stand und Entwicklungspotenzial, Nutzungsansätze für KMU

(Band 46)

127

www.hessen-it.de

2003 E-Business-Konzepte für den Mittelstand (Band 45)

Leitfaden „In modernen Märkten überleben“ (Band 44)

Projektleitfaden „Software-Ergonomie“ (Band 43)

„Digitale Signatur“, Leitfaden zum Einsatz digitaler Signaturen (Band 42)

Die Bedeutung der E-Logistik für den Mittelstand (Band 41)

Management von Kundenbeziehungen im Internet (Band 40)

Leitfaden „Webdesign – Internetpräsenzen besser planen und gestalten“ (Band 7)

2002 IT-Sicherheit für den Mittelstand (Band 38)

E-Paymentsysteme – Bezahlen im Internet (Band 35)

ASP: Mehr als nur Mietsoftware (Band 34)

Recht im Internet (Band 33)

Gefunden werden im Internet (Band 32)

E-Learning für KMU – Neue Medien in der betrieblichen

Aus- und Weiterbildung (Band 31)

Telehaus Wetter – ein TeleServiceZentrum (Band 30)

2001 Kasseler Praxis-Dialog Tele@rbeit – Analysen · Erfahrungen · Positionen

(Band 29)

2000 Leitfaden „Webdesign international“ (Band 22)

E-Shop-Software (Band 20)

Hessische Handwerker entdecken das Internet (Band 19)

Leitfaden zur Anwendung eines Ratingsystems für IT-Unternehmen in Hessen

(Band 18)

Software-Dialog Hessen (3) (Band 17)

Leitfaden „E-Shop“ (Band 16)

128

Schriftenreihe Hessen-IT

ISBN 978-3-939358-63-3

Documents

Hessen Trade & Invest GmbH - Hessisches Ministerium für … · 2013-06-06 · HA Hessen Agentur GmbH Hessen-IT Abraham-Lincoln-Straße 3 8–42 65189 Wiesbaden Telefon 0611 77 4-