SOA MATURITY MODEL, EIN VORGEHENSMODELL ZUR EINFÜHRUNG EINER SERVICEORIENTIERTEN ARCHITEKTUR WHITE PAPER

Transkript

1 SOA MATURITY MODEL, EIN VORGEHENSMODELL ZUR EINFÜHRUNG EINER SERVICEORIENTIERTEN ARCHITEKTUR WHITE PAPER

2 Um die Verbreitung des SOA Maturity Model zu fördern, dürfen Sie die "SOA-Materialien" - unter Berücksichtigung der hier formulierten Einschränkungen - für sich und Ihr Unternehmen kopieren, verteilen und verwenden; dies gilt auch für Arbeiten, die von den "SOA-Materialien" abgeleitet sind. Als "SOA-Materialien" gelten sämtliche Bilder, Icons, Mustervorlagen, Whitepaper und andere Materialien, die im Zusammenhang mit dem SOA Maturity Models bereitgestellt werden; dies gilt auch für den dazugehörigen Text sowie Beschriftungen von Abbildungen. Sie sind nicht berechtigt, Copyright-Vermerke oder andere Hinweise zum geistigen Eigentum zu entfernen, die in den SOA-Materialien oder anderen damit zusammenhängenden Materialien, die Ihnen zur Verfügung gestellt wurden, enthalten sind. Wenn Sie daran interessiert sind, eigene Arbeiten bzw.

3 INHALT > Vorwort 2 > 1.0 Einführung und Motivation 3 > 2.0 Was ist eine SOA (serviceorientierte Architektur)? 6 > 3.0 Das SOA Maturity Model SOA-Reifestufe 1 Initial-Services SOA-Reifestufe 2 Architektur-Services SOA-Reifestufe 3 - Business Services und Kollaborative Services SOA-Reifestufe 4 - Messbare Business Services SOA-Reifestufe 5 - Optimierte Business Services 23 > 4.0 Schluss 25 1

4 VORWORT Das in diesem Whitepaper vorgestellte Modell wurde entwickelt, um Unternehmen bei der Steigerung ihrer Agilität durch den Einsatz einer serviceorientierten Architektur (SOA) zu unterstützen. Insbesondere soll das hier beschriebene Modell Managern dabei helfen, den wirtschaftlichen Nutzen ihrer SOA-Vision besser zu kommunizieren und eine Grundlage für die Messung des Erfolgs zu schaffen, den ihre jeweilige Organisation durch die Einführung einer SOA erzielt. Für den weiteren Ausbau des Modells würden wir uns über Kommentare und Rückmeldungen zu erfolgreichen SOA-Implementierungen freuen. Viel Spaß bei der Lektüre! 2

5 1.0 EINFÜHRUNG UND MOTIVATION In einem Umfeld, in dem der strategische Wert der Informationstechnik in Frage gestellt wird 1 und jede IT- und Softwareentwicklungsorganisation unter Kostendruck steht, gerät mitunter auch der strategische wirtschaftliche Nutzen von Technologie in Vergessenheit. Im Bestreben um Kostenreduzierungen denken Unternehmen sehr oft in erster Linie an Outsourcing oder Offshoring, während der wirtschaftliche Nutzen neuer Technologien in ihren Überlegungen eine eher untergeordnete Rolle spielt. In diesem Whitepaper soll aufgezeigt werden, wie technische und fachliche Organisationen mit einem neuen Ansatz für die Entwicklung und Implementierung von Informationstechnologien, insbesondere SOAs (serviceorientierten Architekturen), in mehreren Dimensionen die Grundlage für eine bessere Zusammenarbeit und die Steigerung ihrer Leistungsfähigkeit schaffen können. Dies beinhaltet nicht nur Kostenreduzierungen, sondern auch eine effizientere Implementierung neuer Geschäftsmodelle. Im Einzelnen sollen mit diesem Whitepaper folgende Voraussetzungen geschaffen werden: > Eine Diskussionsgrundlage, mit der Organisationen verstehen können, wie die Einführung einer SOA erfolgen sollte. > Eine Darstellung der geschäftlichen Vorteile, die durch den erfolgreichen Wechsel zu einer SOA erzielt werden können, wobei zwischen mehrere Reifestufen der SOA- Implementierung unterschieden wird. > Ein aussagekräftiges Vokabular und ein Kontext, in dem Organisationen die Aufgaben der IT-Organisation und des Unternehmens miteinander in Einklang bringen können. > Die Grundlage für die Entwicklung einer Roadmap zur Realisierung einer wirklichen Agilität durch die erfolgreiche Einführung einer SOA. SOA ist ein Ansatz für die Entwicklung und Implementierung von Informationssystemen, bei denen das System aus Komponenten entsteht, mit denen einzelne fachliche Funktionen implementiert werden. Diese als Services bezeichneten Komponenten können über verschiedene geografische Standorte und Unternehmen verteilt und bei Bedarf zu neuen Geschäftsprozessen umkonfiguriert werden. 1 Carr, Nicholas G., Does IT Matter?, Harvard Business School Press,

