SOA-Transformation

pleus.net

SOA-Transformation

SOA-TransformationSOA CenterSOA-TransformationIm technologiegetriebenen Umfeld moderner Softwareentwicklung liegt der Fokusnaturgemäß primär auf technischen Aspekten. Dies gilt auch für das Thema serviceorientierteArchitekturen. Daneben stellt sich den Projektverantwortlichen die Frage,wie eine Transformation in Richtung serviceorientierter Entwicklung erfolgen soll.von Wolfgang Pleusevor mit der Einführung einerserviceorientierten Architekturim Unternehmenbegonnen wird, ist es wichtig, dass denBeteiligten die Ziele und der Nutzendes Vorhabens für das Unternehmenmöglichst klar sind. Dies klingt trivial,ist aber essenziell, da im Verlauf einerSOA-Einführung viele Entscheidungenzu treffen sind, die sich an diesenZielen messen lassen müssen. Dabeigeht es um Fragen wie die, welche Granularitätdie Services haben sollen,welche Business Process Management(BPM) Engine eingesetzt werden soll,oder ob ein Enterprise Service Bus(ESB) zum Einsatz kommt. Sind dieZiele nicht ausreichend klar, bestehtein hohes Risiko, dass am Ende zwar eineReihe von Produkten aus dem SOA-Umfeld eingesetzt wird, der Nutzen fürdie Organisation aber hinter den Erwartungenzurückbleibt.Das Hauptziel eines SOA-Vorhabensist die gesteigerte Agilität des Unternehmensin Bezug auf sich schnell veränderndeMarktbedingungen. Durch einestärkere Verzahnung von IT und Fachbereichen,auch IT/Business-Alignementgenannt, soll ein Wettbewerbsvorsprungerreicht werden. Danebenkann es natürlich noch Nebenziele wiedie Konsolidierung einer bestehendenSystemlandschaft geben. Wichtig istzu verstehen, dass Technologien keinSOA-TransformationDieser erste Teil des Artikelsbeschreibt die typischen Schritteeiner SOA-Transformation undzeigt, was bei der Planung besonderszu beachten ist. Im zweitenTeil in der nächsten Ausgabe desJava Magazins wird beschrieben,welche organisatorischen Veränderungenmit einer solchen Transformationeinhergehen.www.JAXenter.de javamagazin 7|2008 95


