SOA MATURITY MODEL, EIN VORGEHENSMODELL ZUR …cdn.crn.de/fileadmin/whitepapers/files/progress_soa_maturity_model_vor... · INHALT > Vorwort 2 > 1.0 Einführung und Motivation 3 >

SOA MATURITY MODEL, EIN VORGEHENSMODELL ZUR EINFÜHRUNG EINERSERVICEORIENTIERTENARCHITEKTUR

WHITE PAPER

Copyright ©2007. Progress Software Corporation. All rights reserved.

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 IhrUnternehmen 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 undandere Materialien, die im Zusammenhang mit dem SOA Maturity Models bereitgestelltwerden; dies gilt auch für den dazugehörigen Text sowie Beschriftungen vonAbbildungen.

Sie sind nicht berechtigt, Copyright-Vermerke oder andere Hinweise zum geistigenEigentum zu entfernen, die in den SOA-Materialien oder anderen damitzusammenhängenden Materialien, die Ihnen zur Verfügung gestellt wurden, enthaltensind. Wenn Sie daran interessiert sind, eigene Arbeiten bzw.

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 9

3.1 SOA-Reifestufe 1 – Initial-Services 11

3.2 SOA-Reifestufe 2 – Architektur-Services 16

3.3 SOA-Reifestufe 3 - Business Services und Kollaborative Services 18

3.4 SOA-Reifestufe 4 - Messbare Business Services 22

3.5 SOA-Reifestufe 5 - Optimierte Business Services 23

> 4.0 Schluss 25

1

Copyright ©2007. Progress Software Corporation. All rights reserved.2

VORWORT

Das in diesem Whitepaper vorgestellte Modell wurde entwickelt, um Unternehmen beider Steigerung ihrer Agilität durch den Einsatz einer serviceorientierten Architektur(SOA) zu unterstützen. Insbesondere soll das hier beschriebene Modell Managern dabeihelfen, den wirtschaftlichen Nutzen ihrer SOA-Vision besser zu kommunizieren und eineGrundlage für die Messung des Erfolgs zu schaffen, den ihre jeweilige Organisationdurch die Einführung einer SOA erzielt.

Für den weiteren Ausbau des Modells würden wir uns über Kommentare undRückmeldungen zu erfolgreichen SOA-Implementierungen freuen.

Viel Spaß bei der Lektüre!

3Copyright ©2007. Progress Software Corporation. All rights reserved.

1.0 EINFÜHRUNG UND MOTIVATION

In einem Umfeld, in dem der strategische Wert der Informationstechnik in Frage gestelltwird1 und jede IT- und Softwareentwicklungsorganisation unter Kostendruck steht, gerätmitunter auch der strategische wirtschaftliche Nutzen von Technologie in Vergessenheit.Im Bestreben um Kostenreduzierungen denken Unternehmen sehr oft in erster Linie anOutsourcing oder Offshoring, während der wirtschaftliche Nutzen neuer Technologien inihren Überlegungen eine eher untergeordnete Rolle spielt.

In diesem Whitepaper soll aufgezeigt werden, wie technische und fachlicheOrganisationen mit einem neuen Ansatz für die Entwicklung und Implementierung vonInformationstechnologien, insbesondere SOAs (serviceorientierten Architekturen), inmehreren Dimensionen die Grundlage für eine bessere Zusammenarbeit und dieSteigerung ihrer Leistungsfähigkeit schaffen können. Dies beinhaltet nicht nurKostenreduzierungen, sondern auch eine effizientere Implementierung neuerGeschäftsmodelle. Im Einzelnen sollen mit diesem Whitepaper folgendeVoraussetzungen geschaffen werden:

> Eine Diskussionsgrundlage, mit der Organisationen verstehen können, wie dieEinführung einer SOA erfolgen sollte.

> Eine Darstellung der geschäftlichen Vorteile, die durch den erfolgreichen Wechsel zueiner 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 Aufgabender IT-Organisation und des Unternehmens miteinander in Einklang bringen können.

> Die Grundlage für die Entwicklung einer Roadmap zur Realisierung einer wirklichenAgilitä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 fachlicheFunktionen implementiert werden. Diese als “Services” bezeichneten Komponentenkönnen über verschiedene geografische Standorte und Unternehmen verteilt und beiBedarf zu neuen Geschäftsprozessen umkonfiguriert werden.

1Carr, Nicholas G., Does IT Matter?, Harvard Business School Press, 2004.

Neue Technologien und die daran geknüpften Erwartungen werden stets skeptischbeäugt. Deshalb stellt sich die Frage, inwiefern sich SOAs von früheren Ansätzenunterscheiden. Zur Beantwortung dieser Frage sind verschiedene Aspekte vonBedeutung:

> SOAs basieren auf den Standards des Internets, wodurch eine kostengünstige globaleImplementierung mit umfassender Unterstützung von Herstellern ermöglicht wird.

> Services sind “lose gekoppelt”, so dass im Vergleich zu älteren Technologien einewesentlich größere Flexibilität gewährleistet wird, indem entsprechende Serviceswiederverwendet und neu miteinander kombiniert werden, um sowohl innerhalb desUnternehmens als auch über das Unternehmen hinaus neue Geschäftsfunktionen zurealisieren.

> Durch SOA Best Practices entstehen Konstrukte, die die realen Geschäftsprozesseverkörpern und damit eine bessere Voraussetzung für die Ausgliederung undAusdehnung 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 werdenkann.

Die Kombination dieser Faktoren macht SOA zu einem Ansatz, der für alle Beteiligten vonVorteil ist:

> Die Finanzorganisation verzeichnet eine höhere Kosteneffizienz.

> Die Fachorganisation verzeichnet eine Verbesserung und Erweiterung derGeschäftsmodelle (was weiter unten anhand von Beispielen dargestellt wird).

