SOA - Mehr als nur flexible Softwarearchitekturen by Hessen Agentur

Hessisches Ministerium für Wirtschaft, Verkehr und Landesentwicklung www.hessen-it.de

SOA Mehr als nur flexible Softwarearchitekturen

Band 63

Hessen

SOA Mehr als nur flexible Softwarearchitekturen

Hessen-IT Band 63

Benjamin Blau Tobias Conte Dr. Julian Eckert Norbert Eder Markus Ganß Dr. Ralf Helbig Dr. Carsten Holtmann Dr. Christine Legner Dr. Wolfgang Martin Thomas Mironiuk Dr. Bruno Quint Dr. Nicolas Repp

Hessisches Ministerium für Wirtschaft, Verkehr und Landesentwicklung

HA Hessen Agentur GmbH Hessen-IT Abraham-Lincoln-Straße 38–42 65189 Wiesbaden Telefon Telefax E-Mail Internet

0611 774-8481 0611 774-8620 info@hessen-it.de www.hessen-it.de

Redaktionsteam: Dr. Matthias Donath Christian Flory Wolf-Martin Ahrend Gabriele Gottschalk

Alle Rechte vorbehalten. Nachdruck, auch auszugsweise, verboten. © Hessisches Ministerium für Wirtschaft, Verkehr und Landesentwicklung Hessen-IT c/o HA Hessen Agentur GmbH Wiesbaden 2010 Layout/Satz: WerbeAtelier Theißen, Lohfelden Titelcollage: WerbeAtelier Theißen unter Verwendung einer Abbildung von AndyL/istockphoto Druck: Druckerei ausDRUCK, Kassel ISBN 978-3-939358-63-3 Bibliografische Informationen der Deutschen Bibliothek: Die Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.ddb.de abrufbar.

Liebe Leserinnen und Leser, Innovationen sind der Motor für unser Wachstum und unseren Wohlstand in der Zukunft. Im globalen Wettbewerb müssen die westlichen Industrieländer ihre Wirtschaftsgüter nicht nur schneller anbieten, sie müssen auch neuartige, qualitativ hochwertige und technisch fortschrittliche Angebote entwickeln. Informations- und Kommunikationstechnologien (IKT) haben dabei für Unternehmen eine Schlüsselfunktion. Denn sie unterstützen beides: effiziente interne Prozesse und zukunftsorientierte, IKT-basierte Dienste und Produkte. Voraussetzung hierfür ist der Einsatz von hochgradig flexiblen Software- und IKT-Systemen in den Unternehmen. Diese Flexibilität lässt sich mit so genannten serviceorientierten Architekturen (SOA) erzielen. Das SOA-Prinzip strukturiert ein Softwaresystem (Architektur) gemäß seiner einzelnen funktionalen Dienste (Services), welche die IKT für den Geschäftsprozess erbringt. Durch eine Unterteilung des Softwaresystems in lose gekoppelte Module, die sich variabel und mehrfach kombinieren lassen, werden dynamisch veränderbare und vielfältig gestaltbare IKT-Systeme möglich. Entsprechend lassen sich komplexe Softwaresysteme nicht nur übersichtlicher gestalten und Unternehmensstrategien agiler umsetzen – auch neue, innovative Geschäftsmodelle und Geschäftsfelder werden realisierbar. Deswegen sind serviceorientierte Architekturen und Anwendungen zu Leitansätzen in der Softwareentwicklung geworden. Sie nutzen großen Unternehmen und bieten auch mittleren und kleinen Firmen beträchtliche Chancen. Die Softwareregion Rhein-Main-Neckar hat sich als „Silicon Valley Europas“ (Truffle-Studie 2010) zu einem Kompetenzzentrum für SOA entwickelt. Mit diesem Leitfaden, der Beiträge regionaler Experten enthält, möchten wir Ihnen einen praxisnahen Zugang zum vielschichtigen Thema SOA eröffnen und auf die Stärke des SOA-Standortes Hessen hinweisen. Nehmen Sie Kontakt mit den aufgeführten Experten auf oder wenden Sie sich einfach an das Projektteam von Hessen-IT. Für die serviceorientierten Aktivitäten Ihres Unternehmens wünsche ich Ihnen viel Erfolg!

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

SOA

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

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

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

2010

Schriftenreihe Hessen-IT: Neuerscheinungen Ambient Mobility – Intelligent Products and Environments for Mobile Citizens and Businesses Die Gamesbranche – ein ernstzunehmender Wachstumsmarkt (2. aktualisierte Auflage)

Notleidende Projekte – Eine Hilfestellung für IT-Projekte in sieben Akten Satellitennavigation in Hessen – Ideen über All

2009

Ambient Mobility – Intelligente Produkte und Umgebungen

2008

SOA – Mehr als nur flexible Softwarearchitekturen

Leitfaden zur Patentierung computerimplementierter

Hessen

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

Erfindungen (2. aktualisierte Auflage) Telekommunikationsanbieter in Hessen 2008

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

www.hessen-it.de

Einleitung Am 12. April 1996 hat das Marktforschungsunternehmen Gartner in zwei „Research Notes“ den Begriff der „serviceorientierten Architektur“ (Service Oriented Architecture) erstmals verwendet und damit eine neue Sichtweise geprägt. Habe man früher – so Gartner in einem Vergleich zur Luftfahrtindustrie – geschaut, welche Flugzeugarten gebaut werden könnten, betrachte man nun, welche sinnvollen Transportdienste (transportation services) man anbieten kann. Nicht mehr die Technologie steht im Vordergrund, sondern das Geschäft, in dessen Dienst sie steht. Um eine größere Flexibilität zu erreichen, wird das Geschäft in einzelne Teilprozesse aufgeteilt und diesen werden entsprechende IT-Dienste (Services) mit dahinter liegenden Backend-Systemen zugeordnet. Die einzelnen Services sind über standardisierte Schnittstellen lose miteinander gekoppelt, so dass sie flexibel kombinierbar und wieder verwendbar sind und agile Geschäfte ermöglichen.

Prozesse Services Externer Service-Anbieter

BackendSysteme

3-Ebenen-Modell einer serviceorientierten Architektur

Heute, 14 Jahre nach seiner Einführung, hat das SOA-Prinzip nichts von seiner Aktualität verloren. Im Gegenteil, je größer der Wettbewerbsdruck, desto wichtiger werden flexible Geschäfts- und IKT-Prozesse sowie innovative IKT-basierte Dienste und Produkte. Unternehmen mit einer serviceorientierten Architektur können nicht nur ihre internen Services flexibel miteinander kombinieren. Sie können auch externe Services besser anund einbinden und damit die Vorteile von Software-as-a-Service (SaaS)

Einleitung

besser nutzen. Beim SaaS-Ansatz wird Software als mietbarer Dienst über das Netz bezogen bzw. betrieben. Unternehmen können sich damit besser auf Ihre Kernkompetenzen konzentrieren und andere Prozesse an Dienstleister bzw. Services übertragen, die darauf spezialisiert sind. Wertschöpfung entsteht noch stärker im Verbund. Diese Strategie ist eng mit dem Ziel des BMBF-Spitzenclusters „Softwareinnovationen für das digitale Unternehmen“ mit Sitz in Darmstadt verknüpft. Das Software-Cluster möchte Unternehmen durch den Einsatz von so genannter emergenter Software die Entwicklung zu vollständig digitalen Unternehmen ermöglichen. Digitale Unternehmen arbeiten in hochflexiblen, internetbasierten Unternehmensnetzen und richten ihre Geschäftsmodelle und -prozesse dynamisch darauf aus. Alle Daten über Prozesse, Betriebsmittel und Ressourcen in der realen Unternehmenswelt sollen ihnen jederzeit in genauer zeitlicher und räumlicher Auflösung zur Planung, Steuerung und Optimierung zur Verfügung stehen. Das kann nur erreicht werden, wenn emergente Software eine Vielzahl von Softwarekomponenten unterschiedlicher Hersteller dynamisch und flexibel kombinieren kann. Auch das so genannte Internet der Dienste (Internet of Services) setzt bei serviceorientierten Architekturen und Anwendungen an. Hierbei handelt es sich um die Weiterentwicklung des bestehenden Internets zu einem Netzwerk, dass nicht nur allgemeine Informationen, sondern auch personen- und situationsbezogene Informationen, also Dienstleistungen, erbringt. Technisch baut das Internet der Dienste auf Services auf, die – obwohl sie zum Teil von unterschiedlichen Anbietern stammen – miteinander kombiniert und zu komplexeren Services zusammengefügt werden können. Im Rahmen des Leitprogramms in der IKT-Förderung des Bundesministeriums für Wirtschaft und Technologie (BMWi) THESEUS soll das Projekt TEXO, an dem eine Reihe von hessischen Partnern beteiligt sind, genau in diese Richtung führen (siehe S. 98).

www.hessen-it.de

Angesichts all dieser Entwicklungen verwundert es nicht, dass der Markt von und um serviceorientierte(n) Architekturen ein beständig signifikantes Wachstum vollzieht. Eine Studie der Analysten- und Beratungsgesellschaft Pierre Audin Consultants (PAC) vom 30. Juli 2009 – unter Mitwirkung von IDATE, Fraunhofer ISI und London Economics im Auftrag der Europäischen Kommission – prognostiziert ein Wachstum des europäischen SOAMarktes (EU 27) von 38 % in 2010, 31 % in 2011 und 25 % in 2012.

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

2007

2008

2009

2010

2011

2012

EU 27

2057

3534

4838

6678

8808

11002

Jährliches Marktwachstum Jahr

2007

2008

2009

2010

2011

2012

EU 27

–

71,8 %

36,9 %

38,1 %

31,9 %

24,9 %

Lizenzen und Wartung

Mio. Euro

IT-Dienstleistungen

12000 10000 8000 6000 4000 2000 0 2007

2008

2009

2010

2011

2012

Prognose SOA-Marktentwicklung in EU 27 Quelle: PAC, D2 – The European Software Industry, Economic and Social Impact of Software & Software-Based Services, 30. Juli 2009

Einleitung

In dieser Broschüre werden einzelne wichtige Aspekte des Wachstumsmarktes serviceorientierter Architekturen von regionalen Experten erläutert, um Entwicklungen in diesem Bereich begleitend voran zu treiben. Zunächst werden wesentliche Grundlagen und Vorteile des SOA-Ansatzes vermittelt, verbunden mit Umfrageergebnissen und Empfehlungen zum SOA-Einsatz. Der zweite Beitrag stellt umfassend das SOA-Potenzial für mehr Agilität und Effizienz heraus, bevor im dritten Beitrag Ansatzpunkte für neue SOA-Initiativen geschildert werden. Wie das dafür benötigte Budget betriebsintern verargumentiert und erworben werden kann, zeigt Beitrag vier. SOA-Governance und SOA-Security sind Aspekte, die für den Erfolg von SOA-Projekten von zentraler Bedeutung sind. Sie werden in den Beiträgen 5 und 6 aufgegriffen. Mit Beitrag 7 folgt ein Praxiseinblick, der zeigt, dass SOA auch heute schon überbetriebliche Prozesse in Unternehmensnetzwerken optimieren kann. Der achte und letzte Beitrag gibt schließlich einen Ausblick auf aktuelle und künftige Entwicklungen, die durch den Einsatz serviceorientierter IKT realisiert werden.

www.hessen-it.de

SOA-Check 2010: Status quo – Trends – Perspektiven

Dr. Julian Eckert, SOA Competence Center im httc e.V. Dr. Nicolas Repp, SOA Competence Center im httc e.V. (ehem.) Dr. Wolfgang Martin, Wolfgang Martin Team

1.1 SOA-Grundlagen Unter dem Begriff der „serviceorientierten Architektur“ (SOA) versteht man ein Architekturparadigma, welches auf Services als Grundbausteinen basiert. Unter einem Service (Dienst) wird hierbei eine abgeschlossene, unabhängige funktionale Einheit verstanden, die eine klar definierte Geschäftsfunktionalität anbietet. Ein Service kann vollständig manuell erbracht werden, aber auch als funktionale Einheit automatisiert in Form von Software realisiert werden. Im weiteren Verlauf beschränken wir uns auf die Anwendung einer SOA bei komplexen Softwaresystemen. Anders als klassische Softwarearchitekturen, die eine komplette Systemstruktur beschreiben, beschränkt sich eine SOA auf den Bereich der Bereitstellung fachlicher Dienste und Funktionalitäten in Form von Services – vornehmlich zum Zwecke der Anwendungsintegration und der Einbindung von externen Services. Charakterisiert wird eine SOA typischerweise durch drei Rollen:

1. Service-Anbieter Als Service-Anbieter bezeichnet man in diesem Zusammenhang das Unternehmen oder die Organisationseinheit, welche(s) einen oder mehrere Services bereitstellt. Services können sowohl innerhalb eines Unternehmens oder auch über Unternehmensgrenzen hinweg angeboten werden.

SOA-Check 2010: Status quo – Trends – Perspektiven

2. Service-Nutzer Der Nutzer der Services wird Service-Nutzer genannt.

3. Intermediär Optional ist die Rolle des Intermediärs, welcher auch als „Service-Broker“ bezeichnet wird. Ein Intermediär bietet Services verschiedener Anbieter an und kann darüber hinaus zusätzliche Funktionen, wie beispielsweise die Abrechnung der Service-Nutzung, übernehmen. Die Kommunikation zwischen den beteiligten Akteuren (Anbieter, Nutzer und Intermediär) basiert auf dem Austausch von Nachrichten. Der Anbieter stellt die Implementierung eines Dienstes zur Verfügung und veröffentlicht dessen Beschreibung (z. B. Funktion, Leistungsmerkmale) sowie eine Schnittstellenbeschreibung in einem Verzeichnis, das von Kunden durchsucht werden kann. Aufgrund der Beschreibungen ist der Kunde in der Lage, einen passenden Service auszusuchen, aufzurufen und zu nutzen. Anbieter und Nutzer können auch miteinander in Kontakt treten. Zur technischen Realisierung von Softwaresystemen auf Basis des SOAParadigmas haben Web Services an Bedeutung gewonnen. Unter einem Web Service versteht man hier lose gekoppelte, wieder verwendbare Softwarekomponenten, die unter Verwendung von Internetstandards aufgerufen werden können und über den Austausch von XML-basierten Nachrichten miteinander kommunizieren. Kernidee des Service-Prinzips ist die lose Kopplung von Services an die sie nutzenden Applikationen. Die Kopplung im Sinne des SoftwareEngineering ist ein Maß für die Abhängigkeiten der beteiligten Komponenten. Das Prinzip der losen Kopplung meint, dass der Abhängigkeitsgrad der beteiligten Komponenten relativ gering ist.

www.hessen-it.de

1.2 SOA-Vorteile Die lose Kopplung der Komponenten erzeugt den Vorteil, dass Services sehr leicht durch andere Services zur Laufzeit ersetzt werden können, was die Flexibilität und Agilität der Anwendungen verbessert. Unterstützt wird dieser Aspekt durch die Ortstransparenz von Services: Verzeichnisdienste machen den Speicherort transparent. So können Services unabhängig von ihrem tatsächlichen Ausführungsort dynamisch gefunden und genutzt werden. Gewissermaßen wird er damit virtualisiert. Was die so genannte Virtualisierung für die Hardware bedeutet, ist SOA für die Software. Ein weiterer Vorteil der serviceorientierten Architektur besteht darin, dass durch das Beziehen einzelner Prozessbausteine von externen Anbietern eine Kostenreduktion erreicht werden kann, während die Steuerung des Prozesses im Unternehmen verbleibt. Eine SOA ermöglicht ein Höchstmaß an Flexibilität und stellt gleichzeitig sicher, dass die Abhängigkeit von externen Service-Anbietern auf ein Minimum begrenzt wird. Sie ist weitaus flexibler als traditionelles Business Process Outsourcing (BPO), das auf die Auslagerung eines vollständigen Geschäftsprozesses an externe Dienstleister abzielt. Denn eine SOA ermöglicht ein servicebasiertes BPO, d. h. Services können dynamisch zur Laufzeit auch von externen Providern bezogen werden. SOA passt bestens zu SaaS (Software-as-a-Service). SOA ist die Architektur, SaaS ein Liefermodell für externe und interne Services. Während mit dem traditionellen BPO nur strategische Entscheidungen mit Langzeitwirkung möglich waren, können mit dem SOA-Paradigma auch operative Outsourcing-Entscheidungen getroffen werden, die nur von kurzer Dauer sind.

SOA-Check 2010: Status quo – Trends – Perspektiven

1.3 SOA-Marktbefragung Für den SOA Check 2010 wurden 64 Personen in Unternehmen aus Deutschland, der Schweiz und Österreich befragt, die sich mit dem Thema SOA in den jeweiligen Unternehmen beschäftigen. Die Zielsetzung der Befragung war, die Entwicklung von SOA im Markt gegenüber den Vorjahren zu dokumentieren. Ferner sollte bei Unternehmen, die eine SOA-Einführung planen, herausgefunden werden, was deren Ziele und Erwartungen sind, wie deren Planung für die SOA-Einführung aussieht und welche Änderungen sich gegenüber den Vorjahren ergeben haben. Die Zusammensetzung der Stichprobe der Befragung entspricht derjenigen der beiden Vorjahre, womit eine Vergleichbarkeit hergestellt wurde. 36 % der Befragten kommen aus Unternehmen mit bis zu 100 Millionen Euro Umsatz, 28 % der Befragten aus Unternehmen mit 100 Millionen bis 1 Milliarde Euro Umsatz und 36 % aus Unternehmen mit mehr als einer Milliarde Euro Umsatz. Aufgeschlüsselt nach der Anzahl der Mitarbeiter stammen 19 % der Befragten aus Unternehmen mit weniger als 100 Mitarbeitern, 23 % aus Unternehmen mit 100 bis 1000 Mitarbeitern und 58 % aus Unternehmen mit mehr als 1000 Mitarbeitern. Das Profil der Befragung unterstreicht wie in 2009, 2008 und 2007 die Vermutung, dass das Thema SOA zunächst einmal die großen Unternehmen angeht. Der Anteil der Befragten aus mittelständischen Unternehmen in 2010 zeigt aber wie bereits in den beiden Vorjahren, dass SOA auch im Mittelstand ein Thema ist.

www.hessen-it.de

Die Befragung erfolgte sowohl online unter www.soa-check.eu als auch per Fragebogen, wobei die Befragung anonymisiert durchgeführt wurde. Um eine hohe Datenqualität zu gewährleisten, wurden fehlerhafte oder nicht vollständig ausgefüllte Fragebögen nicht in die Auswertung einbezogen. Aufgrund der relativ kleinen Stichprobe erhebt diese Marktbefragung keineswegs den Anspruch repräsentativ zu sein. Die Ergebnisse sind als ein Trend zu interpretieren, können aber als Anhaltspunkte für eigene Entscheidungen und Planungen in Sachen SOA genutzt werden.

Öffentliche Verwaltung 3 % Handel 3%

Öffentliche Verwaltung und Gesundheitswesen

Sonstige 3%

Industrie 16 %

Finanzdienstleister 23%

Automobilbau, Maschinenbau, Chemie, Öl, Gas, Pharma

Banken & Finanzen

Umsatz 36% < 100 Mio. € 28% = 100–1.000 Mio. € 36% > 1.000 Mio. €

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

Mitarbeiter 19% < 100 23% = 100–1.000 58% > 1.000

SOA-Check 2010: Status quo – Trends – Perspektiven

1.4 Ergebnisse SOA-Marktentwicklung Im Folgenden werden das Marktverständnis, die Marktreife und die Marktmotivation einer SOA erläutert. Das Verständnis einer serviceorientierten Architektur ähnelt demjenigen der Vorjahre. 69 % (67 % in 2009, 66 % in 2008) der Befragten verstehen eine SOA als Unternehmens- oder IT-Architektur, während 28 % (31 % in 2009 und 28 % in 2008) SOA ausschließlich als Technologie oder Produkte ansehen. SOA wird von insgesamt 71 % als reines IT-Thema betrachtet (74 % in 2009). Die Bedeutung von SOA innerhalb eines Unternehmens ist für 61 % (53 % in 2009 und 52 % in 2008) der Befragten sehr groß oder mindestens von großer Bedeutung. 26 % (33 % in 2009 und 34 % in 2008) sehen eine mittlere Bedeutung des Themas für ihr Unternehmen. Die zunehmende Marktreife wird durch die Antworten auf die Frage bestätigt, wie lange sich ein Unternehmen bereits mit dem Thema SOA beschäftigt. 48 % (38 % in 2009 und 33 % in 2008) der Befragten geben an, dass sie sich seit über zwei Jahren mit dem Thema SOA befassen. Dabei haben unabhängig von der Unternehmensgröße 52 % aller befragten Unternehmen mehr als 4 Mitarbeiter, die sich mit dem Thema SOA beschäftigen. In 2009 waren das nur 42 %. Entsprechend hat die Anzahl kleinerer Teams mit bis zu einer Person von 25 % in 2009 auf jetzt 18 % abgenommen. Warum beschäftigen sich Unternehmen überhaupt mit dem Thema, was sind die Treiber, die strategischen Ziele? Schwerpunkte der Motivation von Unternehmen bilden die angestrebte höhere Flexibilität mit 29 %, die Optimierung der Prozesse mit 21 %, eine Verkürzung der Time-to-Market mit 16 %, die Steigerung des Innovationsgrades mit 10 %, die Steigerung der Kundenzufriedenheit mit 5 %, die Senkung der Kosten mit 5 % sowie die Steigerung der Produktivität mit 2 %. Der Einsatz von SOA in Unternehmen ist gegenüber dem Vorjahr gestiegen. 63 % (47 % in 2009) setzen eine SOA schon ein, 31 % (37 % in 2009) sind in der Planung und nur noch 6 % (16 % in 2009) bleibt ohne SOA-Einsatzplanung.

www.hessen-it.de

70 60 50

62% 52%

53%

2008

2009

40 30 20 10 0

2010

SOA-Check 2010: Status quo – Trends – Perspektiven

SOA-Einsatz In diesem Abschnitt werden Möglichkeiten und Bedingungen für den Einsatz einer SOA im Unternehmen analysiert. Hierzu wurden nur Teilnehmer befragt, die eine SOA bereits einsetzen oder ihren Einsatz planen. Die Frage nach den Unternehmensbereichen mit der höchsten Bedeutung für SOA bestätigt die Ergebnisse des Vorjahres. Mit 25 % (21 und 19 % in den Vorjahren) wird die IT als Hauptbereich für den SOA-Einsatz identifiziert. Das unterstreicht die IT-Lastigkeit in der Wahrnehmung des Themas SOA. Das Thema Produktion folgt hiernach mit 11 % (7 % in 2009, 6 % in den Vorjahren), und löst die zweiten Plätze des Vorjahres Vertrieb (10 %), Kundenservice (7 %) und Einkauf (7 %) ab. Der Einsatz von SOA in unternehmensübergreifenden Prozessen ist besonders im Bereich der Kollaboration beim Ein- und Verkauf ausgeprägt. Die Kollaboration mit Kunden wird mit 36 % (nach 29 % in 2009, 30 % in 2008 und 32 % in 2007) bewertet, diejenige mit Lieferanten mit 23 % (nach 23 % in 2009, 24 % in 2008 und 26 % in 2007), die Kollaboration mit der Öffentlichkeit mit 13 % (nach 13 % in 2009 und 2008 sowie 11 % in 2007) und mit sonstigen Händlern mit 10 % (nach 14 % in 2009, 11 % in 2008 und 19 % in 2007).

www.hessen-it.de

Auch im SOA Check 2010 zeigt sich der Trend , SOA stark IT-lastig zu beschreiben. Mit rund 25 % (21 % in 2009 und 19 % in den Vorjahren) wird die IT als Hauptbereich für den SOA-Einsatz identifiziert, gefolgt von den Bereichen Produktion, Vertrieb und Logistik.

nein, aber Einsatz geplant

nein, kein Einsatz geplant

100 % 90 % 80 %

16 %

27 %

6% 31 %

70 % 60 % 50 %

16 %

48 %

37 %

42 %

40 %

63 %

30 % 20 %

31 %

36 %

47 %

10 % 0% 2007

2008

2009

2010

SOA-Check 2010: Status quo – Trends – Perspektiven

SOA-Governance Der Governance, d. h. der Kontrolle und Steuerung, servicebasierter Systeme kommt in der Praxis eine immer größere Bedeutung zu. Die Fragen wurden nur von Teilnehmern der Studie beantwortet, die bereits eine SOA einsetzen oder ihren Einsatz planen. Im Vergleich zu den Ergebnissen des Vorjahres sind die aktuellen Ergebnisse positiv zu bewerten. 37 % (nach nur 28 % in 2009 und 20 % in 2008) beschäftigen sich mit dem Thema SOA-Governance bzw. nutzen diese bereits. Nur noch 41 % (nach 66 % in 2009 und 55 % in 2008) geben an, dass eine SOA-Governance in Planung sei. 22 % sagen allerdings (nach 6 % in 2009 und 24 % in 2008), dass eine SOA-Governance nicht geplant ist. Bei der eingesetzten Methodologie zur SOA-Governance führen die „eigenen SOA-GovernanceMethoden“ mit 26 % vor ITIL (IT Infrastructure Library) mit 21 % und vor „allgemeinen modifizierten IT-Governance-Methoden“ mit 12 %. COBIT (Control Objectives for Information and Related Technology) kam nur auf 5 %. Der Einsatz von Service Level Agreements (SLAs) zur vertraglichen Definition von Anforderungen an Services wird nur von 21 % der Befragten nicht eingesetzt (nach 20 % in 2009). Ebenfalls erfreulich ist die Aussage, dass bereits 48 % der Befragten den Wiederverwendungsgrad von Services messen. 35 % der Befragten haben bereits eine Referenzarchitektur im Sinne einer globalen Architekturrichtlinie erstellt.

www.hessen-it.de

SOA-Projekte Auch die Fragen zu bestehenden SOA-Projekten und ihrer Projektstruktur wurden nur von Teilnehmern beantwortet, die bereits eine SOA einsetzen oder ihren Einsatz planen. Die durchschnittliche Zielerreichung der im SOA-Projekt definierten Ziele liegt in der aktuellen Befragung bei rund 76 %. Das ist an sich kein gutes Ergebnis – im Vergleich zu den Vorjahren ist aber eine positive Entwicklung feststellbar. 14 % der befragten Unternehmen haben bereits über 10 SOA-basierte Prozesse im Einsatz und 24 % bereits mehr als 40 Services. Der hauptverantwortliche Projektleiter stammt bei 48 % der Befragten immer noch aus dem IT-Bereich (2009: 54 %). Der IT-Bereich bleibt der Treiber und Macher in Sachen SOA. Deutlich zugelegt haben die internen Fachanwender / Berater, die, nach nur 14 % in 2009, bei 26 % der Befragten die Projektleitung innehatten. Das spricht für einen reifenden Markt. Enttäuschend ist aber der Einfluss auf Seiten der Organisation, denn Prozess- und Service-Denken erfordern auch neue Rollen und neue Verantwortlichkeiten, sowohl in den IT- als auch in den Fachabteilungen. In 46 % der Fälle hat die SOA-Initiative innerhalb der IT-Abteilung keine neuen Arbeitsbereiche hervorgebracht. Ähnlich unverändert zeigen sich die Fachabteilungen: in 54 % der Fälle sind hier keine zusätzlichen Rollen und Verantwortlichkeiten entstanden.

SOA-Check 2010: Status quo – Trends – Perspektiven

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 %.

30%

Chief Information Officer (CIO) Geschäftsführung Verantwortlichkeit ist nicht klar geregelt Chief Process Officer (CPO) Chief Technology Officer (CTO)

26%

Fachabteilung

www.hessen-it.de