SOA CenterSOA-TransformationAbb. 1: Ist- und SollarchitekturenSelbstzweck sind, sondern sich an dengeschäftlichen Zielen messen lassenmüssen.Ist- und SollarchitekturenKlassische Anwendungen werden in derRegel im Rahmen einzelner Projekte realisiert.Die Ausrichtung und der Umfangsolcher Projekte beziehen sich dabei aufeinen speziellen Problembereich, beispielsweiseein neues Portal für das Direktkundengeschäfteiner Versicherung.Im Rahmen dieser Projekte werden fürdie Projektziele relevante Entscheidungengetroffen. Dazu gehören die Auswahleiner Datenbank oder der Einsatz vonJSF und EJB für die Implementierung.Die so realisierten Systeme sind ehervertikal ausgerichtet. Das heißt, dass jedesSystem weite Teile von der grafischenOberfläche über die Geschäftslogik biszur Datenzugriffstechnologie selbstregelt. Selbst Produkte wie Applikationsserverwerden oft projektbezogenlizenziert. Dieses vertikale Modell hatjedoch einige Schwächen. Jeder kenntdas: Obwohl Wiederverwendung prinzipiellgewünscht ist, findet sie jenseitsder Projektgrenzen kaum statt. Stattdessenwird das Rad oft neu erfunden undin Form redundanter Funktionalitätenauf allen Ebenen neu implementiert.Geschäftsprozesse überspannen nichtselten mehre Anwendungen und Systeme.Daraus ergeben sich Systembrüche,die zu Integrationsaufwänden und unbefriedigendenBenutzererfahrungenführen. Mit jedem neuen Projekt nimmtdie Komplexität des Gesamtsystems zu.Nicht zuletzt deshalb konsolidieren Unternehmenihre Systemlandschaften mitentsprechendem Aufwand.Serviceorientierte Architekturenfolgen einem eher horizontalen Modell.Dabei stellen Services allgemeineFunktionalitäten für unterschiedlichefachliche Domänen bereit. TypischeDomänen verwalten beispielsweiseKunden, Verträge oder Tarife. Idealerweiseverfügen die Services über einenhohen Wiederverwendungsgrad undgeringe Redundanz. Verwendet werdensie von Prozessen, die mittels einesBPM-Systems abgebildet werden. DieseProzesse können mehrere Domänenumspannen. Die Interaktion der Benutzermit den Prozessen wird über grafischeOberflächen ermöglicht, die ihmdie zu bearbeitenden Prozessschrittepräsentieren. Prozesse mit Benutzerinteraktionwerden auch als Workflowsbezeichnet. Die angestrebte Agilitätbasiert primär auf der Prozessschicht,die eine flexible Anpassung auf Basisexistierender Services ermöglichen soll.Durch grafische Prozessmodellierungwerden Fachbereiche und IT-Abteilungeneinander angenähert.Aller Anfang ist schwerWie jedes neue Paradigma hat es auchdie Serviceorientierung am Anfangschwer. Dies liegt daran, dass verständlicherweiseniemand auf ein Paradigmasetzen möchte, bevor feststeht, dasses wirklich Erfolg bringt. Bei der Einführungeines neuen Frameworks istdieser Beweis schnell erbracht.Die Effekte einer serviceorientiertenArchitektur zeigen sich dagegeneher langfristig und sind kurzfristigkaum verifizierbar. Da das Thema ansich aber sehr vielversprechend ist, beginnenviele Unternehmen, ausgewählteTechnologien wie BPM oder ESBim Rahmen eines Projekts anzuwenden.Die Aussagekraft jenseits der reintechnischen Fragestellungen ist dabeijedoch sehr eingeschränkt. Ohne eineunternehmensweite oder zumindestabteilungsweite SOA-Strategie endenviele Projekte, noch bevor sie eigentlichbegonnen haben. Daher ist es erforderlich,dass das Thema SOA als strategischesZiel eines Unternehmens begriffenund kommuniziert wird. Dies kannnicht aus einem Projekt heraus geleistetwerden, sondern muss vom Managementgetrieben werden. Den Projektmitarbeiternfällt dabei eine beratendeRolle zu, wenn es darum geht, die möglichenPotenziale zu vermitteln.Big Bang oder evolutionär?Bei der Wahl des grundsätzlichen Vorgehensbieten sich zwei Ansätze an.Beim Big Bang wird ein holistischerAnsatz verfolgt. Dieser Ansatz wirdauch als strategischer oder Top-Down-Ansatz bezeichnet. Die Basis bildendie Geschäftsprozesse und fachlichenDomänen eines Unternehmens. AmBeginn steht eine ausgiebige Analysephase,um den Problembereichweitestgehend zu erfassen. Auf dieserBasis wird dann die Prozess- und Serviceschneidungvorgenommen undsomit die serviceorientierte Landschaftetabliert. Der Vorteil besteht darin,dass frühzeitig eine Fokussierung aufdie Geschäftsprozesse stattfindet. Darauskann eine vernünftige Domänenschneidungund damit verbundendeServicelandschaft hervorgehen. Dochdieser Ansatz ist in der Praxis nichtunproblematisch. Zum einen ist es für96 javamagazin 7|2008www.JAXenter.de


Anzeige