> Die IT-Organisation kann eine bessere Unterstützung ihrer Kunden und die Einhaltungvon Service-Vereinbarungen sicherstellen und verfügt über eine höhere Agilität, umflexibel auf zukünftige Anforderungen zu reagieren.

> Die Unternehmensleitung kann die Ziele der IT- und Fachorganisationen besseraufeinander abstimmen.

Um zu ermitteln, wie die Vorteile einer SOA realisiert werden können, um dieerforderlichen Investitionen zu rechtfertigen, um den Ausgangspunkt festzulegen und umdie anzustrebende Vision zu definieren, benötigen Unternehmen Hilfestellung. EineLösung für dieses Problem ist das in diesem Whitepaper vorgestellte SOA Maturity


Model, mit dem aus der geschäftlichen Perspektive aufgezeigt werden soll, welchepositiven Auswirkungen die Einführung einer SOA haben kann. Zur Entwicklung derReifestufen trugen im Wesentlichen drei Faktoren bei:

> Der Erfolg des CMM-Modells (Capability Maturity Model®) sowie des neueren CMMISM

Konzepts (CMM Integration)2 des Software Engineering Institute (SEI) bei derSchaffung eines gemeinsamen Rahmens für die Definition und Bewertung derVerbesserung von Prozessen bei Softwareprojekten und anderen technischenVorhaben.

> Publikationen wie jene von Randy Heffner von Forrester Research3, in denenerfolgreiche 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äftlichenErfolg von SOAs in verschiedenen Stufen aufzeigen:

Das SOA Maturity Model definiert nicht nur die Ziele, den Umfang und die geschäftlichenVorteile auf den einzelnen Stufen, sondern beinhaltet auch wichtige Industriestandards,wesentliche Methoden sowie entscheidende (sowohl technische als auchorganisatorische) Erfolgsfaktoren. Somit unterstützt das SOA Maturity ModelUnternehmen bei der Festlegung der SOA-Vision und der Definition von Kriterien für dieMessung des Fortschritts.

Forrester Research hat festgestellt, dass Unternehmen bei der Einführung einer SOAunterschiedlich vorgehen und nicht nur unterschiedliche Anforderungen an die durchSOA erzielten geschäftlichen Vorteile stellen, sondern auch über unterschiedlicheVoraussetzungen im Hinblick auf vorhandene Fertigkeiten und Technologieinfrastrukturenverfügen. Während sich einige Unternehmen auf die interne Integration und dieOptimierung interner Arbeitsabläufe konzentrieren, steht bei anderen Unternehmen dieIntegration von Partnerunternehmen im Mittelpunkt. Bei der Verfolgung der für diejeweiligen organisatorischen Anforderungen am besten geeigneten Wege und Zielekönnen Unternehmen anhand des Maturity Models erkennen, welche organisatorischenund technologischen Anforderungen und Ziele berücksichtigt werden müssen, um einehöhere SOA-Reifestufe zu erreichen.


2Software Engineering Institute, Capability Maturity Model® Integration, http://www.sei.cmu.edu/cmmi.3Heffner, Randy, “Your Paths to Service-Oriented Architecture”, Forrester Research, Dec. 2004.

NeueFunktionalitäten

Kostenreduzierung Reaktionsfähigkeitdes Unternehmens

Transformation vonBusiness Prozessen

Optimierung vonBusiness Prozessen

2.0 WAS IST EINE SOA (SERVICEORIENTIERTE ARCHITEKTUR)?

SOAs sind das Ergebnis der Evolution in der verteilten Datenverarbeitung undermöglichen die Interaktion von Softwarekomponenten, so genannter “Services”, überein Netzwerk. Durch die Zusammenstellung solcher Services entstehen Applikationen.Ein besonderer Aspekt ist die Tatsache, dass die Services dabei von mehrerenApplikationen gemeinsam genutzt werden können.

So könnte beispielsweise eine Personalmanagementapplikation aus den folgendenServices zusammengestellt werden:

> Ein Mitarbeiterverwaltungsservice, mit dem die Einstellung von Mitarbeitern, dieÄnderung ihres Status und die Beendigung des Arbeitsverhältnisses verwaltet werdenkann.

> Ein Gehalts- und Leistungsbeurteilungsservice für die Verwaltung vonGehaltsaspekten und Leistungsbeurteilungen auf der Grundlage der Standards desjeweiligen Unternehmens.

> Ein Service für die Verwaltung von Sozialleistungen.

> Ein IT-Sicherheits- und Bereitstellungsservice, mit dem die Vergabe vonZugangsberechtigungen für Mitarbeiter auf der Grundlage ihrer jeweiligen Rolle undihres jeweiligen Status verwaltet wird.

> Ein Lohn- und Gehaltsservice, der durch einen externen Dienstleister über einesichere Internetverbindung bereitgestellt wird.

> Ein Portalservice der Personalabteilung, in dem Mitglieder der Personalabteilung dieFunktionen der vorgenannten Services über eine Web-Browser-Schnittstellepräsentieren können.

> Ein Geschäftsprozess-Verwaltungsservice, mit dem die Genehmigung vonGeschäftsprozessen und die entsprechende Benachrichtigung der Nutzer verwaltetwerden kann.

Durch eine SOA können Organisationen eine größere Nutzung vorhandener Ressourcensicherstellen und schneller auf veränderte Anforderungen reagieren. Möglich ist diesdurch mehrere wichtige Elemente der SOA:


> Die Services spiegeln Fachtätigkeiten logisch wider. In der Regel werden mit jedemService mehrere Aufgaben einer bestimmten fachlichen Funktion durchgeführt. ImLohn- und Gehaltsservice beispielsweise gehört hierzu die Veranlassung derGehaltsüberweisung, die Abführung der Lohnsteuer und die Ausstellung des Lohn- undGehaltsberichts für den jeweiligen Zeitraum. Diese Services werden oft als "grobkörnig"bezeichnet und spiegeln Konzepte von Geschäftsprozessen wider, nicht jedoch dieFunktionen oder "feinkörnigen" APIs, die durch herkömmliche Anwendungspaketedefiniert werden.

> Neue Services können hinzugefügt oder geschaffen werden, indem vorhandene

Services zusammengestellt werden, ohne dass vorhandene Implementierungen von

Services beeinträchtigt werden4. So könnte im vorgenannten Beispiel eine Self-Service-Komponente für Mitarbeiter hinzugefügt werden, die auf vorhandene Serviceszurückgreift und die für die jeweiligen Self-Service-Nutzer relevanten Daten bzw.Vorgänge herausfiltert. Auf diese Weise können Services schrittweise implementiertwerden.

> 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- oderHardwaretechnologie noch im gleichen Netzwerk oder am gleichen Standortimplementiert sein. So könnte der Gehalts- und Leistungsbeurteilungsservice an einemStandort mit einer COBOL-Umgebung auf einem Linux/Mainframe-Server implementiertsein, 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 Anbindungheterogener Systeme, basieren diese Protokolle auf Internetstandards. Bei “WebServices” handelt es sich somit um Implementierungen von Services, die auf diesenStandards beruhen. Amazon und eBay sind bekannte Beispiele für Unternehmen, dieihre Kernapplikationen über das Internet als Web Services für die Nutzer bereitgestellthaben.


4 Wenn vorhandene Services durch neue "Verbraucher" erweitert werden, müssen Sicherheitsvorgaben und etwaige ServiceLevel Agreements (SLAs) berücksichtigt werden.

> Altapplikationen können als Service integriert werden, der vorhandene Ressourcen

nutzt. Die SOA-Technologie stellt Mechanismen bereit, mit denen vorhandene Systemein eine Services-Schnittstelle eingepackt werden können, ohne die vorhandenenSysteme modifizieren zu müssen. Darüber hinaus können traditionelle ERP-Anbieterdie Funktionalität ihrer Applikationen dadurch schnell in Form von Web Servicesbereitstellen.

> Services haben eine Schnittstelle und sind nachrichtenorientiert. Die von Servicesbereitgestellte Funktionalität wird durch Metadaten definiert, mit denen dieSchnittstelle zum Service und dessen Aufgaben beschrieben wird. Zwischen denServices werden Informationen in Form von Messages übertragen. Bei der Definitionder Schnittstelle und der entsprechenden Nachrichten liegt der Schwerpunkt nichtdarauf, "wie" ein Service etwas tut, sondern, "was" er tut. Das “Wie” wird intern, d.h. inder Implementierung des Service, definiert. SOA-Applikationen werden gewöhnlich sogestaltet, dass sie “ereignisgesteuert” sind, d.h. auf eingehende Nachrichtenreagieren.

Die Implementierung einer SOA erfordert Kenntnisse und Fertigkeiten, Methoden undeine SOA-Infrastruktur, die die SOA-Applikation in zuverlässiger, skalierbarer undsicherer Weise unterstützt. Zu den Grundelementen dieses neuen Ansatzes gehörenfolgende Aspekte:

> Analyse-, Konstruktions- und Implementierungsmethoden, die Projektleitern,Entwicklern und IT-Mitarbeitern bei der schnellen Entwicklung, Zusammenstellung undWiederverwendung von SOA-Komponenten helfen.

> Modellierungs-, Konfigurations-, Test- und Implementierungs Tools zur Spezifizierungund Schaffung der Services sowie zur anschließenden Definition vonGeschäftsprozessen, mit denen die auf der tieferen Ebene implementierten Serviceskoordiniert und zu gröber strukturierten fachlichen Services zusammengefügt werden.

> Ein Enterprise Service Bus5 (ESB) für eine zuverlässige, skalierbare und verteilteKommunikation und Datentransformation zwischen Services sowie für dieBereitstellung von Adaptern zu Alttechnologien und Implementierungen verschiedenerHersteller.


5Chappell, David, Enterprise Service Bus, O’Reilly, 2004

> Eine Registry und Datenbank für Services und Richtlinien, um einen einheitlichen Ortfür die Organisation, Analyse und Verwaltung von SOA-Informationen und einenKatalog aller vorhandenen Services, ihrer Schnittstellendefinitionen sowie der jeweilsgeltenden Benutzungsrichtlinien zu schaffen.

> Bereitstellungs- und Infrastrukturmanagement-Tools, um eine umfassendeTransparenz von Geschäftsprozessen (engl. 'Business Process Visibility' - BPV) in einerweit verteilten SOA-Infrastruktur sicherzustellen.

> Runtime Governance zur Definition und Sicherstellung der Kontrolle über Sicherheits-und Geschäftsrichtlinien sowie zur Einhaltung gesetzlicher Vorschriften fürunterschiedliche Softwareklassen, wobei die zugrundeliegenden Geschäftsprozessewidergespiegelt werden müssen.

3.0 DAS SOA MATURITY MODEL

Die Einführung einer SOA bietet technischen und fachlichen Organisationen vonUnternehmen die Möglichkeit, ihr Augenmerk verstärkt auf die Erreichung derallgemeinen Ziele des Unternehmens zu richten. Dabei kann ein SOA Maturity Modelnicht nur zur Festlegung von Zielen beitragen, sondern als Orientierungshilfe dafürdienen, 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 dieentsprechenden Auswirkungen: Initial-Services, Architektur-Services, Business Servicesund Kollaborative Services (mit zwei unterschiedlichen Schwerpunkten in Stufe 3),Messbare Business Services sowie Optimierte Business Services. Zum Vergleich sindauch die entsprechenden CMMISM-Stufen aufgeführt6.