1.5 Fazit Der SOA Check 2010 unterstreicht deutlich: Das Thema „serviceorientierte Architekturen“ kommt im deutschsprachigen Markt gut an und gut voran. Die Unternehmen haben in den letzten Jahren erhebliche Fortschritte gemacht. Der Einsatz von SOA in den befragten Unternehmen ist gegenüber 2009 gestiegen. 63 % (47 % in 2009) setzen eine SOA schon ein, 31 % (37 % in 2009) sind in der Planung und nur ein Rest von 6 % bleibt ohne SOA-Einsatzplanung. Das Thema SOA bleibt bei den meisten Unternehmen also gesetzt und man schreitet in der Umsetzung weiter fort. 9 % der befragten Unternehmen gaben an, dass sie sich bereits in der Endphase der Umsetzung einer SOA befinden und 52 % sehen sich mitten auf dem Weg. 48 % beschäftigen sich seit über zwei Jahren mit SOA. 14 % der Unternehmen, die SOA betreiben, haben bereits mehr als 10 SOA-basierte Prozesse und über 24 % dieser Unternehmen haben sogar schon mehr als 40 Services im Einsatz. Die Einschätzung der Bedeutung einer SOA ist im deutschsprachigen Raum nicht mehr vom Hype gekennzeichnet. Sie ist nun realistisch, bleibt aber immer noch zu IT-lastig. Durch diese IT-geprägte Sicht wird leider der Blick auf weitergehende SOA-Potentiale für Themen wie beispielsweise Compliance und Risiko-Management verstellt (siehe hierzu auch Kapitel 4.4, S. 47ff., in dem erläutert wird, dass der volle Nutzen von SOA erst in einer IT-übergreifenden Betrachtung deutlich wird). Der Nutzen einer SOA wird in 2010 ähnlich bewertet wie in den beiden Vorjahren: höhere Flexibilität (29 %), Optimierung der Prozesse (21 %), Time-to-Market (16 %), Steigerung des Innovationsgrades (10 %), Steigerung der Kundenzufriedenheit (5 %) und Senkung der Kosten (5 %) spielen die wichtigsten Rollen. Betrachtet man die Anwendungen, wird schnell klar, dass der Top-Down-Ansatz (SOA-basierte Geschäftsprozesse) weiter auf dem Vormarsch ist. BPM ist der Business Case für SOA, SOA ist „nur“ die Infrastruktur dazu.

SOA-Check 2010: Status quo – Trends – Perspektiven

SOA-Governance ist als Thema angekommen und wird nun endlich angegangen. Hier gab es einen deutlichen Fortschritt gegenüber den beiden Vorjahren: 37 % der Befragten gaben an bereits eine SOA-Governance umgesetzt zu haben (gegenüber 28 % und 20 %). Auch die Bedeutung von Service Level Agreements wird zunehmend besser verstanden: Nur noch 21 % der Befragten verwenden keine SLAs. Der Methoden- und Werkzeugeinsatz kommt auch voran, aber das Schaffen neuer Rollen und Arbeitsbereiche setzt erst sehr zögerlich in den IT- und Fachbereichen ein. Die Zielerreichung bei SOA-Projekten hat zugenommen. Durchschnittlich werden 76 % der Ziele erreicht. Der Treiber für SOA ist immer noch die IT-Abteilung. In 48 % der Fälle kommt der Projektleiter aus dem IT-Bereich, in 44 % der Fälle wird die Implementierung ausschließlich durch die interne IT-Abteilung gemacht. Auch wenn diese Anteile noch verhältnismäßig hoch erscheinen, ist der Trend hin zu einer geringeren IT-Bedeutung des Themas SOA über die letzten Jahre erkennbar. Das Einbeziehen der Fachabteilungen in die SOA-Projekte ist bei weitem nicht ausreichend: 20 % der SOA-Projekte sind reine IT-Projekte. Hier liegt ein großes Verbesserungspotential, das man im Zuge des Fokus auf SOA-Governance angehen kann.

Der SOA Check 2010 zeigt, dass sich der in 2009 analysierte Trend auch in 2010 fortsetzt. Das Thema SOA ist bei den Unternehmen gesetzt und wurde mittlerweile in den Standard-Lösungskatalog der Unternehmen übernommen. Den „Hype“ der Vorjahre konnte das SOA-Paradigma ablegen – aus SOA ist ein reifes Architekturparadigma geworden, welches in einer Vielzahl von Anwendungen zum Tragen kommt.

www.hessen-it.de

SOA@Work: Mehr Agilität und Effizienz

Norbert Eder, Software AG Das Internet ist ein prägender Faktor unserer Zeit. Die Welt entwickelt sich zur Netzgesellschaft und erhöht als Webciety unseren Lebensstandard. Die Informations- und Kommunikationstechnologie (IKT)-Branche hat mittlerweile einen Anteil am deutschen Bruttoinlandsprodukt von rund 6 Prozent und bietet 750 000 Arbeitsplätze. Dazu kommen die Wertschöpfung und die Arbeitsplätze in den Anwenderbranchen: z.B. in Banken und Versicherungen, in der öffentlichen Hand und der Industrie. Die Digitalisierung der Wirtschaft hat viele Prozesse dramatisch schneller, billiger und effizienter gemacht und unzählige neue Produkte und Dienstleistungen geschaffen. Hinter diesen digitalen Transaktionen und der digital erhöhten Produktivität steckt Technologie. Erst durch Technologie wird die digitale Gesellschaft überhaupt möglich. In der Informationstechnologie (IT) stehen wir vor einem Paradigmenwandel, wie er nur einmal in zehn Jahren stattfindet: von den Anwendungs-Silos hin zur Kollaboration und Flexibilität von IT-Systemen. Diese innovativen Technologien sind der Motor für die Weiterentwicklung des

Webs und der Wertetreiber der Webciety.

SOA@Work: Mehr Agilität und Effizienz

2.1 Agile Unternehmen sind die Ziele Im 21. Jahrhundert agieren Unternehmen in einem rauen Geschäftsklima. Sie müssen sich dem Druck durch scharfen Wettbewerb, zunehmende Globalisierung und Konsolidierung stellen und auf neue Beziehungsmuster reagieren, wie etwa Co-opetition, also in einer Firma gleichzeitig einen Partner und Konkurrenten zu haben. Um diese Herausforderungen meistern zu können, ist ein Umdenken nötig. Eine hohe Innovations- und Reaktionsfähigkeit zur langfristigen Generierung von Erträgen ist das Gebot der Stunde. Dafür ist agiles, flexibles Handeln gefragt. Diese Anforderungen an das Unternehmen sind in den Geschäftsprozessen abgebildet, und die werden nun hinterfragt, neu gestaltet oder optimiert. Technologien sollen diese Anstrengungen unterstützen. Geschäftsabläufe, ganz gleich, ob innerhalb eines Unternehmens oder über Betriebsgrenzen hinweg, müssen transparent, messbar und nachvollziehbar werden. Dies ist die Voraussetzung für ein agiles, flexibles Unternehmen. Eine serviceorientierte Architektur bildet eine ideale Grundlage für die durchgängige Prozessgestaltung und ein umfassendes Prozessmanagement. In diesem Umfeld vertrauen Unternehmen heute zunehmend auf das so genannte Business Process Management (BPM). Eine Studie der Software AG hat herausgefunden, dass jedes fünfte deutsche Unternehmen der IT-gestützten Verwaltung von Geschäftsprozessen eine hohe Priorität einräumt. Das Managementkonzept BPM etabliert eine prozesszentrische Sichtweise auf das Geschäft und stellt das Messen der Leistung in den Mittelpunkt. Es umfasst zudem Methoden, Werkzeuge und Technologien, die verwendet werden, um Betriebsabläufe zu entwerfen, auszuführen, zu analysieren und zu kontrollieren. Technologien für Prozessmanagement (BPM-Systeme) müssen auch die Änderung und Optimierung der Geschäftsabläufe unterstützen, denn Wettbewerbsvorteile entstehen nur dann, wenn die Prozesse auch fortlaufend an neue Anforderungen angepasst werden. Dabei hat sich gezeigt, dass schnelle Änderungen nur schwer möglich sind, solange die Prozesse in herkömmliche IT-Anwendungen eingebettet sind.

www.hessen-it.de

2.2 Flexible Prozesse sind die Lösung Die Lösung für solche Probleme besteht in einer gesteigerten Flexibilität: Systeme zur Prozessautomatisierung auf der Basis einer serviceorientierten Architektur (SOA) bieten einen Ausweg, indem sie die Prozessschicht von den darunter liegenden Anwendungen und der Infrastruktur trennen, so dass die Geschäftsanwender ihre Prozesse kontrollieren und direkt ändern können. Statt fest codierter, starrer Prozessabläufe setzen diese Systeme auf das Prinzip der Komposition von IT-Fähigkeiten und Informationen, auch als „Services“ oder „Dienste“ bekannt, um die benötigte Flexibilität zu erreichen. Die Verantwortlichen in den Unternehmen erkennen zunehmend die Vorteile einer SOA. Denn 60 Prozent der befragten Firmen verwenden bereits eine serviceorientierte Architektur als Grundlage für BPM, wie die Umfrage der Software AG ergab. Serviceorientierte Architekturen gelten als das herausragende Gestaltungsprinzip zeitgemäßer Softwarelandschaften. Sie bieten eine bessere Integration auf der Basis von Standards mit verteilten, lose gekoppelten und nach Bedarf mehrfach verwendbaren Komponenten, welche über Services miteinander interagieren. SOA und BPM bilden komplementäre Aspekte, die für eine flexible Unternehmens-IT notwendig sind. Während eine SOA die technologische Grundlage für das BPM und die Governance bildet (siehe 2.4), liefert BPM als Geschäftsprozessmanagement den fachlichen Rahmen für die Umsetzung der Services – abteilungsübergreifend und über Wertschöpfungsketten hinweg. Auch die Geschäftsprozessregeln lassen sich in einer SOAUmgebung als technische Services bzw. Web Services bereitstellen und somit an verschiedenen Stellen im Prozessablauf wiederverwenden. Im Rahmen von BPM stellt die Fachabteilung Komponenten zu einer Ablaufkette zusammen, die dann in der SOA technisch über den Enterprise Service Bus abgebildet wird.

SOA@Work: Mehr Agilität und Effizienz

2.3 BPM und SOA aufeinander abstimmen Obwohl sich SOA und BPM ergänzen, müssen die Managementaufgaben und -prinzipien des BPM mit den technischen Prinzipien der SOA abgestimmt werden. Dazu gehören die Konzeption einer Architektur in Form von strategischen Zielen und entsprechenden Prozessen, die Modellierung dieser Prozesse als IT-Komponenten und das Aufsetzen einer Governance inklusive der Definition von Rollen und Verantwortlichkeiten. Die erste erfolgskritische Aufgabe besteht darin, die für die definierten Geschäftsziele richtigen Prozesse festzulegen. In einer SOA sind sie der Ausgangspunkt dafür, Services wiederverwendbar zu machen. Praktiker wissen: Gerade die Phase des Identifizierens und Modellierens von Prozessen, die automatisiert und ins Geschäftsprozess-Management einbezogen werden sollen, ist schwierig, weil sie eine enge Zusammenarbeit zwischen den Fachanwendern, Geschäftsanalysten und der IT-Abteilung erfordert. Für diese Kollaboration muss eine einheitliche IT-unterstützte Plattform vorhanden sein, auf der alle Beteiligten miteinander am Design oder Re-Design von Geschäftsprozessen arbeiten können. Prozessexperten, Geschäftsanalysten und IT-Entwickler sind dann in der Lage, sich wie in einem virtuellen Meeting über die Prozesse zu einigen, anstatt wie früher das Design auf dem Papier zu dokumentieren und der IT-Abteilung zur Umsetzung zu übergeben. Der Vorteil einer digitalen Plattform besteht darin, dass die Beteiligten den Prozess gleichzeitig aus ihrer jeweiligen Perspektive sehen können, also z. B. der Analyst aus der Geschäftsperspektive und der IT-Fachmann aus der IT-Perspektive. Die Geschäftsanalysten können in einer solchen, digitalen Umgebung die Prozesse grafisch modellieren, und die Tools erzeugen daraus Prozessbeschreibungen in Standard-Prozessmodellierungskonventionen und Notationen.

www.hessen-it.de

Mit einer integrierten Entwicklungsplattform in einer serviceorientierten Umgebung werden die Prozessschritte dann in technische Services (Web Services) umgewandelt und neue Services zusammengebaut (komponiert). Für die Ausführung dieses Prozesses ist eine so genannte BPMEngine zuständig. In einer herkömmlichen Architektur werden die Engines lediglich statische Versionen eines Prozesses ausführen können und damit der geforderten Flexibilität und Agilität eines Geschäfts entgegenwirken, indem sie dem Unternehmen vorschreiben, wie der Prozess abzulaufen hat. In einer SOA sind die vorhandenen Daten und die Funktionalität in Services vorhanden. Diese fügen Unternehmensfachleute zu so genannten Composite Applications zusammen. Das sind agile Geschäftsprozesse, die auf der Grundlage von definierten Geschäftsprozessen konfiguriert sind. Die Dienste werden öffentlich gemacht und können dynamisch zu anderen Prozessen mit anderer Logik zusammengesetzt werden. Auf diese Weise liefert dieser neue Typus einer serviceorientierten Geschäftsanwendung (Service Oriented Business Application – SOBA) einen prozessgetriebenen Ansatz für das Zusammenstellen eines logischen Informationsflusses aus heterogenen Datenquellen und ist

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

SOA@Work: Mehr Agilität und Effizienz

2.4 Effizienz durch Governance Schließlich muss es eine Instanz – die Governance – geben, die die Komponenten der serviceorientierten Architektur wie Services, Prozesse und Regeln, sowie organisatorische Aspekte begleitet. Eine effiziente Governance definiert aufbau- und ablauforganisatorische sowie technische Regeln für den gesamten Lebenszyklus einer solchen Landschaft. Zu den organisatorischen Aspekten gehört beispielsweise das Festlegen der fachlichen und technischen Verantwortung für einen Service (Ownership). Ferner werden Rollen definiert, die festlegen, wer für bestimmte Bereiche verantwortlich ist. Governance lässt sich durch den Einsatz einer Registry in enger Kombination mit einem Repository für den gesamten Lebenszyklus der Services umsetzen. Die Registry liefert gleichermaßen eine Kategorisierung und eine Organisation der Services. Nutzer können neue Services im Katalog publizieren und nach vorhandenen suchen. Die Komponenten können mehrfach kategorisiert werden, um Services einer bestimmten Service-Domäne, einer fachlichen Funktion oder einem Prozess zuzuordnen. So entsteht eine vollständige Dokumentation der Architektur. Das Repository reichert die Informationen in der Registry um Metadaten an, also um beschreibende Daten etwa zu Schnittstellen oder Anforderungen an die Komponenten. Das Governance-Repository umfasst ein Informationsmodell oder eine Taxonomie und zusätzlich Audit-Fähigkeiten für das Verfolgen von Änderungen an den Services, Identity-ManagementFunktionen und eine rollenbasierte Zugriffskontrolle. Es sollte der gesamte Lebenszyklus einer Komponente als Workflow mit allen Arbeitsschritten und den beteiligten Rollen darin abgebildet werden (Lifecycle Management). Um eine Synchronisation von Repository und Registry sicherzustellen, empfiehlt es sich, die beiden in einem einheitlichen, auf Standards beruhenden Informationsmodell mit einem zugehörigen Datenspeicher zusammen zu führen. Damit sind Governance-bezogene Metadaten und das Informationsmodell konsistent in einem Speicher vereint, und die Anwender erhalten ein einziges System für die Verwaltung aller Informationen bezüglich der SOA-Komponenten und der Governance-Metadaten.

www.hessen-it.de

2.5 Fazit Die IT-Landschaft vieler Unternehmen basiert heute häufig noch auf ITSilos. Gefragt und gewünscht sind jedoch effiziente Prozesse, die unternehmensübergreifend wirksam werden und sowohl Zulieferer als auch Geschäftspartner einbinden. Unternehmen erkennen immer mehr:

Erstklassige Prozesse sind genau so wichtig wie erstklassige Produkte, und innovative Prozesse sind die Grundlage für erstklassige Geschäftserfolge.

Genau darum geht es beim Business Process Management und bei serviceorientierten Architekturen. BPM und SOA sind keine rein technische Aufgabe, die durch neue Produkte oder Dienstleistungen gelöst werden können. Das Management von Geschäftsprozessen und serviceorientierten Architekturen ist von Natur aus eine soziale Aktivität. Ein erfolgreicher Prozess sollte jeden Beteiligten berücksichtigen. Idealerweise kollaborieren alle Ebenen gleichberechtigt, vom Angestellten bis zum Vorstand, um einem Projekt und den damit verbundenen Geschäftsprozessen den optimalen Mix aus Wissen, Erfahrung und persönlichem Einsatz in kürzester Zeit und zu den geringst möglichen Kosten zuteil werden zu lassen. Bisherige Lösungen konzentrierten sich vielfach auf die Installation verschiedener, nur wenig kompatibler Tools durch IT-Abteilungen auf den Desktops der Beteiligten. Das Ergebnis führte jedoch kaum zu den gewünschten Erfolgen einer echten, unternehmensübergreifend arbeitenden sozialen Gemeinschaft, deren Teilnehmer gleichermaßen Interesse am Projekterfolg haben. Die optimierte interne und externe Kollaboration von Experten und die damit entstehenden „fließenden“ Teams, die über Unternehmensgrenzen hinweg gemeinsam ohne Reibungsverluste an BPM- und SOA-Projekten arbeiten, werden in Zukunft darüber entscheiden, ob und inwieweit Prozesse verbessert werden können.

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

Markus Ganß, Opitz Consulting Bad Homburg GmbH

3.1 Einsatzbereiche Als IT-Architektur und Managementkonzept bedeutet eine SOA in vielen Einsatzbereichen die richtige Wahl. Grundsätzlich sprechen nicht die Unternehmensform oder -größe für oder gegen den Einsatz einer SOA, sondern allein die Herausforderungen eines Unternehmens und die daraus abgeleiteten Anforderungen. Bei folgenden Aufgaben und Lösungsansätzen sollte der Einsatz einer serviceorientierten Architektur geprüft und bewertet werden: a Integrationsszenarien Ein typisches Ziel von Integrationsszenarien ist es, Daten über Unternehmensanwendungen hinweg möglichst in Echtzeit zu synchronisieren und konsistente Zustände zu bewahren. Im Rahmen einer SOA kann mit einem Enterprise Service Bus (ESB) die Kommunikation zwischen Systemen koordiniert werden. So wird die Konsistenz und Genauigkeit von Daten auch über Systemgrenzen hinweg sichergestellt. a Entwicklung individueller Anwendungen Bei der Entwicklung von individuellen Anwendungen sollte von Beginn an darauf geachtet werden, die enthaltenen Geschäftsfunktionen der Anwendung im Rahmen von Services bereitzustellen, um durch die lose Kopplung von Modulen die Wartbarkeit und Wiederverwendbarkeit der Anwendung und ihrer Module zu erhöhen. Dabei muss die zusätzliche Investition bei der Erstellung der Anwendung natürlich über eine ROI-Berechnung gerechtfertigt sein.

www.hessen-it.de

a Prozessautomatisierung Durch die Automatisierung von Geschäftsprozessen unter Einbeziehung von Anwendungen, Systemen und Personen lässt sich die Prozessproduktivität verbessern. Die Transparenz der Unternehmensprozesse wird gesteigert und die Agilität der Prozesse wird erhöht. a Prozessportale Durch Prozessportale können manuelle und automatisierte Geschäftsprozesse über Anwendungen hinweg angestoßen, betrieben und verfolgt werden. Auch hierdurch wird die Produktivität und Transparenz der Prozesse erhöht. a Business Activity Monitoring Das Business Activity Monitoring sammelt zur Laufzeit der Prozesse die Prozessdaten und berechnet in Echtzeit die Key Performance Indikatoren (KPI). Auf dieser Basis können dann Prozessoptimierungen durchgeführt werden. Die Daten werden integriert in so genannten Dashboards dargestellt und dienen zur verbesserten und zeitnahen Entscheidungsfindung. a Business-to-Business Integration Die Einführung einer SOA sollte auf jeden Fall auch bei der Anforderung einer Business-to-Business Integration geprüft werden. Ziel dieser Integration ist es, Geschäftspartner in die Geschäftsprozesse des Unternehmens zu integrieren. So können die Kosten innerhalb der Wertschöpfungskette eines Unternehmens gesenkt werden.

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

Über diese genannten Bereiche hinaus finden sich in vielen Unternehmen weitere Anforderungen und Ansatzpunkte, die mit einer SOA unterstützt werden können. Dabei bedarf es einer individuellen Analyse der Anforderungen. Weitere klassische Indikatoren für den möglichen Einsatz einer SOA sind folgende Aspekte: a Verteilte Systeme a Verteilte Verantwortung (bereichsübergreifend) a Heterogene Systemlandschaft Es gibt auch Anforderungen, die durch eine SOA nicht optimal abgedeckt werden können. Beispiele hierfür sind: a Der Austausch großer Datenmengen, z. B. über Datenbankreplikationen a Die Anbindung von Anwendungen auf lokalen Clients

3.2 Dimensionen und Ziele Im Rahmen einer serviceorientierten Architektur sind drei verschiedene Betrachtungs- und Handlungsdimensionen zu beachten:

SOA erfordert ein Organisationskonzept

SOA ist ein Technologiekonzept

SOA Strategie

SOA Architektur

Serviceentwicklung

SOA Maturity Model SOA Assessment

Enterprise Architecture, Integrierte Geschäftsprozess- und IT-Architektur

Standards, Service Orchestrierung

Systeminfrastruktur

SOA Governance Richtlinien

Laufzeitumgebung, Systemintegration

SOA Organisation Rollen und Aufgaben

SOA ist ein Architekturkonzept

SOA Methodik Service-Identifikation, -Klassifikation und -Portfoliomanagement

Systemmanagement SLA, Sicherheit, Performance

www.hessen-it.de

a Dimension Organisation SOA erfordert ein Organisationskonzept, um eine strategische Ausrichtung, einen formalen Handlungsrahmen und eine organisatorische Gestaltung bzw. Implementierung bereitzustellen. a Dimension Architektur SOA ist Teil einer Unternehmensarchitektur (Enterprise Architecture), in der u. a. die Geschäftsprozess- und IT-Infrastrukturen abgebildet und zueinander in Beziehung gesetzt werden. Darüber hinaus bietet eine SOA Methodikansätze zur Identifikation, Klassifikation und zum Management von Services. a Dimension Technologie SOA ist ein Technologiekonzept, das eine Systeminfrastruktur und ein Systemmanagement bereitstellt, um serviceorientierte Anwendungen implementieren und betreiben zu können.

Diese drei Dimensionsebenen machen deutlich: SOA ist mehr als nur das nächste Infrastrukturprojekt – es ist ein fachlich orientierter Managementansatz, der in der Unternehmensarchitektur und der technischen IT-Infrastruktur umgesetzt wird. Ein übergeordnetes Ziel, das jeder SOA-Ansatz verfolgt, ist die Beherrschung der heterogenen Systemlandschaften im Unternehmen. Die Realität zeigt heute vielfach Anwendungslandschaften mit proprietären Schnittstellen, vielen verschiedenen Plattformen und unübersichtlichen Interaktionen zwischen diesen Anwendungen und Systemen.

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

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

www.hessen-it.de

3.3 Komponenten Eine serviceorientierte Architektur kann im einfachsten Fall aus einzelnen Services bestehen, die lose gekoppelte Funktionalitäten zur Wiederverwendung bereitstellen. Ein Service ist eine spezielle Softwarekomponente mit einer wohl-definierten Funktionalität, die von anderen Softwarekomponenten lokal oder über ein Netzwerk mit einer zuvor fest definierten Schnittstelle genutzt werden kann. Funktionalität bezeichnet dabei die Fähigkeit einer Komponente, eine oder mehrere Aufgabe(n) zu lösen.

SCM

Check Credit Service

Webshop Client

Security

Servicebus

Serviceregistry

Service Orchestrierung

Monitoring

Um Punkt-zu-Punkt-Verbindungen zwischen einzelnen Services zu vermeiden, kann ein Enterprise Service Bus (ESB) eingesetzt werden. Der Servicebus ist eine logische Architektur, die konform zu den SOA-Prinzipien eine Integrationsinfrastruktur bereitstellt. Ein ESB bietet zum Beispiel Möglichkeiten, über Adaptoren andere Standardanwendungen (SCM, CRM, ERP) anzusprechen. Er garantiert zudem die Einhaltung von Security-Richtlinien und stellt Oberflächen für das Monitoring bereit. Somit übernimmt er das Management der Integrationsinfrastruktur.

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

Zu den typischen Aufgaben eines ESB gehören: a Transformation der verschiedenen Protokolle und Nachrichtenformate (Meditation) a Routing von Nachrichten a Bereitstellung von Adaptoren zur Anbindung verschiedener Systeme a Verbergen der eigentlichen Service Provider vor den Service Consumern (Service-Virtualisierung) a Monitoring a Security Einzelne Services können über eine Serviceorchestrierung zu höherwertigen (composite) Services kombiniert werden, um z. B. eine Geschäftsfunktion bereitzustellen. Hierfür werden BPM (Business Process Management), BPEL (Business Process Execution Language) oder klassische Workflowsysteme genutzt. Eine Service-Registry ist ein Verzeichnis von Serviceinformationen. Es beinhaltet alle Informationen, um einen Service zu finden und zu nutzen. Das Registry kann noch Informationen zum Servicevertrag beinhalten. Typische Inhalte einer Service-Registry sind Angaben in folgenden Bereichen: a Servicevertrag a Serviceschnittstelle a Sicherheit (verwendetes Sicherheitssystem, Rechte etc.) a Leistungsmerkmale (Performanz, Skalierbarkeit etc.) a Ansprechpartner a Fachliche Fragen und Änderungswünsche, welche die Geschäftslogik betreffen a Technische Fragen und Änderungswünsche, welche die Implementierung betreffen a Informationen über den Ort, an dem der Service zurzeit bereitgestellt ist (oder über einen ESB-Endpunkt)

www.hessen-it.de

3.4 Der erste Service Grad der SOA-Basierung im Unternehmen Wenn ein Unternehmen eine SOA einsetzen möchte, muss es eine SOAStrategie entwickeln. Die Einführung einer SOA erfolgt über einzelne Projekte und sollte daher im Rahmen einer Roadmap definiert werden. Die ersten SOA-Projekte enthalten meistens noch nicht alle Komponenten einer unternehmensweiten SOA (Enterprise SOA) und manche Unternehmen müssen und wollen diese Ausbaustufe auch gar nicht erreichen. Vielfach ist schon eine SOA in kleinerem Umfang (SOA lite) die richtige Wahl, weil sie adäquate Lösungen für die gestellten Aufgaben und Anforderungen liefert.

Erfüllungsgrad

SOA lite

Enterprise SOA

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

Eine SOA lite setzt bereits erste leichtgewichtige Web Services ein, bei denen eindeutige Schnittstellendefinitionen erstellt werden. Oft findet man in dieser Ausbaustufe noch keinen ESB, sondern benutzt Punkt-zuPunkt-Verbindungen zwischen einzelnen Applikationen. Das Thema SOAGovernance beschränkt sich auf die Richtlinien für die Schnittstellendefinitionen und eventuell auf Namenskonventionen. Auf dieser Ebene setzt man häufig Open Source-Werkzeuge für die technische Einführung der SOA ein. Eine Enterprise SOA bildet die strategische Plattform für die Architektur der Unternehmensanwendungen. Es werden komplexe Integrationsszenarien mit Hilfe von Middleware-Infrastrukturen und SOA-Suiten von kommerziellen Herstellern umgesetzt. Die Organisation des Unternehmens ist hier durch die SOA-Governance verändert und neue Rollen, Verantwortlichkeiten und Prozesse sind etabliert.

Das Ziel einer SOA-Einführung besteht darin, den für die individuelle Situation eines Unternehmens adäquaten Erfüllungsgrad zu finden und nicht darin, den höchstmöglichen Erfüllungsgrad zu erreichen.

Ist Ihr Unternehmen auf die Einführung einer SOA vorbereitet? Wenn ein Unternehmen eine serviceorientierte Architektur einführen möchte, sollte dies zunächst in kleinen Schritten geschehen. Ein klassischer Ansatz ist die Durchführung eines SOA-Pilotprojekts:

www.hessen-it.de

SOA Pilotprojekt

