Industrialisierung durch und durch

Transkript

1 SOA: Idustrialisierug durch ud durch SOA: Idustrialisierug durch ud durch Die Idustrialisierug vo IT ud die Eiführug eier SOA wurde jahrelag völlig separat vo uterschiedliche Persoe eies Uterehmes behadelt. Dabei besteht zwische beide Disziplie eie existetielle Relatio: We im Rahme der Idustrialisierug Prozesse verädert werde, müsse Etscheiduge zum Umgag mit Modularisierug, Stadardisierug, Automatisierug ud Wiederverwedug getroffe werde sowie eie Fokussierug auf Kerkompeteze erfolge. Diese Begriffe habe aber auch für die Umsetzug eier SOA eie fudametale Bedeutug. Mit diesem Artikel soll gezeigt werde, wie im Rahme der Idustrialisierug eie erfolgreiche SOA etstehe ka ud bekate Stolpersteie umgage werde köe. Totgesagte lebe läger ud we icht als Begriff, da i jedem Fall als Dekweise. De das ist SOA: Serviceorietierug ist ei Paradigma, das de Rahme für user Hadel vorgibt (erster Satz des SOA- Maifests, vgl. [Ars09]) ud ei Paradigma ist icht weiger als eie grudlegede Dekweise. Diese Dekweise fokussiert Dieste ud Geschäftsprozesse, die i der Regel keieswegs allesamt uter de meist sehr techisch belegte Begriff Serviceorietierte Architektur (SOA) subsumiert werde köe. Auch eie Cloud hat eie serviceorietierte Sicht, de techische Details der Liefererbrigug spiele für de Nutzer hier keie oder weigstes eie utergeordete Rolle. Auch adere Facette des Everythig as a Service (XaaS) besitze eie serviceorietierte Sicht ud reihe sich damit hervorraged i dieses Paradigma ei. Ob dieses Phäome u als SOA bezeichet wird, spielt im tägliche Eisatz kaum eie Rolle iteressat ist das dahiter liegede Dekschema, heute ud sicher auch och weiter i der Zukuft. I diesem Artikel wolle wir versuche, die Esseze des Paradigmas Serviceorietierug herauszuarbeite. Es wird sich zeige, dass diese Esseze eie große Nähe zum Kozept der Idustrialisierug habe. Wir wolle darstelle, dass eie SOA als ei mögliches Ergebis der Idustrialisierug aufgefasst werde ka ud sich aus dieser Sichtweise wertvolle Zusammehäge für de Erfolg eier SOA ergebe. Wichtig ist aber hier scho eimal der Hiweis, dass es auch eie Idustrialisierug ohe SOA als Ergebis gibt. Die SOA ist folglich eie kokrete Zielsetzug vo Idustrialisierug agewedet auf Geschäftsprozesse ud die sie uterstützede IT. Dieser aufgezeigte Zusammehag wird aschließed für eie Reichweite-Beurteilug (Scopig) verwedet, um da kokrete Hiweise dafür zu erhalte, warum SOA- Iitiative sich i der Praxis häufig so extrem schwer gestalte lasse. Erreicht wird dies durch die Awedug eies aus dem Idustrialisierugskotext bekate Orgaisatiosmodells für SOA: dem EFQM- Modell (Europea Foudatio for Quality Maagemet, vgl. z.b. [Mal11], siehe de Kotext -Bereich i Abbildug 1). Idustrialisierug Mit Breer et al. (vgl. [Bre13]) lässt sich die Idustrialisierug der IT als die Übertragug erfolgreicher Maagemetkozepte ud -methode aus der idustrielle Fertigug auf die IT-Leistugserstellug defiiere. Demach lässt sich Idustrialisierug durch die im Folgede beschriebee vier sequezielle Schritte klassifiziere, a dere Ede eie vollstädig idustrialisierte IT steht. Diese Schritte erläuter wir kurz aus dem Blickwikel der Geschäftsprozesse ud IT, sodass das Ergebis eier solche Idustrialisierug eie SOA sei ka. 1. Modularisierug Idee dieses Schrittes (siehe Abbildug 2) ist es, de Geschäftsprozess icht mehr moolithisch atomar, soder als Verkettug bestimmter Teilschritte zu verstehe. Ei wesetlicher Vorteil ist die Egoless Produc- Abb. 1: SOA durch Idustrialisierug ud ihre Eiordug i das EFQM-Modell. 20