6 Kurz dargestellt, bedeutet CMMISM Performed, dass die benötigten Funktionen durchgeführt werden. CMMISM Definedbedeutet, dass Standardprozesse definiert sind; CMMISM Managed bedeutet, dass die Standardprozesse implementiert sindund verwaltet werden; CMMISM Quantitatively Managed bedeutet, dass die Resultate der Prozesse anhand von Zielvorgabengemessen werden; CMMISM Optimizing bedeutet, dass ein Prozess zur kontinuierlichen Verbesserung auf der Grundlage dergemessenen Resultate implementiert worden ist.


Abbildung 1. Die fünf SOA-Reifestufen und deren Auswirkungen

Tabelle 1 zeigt die wesentlichen Charakteristika der einzelnen Reifestufen, d.h. diegeschäftlichen Auswirkungen, den Umfang, die entscheidenden Erfolgsfaktoren sowie diejeweils 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-Reifestufenaufgeführt. Das Erreichen dieser Ziele und die Umsetzung dieser Methoden sindausschlaggebend für die Ermittlung der jeweiligen Reifestufe. Bei jeder Reifestufemüssen die Ziel- und Methodenanforderungen der jeweils darunter liegenden Reifestufenerfüllt sein.

Oft werden auf niedrigeren als auf den in Tabelle 1 und 2 aufgeführten Stufen bestimmteZiele erreicht, Praktiken implementiert und Technologien genutzt. Ja nach dem, welchePrioritäten das Unternehmen gesetzt hat, ist dies zu erwarten und durchaus zuempfehlen.

Eine nähere Beleuchtung der einzelnen SOA-Reifestufen erfolgt in den folgendenAbschnitten.


Tabelle 1 - Arten der SOA-Reife

Reifestufe

1. Initial-Services

2. Architektur-Services

3.a. BusinessServices

3.b. KollaborativeServices

4. MessbareBusinessServices

5. OptimierteBusinessServices

Wesentlichegeschäftliche Vorteile

Neue Funktionalität

Kostensenkung undbessere Kontrolle im ITBereich

Steigerung derReaktionsfähigkeit imgeschäftlichen Bereich- Schnelle undeffektive Änderung vonGeschäftsprozessen

Steigerung derReaktionsfähigkeit imgeschäftlichen Bereich- Zusammenarbeit mitGeschäfts- undHandelspartnern

Transformation dergeschäftlichenAktivitäten vonreagierend zu Echtzeit,EinhaltunggeschäftlicherLeistungskriterien

Optimierung dergeschäftlichenAktivitäten -AutomatischesReagieren und Handeln

Umfang

Experimentelle F&E-Projekte, Pilotprojekte,Integration vonWebsites undPortalen, individuelleIntegrations-Maßnahmen, kleineAnzahl von Services

Integration mehrererApplikationen

Geschäftsprozesseinnerhalb einesGeschäftsbereichsoder Unternehmens

Services werden fürexterne Partnerverfügbar gemacht,unternehmensüber-greifend

Geschäftsbereich,unternehmensweitoder unternehmen-sübergreifend

Geschäftsbereich,unternehmensweitoder unternehmen-sübergreifend

Entscheidende Faktoren für denErfolg der Technologie

Standards, Integration vonAltsystemen

Unterstützung heterogener undverteilter Systeme, zuverlässigeNachrichtenübermittlung,Vermittlung zwischen Services,einfache Implementierung,Integration von Datenbanken,Versionsverwaltung, interneSicherheit, Performance-Management

Wiederverwendung, einfacheModifizierung, Verfügbarkeit,Geschäftsprozessregeln,ereignisgesteuerte Prozesse,zusammengesetzteApplikationen

Schaffung der Voraussetzungenfür die externe Nutzung vonServices, unternehmensüber-greifende Sicherheit,Übersetzung unternehmensüber-greifender Protokolle,Transaktionen mit langer Laufzeit

BAM (Business ActivityMonitoring), ESP (Event StreamProcessing), CEP (Complex EventProcessing), ereignisgesteuerteDashboards und Alarme

Optimierung durchereignisgesteuerteAutomatisierung

Entscheidende personelleund organisatorischeErfolgsfaktoren

Entwickler erwerbenFertigkeiten für dieEntwicklung von ServicesUnterstützung durch denLeiter derEntwicklungsabteilung

Architekturgruppe übernimmtLeitungsfunktion,SOA-KompetenzzentrumUnterstützung durch CIO

OrganisationsübergreifendePartnerschaft zwischen IT-und Fachabteilungen,SOA Lifecycle Governance,NachdrücklicheUnterstützung durchManagement,ereignisgesteuerteEntwicklungsfertigkeiten

Unterstützung durch Leiterdes Geschäftsbereichs

Ständige Evaluation vonGeschäftsprozessen mitaktiver Ergreifung vonMaßnahmenUnterstützung durch CFO

Kultur der kontinuierlichenVerbesserung Unterstützung durch CEO

RelevanteStandardsAuswahl)

XML, XSLT,WSDL, SOAP,J2EE, .NET

UDDI, WS-ReliableMessaging, WS-Policy,WS- Addressing,XQuery, WS-Security, SAML

WS-BPEL

RosettaNet,ebXML, WS-Trust


Tabelle 2 - Ziele und bewährte Vorgehensweisen des SOA Maturity Models

Reifestufe

1. Initial-Services

2. Architektur-Services

3.a. BusinessServices

3.b. KollaborativeServices

4. MessbareBusinessServices

5. OptimierteBusinessServices

Hauptziele

1. Erlernen der SOA-Technologie in F&E-und Pilotprojekten.2. Anwendung der SOA-Technologie fürunmittelbare organisatorischeErfordernisse.3. Definition erster ROI-Kriterien für SOA-Projekte und Anwendung für ersteProjekte.