Ziel Ergebnisorientierter und pragmatischer Ansatz für die Evaluierungs- oder Startup-Phase Ihres SOA-Vorhabens Nutzen SOA in der Praxis an Hand eines klar abgegrenzten Problemfalls kennenlernen Praxiserfahrung in relevanten Methoden und geeigneten Werkzeugen sammeln Erkenntnisse für das weitere Vorgehen in Ihrem SOA-Vorhaben erarbeiten

SOA Pilotprojekt Ausarbeitung einer greifbaren Nutzenargumentation in Richtung Fachbereiche und Management: Was bringt SOA exakt für uns? SOA-Pilot als ein sinnvoller erster Schritt in Richtung Ihres Gesamtvorhabens Attraktives Kosten-Nutzen-Verhältnis durch ergebnisorientierte Umsetzung mit kurzer Laufzeit Klare Fokussierung auf Vorgehensweise und Methodik, da technische Rahmenbedingungen vorgegeben sind

SOA Starter Kit Modul 1: Auswahl eines geeigneten SOA-Piloten

Planung SOA-Pilot

Modul 2: Zieldefinition und Abgrenzung Modul 3: Ausrichtung der Strategie für SOA-Gesamtvorhaben

optional

Projekt Roadmap

Modul 4: Erstellung Projekt-Roadmap

Modul 5: Analyse und Modellierung des neuen Anwendungsfalls

optional

Modul 6: Review eines bestehenden Anwendungsfalls

Durchführung SOA-Pilot

Lauffähige Services

Modul 7: Service-Modellierung Modul 8: Service-Implementierung Modul 9: Service-Rollout

Auswertung SOA-Pilot

optional

Modul 10: Sammlung Lessons Learned Modul 11: Ausarbeitung Nutzenargumentation für SOA-Gesamtvorhaben

SOA-Nutzenargumentation

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

Eigenschaften des ersten Services und dessen Umsetzung Services, die als SOA-Pilotprojekt umgesetzt werden, sollten folgende Eigenschaften besitzen: a Hohe Sichtbarkeit a Managementunterstützung a Klar abgegrenzter Problemfall a Geringer Abstimmungsaufwand a Nicht geschäftskritisch Die hohe Sichtbarkeit erleichtert die Nutzenargumentation im Anschluss an das SOA-Pilotprojekt. Sie fördert die notwendige Managementunterstützung für das weitere SOA-Vorhaben. Der oder die Service(s) sollte(n) einen klar abgegrenzten Problemfall beschreiben, um zu Beginn einen möglichst geringen Abstimmungsaufwand zu ermöglichen. Es ist sinnvoll, anfangs einen nicht-kritischen Geschäftsfall zu implementieren, um sich hierdurch nicht einer unnötigen Drucksituationen auszusetzen. Die Ergebnisse des SOA-Pilotprojekts dienen als Entscheidungsgrundlage für das Unternehmen, ob es weiterhin eine Strategie auf Basis einer serviceorientierten Architektur verfolgen sollte. Insgesamt gilt für das Vorgehen beim Pilotprojekt:

tart small, s , ig b k in Th success k ic u q w o sh

Einbettung des SOA-Piloten in Ihr SOA-Gesamtvorhaben Sobald das SOA-Pilotprojekt abgeschlossen ist, existiert eine Entscheidungsgrundlage für das weitere Vorgehen. Wenn positiv entschieden wurde und eine Roadmap erstellt wurde, um die geplante SOA-Strategie umzusetzen, geht es an die Einbindung von SOA in weitere Projekte des Unternehmens. Ein iterativer, der Roadmap folgender Ansatz hat sich klar bewährt:

www.hessen-it.de

Gesamtvorhaben

PilotProjekt

Lessons Learned

SOAProjekt

Lessons Learned

SOAProjekt

Lessons Learned

SOA Starter Kit

Im Rahmen der weiteren SOA-Projekte baut man die SOA-Architektur mit immer weiteren Komponenten aus, überprüft und verfeinert die SOAGovernance und integriert SOA im Rahmen des Change Managements in das Unternehmen. Wichtig ist immer wieder, das Erreichte zu überprüfen, den Erfolg anhand von definierten Indikatoren zu bewerten und korrigierend einzugreifen, wenn neue Anforderungen oder Rahmenbedingungen die Roadmap zur Erreichung der geplanten serviceorientierten Architektur beeinflussen.

3.5 Fazit Moderne serviceorientierte Architekturen halten in allen Unternehmensformen und -größen Einzug. Erfolge erzielen diejenigen Projekte, die schnell einen Mehrwert für die Fachbereiche erzeugen und vom Management entsprechend unterstützt werden. Wer versucht, eine SOA durch ein einzelnes Projekt oder eine neue Technologie einzuführen, gerät meistens in eine Sackgasse. Es gibt nur wenige SOA-Initiativen, die mit diesen Ansätzen dauerhaft erfolgreich waren. Deswegen ist die Einbettung des SOA-Pilotprojekts in die Gesamtstrategie des Unternehmens entscheidend. Nur wenn dessen strategische Ziele und deren konkrete Machbarkeit durch das Pilotprojekt unterstützt werden, leistet SOA einen wichtigen Beitrag zum Unternehmenserfolg.

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

PD Dr. Ralf Helbig, Detecon International GmbH Wer seinen Chef überzeugen möchte, in eine SOA-Initiative zu investieren, sollte zuerst einige Voraussetzungen schaffen. Innerhalb der IT-Abteilung ist zunächst ein gemeinsames Verständnis von SOA zu erzeugen und Einigung zu erzielen, welchen Nutzen SOA für das Unternehmen haben kann. Hierbei ist es unerlässlich, den Nutzen aus der Geschäftsperspektive zu betrachten. Das heißt, es muss deutlich werden, welche Kosten involviert sind, ob und in welchem Ausmaß Einsparungen realisiert werden können und worin der geschäftliche Nutzen von SOA darüber hinaus besteht. Erst dann wird es wichtig, dem Management zu veranschaulichen, wie SOA funktioniert und wie man die monetären und qualitativen Vorteile von SOA der Fachseite und dem Chef vermitteln kann, so dass dieser eine Bereitschaft für Investitionen zeigt.

4.1 Die optimale SOA-Initiative Serviceorientierung benötigt einen Kunden, der Services anfragt, und einen Lieferanten, der auf einen funktionierenden Betrieb zugreifen kann. Es macht keinen Sinn, Entscheidungsträger allgemein von SOA überzeugen zu wollen, ohne dass sie den konkreten Nutzen vor Augen haben. Im ersten Schritt ist es daher wichtig zu verstehen, wer die Kunden von Services sind und welche Anforderungen sie an diese stellen. Im zweiten Schritt ist dann zu untersuchen, welche Auswirkungen eine Serviceorientierung auf den eigenen Betrieb und dessen Architektur hat.

www.hessen-it.de

Erwartungen orientiert an

Service

Kunde

Lieferant

IT-Architektur

Der Service zwischen Kunde und Lieferant

Die Abbildung zeigt zwei Elemente einer serviceorientierten Architektur. Auf der einen Seite sind Kunden, die Erwartungen an IT-Dienstleistungen haben, die mehr oder weniger konkret artikuliert werden. Auf der anderen Seite stellt sich die Frage, wie die Servicedienstleistung vom Lieferanten mit seiner IT-Fabrik erbracht werden kann. Hierbei ist es für ihn wichtig zu wissen, wie weit die momentane IT von einer serviceorientierten Architektur entfernt ist. Der Nutzen einer serviceorientierten Architektur besteht vor allem in der erhöhten Flexibilität der IT, die dann entsteht, wenn sie erst einmal umgesetzt ist. Die Migration von einer herkömmlichen Architektur zu einer SOA bzw. deren Aufbau ist aber in der Regel aufwendig, da viele Vorarbeiten und Analysen notwendig sind. Daher ist es von Vorteil, einzelne Bereiche zu identifizieren, die von den Vorteilen einer SOA maximal profitieren.

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

Eine SOA setzt eine hohe Transparenz und ein gutes Verständnis der Applikationsarchitektur voraus. Weiterhin benötigt SOA eine redundanzfreie Strukturierung der benötigten geschäftsfachlichen und technischen Fähigkeiten sowie der Informationsobjekte. Wenn diese Voraussetzungen erfüllt sind, können a Redundanzen schnell erkannt werden, a (dadurch) unnötige Komplexität reduziert werden, a IT-Kosten transparent gemacht werden a und eine Standardisierung vorangetrieben werden. So stellt eine serviceorientierte Architektur auf der einen Seite maximale Effektivität sicher, indem sie die angebotenen fachlichen und technischen Services optimal auf die Kundenerfordernisse abstimmt. Auf der anderen Seite leistet sie höchste Effizienz durch eine überlappungsfreie und redundanzfreie Definition der Services, welche die Voraussetzung für eine effiziente Produktion bildet.

Komplexität

Erwartungen

Variantenvielfalt

orientiert an

Kosten Zeit

Service

Flexibilität Qualität

Kunde

Lieferant

IT-Architektur

Kundenorientierung Standardisierung

Effektivität Enabler

Effizienz

Nutzenpotentiale einer serviceorientierten Architektur

www.hessen-it.de

Die Abbildung verdeutlicht diesen angesprochenen Zusammenhang und benennt wesentliche allgemeine Nutzenpunkte, die durch SOA erzielt werden können – wie die bereits erwähnte Reduzierung der Komplexität durch eine Verringerung der Variantenvielfalt und der Redundanzen, die Einsparung von Kosten und Zeit und die damit einhergehende erhöhte Flexibilität, wenn SOA realisiert ist. Auch die Qualität kann durch SOA mittels einer konsequent, am Kunden ausgerichteten Standardisierung gesteigert werden. Diese genannten Vorteile einer serviceorientierten Architektur dürften zu allgemein sein, um Ihren Chef zu überzeugen. Deswegen sollten sie für bestimmte Geschäftsbereiche konkretisiert und auf den greifbaren bzw. monetären Nutzen heruntergebrochen werden. Beispielhafte Ergebnisse könnten sein, dass die Projektkosten um ein Viertel reduziert und die Projektdauer verkürzt werden. Es ist wichtig zu prüfen, welche Ziele auf der Fachseite bestehen und ob diese von einer SOA profitieren. SOA nutzt einem stabilen Geschäft, das kaum Änderungen unterliegt, weniger als einem, das mit kurzen Time-toMarket-Zyklen neue Produkte auf den Markt bringen muss. Für ein erfolgreiches unternehmensinternes SOA-Marketing ist es deshalb entscheidend, diejenigen Unternehmensbereiche zu identifizieren, die von einer serviceorientierten Architektur am meisten profitieren.

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

4.2 Geschäftsanforderungen Für das Aufsetzen einer SOA ist es notwendig, Beziehungen transparent zu machen. In Unternehmen werden zwar häufig Prozesse modelliert, in der Regel existiert aber kein systematisches, zentrales Ordnen von Geschäftsanforderungen. Genau dies ist aber die Voraussetzung für die Identifikation von Fachservices und für das Erkennen von potenziellen Kandidaten für eine Wiederverwendbarkeit. Es wird ein logisches Modell benötigt, das die für ein erfolgreiches Betreiben eines Unternehmens erforderlichen Fähigkeiten und Funktionen überschneidungs- und redundanzfrei definiert und ordnet. Diese logische Strukturierung in Bezug auf Funktionen und Informationen dient als Speicher für Geschäftsanforderungen und hilft, die Geschäftsanforderungen – also die Nachfrage – in darauf abgestimmte IT-Dienstleistungen – also in ein passendes Angebot – zu übersetzen.

Aufbau einer SOA-getriebenen Unternehmensarchitektur mit einem logischen funktionalen Domänenmodell zur Übersetzung der Geschäftsanforderungen sowie einem logischen technischen Domänenmodell zur Strukturierung der Applikationsanforderungen

www.hessen-it.de

Wie in der Abbildung ersichtlich, dient das logische funktionale Domänenmodell als Verbindungsglied zwischen Prozessen und Anwendungsservices. Durch die Zuordnung der Fähigkeiten und IT-Funktionen zu Prozessen entsteht ein Baukastensystem. Dieses ermöglicht: a die Prozesse zusammenzufügen und zu orchestrieren, a die Anforderungen aus den Prozessen zu systematisieren, konsolidieren und in die IT zu kanalisieren, a Hoheiten über Daten zu definieren sowie a Schnittstellen effizient zu systematisieren und zu organisieren. Das Leistungsportfolio der IT mit seinen Applikationen und Services kann über das Domänenmodell optimiert und auf die Erfordernisse des Geschäfts ausgerichtet werden. Eine ähnliche Systematik bietet sich, wie die Abbildung zeigt, auch zur Gestaltung der technischen Infrastruktur an, die einen Fachservice unterstützt. Auch hier lässt sich an der Schnittstelle von Applikationen zur technischen Infrastruktur eine Übersetzungsebene einziehen. Diese ordnet die prinzipiell benötigten, technischen Fähigkeiten in technischen Domänen. Sie dienen als Speicher für die Anforderungen der Applikationen und helfen logische Kombinationsmuster zu definieren, die unterschiedliche Applikationsarchitekturen unterstützen. Auch hier dienen die Muster dazu, eine strategische Ausrichtung der technischen Infrastruktur auf die eher nicht-funktionalen Erfordernisse des Geschäfts zu erreichen. Darüber hinaus wird durch die logische Betrachtung mit der Orientierung an festgelegten Mustern eine maximale Standardisierung bis in die Implementierungswelt hinein erreicht. So werden durch maximale Transparenz in der jeweiligen Architekturebene Hebel für eine sinnvolle, am Geschäft ausgerichtete Standardisierung und Effizienzsteigerung identifiziert. Darüber hinaus werden durch die Transparenz der Beziehungen zwischen den Architekturebenen über die logischen Modelle Ursache- / Wirkungsbeziehungen deutlich, die dann ein konsequentes Ausrichten auf die Anforderungen des Geschäfts ermöglichen.

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

4.3 Argumentationsstrategie Für ein wirksames internes Marketing einer SOA-Initiative ist es wichtig, sich zuvor Verbündete vor allem auf der Geschäftsseite zu suchen. Hierfür ist es hilfreich, nicht gleich für das gesamte Unternehmen, sondern gezielt für einzelne Bereiche den konkreten Nutzen konsequent qualitativ und vor allem monetär zu spezifizieren. Der monetäre Nutzen kann durch Architekturmodelle ermittelt werden, die es ermöglichen, verschiedene Kostenblöcke der IT einzelnen Produkten zuzuordnen. Für eine solche Analyse muss SOA auf einzelne IT-Services bezogen werden. So kann berechnet werden, dass z. B. die Time-to-Market-Spanne um 50 % reduziert wird, wenn man SOA auf einen IT-Service anwendet.

Business Capability

3 other

700.000 €

100.000 €

300.000 €

400.000 €

400.000 € 2 other

100.000 €

400.000 €

ABB costs 500.000 €

200.000 €

100.000 €

2 other

200.000 €

Infrastructure Capability

200.000 €

300.000 €

SOA-basiertes Kosten- und Preismodell

300.000 €

www.hessen-it.de

Ein Kosten- und Preismodell wie in dieser Abbildung dargestellt basiert auf den Verknüpfungsinformationen zuvor beschriebener Modelle. Dadurch können Kosten der IT auf Funktionen, die für das Geschäft verständlich sind, zusammengefasst und dargestellt werden. Dies steigert die monetäre Transparenz über die Wirkung von Änderungen auf der Produkt- und Prozessebene sowie auf der Applikations- und Technologieebene. Die durch ein derartiges Kostenmodell geschaffene Transparenz erlaubt eine Ergebnissicht auf einzelne abgegrenzte Teilbereiche. Optimale, klar abgegrenzte, sehr fokussierte und zielgerichtete SOA-Projekte können so identifiziert und mit begrenztem Aufwand und Risiko umgesetzt werden. Man muss damit nicht einen generellen SOA-Ansatz für die gesamte Unternehmung mit relativ unspezifischen Investitionen verkaufen, sondern kann ganz fokussiert „SOA-profitable“ Bereiche identifizieren, in denen SOA mit der beschriebenen Kosten- und Nutzen-Transparenz nachweislich den maximalen Nutzen produziert. Mit diesen kleineren, fokussierten Maßnahmen ist die Schwelle für die Genehmigung von Mitteln geringer, weil diese dann nachweislich profitabel eingesetzt werden. Indem man die SOA auf einen konkreten Geschäftsbereich anwendet, wird ein ansonsten vager Nutzen für die Geschäftsleitung konkretisiert und greifbar. Wenn beispielsweise ein Geschäftsbereich wie Sales oder Billing identifiziert wird, der mit sehr kurzen Time-to-Market-Anforderungen konfrontiert ist, fällt es nicht schwer, den Nutzen überzeugend zu kommunizieren und Verbündete zu gewinnen. Durch die Verknüpfung strategischer Ziele des Unternehmens mit denen einzelner Stakeholder, zu denen SOA nachweislich einen direkten Wertbeitrag liefert, wird Aufmerksamkeit auf der Geschäftsseite erzeugt und die Bereitschaft geschaffen, in derartig werthaltige, abgegrenzte Maßnahmen mit überschaubaren Risiken zu investieren. Hat man einen solchen Nutzen aufgezeigt, quantifiziert und überzeugend vermittelt, ist es bei der Umsetzung dieser Maßnahme wichtig, die Realisierung dieses Nutzens bei der Implementierung nachzuweisen.

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

Dieser Ansatz birgt aber auch Gefahren: Eine Investitionszusage in eine SOA-Initiative ist mit ihm zwar leichter zu erreichen, das bedeutet aber nicht automatisch einen Durchbruch für eine unternehmensweite SOA. Denn er erfordert eine sehr gute Vorbereitung und die Gewissheit, dass der versprochene Nutzen auch nachweisbar erbracht werden kann. Ein Misslingen oder auch eine signifikante zeitliche Verzögerung des Projektes, die der Serviceorientierung zugeschrieben werden kann, bedeutet in der Regel die Aufgabe des SOA-Prinzips im laufenden Projekt und auf lange Zeit hin das Ende jeder weiteren SOA-Initiative. Sowohl bei der Identifikation und der Auswahl des SOA-affinen Bereichs als auch bei dem Nutzenversprechen und der geplanten Umsetzung ist größte Sorgfalt geboten, weil die Initiative und der zu erbringenden Nachweis eines SOAbasierten Nutzens von allen Seiten neugierig beobachtet wird. Mit SOA kann man nur mit einer effizienten, Fakten-basierten und an den Bedürfnissen der Stakeholder orientierten Kommunikation erfolgreich sein. Diese sollte auf einer transparenten und steuerbaren Architektur basieren, die gezielte SOA-Eingriffe ermöglicht und den entstandenen Nutzen quantifizieren lässt. Mithilfe von wohldefinierten, aus den Kerntreibern des Geschäfts abgeleiteten KPIs (Key Performance Indicators) kann der Erfolgsbeitrag von SOA in dem betrachteten Projekt nachgewiesen und an den Sponsor kommuniziert werden.

www.hessen-it.de

4.4 Vorteile kommunizieren In der IT ist meistens ein multivariates Zielsystem zu beachten. Das heißt, es handelt sich nicht um eine eindimensionale Optimierung, wie z. B. nur nach Kostenzielen, sondern um eine Mischung diverser, unterschiedlich gewichteter, teilweise konkurrierender Ziele, die zusammen betrachtet werden müssen. Außerdem ist nicht nur eine Ist- mit einer Zielsituation zu vergleichen, sondern auch die Migration dorthin. Denn selbst wenn das angestrebte Ziel ein Optimum darstellt und die gesetzten Ziele bestens erfüllt, scheidet die Lösung aus, wenn der Weg dorthin zu viele Risiken oder Kosten verursacht. Das Aufzeigen des Wertbeitrages führt oft zu komplexen Argumentationen, die für ein Management nicht überzeugend genug sind. Deswegen müssen die wesentlichen Vorteile mit Bezug zur Strategie möglichst mit einem quantifizierbaren Nutzen für das Geschäft herausgearbeitet und evtl. mithilfe anschaulicher Metaphern verdeutlicht werden. Da der Nutzen von SOA nicht unmittelbar und direkt auf das Geschäft wirkt, ist es wichtig, ausgehend von strategischen Treibern, die auf ein Geschäftsfeld wirken, eine Ursache- / Wirkungskette aufzubauen. Hierzu ist es nützlich, mit strategischen Aussagen realistische begründete Geschäftsszenarien zu erstellen, die künftig wahrscheinliche Situationen plakativ beschreiben. Daraus sollten Auswirkungen bzw. resultierende Anforderungen an die IT abgeleitet werden. Die spannende Frage ist dann, welche Maßnahmen mit welchem Ressourcen- und Zeitaufwand in der existierenden und, im Vergleich dazu, in einer imaginären SOA-getriebenen IT ergriffen werden könnten. Beim Vergleich der Zeiten- und Ressourcenaufwände von beiden IT-Varianten geht es nicht nur um die entstandenen Aufwände, sondern auch um den entgangenen Nutzen auf der Geschäftsseite durch eine zeitlich verzögerte Unterstützung und Realisierung des Geschäftsvorteils. Sowohl der Aufwand als auch der entgangene Nutzen ist also für beide IT-Varianten abzuschätzen und miteinander zu vergleichen.

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

Dieser berechnete Nutzen kann so noch nicht als Business Case für den SOA-Piloten verwendet werden, weil die Kosten für die Migration der existierenden IT auf eine serviceorientierte Architektur noch mitberechnet werden müssen. Zur Berechnung dieser Kosten müssen die bestehenden Abhängigkeiten, die im betrachteten Kontext bestehen, sowie die daraus resultierenden Aufwände für eine Transformation ableitbar sein. Diese setzt eine Transparenz voraus, wie sie nur durch die konsequente Umsetzung einer Unternehmensarchitektur möglich ist. Denn in der Regel muss abgegrenzt werden, welche Prozesse und damit verbunden Fähigkeiten von einem beschriebenen Geschäftsszenario betroffen sind. Ein Bebauungsplan zeigt dann sofort auf, welche Applikationen diese Fähigkeiten unterstützen. Wenn darüber hinaus die Betriebsmodelle und Server bekannt sind, auf denen diese Applikationen betrieben werden, können diese Informationen genutzt werden, um die aktuellen Kosten zu ermitteln. Andererseits wird auch deutlich, welche Anwendungen ersetzt werden müssen, um entsprechende Fachservices neu aufzubauen. Daraus müssen Kosten für die Entwicklung bzw. Beschaffung der benötigten Fachservices ermittelt und sowohl die Datenmigration wie auch der temporäre Parallelbetrieb während einer Übergangszeit mit kalkuliert werden.

2010

2011

2012

2013

2014

CAPEX (Ist) OPEX Maintenance (Ist) OPEX Operations (Ist)

100 500 600

50 500 600

20 400 500

0 0 0

CAPEX (SOA) OPEX Maintenance (SOA) OPEX Operations (SOA)

0 0 0

1.500 200 150

1.000 300 300

80 300 400

1.200 0

3.000 –1.800

2.520 –1.320

780 420

Umsatzplus Prozesseffizienz

0 0

1.000 500

1.500 1.000

2.000 1.200

Gesamt

–1.800

180

2.920

3.620

Gesamtkosten / Jahr Einsparungen IT Kosten zu Ist

Kosten- und Ertragsentwicklung eines fiktiven SOA-Projektes in T € CAPEX = Capital expenditure, Investitionen OPEX = Operational expenditures, Betriebskosten

www.hessen-it.de

Die Tabelle zeigt ein Beispiel für die mögliche Kostenentwicklung in einer begrenzten SOA-Initiative. Darin sind die parallel anfallenden Kosten der laufenden Systeme und der neu zu implementierenden SOA-basierten Systeme in den Jahren 2011 und 2012 berücksichtigt. Bei den IT-seitig erzielten Einsparungen werden die im Jahre 2010 berechneten 1,2 Mio Euro als Ausgangskosten verwendet, die als Vergleich konstant über die weiteren Jahre extrapoliert werden (siehe „Gesamtkosten / Jahr“). So werden die Einsparungen berechnet, die in den Jahren 2011 und 2012 negativ sind, da dort Investitionen für die Einführung der SOA vorgenommen werden, die die momentanen Betriebskosten übersteigen (siehe „Einsparungen IT-Kosten zu Ist“). Im Jahre 2013 werden erste Einsparungen erzielt, da die Betriebskosten im Zielsystem geringer ausfallen. Hierunter fallen auch Effekte, wie die Verringerung von Projektkosten zur Erweiterung der Services oder die geringeren Kosten zur Implementierung von Änderungen. Darüber hinaus werden die Auswirkungen der SOA auf die Geschäftsseite kalkuliert. Der Umsatz kann gesteigert werden, da durch kürzere Timeto-Market-Realisierungen neue Produkte eher an den Markt gebracht werden können, wodurch Marktvorteile entstehen, die in messbaren Umsatz- und damit in Gewinnsteigerungen resultieren. Ebenso können Kosten auf der Fachseite eingespart werden, weil die Prozesse schneller angepasst und effizienter gestaltet werden können (siehe Abbildung nächste Seite). Hieraus ergibt sich, dass – ohne eine entsprechende Verzinsung zu berücksichtigen – der Nutzen die Kosten bereits im zweiten Jahr übersteigt. Eine Amortisierung der Investition ist danach bereits nach drei Jahren erreicht. Das ist eine Perspektive, die auch von einem Chef nicht ignoriert werden kann und ihn überzeugen dürfte.

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

Geschäftsorientierter Nutzen von SOA Einsparungen in €

4000 Prozessefﬁzienz Umsatzplus IT-Einsparungen

3000 2000 1000 0 –1000

2010

2011

2012

2013

2014

–2000 –3000 Zeit Kumulierte Entwicklung eines fiktiven SOA-Projektes

18000 16000

IT SOA kumuliert, verzinst IT Bezugslinie kumuliert, verzinst

14000 12000 10000 8000 6000 4000 2000

20 20

18 20

16 20

14 20

Kumulierte, verzinste Kosten in €

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

Zeit Amortisierung eines fiktiven SOA-Projektes in reiner IT-Perspektive

www.hessen-it.de

Betrachtet man die kumulierte Kostenentwicklung eines SOA-Projektes lediglich in der IT-Perspektive und projiziert man die aktuellen, jährlichen Kosten konstant in die Zukunft, so erhält man bei einer Verzinsung von acht Prozent erst eine Amortisation nach ca. zehn Jahren. Diese Perspektive wird keinen Chef zu einer Investition veranlassen.

Eine rein IT-bezogene Betrachtung des SOA-Nutzens ist in vielen Fällen nicht überzeugend. Der Geschäftsnutzen ist unbedingt mit zu berücksichtigen.

SOA sollte man deshalb grundsätzlich mit Bezug zum erzeugten Geschäftsnutzen darstellen und kommunizieren. Dabei ist es hilfreich, die strategischen Treiber, die auf ein Geschäftsfeld wirken, zu kennen, und daraus diejenigen zu identifizieren, die durch SOA positiv beeinflusst werden. Es sollten diejenigen Prozesse herausgesucht werden, die diese Treiber am stärksten fördern, und damit die Fähigkeiten, die von diesen benötigt werden. Daraus können die involvierten Applikationen abgeleitet werden, die in eine serviceorientierte Architektur überführt werden müssten. So erfolgt eine strategisch determinierte Auswahl eines Bereiches, der von einer SOA am meisten profitiert. Diese strategisch getriebene Auswahl und Abgrenzung eines Geschäftsbereiches hilft, den Nutzen von SOA geschäftsorientiert darzustellen. Eventuell kann diese monetäre Kalkulation durch weitere qualitative Kennzahlen, die an den involvierten strategischen Treibern orientiert sind, ergänzt werden. Die folgende Abbildung zeigt in diesem Zusammenhang einen Ausschnitt aus der beschriebenen Ursache- / Wirkungskette – von den bereits aus strategischen Gesichtspunkten selektierten Prozessen über die sie unterstützenden Fähigkeiten zu den Applikationen. Hieraus kann sowohl die bestehende Situation wie auch die künftig gewünschte, serviceorientierte Ausrichtung der Anwendungsarchitektur entnommen werden.

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