2 Abb. 2: Modularisierug. tio (ählich zu Egoless Programmig, vgl. [Ada01]). Dadurch werde Prozesse, die vorher ur implizit i de Köpfe eizeler Persoe vorhade ware, explizit. Eizele Mitarbeiter köe leichter ersetzt bzw. etlastet werde, was aus Uterehmessicht als durchaus positiv zu bewerte ist. Die Uterehmesprozesse werde schulbar ud sid daher vom Grude her übertragbar. Für diese saubere Modellierug ud gegeseitige Abgrezug der Arbeitsprozesse ist zuächst detailliertes Wisse über die Abläufe selbst erforderlich. Die Erfahrug zeigt, dass sogar viele Persoe, die operativ maximal tief i bestimmte, och icht modularisierte Arbeitsschritte ivolviert sid, häufig icht das große Gaze überblicke. Der Begriff des Fachidiote, der rei vertikal spezialisiert arbeitet, lässt sich hier eiorde. Der Modularisierer dagege ket die operative Ebee ebeso gut, ka sie aber darüber hiaus auch i eie Abb. 3: Stadardisierug. Kotext eiorde. Die etlag der Modularisierug etstehede Module kommuiziere über Schittstelle miteiader. Diese sid erste, och sehr rohe Kadidate für eie serviceorietierte Sicht. Wie die eizele Module fuktioiere, ist sekudär. Ohe eie solche Modularisierug ka es keie SOA gebe, da och keie Services idetifiziert sid. 2. Stadardisierug Sobald eizele Module explizit defiiert vorliege, wird i diesem Schritt offekudig, dass viele Prozessschritte etwas Gemeisames habe ud daher i ei stadardisiertes Modul überführt werde köe (siehe Abbildug 3). Die Vielfalt der eizele Variatioe wird da etweder zuguste des Stadards aufgegebe oder als Etscheidugsalterative im Stadardprozess abgebildet. Dieser Schritt beötigt och mehr Fachkompetez, de geau diese Abwägug, was och i de Stadard passt ud was eie eigee Prozessschritt motiviert, ka ur mit hervorrageder Ketis der Materie erfolge. Eie weitere wichtige Kompetez kommt hier allerdigs hizu: die betriebswirtschaftliche Kompetez. Ei wichtiger Vorteil vo Stadards sid betriebswirtschaftlich relevate Effiziezsteigeruge aufgrud vo Syergie zwische vorher disjukt betrachtete Arbeitsschritte. Die Stadardisierug reduziert de mögliche Katalog der währed der Modularisierug idetifizierte rohe Service-Kadidate: Die stadardisierte Services sid abteilugsübergreifed eisetzbar, uterehmesweit abgestimmt (we auch die Stadardisierug uterehmesweit erfolgte) ud habe die ötige Abstraktio. Service-Redudaze (eie der SOA-Todsüde) müsse über die Stadardisierug beseitigt werde. 3. Automatisierug ud Wiederverwedug Das Bearbeite vo Geschäftsprozesse ist icht zwagsläufig mit dem Aspruch eier Automatisierug (siehe Abbildug 4) verbude. Vielmehr köe die vorherige Schritte auch völlig ohe elektroische Uterstützug papiergestützt erfolge. Für eie IT-SOA ist dieser Schritt allerdigs existeziell, da hier die IT-Teile der Idustrialisierug idetifiziert werde. Ierhalb eier modularisierte ud stadardisierte Prozessladkarte steht hier also die Frage ach Automatisierug bzw. Wiederverwedug a. We bereits die prozessorale Stadardisierug viel Effiziezgewi ermöglicht, ka uter Zuhilfeahme vo IT och eimal eie deutliche Effiziezsteigerug bewerkstelligt werde. Dafür ist allerdigs zwische Fach- ud IT-Abteilug im Uterehme zwiged zu kläre, wie durch die IT etweder eizele Prozessschritte völlig ersetzt oder zumidest maßgeblich uterstützt werde köe. Als weitere Kompetez kommt i diesem Idustrialisierugsschritt eiiges a Grudketisse der IT hizu: Was ist grudsätzlich mit IT überhaupt möglich? Was gibt es als fertiges IT-Produkt? Wie gut köe fertige Produkte etlag des eigee Kotextes agepasst werde? Welche achgelagerte techische Abhägigkeite werde damit eigegage oder müsse zusätzlich berücksichtigt werde? Allerdigs ist auch hier das Domäewisse och fudametal, da es letztlich um die grudsätzliche Frage geht: IT oder icht IT? Diese Etscheidug wird als die 03/