1. Institutionalisierung der SOA-Nutzung.2. Festlegung der Zuständigkeit und Leitungfür Fragen der SOA-Architektur.3. Nachweis des Nutzens vonStandardtechnologien.4. Prognostizierung der Nutzung von SOA-Informationen zur Optimierung vonGeschäftsprozessen.

1. Schaffung einer kontinuierlichenPartnerschaft zwischen fachlichen undtechnischen Organisationen zurRealisierung von SOA Governance.2. Unterstützung vollständigerGeschäftsprozesse über SOA.3. Nachweis des Nutzens, der durch dieWiederverwendung von Services und dasschnellere Reagieren auf Änderungenerzielt wird.

1. Schaffung einer kontinuierlichenPartnerschaft zwischen fachlichen undtechnischen Organisationen zurRealisierung von SOA Governance.2. Ausdehnung von SOA-Geschäftsprozessen auf externeOrganisationen3. Nachweis des Nutzens derWiederverwendung von Services für diekollaborative Zusammenarbeit.

1. Realisierung einer Transformation vonreagierenden hin zu in Echtzeitablaufenden Geschäftsprozessen.2. Definition und Einhaltung fachorientierterLeistungskriterien.

1. Realisierung einer unternehmensweitenLeitung für fachliche Aufgaben und SOA-Governance.2. Nachweis des Nutzens einer durchSOAs unterstützten kontinuierlichenVerbesserung.

Wesentliche Maßnahmen

1. Definition von Services.2. Aufnahme des SOA-Ansatzes in dieProjektentwicklungsmethodik.3. Quantifizierung des Zeit- undKostenaufwands und der wirtschaftlichenVorteile von Pilotprojekten.

1. Festlegung von Technologiestandards fürSOA.2. Aufnahme des SOA-Ansatzes in denorganisationsweiten Entwicklungsprozess.3. Organisationsweite Ausbildung in SOA-Fragen und Etablierung eines SOA-Kompetenzzentrums.4. Schrittartige Integration.

1. Festlegung von Richtlinien für den Einsatzeiner SOA bei der Einrichtung oderModifizierung von Geschäftsprozessen.2. Nutzung ereignisorientierter undvermittelnder Funktionen von SOA-Technologien, insbesondere im Hinblick aufdie Verbesserung/Erweiterung vonGeschäftsprozessen.

1. Festlegung von Richtlinien für denEinsatz einer SOA bei der Zusammenarbeitmit Geschäfts- und Handelspartnern2. Implementierung einer unternehmen-sübergreifenden Sicherheit.

1. Erfassung und Analyse geschäftsprozes-sorientierter Echtzeit-Leistungskriterien.2. Implementierung einer kontinuierlichenEvaluation und Umgestaltung vonGeschäftsprozessen.

1. Implementierung selbst korrigierenderGeschäftsprozesse.


7 World Wide Web Consortium, “Web Services Activity”, http://www.w3.org/2002/ws/.

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 einerSOA. Auf dieser Stufe werden Projekte gewöhnlich durchgeführt, um eine spezifischeFunktionalität zu implementieren und gleichzeitig bestimmte Technologien sowie einenSOA-Ansatz auszuprobieren. Hierzu gehören auch erste F&E-Aktivitäten, bei denen dieSOA-Technologien unter Laborbedingungen getestet werden. Gewöhnlich geht die ersteEinführung einer SOA von der Anwendungsentwicklungsabteilung aus und erfolgt oft imRahmen eines Anwendungsintegrationsprojekts. Dabei werden neueEntwicklerkenntnisse erworben und erste Schritte zur Quantifizierung deswirtschaftlichen Nutzens unternommen.

Auf dieser Stufe werden die grundlegendsten SOA-Standards des W3C-Konsortiums7

eingeführt, beispielsweise XML für die Definition von Nachrichtenformaten, WSDL fürdie 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, wodas unternehmensweite Web-Portal einer Vertriebsorganisation direkt an einvorhandenes, auf dem Mainframe laufendes Sales-Forecasting-Altsystem angebundenund eine neue CRM-Applikation als Web Service bereitgestellt wird. In diesem Beispielkönnte die folgende SOA-Infrastrukturkomponente verwendet werden:

> Ein Mainframe-Integrationsservice wie Shadow RTE von DataDirect, mit dem einbidirektionaler, auf Standards basierender Web-Service-Zugang zu einem SalesForecasting Altsystem realisiert wird, der innerhalb von CICS auf einem IBMMainframe mit dem Betriebssystem z/OS betrieben wird.

> Eine extrem produktive Entwicklungsplattform, die für die Erstellungserviceorientierter Geschäftsapplikationen optimiert ist (z.B. Progress OpenEdge) unddie Entwicklung und den Betrieb neuer CRM-Applikationslogik ermöglicht, auf die überWeb Services zugegriffen werden kann.


Abbildung 2: Beispielapplikation für Reifestufe 1: Initial-Services

Die Hauptvorteile eines solchen ersten Projekts bestehen darin, dass die fachlicheFunktion bereitgestellt wird und gleichzeitig die Kenntnisse und Fertigkeiten erworbenwerden, die für die Entwicklung und Implementierung einer SOA-Basisapplikationerforderlich sind. Eine entsprechende Implementierung würde das SOAP-Protokoll fürdie Kommunikation zwischen dem Portalserver und den unterstützenden Services sowiefü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 derzusätzlichen SOA-Infrastrukturkomponenten profitieren. Neben der Tatsache, dassbereits sehr früh mit dem Erwerb von Kenntnissen in der Nutzung der Technologienbegonnen wird, erfolgt die Einführung dieser modernen Technologien in erster Linie auchdeshalb bei ersten Projekten, um eine skalierbare Technologie zu implementieren, mitder sichergestellt wird, dass bei der Ausdehnung der SOA auf weitereGeschäftsfunktionen bereits das richtige Fundament vorhanden ist. So werdenbeispielsweise in Abbildung 3 die folgenden Komponenten hinzugefügt:

> Ein Runtime Governance Service wie der von Actional, welcher die Überwachungs-und Kontrollmechanismen bereitstellt, mit denen die jeweiligen Service- undSicherheitsrichtlinien für sämtliche Schritte innerhalb eines Geschäftsprozesses beiheterogenen SOA-Infrastrukturelementen angewandt werden.

> Ein Enterprise Service Bus (ESB) wie jener von Sonic, der ein standardisiertesInteraktionsmodell für SOA-Komponenten wie Web Services und relationaleDatenbanken als skalierbare, einfach zu implementierende verteilte Infrastrukturbereitstellt. Der ESB enthält eine große Anzahl von Adaptern, die dafür sorgen, dass inunterschiedlichen Technologien implementierte Services Nachrichten austauschenkönnen. Auf diese Weise kann beispielsweise eine .NET Applikation auf der Ebene derServices mit einer J2EE Applikation kommunizieren.

> Eine Services Registry, die den UDDI-Standard unterstützt. Auf diese Weise wird füralle anfänglichen Projekte ein zentrales Register mit Servicedefinitionen aufgebaut,auf das Serviceentwickler zurückgreifen können, um die Definitionen von Services zuerhalten.

Abbildung 3: Erweiterte SOA-Infrastruktur für SOA-Reifestufe 1: Initial-Services



8 OASIS, “OASIS Committees by Category: Web Services and SOA”, http://www.oasis-open.org/committees/tc_cat.php?cat=ws.9 WS-I, Web Services Interoperability Organization, http://ws-i.org

3.2 SOA–REIFESTUFE 2–ARCHITEKTUR–SERVICES

Bei SOA-Reifestufe 2 handelt es sich um Architektur-Services (siehe Tabelle 1 und 2). Aufdieser Stufe werden Standards für die technische Organisation der SOA-Implementierungfestgelegt, typischerweise unter der Leitung der Architekturorganisation. Der wichtigstewirtschaftliche Vorteil dieser Stufe besteht darin, dass die Entwicklungs- undImplementierungskosten im Vergleich zu älteren Technologien oder im Vergleich zu denkumulativen Kosten mehrerer Einzelprojekte durch den Einsatz von SOA-Standardinfrastrukturen und -komponenten reduziert werden. In den heterogenenUmgebungen, die in den meisten Unternehmen anzutreffen sind, sind diese Vorteile in derRegel noch größer.

Auf der Grundlage der in Reifestufe 1 erworbenen Kenntnisse und Erfahrungen, werdenArchitekturstandards und Standardtechnologien für die Implementierung definiert, z.B.:

> Auswahl der zu verwendenden Enterprise-SOA-Protokolle auf der Grundlage vonIndustriestandards wie W3C, OASIS8 und WS-I9 .

> Zu verwendende Implementierungsplattformen.

> Richtlinien für Wiederverwendung, Runtime Governance, Compliance und Sicherheit.

> Technischer Überprüfungsprozess für die Definition neuer Services und dieWiederverwendung vorhandener Services.

Abbildung 4 zeigt ein SOA-Beispiel der Reifestufe 2 für eine Implementierung imFinanzhandel. Reifestufe 2 beinhaltet die Nutzung der in Abbildung 3 gezeigtenKernkomponenten (d.h. Runtime Governance Service und Enterprise Service Bus) sowieder 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, überdie an dieser Stelle nachgedacht werden muss, sind Lifecycle-Support-Aspekte wieZugangskontroll-, Versionsverwaltungs- und Implementierungs Tools. Die Nutzungeines solchen Repositorys mit Entwicklungs- und Laufzeitunterstützung ist Bestandteilder Reifestufe 2 (Architektur-Services).


> Ein modifizierter Runtime Governance Service, der Services und die zwischen ihnenbestehenden Abhängigkeiten identifiziert und damit eine geeignete Grundlage schafft,um sowohl System- als auch Applikationsfehler zu erkennen, zu diagnostizieren undautomatisch zu beheben.

> Ein Message Transformation Service, der die Integration von Services ermöglicht, diesich im Hinblick auf die erwarteten Nachrichteninhalte oder -formate voneinanderunterscheiden. Oft wird dies realisiert, indem XLST-Transformationen aufgerufen undauf eine XML-Nachricht angewandt werden - in diesem Fall als “Mittler”-Funktionunter der Kontrolle des ESB.

> Ein Single Sign-On Service, der eine organisationsweite Authentifizierung undAutorisierung von Benutzern unterstützt. Entsprechende Services werden oft voneinem Softwarehersteller bezogen und könnten auf dem OASIS SAML-Standard fürden Austausch von Authentifizierungs- und Autorisierungsinformationen basieren.

Abbildung 3: Erweiterte SOA-Infrastruktur für SOA-Reifestufe 1: Initial-Services

3.3 SOA–REIFESTUFE 3–BUSINESS SERVICES UNDKOLLABORATIVE SERVICES

Der Schwerpunkt der SOA-Reifestufe 3 liegt auf der Partnerschaft zwischen technischenund fachlichen Organisationen. Damit soll sichergestellt werden, dass dieReaktionsfähigkeit des Unternehmens durch die Nutzung einer SOA deutlich gesteigertwird. Ein wesentlicher Vorteil der SOA ist die in Abbildung 5 dargestellte Verknüpfungzwischen geschäftlichen und digitalen Prozessen.

Abbildung 5: Die Stärke von SOA: Modellierung von Geschäftsprozessen (angelehnt anForrester Research)10