6 Neue Technologien und die daran geknüpften Erwartungen werden stets skeptisch beäugt. Deshalb stellt sich die Frage, inwiefern sich SOAs von früheren Ansätzen unterscheiden. Zur Beantwortung dieser Frage sind verschiedene Aspekte von Bedeutung: > SOAs basieren auf den Standards des Internets, wodurch eine kostengünstige globale Implementierung mit umfassender Unterstützung von Herstellern ermöglicht wird. > Services sind lose gekoppelt, so dass im Vergleich zu älteren Technologien eine wesentlich größere Flexibilität gewährleistet wird, indem entsprechende Services wiederverwendet und neu miteinander kombiniert werden, um sowohl innerhalb des Unternehmens als auch über das Unternehmen hinaus neue Geschäftsfunktionen zu realisieren. > Durch SOA Best Practices entstehen Konstrukte, die die realen Geschäftsprozesse verkörpern und damit eine bessere Voraussetzung für die Ausgliederung und Ausdehnung von Prozessen auf Geschäftspartner schaffen. > In eine SOA können auch Altsysteme und vorhandene Prozesse eingebunden werden, so dass der Nutzen vorhandener Investitionen erhalten oder gar gesteigert werden kann. Die Kombination dieser Faktoren macht SOA zu einem Ansatz, der für alle Beteiligten von Vorteil ist: > Die Finanzorganisation verzeichnet eine höhere Kosteneffizienz. > Die Fachorganisation verzeichnet eine Verbesserung und Erweiterung der Geschäftsmodelle (was weiter unten anhand von Beispielen dargestellt wird). > Die IT-Organisation kann eine bessere Unterstützung ihrer Kunden und die Einhaltung von Service-Vereinbarungen sicherstellen und verfügt über eine höhere Agilität, um flexibel auf zukünftige Anforderungen zu reagieren. > Die Unternehmensleitung kann die Ziele der IT- und Fachorganisationen besser aufeinander abstimmen. Um zu ermitteln, wie die Vorteile einer SOA realisiert werden können, um die erforderlichen Investitionen zu rechtfertigen, um den Ausgangspunkt festzulegen und um die anzustrebende Vision zu definieren, benötigen Unternehmen Hilfestellung. Eine Lösung für dieses Problem ist das in diesem Whitepaper vorgestellte SOA Maturity 4

7 Model, mit dem aus der geschäftlichen Perspektive aufgezeigt werden soll, welche positiven Auswirkungen die Einführung einer SOA haben kann. Zur Entwicklung der Reifestufen trugen im Wesentlichen drei Faktoren bei: > Der Erfolg des CMM-Modells (Capability Maturity Model ) sowie des neueren CMMI SM Konzepts (CMM Integration) 2 des Software Engineering Institute (SEI) bei der Schaffung eines gemeinsamen Rahmens für die Definition und Bewertung der Verbesserung von Prozessen bei Softwareprojekten und anderen technischen Vorhaben. > Publikationen wie jene von Randy Heffner von Forrester Research 3, in denen erfolgreiche Wege zur Einführung einer SOA dargestellt werden. > Der Erfolg unserer Kunden bei der Realisierung von SOA-Projekten. Indem SOA in einen Rahmen eingebettet wird, der dem Capability Maturity Model ähnelt, können wir die Ziele, die Eigenschaften und die Voraussetzungen für den geschäftlichen Erfolg von SOAs in verschiedenen Stufen aufzeigen: Neue Funktionalitäten Kostenreduzierung Reaktionsfähigkeit des Unternehmens Transformation von Business Prozessen Optimierung von Business Prozessen Das SOA Maturity Model definiert nicht nur die Ziele, den Umfang und die geschäftlichen Vorteile auf den einzelnen Stufen, sondern beinhaltet auch wichtige Industriestandards, wesentliche Methoden sowie entscheidende (sowohl technische als auch organisatorische) Erfolgsfaktoren. Somit unterstützt das SOA Maturity Model Unternehmen bei der Festlegung der SOA-Vision und der Definition von Kriterien für die Messung des Fortschritts. Forrester Research hat festgestellt, dass Unternehmen bei der Einführung einer SOA unterschiedlich vorgehen und nicht nur unterschiedliche Anforderungen an die durch SOA erzielten geschäftlichen Vorteile stellen, sondern auch über unterschiedliche Voraussetzungen im Hinblick auf vorhandene Fertigkeiten und Technologieinfrastrukturen verfügen. Während sich einige Unternehmen auf die interne Integration und die Optimierung interner Arbeitsabläufe konzentrieren, steht bei anderen Unternehmen die Integration von Partnerunternehmen im Mittelpunkt. Bei der Verfolgung der für die jeweiligen organisatorischen Anforderungen am besten geeigneten Wege und Ziele können Unternehmen anhand des Maturity Models erkennen, welche organisatorischen und technologischen Anforderungen und Ziele berücksichtigt werden müssen, um eine höhere SOA-Reifestufe zu erreichen. 2 Software Engineering Institute, Capability Maturity Model Integration, 3 Heffner, Randy, Your Paths to Service-Oriented Architecture, Forrester Research, Dec