3 SOA: Idustrialisierug durch ud durch Idustrialisierugsreihefolge Die beschriebee Idustrialisierug bezieht sich auf ei gesamtes Uterehme. Gerade aus eier orgaisatorische Betrachtug heraus stellt sich damit häufig die Frage, was zuerst idustrialisiert werde muss: die IT oder das Busiess. Prizipiell sid drei Wege dekbar: Zuerst Idustrialisierug der IT ud da der Geschäftsprozesse. Zuerst Idustrialisierug der Geschäftsprozesse ud da der IT. Kombiatio beider Asätze, um früh Nutze aus de Ergebisse ziehe zu köe ud früh Feedback über die Wirksamkeit der Idustrialisierug sowohl für die IT als auch für die Fachlichkeit zu erhalte. Abb. 4: Automatisierug. Schittmege vo Gewüschtem (aus der Domäesicht) ud Machbarem (aus der IT-Sicht) verstade. Auch die Trasitio selbst hi zum IT-gestützte Vorgehe geschieht mit maximalem Domäewisse. Da die IT währed dieses Schritts meist och ihouse agesiedelt ist ud sehr kurze Diestwege zwische Fachseite ud IT-Seite existiere, ist auch die Fachkompetez i der IT i diese Uterehme extrem gut ausgeprägt. Auch dieser Schritt reduziert de mögliche Katalog der währed der Stadardisierug geschärfte IT-Service-Kadidate weiter: Diejeige Module, die als IT-basiert eigestuft werde, sid eie solide Ausgagslage für eie IT-SOA. 4. Kerkompetez-Fokussierug Der letzte Schritt der Idustrialisierug ist eigetlich die Frage, ob ei bestimmter Arbeitsschritt überhaupt durch die eigee Firma erbracht werde muss oder besser as a service vo extere Leistugserbriger eigekauft werde sollte. Diese Frage liegt icht mehr im Fokus eier Idustrialisierug mit SOA-Hitergrud. Hier köte allerdigs der Bereich der uterehmesübergreifede SOA begie, da für uterehmesübergreifede Service- Stadards durchaus die Frage relevat ist, ob die Service-Erbrigug icht vo extere Parter hizugekauft werde sollte, da der Service-Betrieb icht zur eigee Kerkompetez gehört (siehe Abbildug 5). Die zuehmede Öffug vo Wertschöpfugskette großer Ifrastrukture wie Amazo oder Dropbox mittels expliziter Schittstelle zu Teilschritte motiviert dies weiter (vgl. z. B. [Cloe14], [Kal14]). Auch we die erste beide Asätze eie eifachere Umsetzug verspreche, habe sie sigifikate Nachteile: Wird mit der IT begoe, etsteht eie Idustrialisierugsisel, die bisher icht durch IT abgedeckte Prozesse igoriert ud uter Umstäde sogar a Bedarfe ud Treds des Busiess vorbei modelliert wird. Der Begi mit de Geschäftsprozesse spiegelt ei altes Werteverstädis der IT wider, die ur als Uterstützug des Busiess aufgefasst wird. Allerdigs ist heute die IT immer häufiger das Busiess selbst (z.b. mobile Paymet). Außerdem bleibe IT-itere Idustrialisierugsmöglichkeite ohe direkte Busiess-Bezug (z.b. Backup) iitial uberücksichtigt. Spätestes eue orgaisatorische Asätze, i dee die Treug zwische Fachseite ud IT (agile Softwareetwicklug) ud auch die Treug zwische Etwicklug ud Betrieb (DevOps) sukzessive beseitigt werde, köe die Fragestellug ach eier klare Reihefolge icht beatworte. Die Frage ach der Reihefolge IT vs. Fachseite ist für die Idustrialisierug also heute icht mehr agemesse. Idustrialisierug sollte viel agiler ud allumfasseder durchgeführt werde. Die Reihefolge Idustrialisierug vor SOA dagege ist immer och fudametal. Abb. 5: Kerkompetez-Fokussierug. Idustrialisierugskotext Die reie Idustrialisierug bezieht die gesamte Orgaisatio iklusive ihrer Schittstelle ach auße ei ud wird seit jeher gazheitlich verstade. Die bekate radikale Idustrialisierug der Automobil- 22