SOA-Reifestufe 3 wird durch zwei komplementäre Pfade definiert, mit denen diese Zielerealisiert werden: Der erste Pfad, Business Services, konzentriert sich auf dieVerbesserung interner Geschäftsprozesse, während im Mittelpunkt des zweiten Pfads(Kollaborative Services) die Verbesserung der kollaborativen Prozesse im Rahmen derZusammenarbeit mit externen Partnern steht (siehe Tabelle 1 und 2). Natürlich könnenbeide Wege beschritten werden, so dass mit der SOA optimale Ergebnisse erzieltwerden, jedoch kann Reifestufe 3 auch durch einem der beiden Wegen erreicht werden,da in beiden Fällen die Reaktionsfähigkeit des Unternehmens gesteigert wird.



Abbildung 6 zeigt ein SOA-Beispiel der Reifestufe 3 für eine Implementierung imFinanzhandel. Hier die wesentliche Elemente dieser Implementierung von BusinessServices:

> Business Process Management (BPM) - Das Management von Prozessen mit langerLaufzeit, bei denen eine Folge von Nachrichten zwischen Services ausgetauscht wird.Diese Aufgabe könnte beispielsweise durch den Sonic Orchestration Server realisiertwerden, der den Zustand der einzelnen Prozesse und die entsprechendenZwischenergebnisse verwalten kann.

Abbildung 6: Beispielapplikation für SOA-Reifestufe 3: Business Services

In Abbildung 7 wird die Weiterentwicklung von Business Services fortgesetzt, indemfolgende Elemente hinzukommen:

> Einfache Erweiterung von Geschäftsprozessen. Ein Hauptvorteil einer SOA ist dieMöglichkeit, Geschäftsprozesse durch eine einfache Umkonfiguration von Services zumodifizieren. In diesem Beispiel wird ein neuer Compliance Service, der zur Einhaltunggesetzlicher Vorschriften erforderlich ist, in den Nachrichtenstrom zwischen demOrder Management Service und dem Trading Service eingefügt, ohne dieImplementierungen der vorhandenen Services ändern zu müssen.

10 “The Big Strategic Impact Of Organic Business And Service-Oriented Architecture”, Forrester Research, Inc., June 2004.

> Wiederverwendung von Services. In diesem Beispiel wird die Wiederverwendungdurch eine Multi-Channel-Applikation (bei der beispielsweise Kunden auf mehrerenKommunikationswegen auf die gleiche Applikation zugreifen können) realisiert, wobeider Order Management Service sowohl vom Call Center Service als auch vom OnlineService genutzt wird.

Abbildung 7: Weiterentwicklung der Anwendung zur Realisierung der Reifestufe 3

Alternativ kann der Schwerpunkt der Reifestufe 3 auf Kollaborative Services liegen,wobei die Anbindung externer Partner im Mittelpunkt steht. Abbildung 8 zeigt einBeispiel, in dem das Handelsunternehmen durch einen neuen Geschäftszweig erweitertwurde, bei dem Devisentransaktionen über das Internet angeboten werden.


Wesentliche Merkmale dieser Implementierung von Kollaborations-Services:

> Nutzung von SOA-Standardprotokollen zur Unterstützung spezifischer B2B-

Funktionen (Business-to-Business), z.B. der durch RosettaNet11 definierten StandardXML-Messaging-Funktionen für unternehmensübergreifende Abläufe wieBeschaffung von Produkt- und Bestandsinformationen oder Bestellung von Produkten.

> Ein Kollaborations-Service implementiert die B2B-Protokolle und unterstützt nicht nurdie Transformationen der unternehmensintern ausgetauschten Nachrichten, sondernauch die für externe Prozesse erforderlichen Transformationsvorgänge.

> Anstatt eines proprietären Protokolls wird für die ECN-Anbindung (Electronic CrossingNetwork) ein Services-Protokoll auf Basis von Industriestandards verwendet, so dassdie entsprechende Verbindung durch den Kollaborations-Service verwaltet wird.

Abbildung 8: SOA-Reifestufe 3: Kollaborative Services


11 RosettaNet, ”Standards”, http://rosettanet.org/standards


Abbildung 9: Beispielapplikation für SOA-Reifestufe 4: messbare Business Services

3.4 REIFESTUFE 4–MESSBARE BUSINESS SERVICES

Während sich die SOA-Reifestufe 3 auf die Implementierung interner und/oder externerGeschäftsprozesse konzentrierte, liegt das Hauptaugenmerk bei SOA-Reifestufe 4 auf dieMessung und Darstellung dieser Prozesse auf der Business Ebene, um einekontinuierliche Rückmeldung zur Performance und zu den geschäftlichen Auswirkungender in Stufe 3 implementierten Prozesse zu erhalten (siehe Tabelle 1 und 2).

Abbildung 9 zeigt einen exemplarischen Konfigurations-, Auftrags- und Fertigungsprozess,bei dem die Services für die einzelnen Kernfunktionen auf verschiedene geografischeStandorte verteilt sind.

Die wichtigsten Funktionen in diesem Beispiel sind:

> Real-time Event Stream Processing, wobei in diesem Fall alle RFID-Events in einerEvent-Datenbank erfasst werden, um die geschäftlich relevanten Events anhand vonRegeln herauszufiltern und an andere Services zur weiteren Nutzung weiterzuleiten.Wie in The Power of Events12 und “Event Stream Processing - A New Physics of

Software”13 erläutert, ermöglicht ESP (Event Stream Processing) und CEP (ComplexEvent Processing) eine Transformation von Geschäftsabläufen indem sie nichtlediglich reagieren, sondern auf der Grundlage von Echtzeitinformationen arbeiten.