8 2.0 WAS IST EINE SOA (SERVICEORIENTIERTE ARCHITEKTUR)? SOAs sind das Ergebnis der Evolution in der verteilten Datenverarbeitung und ermöglichen die Interaktion von Softwarekomponenten, so genannter Services, über ein Netzwerk. Durch die Zusammenstellung solcher Services entstehen Applikationen. Ein besonderer Aspekt ist die Tatsache, dass die Services dabei von mehreren Applikationen gemeinsam genutzt werden können. So könnte beispielsweise eine Personalmanagementapplikation aus den folgenden Services zusammengestellt werden: > Ein Mitarbeiterverwaltungsservice, mit dem die Einstellung von Mitarbeitern, die Änderung ihres Status und die Beendigung des Arbeitsverhältnisses verwaltet werden kann. > Ein Gehalts- und Leistungsbeurteilungsservice für die Verwaltung von Gehaltsaspekten und Leistungsbeurteilungen auf der Grundlage der Standards des jeweiligen Unternehmens. > Ein Service für die Verwaltung von Sozialleistungen. > Ein IT-Sicherheits- und Bereitstellungsservice, mit dem die Vergabe von Zugangsberechtigungen für Mitarbeiter auf der Grundlage ihrer jeweiligen Rolle und ihres jeweiligen Status verwaltet wird. > Ein Lohn- und Gehaltsservice, der durch einen externen Dienstleister über eine sichere Internetverbindung bereitgestellt wird. > Ein Portalservice der Personalabteilung, in dem Mitglieder der Personalabteilung die Funktionen der vorgenannten Services über eine Web-Browser-Schnittstelle präsentieren können. > Ein Geschäftsprozess-Verwaltungsservice, mit dem die Genehmigung von Geschäftsprozessen und die entsprechende Benachrichtigung der Nutzer verwaltet werden kann. Durch eine SOA können Organisationen eine größere Nutzung vorhandener Ressourcen sicherstellen und schneller auf veränderte Anforderungen reagieren. Möglich ist dies durch mehrere wichtige Elemente der SOA: 6

9 > Die Services spiegeln Fachtätigkeiten logisch wider. In der Regel werden mit jedem Service mehrere Aufgaben einer bestimmten fachlichen Funktion durchgeführt. Im Lohn- und Gehaltsservice beispielsweise gehört hierzu die Veranlassung der Gehaltsüberweisung, die Abführung der Lohnsteuer und die Ausstellung des Lohn- und Gehaltsberichts für den jeweiligen Zeitraum. Diese Services werden oft als "grobkörnig" bezeichnet und spiegeln Konzepte von Geschäftsprozessen wider, nicht jedoch die Funktionen oder "feinkörnigen" APIs, die durch herkömmliche Anwendungspakete definiert werden. > Neue Services können hinzugefügt oder geschaffen werden, indem vorhandene Services zusammengestellt werden, ohne dass vorhandene Implementierungen von Services beeinträchtigt werden 4. So könnte im vorgenannten Beispiel eine Self- Service-Komponente für Mitarbeiter hinzugefügt werden, die auf vorhandene Services zurückgreift und die für die jeweiligen Self-Service-Nutzer relevanten Daten bzw. Vorgänge herausfiltert. Auf diese Weise können Services schrittweise implementiert werden. > Services können in heterogenen Systemen, in verschiedenen Netzwerken und an verschiedenen Standorten implementiert sein, wodurch nicht nur eine umfassende Plattformunabhängigkeit, sondern auch eine vollständige Standorttransparenz erzielt wird. Die einzelnen Services müssen weder mit der gleichen Software- oder Hardwaretechnologie noch im gleichen Netzwerk oder am gleichen Standort implementiert sein. So könnte der Gehalts- und Leistungsbeurteilungsservice an einem Standort mit einer COBOL-Umgebung auf einem Linux/Mainframe-Server implementiert sein, während der IT-Sicherheits- und Bereitstellungsservice in einer Microsoft.NET- Umgebung auf einem Windows-Server, der sich an einem anderen Ort befindet, implementiert sein könnte. > Services kommunizieren über Standardprotokolle, wodurch eine umfassende Interoperabilität gewährleistet wird. In der Regel, speziell bei der Anbindung heterogener Systeme, basieren diese Protokolle auf Internetstandards. Bei Web Services handelt es sich somit um Implementierungen von Services, die auf diesen Standards beruhen. Amazon und ebay sind bekannte Beispiele für Unternehmen, die ihre Kernapplikationen über das Internet als Web Services für die Nutzer bereitgestellt haben. 4 Wenn vorhandene Services durch neue "Verbraucher" erweitert werden, müssen Sicherheitsvorgaben und etwaige Service Level Agreements (SLAs) berücksichtigt werden. 7