Prozessmodell Sub-processes

Domänenmodell Analyse & Design

Construction

Domäne x

Fähigkeiten

Bebauungsplan Fähigkeiten ITP

App.1

App.4

App.5

App.7

App. 11

App.14

App.12 App.13

App.15

App.17

App.10

App.16

App.x

Target architecture (Master plan)

As-is Applikationen

App.8

ITF

App.2

ITx

App.3

App.6

App.9

Ursache- / Wirkungszusammenhänge zwischen Prozessen (oben) über Domänen / Fähigkeiten (Mitte) und Applikationen (unten)

Anhand derartiger Darstellungen kann kommuniziert werden, wie die Komplexität durch SOA reduziert, die Qualität gezielt verbessert und dadurch die Kosten nachvollziehbar gesenkt werden können. Damit können dann Aussagen getroffen werden, die wie in der folgenden Abbildung visualisiert werden können. Diese eher plakativen Darstellungen sind einprägsam und reduzieren die Botschaft auf wesentliche, geschäftswirksame Aussagen.

www.hessen-it.de

Verringerung der Variantenvielfalt

Kostensenkung # Applikationen

280 –68%

–15%

Prozessmodell Sub-processes

Domänenmodell Analyse & Design

Construction

Domäne x

Fähigkeiten

Bebauungsplan Fähigkeiten

100 Ist

ITP

App.1

App.4

App.5

App. 11

App.14

App.12 App.13

App.15

App.17

App.16

App.x

App.7 App.8

ITF

App.2

ITx

App.3

Soll

App.6

App.9 App.10

Target architecture (Master plan)

As-is Applikationen

# Betriebsmodelle

Soll

Ist

Soll

Ist

–25%

Core

Host

FrontEndServer

Encaps. 3270/DTA

2 Soll

Clearing-DTA, etc.

FTP/DTA

FTP

Layer

Ist

BackEndServer

HTTPS, etc.

Layer

–83%

Layer

Zentraler Mainframe mit Windows Front-/Back-Ends Thin Client

Thin Client Rumba

Server

ORACLE WIN 2003 x86

RUV Permanent Proc. RUV Task Shared DB2 z/OS parallel Sys plex IBM zSeries

Server

ORACLE WIN 2003 x86

Kosteneinsparungsnutzen von SOA, beispielhaft illustriert

4.5 Fazit Bevor SOA der Geschäftsleitung oder den Entscheidungsträgern eines Unternehmens präsentiert werden kann ist eine gute, gründliche Vorbereitung erforderlich. Die Zusammenhänge zwischen den verschiedenen Geschäftsfeldern müssen erörtert und verstanden werden. Dies ist in der Regel durch eine gute Architekturarbeit zu erreichen. Es sollte eine Unternehmensarchitektur erarbeitet werden, die für die Identifizierung und Abgrenzung der für die serviceorientierte Architektur optimalen Geschäftsbereiche von erheblichem Nutzen ist und somit für die benötigte Transparenz sorgt. Mit ihr kann die Migration zur neuen SOA-Welt exakt geplant und der durch SOA zu realisierende Nutzen genau abgeschätzt und quantifiziert werden. Wenn im ausgewählten Bereich die Transformation in eine serviceorientierte Architektur ohne Risiko und im geplanten Zeit- und Kostenrahmen bewerkstelligt werden kann, sollte das SOA-Vorhaben in einer Art und Weise präsentiert werden, die den Chef mit seiner Sprache abholt und ihm anschaulich und plakativ die wesentlichen Botschaften vermittelt. Nach erfolgtem Entscheid für das SOA-Projekt kann dann die SOA-Implementierung begonnen werden, um den versprochenen Nutzen wie geplant reibungslos und nachweisbar zu realisieren.

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

Thomas Mironiuk, Intersystems GmbH Zu Recht wird serviceorientierte Architektur (SOA) heute in einem Atemzug mit Business Prozess Management (BPM) genannt, war sie doch von Anfang an als Methode zur Prozessoptimierung gedacht. Wie so viele sinnvolle Ansätze aus der IT leidet sie allerdings, seit der Begriff von Gartner kreiert wurde, an akuten Kommunikationsproblemen. Geradezu sträflich wurde versäumt, den an den zu optimierenden Prozessen beteiligten oder von ihnen betroffenen Menschen eine verbindliche und allgemeinverständliche Definition von SOA an die Hand zu geben. Bis heute können sich Industrie und Wissenschaft nicht einmal auf eine gemeinsame Definition von SOA für die IT einigen. „SOA ist ein Paradigma für die Strukturierung und Nutzung verteilter Funktionalität, die von unterschiedlichen Besitzern verantwortet wird.“, lautet die Definition der Organization for the Advancement of Structured Information Standards (OASIS). Sicherlich richtig, aber lebensfern. Jenseits der Kreise, die sich mit IT-Infrastrukturen im Unternehmen beschäftigen, dürfte man viel eher den Satz zu hören bekommen: „Gestern wurden Mitarbeiter wegrationalisiert, heute machen

wir SOA.“

www.hessen-it.de

5.1 Definition „SOA-Governance” Die Herausforderung, diesen Missstand auf Unternehmenseben zu beheben, fällt in den Aufgabenbereich der SOA-Governance, der Kontrolle und Steuerung von serviceorientierten Prozessen. Das Problem hierbei ist nur, dass die Vorstellung aller Beteiligten, was genau SOA-Governance sein soll, noch unpräziser ausfällt als bei SOA selbst. 2008 definierte der Branchenverband BITKOM in einem SOA-Leitfaden den Begriff der SOAGovernance als: „Definition, Durchsetzung und Steuerung von organisatorischen Regeln, Richtlinien und Standards zur konsequenten Ausrichtung der Services und Geschäftsprozesse an der Unternehmensstrategie durch geeignete Steuerungs- und Kontrollmaßnahmen. IT-Governance im konventionellen Sinne befasst sich hingegen mit der Organisation, Steuerung und Kontrolle der IT und der IT-Prozesse. Diese Aufgabe wird jedoch immer noch zu technisch gesehen. Durch die Einführung einer SOA rückt der Fokus auf Services und Geschäftsprozesse auch in den Mittelpunkt der IT-Governance“. Mittlerweile wird der Begriff „Governance“ ähnlich inflationär gebraucht wie der Begriff Management, weil sich damit herrlich verschleiern lässt, dass derjenige, der ihn nutzt, nur eine verschwommene Vorstellung von dem hat, was zu tun ist. Und wie bei des Kaisers neuen Kleidern traut man sich nicht nachzufragen – zu groß die Angst, Unkenntnis einzugestehen. Neusprachlich leitet sich der Begriff vom französischen Wort „gouverner“ ab, was so viel wie verwalten, leiten oder erziehen heißt. Sicherlich alles Tätigkeiten, die im Rahmen von Governance anfallen. Folgt man dem Wort aber zu seinen historischen Wurzeln, findet man das griechische „kybernan“, was bedeutet, das Steuerruder zu führen. Alle, die an der SOA-Governance beteiligt sind, sollten sich diesem Ursprung verpflichtet fühlen, denn die Aufgabe, die ihnen bevorsteht, besteht darin, die Anweisungen des Kapitäns bzw. CEOs in einen schnellen, aber sicheren Kurs für Schiff und Mannschaft umzusetzen. Dabei geht es dann eben nicht darum zu verwalten, sondern zu führen.

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

Zu einer der ersten Aufgaben der SOA-Governance gehört daher die Entwicklung eines Governance-Plans, einer Seekarte durch die SOAUntiefen. Dies bedarf natürlich einiger Vorbereitungen. Da ist zunächst das Bekenntnis von Geschäfts- und IT-Leitung einzuholen, SOA zu einem langfristigen integralen Bestandteil der IT-Strategie des Unternehmens zu machen. Trotzdem sollten die ersten Projekte so angelegt sein, dass sich kurzfristig sichtbare Vorteile ergeben, um die generelle Akzeptanz von SOA für die Zukunft zu fördern. Das wahre Potenzial spielt eine solche Architektur aber erst dann aus, wenn der Pool an verfügbaren Services echte Mehrwertanwendungen erlaubt und Prozesse problemlos neu angelegt oder verändert werden können. SOA ist kein Sprint, sondern ein Weg, und der, so Kafka, entsteht dadurch, dass man ihn geht. Desweiteren sollten die an der SOA-Governance Beteiligten eine ehrliche Bestandsaufnahme der Ressourcen und Fähigkeiten durchführen und dann festlegen, welche Ziele SOA für das Unternehmen erreichen soll. Der „Alles-Ansatz“, Kosten senken, Flexibilität erhöhen und Mehrwerte schaffen, eignet sich zwar hervorragend, um Erfolge zu vermelden, wo positive Ergebnisse trotz vollständigen Scheiterns der ursprünglichen Mission zu Buche schlagen wie bei Christoph Kolumbus, nicht aber für ein qualifiziertes Measuring und Controlling. Unbedingt muss die SOAGovernance auch in Einklang mit den anderen Steuerungsmodulen im Unternehmen gebracht werden, von Corporate-Governance über BPMGovernance bis zur Data-Governance. Hier sind gegebenenfalls erste Anpassungen im Nicht-IT-Umfeld notwendig, sollten sich Teile der Regelungen als untauglich oder hinderlich für die erfolgreiche Implementierung einer SOA im Unternehmen erweisen. Ist er erst einmal erstellt, enthält der SOA-Governance-Plan dann alle Informationen, um neue Mitglieder im Governance-Team umfänglich über Ziel, Ressourcen, Hierarchien, Policies und Kommunikationsmaßnahmen zu informieren. Zudem gibt er formale Strukturen, zum Beispiel in Form von Abzeichnungsbögen vor, um die Integrität der Dokumentation zu sichern.

www.hessen-it.de

5.2 Soziale Auswirkungen Die im Pan verzeichneten Ressourcen umfassen nicht nur Gebäude und die IT-Infrastruktur, sondern vor allem Mitarbeiter. Team-Rollen und Verantwortlichkeiten sowie die damit einhergehenden individuellen Rollen und Pflichten sind essenzieller Bestandteil eines jeden Governance-Plans. Dabei darf getrost davon ausgegangen werden, dass die neuen Teams wenig mit den alten Abteilungsstrukturen zu tun haben. Noch bevor SOA mit neuen oder veränderten Prozessen im Makrokosmos Unternehmen für Unruhe sorgt, wirbelt sie den Mikrokosmos der IT-Abteilung durcheinander. Holt man neue Leute für das SOA-Projekt, geht auf Leitungsebene der Machtkampf um Personalstellen los, während gestandene Mitarbeiter sich in ihrer Wertschätzung zurückgesetzt fühlen. Hat man alle benötigten Qualifikationen schon im Unternehmen, kommt es unweigerlich zu Verschiebungen innerhalb der Leitungshierarchie, während sich gleichzeitig Karriereziele und Aufstiegspfade verändern oder gar verschwinden. Wer glaubt, ohne entsprechende Optionen und Angebote für die betroffenen Mitarbeiter eine Politik allein „zum Wohle des Unternehmens“ durchsetzen zu können, stößt daher schnell an seine Grenzen. Schleppende Umsetzung und innere Kündigung sind noch die harmlosesten Folgen. Wenn erhoffte Beförderungen nicht mehr möglich sind oder Arbeitszeit und Arbeitsort zu privaten Problemen führen, verliert das Unternehmen unter Umständen für den Erfolg der SOA-Strategie wesentliche Mitarbeiter. Erfahrung mit der Unternehmensstruktur und -kultur kann nicht einfach durch fachliche Kompetenz eines neuen Mitarbeiters ersetzt werden, von der Projektverzögerung ganz zu schweigen.

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

Kommunikation und Vermittlung des Governance-Plans sollten sich daher nicht auf die rein fachlichen Informationen und Maßnahmen für die IT-Mitarbeiter respektive die Prozessinhaber der Fachabteilungen beschränken. Zugleich sind ein der Kultur des Unternehmens entsprechendes Anreizoder Belohnungssystem zu schaffen und Karrierealternativen aufzuzeigen. Bei der Formulierung dieses Angebots für die Beschäftigten handelt es sich zugleich um die Generalprobe für das Gesamtunternehmen. SOA-unterstütztes BPM wird immer wieder nicht nur Abläufe, sondern auch strukturelle Zuständigkeiten verändern. Eine Belegschaft, die darauf vertrauen kann, dass ihre Interessen bei solchen Planungen berücksichtigt werden,

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

www.hessen-it.de

5.3 Governance realisieren Steht der Plan, gilt es ihn in die Tat umzusetzen. Dabei zeigt sich sehr schnell, dass SOA-Governance ein fließender Prozess ist. Das SOA Center of Excellence (COE) wird im Laufe der Zeit neue Mitglieder bekommen, Hard- und Software werden sich auf neue Technologien und Produkte einstellen, Prozesse anhand von Erfahrungen optimiert oder zu Best-Practices erklärt werden. Insbesondere Fragen der Wiederverwendung von Services (service reuse), der Kostenverteilung und eines Anreizsystems für den Reuse sowie der Art und Vergütung von Service-Level-Agreements (SLA) sind nicht immer schon im Vorfeld eindeutig festzulegen. Nach den ersten SOA-Teilprojekten können dann sukzessive Maßnahmen in die Wege geleitet werden, die gezielt nach Aktivposten suchen und solche verwalten, Monitoring-Tools implementieren und Mitarbeiter auf allen Ebenen über neue Prozesse und erwartetes Verhalten schulen und informieren. Umfragen zeigen, dass diejenigen Unternehmen erfolgreicher abschneiden, die ihre für SOA benötigte Software gezielt nach deren Fähigkeiten auswählen, als solche, die sich blind auf eine Suite verlassen. Trotzdem sind Fragen der richtigen Infrastruktur oder Entwicklungsumgebung, nach Herstellerunabhängigkeit und Standards leichter zu lösen als solche, die Jobprofile und Personalüberlegungen beinhalten. Zu den grundlegenden Aufgaben der SOA-Governance gehört, sich Gedanken zu Lebenszyklen von Services zu machen, Composite Applications zu schaffen oder Regeln und Strukturen für den Umgang mit von außen eingekauften Services zu definieren und für deren Einhaltung zu sorgen. Die hierzu benötigten Mittel wie Excellence-Center oder Service-Level-Agreements sind bewährte Elemente innerhalb der IT. Dies ist Segen und Fluch zugleich.

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

5.4 Governance kommunizieren Da SOA-Governance bewusst die Fachabteilungen in die Prozesse mit einbezieht, ist die IT gezwungen, mit Nichtfachleuten über Fachbegriffe zu reden. Plötzlich muss die Kommunikation ohne Meta-Wissen auskommen, es verlieren die stillschweigenden Voraussetzungen und Übereinkünfte ihre Wirkung, die immer dann in Kraft sind, wenn Fachleute eines Berufsstandes unter sich sind. Im Idealfall reden IT-Spezialisten mit ihren Kollegen aus den Fachabteilungen so, wie es Verbraucherschützer inzwischen von Kundenberatern in Banken fordern: „Setzen Sie nichts voraus.“ Um verständlich zu werden, müssen vor allem Zahlen in einen Kontext gebracht werden, den die Fachabteilungen verstehen. Was bedeutet ein vereinbarter Service-Level? Warum machen Millisekunden bei ResponseZeiten einen Unterschied? Was verbirgt sich hinter Service-Versionen? Wem das zu banal klingt, der stelle sich einfach nur vor, er wäre von jetzt auf gleich auf das Handelsparkett der Deutschen Börse in Frankfurt gestellt. Die Sprache in der IT entwickelt sich mindestens so rasch weiter wie die Technologie selbst und erinnert manchen branchenfremden Menschen an die Geheimsprache der mittelalterlichen Handwerksbünde.

Holen Sie sich soziale Kompetenz ins SOA-Team und betreiben Sie intern SOA-PR und -Marketing!

www.hessen-it.de

Wenn man also verhindern will, dass SOA scheitert, obwohl man technisch alles richtig macht, gilt es zwei Dinge zu beherzigen: Zum einen ist rechtzeitig soziale Kompetenz ins SOA-Governance-Team zu holen, um die Auswirkungen von Prozessänderungen auf die Mitarbeiter zu bewerten und gegebenenfalls abfangen zu können. Zum anderen darf man sich nicht zu schade für interne PR und internes Marketing sein. Keine gute Idee verkauft sich von alleine und eine SOA schon gar nicht. Während es außerhalb der IT-Abteilung Verlustängste und Widerstände zu überwinden gilt, muss innerhalb womöglich gegen den „Alles schon mal dagewesen“-Faktor angekämpft werden. SOA ist zugegebenermaßen lediglich der aktuellste einer ganzen Reihe von Ansätzen, IT-Abläufe und Unternehmensprozesse zu harmonisieren. DCOM (Distributed Component Object Model), DCE (Distributed Computing Environment) und CORBA (Common Object Request Broker Architecture) kamen alle mit ähnlich vollmundigen Versprechungen daher, um dann wieder in der Versenkung zu verschwinden.

5.5 Fazit Um SOA-Governance erfolgreich umzusetzen, reichen fachliche Qualifikationen allein nicht aus. Investitionen in die Softskills des GovernanceTeams sind für den Erfolg der SOA im Unternehmen entschieden wichtiger als die Anschaffung etwa eines Monitoring-Tools. Ohne solche Software lässt sich eine SOA zur Not realisieren, aber ohne die Fähigkeit, die Belegschaft für SOA zu begeistern, ist das Scheitern von Anfang an vorprogrammiert.

SOA-Security: Webservices erfordern zusätzliche Sicherheitsmaßnahmen

Dr. Bruno Quint, Corisecio GmbH

6.1 Grundlagen Serviceorientierte Architekturen (SOA) entwickeln sich von einem HypeThema zu realen Projekten. Die Idee, Funktionalitäten und Aufgaben als lose gekoppelte, unabhängige, austauschbare Dienste über standardisierte Schnittstellen anzubieten, ermöglicht Unternehmen flexibler auf sich ändernde Geschäftsprozesse zu reagieren. Um den Vorteil der Flexibilität und die damit verbundene Kostenersparnis zu erreichen, müssen einzelne Services bestimmten Anforderungen genügen. In der Literatur existiert eine Vielzahl von Kriterien an Services – die verbreiteten sind: a Standardisierte Service-Schnittstellen – um die Interoperabilität sicherzustellen a Lose Kopplung – ein Minimum an Abhängigkeiten muss die Modellierbarkeit verschiedener Services zu einem Geschäftsprozess erlauben a Funktionsabstraktion – fordert eine Kapselung von Funktionen a Wiederverwendbarkeit – ist eine Grundanforderung zur Erreichung von Kostenersparnissen a Service-Autonomie – ermöglicht das (weitgehend) autarke Agieren von Services a Vorratsdatenfreiheit des Services (Statelessness) – persistente Daten werden nur gespeichert, wenn sie explizit Dienstleistungsbestandteil des Service sind a Auffindbarkeit des Services – über definierte Repositories a Orchestrierbarkeit der Services – um einzelne Services zu einem Gesamtprozess zu verbinden 62

www.hessen-it.de

Grundsätzlich ist SOA ein Managementkonzept. Es schreibt keine konkrete technische Realisierung oder bestimmte Methoden vor. Allerdings haben sich Web Services (basierend auf SOAP/XML) zur Realisierung durchgesetzt. Ein Web Service ist eine auf XML (eXtensible Markup Language) und SOAP (Simple Object Access Protocol) basierende Anwendung, die definierte Methoden über eine standardisierte Schnittstelle anbietet und über eine URI (Uniform Resource Identifier) eindeutig identifizierbar macht. Als Kommunikationsprotokoll dient SOAP (W3C), mit dem Daten zwischen Systemen ausgetauscht werden können. SOAP verwendet XML zur Datenrepräsentation sowie (in den meisten Fällen) TCP/IP für den Transport. Zu einer SOA-Infrastruktur gehört weiterhin ein Service Repository, welches meist über UDDI (Universal Description, Discovery and Integration) und WSDL (Web Services Description Language) realisiert wird.

6.2 Sicherheitsanforderungen Im Grunde gelten für SOA die gleichen Sicherheitsanforderungen wie für herkömmliche monolithische Systeme. Zusätzlich existieren durch die Verteilung von Systemen und Prozessen aber SOA-spezifische Sicherheitsrisiken, die entsprechend zu berücksichtigen sind. Wie in monolithischen Systemen müssen auch in SOA-Infrastrukturen Identitäten und Berechtigungen verwaltet, Benutzer authentisiert, Zugriffsberechtigungen überprüft, Zugriffe und Zugriffsversuche aufgezeichnet und Daten mittels kryptografischer Methoden signiert (Integrität) oder verschlüsselt (Vertraulichkeit) werden. Gerade in verteilten Umgebungen werden zudem systemweite Sicherheitsrichtlinien (Policies) benötigt, deren Einhaltung (Compliance) es permanent zu überwachen gilt. Die Bedrohungspotentiale lassen sich grob in zwei Kategorien einteilen. Zum einen wird eine SOA-Infrastruktur basierend auf einem Netzwerk / IT-System allgemeinen Gefahren wie Malware, Buffer Overflows, Backdoors, Netzangriffen (Scanning, Spoofing, etc.) sowie Denial of Service (DoS) und vielen mehr ausgesetzt.

SOA-Security: Webservices erfordern zusätzliche Sicherheitsmaßnahmen

Der Grundgedanke von SOA wirft zum anderen weitere Anforderungen und Bedrohungspotentiale auf, die durch die Integration verteilter und teilweise heterogener Systeme insbesondere zu beachten sind. So müssen Replay-Attacks, Service-Kompromittierung sowie unberechtigte Service-Nutzung durch adäquate Mechanismen verhindert werden.

UserID / Password

Application

Service

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).

www.hessen-it.de

Die Realisierung eines Geschäftsprozesses über eine Vielzahl lose gekoppelter Services erfordert zudem mehr Authentisierungs- und Autorisierungsvorgänge, eine jederzeit gewährleistete Vertraulichkeit sowie eine höhere Integrität als in einem monolithischen System. Ein Prozessdesign über Unternehmensgrenzen hinweg und zwischen unternehmensfremden Teilnehmern verstärkt diese Sicherheitsanforderungen an Services und Lösungen und setzt so genannte Federation-Konzepte voraus. Technisch gesehen muss dabei die Interoperabilität sichergestellt werden. Zu nennen sind an dieser Stelle bspw. die Umwandlung von Identitäten und deren Formate, der Einsatz von Industriestandards und die Gewährleistung der Wiederverwendbarkeit von Security-Diensten.

Die herkömmlichen Sicherheitsanforderungen müssen um diverse SOA-spezifische Ausprägungen erweitert werden.

Im folgenden Abschnitt sollen die Sicherheitsmechanismen und SecurityStandards kurz dargestellt werden. Eine einleitende Diskussion über den Einsatz herkömmlicher Methoden im SOA-Umfeld zeigt die Notwendigkeit neuer Sicherheitslösungen auf.

SOA-Security: Webservices erfordern zusätzliche Sicherheitsmaßnahmen

6.3 Sicherheitsmechanismen Schwächen herkömmlicher Ansätze Wie zuvor aufgezeigt, stellt eine serviceorientierte Architektur zusätzliche, neue Anforderungen an die Informationssicherheit in den Unternehmen. Herkömmliche Schutzmaßnahmen auf Transport- und Applikationsebene stoßen beim Einsatz in SOA an ihre Grenzen und bieten keinen ausreichenden Schutz. So ist die Absicherung von Web Services mittels TLS (Transport Layer Security) oder SSL (Secure Sockets Layer) unzureichend. Schließlich bietet TLS / SSL lediglich eine Sicherheit auf Transport-Ebene für eine definierte Punkt-zu-Punkt-Verbindung. Die Sicherheit kann nach dem Eingang im Zielsystem nicht mehr gewährleistet werden und der Sicherheitskontext geht verloren. In einem nachrichtenbasierten Workflow über mehrere Knoten und Teilnehmer bedeutet dies, dass beispielsweise nicht mehr sicher nachvollzogen werden kann, wer eine Bestellung aufgegeben hat oder wer von welcher Stelle als vertrauenswürdig bestätigt wurde. Zudem sind geforderte Security-Operationen auf Elementebene (bspw. für Signatur und Verschlüsselung der Kreditkarteninformationen) mit TLS nicht zu realisieren, da lediglich der Transport der gesamten Nachricht gesichert wird. Herkömmliche Firewall-Technologie (Transport Layer Firewalls) kann lediglich eine Netzwerksicherheit gewährleisten und ist somit zwar notwendig, aber keineswegs ausreichend. Eine Inspektion der Nachrichten auf Schadsoftware ist ebenso wenig möglich wie die Überprüfung der Gültigkeit von Inhalt oder Absender. Die Weiterentwicklung von herkömmlichen Firewalls zu XML-Firewalls erlaubt zwar ein Durchsuchen (Parsen) der Nachrichten und rudimentäre Content-Inspection, diese sind aber für einen Einsatz zur Durchsetzung einer Security Policy nicht ausreichend. Neben der Administrations- und Kostenproblematik, vor jeden Service eine XML-Firewall zu platzieren, stoßen diese Technologien spätestens bei transformierten Nachrichten (durch Verschlüsselung, Signatur oder Security Token) an ihre Grenzen.

www.hessen-it.de

Traditionellerweise wird ein Teil der Sicherheit (wie Authentisierung und Autorisierung) innerhalb der Applikation umgesetzt. Dies ist aber in einer SOA-Umgebung bereits aufgrund der Inflexibilität problematisch. Bei neuen Security-Anforderungen müsste jede betroffene Applikation geändert werden. Eine zentrale Administration fehlt. Notwendig wäre weiterhin die Implementierung der Security-Funktionalität in jeder Applikation und jedem Service. Das Grundprinzip der losen Kopplung und die damit verbundene Flexibilität würde durch eine starre Security-Implementierung verloren gehen. Der Anpassungsaufwand für die Security-Lösung würde ein flexibles Design von Geschäftsprozessen stark einschränken. Eine mögliche Alternative bietet ein streng zentraler Architekturansatz. Dabei wird die Security-Logik aus der Applikation herausgenommen und in einem zentralen Server vorgehalten. Simple Agenten außerhalb der Applikation fragen den zentralen Server zur Umsetzung der Policy bei jedem Aufruf an. Ein solcher Ansatz ist nur bedingt geeignet. Zwar ist die Beherrschbarkeit und Administration gewährleistet. Jedoch wirkt sich diese Struktur nachteilig auf Aspekte wie Ausfallsicherheit, Netzwerktraffic, Lastverteilung und Skalierung aus. Security-Lösungen für SOAInfrastrukturen erfordern flexible Architekturansätze, die die beschriebenen Aspekte abdecken.

SOA-Security: Webservices erfordern zusätzliche Sicherheitsmaßnahmen

Sicherheitsstandards Um die Schwächen herkömmlicher Sicherheitsmechanismen zu beheben und SOA-spezifische Anforderungen zu erfüllen, existieren zahlreiche Techniken und Methoden, die speziell für den Einsatz in nachrichten- und dienstorientierten Infrastrukturen entwickelt wurden. Insbesondere die von den Standardisierungsgremien (W3C und OASIS) verabschiedeten Standards bieten Basistechnologien, die neben der Sicherheit auch die Interoperabilität gewährleisten. Allen gemein ist dabei, dass die Sicherheit und Sicherheitsinformationen auf Nachrichtenebene implementiert werden und somit die Schwächen von Sicherheitsmechanismen auf Transportebene, wie z. B. SSL / TLS überwunden werden.

Aufgrund der Vielzahl von Sicherheitsstandards und -methoden werden an dieser Stelle nur die wichtigsten kurz vorgestellt: a XML-Encryption Diese Spezifikation legt fest, wie und in welcher Form XMLDokumente innerhalb der XML-Syntax verschlüsselt werden. a XML-Signature Die XML-Digital-Signature-Specification legt die Regeln und die Syntax fest, mit denen digitale Unterschriften für XML-Elemente erzeugt werden. a Web Service (WS)-Security Grundidee des von Microsoft, IBM und Verisign entwickelten Standards war es, eine Spezifikation zu erstellen, die zeigt, wie die vorhandenen Basistechnologien XML-Encryption, XMLSignature und XML-Key Management in SOAP integriert werden können. Dieser Standard bildet somit die Schnittstelle zwischen vorhandenen Security-Technologien und dem Web ServiceStandardformat SOAP.