4 schwerpukt Tipp 4: Abahmetests sollte immer grü sei Zero Bug Policy. Iteratio kapp wird. Das führt zu eiem Auch we das Release och ei paar Woche gefährliche Trugschluss: We es akzeptabel ist, mauelle Tests im Notfall wegzu- etfert sei mag, ist es sehr wichtig, Testfälle icht läger als otwedig fehlschlage zu lasse lasse, sid sie scheibar icht wichtig. auch we ma die vermutliche Ursache ket. Auch i der agile Welt ist es der Zweck Ei fehlschlageder Testfall ka durchaus vo Tests, Fehler i der Software zu fide. Probleme verdecke, die erst ach Behebug der We automatisierte Tests dazu ur offesichtliche Ursache zu Tage trete. Ziel des bedigt i der Lage sid, gibt es lediglich Teams muss es sei, die Testfälle auch währed eie Alterative: mauelles beziehugsweise exploratives Teste, bei dem die der Etwicklug grü zu halte. Grü bezieht sich hier auf die Sigalfarbe, die traditioell i Build- Tester ihre Kreativität ud Spotaität eisetze, um Fehler zu fide. Ei weset- Umgebuge eigesetzt werde. licher Nutze maueller Tests besoders bei eue Features ist die kotextbezogee Perspektive auf die zu prüfede gehesweise, we die Erweiterug durch Fuktioalität. De im Gegesatz zu Umpriorisierug doch icht stattfidet ud automatisierte Tests ket der mauelle die Tests weiterhi mauell durchgeführt Tester dere aktuelle Kotext. werde müsse. We es Kude ud Budget zulasse, Aus userer Erfahrug loht sich eie plae wir am Ede eier Iteratio für alle Abb. 6: Prizipie des SOA-Maifests (stark vereifacht). sprechede, achvollziehbare Zuordug Etwickler eie Tag ei, desse Fokus auf vo Aforderuge (User-Storys) ud maueller Testdurchführug liegt. Ziel dieses Tages ist es, die Software zerbreche zu Akzeptaztests. Wird eie Aforderug verädert oder erweitert, fließt der Auf - lasse. Geligt es, de Code durch Beut - wad für eie otwedige Apassug zer eigabe oder Datekostellatioe zu herstellug durch Hery Ford hatte daher diese Operatioalisierug der der Idustrialisierug implizite Gazheitlichkeit pro- besteheder Akzeptaztests mit i die zerbreche, wird für die Situatio, die dazu icht ur Auswirkuge auf die Prozesse i Schätzug ei. Gibt es außerhalb des geführt hat, ei automatisierter Test Form eies radikale Taylorismus, soder fitiere ka. Etwicklugsteams Iteressete für die geschriebe. Aschließed wird der Ma - durch eie hohe Stadardisierugsgrad Akzeptaztest-Kriterie, erhalte diese gel ach voll ziehbar behobe ud mit dem bis hi zur Arbeitsmootoie auch auf die wertvolles Feedback zu de Auswirkuge automatisierte Test dafür gesorgt, dass die eizele Mitarbeiter ud die Arbeitsergebisse (Ford: Sie köe jede Farbe habe, Es wurde immer wieder darauf higewie- SOA-Kotext der Äderug. Köe Aforderuge ud so ge woee höhere Robustheit erhalte Akzeptaztests eiader icht zugeordet bleibt. solage es schwarz ist ). se, dass die Eiführug eier SOA i eiem Uterehme ur i de selteste werde, kommt das böse Erwache bei der Um diese Gazheitlichkeit systematisch zu Etwicklug: Die Äderuge dauer füf Plädoyer für Nichterreiche, köe Uterehmesmodelle Fälle eie techische Herausforderug Miute, das Apasse der fehlgeschlagee alte Akzeptaztests zwei Tage. We die geforderte Fuktioalität imple- Automatisierug verwedet werde, wie sie z.b. aus dem ist (vgl. [Lem13]). Das würde ämlich Bereich des Total-Quality-Maagemet ebefalls dem Paradigma-Gedake (siehe metiert wurde, also sämtliche automatisierte Tests durchgeführt ud um evetuell (TQM) gebräuchlich sid (vgl. [Mal11]). obe) widerspreche, der als grudsätzliches Dekmuster alles i eier Orgaisa- Mauelle Tests Ei gerade i Europa weit verbreitetes Modell ist das der EFQM. Auf der oberste tio i Betracht zieht. So ist es ur folge- Mauelle Tests sid auch i agile Pro - otwedige mauelle Tests der eue jekte wichtig. Sie schließe die Lücke zwische automatisierte Tests ud aufwädig weitere mauelle Stufe a. Features ergäzt wurde, schließt sich eie Ebee ket es die drei wesetliche Säule: ebefalls alle relevate Strukture i eirichtig, dass die SOA wie ei Paradigma oder gar icht automatisiert prüfbare Der User-Acceptace-Test (UAT) diet em Uterehme beleuchte muss. Diese Aforderuge. Dabei köe mauelle dazu, eie Software uter reale Bedi gu - Orgaisatioe sid deutlich komplexer als die Eiteilug Tests zeitaufwädig ud fehlerafällig sei. ge zu teste ud zu prüfe, ob eie Prozesse i IT ud Fachseite. Eiige Hiweise für Auch i der agile Welt eige Projekt - Software effiziet ud effektiv geutzt werde ka. Software, die für Edaweder Ergebisse diese Forderug ach Gazheitlichkeit lieteams dazu, mauelle Tests zu verachlässige, we die Zeit am Ede eier gedacht ist, muss bei dieser Testart vom Die Idustrialisierug berührt allerdigs Beutzer selbst geprüft werde. Dazu ist es icht ur diese Hauptsäule, soder auch otwedig, de fachliche Kotext der zu die sechs Tipp 5: weitere Pair-Testig Kotexte im UAT. (siehe Abbildug User-Acceptace-Tests 1). Der Pukt Politik sollte ud dabei Strategie ie prüfede Soft ware zu kee ud eizu- umfasst durch hier die beispielsweise Softwareetwickler so wichtige durchgeführt wie werde. Arbeitsschutz, UAT mittels Pair-Testig Betriebsrat hat ud Aspekte Dateschutz. sich dagege Eie bewährt. Idustrialisierug, Hier führt ei die diese Pukte Beutzer igoriert, de UAT durch, hat der gute Etwickler Chace zu scheiter. sitzt daebe ud bekommt direkt wertvolles Feedback zur Das EFQM-Modell liefert Beutzbarkeit damit seier eie gute Arbeit. Im Idealfall ist dieser Tester der Kotextliste, die bei eier Idustrialisierug berücksichtigt werde muss. Im Fol- Kude selbst oder ei Mitarbeiter mit tiefem fachliche Wisse, aber keie weitere Ketisse über de gede wird aufgezeigt, wie die SOA durch Quellcode. OBJEKTspektrum ist eie Fachpublikatio des Verlags: SIGS DATACOM GmbH Lidlaustraße 2c Troisdorf Tel.: / Fax: / ifo@sigs-datacom.de fert bereits das SOA-Maifest selbst (vgl. beziehe. Test werk zeuge sid hierzu icht [Ars09]): i der Lage. Aus userer Sicht ist ei vollstädig automatisierter UAT auch i der Prizip 1: Respektiere die Sozial- ud agile Welt icht seriös durchführbar ausgeomme automatisierte Smoke-Tests, die Machtstruktur der Orgaisatio. die Vollstädigkeit der Fuk tio alität oberflächlich prüfe. Gele getlich werde auto- Prizip 2: Erkee a, dass SOA letztlich Veräderug auf viele matisierte GUI-Tests (Graphi cal-user- Ebee bedeutet. Iterface) als UAT bezeichet. Diese Tests Prizip 11: Services ud dere Ausgestaltug sollte sich ahad der sid fuktioale Tests uter Eibeziehug eier Oberfläche ud köe zum Beispiel Art ud Weise, wie sie wirklich im Regressiostest eie wertvolle Beitrag geutzt werde, etwickel. leiste. Sie sid aber kei Er satz für die Eibeziehug des Mesche als Tester. Hier sid ur die Prizipie des SOA- Maifests geat, die bereits i ihrer Formulierug auf die komplexe Struktur vo Orgaisatioe Tipp 6: Zeitaher eigehe. UAT. Doch bereits diese Fragmete Währed der lasse UAT i eie der klassische hohe Nähe zum EFQM-Modell Projektwelt eie aufkomme, abgeschlossee da Phase ebe dem mit darstellt, SOA bietet zu erbrigede es sich i agile Projekte Geschäftswert auch die Prozesse ud die Orgaisa- a, umittelbar ach dem Abschluss eier Fuktioalität Nutzer-Feedback eizuhole. Will der Etwickler i Folge des tiosstruktur selbst agesproche werde. Grudsätzlich lasse sich alle Prizipie des Feedbacks Äderuge vorehme, ist SOA-Maifests auf die Aspekte des EFQMseie Arbeit effektiver als ach eiem Modells beziehe. Um dies zu verdeutliche, UAT-Feedback mehrere Woche. habe wir i Tabelle 1 eie Zuordug zwische de Prizipie des SOA-Maifests ud de Aspekte des EFQM-Frameworks vorgeomme. Abbildug 6 zeigt die Prizipie Ei Fokus des UAT liegt auf der Istal - lierbarkeit der Software. Diese lässt sich des SOA-Maifests i vereifachter Form. leicht i Kombiatio mit der obe Die eifache Zuordug i Tabelle 1 soll beschriebee automatisierte Prüfug auf aufzeige, wie ahelieged es ist, für die Vollstädigkeit awede: We dieser der Idustrialisierug iewohede Forderug ach Gazheitlichkeit dasselbe Mo- Smoke-Test erfolgreich war, ließ sich die Software offebar erfolgreich istalliere. dell auch für eie SOA zu verwede. Da Ziel des UAT ist es, die Beutzbarkeit eier die SOA selbst ur de servicerelevate Software zu prüfe. Aus eigeer Erfahrug Teilausschitt ud isbesodere auch die wisse wir, dass für eie erfolgreiche UAT techische Umsetzug betrachtet, ka die i alle Teststufe gewissehaft gearbeitet gazheitliche Idustrialisierug als Ergebis eie SOA sei (we SOA ohe techi- werde muss. Für Et wickler gibt ichts Schlimmeres als eie UAT, der vo de sche Umsetzug verstade wird) oder als Tester oder vom Kude ach weige ideale Vorarbeit (we SOA iklusive der Miute abgebroche wird, weil viele offesichtliche Fehler i de vorherige Teststufe techische Umsetzug verstade wird) geutzt werde. Die sich daraus ergebede icht etdeckt wurde ud der Software Kerhypothese lautet: magelde Qualität bescheiigt wird. Last ud Performace-Tests Die Teststufe Last- ud Performace-Tests diet im Wesetliche dazu, drei icht- 4 03/2015 /