10 > Altapplikationen können als Service integriert werden, der vorhandene Ressourcen nutzt. Die SOA-Technologie stellt Mechanismen bereit, mit denen vorhandene Systeme in eine Services-Schnittstelle eingepackt werden können, ohne die vorhandenen Systeme modifizieren zu müssen. Darüber hinaus können traditionelle ERP-Anbieter die Funktionalität ihrer Applikationen dadurch schnell in Form von Web Services bereitstellen. > Services haben eine Schnittstelle und sind nachrichtenorientiert. Die von Services bereitgestellte Funktionalität wird durch Metadaten definiert, mit denen die Schnittstelle zum Service und dessen Aufgaben beschrieben wird. Zwischen den Services werden Informationen in Form von Messages übertragen. Bei der Definition der Schnittstelle und der entsprechenden Nachrichten liegt der Schwerpunkt nicht darauf, "wie" ein Service etwas tut, sondern, "was" er tut. Das Wie wird intern, d.h. in der Implementierung des Service, definiert. SOA-Applikationen werden gewöhnlich so gestaltet, dass sie ereignisgesteuert sind, d.h. auf eingehende Nachrichten reagieren. Die Implementierung einer SOA erfordert Kenntnisse und Fertigkeiten, Methoden und eine SOA-Infrastruktur, die die SOA-Applikation in zuverlässiger, skalierbarer und sicherer Weise unterstützt. Zu den Grundelementen dieses neuen Ansatzes gehören folgende Aspekte: > Analyse-, Konstruktions- und Implementierungsmethoden, die Projektleitern, Entwicklern und IT-Mitarbeitern bei der schnellen Entwicklung, Zusammenstellung und Wiederverwendung von SOA-Komponenten helfen. > Modellierungs-, Konfigurations-, Test- und Implementierungs Tools zur Spezifizierung und Schaffung der Services sowie zur anschließenden Definition von Geschäftsprozessen, mit denen die auf der tieferen Ebene implementierten Services koordiniert und zu gröber strukturierten fachlichen Services zusammengefügt werden. > Ein Enterprise Service Bus 5 (ESB) für eine zuverlässige, skalierbare und verteilte Kommunikation und Datentransformation zwischen Services sowie für die Bereitstellung von Adaptern zu Alttechnologien und Implementierungen verschiedener Hersteller. 5 Chappell, David, Enterprise Service Bus, O Reilly,

11 > Eine Registry und Datenbank für Services und Richtlinien, um einen einheitlichen Ort für die Organisation, Analyse und Verwaltung von SOA-Informationen und einen Katalog aller vorhandenen Services, ihrer Schnittstellendefinitionen sowie der jeweils geltenden Benutzungsrichtlinien zu schaffen. > Bereitstellungs- und Infrastrukturmanagement-Tools, um eine umfassende Transparenz von Geschäftsprozessen (engl. 'Business Process Visibility' - BPV) in einer weit verteilten SOA-Infrastruktur sicherzustellen. > Runtime Governance zur Definition und Sicherstellung der Kontrolle über Sicherheitsund Geschäftsrichtlinien sowie zur Einhaltung gesetzlicher Vorschriften für unterschiedliche Softwareklassen, wobei die zugrundeliegenden Geschäftsprozesse widergespiegelt werden müssen. 3.0 DAS SOA MATURITY MODEL Die Einführung einer SOA bietet technischen und fachlichen Organisationen von Unternehmen die Möglichkeit, ihr Augenmerk verstärkt auf die Erreichung der allgemeinen Ziele des Unternehmens zu richten. Dabei kann ein SOA Maturity Model nicht nur zur Festlegung von Zielen beitragen, sondern als Orientierungshilfe dafür dienen, wie der Nutzen einer SOA für das Unternehmen optimiert werden kann. Abbildung 1 zeigt in aufsteigender Folge die fünf Stufen der SOA-Reife sowie die entsprechenden Auswirkungen: Initial-Services, Architektur-Services, Business Services und Kollaborative Services (mit zwei unterschiedlichen Schwerpunkten in Stufe 3), Messbare Business Services sowie Optimierte Business Services. Zum Vergleich sind auch die entsprechenden CMMI SM -Stufen aufgeführt 6. 6 Kurz dargestellt, bedeutet CMMI SM Performed, dass die benötigten Funktionen durchgeführt werden. CMMI SM Defined bedeutet, dass Standardprozesse definiert sind; CMMI SM Managed bedeutet, dass die Standardprozesse implementiert sind und verwaltet werden; CMMI SM Quantitatively Managed bedeutet, dass die Resultate der Prozesse anhand von Zielvorgaben gemessen werden; CMMI SM Optimizing bedeutet, dass ein Prozess zur kontinuierlichen Verbesserung auf der Grundlage der gemessenen Resultate implementiert worden ist. 9