SOA CenterSOA-TransformationAbb. 2: SOA-ProgrammAbb. 3: Phasen der Roadmap-Definitiongroße Unternehmen oft kaum möglich,eine ganzheitliche Sicht zu erreichen.Zudem entstehen hohe Initialkostenfür Analyse, Evaluierung und Infrastruktur,ohne dass dem zunächst einkonkreter Nutzen gegenübersteht.Nicht zuletzt stehen einem solchenAnsatz unter Umständen kulturelleWiderstände entgegen, da eine neueAusrichtung der Entwicklung Verantwortlichkeitenverschiebt und dieEntscheidungsfreiheit der Projekte einschränkenkann.Die Lernkurve ist ebenfalls nicht zuunterschätzen. Denn die SOA-Paradigmenmüssen im Unternehmen vermitteltwerden, damit sie von den Mitarbeiternunterstützt und getragen werden.Der evolutionäre, auch taktischeroder Bottom-Up-Ansatz genannt, nähertsich der SOA in Form kleinererSchritte. Dabei werden zunächst bestehendeSysteme SOA-fähig gemacht.Dies erfolgt beispielsweise durch dieBereitstellung offener Schnittstellen,Abb 4: Aktivitäten einer Iterationdie von anderen Projekten verwendetwerden können. Der Einsatz einerBPM Engine für die Prozessabbildungist ebenfalls ein häufig gewählter Weg.Vorteilhaft dabei ist, dass die Machbarkeitsehr schnell dargestellt werdenkann. Zudem entsteht direkt eingeschäftlicher Nutzen, da konkretefachliche Anforderungen umgesetztwerden. Dieser Weg ist zudem leichteinzuschlagen, da sich die Aktivitätenim bekannten Projektrahmen bewegen.In Bezug auf eine ganzheitliche SOA istder Wertbeitrag jedoch gering, da derKontext eines Projekts zu klein ist unddie SOA-Effekte vor allem projektübergreifendentstehen. Zudem entsprichtdie Granularität der Projekte nichtnotwendigerweise der Granularität derSOA-Domänen, wodurch strukturelleVerbesserungen verhindert werden.Es ist sicherlich ein sinnvoller ersterSchritt, die SOA-Paradigmen innerhalbeines Projekts zu erproben. Wennes danach aber nicht gelingt, diese Paradigmenauf einer höheren Ebene wieeiner Abteilung zu etablieren, kann voneiner serviceorientierten Architektur,die sich nicht alleine über technischeModebegriffe definiert, kaum gesprochenwerden.Der evolutionäre Ansatz hat sich inder Praxis bewährt, sofern er Teil einerSOA Roadmap ist, die vom Managementaktiv unterstützt wird. So sind die Aktivitätenimmer in einen größeren Kontexteingeordnet, mit dem Ziel, die SOAschrittweise einzuführen. Zeitgleichkann im Rahmen eines strategischenAnsatzes mit der Prozess- und Domänenanalysebegonnen werden. Durchregelmäßige Abstimmungen kann somit der Zeit eine stabile Unternehmens-SOA entstehen.Das SOA-ProgrammDer erste konkrete Schritt in Richtungeiner SOA ist das Aufsetzen eines SOA-Programms. Das SOA-Programm beschreibtdie grundsätzlichen Phasender Transformation. Diese Phasenkönnen variieren, beinhalten jedochprinzipiell immer die in Abbildung 2gezeigten Phasen. Das Aufsetzen desSOA-Programms bedeutet nicht notwendigerweise,dass die SOA auch tatsächlichumgesetzt wird. Es ist lediglichder erste Schritt im Rahmen einesstrukturierten Vorgehens und stellt eingrundsätzliches Bekenntnis zum ThemaSOA dar.Die Phase der Information beinhalteteine erste Auseinandersetzung mitdem Thema, die in beliebiger Form erfolgenkann – beispielsweise durch Fachvorträge,Workshops, Konferenzbesuche,oder Literaturstudium. Ziel ist es,ein Grundverständnis zu erlangen, dasals Basis für die weiteren Phasen erforderlichist.Ob eine SOA für ein Unternehmensinnvoll ist, hängt vor allem davonab, ob es von einem Agilitätszuwachsund einem besseren IT/Business-Alignement profitieren kann. Dies istzum Beispiel der Fall, wenn die Geschäftsprozessemaßgeblich durch dieIT unterstützt werden und sich dasUnternehmen in einem dynamischenMarktumfeld bewegt. Während derPotenzialanalyse wird die Eignung98 javamagazin 7|2008www.JAXenter.de