5 SOA: Idustrialisierug durch ud durch Prizipie des SOA- Maifests Respektiere die Sozial- ud Machtstruktur der Orgaisatio. Erkee a, dass SOA letztlich Veräderug auf viele Ebee bedeutet. Der Bereich, i dem SOA eigeführt wird, ka uterschiedlich ausfalle. Halte die Aufwäde i eiem überschaubare ud sivolle Rahme. Produkte ud Stadards allei werde weder SOA liefer, och das serviceorietierte Paradigma umsetze. SOA ka mit uterschiedliche Techologie ud Stadards umgesetzt werde. Etabliere eiheitliche Uterehmesstadards ud - richtliie auf der Basis vo Idustrie- ud De- facto- Stadards sowie Stadards der SOA- Gemeide. Strebe ach auße Eiheitlichkeit a, aber lasse ach ie Vielfalt zu. Idetifiziere Services durch Zusammearbeit zwische fachliche ud techische Iteressevertreter. Maximiere die Awedbarkeit vo Services durch Berücksichtigug der derzeitige ud zuküftige Awedugsgebiete. Stelle sicher, dass Services fachliche Aforderuge ud Ziele diee. Services ud dere Ausgestaltug sollte sich ahad der Art ud Weise, wie sie wirklich geutzt werde, etwickel. Tree die verschiedee Aspekte eies Systems, die sich uterschiedlich häufig äder. Reduziere implizite Abhägigkeite ud publiziere alle extere Abhägigkeite, um Robustheit zu förder ud die Auswirkuge vo Veräderuge zu reduziere. Orgaisiere jede Service auf jeder Abstraktiosebee i oder ahad eier zusammehägede ud überschaubare Fuktioseiheit. Jeder fehlede Idustrialisierugsschritt i eiem der vo EFQM aufgezeigte Dimesioe muss zwagsläufig zum Scheiter eier SOA- Iitiative führe, ebeso wie das vollstädige Vergesse eies EFQM- Aspektes bezüglich der Idustrialisierug. Als Beleg dieser Hypothese werde im Folgede eiige typische Stolpersteie der Eiführug vo SOA erläutert ud ierhalb dieses Modells verortet. Es wird sich zeige, wie gut dieses Modell tatsächlich Aspekte des EFQM- Frameworks Mitarbeiter, mitarbeiterbezogee Ergebisse, Politik ud Strategie, Parterschaft ud Ressource. Führug, Politik ud Strategie, Mitarbeiter, Prozesse, alle Ergebisaspekte. Politik ud Strategie, Parterschaft ud Ressource, alle Ergebisaspekte. Politik ud Strategie, Prozesse, alle Ergebisaspekte. Politik ud Strategie, Parterschaft ud Ressource Führug, Politik ud Strategie, Prozesse. Führug, Politik ud Strategie, Prozesse, Mitarbeiter. Führug, Politik ud Strategie, Parterschaft ud Ressource, Prozesse, Mitarbeiter, alle Ergebisse. Führug, Politik ud Strategie, Parterschaft ud Ressource, Prozesse, alle Ergebisse. Tabelle 1: Assoziatio zwische SOA-Maifest ud EFQM-Modell. Politik ud Strategie, Parterschaft ud Ressource, Prozesse, alle Ergebisse. geeiget ist, die Fehler bei der Etablierug vo SOA zu aalysiere, um darauf aufbaued Gegemaßahme abzuleite. Kostruktiv formuliert bedeutet dies: We eier SOA-Eiführug eie gazheitliche Idustrialisierug voragestellt wird, sid viele Risike ausgeschaltet. Fehlede Harmoisierug der Date Eier der häufigste Grüde, warum SOA i der Vergageheit gescheitert ist, war die fehlede Harmoisierug der Iformatiosobjekte bzw. die Harmoisierug der Date des Uterehmes. Dabei wurde vo uterschiedliche Quelle Services etwickelt ud bereitgestellt, die sich über- scheidede oder zueiader ikompatible Date abote. We ei Uterehme zwei Systeme besitzt, die Master vo Kude- ud Persoedate sid, ud beide Systeme diese Date über Services abiete, sid diese Dieste für potezielle Service-Nutzer ohe klare Regeluge schwer eisetzbar. Es muss geklärt sei, welches System die aktuelle Date hält ud i welchem System Äderuge a Kudedate durchgeführt werde müsse. Es gibt eie Reihe weiterer typischer Beispiele für die fehlede Harmoisierug, beispielsweise Adressdate, Kotoverbiduge, Kommuikatiosverbiduge, Termie ud Dokumete. Orgaisatioe, die trotz Überscheiduge vo Iformatiosobjekte i verschiedee Systeme eie SOA eiführe, habe i der Regel och mehrere Jahre damit zu kämpfe, diese Harmoisierug achzuziehe. Der Aufwad für die Reduzierug vo Redudaze ka dabei durchaus um de Faktor zwei oder drei höher sei als bei eier Harmoisierug der Date vo Afag a. Etlag des EFQM sid die Schwachstelle offekudig, da es um mitarbeiterbezogee (z. B. itere Arbeitsergebisse wie Bearbeitugsvermerke) ud kudebezogee Ergebisse (z.b. Adressdate) geht: Eie saubere Modularisierug hat klare Veratwortugsbereiche zur Folge. Überscheiduge gibt es icht mehr, soder die Abgrezug wird durch Schittstelle explizit. Die folgede Stadardisierug ermöglicht da eie eiheitliche Nomeklatur eier SOA-Kommuikatio zwische alle beteiligte Kommuikatiosparter. Stabile Architektur, die SOA uterstützt Eie Orgaisatio muss über eie stabile IT-Architektur verfüge, die SOA uterstütze ka. Es reicht ach userer Erfahrug icht aus, dass jede Awedug so erweitert wird, dass die Nutzug oder das Agebot vo SOA-Services grudsätzlich möglich ist. Dass Services geutzt werde köe, bedeutet och icht, dass sie leicht beutzbar sid, mit ausreicheder Performace agebude werde köe oder dass die zu Grude liegede IT-Architektur gar stabil geug ist. Betrachte wir eimal das folgede Beispiel: Wie leicht ka es eier Orgaisatio falle, eie SOA eizuführe, die i ihrer IT- Ladschaft folgede Kompoete vereit? Ereigisgesteuerte Architektur Messagig-Systeme Cliet-Server-Aweduge 24