12 Abbildung 1. Die fünf SOA-Reifestufen und deren Auswirkungen Tabelle 1 zeigt die wesentlichen Charakteristika der einzelnen Reifestufen, d.h. die geschäftlichen Auswirkungen, den Umfang, die entscheidenden Erfolgsfaktoren sowie die jeweils relevanten Standards. Wie beim SEI-Ansatz für das Capability Maturity Model sind in Tabelle 2 wesentliche Ziele und Maßnahmen für die einzelnen SOA-Reifestufen aufgeführt. Das Erreichen dieser Ziele und die Umsetzung dieser Methoden sind ausschlaggebend für die Ermittlung der jeweiligen Reifestufe. Bei jeder Reifestufe müssen die Ziel- und Methodenanforderungen der jeweils darunter liegenden Reifestufen erfüllt sein. Oft werden auf niedrigeren als auf den in Tabelle 1 und 2 aufgeführten Stufen bestimmte Ziele erreicht, Praktiken implementiert und Technologien genutzt. Ja nach dem, welche Prioritäten das Unternehmen gesetzt hat, ist dies zu erwarten und durchaus zu empfehlen. Eine nähere Beleuchtung der einzelnen SOA-Reifestufen erfolgt in den folgenden Abschnitten. 10

13 Tabelle 1 - Arten der SOA-Reife Reifestufe Wesentliche geschäftliche Vorteile Umfang Entscheidende Faktoren für den Erfolg der Technologie Entscheidende personelle und organisatorische Erfolgsfaktoren Relevante Standards Auswahl) 1. Initial-Services Neue Funktionalität Experimentelle F&E- Projekte, Pilotprojekte, Integration von Websites und Portalen, individuelle Integrations- Maßnahmen, kleine Anzahl von Services Standards, Integration von Altsystemen Entwickler erwerben Fertigkeiten für die Entwicklung von Services Unterstützung durch den Leiter der Entwicklungsabteilung XML, XSLT, WSDL, SOAP, J2EE,.NET 2. Architektur- Services Kostensenkung und bessere Kontrolle im IT Bereich Integration mehrerer Applikationen Unterstützung heterogener und verteilter Systeme, zuverlässige Nachrichtenübermittlung, Vermittlung zwischen Services, einfache Implementierung, Integration von Datenbanken, Versionsverwaltung, interne Sicherheit, Performance- Management Architekturgruppe übernimmt Leitungsfunktion, SOA-Kompetenzzentrum Unterstützung durch CIO UDDI, WS- ReliableMessagi ng, WS-Policy, WS- Addressing, XQuery, WS- Security, SAML 3.a. Business Services Steigerung der Reaktionsfähigkeit im geschäftlichen Bereich - Schnelle und effektive Änderung von Geschäftsprozessen Geschäftsprozesse innerhalb eines Geschäftsbereichs oder Unternehmens Wiederverwendung, einfache Modifizierung, Verfügbarkeit, Geschäftsprozessregeln, ereignisgesteuerte Prozesse, zusammengesetzte Applikationen Organisationsübergreifende Partnerschaft zwischen ITund Fachabteilungen, SOA Lifecycle Governance, Nachdrückliche Unterstützung durch Management, ereignisgesteuerte Entwicklungsfertigkeiten WS-BPEL 3.b. Kollaborative Services Steigerung der Reaktionsfähigkeit im geschäftlichen Bereich - Zusammenarbeit mit Geschäfts- und Handelspartnern Services werden für externe Partner verfügbar gemacht, unternehmensübergreifend Schaffung der Voraussetzungen für die externe Nutzung von Services, unternehmensübergreifende Sicherheit, Übersetzung unternehmensübergreifender Protokolle, Transaktionen mit langer Laufzeit Unterstützung durch Leiter des Geschäftsbereichs RosettaNet, ebxml, WS- Trust 4. Messbare Business Services Transformation der geschäftlichen Aktivitäten von reagierend zu Echtzeit, Einhaltung geschäftlicher Leistungskriterien Geschäftsbereich, unternehmensweit oder unternehmensübergreifend BAM (Business Activity Monitoring), ESP (Event Stream Processing), CEP (Complex Event Processing), ereignisgesteuerte Dashboards und Alarme Ständige Evaluation von Geschäftsprozessen mit aktiver Ergreifung von Maßnahmen Unterstützung durch CFO 5. Optimierte Business Services Optimierung der geschäftlichen Aktivitäten - Automatisches Reagieren und Handeln Geschäftsbereich, unternehmensweit oder unternehmensübergreifend Optimierung durch ereignisgesteuerte Automatisierung Kultur der kontinuierlichen Verbesserung Unterstützung durch CEO 11