> Business Process Visibility (BPV), wodurch die SOA aus der Perspektive desGeschäftsprozesses verwaltet werden kann. Durch BPV erhalten fachliche und ITBenutzer nicht nur einen umfassenden Überblick über einzelne Geschäftsprozesseund deren unterstützenden Business Services und IT-Infrastruktur, sondern könnengleichzeitig Richtlinien auf der Ebene des Geschäftsprozesses durchsetzen.

Abbildung 9: Beispielapplikation für SOA-Reifestufe 4: messbare Business Services

3.5 REIFESTUFE 5–OPTIMIERTE BUSINESS SERVICES

In SOA-Reifestufe 5 werden die in Stufe 4 implementierten Messungen durch Funktionenerweitert, mit denen eine automatische Reaktion ermöglicht wird. Auf diese Weise wirddas SOA-Informationssystem zum Nervensystem des Unternehmens. Anhand von Regelnfür die Optimierung von Geschäftszielen werden auf der Grundlage der aufgeschäftlicher Ebene erfolgten Ereignisse automatisch Maßnahmen ergriffen (sieheTabelle 1 und 2).

Abbildung 10 zeigt, wie der Konfigurations-, Auftrags- und Fertigungsprozess soerweitert wird, dass die Preise der Produkte unter Berücksichtigung derMaterialbestände und der aktuellen Produktionsdaten dynamisch generiert werden.Wenn beispielsweise der Vorrat von Teilen, die für eine bestimmte Variante einesArtikels benötigt werden, knapp ist, können die Preise so gestaltet werden, dass es fürKunden attraktiv ist, einen anderen Artikel mit alternativen Teilen zu kaufen. Ein Beispielhierfür ist der Erfolg, den die Dell Corporation mit einer dynamischen Preisgestaltungerzielt hat. Ist der Bestand an Laufwerken mit einer bestimmten Speicherkapazitätniedrig, wird dort dynamisch ein Sonderangebot generiert, das die Kunden motivieren


12Luckham, David, The Power of Events, Addison-Wesley, 2002.13Palmer, Mark, “Event Stream Processing - A New Physics of Software”, DM Direct Newsletter, July 29, 2005,http://www.dmreview.com/editorial/newsletter_archive.cfm?nl=dmdirect&issueid=20226.

soll, einen Rechner mit einem größeren Laufwerk zu konfigurieren und zu kaufen.14, 15

Durch SOA-Komponenten lässt sich ein solcher Ansatz wesentlich problemloserimplementieren und weiterentwickeln als durch den Aufbau proprietärer Systeme. Beierfolgreicher Realisierung der Reifestufe 5 können Unternehmen echteWettbewerbsvorteile erlangen, indem sie den Informationsfluss im Unternehmen inEchtzeit nutzen, um den Umsatz zu steigern, Kosten zu reduzieren und in automatisierterWeise auf unerwartete Ereignisse reagieren zu können.

Abbildung 10: Beispielapplikation für SOA-Reifestufe 5: Optimierte Business Services


14Friedman, Thomas L., The World is Flat, Farrar, Straus and Giroux, 2005.15McWilliams, Gary, “Lean Machine: How Dell Fine-Tunes Its PC Pricing to Gain Edge in a Slow Market”, The Wall StreetJournal, June 8, 2001.

4.0 SCHLUSS

Das SOA Maturity Model schafft einen Rahmen, mit dem sowohl die Vision zurSteigerung der geschäftlichen Vorteile realisiert durch die Einführung einer SOA alsauch deren Bewertung unterstützt wird. Das Modell besteht aus fünf Reifestufen, diedurch die folgenden Hauptvorteile gekennzeichnet sind:

Eine wesentliche Voraussetzung für den Erfolg einer SOA-Implementierung ist dieBildung einer Partnerschaft zwischen den technischen und fachlichen Organisationen.Diese Partnerschaft gründet darauf, dass die technische Organisation in der Lage ist,das Unternehmen sowohl bei der Reaktion auf Maßnahmen der Mitbewerber als auchbei der schnellen Implementierung neuer Geschäftsmodelle - z.B. neuer Vertriebskanäle,neuer Informationsdienste und neuer Preismodelle - zu unterstützen, zur gleichzeitigenVerbesserung der Erfolgskriterien wie Profitabilität und Kundenzufriedenheit.

Das Ziel des SOA-Ansatzes besteht darin, diese geschäftliche Agilität auf andere undbessere Weise zu ermöglichen als frühere Technologien: anders wegen der Nutzung vonWeb-Standards, wegen der immanenten Flexibilität des SOA-Konzepts, wegen derIntegration von Altsystemen und wegen der allgemeinen Verfügbarkeit von SOA-Architekturlösungen und SOA-Services. Der Erfolg eines Unternehmens bei derRealisierung einer höheren Reifestufe hängt jedoch letztlich von der Methodik undBeharrlichkeit ab, mit der das Unternehmen entsprechende Projekte entweder selbst inAngriff nimmt oder einem Systemintegrator überträgt, um die Implementierung zubeschleunigen.


Worldwide HeadquartersProgress Software Corporation, 14 Oak Park, Bedford, MA 01730 USATel: +1 781 280-4000 Fax: +1 781 280-4095www.progress.com

For regional international office locations and contact information, please refer to www.progress.com/worldwide

© Copyright 2007 Progress, DataXtend, Actional, Sonic ESB are registered trademarks of Progress SoftwareCorporation or one of its subsidiaries or affiliates in the US and other countries. Any other trademarks containedherein are the property of their respective owners.

0000113863

prod code 7631

Documents

SOA MATURITY MODEL, EIN VORGEHENSMODELL ZUR …cdn.crn.de/fileadmin/whitepapers/files/progress_soa_maturity_model_vor... · INHALT > Vorwort 2 > 1.0 Einführung und Motivation 3 >