www.hessen-it.de

a SAML (Security Assertion Markup Language) SAML ist ein Standard zum Transport von Authentisierungsund Autorisierungsinformationen innerhalb von Web Services. Er ermöglicht die Einbringung erweiterter Sicherheitsinformationen in SOAP-Dokumente als auch die Realisierung von Single Sign On (SSO)-Szenarien. a XKMS – XML Key Management Specification Die XKMS-Spezifikation beschreibt Möglichkeiten für den Austausch und die Überprüfung von Zertifikaten innerhalb einer PKI. Durch die Standardisierung wird zudem die Kompatibilität verschiedener PKI sichergestellt. Des Weiteren sei an dieser Stelle auf die Spezifikationen von

WS-Trust, WS-Policy sowie WS-Federation verwiesen.

Nicht-standardisierte Sicherheitsmechanismen Neben standardisierten Sicherheitsmechanismen müssen auch in SOAUmgebungen herkömmliche Bedrohungen wie Netzattacken abgewehrt werden. Wie im Abschnitt 6.2 dargelegt, sind an die Umsetzung und Implementierung von SOA-Lösungen besondere Anforderungen gestellt, die die traditionellen Umsetzungen nicht erfüllen. Diese müssen sozusagen „SOA-enabled“ werden.

SOA-Security: Webservices erfordern zusätzliche Sicherheitsmaßnahmen

Single Sign On (SSO) Richtig eingesetzt ermöglichen SSO-Methoden gleichsam erhöhte Sicherheit, niedrigere Verwaltungskosten sowie verbesserte Benutzbarkeit. In SOA-Szenarien mit einer Vielzahl integrierter Systeme und Services mit dementsprechend vielen Policy Enforcement Points kann ein SSO-System diese Vorteile voll und ganz ausspielen. Voraussetzung ist aber ein SOAfähiges SSO-Konzept. In realen SOA-Szenarien authentifiziert sich ein Nutzer nicht direkt an den jeweiligen Backendsystemen, sondern an zentraler Stelle, meistens an einer Portalanwendung. Alle weiteren Anmeldungen erfolgen über technische User-Konzepte. SSO nutzt daher ein Benutzer- und Credentialmapping, um Anwendungen mit unterschiedlichen Authentisierungsinformationen zu bedienen. Zudem besteht die Möglichkeit zur Schaffung einer zentralen Entität. Dafür müssen Entitäten aus verschiedenen Quellen (Meta Directories, Datenbanken, etc.) angebunden, ausgelesen, importiert und synchronisiert werden. Werkzeuge, die manuell oder über automatisierte Läufe ein Mapping (Beziehung schaffen) zwischen gleichen Entitäten erlauben, helfen bei der Umsetzung und Pflege. Die Authentisierungsdaten können dann über verschiedene Mechanismen (z. B. Agentensysteme) an die angebundenen Systeme geliefert werden. Gerade bei der Anbindung von Legacy-Systemen ist es vielfach erforderlich, die Anmeldeinformationen zusätzlich in ein anderes Format zu transformieren. Dabei kann eine Anmeldung auf Nachrichtenebene (im Gegensatz zu sitzungsbasierten Systemen) von Agenten ausgeführt werden und eine Anmeldung in Formaten der Legacy-Anwendungen ist möglich.

www.hessen-it.de

Web Application Firewall (WAF) Eine WAF-Technologie ist notwendig, aber nicht hinreichend, um Services sowie den Nachrichtenaustausch umfassend abzusichern. So ist der Schutz vor SQL-Injections, Brute Force, Denial of Service-Attacken durch eine WAF zu gewährleisten. Dennoch stoßen herkömmliche Web Application Firewalls bei der Behandlung von Web Services schnell an ihre Grenzen. Gerade bei verschlüsselten SOAP-Nachrichten sind diese Lösungen nicht in der Lage, Angriffe zu identifizieren bzw. abzuwehren. Durch Nachrichtentransformation und das Hinzufügen weiterer Sicherheitsmerkmale auf Nachrichtenebene gestaltet sich auch die Schema-Validierung schwierig. Ausschließlich die Datentypen / Requests, die von einer WAF überprüft werden können, dürfen an diese übergeben werden. Andere Aufgaben, wie beispielsweise Content Inspection von verschlüsselten Nachrichten und die Überprüfung der Signatur müssen von der Lösung selbst durchgeführt bzw. an andere Lösungen zur Prüfung weitergeleitet werden. Die Übergabe von mutmaßlich ungültigen Daten (bspw. verschlüsselte SOAP-Nachrichten) würde zu einem Fehler führen und das Ergebnis wäre nicht verlässlich. Zudem besteht eine Kosten- und Administrationsproblematik beim herkömmlichen Einsatz von WAF. Durch die verteilte Systemstruktur in SOAUmgebungen würde es bedeuten, dass jeder Service durch eine WAF gesichert werden müsste. Dies ist bei einer Vielzahl verteilter Services nicht kosteneffizient, da für jeden Service-Provider eine dedizierte WAF bereitgestellt werden müsste. SOA-Lösungen müssen einen Service bereitstellen, der eine WAF für mehrere Services (in einer Domäne etc.) nutzbar macht.

Anti Virus (AV) Viren und Malware müssen selbstverständlich auch in einer SOA Berücksichtigung finden. SOA-spezifische Anforderungen an die AV-Lösung sind bspw. die Überprüfung von SOAP-Attachments. Des Weiteren gelten für Anti Virus-Lösungen ähnliche Rahmenbedingungen wie im Abschnitt Web Application Firewall beschrieben. Insbesondere Lizenz- und Betriebskosten lassen sich durch zentrale Anti Virus-Services deutlich senken. Beim Einsatz von Agenten ergeben sich Vorteile durch die Möglichkeit der Modellierung von Virus-Prüfungen innerhalb einer gesamten Security-Logik. 71

SOA-Security: Webservices erfordern zusätzliche Sicherheitsmaßnahmen

6.4 Methoden zur Umsetzung Unternehmen können viele der bisher beschriebenen Ansätze und insbesondere offene Sicherheitsstandards manuell implementieren und umsetzen. Die WS-Security-Spezifikationen der Standards sind öffentlich zugänglich, und Entwickler können sie in die Applikationen integrieren. Problematisch wird ein solcher Ansatz allerdings bei einer Vielzahl von Services und eingebundenen Applikationen. Der Programmieraufwand bei technischen oder organisatorischen Prozessänderungen ist dann nicht mehr wirtschaftlich – schließlich muss der Sicherheitsteil jeder Applikation neu angepasst und getestet werden. Ein solches Vorgehen steht im Gegensatz zu den ursprünglichen SOA-Prinzipien und würde die Vorteile einer flexiblen Infrastruktur zunichte machen. Ein weiterer Nachteil einer manuellen Umsetzung ist sicherlich die fehlende Beherrschbarkeit des Gesamtsystems, weil keine zentrale Administration und auch nur schlechte Möglichkeiten des Reportings und Audits vorhanden sind. Das bedeutet, Anwender müssen in der Lage sein, Sicherheitsmechanismen ebenso flexibel zu modellieren, zu managen und auszurollen wie die serviceorientierte Infrastruktur selbst. Zur Umsetzung solcher und weiterer Anforderungen bietet sich ein Framework-Ansatz an, der das SecurityDesign, die Einführung sowie die Verteilung und den Betrieb von Security-Mechanismen unterstützt. Ein auf offenen Standards basierendes Framework in Verbindung beispielsweise mit einem Plugin-Adapter-Konzept ist in der Lage, die benötigte Flexibilität der Sicherheitsmechanismen umzusetzen. Security-Funktionalität, Standards und Erweiterungen (wie Integrationsfunktionen) werden über Plug In-Adapter geladen und stehen systemweit zur Verfügung.

www.hessen-it.de

Security als Service Zudem bietet es sich an, Sicherheitsfunktionalität selbst als Service anzubieten. Dabei wird die Funktionalität SOA-konform in Services gekapselt und zur Verfügung gestellt. Dies kann zentrale Administrationsdienste umfassen, beispielsweise Identity-Management oder -Modellierung, ebenso wie die Umsetzung am Policy Enforcement Point (zum Beispiel Verschlüsselungen, Authentifizierung). Als Service können auch Dienste für die Nutzung von herkömmlichen Security-Lösungen in SOA-Umgebungen realisiert werden. Über standardisierte Schnittstellen (Web Services, SOAP) können diese von sämtlichen Systemen genutzt und anforderungsgerecht skaliert werden. Die Implementierung als Service Provider erlaubt systemweit oder innerhalb von Domänen Sicherheitsmechanismen, wie beispielsweise Anti Virus, Signatur, Public Key Infrastruktur, zu nutzen.

Architekturansätze Ein Ansatz für ein Sicherheits-Framework benötigt zentrale Komponenten, wie zum Beispiel eine Administration, aber auch lokale Laufzeitumgebungen, in denen Sicherheitslösungen lokal umgesetzt werden. In verteilten Umgebungen ist ein zentrales Management der Sicherheitsinfrastruktur notwendig. Es bedarf einer systemweiten Security Policy, die verteilt und umgesetzt werden muss. Besondere Beachtung sollte dabei der Integration bestehender Systeme geschenkt werden, um vorhandene Benutzer, Rollen und Rechte oder auch Zertifikate im SOA-Kontext nutzbar zu machen. Der Architekturansatz einer lokalen Sicherheitslaufzeitumgebung hat einen großen Einfluss auf die Anwendbarkeit von Sicherheitslösungen in einer SOA. Die Umsetzung kann durch verschiedene Architekturansätze erfolgen: Es lässt sich zwischen lokalen und domänenweiten Security Services unterscheiden. Lokale Services setzen Sicherheitsfunktionen außerhalb der Applikationen und Services um.

SOA-Security: Webservices erfordern zusätzliche Sicherheitsmaßnahmen

Security Service

Service

Security Service

Service

Die lokale Security-Laufzeitumgebung übernimmt den unveränderten Web Service der Applikation und sichert diesen on-the-fly nach vorgegebenen Security-Regeln ab. Auf der Empfängerseite überprüft der Security Service den empfangenen, gesicherten Web Service und stellt den Urzustand wieder her.

Die lokalen Laufzeitumgebungen agieren somit als automatisierte Proxies, um Sicherheitsfunktionalität aus der Applikation zu nehmen. So kann beispielsweise die in der Policy definierte Verschlüsselung eines Elements (XML-Encryption) außerhalb der Applikation durchgeführt werden.

Service Consumer

Service

Domain Security Service

Der zentralisierte Security Service bietet die Sicherheitsüberprüfung als Service, z. B. das Scannen nach Viren in Attachments.

www.hessen-it.de

Domänenweite Services bieten dafür Sicherheitslösungen, wie beispielsweise Virenscanner als Sicherheitsdienst an. Der Vorteil dieser Konzepte ist die einfache Implementierung, der Nachteil liegt in einer schlechten Performance. Diese Implementierung eignet sich daher für zeitunkritische Prozesse oder Sicherheitslösungen, in denen der Performance-Nachteil gegenüber dem eigentlichen Scan-Prozess zu vernachlässigen ist oder durch Hardwareinvestitionen ausgeglichen werden kann.

6.5 Fazit Die Implementierung einer sicheren SOA-Infrastruktur ist keine triviale Aufgabe. Neben neuen notwendigen Sicherheitsmethoden, die die Sicherheit auf Nachrichtenebene gewährleisten, bestehen auch bei traditionellen Techniken (wie z. B. Antivirus-Lösungen) neue Anforderungen. Unternehmen benötigen leistungsstarke Werkzeuge, mit denen diese und weitere Anforderungen wie Policy-Administration, Workflows für Verteilung und Orchestrierung automatisiert umgesetzt werden müssen. Sicherheitsanforderungen wie Authentizität, Vertraulichkeit, Integrität und Verbindlichkeit können mit der konsequenten Anwendung standardisierter WS-Security Mechanismen gelöst werden. Für Bedrohungen wie SQLInjections, DoS-Attacken im SOA-Umfeld sollte eine servicekonforme Nutzung vorhandener Lösungen möglich sein. Ein Ansatz mit einem Security-as-a-Service-Konzept bietet diese Möglichkeiten. Unternehmen können einen Security Service effizient und anforderungsgerecht entweder lokal außerhalb der Applikation oder auch als domänenweiten Service implementieren. Eine zentrale Orchestrierungsund Management-Plattform mit breiten Integrationsmöglichkeiten liefert Unternehmen die Möglichkeit, vorhandene Lösungen (etwa Metadirectories, PKI) weiterhin im SOA-Umfeld zu nutzen. In Verbindung mit leistungsstarken Modellierungswerkzeugen und vorkonfigurierten Workflows ist die Automatisierung von SOA-Security effizient umzusetzen.

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 Automobilindustrie verdeutlichen, in der verschiedene Fahrzeugmodelle baugleiche Komponenten teilen. Bei der konzernübergreifenden Kleinwagenplattform mit den Modellen Citroën C1, Peugeot 107 und Toyota Aygo beträgt der Anteil an Gleichteilen ungefähr 60 %. So einleuchtend die Kernidee einer SOA jedoch ist, so herausfordernd sind die Fragen, denen sich IT-Verantwortliche derzeit stellen müssen: Was heisst SOA denn konkret? Und wo fängt man am besten an? Aus Risiko- und Kostenüberlegungen ist es sicherlich nicht zu empfehlen, bewährte IT-Systeme mit SOA komplett umzukrempeln oder gar vollständig in Services zu zerlegen. Es gilt also, die Bereiche zu identifizieren, in denen die gewachsen Systemlandschaften an ihre Grenzen geraten. Mögliche Symptome dafür sind ein „Wildwuchs“ an Systemen, welche die steigenden Anforderungen der Fachbereiche nicht mehr erfüllen können.

j rze

ot -F

ia.

www.hessen-it.de

B2B-Architekturen als Ansatzpunkt für SOA Einer der erfolgversprechenden Ansatzpunkte für SOA ist an den Unternehmensgrenzen zu finden. Überall dort, wo die Verzahnung mit Geschäftspartnern enger wird, steigt der Bedarf an elektronischer Kommunikation und Prozessintegration über die Unternehmensgrenzen hinweg. Amazon gehört zu den erfolgreichen Beispielen, die durch SOA und Web Services ihr Partnernetzwerk enger an sich binden und neue Einnahmequellen erschließen. In der Automobilindustrie lassen sich solche Ansatzpunkte für SOA ebenfalls ausmachen: Im Zuliefernetzwerk steigt der überbetriebliche Integrationsbedarf bedingt dadurch, dass Hersteller ihre Wertschöpfungstiefe reduzieren und Zulieferer ganze Produktions- und Entwicklungsumfänge übernehmen. Auf der Vertriebsseite wird die überbetriebliche Integration ebenfalls immer wichtiger, um dem weltweiten Händlernetzwerk Produktinformationen verfügbar zu machen oder OnlineServices zur Werkstattunterstützung anzubieten. In beiden Bereichen wird massiv in IT investiert, was sich in den entsprechenden Projektportfolios der Automobilunternehmen zeigt. Gleichzeitig wird auch deutlich, dass individuelle Punkt-zu-Punkt-Schnittstellen an ihre Grenzen stoßen. Das bedeutet, dass in Zukunft leistungsfähigere Integrationsarchitekturen aufgebaut werden müssen. Im Folgenden wird vor allem von SOA-Potenzialen für die Koordination entlang der Zulieferkette die Rede sein. Die vorgestellten SOA-Ideen wurden im Rahmen der Initiative „SOA in Automotive“ erarbeitet. Neben einem Forscherteam waren verschiedene Automobilhersteller und -zulieferer (u. a. BMW, Hella KgaA, Magna Steyr, Siemens VDO, ZF), die Branchenplattform SupplyOn sowie weitere Technologieanbieter (u. a. SAP, IBM, BEA) beteiligt. Das SOA-Konzept wurde in Form einer Zielarchitektur für die servicebasierte B2B-Kooperation konkretisiert und anschließend durch einen Piloten erprobt.

SOA goes B2B: Lessons Learned aus der Automobilindustrie

Heterogenität als Problemstellung der B2B Unternehmen-zu-Unternehmen (B2B)-Integration war und ist in der Automobilindustrie stark mit dem Einsatz von Electronic Data Interchange (EDI) verbunden. Obwohl alle Großunternehmen eine EDI-Infrastruktur aufgebaut haben und diese immer noch erweitern, bleibt deren Anwendung auf wenige stark strukturierte Geschäftsdokumente in der Logistik, wie z. B. Lieferabrufe, Lieferavis und Bestellung, beschränkt. Hersteller und Zulieferer nutzen zunehmend die vielfältigen Möglichkeiten des Internets, um den Koordinationsbedarf entlang des kompletten Produktlebenszyklus – vom ersten Fahrzeugkonzept über Produktentwicklung und Produktion bis hin zur Produktnutzungsphase mit anschließender Entsorgung und Recycling – zu decken. An erster Stelle sind hier die Lieferantenportale – wie z. B. BMW Group Partner Portal oder VWGroupSupply.com – zu nennen. Diese haben sich zu sehr mächtigen Plattformen entwickelt und integrieren oft zahlreiche interne Applikationen, über die Geschäftspartner z. B. aktuelle

Qualitätskennzahlen abrufen oder Reklamationen bearbeiten können.

www.hessen-it.de

Die Portallösungen stellen zwar eine komfortable Lösung für die Betreiber-, nicht aber für die Lieferantenseite dar. Große Zuliefererunternehmen, die ihre internen Prozesse professionell durch IT-Lösungen unterstützen, müssen im Schnitt 30 bis 50 Portale bedienen. Portale sind für sie zeitund kostenaufwändige Mensch-Maschine-Schnittstellen, die einen hohen Monitoringaufwand und fehleranfällige redundante Datenpflege verursachen. Angesichts der immer weiter steigenden Anzahl von Portalen, die selbst oft mehrere hundert Anwendungen umfassen, sehen sich die Zulieferer einem „Portaldschungel“ gegenüber. Im Vergleich zur Popularität der Portale konnte sich der XML-basierte Nachrichtenaustausch in der Automobilindustrie bisher noch vergleichsweise wenig durchsetzen. Eine Ausnahme ist der auf XML basierende QDX-Standard für das überbetriebliche Qualitäts- und Reklamationsmanagement. Entsprechende B2B-Integrationsprojekte werden in der Regel als Einzelprojekt auf Anforderung eines Fachbereiches oder eines externen Partners realisiert. Diese Projekte erfordern erhebliches Integrationswissen und die Realisierung von Schnittstellen. Zusätzlich sind partnerspezifische Anforderungen zu berücksichtigen, so z. B. die Vorgaben eines Automobilherstellers an seine Zulieferer in Bezug auf Datenformate und -qualität. Eine aktuelle Studie von Supply On zeigt einen stark anwachsenden Anteil digitaler Prozesse – bei zunehmender Vielfalt der eingesetzten e-BusinessPlattformen. Berücksichtigt man die enorme Komplexität und die Kosten beim Aufsetzen elektronischer Prozesse, so besteht erheblicher Handlungsbedarf.

SOA goes B2B: Lessons Learned aus der Automobilindustrie

7.2 SOA-B2B-Architektur: Öffentliche und interne Sicht Aufbau der serviceorientierten B2B-Zielarchitektur Die steigende Vielfalt und Heterogenität der elektronischen Integrationsbeziehungen wird in Zukunft nur durch eine sorgfältig geplante B2BArchitektur zu bewältigen sein. Serviceorientierte Architekturen liefern hier zunächst die technischen Grundlagen für den automatisierten Datenaustausch von strukturierten und unstrukturierten Inhalten in überbetrieblichen Geschäftsbeziehungen. Durch sie lassen sich sowohl die klassische nachrichtenbasierte Integration, wie im Falle von EDI, als auch eine prozessorientierte Integration über Workflows und der Austausch von schwach strukturierten Dokumenten oder deren Anzeige in Portalen realisieren. Sie eignen sich daher auch für den Einsatz in weniger hochvolumigen und strukturierten Kooperationsprozessen, wie z. B. in der Produktentwicklung oder im Qualitätsmanagement. SOA ist jedoch noch lange kein Produkt, dass sich „out-of-the-box“ einführen lässt. Vielmehr erfordert SOA grundsätzliche Überlegungen, wie eine B2B-Architektur auszugestalten ist. Es gilt beispielsweise zu bewerten, welche Funktionalität künftig als Service zu realisieren ist, um so wiederverwendet oder schneller zu neuen Prozessvarianten konfiguriert zu werden. Es ist auch prinzipiell zu überlegen, wie man über Unternehmensgrenzen über Services interagiert und welche Services ein Partner nutzen darf. Diese Überlegungen wurden im Rahmen von „SOA in Automotive“ in einer Zielarchitektur konkretisiert (vgl. Abbildung unten). Ein wichtiges Hilfsmittel ist die Unterscheidung in eine öffentliche Sicht („Public“) und in eine interne Sicht („Private“). Während die öffentliche Sicht über die verschiedenen Geschäftspartner hinweg abzustimmen ist und die überbetriebliche Prozessintegration umfasst, betrachtet die interne Sicht die interne Umsetzung innerhalb eines Unternehmens. So wird der Anforderung Rechnung getragen, dass interne Prozessabläufe und Systemlandschaften verschiedener Partner unabhängig voneinander entworfen und geändert werden.

www.hessen-it.de

Automobilhersteller

Zulieferer

Private

Public

Prozessarchitektur

Prozess

Prozessarchitektur

Servicebeschreibung

(SOA-basierte) Integrationsarchitektur

System

Desktopintegration

Serviceverzeichnis

Workflow

Private

WSDL Semantik

BusinessServices App.Services

Serviceverzeichnis

(SOA-basierte) Integrationsarchitektur Desktopintegration Workflow BusinessServices App.Services

Nachrichten

Applikationsarchitektur

Infrastrukturarchitektur

System

Private

Abbildung : Serviceorientierte B2B-Architektur

Öffentliche Sicht: SOA ermöglicht m:n-Fähigkeit Zentrale Bestandteile einer SOA sind (Web) Services, die gekapselte Geschäftslogik als selbstbeschreibender Service zur Verfügung stellen. Nutzt man Services in Beziehungen mit externen Geschäftspartnern, so können diese schnell und ohne großen bilateralen Abstimmungs- und Realisierungsaufwand über wohldefinierte Schnittstellen elektronisch interagieren. Eine SOA hat damit das Potenzial, die Vielfalt und Heterogenität in B2B-Integrationsbeziehungen einzudämmen. Voraussetzung dafür ist m:n-Fähigkeit, d. h. dass beliebige (m) Lieferanten mit beliebigen (n) Kunden die „gleiche Sprache“ an den Prozess- und Systemschnittstellen sprechen. M:n-Fähigkeit reduziert die derzeitige Vielfalt überbetrieblicher Prozessvarianten auf ein sinnvolles und beherrschbares Maß und führt dazu, dass der Abstimmungs- und Integrationsaufwand beim Aufbau elektronischer Kooperationen erheblich sinkt. 81

SOA goes B2B: Lessons Learned aus der Automobilindustrie

Die Web Service-Standards, die einer SOA zugrunde liegen, nutzen offene Internet-Standards (XML, SOAP, WSDL) und sichern so eine höhere Plattformunabhängigkeit und Interoperabilität. Sie liefern dadurch bereits einen erheblichen Mehrwert gegenüber früheren, sehr viel stärker proprietären Technologien wie EDI. Allerdings reichen das von den Herstellern propagierte techniklastige Service-Verständnis und die rein technische Interoperabilität von Web Services nicht aus. Überbetriebliche elektronische Vernetzung funktioniert mit SOA nur, wenn alle Partner Web Services mit gleicher Semantik verwenden, d. h. sich auf ein fachliches Service-Design einigen. Die große Herausforderung liegt dabei in der betriebswirtschaftlichen Service-Definition sowie in der Verwendung standardisierter Web Service-Signaturen. Idealerweise ergänzen also Fachstandards die technische Standardisierung von Web Services. Im Rahmen von „SOA in Automotive“ wurde die VDA-Empfehlung 4965 für das technische Änderungsmanagement in m:n-fähige Prozesse und Services überführt. Als Teil der unternehmensübergreifenden Produktentwicklung (Collaborative Engineering) umfasst das Änderungsmanagement die Bewertung und Entscheidung von Änderungsideen sowie die Umsetzung von Änderungen in gemeinsamen Entwicklungs-, Planungs- und Fertigungsprozessen. Dazu wurde ein „ECR Public Process“ (ECR = Engineering Change Request) als ereignisgesteuerte Prozesskette mit Erweiterungen in ARIS dokumentiert. Diese umfassende Dokumentation des öffentlichen Prozesses schafft ein gemeinsames Verständnis über zwischenbetriebliche Prozessabläufe und erweitert damit die herkömmliche Standardisierung um den Prozesskontext. Gleichzeitig bietet der „Public Process“ den Geschäftspartnern klar definierte Anbindungspunkte für ihre jeweiligen internen Prozesse („Private Processes“) und ihre interne Prozessdokumentation. Der „ECR Business Service“ setzt die Prozessinteraktion auf Systemebene um. Automobilhersteller und -zulieferer können so ihre Prozesse im Änderungsmanagement durch Serviceaufrufe elektronisch koppeln.

www.hessen-it.de

Interne Sicht: SOA erleichert die Anbindung an überbetriebliche Prozesse Während SOA also Geschäftspartnern ermöglicht, über wohldefinierte Schnittstellen zu interagieren, adressieren serviceorientierte Ansätze noch weitere Schwachpunkte der bisherigen B2B-Integrationslösungen. In einer SOA wird Funktionalität, die in vielen B2B-Integrationsprojekten benötigt wird, als Service realisiert. Sie wird also nicht redundant implementiert, wie es angesichts der projektgetriebenen Umsetzung von B2BIntegrationslösungen häufig der Fall ist. Solche Services stellen in B2BArchitekturen insbesondere Basisfunktionalitäten zur Verfügung, wie die Authentifizierung bzw. Autorisierung von externen Partnern oder die Validierung von XML-Nachrichten. Neben der Wiederverwendung erleichtert SOA generell auch das Anbinden der internen Prozesse und Systeme an die externen Schnittstellen. Durch Konvergenz der Plattformen für B2BIntegration und Enterprise Application Integration (EAI) lassen sich überbetriebliche Serviceaufrufe eng mit den internen Workflows koppeln, die eine Weiterverarbeitung und Integration in die entsprechenden internen Backendsysteme sicherstellen. Im Vergleich zu den traditionellen Formen der B2B-Integration können nicht nur die Transaktionssysteme (Enterprise Resource Planning- oder Supply Chain Management-Systeme), sondern auch Dokumenten- bzw. Content Management Systeme und Reportingsysteme (Data Warehouses) eingebunden werden. SOA erlaubt insbesondere ein verbessertes Prozesshandling, -Routing und -Monitoring. Auch die individuelle Anpassung an partnerspezifische Besonderheiten, wie z. B. Prozessvarianten oder Nachrichtenformate, fällt sehr viel leichter. Diese wird es – auch wenn die fachliche Standardisierung Fortschritte macht – sicherlich weiterhin geben.

SOA goes B2B: Lessons Learned aus der Automobilindustrie

Diese Aspekte wurden in der Zielarchitektur aus „SOA in Automotive“ für das technische Änderungsmanagement weiter ausgearbeitet: Im Unternehmen wurde dabei von der bestehenden Landschaft aus zumeist heterogenen Anwendungssystemen ausgegangen, die für die fachliche Verarbeitung von Änderungsanträgen zuständig sind. Diese Systeme werden in der Schicht der domänenspezifischen Anwendungsdienste (Application Service) als Web Services bereitgestellt, um eine prozessorientierte Integration zu ermöglichen. Darüber hinaus werden Hilfsdienste, so genannte Utility Services, entwickelt, die mehrfach benötigte domänenübergreifende Funktionalität realisieren. Innerhalb eines Workflows werden die vorhandenen Dienste aufgerufen und miteinander verschaltet. Mit Hilfe einer Frontend-Integration kann auch die Benutzer-Interaktion in die Prozesse mit einbezogen werden. Damit lassen sich z. B. MenschMaschine- und Maschine-Maschine-Schnittstellen mit der gleichen Integrationsinfrastruktur realisieren.