14 Tabelle 2 - Ziele und bewährte Vorgehensweisen des SOA Maturity Models Reifestufe 1. Initial-Services 2. Architektur- Services 3.a. Business Services 3.b. Kollaborative Services 4. Messbare Business Services 5. Optimierte Business Services Hauptziele 1. Erlernen der SOA-Technologie in F&Eund Pilotprojekten. 2. Anwendung der SOA-Technologie für unmittelbare organisatorische Erfordernisse. 3. Definition erster ROI-Kriterien für SOA- Projekte und Anwendung für erste Projekte. 1. Institutionalisierung der SOA-Nutzung. 2. Festlegung der Zuständigkeit und Leitung für Fragen der SOA-Architektur. 3. Nachweis des Nutzens von Standardtechnologien. 4. Prognostizierung der Nutzung von SOA- Informationen zur Optimierung von Geschäftsprozessen. 1. Schaffung einer kontinuierlichen Partnerschaft zwischen fachlichen und technischen Organisationen zur Realisierung von SOA Governance. 2. Unterstützung vollständiger Geschäftsprozesse über SOA. 3. Nachweis des Nutzens, der durch die Wiederverwendung von Services und das schnellere Reagieren auf Änderungen erzielt wird. 1. Schaffung einer kontinuierlichen Partnerschaft zwischen fachlichen und technischen Organisationen zur Realisierung von SOA Governance. 2. Ausdehnung von SOA- Geschäftsprozessen auf externe Organisationen 3. Nachweis des Nutzens der Wiederverwendung von Services für die kollaborative Zusammenarbeit. 1. Realisierung einer Transformation von reagierenden hin zu in Echtzeit ablaufenden Geschäftsprozessen. 2. Definition und Einhaltung fachorientierter Leistungskriterien. 1. Realisierung einer unternehmensweiten Leitung für fachliche Aufgaben und SOA- Governance. 2. Nachweis des Nutzens einer durch SOAs unterstützten kontinuierlichen Verbesserung. Wesentliche Maßnahmen 1. Definition von Services. 2. Aufnahme des SOA-Ansatzes in die Projektentwicklungsmethodik. 3. Quantifizierung des Zeit- und Kostenaufwands und der wirtschaftlichen Vorteile von Pilotprojekten. 1. Festlegung von Technologiestandards für SOA. 2. Aufnahme des SOA-Ansatzes in den organisationsweiten Entwicklungsprozess. 3. Organisationsweite Ausbildung in SOA- Fragen und Etablierung eines SOA- Kompetenzzentrums. 4. Schrittartige Integration. 1. Festlegung von Richtlinien für den Einsatz einer SOA bei der Einrichtung oder Modifizierung von Geschäftsprozessen. 2. Nutzung ereignisorientierter und vermittelnder Funktionen von SOA- Technologien, insbesondere im Hinblick auf die Verbesserung/Erweiterung von Geschäftsprozessen. 1. Festlegung von Richtlinien für den Einsatz einer SOA bei der Zusammenarbeit mit Geschäfts- und Handelspartnern 2. Implementierung einer unternehmensübergreifenden Sicherheit. 1. Erfassung und Analyse geschäftsprozessorientierter Echtzeit-Leistungskriterien. 2. Implementierung einer kontinuierlichen Evaluation und Umgestaltung von Geschäftsprozessen. 1. Implementierung selbst korrigierender Geschäftsprozesse. 12