einer SOA unter Einbeziehung vonGeschäfts- und IT-Strategie sowie derProzess- und Anwendungslandschaftermittelt und dargestellt. Je nach Ergebnisder Analyse wird das SOA-Programman dieser Stelle beendet oderfortgeführt.Die SOA RoadmapDie SOA Roadmap stellt den Masterplanfür die SOA-Umsetzung dar. Dieser Planist für jedes Unternehmen individuell,weil er die bestehende Projekt- undAnwendungslandschaft einbezieht. ImRahmen der Roadmap-Definitionsphasewird die konkrete, individuelleRoadmap entwickelt. Die Roadmap-Methodik variiert je nach Herstelleroder Beratungshaus [3], [4], folgt abergrundsätzlich den Phasen aus Abbildung3. Die während der verschiedenenPhasen erforderlichen Aktivitäten sindin Tabelle 1 dargestellt.In der Planungsphase geht es darum,den Umfang klar abzugrenzen.Dabei ist es einerseits wichtig zu beschreiben,was Teil (Systeme, Organisationseinheiten)des SOA-Vorhabensist. Andererseits ist klar zu beschreiben,welche Teile nicht einbezogen werden.Dies hilft, eine realistische Erwartungshaltungbei allen Beteiligten aufzubauenund spätere Enttäuschungenzu vermeiden. In dieser Phase solltenzudem die Teams für die weiteren Phasenbenannt werden. Zudem sollte einSteuerungsgremium mit Entscheidungskompetenzbenannt werden, dasauftretende Fragestellungen währendder Roadmap-Definition verbindlichklären kann. Beispielsweise kann es erforderlichsein, den Umfang des SOA-Vorhabens aufgrund neuer Erkenntnisseneu auszurichten. Da dies unterUmständen weitreichende Konsequenzenhaben kann, sollte eine solche Fragestellungvom Steuerungsgremiumentschieden werden.Die Bewertung der Reife beinhalteteine Analyse der bestehendenLandschaft in Bezug auf IT-Systeme,Geschäftsprozesse und Organisationsstrukturen.Da sich eine SOA an der bestehendenIT- und Geschäftsstrategieausrichten muss, sollten diese ebenfallsmit in die Analyse einbezogen werden.Nicht selten ist es der Fall, dass die Zusammenhängeder bestehenden Landschaftin der Organisation nur unzureichendbekannt sind. Daher empfiehltes sich, einen oder mehrere Systematlantenund Organigramme zu erstellen.Dieser Aufwand zahlt sich schnell aus,da sie Kommunikation in den weiterenPhasen unterstützt. Falls eine Potenzialanalysedurchgeführt wurde, können dieErgebnisse in die Bewertung der Reifeeinbezogen werden. Wenn eine externeSicht erforderlich ist, können auchSOA-Maturity-Modelle herangezogenwerden.Bei der Entwicklung der Zieldefinitiongeht es darum, das Soll in technischerund organisatorischer Hinsicht zu beschreiben.Ziel ist es, möglichst plastischdarzustellen, wie das Unternehmen intechnischer und organisatorischer Hinsichtnach der Transformation aussehensoll. Dabei ist es hilfreich, eine Referenzarchitekturzu erstellen. Diese enthält dieelementaren Bestandteile wie BusinessProcess Management, Enterprise ServiceBus, Business Activity Monitoringoder Repository. Erste Domänen- undAnzeigePhasePlanungBewertung der ReifeEntwicklung der ZieldefinitionDefinition der RoadmapErgebnisTabelle 1: Aktivitäten der Roadmap-DefinitionUmfang und Abgrenzung festlegenSteuerungsgremium benennenTeams für die weiteren Phasen benennenAnalyse bestehender Systeme und ProzesseAnalyse der Geschäfts- und IT-StrategieErstellung Organigramm und SystematlasTechnisch (Domänen- und Servicekandidaten, Geschäftsprozesse)Organisatorisch (Teamstrukturen, Finanzierung)Erstellung ReferenzarchitekturTechnisch (Domänen- und Servicekandidaten, Geschäftsprozesse)Organisatorisch (Teamstrukturen, Finanzierung)Erstellung Referenzarchitekturwww.JAXenter.de