7.3 SOA vs. herkömmliche B2B-Integration Die hier skizzierte SOA für eine überbetriebliche Vernetzung ist derzeit noch eine Vision. Allerdings konnte sie im Projekt „SOA in Automotive“ bereits für die Zusammenarbeit zwischen Automobilherstellern und – zulieferern durchgespielt werden. Dies erlaubt mindestens einige Schlussfolgerungen in Bezug auf die Potenziale, aber auch auf die Herausforderungen bei der Umsetzung in Produktivumgebungen. Vergleicht man den servicebasierten Ansatz mit einer Realisierung über Lieferantenportale, so liegt der Nutzen einer SOA in der Vermeidung von Medienbrüchen und manueller Informationsbereitstellung sowie weniger Schulungsaufwand für die Nutzer. Im Beispiel bearbeiten die Mitarbeiter auf Zulieferseite Änderungsanträge in den bestehenden Änderungsmanagementsystemen, anstatt sie zusätzlich in Lieferantenportalen zu erfassen. Dadurch entfällt Aufwand für die Informationsbereitstellung, der im konkreten Fall auf 0,75 Tage geschätzt wurde. Andere Formen der elektronischen Integration (z. B. EDI in Form von bilateralen Punkt-zu-Punkt-Verbindungen und standardisierter Nachrichtenaustausch ohne Prozessstandardisierung) weisen zwar ähnliche Vorteile wie der servicebasierte Ansatz

www.hessen-it.de

bzgl. des Koordinationsaufwands in den Geschäftsprozessen auf. Jedoch liegt im Vergleich zu diesen der Mehrwert des servicebasierten Ansatzes in geringeren Aufwendungen für den Aufbau der elektronischen Prozessintegration. Hierbei kann die Realisierung des „ECR Business Service“ auf bestehenden Infrastruktur- und Middlewarekomponenten erfolgen, die bereits für die innerbetriebliche Integration genutzt werden. Es ist folglich keine parallele B2B-Infrastruktur, wie z. B. im Fall von EDI, erforderlich. Auch aufgrund der gegenwärtigen Anstrengungen aller Softwareanbieter ist von einem schnellen SOA-Enabling bei Standardsoftwarepaketen auszugehen, so dass sich eine servicebasierte Kopplung von Geschäftsprozessen in Zukunft wesentlich kostengünstiger realisieren lässt. Gegenüber reinen Nachrichtenstandards und Schnittstellendefinitionen (z. B. in EDI- oder XML-Syntax) ermöglichen serviceorientierte Ansätze eine stärkere fachliche Spezifikation von Services, die nicht nur die Nachrichten (Semantik) selbst, sondern auch die Prozessinteraktion (Pragmatik) abdeckt. Weiterhin sieht ein gutes Service-Design zusätzliche Erweiterungskonzepte auf der Nachrichtenebene vor, so dass partnerspezifische Anpassungen einfacher realisiert werden können. Außerdem können häufig benötigte Funktionen für die prozessübergreifende Integration (z. B. Logging, Authentifizierung) in einer serviceorientierten Architektur als wieder verwendbare Utility Services realisiert werden. Durch eine servicebasierte Kooperationsarchitektur lassen sich folglich Integrationsbeziehungen mit mehreren Partnern und über mehrere Prozesse hinweg auf Basis einer einheitlichen Integrationsarchitektur umsetzen und gleichzeitig flexibel und skalierbarer gestalten.

SOA goes B2B: Lessons Learned aus der Automobilindustrie

7.4 Reifegrad und Herausforderungen SOA-Konzepte und Web Service-Technologien haben mittlerweile die notwendige Reife für den produktiven Praxiseinsatz in B2B-Kooperationen erreicht. Die Erfahrungen aus „SOA in Automotive“ zeigen, dass Web Services sich auf Basis der bestehenden Middlewareplattformen in Unternehmen innerhalb von wenigen Tagen implementieren lassen. Auch die unternehmensübergreifende Interoperabilität wird weitgehend problemlos erreicht. Einen großen Anteil daran haben die sog. WS-I Profile, die frühere Interoperabilitätsprobleme zwischen verschiedenen Herstellern beseitigt haben und Interpretationsspielräume der WS-Standards effektiv eingrenzen. Sie decken auch weitergehende Anforderungen im Bereich Sicherheit (mit dem WS-I Basic Security Profile) und Zuverlässigkeit (WS-I Reliable Secure Profile) ab. Die heutigen Middlewareplattformen beinhalten bereits eine komplette technische Infrastruktur zur Realisierung einer SOA. Kernelement bildet der Service Bus, der Serviceaufrufe an den richtigen Serviceanbieter weiterleitet und diese Weiterleitung auch garantiert. Des Weiteren realisiert der Service Bus Fehlerbehandlungsmechanismen für fehlgeschlagene Serviceaufrufe, z. B. durch Benachrichtigung des Serviceaufrufenden, Mechanismen zur technischen Transformationen (z. B. mit XSLT) oder semantische Mappings (z. B. Purchase Orders von RosettaNet nach SAP).

Auf der Basis der in den Unternehmen eingesetzten Middlewareplattformen lassen sich B2B Web Services innerhalb von wenigen Tagen realisieren.

www.hessen-it.de

Allerdings machen die Erfahrungen aus „SOA in Automotive“ auch deutlich, dass es noch einige Hürden auf dem Weg hin zu einer serviceorientierten B2B-Architektur gibt – auch, wenn man die menschlichen Voraussetzungen und das Change Management zunächst noch unberücksichtigt lässt. Eine wichtige Voraussetzung für die erfolgreiche Umsetzung einer SOA ist der Zugriff auf die benötigte Funktionalität in den Anwendungssytemen über geeignete Servicesschnittstellen. Fehlen diese, so müssen im Rahmen eines SOA-Enabling entsprechende Serviceschnittstellen zunächst realisiert werden. Im konkreten Beispiel stellte dies den größten Aufwandstreiber für eine durchgängige B2B-Lösung, und manchmal sogar ein unüberwindbares Hindernis, dar und hat letztendlich auch eine kurzfristige Umsetzung der Zielarchitektur im überbetrieblichen Änderungsmanagement verhindert. Im Projekt zeigte sich, dass die eingesetzten Änderungsmanagementsysteme – auch die Standardsoftwarepakete – bisher nicht über eine geeignete Serviceschnittstelle verfügten. Ein SOAEnabling wäre zwar bei allen Projektpartnern möglich gewesen, sie wurde jedoch wegen des erheblichen Aufwands in diesem Projekt nicht durchgeführt. Zu betonen ist, dass dieser Aufwand prinzipiell bei jeglicher elektronischen Kopplung von Applikationen besteht und damit nicht SOA-spezifisch ist, sondern in ähnlicher Form bei vielen B2B-Integrationsprojekten beobachtet werden kann. Wenn sich serviceorientierte Architekturen weiter durchsetzen, wird sich dieser Aufwand jedoch nach und nach reduzieren, da Anwendungssysteme künftig ihre Funktionalität als Service bereitstellen. Allerdings zeigt die Erfahrung aus „SOA for Automotive“ auch, dass B2B-Integration nur dann reibungslos funktioniert, wenn einheitliche fachliche Service-Spezifikationen („Semantik“) existieren und die öffentlichen Prozesse spezifiziert sind. An dieser Stelle besteht aktuell dringender Handlungsbedarf. Es ist also notwendig, branchenweit akzeptierte Prozess- und Servicedefinitionen zu definieren und zu implementieren, um so die Potenziale der Serviceorientierung in der B2B-Integration in vollem Umfang zu nutzen.

SOA goes B2B: Lessons Learned aus der Automobilindustrie

7.5 Fazit Die zunehmende Reife serviceorientierter Architekturen ermöglicht es, leistungsfähige Prozessplattformen für die B2B-Integration zu realisieren. Diese sind in der Lage, die bestehenden und künftigen Anforderungen abzudecken und bergen im Vergleich zu den existierenden Einzellösungen erhebliche Vorteile: a Prozessplattformen unterstützen die verschiedenen B2B-Kanäle (Maschine-Maschine und Mensch-Maschine) dadurch, dass der Zugriff auf Services sowohl über ein Portal als auch über einen plattform- und organisationsübergreifenden Web Service-Aufruf erfolgen kann. a Durch Nutzung von XML und Web Services können Prozessplattformen ein breites Spektrum an Integrationsszenarien abdecken. Im Gegensatz zu nachrichtenbasierten (EDI-) Ansätzen sind sie in der Lage, komplexere (Multi-Step) Prozesse abzubilden. Sie sind daher geeignet, weniger hochvolumige und strukturierte Prozesse zu unterstützen. a Prozessplattformen entkoppeln die Prozess- von der Anwendungslogik. Mittels Orchestrierung (innerbetrieblich) bzw. Choreographie (überbetrieblich) von Web Services verschalten sie lediglich Anwendungsfunktionen und beschleunigen so die Umsetzung neuer Prozessvarianten. Ein Prozessvorlagen-Repository enthält Templates für „Public Processes“, die partnerspezifisch angepasst werden können. a Durch Konvergenz der Plattformen für B2B-Integration (B2Bi) und Enterprise Application Integration (EAI) lassen sich überbetriebliche Serviceaufrufe eng mit den internen Workflows koppeln, die eine Weiterverarbeitung und Integration in die entsprechenden internen Backendsysteme sicherstellen. Letztere umfassen Transaktionssysteme (ERP, SCM, …) ebenso wie Dokumenten- bzw. Content Management Systeme und Managementinformationssysteme (Data Warehouses). a Basis-Services für die überbetriebliche Prozessintegration, wie z. B. Authentifizierung von Geschäftspartnern, Logging, usw., können zentral bereitgestellt und in verschiedenen Kooperationsbeziehungen wieder verwendet werden. Diese Services können auch auf einfache Weise von externen Spezialisten bezogen werden. 88

www.hessen-it.de

Aktuelle Herausforderungen in B2B-Netzwerken

Was bringt SOA?

Wo liegen Herausforderungen bei der SOA?

Starker Zuwachs digitaler Prozesse von der Produktentwicklung über die Produktion bis hin zu Garantie, Service und Entsorgung

m:n-Fähigkeit in überbetrieblichen Prozessen:

Fachliche Service-Spezifikation („Semantik“): z. B. Ergänzung von Fachstandards (VDA, Odette, …) durch Spezifikation von (Web) Services und deren Choreographie

Vielfalt der Partner, Prozessvarianten und eingesetzten Technologien

a Nutzung offener, kostengünstiger und weit verbreiteter Internet-Technologien a Geringerer Abstimmungs- und Integrationsaufwand durch Services als wohldefinierte Schnittstellen für externe Partner a Dokumentation der Services in einem Service-Repository mit externen Sichten

Realisierung von B2B-Integration als Einzellösung auf Anforderung eines Fachbereiches oder Partners Vielfalt der e-Business-Plattformen (Portale, XML-Nachrichtenaustausch, EDI, …) Aufwände für die Anbindung interner Systeme an unterschiedliche e-Business-Plattformen

Skalierbare, flexible e-BusinessPlattform im Unternehmen a Konvergenz der Plattformen für B2B-Integration (B2Bi) und Enterprise Application Integration (EAI) a Unterstützung sämtlicher Varianten der B2B-Integration: nachrichtenbasiert (EDI, XML), prozessorientiert (Workflows), benutzerorientiert (Portale)

Überbetriebliche (Referenz-)Prozesse als Grundlage der elektronischen Integration: „Public Processes“, z. B. in der Produktentwicklung, im Qualitäts- oder Reklamationsmanagement

Konzeption einer SOA-basierten B2B-Zielarchitektur für das Unternehmen Schrittweise Umsetzung im Sinne der B2B-Zielarchitektur SOA-Enabling der Anwendungssysteme

a Wiederverwendung von BasisServices (z. B. Authentifizierung, Validierung) a Workflows zur Weiterverarbeitung von externen Serviceaufrufen und Integration in die entsprechenden internen Backendsysteme a Änderbarkeit und Anpassungsfähigkeit an partnerspezifische Anforderungen (Datenformate, Prozessvarianten)

SOA als Grundlage zukunftsfähiger B2B-Architekturen

SOA-Perspektiven: Geschäftsmodelle und Innovationen für das Internet der Dienste

Tobias Conte, Dr. Carsten Holtmann, Benjamin Blau FZI Forschungszentrum Informatik

8.1 Internet der Dienste Unternehmen müssen kontinuierlich Antworten auf die Herausforderungen ihrer jeweiligen Umwelt finden – in der Art, wie sie das tun und wie sie ihre Wertschöpfungsbeziehungen organisieren lassen sich Muster erkennen: In den 70er und 80er Jahren waren Wertschöpfungsaktivitäten tendenziell eher „hart verdrahtet“. Unternehmen strebten es an, möglichst viele der notwendigen Aktivitäten selbst und integriert anzubieten. Dies wurde als Ära der vertikalen Integration bekannt. Ende der 80er Jahre begann man dann, sich stärker zu spezialisieren. Einzelne Prozesse wurden über Unternehmensgrenzen hinweg ausgelagert und Wertschöpfungsketten und -beziehungen begannen, feingranularer zu werden. Heute und voraussichtlich in der Zukunft schreitet dieser Trend weiter fort: Unternehmen fokussieren sich auf die Spezialaktivitäten, in denen sie echte Kernkompetenzen besitzen und global wettbewerbsfähig sind, in anderen Bereichen stützt man sich auf die Kompetenzen von Partnern. Unternehmen versuchen, ökosystemartige Umgebungen verbundener Partner um sich zu gruppieren und die Wertschöpfung erfolgt damit weniger in definierten Ketten als vielmehr in Netzen, den so genannten „Service Value Networks“ (siehe Abbildung).

www.hessen-it.de

Hartverdrahtete Wertschöpfungsketten

Spezialisierung und Konsolidierung

Agile Service Value Networks

Von hartverdrahteten Wertschöpfungsketten zu agilen Service Value Networks

Notwendig wird diese flexible Zusammenarbeit u. a. durch den globalen Wettbewerbsdruck, ermöglicht wird sie durch die serviceorientierten IT-Paradigmen. Die Idee ist, dass man auf dieser Basis innerhalb von Netzwerken Geschäftsprozesse agil und dynamisch zusammenfügen kann. Die Softwarebranche ist selbst ein Pionier in diesem Bereich. Die Unternehmen wandeln ihre Softwareprodukte nicht nur in Software-as-a-Service (SaaS)-Angebote um, sie beginnen auch damit, in Service Value Networks gemeinsam mit spezialisierten Partnern komplexe Dienste anzubieten. Aus der Gesamtheit solcher und ähnlicher, teilweise untereinander verknüpfter Servicenetzwerke wird die Entwicklung einer Infrastruktur erwartet, die auch als das „Internet der Dienste“ charakterisiert wird.

SOA-Perspektiven: Geschäftsmodelle und Innovationen für das Internet der Dienste

Revolution des Softwarevertriebes: Software-as-a-Service Neben der SOA-Entwicklung, die vornehmlich in Unternehmen Wirkung erzeugt, sind diverse weitere bedeutsam, die eine Revolution unternehmensübergreifender Leistungsprozesse möglich machen sollen. Allgemein lassen sich diese unter dem Begriff „X-as-a-Service“ zusammenfassen. Das „X“ kann dabei für Software, Infrastruktur und Plattform stehen, wobei erstere hier im Vordergrund steht. Bei Software-as-a-Service (SaaS) handelt es sich um ein Vertriebsmodell, mit welchem Anwendungen vom Service-Anbieter gehostet werden und über ein elektronisches Netzwerk wie das Internet den Konsumenten nach dem Prinzip „one-to-many“ zur Verfügung gestellt werden. „One-to-many“ bezeichnet dabei die Softwarenutzung durch mehrere Unternehmen parallel (Multiagentenfähigkeit) jeweils über das Internet. Eigentümer der Software bleibt in diesem Falle der Anbieter. Er ist es auch, der die Anwendung betreibt und zentral aktualisiert. Die Entwicklung hin zu SaaS kann auf einige Treiber und Gründe zurückgeführt werden. Zum einen sorgen fallende Transaktions- und Kommunikationskosten dafür, dass Anbieter Software betriebsfertig über das Internet anbieten und so Skaleneffekte nutzen können. In Verbindung mit den sinkenden Kosten bietet sich nun die Möglichkeit, bisher weniger erschlossene Märkte zu bedienen. Im Vergleich zu traditioneller Software bezahlen Kunden typischerweise keine einmalige Lizenzgebühr plus Wartungsgebühren, sondern eine Nutzungsgebühr pro Einzelnutzung („pay-per-use“) oder auf Periodenbasis („Subscription Fee“). Diese Preise beinhalten auch die vom Anbieter durchgeführten Updates. Während lizenzbasierte Geschäftsanwendungen aufgrund ihres Preises und ihrer Komplexität oftmals nur für große Unternehmen interessant waren, besteht nun die Möglichkeit, nutzungsbasiert oder auf periodischer Basis auch kleine und mittelständische Unternehmen (KMU) zu bedienen und so den oftmals gesättigten Markt der Großunternehmen zu erweitern. Für KMU werden On-Demand-Lösungen attraktiv, da sie bei Bedarf genutzt werden können, hohe Upfront-Investitionen für einmalige Lizenzen der Vergangenheit angehören bzw. Bedarfsschwankungen einfacher ausgeglichen werden können. Beispielsweise werden OnDemand-Applikationen als Mittelstandslösung angeboten, die ab 133 Euro monatlich bezogen werden kann (Stand 2009). 92

www.hessen-it.de

Entwicklungsstufen: Eine einfache Typologie Der Begriff „Internet der Dienste“ wurde bisher in der akademischen Welt noch nicht erschöpfend definiert, Impulse kommen hauptsächlich aus der industrienahen Forschung. Das Internet der Dienste folgt – einfach gesprochen – dem Gedanken, dass im künftigen Internet nicht nur primär Inhalte in Form von Webseiten verfügbar sein werden, sondern dass vielmehr Dienste (wie bspw. Google Maps) nutzbar sind, die Unternehmen und Privatanwendern Informationen zielgerichtet und damit personalisiert aufbereiten. Diese Dienste werden miteinander kombinierbar sein und können so zu komplexen Diensten zusammengefügt werden. Komplexe (oder zusammengesetzte) Dienste beinhalten typischerweise die Orchestrierung und den Aufruf mehrerer vorhandener Dienste. Diese können von unterschiedlichen Parteien kommerziell angeboten werden und letztendlich einen Geschäftsprozess abbilden.

Definition „Internet der Dienste“ Das Internet der Dienste ist ein globales Netzwerk, welches das Design, das Auffinden, das Kombinieren, den Handel und die Nutzung interoperabler, elektronischer Services im Web ermöglicht. (angelehnt an Papazoglou 2007)

Erste Schritte hin zu einem Internet der Dienste sind mit den allgemein bekannten Entwicklungen zu SaaS bereits getan, weitere weniger bekannte und komplexere Entwicklungen sind bereits zu beobachten und lassen sich mit der folgenden Typologie abgrenzen.

Grad der Interaktion

Ein (dominierender) Anbieter

Viele Anbieter

SOA-Perspektiven: Geschäftsmodelle und Innovationen für das Internet der Dienste

Aggretiertes Angebot einfacher Dienste über einen Marktplatz. Funktionale Integration wird nicht unterstützt.

Integriertes Angebot komplexer Dienste, die aus einfachen oder komplexen Teildiensten bestehen und über einen Marktplatz vertrieben werden.

Angebot einfacher Dienste durch einzelnes Unternehmen.

Angebot komplexer Dienste durch einzelnes Unternehmen.

1 3 2 4 Grad der Komplexität

Einfacher Dienst

Komplexer Dienst

Typologie von Business Services

Die bekannten Phänomene können in vier Quadranten klassifiziert werden, die sich anhand der Dimensionen aufspannen lassen: a Interaktionsgrad bei Erstellung und Angebot des Dienstes a Komplexitätsgrad des Dienstes / der Komposition Die Typologie grenzt demnach die Dienste nicht hinsichtlich ihres Typs „X-as-a-Service“ ab, sondern anhand ihrer Komplexität und ihres Kooperationsgrades über Unternehmensgrenzen hinweg.

www.hessen-it.de

Quadrant 1:

Einfache Dienste durch einzelne Anbieter