6 Applicatio-Server-Cluster Multi-Layer-Systeme Host-Systeme Kakophoe Isellösuge mit Kompoeteframeworks, proprietäre Sprache ud Kommuikatiosstile wie CORBA,.NET, VBA, JEE ud RPC Das wird ur mit großer Mühe ud uter Träe gelige. Mit Bezug auf EFQM sid auch hier die Probleme offesichtlich, da die wichtige Dimesio Parterschaft ud Ressource explizit agesproche wird. Die obe aufgeführte Problembereiche zeige deutliches Potezial für Stadardisierug. Selbst we die Modularisierug och erfolgreich durchgeführt wurde, so weist die Verschiedeartigkeit der Systeme ud Techologie (alias Ressource, evetuell auch vo Parter) auf de uvollstädige Stadardisierugsschritt, was da hi zu sigifikate Mehrkoste bei der SOA-Eiführug führt, ohe dass die SOA-Umsetzug selbst dafür schuldig gemacht werde ka. Auch we eie SOA sicherlich techisch heterogee Systeme bis zu eiem bestimmte Grad itegriere ka, so sollte der Grudtypus der IT sehr wohl bereits stadardisiert sei. Aber auch auf der ächste Ebee der Techologieplattform (z.b..net vs. JEE) ist eie uterehmesweite Stadardisierug sehr hilfreich bei der Etablierug eier SOA. Harmoisierug vo Prozesse ud Orgaisatioe Ählich wie die Date müsse auch Prozesse harmoisiert werde, die mit der SOA verbessert werde solle. Prozesse diee i der Regel dazu, eie Abteilug bei der Durchführug ihrer Aufgabe zu uterstütze also müsse geau geomme Aufbau ud Aufgabe der betroffee Orgaisatio harmoisiert werde. Geschieht das icht, wird eie SOA keie Vorteile brige. I große Orgaisatioe mit viele Abteiluge werde gleiche Aufgabe ger auf völlig uterschiedliche Art ud Weise bediet. Wo die eie Abteilug für eie bestimmte Aufgabe eie mediebruchfreie, elektroische Prozess lebt, verwedet eie adere Abteilug eie ähliche Prozess mit viele mauelle Schritte ud i eier dritte Abteilug gibt es gar keie defiierte Prozess. Hier wird bei jeder Durchführug des Prozesses ad hoc etschiede, wie zu verfahre ist. Es besteht Koses i de drei Abteiluge, dass auf keie Fall der Prozess eier adere Abteilug verwedet werde ka. Warum, weiß iemad mehr so geau. Auch hier sid die fehlede Vorbediguge der Idustrialisierug für die im EFQM-Modell aufgeführte Etitäte ud hier atürlich alle vora der explizite Bereich der Prozesse offekudig. Iteressaterweise wird die Eiführug eier SOA heute immer och ger als Vehikel verwedet, um die Harmoisierug vo Prozesse vorazutreibe. Ei Busiess-Prozess wird mit Hilfe vo auf dem Reißbrett etworfee Services umgesetzt. Da wird erwartet, dass die vo diesem Prozess betroffee Abteiluge die etsprechede Services verwede. Die Erfolgswahrscheilichkeit dieses Asatzes ist userer Erfahrug ach eher gerig, sodass er icht empfohle werde ka. Die SOA-Umsetzug sollte ach der Idustrialisierug erfolge, sie sollte diese icht atreibe. Das Gesetz vo Coway (vgl. [Co]) beschreibt, dass sich die Kommuikatiosbeziehuge ierhalb eier Orgaisatio (vgl. Etität Führug im EFQM i Abbildug 1) i der Architektur ihrer IT- Ladschaft widerspiegel. Werde diese Kommuikatiosbeziehuge die uter aderem durch Prozesse ud Orgaisatioe beschriebe werde vor der Eiführug eier SOA icht harmoisiert, werde diese i der Architektur zemetiert ud behider die Flexibilität vo Prozesse ud Orgaisatio eher, als dass sie diese uter- Literatur & Liks stütze. Die Reihefolge ist also ei wichtiger Erfolgsfaktor. SOA-Teste i der Praxis Komplexe Services eier SOA lasse sich häufig schwer teste ud die Aussagekraft vo Testergebisse ist stark eigeschräkt. Nebe eiige praktische Grüde liegt die Ursache dafür häufig i der Kozeptio ud dem Etwurf der Services ud der Tests selbst. SOA-Tests werde üblicherweise sychro durchgeführt. I der Realität ist eie SOA asychro ausgelegt. Als Folge sid Laufzeitverhalte, Ergebisse oder Atwortzeite aus de Tests ur bedigt mit der Realität vergleichbar. Durch klassische, fuktioale Tests ka ur schwer ermittelt werde, ob icht-fuktioale Aforderuge wie kurze Atwortzeite oder Durchsatz im Echtbetrieb tatsächlich geleistet werde köe. Eie Ursache dafür ist, dass das tatsächliche Nutzugsverhalte im Test ur asatzweise simuliert werde ka. Werde mit der SOA viele kleiteilige, miteiader kombiierbare Services betriebe, fällt die Vorhersagbarkeit des Nutzugsverhaltes och schwerer. Die Azahl der a der SOA beteiligte IT-Systeme ud ihre Netztopologie spiele ebeso eie Rolle wie die Azahl ud die Nutzugshäufigkeit der eizele Service-Operatioe bezoge [Ada01] L. Adams, Egoless programmig: The path to better code, TechRepublic, März 2001, siehe: [Ars09] Ali Arsajai et al., SOA-Maifest, 2009, siehe: [BIT] BITKOM, Plattform Idustrie 4.0, siehe: [Bre13] W. Breer et al., Die Zukuft der IT i Uterehme, i: F. Abolhassa (Hrsg.), Der Weg zur modere IT-Fabrik: Idustrialisierug Automatisierug Optimierug, Spriger Gabler Verlag, 2013 [Cloe14] T. Cloer, Leiteder, Dropbox brigt for-busiess-api, i: Computerwoche [Co] M. Coway, Coway s Law, siehe: [Kal14] F. Kaleda, Amazo führt API für Cloud Drive ei, i: ZDNet [Lem13] P. Lemberger, M. Morel, Maagig Complexity of Iformatio Systems, Wiley Olie Library, Jauar 2013 (dort Why has SOA failed so ofte, Appedix 3), siehe auch: [Mal11] C. Malory, T. Hummel, Total Quality Maagemet: Tipps für die Eiführug, Haser- Verlag (4. Aufl.), /