SOA CenterSOA-TransformationServicekandidaten vermitteln recht konkret,in welche Richtung sich die SOA entwickelnwird. Da noch keine detaillierteAnalyse stattgefunden hat, kann dies natürlichnur grob dargestellt werden.In der letzen Phase wird der Wegvom Ist zum Soll beschrieben. Hiergeht es darum, wichtige Meilensteinefestzulegen. Dies könnte beispielsweisedie Verfügbarkeit der Domänenkundenoder die Abbildung ausgewählterVerkaufsprozesse sein. Zudem werdenKriterien festgelegt, anhand derer dasErreichen eines Meilensteins geprüftwerden kann. Es empfiehlt sich ebenfalls,den jeweils angestrebten Nutzeneines Meilensteins zu definieren. Dieshilft, um die permanent auftretendeFrage nach der Motivation des SOA-Programms zu beantworten. Das Ergebnisder letzten Phase ist die konkreteRoadmap, die den groben Ablauf derTransformation beschreibt.UmsetzungBisher dienten alle Aktivitäten der Vorbereitungder SOA-Umsetzung. Im Rahmendes SOA-Programms wurde dieSOA Roadmap entwickelt. Wenn diesefreigegeben wird, beginnt die Phase derUmsetzung. Im Vergleich zu den anderenPhasen ist diese ungleich länger, dahier die eigentliche Implementierungerfolgt. Die Umsetzungsphase ist inkrementellund orientiert sich an denMeilensteinen der Roadmap. Jeder Meilensteinkann mehrere Iterationen erfordern.Diese Iterationen beinhalten prinzipielldie Aktivitäten aus Abbildung 4.Zu Beginn einer jeden Iteration stehtdie Bewertung des bisher Erreichten.Dabei werden die bisher gemachtenErfahrungen in die neue Iteration einbezogenund gegebenenfalls Kurskorrekturenvorgenommen. Danach folgteine Potenzialanalyse im Kontext derIteration. Es wird die Frage beantwortet,welchen Wertbeitrag die Iteration zumMeilenstein beziehungsweise zum SOA-Programm insgesamt leisten kann. Diesist wichtig, da sich jede Entwicklung anden Zielen des SOA-Vorhabens messenlassen muss. Nur wenn es kontinuierlichgelingt, zu zeigen, welchen Nutzen dieaktuelle Entwicklung bringt, lässt sichein SOA-Vorhaben über einen langenZeitraum umsetzen.Danach folgen die obligatorischenAktivitäten der Planung, der Implementierungund des Betriebs. UnterUmständen wird nicht jede Iterationproduktiv in Betrieb gehen, jedochEs ist wichtig, die Ziele des SOA-Vorhabens immer vor Augen zu haben.sind kleine Iterationen mit häufigerProduktivsetzung gegenüber langenIterationen vorzuziehen, da so der geschäftlicheNutzen besser dargestelltwerden kann. Mit dem Fortschreitender Umsetzung entlang der Meilensteinewird die SOA schrittweise umgesetzt.Idealerweise nimmt die Reifeder SOA und die Agilität des Unternehmensdabei immer weiter zu.Die Phase der Umsetzung endet,wenn der letzte Meilenstein der Roadmaperreicht ist. Spätestens zu diesemZeitpunkt stellt SOA das führende Paradigmaim Unternehmen dar.ErfolgsfaktorenEs ist wichtig, sich die Ziele des SOA-Vorhabens immer wieder zu vergegenwärtigen.Denn nur wenn sichLinks & LiteraturTransformation permanent an den Geschäftszielenausrichtet, kann sie dengewünschten Nutzen bringen. In derPraxis wird dies nicht selten übersehenund es entstehen komplexe Lösungen,die vor allem durch technische Modethemengetrieben werden. Zudemsollte eine SOA nicht im Elfenbeinturmentstehen und/oder von außenverordnet werden. Nur wenn das Paradigmavon den Entwicklern akzeptiertund getragen wird, kann es erfolgreichumgesetzt werden. Dies kann wiederumnur gelingen, wenn möglichst frühein einheitliches Verständnis für dasThema SOA im Unternehmen etabliertwird.Nicht zuletzt deshalb spielt das SOA-Programm und die SOA Roadmap eineherausragende Rolle bei der Umsetzungeiner serviceorientierten Architektur.FazitIm Zuge der SOA-Transformation wirdder Übergang von einer projekt- undanwendungszentrierten zu einer serviceorientiertenStruktur vollzogen. Imersten Teil dieser Serie wurde das grundsätzlicheVorgehen bei einer solchenTransformation vorgestellt. Mit demAbschluss der Transformation ist dasSOA-Vorhaben nicht zu Ende, sondernwird im Rahmen des normalen Tagesgeschäftsweiter gelebt. Daraus ergebensich Konsequenzen für die organisatorischenStrukturen, die im zweiten Teildieser Serie behandelt werden.Wolfgang Pleus arbeitet als Technologieberater, Autor und Trainer imBereich serviceorientierter Architekturen. Seit über 15 Jahren unterstützter internationale Unternehmen bei der Realisierung komplexer Geschäftslösungenauf der Basis von J2EE und .NET. Er ist Mitglied des AccelsisSOA-Competence-Teams.[1] www.sonicsoftware.com/solutions/service_oriented_architecture/soa_maturity_model/[2] www.ibm.com/developerworks/webservices/library/ws-soa-simm/[3] dev2dev.bea.com/images/2005/11/maturitymatrix.jpg[4] dev2dev.bea.com/pub/a/2005/12/soa-roadmap.html[5] www1.webmethods.com/PDF/datasheets/SOA_Roadmap_datasheet.pdf100 javamagazin 7|2008www.JAXenter.de

Weitere Magazine dieses Users
Ähnliche Magazine