Die Vielfalt von als SaaS angebotenen einfachen Web Services ist heute schon riesig. Paradebeispiele sind die von Google offerierten Dienste wie z. B. GoogleMaps (http://maps.google.com ), einem Kartendienst, der mit wenigen Zeilen Code in Webseiten und Mash-Ups integriert werden kann, oder Google Docs (http://docs.google.com ) als sozusagen „webbasierte Office-Lösung“. Weitere Beispiele für einfache Web Services sind Amazons Simple Storage Service (S3) (http://aws.amazon.com/s3) und die Elastic Compute Cloud (EC2) (http://aws.amazon.com/ec2 ). Während S3 und EC2 kostenpflichtig sind, bietet Google seine GoogleMaps-Applikation kostenfrei an. Auch Unternehmen können sich kostenlos auf GoogleMaps eintragen.

Quadrant 2:

Einfache Dienste von Anbieterverbünden

Des weiteren entwickeln sich Web Service-Marktplätze wie Strikeiron (www.strikeiron.com ) oder Xignite (http://xignite.com ). Sie stellen anderen Service Providern eine Plattform zur Verfügung, auf der sie ihre kommerziellen Dienste über einen gemeinsamen Kanal vertreiben können. Solche Marktplätze bieten heute lediglich recht rudimentäre Infrastrukturdienste an. Bis auf einen Katalog der angebotenen Dienste, einem thematischen Clustering und einer Suchfunktion werden keine zusätzlichen, technisch ausgefeilten Infrastrukturdienste angeboten. Funktionale Integration wird beispielsweise ebenso wenig angeboten wie ein gemeinsames Monitoring.

SOA-Perspektiven: Geschäftsmodelle und Innovationen für das Internet der Dienste

Quadrant 3:

Komplexere Dienstkonfigurationen durch einzelne Anbieter

Es sind aber nicht nur einfache Dienste, die on-demand zur Verfügung gestellt werden. Auch Mehrwertdienste, die komplexe Geschäftsprozesse unterstützen, werden bereits über das Netz angeboten. Beispiele hierfür sind Salesforce.com (www.salesforce.com) und Netsuite Inc. (www.netsuite.com), die mit ihren vollständig webbasierten CRM-Lösungen den Markt der Geschäftsanwendungen revolutionierten. Einzelkomponenten dieser Anwendungen können dynamisch zu nutzerspezifischen Prozessen modelliert werden. Einen Schritt weiter in Richtung des vierten Quadranten geht AppExchange, der von Salesforce.com betriebene Marktplatz für On-DemandServices. Die Idee von AppExchange (www.salesforce.com/appexchange ) ist es, komplementäre Angebote um Salesforce CRM herum zu gruppieren, um die eigene Werthaltigkeit zu erhöhen. Hier werden nicht nur eigene, sondern vor allem Applikationen von Drittanbietern (Partner und freie Softwareentwickler) angeboten. Die offerierten Dienste sind voll integrierbar in Salesforce CRM. Jedoch handelt es sich dabei um Services, die auf eine Kernanwendung ausgerichtet sind und daher alle auf der Plattform force.com basieren. Dadurch wird die Integration beträchtlich erleichtert. Die von AppExchange angebotenen Infrastrukturdienste sind demnach zwar durch einen Plattformdienst erweitert, jedoch gibt es auch hier kein gemeinsames Monitoring oder eine gemeinsame Abrechnungskomponente für alle angebotenen zusammengesetzten Services.

www.hessen-it.de

Generell zielte SaaS bisher vor allem auf die kostengünstige Bereitstellung von isoliert stehenden Geschäftsanwendungen ab. Anbieter dieses oftmals „SaaS 1.0“ genannten Konzepts warben meist mit schneller Einführung und niedriger Total Cost of Ownership (TCO). Seit wenigen Jahren zeichnet sich allerdings eine Entwicklung in Richtung „SaaS 2.0“ ab, die man unter anderem in der Evolution des von Salesforce.com angebotenen Portfolios beobachten kann. 1999 startete das Unternehmen mit seiner isoliert stehenden Geschäftslösung Salesforce CRM. Seitdem hat Salesforce.com ein Ökosystem an Partnern um sich gruppiert, das das Kernprodukt mit komplementären Angeboten erweitert, die seit 2005 auf AppExchange angeboten werden. Diese Entwicklung spiegelt SaaS 2.0 wider. Software-as-a-Service-Lösungen sollen als integrierte Geschäftslösungen komplexe Geschäftsprozesse unterstützen. Durch die Orchestrierung modularer Teildienste findet nicht nur eine organisationsübergreifende Zusammenarbeit in Service-Netzwerken statt (vgl. Abbildung auf S. 91). Durch die freie Kombinierbarkeit der Teildienste können Konsumenten die komplexen Dienste deutlich flexibler an ihre Bedürfnisse anpassen, als dies bei allein stehenden SaaS 1.0- Anwendungen möglich ist. Auch nahtlose Integration in Legacysysteme soll in SaaS 2.0-Anwendungen unterstützt werden.

Quadrant 4:

Komplexe Dienstkonfiguration durch Wertschöpfungsnetze

Auch wenn das Salesforce-Angebot schon ein sehr umfassendes Lösungsspektrum umfasst, besteht weiterhin Forschungsbedarf im Bereich komplexer Services, die von unterschiedlichen, gleichberechtigten Anbietern dynamisch zusammengesetzt werden können. Dieser vierte Quadrant wird derzeit von dem Projekt THESEUS / TEXO adressiert. Hier geht es um die Bereitstellung einer offenen Plattform, auf der Diensteanbieter und -konsumenten zusammentreffen und komplexe wie auch einfache Dienstleistungen handeln können.

SOA-Perspektiven: Geschäftsmodelle und Innovationen für das Internet der Dienste

8.2 Forschungsprojekt TEXO TEXO ist Teil des Dachprojekts THESEUS (http://theseus-programm.de ), das vom Bundesministerium für Wirtschaft und Technologie (BMWi) gefördert wird. Ziel ist es, eine neue internetbasierte Infrastruktur für die Wissensund Dienstleistungsgesellschaft zu entwickeln. Um Wissen im Internet besser verfügbar zu machen, werden in unterschiedlichen Forschungsprojekten (Use Cases), die jeweils von renommierten deutschen Technologieunternehmen geführt werden, anwendungsorientierte Basistechnologien entwickelt und evaluiert. Es werden nicht nur neue Werkzeuge und Dienste erwartet, sondern auch Fortschritte im Hinblick auf deren wirtschaftliche Verwendung. Das Forschungsprojekt TEXO wird von SAP geführt und mit 11 weiteren Partnern aus Industrie, Forschungseinrichtungen und Universitäten bearbeitet. Insgesamt befassen sich etwa 55 Wissenschaftlerinnen und Wissenschaftler mit TEXO. TEXO zielt auf den Entwurf und die prototypische Umsetzung einer sozio-technischen Infrastruktur, innerhalb welcher komplexe, zusammengesetzte (elektronische) Dienste über das Internet gehandelt werden können. TEXO wird also den vierten Quadranten der oben aufgezeigten Typologie zum Leben erwecken und dabei alle Phasen des Dienstleistungslebenszyklus unterstützen (vgl. Abbildung auf S. 99): a Bevor Teilnehmer des Internet der Dienste einen Dienst anbieten oder nutzen können, erfolgt die Initiierung im Netzwerk. a Die Innovationsphase enthält die Bereiche Ideengeneration, deren Bewertung, Marktanalysen und Entwicklung. a Danach erfolgt mit der Angebotsphase die Kommerzialisierung eines Dienstes. a Die darauf folgende Matchmakingphase kann in Marketing und Sales unterteilt werden. a Nach dem Matchmaking, in der Angebot und Nachfrage zusammengeführt und ggf. Preise und weitere Diensteigenschaften verhandelt wurden, a folgt die Nutzungsphase, auf die letztendlich die Feedbackphase folgt. Das Feedback der Beteiligten stößt wiederum die Innovationsphase neu an.

www.hessen-it.de

Externe Innovation

! W ) W Initiierung

@ W

Innovation

% W

Angebot

Dienstleistungslebenszyklus

Feedback

Matchmaking

$ W Nutzung

Dienstleistungslebenszyklus

Eine solche Infrastruktur wird mit der TEXO Services Management Platform bereitgestellt werden. In hochgradig modularen, dynamischen Umgebungen wie dem Internet der Dienste spielen Intermediäre, die Angebot und Nachfrage zusammenbringen, eine wichtige Rolle. Service Broker erzeugen einen ökonomischen Wert, indem sie als Infomediär auftreten oder kompatible, modulare Dienste zu komplexen Diensten zusammenfügen. So können bereits existierende Dienste von unterschiedlichsten Anbietern kombiniert werden. Durch eine solche Reallokation entstehen neue, innovative Anwendungen. Die TEXO Services Management Platform tritt sowohl als Koordinator als auch als Integrator und Schnittstelle auf, um alle beteiligten Parteien zusammenzubringen. Es werden sowohl Geschäftsanwendungen als auch deren Realisierung durch technische Dienste betrachtet. Die TEXO Service Management Platform eröffnet damit kleinen und mittelständischen Dienstleistern neue Märkte und ermöglicht es Dienstkonsumenten, ihre Software dynamisch an Veränderungen anzupassen. 99

SOA-Perspektiven: Geschäftsmodelle und Innovationen für das Internet der Dienste

8.3 Marktpotenzial serviceorientierter IKT Das Marktpotenzial, das serviceorientierten Ansätzen zugesprochen wird, ist sehr bedeutsam und wird später noch konkreter illustriert. Im Vordergrund der weiteren Ausführungen steht aber die Frage, welchen Einfluss diese auf die Geschäftsmodelle der Anbieter haben werden. Internetbasierte Geschäftsmodelle gelten als einer der meist diskutierten, jedoch noch immer nicht im Detail verstandenen Aspekte im E-Business. Das gilt insbesondere für lose gekoppelte Geschäftsnetzwerke. Im Folgenden werden wir nach einem kurzen Blick auf einige Marktzahlen zur Entwicklung serviceorientierter Ansätze eine ausgewählte Umsetzungsvision des Internet der Dienste präsentieren und die Chancen und Risiken für die Beteiligten beispielhaft umreißen. Die Prognosen von Marktanalysten, die in den vergangenen Jahren für serviceorientierte IKT verfügbar sind versprechen nahezu konsistent ein enormes Potenzial und lassen die Serviceorientierung in der Presse als einen der derzeit wichtigsten IKT-Trends erscheinen: 31 % der Businessund IT-Manager halten SaaS bzw. SaaS-Plattformen sogar für den derzeit wichtigsten Trend der Softwarebranche (Quelle: Studie der Sand Hill Group und der McKinsey & Company in Enterprise Software Customer Survey 2008). Weltweit werden laut Gartner im Jahre 2011 mehr als 25 % des Umsatzes bei Geschäftsanwendungen durch SaaS erzielt werden. Konkret wird die Entwicklung von 2006 14,7 %, über 2007 16,0 % auf geschätzte 26,3 % 2011 ansteigen. Für Deutschland prognostiziert die Experton Group für 2010 einen Gesamtumsatz von 577 Mio. Euro, das entspricht einem Zuwachs von 113 % im Vergleich zu 2007.

100

www.hessen-it.de

KMU sind laut der Sandhill Group und McKinsey dabei die Kernzielgruppe. Nach einer Studie in den USA geben heute kleine Unternehmen mit weniger als 100 Mitarbeitern bereits 26 % ihres Budgets für OnDemand-Software aus. Dabei sind nach einer Gartner-Studie die beliebtesten Funktionen Customer Relationship Management (CRM), Enterprise Resource Planning (ERP), Supply Chain Management (SCM), Storage und Kollaborationsanwendungen – insgesamt meist Funktionen, die typischerweise nicht den Kern des eigentlichen Geschäfts der Anwender darstellen dürften. Ähnliche relative und deutlich höhere absolute Dimensionen lassen sich für die gesamte XaaS bzw. Cloud Computing-Entwicklung finden. Merrill Lynch (Quelle: The Cloud Wars, 2008) prognostiziert, dass Cloud Computing im Jahre 2011 einen Anteil von ca. 12 % des gesamten, weltweiten Softwareumsatzes erreichen kann. Hier ist nicht nur der Markt der Geschäftsanwendungen, sondern der gesamte Softwaremarkt die Basis für die Berechnung. Insgesamt berechnet Merril Lynch einen Umsatz von 744 Mrd. US Dollar für Software, davon fallen 237 Mrd. US Dollar auf Geschäftsanwendungen. Der Umsatz von Cloud Computing wird dabei auf 95 Mrd. US Dollar geschätzt. Wichtiger als die Marktprognosen sind an dieser Stelle aber die dazu zu überwindenden Hindernisse. Sowohl auf Kunden- wie auch auf Anbieterseite ist ein Wandel zu vollziehen. Beim Kunden sind die meist zitierten Bedenken, die aus dem Weg zu räumen sind, heute offensichtlich immer noch in den Bereichen Security und Netz- / Systemverfügbarkeit zu finden. Bedenken bzgl. Integration, wirklicher Reduktion der TCO und fehlender Funktionalität dürften laut einer Forrester-Studie jedoch ebenso große Hürden darstellen. Ist der Schritt zur Nutzung gegangen, besteht die Kernherausforderung für den Kunden darin, die neu gewonnene Flexibilität dann auch zu nutzen und kommerziell zum Effekt zu bringen – technische und wirtschaftliche Change-Prozesse müssen hier also eng abgestimmt sein.

101

SOA-Perspektiven: Geschäftsmodelle und Innovationen für das Internet der Dienste

Für bereits etablierte Anbieter von Unternehmenssoftware ist eine Änderung hin zu On-Demand-Delivery ein wohl noch substantiellerer Schritt, da er das Geschäftsmodell radikal tangiert: Bisherige lizenzorientierte Geschäfts- bzw. konkreter: Ertragsmodelle basierten zumeist auf den Säulen „Lizenzgebühren“, „Customizing / Consulting“ sowie regelmäßig wiederkehrenden Wartung („Maintenance“). Bei SaaS-Geschäftsmodellen sieht sich der Anbieter weiterhin initialen Kosten für Entwicklung, Marketing etc. ausgesetzt, Umsätze werden allerdings erst nach und nach durch nutzungsbedingte oder monatlich berechnete Gebühren generiert, wobei zudem laufende Bereitstellungskosten (für z. B. Serverkapazität) existieren. Das heißt letztendlich, dass durch das Mietmodell von SaaS während der Wachstumsphase eines SaaS-Geschäfts Erträge typischerweise deutlich langsamer, dafür aber kontinuierlicher erzielt werden. Richtet sich das Angebot tendenziell eher an KMU, wäre im Vergleich zu großen Unternehmen ein Mehraufwand nötig, wenn Vertrieb und Bereitstellung nicht (z. B. durch gemeinsame Plattformen, siehe hinten) effizienter organisiert werden können. Der Bedarf für Customizing und Consulting auf Kundenseite könnte im SaaS-Modell beschränkter sein, da die Implementierung bzw. Installation beim Kunden wegfällt. Andererseits ist die Personalisierung und Lösungsintegration mit bestehender Infrastruktur wohl in vielen Fällen trotzdem erforderlich und insbesondere bei komplexeren SaaS-Anwendungen weiterhin zu erwarten. Beispielsweise arbeitet Salesforce.com mit einer Vielzahl an Consulting-Partnern zusammen, da Schulungen bzgl. der Funktionalität und weiterer Dienste wie force.com vom Kunden stark nachgefragt werden. Da Professional Services wie Beratung und Anpassung im traditionellen Lizenzgeschäft oftmals größere Erträge bringen als die Lizenzen selbst, müssen die möglichen Konsequenzen in allen drei bisherigen Erlösquellen möglichst individuell exakt antizipiert werden, da die Umstellung auf ein SaaS-Angebot umfassende Auswirkungen auf die Anbieter hat. Darüber hinaus sind die Wechselwirkungen mit den Unternehmenspartnern für die Angebotsmodelle der oben eingeführten Quadranten 2, 3 und 4 von großer Bedeutung (vgl. Abbildung auf S. 94). 102

www.hessen-it.de

8.4 Geschäftsmodelle für das Internet der Dienste Welche neuen Geschäftsmodelle sind nun in einer offenen Serviceplattform, wie sie das TEXO-Konsortium anstrebt, denkbar? Potenziell natürlich unendlich viele. Zur Illustration seien einige skizziert, wobei wir vereinfachend die Annahme treffen, dass die gesamte Infrastruktur von einem Anbieter betrieben wird. Die andere Extremform ist die eines rein dezentralen Ansatzes, ein Kontinuum dazwischen ist ebenso denkbar. Um ein Geschäftsmodell vereinfacht zu beschreiben, greifen wir auf die Geschäftsmodelldefinition von Stähler (2001) zurück. Sie enthält die Elemente „Architektur der Wertschöpfung“ unter Berücksichtigung der beteiligten „Agenten“, eine Beschreibung des „generierten Kundennutzen“ sowie „Art und Ursprung der Erträge“. Grundsätzlich gehören die Akteure einer solchen Plattform fünf grundlegenden Rollen an: Plattformbetreiber, Servicekonsument, Serviceanbieter, Communitymitglied und Serviceinnovator. Die beiden letztgenannten Rollen werden im Folgenden vernachlässigt, da sie spezielle Rollen darstellen, die größtenteils in Überlappungen mit den drei erstgenannten Rollen auftreten dürften. Die Abbildung unten zeigt, welche Infrastrukturdienste auf der Plattform (Servicemarktplatz) vom Betreiber zur Verfügung gestellt werden könnten, um den eigentlichen Serviceanbietern und -konsumenten eine geeignete Infrastruktur zur Unterstützung aller Phasen des Lebenszyklus zu ermöglichen (die Zahlen beziehen sich jeweils auf die jeweiligen Phasen im Dienstleistungslebenszyklus).

103

SOA-Perspektiven: Geschäftsmodelle und Innovationen für das Internet der Dienste

% W

) W ! W

@ W # W $ W

Infrastrukturdienste auf der Serviceplattform

Für die Initiierungsphase (0) bietet die Plattform ein Identitätsmanagement und gibt grundlegende Standards vor. Innovationsdienste erleichtern Innovatoren (1) die Neuentwicklung und Evolution von Diensten. In der Angebotsphase (2) werden vorrangig Dienste zur Verfügung gestellt, die das Service Engineering – z. B. ein Plattformservice, der Serviceanbieter bei der Implementierung ihrer Dienste unterstützt, ein Infrastrukturdienst sowie ein juristischer Dienst, der Serviceanbieter für rechtliche Gegebenheiten sensibilisiert – und das Servicemarketing unterstützen. In der Matchmakingphase (3) können sowohl ökonomische, rechtliche als auch technische Dienste angeboten werden. Beispielsweise könnten allgemeine Geschäftsbedingungen (AGBs) von Anbieter und Konsument abgeglichen und ggf. angepasst werden. Semantische Technologien und Service Repositories unterstützen die Komposition von Teildiensten zu komplexen Diensten. Außerdem können dynamische Preis- und Allokationsdienste den aus ökonomischer Sicht effizienten Dienst ermitteln und dessen Preis festlegen. Monitoringdienste überwachen in der Nutzungsphase (4) die

104

www.hessen-it.de

erbrachten Dienste. Außerdem können die Angebote potentiell über mehrere Kanäle auf unterschiedlichsten Endgeräten angeboten werden. Im Anschluss an die Nutzung werden dann Services für Abrechnung und Bezahlung der genutzten Dienste bereitgestellt. Dienste, die Communities unterstützen, sollen abschließend qualitativ hochwertiges Feedback (5) ermöglichen und damit neue Serviceinnovation anstoßen (1). Des weiteren können verwandte Beratungsleistungen wie Marktanalysen, Schulungen, Nachfrageaggregation und weiterführende Integrationsdienste von plattformexternen Dienstleistern angeboten werden. Gleiches gilt für IaaS-Dienste. Speicherplatz und Rechenleistung muss nicht notwendigerweise von der Plattform bereitgestellt werden. Auch hier erwarten wir die Herausbildung spezialisierter Partner, die Serviceanbietern entsprechende Leistungen anbieten werden.

Durch die Flexibilität einer Serviceplattform können profitabel Nischendienstleistungen angeboten werden. So kann ein Anbieter durch Re-Konfiguration vorhandener Komponenten in unterschiedlichen komplexen Diensten auch Kundenbedürfnisse befriedigen,

die fernab der Massenbedürfnisse liegen.

105

SOA-Perspektiven: Geschäftsmodelle und Innovationen für das Internet der Dienste

Nutzen für Servicekonsumenten Der generierte Nutzen für den Servicekonsumenten lässt sich grob in sieben Kategorien einteilen: erhöhte Flexibilität, Qualitätssteigerung, Anwendungsintegration, Komplexitätsreduktion, Wiederverwendbarkeit, Kostenreduktion und schnelle Anpassung. Der postulierte Nutzen einer Serviceplattform ist demnach eng verwandt mit den generellen Nutzenversprechen eines SOA-Einführungsprojekts. a Flexibilität: Auf dem Servicemarktplatz werden nicht nur komplementäre, sondern auch gleichartige Services angeboten. Im Zusammenspiel mit der leichteren Integrierbarkeit der Dienste kann der Kunde hier vereinfacht zwischen Anbietern wechseln („switch on the fly“). Dadurch sinken für den Kunden insgesamt die Umstellungskosten bei Anbieterwechsel („Switching Costs“). Im Allgemeinen ist ein Konsument Umstellungskosten bei einem Anbieterwechsel ausgesetzt, wenn eine Investition, die bezüglich des bestehenden Anbieters erbracht werden musste, für einen neuen Anbieter erneut aufgebracht werden müsste. Im traditionellen Lizenzgeschäft mit hohen Initialkosten und langfristigen Wartungsverträgen findet sich der Kunde sehr schnell in einer solchen Situation wieder. Dies führt letztendlich dazu, dass starke Abhängigkeiten („Lock-In-Situationen“) entstehen, die den Kunden daran hindern, Serviceanbieter zu wechseln, obwohl andere für ihn vorteilhafter wären. SaaS-Anwendungen werden entweder nutzungsbasiert oder auf monatlicher Basis („Subscription Fee“) abgerechnet. Ist der Kunde nun unzufrieden, ist es für ihn beträchtlich einfacher und kostengünstiger, den Anbieter zu wechseln. Durch das Angebot gleichartiger, konkurrierender Dienste auf der Plattform wird dieser Effekt noch verstärkt. Es fallen zwar weiterhin Integrationskosten an, diese schlagen aber wegen gemeinsamer Standards bei einem Anbieterwechsel nicht zwangsläufig doppelt zu Buche. Des weiteren wird durch den Marktplatz, der eine weite Masse an Kunden erreicht, das Anbieten von Nischenprodukten profitabel. So können deutlich mehr Unternehmen mit spezifischen Anwendungen versorgt werden. Damit könnte die gegenwärtige Situation vieler Konsumenten beträchtlich verbessert werden – laut einer Forrester-Studie von 2007 finden 42 % SaaS-interessierte Unternehmen momentan keine passenden On-Demand-Anwendungen. 106

www.hessen-it.de

a Qualitätssteigerung: Geringere Switching Costs und Lock-In-Effekte erhöhen den Druck auf die Anbieter, was wiederum die Qualität der Dienste erhöht. Um sich zu differenzieren, müssen Anbieter nicht nur kompetitive Preise bieten, sondern vor allem über die Servicequalität Kunden binden. Servicequalität gilt mittlerweile als der wichtigste Abgrenzungsfaktor. a Anwendungsintegration: Die Möglichkeit der On-Premise-Integration der Dienste erhöht Flexibilität. Diese Eigenschaft, die als eine der Alleinstellungsmerkmale der TEXO Service Management Platform gilt, kann von Integrationsdiensten auf der Plattform sowie von externen Partnern unterstützt werden. a Komplexitätsreduktion: Der Betrieb der Hard- und Software sowie der Infrastruktur verlagert sich vom Kunden auf die Dienstanbieter bzw. den Plattformbetreiber. Dies verringert die Komplexität und den Ressourceneinsatz auf Kundenseite beträchtlich. Auch Updates und Upgrades werden zentral durchgeführt. So spart der Servicekonsument nicht nur den Aufwand, sondern kann auch sichergehen, dass an allen Arbeitsplätzen dieselbe Version verfügbar ist. Auch im Falle von Nichterfüllung vereinbarter Service Level Agreements (SLAs) unterstützt die zentrale Monitoringkomponente der Plattform und bietet dem Servicekonsumenten einen zentralen Ansprechpartner („one-faceto-the-customer“). Besteht ein komplexer Dienst beispielsweise aus drei Teildiensten, muss man sich als Konsument auf die Zuverlässigkeit von drei Anbietern verlassen können, es gibt drei unterschiedliche SLAs. Fällt nun ein Teilservice aus, entfaltet der komplexe Service gar keinen bzw. nicht den vollen Nutzen für den Kunden. Ohne einen zentralen Servicemarktplatz („Single-Point-of-Access“) müsste der Konsument nun selbst Kompensationszahlungen des betreffenden Anbieters einfordern. Je mehr Anbieter am Dienst beteiligt sind, umso komplexer die Verrechnung unzureichend erbrachter Dienste und die Ermittlung des Verursachers.

107

SOA-Perspektiven: Geschäftsmodelle und Innovationen für das Internet der Dienste

a Wiederverwendbarkeit: Wenn der Kunde auf der Serviceplattform keine passenden Applikationen findet, bietet die Plattform ein Framework (PaaS) an, mit dessen Hilfe eigene Anwendungen implementiert werden können. Die selbst implementierten Dienste kann der Kunde wiederum auf dem Marktplatz anbieten und somit selbst zum Serviceanbieter werden. a Kostenreduktion: Durch die Möglichkeit, Geschäftsanwendungen nutzungsbasiert beziehen zu können, müssen Unternehmen nur noch ihre tatsächliche Nutzung bezahlen. Gerade für kleine und mittelständische Unternehmen (KMU) war es bisher oftmals unwirtschaftlich, lizenzbasierte Anwendungen zu betreiben, wenn sie nur wenige Male zum Einsatz kommen. Durch das On-Demand-Modell ändert sich diese Situation – KMU können bei Bedarf auf benötigte hochwertige Applikationen zugreifen. Dies kann nicht nur Kosten reduzieren, sondern auch die Qualität erhöhen. a Schnellere Einsatzfähigkeit: Da die SaaS-Anbieter bzw. der Marktplatzbetreiber sowohl Hard- und Software, als auch die Infrastruktur liefern, verringert sich in der Regel die Zeit, bis die Applikation einsatzfähig ist („Time-to-Market“).

imagesource

108

www.hessen-it.de

Nutzen für Service Provider Auch für Serviceanbieter ergeben sich zahlreiche Anreize, Anwendungen auf der Serviceplattform bereitzustellen. a Flexibilität: Aufgrund der Multimandatenfähigkeit von SaaS-Anwendungen können Anbieter mehrere Tausend Servicekonsumenten mit derselben Instanz der Applikation bedienen. Durch Rekonfiguration einzelner Services (vgl. SOA-Paradigma) können Anwendungen schnell skaliert, geändert, versioniert und aktualisiert werden. Übergreifend über mehrere Serviceanbieter unterstützt die Plattform so Agilität und Innovation. Damit zusammenhängend kann die n-te Anwendung in Kombination mit n-1 vorhandenen Services sehr günstig angeboten werden und liefert die nötige Flexibilität, um Customizing-Wünsche der Servicekonsumenten befriedigen zu können. Während SaaS 1.0 bezüglich Kundenbezogenheit noch recht unflexibel war, können mit so genannten kompositen Applikationen (Composite Apps) durch Kooperation von Anbietern komplementärer Dienste innerhalb der Serviceplattform spezifische Kundenwünsche befriedigt werden. Dabei kann es sich beispielsweise um die Abbildung komplexer Geschäftsprozesse handeln. So können sich Dienstanbieter auf spezielle Funktionalitäten spezialisieren, bleiben dadurch schlank und agil, und kooperieren mit Partnern bei der Erstellung komplexer Dienste. a Komplexitätsreduktion: Die auf der Plattform angebotenen Infrastrukturservices reduzieren den Aufwand für Dienstanbieter. Die eigene Infrastruktur kann somit minimal gehalten werden, die Plattform übernimmt Aufgaben, die für Serviceanbieter bisher als „notwendiges Übel“ Overhead produziert haben. Beispielsweise können unter anderem Abrechnungsfunktionen, Monitoring, rechtliche Unterstützung, (dynamische) Preisfindung etc. zentral angeboten werden.

109

SOA-Perspektiven: Geschäftsmodelle und Innovationen für das Internet der Dienste

a Wiederverwendbarkeit: Durch die hohe Marktabdeckung einer Serviceplattform können profitabel Nischendienstleistungen angeboten werden. So kann ein Anbieter günstig, beispielsweise durch Wiederverwendung vorhandener Komponenten und das Angebot von nutzungsbasierter Abrechnung auch Nachfrage befriedigen, die fernab der Massenbedürfnisse liegen. Man spricht hierbei vom so genannten „Long Tail“. a Kostenreduktion und Skaleneffekte: Die potentiell große Menge an Servicekonsumenten begünstigt Skalenerträge. Aufgrund des Multimandantenprinzips lassen sich viele Kunden mit nur einer Instanz der Anwendung bedienen. Wie oben erwähnt, lassen sich durch flexible Rekonfiguration von Services kostengünstig angepasste komplexe Dienste erzeugen. Diese werden massiv von Kunden nachgefragt. Nach einer Forrester-Studie bemängeln 55 % der Befragten eine fehlende Customization bei SaaS-Anwendungen. Kosteneinsparungen sind auch durch Einsparungen im Marketingbereich möglich, da sich Marketingmaßnahmen durch die Plattform direkt auf Serviceanbieter

auswirken können.

110

www.hessen-it.de

8.5 Fazit Der Wandel zur Dienstleistungsgesellschaft ist aufwendig und vielschichtig – Beispiele für die Vielfalt der im Zuge der Dienstorientierung entstehen technischen Neuerungen sowie die wirtschaftlichen Risiken, aber auch Handlungsoptionen wurden hier illustriert. Ausgehend von der heutigen Situation, das heißt dem Angebot individueller SaaS-Angebote sowie dem Trend hin zu Service Value Networks sehen wir eine Verlagerung in Richtung eines vernetzten „IT-Ökosystems“. Diese Zukunftsvision des Internet der Dienste beinhaltet XaaS-Lösungen mit Fokus auf vernetzten Diensten, Integration, Plattformen, Infrastrukturdiensten, Brokern etc. In ersten einfachen Ausbaustufen hat das Internet der Dienste tragfähige Geschäftsmodelle hervorgebracht, die bereits konkrete Nachfrage bedienen: Der Umsatz von salesforce.com betrug im Jahre 2008 250 Mio. US Dollar. AppExchange beheimatet mittlerweile ca. 450 unabhängige Anbieter, die dort ca. 800 komplementäre Anwendungen zu Salesforce bereitstellen. Das Unternehmen hat insgesamt ca. 47 000 registrierte Kunden (Stand 25. Januar 2010). Unternehmen haben heute die Chance, von solchen Vorreitern oder von existierenden wegweisenden Forschungsarbeiten zu lernen und die Perspektive zu prüfen, eigene Services künftig auf dem tatsächlich globalen Markt zur Verfügung zu stellen oder Dienste von Dritten in ihre Infrastruktur zu integrieren. Sie können dabei vor allem von offenen Innovationsprozessen, also der engen Zusammenarbeit mit Lieferanten und Kunden sowie dem Kreis der Partner profitieren. Innovation findet dabei schon lange nicht mehr nur über die Technik statt – der zielgerichtetere Einsatz von Wissen, die intelligenteren Prozesse oder eben das schlagkräftigere Geschäftsmodell können ebenso differenzierend wirken.

111

Glossar

9 Glossar Business Process Execution Language (BPEL) BPEL ist eine XML-basierte Beschreibungssprache, mit der sich ein fachlicher Prozess spezifizieren lässt. Mit einem BPEL-Editor wird von der Überführung des fachlichen Prozesses ein grafisches IT-Prozessmodell erstellt. Dieses Modell enthält die Perspektiven der Fach- und der IT-Seite.

Enterprise Service Bus (ESB) Der „ESB“ (Gartner 2002) bildet eine Integrationsinfrastruktur, die z. B. einem Unternehmen einen Service über einen Datenbus zur Verfügung stellt. Ein ESB wird gemeinsam von Service-Gebern und -Nehmern genutzt, so dass unzählige Punkt-zu-PunktVerbindungen vermieden werden. Governance

Business Process Management (BPM) BPM ist ein ganzheitlicher Ansatz zum Management des Lebenszyklusses von Prozessen, der zur Prozessoptimierung eingesetzt werden kann. BPM und SOA ergänzen sich wechselseitig. Denn einerseits sollte ein Prozess, bevor er informationstechnisch abgebildet wird, zunächst analysiert und optimiert werden. Andererseits stellt SOA eine IT-Architektur dar, die eine flexible Prozessgestaltung und -verbesserung unterstützt.

112

SOA-Governance (franz. gouverner, verwalten, leiten, erziehen) bezeichnet die soziale, IT- und geschäftsbezogene Steuerung und Kontrolle eines SOA-Prozesses. Sie umfasst diesbezügliche Aktivitäten, Entscheidungen, Rollen und Verantwortlichkeiten. Orchestrierung Der Prozess oder Zustand einer losen Verkopplung von Services z. B. mittels BPEL wird Orchestrierung genannt. Durch die Verkopplung wird ein neuer übergeordneter Service mit erweiterten Funktionen oder eine neue Anwendung erzeugt.

www.hessen-it.de

Registry

Service

Ein Verzeichnis oder Katalog verfügbarer Services mit nur wenigen Metadaten wie etwa einer Schnittstellenbeschreibung wird Registry genannt. Einem Branchen-Telefonbuch ähnlich gehen daraus im Wesentlichen nur die Adresse und wenige Zusatzinformationen hervor.

Ein Service (Dienst) ist die zentrale Grundkomponente einer SOA. Er stellt eine eigenständige und unabhängige funktionale Einheit dar. Wird ein Service mit einer standardisierten Schnittstelle über Web Services mit anderen Services verknüpft, entsteht eine serviceorientierte Architektur.

Repository

Web Service

Das Repository dient – stärker als das Registry – als Instrument der SOA-Governance zur Steuerung und Kontrolle von Services. Es speichert und kategorisiert die Services mit ihren zugehörigen Aspekten. Werden Registry und Repository zu einer integrierten Einheit zusammengefasst, werden sie als „Repistry“ bezeichnet.

Unter Web Service kann man lose gekoppelte, wieder verwendbare Softwarekomponenten verstehen, die unter Verwendung von Internetstandards aufgerufen werden können und über den Austausch von XMLbasierten Nachrichten miteinander kommunizieren. Web Services sind der zentrale Standard zur Realisierung von ServiceSchnittstellen und zur Kopplung von Services.

113

Ihre Partner in Hessen

10 Ihre Partner in Hessen Hier finden Sie eine Auswahl an hessischen Unternehmen, Wissenschafts- und Forschungseinrichtungen sowie anderen Akteuren mit Kompetenzen im Bereich von serviceorientierten Architekturen. Die Listung erhebt keinen Anspruch auf Vollständigkeit. Weitere Informationen über mögliche SOA-Partner mit Sitz in Hessen erhalten Sie im Internet unter www.kompetenzatlas-hessen.de.

Accelsis Technologies GmbH

arlanis Software AG Mannheimer Straße 97 60327 Frankfurt am Main

Mergenthalerallee 77 65760 Eschborn

Andreas Holubek Telefon 069 241829-0 Telefax 069 241829-29 info@arlanis.com

Frank Joecks Telefon 06196 470520 Telefax 06196 470549 frank.joecks@accelsis.biz

www.arlanis.com

www.accelsis.biz

ATE Software GmbH

Accenture GmbH

Bockenheimer Anlage 4 60322 Frankfurt Main

Campus Kronberg 1 61476 Kronberg im Taunus Telefon 06173 94-99 Telefax 06173 94-98 accenture.direct.ela@accenture.com

Thomas Erbrich Telefon 069 9150119-0 Telefax 069 9150119-1 info@ate-software.net

www.accenture.com

www.ate-software.net

Accurat Informatik GmbH

Avanade Deutschland GmbH

Im Gefierth 13c 63303 Dreieich

Campus Kronberg 7 61476 Kronberg

Telefon 06103 3807-0 Telefax 06103 3807-124 info@accurat.de

Telefon 06173 94 63800 Telefax 06173 94 63999 germany@avanade.com

www.accurat.de

www.avanade.de

ALTRAN Deutschland Holding GmbH Schillerstraße 20 60313 Frankfurt am Main Telefon 069 219767-70 Telefax 069 219767-76 info@altran.de

www.altran.de

114

uns Dann senden Sie Fehlt Ihr Eintrag? de fo@hessen-it. Ihre Angaben an in

www.hessen-it.de

Axway GmbH Mainzer Landstraße 61 60329 Frankfurt am Main Telefon 069 244 508-0 Telefax 069 244 508-21 contactgermany@axway.com

www.axway.de

BLAUERLOTOS GmbH & Co. KG

CAST e.V. – Competence Center for Applied Security Technology Geschäftsführung Fraunhoferstraße 5 64283 Darmstadt Claudia Prediger Telefon 06151 155-529 Telefax 06151 155-499 claudia.prediger@cast-forum.de

www.cast-forum.de

Am Felsenkeller 8a 63505 Langenselbold Telefon 06184 937221 Telefax 06184 937481 wasewitz@blauerlotos.com

www.blauerlotos.com

CA Deutschland GmbH

Geschäftsführung Fraunhoferstraße 5 64283 Darmstadt Prof. Dr. Andreas Heinemann Telefon 0621 4105-1170 Telefax 06151 155-499 andreas.heinemann@cast-forum.de

Marienburgstraße 35 64297 Darmstadt

www.cast-forum.de

Telefon 06151 949-0 Telefax 06151 949-600 info@ca.com

Corisecio GmbH

www.ca.com/de

CASED – Center for Advanced Security Research Darmstadt Direktor Mornewegstraße 32 64293 Darmstadt Prof. Dr. Johannes Buchmann Telefon 06151 16-50777 Telefax 06151 16-6036 buchmann@cdc.informatik.tu-darmstadt.de

www.cased.de

Uhlandstraße 9 64297 Darmstadt Telefon 06151 95130-11 Telefax 06151 95130-66 info@corisecio.com

www.corisecio.com

CSC in Deutschland Abraham-Lincoln-Park 1 65189 Wiesbaden Telefon 0611 142-0 Kundeninfo 0611 142-22222 Telefax 0611 142-22000 deutschland@csc.com

www.csc.com/de Software-Cluster Koordinierungsstelle Mornewegstraße 32 64293 Darmstadt Gino Brunetti Telefon 06151 16-70821 Telefax 06151 16-55136 gino.brunetti@cased.de

www.cased.de

Daenet GmbH Hanauer Landstraße 204 60314 Frankfurt am Main Telefon 069 242408-0 Telefax 069 242408-25 info@daenet.de

www.daenet.de

115

Ihre Partner in Hessen

DB Systel GmbH Kleyerstraße 27 60326 Frankfurt am Main Gunnar Rühl Telefon 069 265-17800 Telefax 069 265-18420 gunnar.ruehl@deutschebahn.com

www.dbsystel.de

European Business School Institute of Research on Information Systems IRIS Rheingaustraße 1 65375 Oestrich-Winkel Dr. Christine Legner Telefon 06723 991-251 Telefax 06723 991-255 christine.legner@ebs.edu

www.ebs.edu/iris

Detecon International GmbH Frankfurter Straße 27 65760 Eschborn Dieter Wendel Telefon 06196 903-255 Telefax 06196 903-496 dieter.wendel@detecon.com

www.detecon.com

Fachhochschule Gießen-Friedberg Wiesenstraße 14 35390 Gießen Prof. Dr. Thomas Letschert Telefon 0641 309-2388 Telefax 0641 309-2908 thomas.letschert@mni.fh-giessen.de

www.mni.fh-giessen.de

Devoteam Danet GmbH Gutenbergstraße 10 64331 Weiterstadt Telefon 06151 868-0 info@devoteam.de

www.devoteam.de

EDAG GmbH & Co. KGaA Reesbergstraße 1 36039 Fulda IT Services

FORTENO GmbH Taunusstraße 66 65183 Wiesbaden Telefon 0611 58069-10 Telefax 0611 58069-77 info@forteno.com

www.forteno.com

Frankfurt School of Finance & Management

Raoul Flügel Telefon 0661 6000-596 Telefax 0661 6000-113204 raoul.fluegel@edag.de

Wirtschaftsinformatik Management Research Centre Sonnemannstraße 9-11 60314 Frankfurt am Main

www.edag.com

Prof. Dr. Matthias Goeken (JP) Telefon 069 154008-746 Telefax 069 154008-4746 m.goeken@frankfurt-school.de

Epicor Software Deutschland GmbH Hanauer Landstraße 291a 60314 Frankfurt am Main Telefon 069 800 766-00 Telefax 069 800 766-05 info.germany@epicor.com

www.epicor.de

www.frankfurt-school.de Prof. Dr. Peter Rossbach Telefon 069 154008-739 Telefax 069 154008-4739 p.rossbach@frankfurt-school.de

www.frankfurt-school.de

116

www.hessen-it.de

Fraunhofer-Institut für Sichere Informationstechnologie (SIT)

Hochschule Fulda

Institutsleitung Rheinstraße 75 64293 Darmstadt

Angewandte Mathematik, Kryptographie, IT-Sicherheit Marquardstraße 35 36039 Fulda

Prof. Dr. Claudia Eckert Telefon 06151 869-285 Telefax 06151 869-127 claudia.eckert@sit.fraunhofer.de

Prof. Dr. Ulrich Bühler Telefon 0661 9640-325 Telefax 0661 9640-349 u.buehler@informatik.hs-fulda.de

www.sit.fraunhofer.de

www.informatik.hs-fulda.de

Gartner Deutschland GmbH Lyoner Straße 20 60528 Frankfurt Telefon 069 669084-0 Telefax 069 6662809 gartner.deutschland@gartner.com

www.gartner.com

HA Hessen-Agentur GmbH

Hochschule RheinMain Design Informatik Medien Labor für Verteilte Systeme Kurt-Schumacher-Ring 18 65197 Wiesbaden Prof. Dr. Reinhold Kröger Telefon 0611 9495-1207, -1202 Telefax 0611 9495-1210 reinhold.kroeger@hs-rm.de

wwwvs.cs.hs-rm.de

siehe Hessen-IT

Hochschule Darmstadt Hessen-IT Aktionslinie für den hessischen IKT-Markt des Hessischen Ministeriums für Wirtschaft, Verkehr und Landesentwicklung (HMWVL) c/o HA Hessen Agentur GmbH Abraham-Lincoln-Straße 38–42 65189 Wiesbaden Wolf-Martin Ahrend Telefon 0611 774-8299 Telefax 0611 774-8620 wolf-martin.ahrend@hessen-agentur.de

www.hessen-it.de Dr. Matthias Donath Telefon 0611 774-8963 Telefax 0611 774-8620 matthias.donath@hessen-agentur.de

Informatik Schöfferstraße 8b 64295 Darmstadt Prof. Dr. Bernhard Humm Telefon 06151 16-8494 Telefax 06151 16-8935 b.humm@fbi.h-da.de

www.fbi.h-da.de Informatik, Institut für Angewandte Informatik Darmstadt (aiDa) Schöfferstraße 8b 64295 Darmstadt Prof. Dr. Hans-Peter Wiedling Telefon 06151 16-8441 Telefax 06151 16-8935 h.wiedling@fbi.h-da.de

www.aida.h-da.de

www.hessen-it.de

HTTC – Hessisches Telemedia Technologie Komptenz-Center e.V. siehe SOA Competence Center im HTTC e.V.

117

Ihre Partner in Hessen

IDC Central Europe GmbH

Intersystems GmbH

Hanauer Landstraße 135-137 60314 Frankfurt

Hilpertstraße 20a 64295 Darmstadt

Telefon 069-90502-0 Telefax 069-90502-100 info_ce@idc.com

Thomas Mironiuk Telefon 06151 1747-0 Telefax 06151 1747-11 thomas.mironiuk@intersystems.com

www.idc.com

www.intersystems.de

infodienst GmbH Schützenrain 9 61231 Bad Nauheim Telefon 06034 92314 Telefax 06034 92301 bbuss@4soa.de

www.4soa.de

Informatica GmbH Lyoner Straße 15 60528 Frankfurt Telefon 069 928809-0 Telefax 069928809-500 info-de@informatica.com

www.informatica.com/de

Information Builders (Deutschland) GmbH Mergenthalerallee 35 65760 Eschborn Anja Griebel

Intraprend Gesellschaft für Intranet Anwendungsentwicklung mbH Borsigstraße 18 65205 Wiesbaden Telefon 06122 533959 Telefax 06122 533963 info@intraprend.de

www.cierp3.de

iPIsec Ltd. Auguste-Viktoria-Straße 3 61231 Bad Nauheim Wolfgang Geisel Telefon 06032 93897-12 Telefax 06032 93897-15 wgeisel@i-pi-sec.de

www.ipisec.com

Johann Wolfgang Goethe-Universität

Telefon 06196 77576-0 Telefax 06196 77576-99 anja_griebel@ibi.com

Institut für Wirtschaftsinformatik Grüneburgplatz 1 60323 Frankfurt am Main

www.informationbuilders.de

Prof. Dr. Wolfgang König Telefon 069 798-34001 Telefax 069 798-33910 wkoenig@wiwi.uni-frankfurt.de

intelligent views gmbH Julius-Reiber-Straße 17 64293 Darmstadt

www.wiwi.uni-frankfurt.de

Claudia Baumer Telefon 06151 5006-423 Telefax 06151 5006-138 c.baumer@i-views.de

Datenbanken und Informationssysteme (DBIS) Robert-Mayer-Straße 10 60054 Frankfurt am Main

www.i-views.de

Prof. Dr.-Ing. Roberto V. Zicari Telefon 069 798-28212 Telefax 069 798-28123 zicari@cs.uni-frankfurt.de

www.dbis.informatik.uni-frankfurt.de

118

www.hessen-it.de

Justus-Liebig-Universität Gießen Institut für Informatik Arndtstraße 2 35392 Gießen Prof. Dr. Martin Kutrib Telefon 0641 99-32140 Telefax 0641 99-32149 kutrib@informatik.uni-giessen.de

Opitz Consulting Bad Homburg GmbH Kaiser-Friedrich-Promenade 93-95 61348 Bad Homburg v. d. H. Markus Ganss Telefon 06172 66260-0 Telefax 06172 66260-4500 markus.ganss@opitz-consulting.de

www.opitz-consulting.de

www.informatik.uni-giessen.de

PA Consulting Group Deutschland GmbH Logica Deutschland GmbH & Co. KG Rheinstraße 95 64295 Darmstadt Telefon 06151 36860-0 Telefax 06151 36860-222 Am Limespark 2 65843 Sulzbach (Taunus) Telefon 06196 7742-0 Telefax 06196 7742-555 www.logica.com

msgGillardon AG Mergenthalerallee 55-59 65760 Eschborn Dr. Nicolas Repp Telefon 06196 7750-0 Telefax 06196 7750-5410 nicolas.repp@msg-gillardon.de

www.msg-gillardon.de

Lufthansa Systems AG Am Weiher 24 65451 Kelsterbach Telefon 069 696-90000 Telefax 069 696-95959 info@LHsystems.com

www.LHsystems.com

OctaVIA AG Marie-Calm-Straße 1-5 34131 Kassel Telefon 0561 31000-0 Telefax 0561 31000-31 info@octavia.de

Eschersheimer Landstraße 223 60320 Frankfurt am Main Telefon 069 71702-0 Telefax 069 71702-263 info@paconsulting.com

www.paconsulting.com

Philipps-Universität Marburg Fachbereich Mathematik und Informatik Hans-Meerwein-Straße 3 35032 Marburg Prof. Dr. Bernd Freisleben Telefon 06421 2821-568 Telefax 06421 2821-573 freisleb@informatik.uni-marburg.de

www.informatik.uni-marburg.de

Rücker AG Kreuzberger Ring 40 65205 Wiesbaden Telefon 0611 73 75-0 Telefax 0611 73 75-102 info@ruecker.de

www.ruecker.de

Saugatuck Technologies Inc. Bluecherstraße 4 65343 Eltville Frank P. Sempert Telefon 06123 630285 Telefax 06123 630362 frank.sempert@saugatech.com

www.saugatech.com

www.octavia.de

119

Ihre Partner in Hessen

SAP Research CEC Darmstadt

SP Integration GmbH

Bleichstraße 8 64283 Darmstadt

Otto-Volger-Straße 5a 65843 Sulzbach / Taunus

Dr. Knut Manske Telefon 06227 7-68844 Telefax 06227 78-44632 knut.manske@sap.com

Telefon 06196 76430-0 Telefax 06196 76430-11 info@sp-integration.de

www.sp-integration.de

www.sap.com/research

Sylphen GmbH & Co. KG Software AG Uhlandstraße 12 64297 Darmstadt Daniel Adelhardt Telefon 06151 92-1403 Telefax 06151 92-11 91 daniel.adelhardt@softwareag.com

www.softwareag.com

SOA Competence Center im HTTC e.V. Rundeturmstraße 10 64283 Darmstadt Dr.-Ing. Julian Eckert Telefon 06151 16-3742 Telefax 06151 16-6152 julian.eckert@httc.de

www.httc.de Stefan Schulte Telefon 06151 16-6187 Telefax 06151 16-6152 stefan.schulte@httc.de

www.httc.de

Liebigstraße 14 35390 Gießen Ralph Boßler Telefon 0641-94468-0 rbossler@sylphen.com

www.sylphen.com

Syngenio AG Schiersteiner Straße 86 65187 Wiesbaden Stefan Scheid Telefon 0611 450415-0 Telefax 0611 450415-22 stefan.scheid@syngenio.de

www.syngenio.de

T-Systems International GmbH Otto-Röhm Straße 71c 64293 Darmstadt Bernard Tsai Telefon 06151 886-1757 Telefax 06151 886-9515 bernard.tsai@t-systems.com

www.t-systems.de

Software & Support Verlag GmbH Geleitsstraße 14 60599 Frankfurt am Main Mirko Schrempp Telefon 069 630089-38 Telefax 069 630089-89 mschrempp@sandsmedia.com

www.software-support.biz

120

Tieto Deutschland GmbH Düsseldorfer Straße 40 65760 Eschborn Telefon 06196 9329-0 Telefax 06196 9329-898

http://tieto.de

www.hessen-it.de

Technische Universität Darmstadt Information Systems / Wirtschaftsinformatik Hochschulstraße 1 64289 Darmstadt Prof. Dr. Peter Buxmann Telefon 06151 16-4826 Telefax 06151 16-5162 buxmann@is.tu-darmstadt.de

Universität Kassel Kommunikationstechnik Wilhelmshöher Allee 73 34121 Kassel Prof. Dr.-Ing. Klaus David Telefon 0561 804-6314 Telefax 0561 804-6360 david@uni-kassel.de

www.is.tu-darmstadt.de

www.comtec.eecs.uni-kassel.de

Multimedia Communications Lab Rundeturmstraße 10 64283 Darmstadt

Verteilte Systeme Wilhelmshöher Allee 73 34121 Kassel

Prof. Dr.-Ing. Ralf Steinmetz Telefon 06151 16-6151 Telefax 06151 16-6152 ralf.steinmetz@kom.tu-darmstadt.de

www.kom.tu-darmstadt.de

Prof. Dr. Kurt Geihs Telefon 0561 804-6275 Telefax 0561 804-6277 geihs@uni-kassel.de

www.vs.uni-kassel.de

Unisys Deutschland GmbH Am Unisys-Park 1 65843 Sulzbach Telefon 06196 99-0 Telefax 06196 99-1570 infodeutschland@de.unisys.com

www.unisys.de

121

Profile der Unternehmen und Institutionen der Autoren in der Reihenfolge des Erscheinens

Profile der Unternehmen und Institutionen der

11 Autoren in der Reihenfolge des Erscheinens SOA Competence Center im httc e.V.

Software AG

Das SOA Competence Center (SCC) ist ein Geschäftsbereich des Hessischen Telemedia Technologie Kompetenz-Centers e.V. in Darmstadt (httc e.V.). Das SCC berät Unternehmen und Organisationen im Rahmen von Software-Architekturprojekten im Kontext serviceorientierter Architekturen. Die Leistungen des SCC richten sich an Unternehmen, die SOA planen, einführen, optimieren und als Infrastruktur anbieten.

Software AG ist ein weltweit führendes Unternehmen im Bereich Business Process Excellence. Der Unternehmensumsatz beläuft sich auf mehr als 1 Milliarde Euro (2009), mehr als 6000 Mitarbeiter gehören zum Unternehmen, und es beliefert über 10 000 Kunden in 70 Ländern weltweit. Das Unternehmen hat seinen Hauptsitz in Deutschland und ist an der Frankfurter Wertpapierbörse notiert.

www.httc.de

www.softwareag.com

Dr. Wolfgang Martin Team

Opitz Consulting Bad Homburg GmbH

Dr. Wolfgang Martin ist ein unabhängiger Analyst und europäischer Experte auf den Gebieten Business Intelligence / Corporate Performance Management (BI / CPM), Business Process Management, Enterprise Information Management (Business Integration), Service Oriented Architecture (SOA) und Customer Relationship Management (CRM)

OPITZ CONSULTING ist ein Projektspezialist im Java-, SOA- und Oracle-Markt. Das Unternehmen unterstützt bei der Erstellung einer IT-Strategie und berät bei dem Prozessdesign und der Aufnahme der Anforderungen. Es konzipiert und realisiert kundenspezifische IT-Lösungen, gewährleistet einen hochverfügbaren Betrieb und bildet Mitarbeiter in Schulungszentren aus. OPITZ CONSULTING wurde 1990 gegründet und beschäftigt über 400 Mitarbeiter an Standorten in Deutschland, Polen und der Schweiz.

www.wolfgang-martin-team.net

www.opitz-consulting.com

122

www.hessen-it.de

Detecon International GmbH

European Business School

Detecon International ist ein weltweit führendes Unternehmen für integrierte Management- und Technologieberatung entlang der gesamten Wertschöpfungskette der Kunden. Detecon International entstand 2002 aus der Fusion der beiden Beratungshäuser DETECON und Diebold und ist ein Tochterunternehmen der T-Systems.

Die European Business School (EBS) ist Deutschlands älteste private wissenschaftliche Hochschule mit hervorragendem nationalen und internationalen Ruf. Im Bereich Wirtschaftsinformatik bietet sie praxisnahe Studienangebote (Bachelor-, Master- und Executive-Programme) und Forschung zu aktuellen Fragen des strategischen IT-Managements an.

www.detecon.com

www.ebs.edu/iris

Intersystems GmbH InterSystems ist ein mehr als 30 Jahre erfolgreicher Softwarehersteller im Bereich objektorientierte Datenbanken, Kommunikationsserver, Integrationsplattformen und Lösungen für das Gesundheitswesen. www.intersystems.de

Corisecio GmbH CORISECIO ist ein führender Hersteller von automatisierten Security-Produkten für SOA-Infrastrukturen. Basierend auf der eigenen Open Platform sind EnterpriseLösungen für SOA Security und SAP sowie Mobile Security und Database Encryption erfolgreich in mehr als 50 Ländern im Einsatz. CORISECIO hat ihren Hauptsitz in Darmstadt und wird durch Vertriebspartner weltweit unterstützt.

FZI Forschungszentrum Informatik Das FZI Forschungszentrum Informatik Karlsruhe hilft – als unabhängige Forschungseinrichtung des Landes Baden-Württemberg – Unternehmen und öffentlichen Einrichtungen, gemeinsam Innovationen zu entwickeln. Informatik als Schlüssel zu neuen Technologien steht im Mittelpunkt von Anwendungsforschung, Entwicklung und Technologietransfer. www.fzi.de

www.corisecio.com

123

Die Aktionslinie Hessen-IT

12 Die Aktionslinie Hessen-IT Hessen-IT ist die Aktionslinie des Hessischen Ministeriums für Wirtschaft, Verkehr und Landesentwicklung für den gesamten Informations- und Kommunikationstechnologiemarkt in Hessen. Hessen-IT bietet Informationen und Services zum Online-Markt, zu E- und M-Commerce, zu Softwareund Telekommunikationsanbietern sowie über Telearbeit. Angesprochen werden auf der einen Seite die fast 10.000 hessischen Unternehmen, die Produkte oder Dienstleistungen auf dem Informations- und Kommunikationstechnologiemarkt anbieten, auf der anderen Seite die kleinen und mittleren Anwender-Unternehmen. Anbieter-Datenbanken erleichtern die Suche nach geeigneten Dienstleistern bei der Durchführung von IT-Projekten. Gleichzeitig fungieren diese Datenbanken für Anbieter als Informations- und Kommunikationsplattform, auf der sich diese den Anwendern und potenziellen Kunden präsentieren können. Newsticker, E-Mail- und Print-Newsletter berichten regelmäßig über den IKT-Markt in Hessen. Zahlreiche Schriftenreihen und Veröffentlichungen ergänzen das Informationsangebot der Website. Die Broschüren können bequem online bestellt oder heruntergeladen werden. Hessen-IT hat verschiedene Netzwerke und Branchentreffs initiiert, in denen sich teils nichtkommerzielle Initiativen, teils kommerzielle Anbieter zusammengeschlossen haben. Regionale Multimedia- und E-CommerceZentren sowie IHKs, Handwerkskammern und andere regionale Akteure arbeiten zusammen an dem Ziel, Hessens starke Stellung im deutschen und europäischen IKT-Markt weiter zu sichern und auf dem Weg in die Informationsgesellschaft weiter voran zu bringen.

124

www.hessen-it.de

Einen Überblick über diese Netzwerke und Treffen sowie Terminankündigungen zu Veranstaltungen, an denen Hessen-IT beteiligt ist, finden Sie im Online-Terminkalender auf der Website. Auch bei internationalen Messen wie der CeBIT oder bei regionalen Veranstaltungen in ganz Hessen sind kompetente Ansprechpartner der Aktionslinie präsent. Hinzu kommen Seminare und Workshops, die Hessen-IT zu verschiedenen Themen ausrichtet. Das Projektteam von Hessen-IT steht Ihnen jederzeit gerne als Ansprechpartner zur Verfügung. Besuchen Sie unsere Website unter

www.hessen-it.de

125

Schriftenreihe Hessen-IT

Schriftenreihe Hessen-IT (vormals Hessen-Media) Bestellmöglichkeit und Download als PDF-Datei finden Sie im Internet unter www.hessen-it.de

Wir über uns 2001

Hessen-infoline-Netzwerk (Band 26) Projektdokumentation (Band 1)

Bildung und Wissenschaft 2002

Telemedizin in Hessen – Beiträge aus dem Universitätsklinikum Gießen (Band 24)

2001

Entwicklung und Einsatz elektronischer Medien als Lehr- und Lernmittel an hessischen Hochschulen (Band 27) Kompetenzzentren und Onlinedienste im Schulwesen – Beispiele für Hessen-Media Projekte (Band 25)

2000

Die virtuelle Universität (Band 15)

E-Government 2002

Auf dem Weg zu E-Government – Hessens Kommunen im Internet (Band 37) Wirtschaftsförderung und Standortmarketing im Internet (Band 36)

Marktstudien IT-Standort Hessen 2008

Telekommunikationsanbieter in Hessen 2008 (Band 60)

2006

IKT-Markt in Hessen (Band 58)

2004

Softwareanbieter in Hessen 2004 (Band 50) Telekommunikationsanbieter in Hessen 2004 (Band 49)

126

2003

Online-Anbieter in Hessen (Band 2)

2002

E-Shops in Hessen (Band 28)

2000

Der Telekommunikationsmarkt in Hessen (Band 21)

www.hessen-it.de

Leitfäden für IT-Anwendungen 2010

Notleidende Projekte – Eine Hilfestellung für IT-Projekte in sieben Akten (Band 64) Die Gamesbranche – ein ernstzunehmender Wachstumsmarkt (Band 59, 2. aktualisierte Auflage) SOA – Mehr als nur flexible Softwarearchitekturen (Band 63) Satellitennavigation in Hessen – Ideen über All (Band 65) Ambient Mobility – Intelligent Products and Environments for Mobile Citizens and Businesses (Band 62)

2009

Ambient Mobility – Intelligente Produkte und Umgebungen für mobile Bürger und Unternehmen (Band 61) Rating für IKT-Unternehmen (Band 53, 2. aktualisierte Auflage)

2008

Leitfaden zur Patentierung computerimplementierter Erfindungen (Band 51, 2. aktualisierte Auflage)

2007

Web 2.0 – Neue erfolgreiche Kommunikationsstrategien für kleine und mittlere Unternehmen (Band 57) Die Gamesbranche – ein ernstzunehmender Wachstumsmarkt (Band 59) In modernen Märkten überleben – Kooperationen mittelständischer Softwareunternehmen in Hessen (Band 44, 2. Auflage)

2006

Internet-Marketing nicht nur für kleine und mittlere Unternehmen (Band 52) Basel II – Rating für IT-Unternehmen (Band 53) RFID – Geschäftsprozesse mit Funktechnologie unterstützen (Band 54) Anti-Spam – Ein Leitfaden über und gegen unverlangte E-Mail-Werbung (Band 55) VoIP – Telefonieren über das Internet (Band 56) Leitfaden Webdesign – Internetpräsenzen besser planen und gestalten (Band 7, 5. Auflage)

2005

Recht im Internet (Band 33, 2. Auflage) Gefunden werden im Internet (Band 32, 2. Auflage)

2004

Wettbewerbsvorteile durch barrierefreie Internetauftritte (Band 48) Domainregistrierung international (Band 47) Wireless-LAN: Stand und Entwicklungspotenzial, Nutzungsansätze für KMU (Band 46)

127

Schriftenreihe Hessen-IT

2003

E-Business-Konzepte für den Mittelstand (Band 45) Leitfaden „In modernen Märkten überleben“ (Band 44) Projektleitfaden „Software-Ergonomie“ (Band 43) „Digitale Signatur“, Leitfaden zum Einsatz digitaler Signaturen (Band 42) Die Bedeutung der E-Logistik für den Mittelstand (Band 41) Management von Kundenbeziehungen im Internet (Band 40) Leitfaden „Webdesign – Internetpräsenzen besser planen und gestalten“ (Band 7)

2002

IT-Sicherheit für den Mittelstand (Band 38) E-Paymentsysteme – Bezahlen im Internet (Band 35) ASP: Mehr als nur Mietsoftware (Band 34) Recht im Internet (Band 33) Gefunden werden im Internet (Band 32) E-Learning für KMU – Neue Medien in der betrieblichen Aus- und Weiterbildung (Band 31) Telehaus Wetter – ein TeleServiceZentrum (Band 30)

2001

Kasseler Praxis-Dialog Tele@rbeit – Analysen · Erfahrungen · Positionen (Band 29)

2000

Leitfaden „Webdesign international“ (Band 22) E-Shop-Software (Band 20) Hessische Handwerker entdecken das Internet (Band 19) Leitfaden zur Anwendung eines Ratingsystems für IT-Unternehmen in Hessen (Band 18) Software-Dialog Hessen (3) (Band 17) Leitfaden „E-Shop“ (Band 16)

128

ISBN 978-3-939358-63-3