7 SOA: Idustrialisierug durch ud durch auf die beteiligte Kompoete. Die Verfügbarkeit dieser Systeme ist uter Umstäde Schwakuge uterworfe, ierhalb derer die SOA weiterhi fuktioiere muss. Dieses Verhalte im Test zu simuliere, ist erfahrugsgemäß sehr aufwädig. Die Qualität des Serviceschitts der beteiligte Services zeigt sich häufig erst i der Praxis. Beutzer verwede Services icht ur, we sie es müsse, soder auch, we sie es köe. Eie Service-Operatio, die viele Date liefert, wird uter Umstäde hudertmal häufiger verwedet, als bei der Kozeptio erwartet. Das System, das diese Service abietet, wird schell zum Egpass. Auch dies ka ur schwer im Test herausgefude werde. Die beschriebee Probleme adressiere Bereiche, die erst durch das Idustrialisierugskozept, das da für die IT mittels eier SOA realisiert wird, etstehe. Dies fällt icht direkt bei der Modularisierug auf, da diese ja och primär die Geschäftsprozesse adressiert. Aber im Zuge der Stadardisierug ud Etablierug eier zetrale SOA über die folgede Automatisierug taucht ei eues Arbeitspaket für dieses eue IT-Artefakt auf: das Teste. Dieses muss da ebeso modularisiert ud stadardisiert werde. Etlag des EFQM wird da ämlich deutlich, dass dieser eue Artefakt ebefalls eier Führug bedarf, dass dort auch wohl-defiierte Prozesse (z.b. für das Deploymet ud das Stagig) otwedig sid ud dass auch dort bestimmte Schlüsselergebisse (z.b. die Eihaltug vo Service Level Agreemets (SLAs)) ablesbar sei sollte. Fazit Die Idustrialisierug der IT ist heute ei uumkehrbarer Tred. Der für eies der größte IT-Wachstumsfelder verwedete Begriff der Idustrie 4.0 zeigt die Aahme, dass die obe formulierte Idustrialisierugsschritte für die IT scho umgesetzt sid, um da eue Bereiche hier ebe isbesodere Cyber-Physical-Systems i Form vo Smart Factories (vgl. z.b.[bit]) zu befruchte. Ob das Ziel eier solche Idustrialisierug u SOA heißt oder Idustrie 4.0, ist belaglos das hiter eier SOA stehede Kozept muss icht revitalisiert werde: Es war immer ud wird immer relevat bleibe. Die Schwierigkeit der Umsetzug vo SOA ist dabei ihre Iterdiszipliarität: Es ist keie rei techische Herausforderug, die auf die IT beschräkt ist die Umsetzug ist vielmehr ei die gesamte Orgaisatio veräderdes Paradigma. Das der Awedug im Kotext der Idustrialisierug etlehte Die Autore Ramo Ager (ramo.ager@capgemii.com) arbeitet als Maagig Solutio Architect im Bereich Service Idustries bei Capgemii. Er beschäftigt sich isbesodere mit eue Techologie, Softwarearchitektur ud agile Methode. Außerdem arbeitet er aktiv im BITKOM-Arbeitskreis Software-Architekture mit ud promoviert berufsbegleited a der TU Ilmeau. EFQM-Modell hilft, diese Vielschichtigkeit ud Iterdepedeze zu verstehe. Für eie so aufgesetzte SOA muss die Idustrialisierug demach gazheitlich auf alle relevate Aspekte eier Orgaisatio eiwirke. Dies sid etlag des EFQM- Modells weigstes die Orgaisatio, die Prozesse ud alle Ergebisse. We diese Idustrialisierug gazheitlich ud zielorietiert für alle diese Dimesioe solide durchgeführt wird, ka eie SOA erfolgreich werde. Die Idustrialisierug ist demach eie hireichede Vorbedigug für eie SOA. Erfolgt dies icht, ist der Misserfolg häufig vorprogrammiert, ka aber keieswegs der SOA-Umsetzug zugesproche werde, soder der uvollstädige Berücksichtigug vo SOA als grudlegede, serviceorietierte Dekweise i eiem Uterehme. Dr. Frak Simo (frak.simo@bluecarat.de) leitet bei der BLUECARAT AG de Bereich Busiess Developmet ud etwickelt eue Techologie ud Beratugsasätze. Im BITKOM leitet er de Lekugsausschuss Software ud ist Leiter der Arbeitskreise Software-Egieerig ud Software-Architekture. Außerdem ist er im Vorstad des Germa Testig-Boards. 26