15 3.1 SOA REIFESTUFE 1 INITIAL-SERVICES Die SOA-Reifestufe 1 trägt die Bezeichnung Initial-Services (siehe Tabelle 1 und 2). Hierbei handelt es sich um die erste Lern- und Projektphase bei der Einführung einer SOA. Auf dieser Stufe werden Projekte gewöhnlich durchgeführt, um eine spezifische Funktionalität zu implementieren und gleichzeitig bestimmte Technologien sowie einen SOA-Ansatz auszuprobieren. Hierzu gehören auch erste F&E-Aktivitäten, bei denen die SOA-Technologien unter Laborbedingungen getestet werden. Gewöhnlich geht die erste Einführung einer SOA von der Anwendungsentwicklungsabteilung aus und erfolgt oft im Rahmen eines Anwendungsintegrationsprojekts. Dabei werden neue Entwicklerkenntnisse erworben und erste Schritte zur Quantifizierung des wirtschaftlichen Nutzens unternommen. Auf dieser Stufe werden die grundlegendsten SOA-Standards des W3C-Konsortiums 7 eingeführt, beispielsweise XML für die Definition von Nachrichtenformaten, WSDL für die Definition von Serviceschnittstellen sowie SOAP für den Aufruf von Services. Ein typisches Beispiel für ein erstes Services-Projekt ist in Abbildung 2 dargestellt, wo das unternehmensweite Web-Portal einer Vertriebsorganisation direkt an ein vorhandenes, auf dem Mainframe laufendes Sales-Forecasting-Altsystem angebunden und eine neue CRM-Applikation als Web Service bereitgestellt wird. In diesem Beispiel könnte die folgende SOA-Infrastrukturkomponente verwendet werden: > Ein Mainframe-Integrationsservice wie Shadow RTE von DataDirect, mit dem ein bidirektionaler, auf Standards basierender Web-Service-Zugang zu einem Sales Forecasting Altsystem realisiert wird, der innerhalb von CICS auf einem IBM Mainframe mit dem Betriebssystem z/os betrieben wird. > Eine extrem produktive Entwicklungsplattform, die für die Erstellung serviceorientierter Geschäftsapplikationen optimiert ist (z.b. Progress OpenEdge) und die Entwicklung und den Betrieb neuer CRM-Applikationslogik ermöglicht, auf die über Web Services zugegriffen werden kann. 7 World Wide Web Consortium, Web Services Activity, 13

16 Abbildung 2: Beispielapplikation für Reifestufe 1: Initial-Services Die Hauptvorteile eines solchen ersten Projekts bestehen darin, dass die fachliche Funktion bereitgestellt wird und gleichzeitig die Kenntnisse und Fertigkeiten erworben werden, die für die Entwicklung und Implementierung einer SOA-Basisapplikation erforderlich sind. Eine entsprechende Implementierung würde das SOAP-Protokoll für die Kommunikation zwischen dem Portalserver und den unterstützenden Services sowie für den Sales Forecasting & Tracking Service benutzen, um Informationen aus der CRM- Applikation zu erhalten. Selbst eine solche erste Basisapplikation könnte von der Nutzung einiger der zusätzlichen SOA-Infrastrukturkomponenten profitieren. Neben der Tatsache, dass bereits sehr früh mit dem Erwerb von Kenntnissen in der Nutzung der Technologien begonnen wird, erfolgt die Einführung dieser modernen Technologien in erster Linie auch deshalb bei ersten Projekten, um eine skalierbare Technologie zu implementieren, mit der sichergestellt wird, dass bei der Ausdehnung der SOA auf weitere Geschäftsfunktionen bereits das richtige Fundament vorhanden ist. So werden beispielsweise in Abbildung 3 die folgenden Komponenten hinzugefügt: 14

17 > Ein Runtime Governance Service wie der von Actional, welcher die Überwachungsund Kontrollmechanismen bereitstellt, mit denen die jeweiligen Service- und Sicherheitsrichtlinien für sämtliche Schritte innerhalb eines Geschäftsprozesses bei heterogenen SOA-Infrastrukturelementen angewandt werden. > Ein Enterprise Service Bus (ESB) wie jener von Sonic, der ein standardisiertes Interaktionsmodell für SOA-Komponenten wie Web Services und relationale Datenbanken als skalierbare, einfach zu implementierende verteilte Infrastruktur bereitstellt. Der ESB enthält eine große Anzahl von Adaptern, die dafür sorgen, dass in unterschiedlichen Technologien implementierte Services Nachrichten austauschen können. Auf diese Weise kann beispielsweise eine.net Applikation auf der Ebene der Services mit einer J2EE Applikation kommunizieren. > Eine Services Registry, die den UDDI-Standard unterstützt. Auf diese Weise wird für alle anfänglichen Projekte ein zentrales Register mit Servicedefinitionen aufgebaut, auf das Serviceentwickler zurückgreifen können, um die Definitionen von Services zu erhalten. Abbildung 3: Erweiterte SOA-Infrastruktur für SOA-Reifestufe 1: Initial-Services 15

18 3.2 SOA REIFESTUFE 2 ARCHITEKTUR SERVICES Bei SOA-Reifestufe 2 handelt es sich um Architektur-Services (siehe Tabelle 1 und 2). Auf dieser Stufe werden Standards für die technische Organisation der SOA-Implementierung festgelegt, typischerweise unter der Leitung der Architekturorganisation. Der wichtigste wirtschaftliche Vorteil dieser Stufe besteht darin, dass die Entwicklungs- und Implementierungskosten im Vergleich zu älteren Technologien oder im Vergleich zu den kumulativen Kosten mehrerer Einzelprojekte durch den Einsatz von SOA- Standardinfrastrukturen und -komponenten reduziert werden. In den heterogenen Umgebungen, die in den meisten Unternehmen anzutreffen sind, sind diese Vorteile in der Regel noch größer. Auf der Grundlage der in Reifestufe 1 erworbenen Kenntnisse und Erfahrungen, werden Architekturstandards und Standardtechnologien für die Implementierung definiert, z.b.: > Auswahl der zu verwendenden Enterprise-SOA-Protokolle auf der Grundlage von Industriestandards wie W3C, OASIS 8 und WS-I 9. > Zu verwendende Implementierungsplattformen. > Richtlinien für Wiederverwendung, Runtime Governance, Compliance und Sicherheit. > Technischer Überprüfungsprozess für die Definition neuer Services und die Wiederverwendung vorhandener Services. Abbildung 4 zeigt ein SOA-Beispiel der Reifestufe 2 für eine Implementierung im Finanzhandel. Reifestufe 2 beinhaltet die Nutzung der in Abbildung 3 gezeigten Kernkomponenten (d.h. Runtime Governance Service und Enterprise Service Bus) sowie der zusätzlichen Hauptelemente dieses Beispiels: > Ein Repository, das die Services Registry erweitert und die Speicherung von SOA- Artefakten und Richtlinieninformationen ermöglicht. Weitere wichtige Elemente, über die an dieser Stelle nachgedacht werden muss, sind Lifecycle-Support-Aspekte wie Zugangskontroll-, Versionsverwaltungs- und Implementierungs Tools. Die Nutzung eines solchen Repositorys mit Entwicklungs- und Laufzeitunterstützung ist Bestandteil der Reifestufe 2 (Architektur-Services). 8 OASIS, OASIS Committees by Category: Web Services and SOA, 9 WS-I, Web Services Interoperability Organization, 16

19 > Ein modifizierter Runtime Governance Service, der Services und die zwischen ihnen bestehenden Abhängigkeiten identifiziert und damit eine geeignete Grundlage schafft, um sowohl System- als auch Applikationsfehler zu erkennen, zu diagnostizieren und automatisch zu beheben. > Ein Message Transformation Service, der die Integration von Services ermöglicht, die sich im Hinblick auf die erwarteten Nachrichteninhalte oder -formate voneinander unterscheiden. Oft wird dies realisiert, indem XLST-Transformationen aufgerufen und auf eine XML-Nachricht angewandt werden - in diesem Fall als Mittler -Funktion unter der Kontrolle des ESB. > Ein Single Sign-On Service, der eine organisationsweite Authentifizierung und Autorisierung von Benutzern unterstützt. Entsprechende Services werden oft von einem Softwarehersteller bezogen und könnten auf dem OASIS SAML-Standard für den Austausch von Authentifizierungs- und Autorisierungsinformationen basieren. Abbildung 3: Erweiterte SOA-Infrastruktur für SOA-Reifestufe 1: Initial-Services 17

20 3.3 SOA REIFESTUFE 3 BUSINESS SERVICES UND KOLLABORATIVE SERVICES Der Schwerpunkt der SOA-Reifestufe 3 liegt auf der Partnerschaft zwischen technischen und fachlichen Organisationen. Damit soll sichergestellt werden, dass die Reaktionsfähigkeit des Unternehmens durch die Nutzung einer SOA deutlich gesteigert wird. Ein wesentlicher Vorteil der SOA ist die in Abbildung 5 dargestellte Verknüpfung zwischen geschäftlichen und digitalen Prozessen. Abbildung 5: Die Stärke von SOA: Modellierung von Geschäftsprozessen (angelehnt an Forrester Research) 10 SOA-Reifestufe 3 wird durch zwei komplementäre Pfade definiert, mit denen diese Ziele realisiert werden: Der erste Pfad, Business Services, konzentriert sich auf die Verbesserung interner Geschäftsprozesse, während im Mittelpunkt des zweiten Pfads (Kollaborative Services) die Verbesserung der kollaborativen Prozesse im Rahmen der Zusammenarbeit mit externen Partnern steht (siehe Tabelle 1 und 2). Natürlich können beide Wege beschritten werden, so dass mit der SOA optimale Ergebnisse erzielt werden, jedoch kann Reifestufe 3 auch durch einem der beiden Wegen erreicht werden, da in beiden Fällen die Reaktionsfähigkeit des Unternehmens gesteigert wird. 18