SOA: Industrialisierung durch und durch
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
SOA: Industrialisierung durch und durch
SOA:
Industrialisierung durch und durch
Die Industrialisierung von IT und die Einführung einer SOA wurden jahrelang völlig separat von unterschiedli-
chen Personen eines Unternehmens behandelt. Dabei besteht zwischen beiden Disziplinen eine existentielle
Relation: Wenn im Rahmen der Industrialisierung Prozesse verändert werden, müssen Entscheidungen zum
Umgang mit Modularisierung, Standardisierung, Automatisierung und Wiederverwendung getroffen werden
sowie eine Fokussierung auf Kernkompetenzen erfolgen. Diese Begriffe haben aber auch für die Umsetzung einer
SOA eine fundamentale Bedeutung. Mit diesem Artikel soll gezeigt werden, wie im Rahmen der Industrialisierung
eine erfolgreiche SOA entstehen kann und bekannte Stolpersteine umgangen werden können.
Totgesagte leben länger – und wenn nicht (Scoping) verwendet, um dann konkrete gung auf die IT-Leistungserstellung“ definie-
als Begriff, dann in jedem Fall als Denkwei- Hinweise dafür zu erhalten, warum SOA- ren. Demnach lässt sich Industrialisierung
se. Denn das ist SOA: „Serviceorientierung Initiativen sich in der Praxis häufig so ex- durch die im Folgenden beschriebenen vier
ist ein Paradigma, das den Rahmen für un- trem schwer gestalten lassen. Erreicht wird sequenziellen Schritte klassifizieren, an de-
ser Handeln vorgibt“ (erster Satz des SOA- dies durch die Anwendung eines aus dem ren Ende eine vollständig industrialisierte IT
Manifests, vgl. [Ars09]) und ein Paradigma Industrialisierungskontext bekannten Or- steht. Diese Schritte erläutern wir kurz aus
ist nicht weniger als „eine grundlegende ganisationsmodells für SOA: dem EFQM- dem Blickwinkel der Geschäftsprozesse und
Denkweise“. Modell (European Foundation for Quality IT, sodass das Ergebnis einer solchen Indus-
Diese Denkweise fokussiert Dienste und Management, vgl. z. B. [Mal11], siehe den trialisierung eine SOA sein kann.
Geschäftsprozesse, die in der Regel keines- „Kontext“-Bereich in Abbildung 1).
wegs allesamt unter den meist sehr tech- 1. Modularisierung
nisch belegten Begriff Serviceorientierte Industrialisierung Idee dieses Schrittes (siehe Abbildung 2) ist
Architektur (SOA) subsumiert werden kön- Mit Brenner et al. (vgl. [Bre13]) lässt sich es, den Geschäftsprozess nicht mehr mo-
nen. Auch eine Cloud hat eine serviceorien- die Industrialisierung der IT als die „Über- nolithisch atomar, sondern als Verkettung
tierte Sicht, denn technische Details der Lie- tragung erfolgreicher Managementkonzepte bestimmter Teilschritte zu verstehen. Ein
fererbringung spielen für den Nutzer hier und -methoden aus der industriellen Ferti- wesentlicher Vorteil ist die Egoless Produc-
keine oder wenigstens eine untergeordnete
Rolle. Auch andere Facetten des Everything
as a Service (XaaS) besitzen eine serviceo-
rientierte Sicht und reihen sich damit her-
vorragend in dieses Paradigma ein. Ob
dieses Phänomen nun als SOA bezeichnet
wird, spielt im täglichen Einsatz kaum eine
Rolle – interessant ist das dahinter liegende
Denkschema, heute und sicher auch noch
weiter in der Zukunft.
In diesem Artikel wollen wir versuchen,
die Essenzen des Paradigmas „Serviceori-
entierung“ herauszuarbeiten. Es wird sich
zeigen, dass diese Essenzen eine große Nähe
zum Konzept der Industrialisierung haben.
Wir wollen darstellen, dass eine SOA als
ein mögliches Ergebnis der Industrialisie-
rung aufgefasst werden kann und sich aus
dieser Sichtweise wertvolle Zusammenhän-
ge für den Erfolg einer SOA ergeben. Wich-
tig ist aber hier schon einmal der Hinweis,
dass es auch eine Industrialisierung ohne
SOA als Ergebnis gibt. Die SOA ist folglich
eine konkrete Zielsetzung von Industriali-
sierung – angewendet auf Geschäftspro-
zesse und die sie unterstützende IT. Dieser
aufgezeigte Zusammenhang wird anschlie-
ßend für eine Reichweiten-Beurteilung Abb. 1: SOA durch Industrialisierung und ihre Einordnung in das EFQM-Modell.
20
www.objektspektrum.de
noch in den Standard passt und was einen
eigenen Prozessschritt motiviert, kann nur
mit hervorragender Kenntnis der Materie
erfolgen. Eine weitere wichtige Kompetenz
kommt hier allerdings hinzu: die betriebs-
wirtschaftliche Kompetenz. Ein wichtiger
Vorteil von Standards sind betriebswirt-
schaftlich relevante Effizienzsteigerungen
aufgrund von Synergien zwischen vorher
disjunkt betrachteten Arbeitsschritten.
Die Standardisierung reduziert den mögli-
chen Katalog der während der Modulari-
sierung identifizierten rohen Service-Kan-
didaten: Die standardisierten Services sind
abteilungsübergreifend einsetzbar, unter-
nehmensweit abgestimmt (wenn auch die
Abb. 2: Modularisierung. Standardisierung unternehmensweit er-
folgte) und haben die nötige Abstraktion.
Service-Redundanzen (eine der SOA-Tod-
tion (ähnlich zu Egoless Programming, vgl. Kontext einordnen. Die entlang der Modu- sünden) müssen über die Standardisierung
[Ada01]). Dadurch werden Prozesse, die larisierung entstehenden Module kommu- beseitigt werden.
vorher nur implizit in den Köpfen einzelner nizieren über Schnittstellen miteinander.
Personen vorhanden waren, explizit. Ein- Diese sind erste, noch sehr rohe Kandida- 3. Automatisierung und
zelne Mitarbeiter können leichter ersetzt ten für eine serviceorientierte Sicht. Wie Wiederverwendung
bzw. entlastet werden, was aus Unterneh- die einzelnen Module funktionieren, ist se- Das Bearbeiten von Geschäftsprozessen ist
menssicht als durchaus positiv zu bewer- kundär. Ohne eine solche Modularisierung nicht zwangsläufig mit dem Anspruch ei-
ten ist. Die Unternehmensprozesse werden kann es keine SOA geben, da noch keine ner Automatisierung (siehe Abbildung 4)
„schulbar“ und sind daher vom Grunde her Services identifiziert sind. verbunden. Vielmehr können die vorheri-
übertragbar. gen Schritte auch völlig ohne elektronische
Für diese saubere Modellierung und ge- 2. Standardisierung Unterstützung „papiergestützt“ erfolgen.
genseitige Abgrenzung der Arbeitsprozesse Sobald einzelne Module explizit definiert Für eine IT-SOA ist dieser Schritt allerdings
ist zunächst detailliertes Wissen über die vorliegen, wird in diesem Schritt offen- existenziell, da hier die IT-Teile der Indus-
Abläufe selbst erforderlich. Die Erfahrung kundig, dass viele Prozessschritte etwas trialisierung identifiziert werden. Innerhalb
zeigt, dass sogar viele Personen, die opera- Gemeinsames haben und daher in ein stan- einer modularisierten und standardisierten
tiv maximal tief in bestimmte, noch nicht dardisiertes Modul überführt werden kön- Prozesslandkarte steht hier also die Frage
modularisierte Arbeitsschritten involviert nen (siehe Abbildung 3). Die Vielfalt der nach Automatisierung bzw. Wiederver-
sind, häufig nicht das große Ganze über- einzelnen Variationen wird dann entweder wendung an. Wenn bereits die prozesso-
blicken. Der Begriff des „Fachidioten“, der zugunsten des Standards aufgegeben oder rale Standardisierung viel Effizienzgewinn
rein vertikal spezialisiert arbeitet, lässt sich als Entscheidungsalternative im Standard- ermöglicht, kann unter Zuhilfenahme von
hier einordnen. Der Modularisierer dage- prozess abgebildet. IT noch einmal eine deutliche Effizienzstei-
gen kennt die operative Ebene ebenso gut, Dieser Schritt benötigt noch mehr Fachkom- gerung bewerkstelligt werden. Dafür ist al-
kann sie aber darüber hinaus auch in einen petenz, denn genau diese Abwägung, was lerdings zwischen Fach- und IT-Abteilung
im Unternehmen zwingend zu klären, wie
durch die IT entweder einzelne Prozess-
schritte völlig ersetzt oder zumindest maß-
geblich unterstützt werden können.
Als weitere Kompetenz kommt in diesem
Industrialisierungsschritt einiges an Grund-
kenntnissen der IT hinzu: Was ist grund-
sätzlich mit IT überhaupt möglich? Was
gibt es als fertiges IT-Produkt? Wie gut
können fertige Produkte entlang des eige-
nen Kontextes angepasst werden? Welche
nachgelagerten technischen Abhängigkei-
ten werden damit eingegangen oder müssen
zusätzlich berücksichtigt werden?
Allerdings ist auch hier das Domänen-
wissen noch fundamental, da es letztlich
um die grundsätzliche Frage geht: IT oder
Abb. 3: Standardisierung. nicht IT? Diese Entscheidung wird als die
03/2015 21
SOA: Industrialisierung durch und durch
de aus einer organisatorischen Betrachtung
heraus stellt sich damit häufig die Frage,
was zuerst industrialisiert werden muss: die
IT oder das Business. Prinzipiell sind drei
Wege denkbar:
n Zuerst Industrialisierung der IT und
dann der Geschäftsprozesse.
n Zuerst Industrialisierung der Geschäfts-
prozesse und dann der IT.
n Kombination beider Ansätze, um früh
Nutzen aus den Ergebnissen ziehen zu
können und früh Feedback über die
Wirksamkeit der Industrialisierung so-
wohl für die IT als auch für die Fach-
lichkeit zu erhalten.
Auch wenn die ersten beiden Ansätze eine
Abb. 4: Automatisierung. einfachere Umsetzung versprechen, haben
sie signifikante Nachteile:
Schnittmenge von Gewünschtem (aus der Firma erbracht werden muss oder besser
Domänensicht) und Machbarem (aus der „as a service“ von externen Leistungser- n Wird mit der IT begonnen, entsteht eine
IT-Sicht) verstanden. Auch die Transition bringern eingekauft werden sollte. Diese Industrialisierungsinsel, die bisher nicht
selbst hin zum IT-gestützten Vorgehen ge- Frage liegt nicht mehr im Fokus einer In- durch IT abgedeckte Prozesse ignoriert
schieht mit maximalem Domänenwissen. dustrialisierung mit SOA-Hintergrund. und unter Umständen sogar an Bedar-
Da die IT während dieses Schritts meist Hier könnte allerdings der Bereich der un- fen und Trends des Business vorbei mo-
noch inhouse angesiedelt ist und sehr kurze ternehmensübergreifenden SOA beginnen, delliert wird.
Dienstwege zwischen Fachseite und IT-Seite da für unternehmensübergreifende Service- n Der Beginn mit den Geschäftsprozes-
existieren, ist auch die Fachkompetenz in Standards durchaus die Frage relevant ist, sen spiegelt ein altes Werteverständnis
der IT in diesen Unternehmen extrem gut ob die Service-Erbringung nicht von exter- der IT wider, die nur als Unterstützung
ausgeprägt. nen Partnern hinzugekauft werden sollte, da des Business aufgefasst wird. Allerdings
Auch dieser Schritt reduziert den möglichen der Service-Betrieb nicht zur eigenen Kern- ist heute die IT immer häufiger das
Katalog der während der Standardisierung kompetenz gehört (siehe Abbildung 5). Die Business selbst (z. B. mobile Payment).
geschärften IT-Service-Kandidaten weiter: zunehmende Öffnung von Wertschöpfungs- Außerdem bleiben IT-interne Industria-
Diejenigen Module, die als IT-basiert einge- ketten großer Infrastrukturen wie Amazon lisierungsmöglichkeiten ohne direkten
stuft werden, sind eine solide Ausgangslage oder Dropbox mittels expliziter Schnittstel- Business-Bezug (z. B. Backup) initial
für eine IT-SOA. len zu Teilschritten motiviert dies weiter unberücksichtigt.
(vgl. z. B. [Cloe14], [Kal14]). n Spätestens neue organisatorische An-
4. Kernkompetenz-Fokussierung sätze, in denen die Trennung zwischen
Der letzte Schritt der Industrialisierung Industrialisierungsreihenfolge Fachseite und IT (agile Softwareent-
ist eigentlich die Frage, ob ein bestimmter Die beschriebene Industrialisierung bezieht wicklung) und auch die Trennung
Arbeitsschritt überhaupt durch die eigene sich auf ein gesamtes Unternehmen. Gera- zwischen Entwicklung und Betrieb
(DevOps) sukzessive beseitigt werden,
können die Fragestellung nach einer
klaren Reihenfolge nicht beantworten.
Die Frage nach der Reihenfolge „IT vs.
Fachseite“ ist für die Industrialisierung also
heute nicht mehr angemessen. Industriali-
sierung sollte viel agiler und allumfassen-
der durchgeführt werden. Die Reihenfolge
„Industrialisierung vor SOA“ dagegen ist
immer noch fundamental.
Industrialisierungskontext
Die reine Industrialisierung bezieht die ge-
samte Organisation inklusive ihrer Schnitt-
stellen nach außen ein und wird seit jeher
ganzheitlich verstanden. Die bekannte „ra-
Abb. 5: Kernkompetenz-Fokussierung. dikale“ Industrialisierung der Automobil-
22
www.objektspektrum.de
schwerpunkt
Tipp 4: Abnahmetests sollten immer
fert bereits das SOA-Manifest selbst (vgl.
grün sein – Zero Bug Policy. Iteration knapp wird. Das führt zu einem beziehen. Testwerkzeuge sind hierzu nicht
[Ars09]):
Auch wenn das Release noch ein paar Wochen gefährlichen Trugschluss: Wenn es akzep- in der Lage. Aus unserer Sicht ist ein voll-
entfernt sein mag, ist es sehr wichtig, Testfälle tabel ist, manuelle Tests im Notfall wegzu- ständig automatisierter UAT auch in der
Prinzip 1: „Respektiere die Sozial- und
nicht länger als notwendig fehlschlagen zu lassen lassen, sind sie scheinbar nicht wichtig. agilen Welt nicht seriös durchführbar – aus-
Machtstruktur der Organisa-
– auch wenn man die vermutliche Ursache kennt. Auch in der agilen Welt ist es der Zweck genommen automatisierte Smoke-Tests, die
tion.“
Ein fehlschlagender Testfall kann durchaus von Tests, Fehler in der Software zu finden. die Vollständigkeit der Funktionalität ober-
Prinzip 2: „Erkenne an, dass SOA letzt-
Probleme verdecken, die erst nach Behebung der Wenn automatisierte Tests dazu nur flächlich prüfen. Gelegentlich werden auto-
offensichtlichen Ursache zu Tage treten. Ziel des lich Veränderung auf vielen
bedingt in der Lage sind, gibt es lediglich matisierte GUI-Tests (Graphical-User-
Teams muss es sein, die Testfälle auch während Ebenen bedeutet.“
eine Alternative: manuelles beziehungs- Interface) als UAT bezeichnet. Diese Tests
der Entwicklung grün zu halten. Grün bezieht sich Prinzip 11: „Services und deren Ausgestal-
weise exploratives Testen, bei dem die sind funktionale Tests unter Einbeziehung
hier auf die Signalfarben, die traditionell in Build- tung sollten sich anhand der
Tester ihre Kreativität und Spontanität ein- einer Oberfläche und können zum Beispiel
Umgebungen eingesetzt werden. Art und Weise, wie sie wirklich
setzen, um Fehler zu finden. Ein wesent- im Regressionstest einen wertvollen Beitrag
genutzt werden, entwickeln.“
licher Nutzen manueller Tests – besonders leisten. Sie sind aber kein Ersatz für die
bei neuen Features – ist die kontextbezoge- Einbeziehung des Menschen als Tester.
Hier sind nur die Prinzipien des SOA-
ne Perspektive auf die zu prüfende
Manifests genannt, die bereits in ihrer For-
gehensweise, wenn die Erweiterung durch Funktionalität. Denn im Gegensatz zu
mulierung auf die komplexe Struktur von
Umpriorisierung doch nicht stattfindet und automatisierte Tests kennt der manuelle
Tipp 6: Zeitnaher
Organisationen eingehen. UAT. Doch bereits
die Tests weiterhin manuell durchgeführt Tester deren aktuellen Kontext. Während derlassen UAT in eine
der klassischen
diese Fragmente hohe Nähe
werden müssen. Wenn es Kunde und Budget zulassen, Projektwelt eine aufkommen,
abgeschlossene da Phase
zum EFQM-Modell neben
Aus unserer Erfahrung lohnt sich eine planen wir am Ende einer Iteration für alle darstellt, bietet es sich in agilen Projekten
Abb. 6: Prinzipien des SOA-Manifests (stark vereinfacht). dem mit SOA zu erbringenden Geschäfts-
sprechende, nachvollziehbare Zuordnung Entwickler einen Tag ein, dessen Fokus auf an, unmittelbar nach dem Abschluss einer
wert auch die Prozesse und die Organisa-
von Anforderungen (User-Storys) und manueller Testdurchführung liegt. Ziel die- Funktionalität Nutzer-Feedback einzuho-
tionsstruktur selbst angesprochen werden.
Akzeptanztests. Wird eine Anforderung ses Tages ist es, die Software zerbrechen zu len. Will der Entwickler in Folge des
Grundsätzlich lassen sich alle Prinzipien des
verändert oder erweitert, fließt der Auf- lassen. Gelingt es, den Code durch Benut- Feedbacks Änderungen vornehmen, ist
SOA-Manifests auf die Aspekte des EFQM-
wand für eine notwendige Anpassung zereingaben oder Datenkonstellationen zu seine Arbeit effektiver als nach einem
herstellung durch Henry Ford hatte daher diese Operationalisierung der der Industri- Modells beziehen. Um dies zu verdeutlichen,
bestehender Akzeptanztests mit in die zerbrechen, wird für die Situation, die dazu UAT-Feedback mehreren Wochen.
nicht nur Auswirkungen auf die Prozesse in alisierung impliziten Ganzheitlichkeit pro- haben wir in Tabelle 1 eine Zuordnung zwi-
Schätzung ein. Gibt es außerhalb des geführt hat, ein automatisierter Test
Form eines radikalen Taylorismus, sondern fitieren kann. schen den Prinzipien des SOA-Manifests und
Entwicklungsteams Interessenten für die geschrieben. Anschließend wird der Man-
– durch einen hohen Standardisierungsgrad den Aspekten des EFQM-Frameworks vor-
Akzeptanztest-Kriterien, erhalten diese gel nachvollziehbar behoben und mit dem Ein Fokus des UAT liegt auf der Instal-
bis hin zur Arbeitsmonotonie – auch auf die genommen. Abbildung 6 zeigt die Prinzipien
wertvolles Feedback zu den Auswirkungen automatisierten Test dafür gesorgt, dass die lierbarkeit der Software. Diese lässt sich
einzelnen Mitarbeiter und die Arbeitsergeb- SOA-Kontext des SOA-Manifests in vereinfachter Form.
der Änderung. Können Anforderungen und so gewonnene höhere Robustheit erhalten leicht in Kombination mit der oben
nisse (Ford: „Sie können jede Farbe haben, Es wurde immer wieder darauf hingewie- Die einfache Zuordnung in Tabelle 1 soll
Akzeptanztests einander nicht zugeordnet bleibt. beschriebenen automatisierten Prüfung auf
solange es schwarz ist“). sen, dass die Einführung einer SOA in ei- aufzeigen, wie naheliegend es ist, für die
werden, kommt das böse Erwachen bei der Vollständigkeit anwenden: Wenn dieser
Um diese Ganzheitlichkeit systematisch zu nem Unternehmen nur in den seltensten der Industrialisierung innewohnende For-
Entwicklung: Die Änderungen dauern fünf Plädoyer für Nicht- Smoke-Test erfolgreich war, ließ sich die
erreichen, können Unternehmensmodelle Fällen eine technische Herausforderung derung nach Ganzheitlichkeit dasselbe Mo-
Minuten, das Anpassen der fehlgeschlage- Automatisierung Software offenbar erfolgreich installieren.
verwendet werden, wie sie z. B. aus dem ist (vgl. [Lem13]). Das würde nämlich dell auch für eine SOA zu verwenden. Da
nen alten Akzeptanztests zwei Tage. Wenn die geforderte Funktionalität imple- Ziel des UAT ist es, die Benutzbarkeit einer
Bereich des Total-Quality-Management ebenfalls dem Paradigma-Gedanken (siehe die SOA selbst nur den servicerelevanten
mentiert wurde, also sämtliche automati- Software zu prüfen. Aus eigener Erfahrung
(TQM) gebräuchlich sind (vgl. [Mal11]). oben) widersprechen, der als grundsätzli- Teilausschnitt und insbesondere auch die
Manuelle Tests sierte Tests durchgeführt und um eventuell wissen wir, dass für einen erfolgreichen UAT
Ein gerade in Europa weit verbreitetes Mo- ches Denkmuster alles in einer Organisa- technische Umsetzung betrachtet, kann die
Manuelle Tests sind auch in agilen Pro- notwendige manuelle Tests der neuen in allen Teststufen gewissenhaft gearbeitet
dell ist das der EFQM. Auf der obersten tion in Betracht zieht. So ist es nur folge- ganzheitliche Industrialisierung als Ergeb-
jekten wichtig. Sie schließen die Lücke zwi- Features ergänzt wurden, schließt sich eine werden muss. Für Entwickler gibt nichts
Ebene kennt es die drei wesentlichen Säu- richtig, dass die SOA wie ein Paradigma nis eine SOA sein (wenn SOA ohne techni-
schen automatisierten Tests und aufwändig weitere manuelle Stufe an. Schlimmeres als einen UAT, der von den
len: ebenfalls alle relevanten Strukturen in ei- sche Umsetzung verstanden wird) oder als
oder gar nicht automatisiert prüfbaren Der User-Acceptance-Test (UAT) dient Testern oder vom Kunden nach wenigen
nem Unternehmen beleuchten muss. Diese ideale Vorarbeit (wenn SOA inklusive der
Anforderungen. Dabei können manuelle dazu, eine Software unter realen Bedingun- Minuten abgebrochen wird, weil viele offen-
n Organisationen sind deutlich komplexer als die Einteilung technischen Umsetzung verstanden wird)
Tests zeitaufwändig und fehleranfällig sein. gen zu testen und zu prüfen, ob eine sichtliche Fehler in den vorherigen Teststufen
n Prozesse in IT und Fachseite. Einige Hinweise für genutzt werden. Die sich daraus ergebende
Auch in der agilen Welt neigen Projekt- Software effizient und effektiv genutzt wer- nicht entdeckt wurden und der Software
n Ergebnisse diese Forderung nach Ganzheitlichkeit lie- Kernhypothese lautet:
teams dazu, manuelle Tests zu vernachläs- den kann. Software, die für Endanwender mangelnde Qualität bescheinigt wird.
sigen, wenn die Zeit am Ende einer gedacht ist, muss bei dieser Testart vom
Die Industrialisierung berührt allerdings
Benutzer selbst geprüft werden. Dazu ist es Last und Performance-Tests
nicht nur diese Hauptsäulen, sondern auch
notwendig, den fachlichen Kontext der zu Die Teststufe Last- und Performance-Tests
Tipp 5:
die sechs Pair-Testing
weiteren Kontexteim UAT. (siehe Abbil-
prüfenden Software zu kennen und einzu- dient im Wesentlichen dazu, drei nicht-
dung User-Acceptance-Tests
1). Der Punkt „Politik sollten
unddabei nie
Strategie“
umfasstdurch diebeispielsweise
hier Softwareentwickler durchge- As-
so wichtige
pekte führt
wiewerden. UAT mittels Pair-Testing
Arbeitsschutz, Betriebsrat hat und
sich dagegen
Datenschutz. Einebewährt. Hier führt ein die
Industrialisierung, OBJEKTspektrum ist eine Fachpublikation des Verlags:
Benutzer ignoriert,
diese Punkte den UAT durch,
hat der
guteEntwickler
Chancen zu SIGS DATACOM GmbH · Lindlaustraße 2c · 53842 Troisdorf
sitzt daneben und bekommt direkt wert-
scheitern. Tel.: 0 22 41 / 23 41-100 · Fax: 0 22 41 / 23 41-199
volles Feedback zurliefert
Das EFQM-Modell Benutzbarkeit
damitseiner
eine gute E-mail: info@sigs-datacom.de
Arbeit. Im Idealfall ist dieser Tester der
Kontextliste, die bei einer Industrialisie- www.objektspektrum.de
Kunde selbst oder ein Mitarbeiter mit tie-
rung berücksichtigt werden muss. Im Fol- www.sigs.de/publications/aboservice.htm
fem fachlichen Wissen, aber keinen weite-
genden wird aufgezeigt, wie die SOA durch
ren Kenntnissen über den Quellcode.
403/2015
/ 2 01 3 23
SOA: Industrialisierung durch und durch
Prinzipien
des
SOA-‐Manifests
Aspekte
des
EFQM-‐Frameworks
schneidende oder zueinander inkompatible
Daten anboten.
Respektiere
die
Sozial-‐
und
Machtstruktur
der
Mitarbeiter,
mitarbeiterbezogene
Wenn ein Unternehmen zwei Systeme be-
Organisation.
Ergebnisse,
Politik
und
Strategie,
Partnerschaft
und
Ressourcen.
sitzt, die Master von Kunden- und Per-
sonendaten sind, und beide Systeme diese
Erkenne
an,
dass
SOA
letztlich
Veränderung
auf
vielen
Führung,
Politik
und
Strategie,
Daten über Services anbieten, sind diese
Ebenen
bedeutet.
Mitarbeiter,
Prozesse,
alle
Dienste für potenzielle Service-Nutzer ohne
Ergebnisaspekte.
klare Regelungen schwer einsetzbar. Es
Der
Bereich,
in
dem
SOA
eingeführt
wird,
kann
muss geklärt sein, welches System die ak-
Politik
und
Strategie,
Partnerschaft
und
unterschiedlich
ausfallen.
Halte
die
Aufwände
in
einem
Ressourcen,
alle
Ergebnisaspekte.
tuellen Daten hält und in welchem System
überschaubaren
und
sinnvollen
Rahmen.
Änderungen an Kundendaten durchgeführt
Produkte
und
Standards
allein
werden
weder
SOA
liefern,
Politik
und
Strategie,
Prozesse,
alle
werden müssen. Es gibt eine Reihe weiterer
noch
das
serviceorientierte
Paradigma
umsetzen.
Ergebnisaspekte.
typischer Beispiele für die fehlende Har-
SOA
kann
mit
unterschiedlichen
Technologien
und
Politik
und
Strategie,
Partnerschaft
und
monisierung, beispielsweise Adressdaten,
Standards
umgesetzt
werden.
Ressourcen
Kontoverbindungen, Kommunikationsver-
Etabliere
einheitliche
Unternehmensstandards
und
bindungen, Termine und Dokumente.
-‐richtlinien
auf
der
Basis
von
Industrie-‐
und
De-‐facto-‐ Führung,
Politik
und
Strategie,
Prozesse.
Organisationen, die trotz Überschneidun-
Standards
sowie
Standards
der
SOA-‐Gemeinde.
gen von Informationsobjekten in verschie-
denen Systemen eine SOA einführen, haben
Strebe
nach
außen
Einheitlichkeit
an,
aber
lasse
nach
Führung,
Politik
und
Strategie,
Prozesse,
innen
Vielfalt
zu.
Mitarbeiter.
in der Regel noch mehrere Jahre damit zu
kämpfen, diese Harmonisierung nachzuzie-
Identifiziere
Services
durch
Zusammenarbeit
zwischen
hen. Der Aufwand für die Reduzierung von
fachlichen
und
technischen
Interessenvertretern.
Redundanzen kann dabei durchaus um den
Maximiere
die
Anwendbarkeit
von
Services
durch
Führung,
Politik
und
Strategie,
Faktor zwei oder drei höher sein als bei einer
Berücksichtigung
der
derzeitigen
und
zukünftigen
Partnerschaft
und
Ressourcen,
Harmonisierung der Daten von Anfang an.
Anwendungsgebiete.
Prozesse,
Mitarbeiter,
alle
Ergebnisse.
Entlang des EFQM sind die Schwachstellen
Stelle
sicher,
dass
Services
fachlichen
Anforderungen
und
offenkundig, da es um mitarbeiterbezoge-
Zielen
dienen.
ne (z. B. interne Arbeitsergebnisse wie Be-
Services
und
deren
Ausgestaltung
sollten
sich
anhand
der
Führung,
Politik
und
Strategie,
arbeitungsvermerke) und kundenbezogene
Art
und
Weise,
wie
sie
wirklich
genutzt
werden,
Partnerschaft
und
Ressourcen,
Ergebnisse (z. B. Adressdaten) geht: Eine
entwickeln.
Prozesse,
alle
Ergebnisse.
saubere Modularisierung hat klare Verant-
Trenne
die
verschiedenen
Aspekte
eines
Systems,
die
sich
wortungsbereiche zur Folge. Überschnei-
unterschiedlich
häufig
ändern.
dungen gibt es nicht mehr, sondern die Ab-
grenzung wird durch Schnittstellen explizit.
Reduziere
implizite
Abhängigkeiten
und
publiziere
alle
externen
Abhängigkeiten,
um
Robustheit
zu
fördern
und
Politik
und
Strategie,
Partnerschaft
und
Die folgende Standardisierung ermöglicht
die
Auswirkungen
von
Veränderungen
zu
reduzieren.
Ressourcen,
Prozesse,
alle
Ergebnisse.
dann eine einheitliche Nomenklatur einer
SOA-Kommunikation zwischen allen betei-
Organisiere
jeden
Service
auf
jeder
Abstraktionsebene
in
oder
anhand
einer
zusammenhängenden
und
ligten Kommunikationspartnern.
überschaubaren
Funktionseinheit.
Stabile Architektur, die SOA unterstützt
Eine Organisation muss über eine stabile
Tabelle 1: Assoziation zwischen SOA-Manifest und EFQM-Modell. IT-Architektur verfügen, die SOA unter-
stützen kann. Es reicht nach unserer Erfah-
rung nicht aus, dass jede Anwendung so
Jeder fehlende Industriali- geeignet ist, die Fehler bei der Etablie- erweitert wird, dass die Nutzung oder das
sierungsschritt in einem der rung von SOA zu analysieren, um darauf Angebot von SOA-Services grundsätzlich
aufbauend Gegenmaßnahmen abzuleiten. möglich ist. Dass Services genutzt werden
von EFQM aufgezeigten
Konstruktiv formuliert bedeutet dies: Wenn können, bedeutet noch nicht, dass sie leicht
Dimensionen muss zwangs-
einer SOA-Einführung eine ganzheitliche benutzbar sind, mit ausreichender Perfor-
läufig zum Scheitern einer SOA-
Industrialisierung vorangestellt wird, sind mance angebunden werden können oder
Initiative führen, ebenso wie das viele Risiken ausgeschaltet. dass die zu Grunde liegende IT-Architektur
vollständige Vergessen eines EFQM- gar stabil genug ist.
Aspektes bezüglich der Industriali- Fehlende Harmonisierung der Daten Betrachten wir einmal das folgende Beispiel:
sierung. Einer der häufigsten Gründe, warum SOA Wie leicht kann es einer Organisation fal-
in der Vergangenheit gescheitert ist, war len, eine SOA einzuführen, die in ihrer IT-
Als Beleg dieser Hypothese werden im Fol- die fehlende Harmonisierung der Informa- Landschaft folgende Komponenten vereint?
genden einige typische Stolpersteine der tionsobjekte bzw. die Harmonisierung der
Einführung von SOA erläutert und inner- Daten des Unternehmens. Dabei wurden n Ereignisgesteuerte Architektur
halb dieses Modells verortet. Es wird sich von unterschiedlichen Quellen Services n Messaging-Systeme
zeigen, wie gut dieses Modell tatsächlich entwickelt und bereitgestellt, die sich über- n Client-Server-Anwendungen
24
www.objektspektrum.de
n Application-Server-Cluster Fall der Prozess einer anderen Abteilung stützen. Die Reihenfolge ist also ein wichti-
n Multi-Layer-Systeme verwendet werden kann. Warum, weiß nie- ger Erfolgsfaktor.
n Host-Systeme mand mehr so genau.
n Kakophone Insellösungen mit Kompo- Auch hier sind die fehlenden Vorbedin- SOA-Testen in der Praxis
nentenframeworks, proprietären Spra- gungen der Industrialisierung für die im Komplexe Services einer SOA lassen sich
chen und Kommunikationsstilen wie EFQM-Modell aufgeführten Entitäten – häufig schwer testen und die Aussagekraft
CORBA, .NET, VBA, JEE und RPC und hier natürlich allen voran der explizite von Testergebnissen ist stark eingeschränkt.
Bereich der Prozesse – offenkundig. Neben einigen praktischen Gründen liegt
Das wird nur mit großer Mühe und unter Interessanterweise wird die Einführung die Ursache dafür häufig in der Konzepti-
Tränen gelingen. einer SOA heute immer noch gern als Ve- on und dem Entwurf der Services und der
Mit Bezug auf EFQM sind auch hier die hikel verwendet, um die Harmonisierung Tests selbst.
Probleme offensichtlich, da die wichtige von Prozessen voranzutreiben. Ein Busi-
Dimension „Partnerschaft und Ressour- ness-Prozess wird mit Hilfe von auf dem n SOA-Tests werden üblicherweise syn-
cen“ explizit angesprochen wird. Die oben Reißbrett entworfenen Services umgesetzt. chron durchgeführt. In der Realität ist
aufgeführten Problembereiche zeigen deut- Dann wird erwartet, dass die von diesem eine SOA asynchron ausgelegt. Als Fol-
liches Potenzial für Standardisierung. Selbst Prozess betroffenen Abteilungen die ent- ge sind Laufzeitverhalten, Ergebnisse
wenn die Modularisierung noch erfolgreich sprechenden Services verwenden. Die Er- oder Antwortzeiten aus den Tests nur
durchgeführt wurde, so weist die Verschie- folgswahrscheinlichkeit dieses Ansatzes bedingt mit der Realität vergleichbar.
denartigkeit der Systeme und Technologien ist unserer Erfahrung nach eher gering, n Durch klassische, funktionale Tests
(alias Ressourcen, eventuell auch von Part- sodass er nicht empfohlen werden kann. kann nur schwer ermittelt werden, ob
nern) auf den unvollständigen Standardisie- Die SOA-Umsetzung sollte nach der Indus- nicht-funktionale Anforderungen – wie
rungsschritt, was dann hin zu signifikanten trialisierung erfolgen, sie sollte diese nicht kurze Antwortzeiten oder Durchsatz
Mehrkosten bei der SOA-Einführung führt, antreiben. im Echtbetrieb – tatsächlich geleistet
ohne dass die SOA-Umsetzung selbst dafür Das „Gesetz von Conway“ (vgl. [Con]) werden können. Eine Ursache dafür ist,
schuldig gemacht werden kann. beschreibt, dass sich die Kommunikati- dass das tatsächliche Nutzungsverhal-
Auch wenn eine SOA sicherlich technisch onsbeziehungen innerhalb einer Organisa- ten im Test nur ansatzweise simuliert
heterogene Systeme bis zu einem bestimm- tion (vgl. Entität „Führung“ im EFQM in werden kann. Werden mit der SOA vie-
ten Grad integrieren kann, so sollte der Abbildung 1) in der Architektur ihrer IT- le kleinteilige, miteinander kombinier-
Grundtypus der IT sehr wohl bereits stan- Landschaft widerspiegeln. Werden diese bare Services betrieben, fällt die Vor-
dardisiert sein. Aber auch auf der nächsten Kommunikationsbeziehungen – die unter hersagbarkeit des Nutzungsverhaltens
Ebene – der Technologieplattform (z. B. anderem durch Prozesse und Organisatio- noch schwerer.
.NET vs. JEE) – ist eine unternehmensweite nen beschrieben werden – vor der Einfüh- n Die Anzahl der an der SOA beteilig-
Standardisierung sehr hilfreich bei der Eta- rung einer SOA nicht harmonisiert, werden ten IT-Systeme und ihre Netztopologie
blierung einer SOA. diese in der Architektur zementiert und be- spielen ebenso eine Rolle wie die An-
hindern die Flexibilität von Prozessen und zahl und die Nutzungshäufigkeit der
Harmonisierung von Prozessen Organisation eher, als dass sie diese unter- einzelnen Service-Operationen bezogen
und Organisationen
Ähnlich wie die Daten müssen auch Prozes-
se harmonisiert werden, die mit der SOA
verbessert werden sollen. Prozesse dienen
in der Regel dazu, eine Abteilung bei der
Durchführung ihrer Aufgaben zu unter- Literatur & Links
stützen – also müssen genau genommen
Aufbau und Aufgaben der betroffenen Or- [Ada01] L. Adams, Egoless programming: The path to better code“, TechRepublic, März 2001,
ganisation harmonisiert werden. Geschieht siehe:
das nicht, wird eine SOA keine Vorteile http://www.techrepublic.com/article/egoless-programming-the-path-to-better-code/
bringen. [Ars09] Ali Arsanjani et al., SOA-Manifest, 2009, siehe: http://soa-manifest.de/
In großen Organisationen mit vielen Ab- [BIT] BITKOM, Plattform Industrie 4.0, siehe: http://www.plattform-i40.de/
teilungen werden gleiche Aufgaben gern [Bre13] W. Brenner et al., Die Zukunft der IT in Unternehmen, in: F. Abolhassan (Hrsg.), Der
auf völlig unterschiedliche Art und Weise Weg zur modernen IT-Fabrik: Industrialisierung – Automatisierung – Optimierung, Springer
bedient. Wo die eine Abteilung für eine be- Gabler Verlag, 2013
stimmte Aufgabe einen medienbruchfreien, [Cloe14] T. Cloer, Leitender, Dropbox bringt for-business-API, in: Computerwoche 2.12.2014
elektronischen Prozess lebt, verwendet eine [Con] M. Conway, Conway’s Law, siehe: http://www.melconway.com/Home/Conways_Law.html
andere Abteilung einen ähnlichen Prozess [Kal14] F. Kalenda, Amazon führt API für Cloud Drive ein, in: ZDNet 12.11.2014
mit vielen manuellen Schritten und in einer [Lem13] P. Lemberger, M. Morel, Managing Complexity of Information Systems, Wiley Online
dritten Abteilung gibt es gar keinen defi- Library, Januar 2013 (dort „Why has SOA failed so often“, Appendix 3), siehe auch:
nierten Prozess. Hier wird bei jeder Durch- http://onlinelibrary.wiley.com
führung des Prozesses ad hoc entschieden, [Mal11] C. Malorny, T. Hummel, Total Quality Management: Tipps für die Einführung, Hanser-
wie zu verfahren ist. Es besteht Konsens Verlag (4. Aufl.), 2011
in den drei Abteilungen, dass auf keinen
03/2015 25
SOA: Industrialisierung durch und durch
auf die beteiligten Komponenten. Die größten IT-Wachstumsfelder verwendete EFQM-Modell hilft, diese Vielschichtigkeit
Verfügbarkeit dieser Systeme ist unter Begriff der „Industrie 4.0“ zeigt die Annah- und Interdependenzen zu verstehen.
Umständen Schwankungen unterwor- me, dass die oben formulierten Industriali- Für eine so aufgesetzte SOA muss die In-
fen, innerhalb derer die SOA weiterhin sierungsschritte für die IT schon umgesetzt dustrialisierung demnach ganzheitlich auf
funktionieren muss. Dieses Verhalten sind, um dann neue Bereiche – hier eben alle relevanten Aspekte einer Organisation
im Test zu simulieren, ist erfahrungsge- insbesondere Cyber-Physical-Systems in einwirken. Dies sind entlang des EFQM-
mäß sehr aufwändig. Form von Smart Factories (vgl. z. B.[BIT]) Modells wenigstens die Organisation, die
n Die Qualität des Serviceschnitts der – zu befruchten. Prozesse und alle Ergebnisse.
beteiligten Services zeigt sich häufig Ob das Ziel einer solchen Industrialisierung Wenn diese Industrialisierung ganzheitlich
erst in der Praxis. Benutzer verwenden nun SOA heißt oder Industrie 4.0, ist belang- und zielorientiert für alle diese Dimensi-
Services nicht nur, wenn sie es müssen, los – das hinter einer SOA stehende Konzept onen solide durchgeführt wird, kann eine
sondern auch, wenn sie es können. Eine muss nicht revitalisiert werden: Es war im- SOA erfolgreich werden. Die Industrialisie-
Service-Operation, die viele Daten lie- mer und wird immer relevant bleiben. rung ist demnach eine hinreichende Vorbe-
fert, wird unter Umständen hundertmal Die Schwierigkeit der Umsetzung von SOA dingung für eine SOA. Erfolgt dies nicht,
häufiger verwendet, als bei der Kon- ist dabei ihre Interdisziplinarität: Es ist kei- ist der Misserfolg häufig vorprogrammiert,
zeption erwartet. Das System, das die- ne rein technische Herausforderung, die auf kann aber keineswegs der SOA-Umsetzung
sen Service anbietet, wird schnell zum die IT beschränkt ist – die Umsetzung ist zugesprochen werden, sondern der unvoll-
Engpass. Auch dies kann nur schwer im vielmehr ein die gesamte Organisation ver- ständigen Berücksichtigung von SOA als
Test herausgefunden werden. änderndes Paradigma. Das der Anwendung „grundlegende, serviceorientierte Denkwei-
im Kontext der Industrialisierung entlehnte se“ in einem Unternehmen. ||
Die beschriebenen Probleme adressieren
Bereiche, die erst durch das Industrialisie-
rungskonzept, das dann für die IT mittels
einer SOA realisiert wird, entstehen. Dies
fällt nicht direkt bei der Modularisierung
auf, da diese ja noch primär die Geschäfts-
prozesse adressiert. Aber im Zuge der Stan- Die Autoren
dardisierung und Etablierung einer zentra-
len SOA über die folgende Automatisierung
taucht ein neues Arbeitspaket für dieses
neue IT-Artefakt auf: das Testen. Dieses
muss dann ebenso modularisiert und stan-
dardisiert werden. Entlang des EFQM wird
dann nämlich deutlich, dass dieser neue Ar-
tefakt ebenfalls einer Führung bedarf, dass
dort auch wohl-definierte Prozesse (z. B.
für das Deployment und das Staging) not-
wendig sind und dass auch dort bestimm- || Ramon Anger || Dr. Frank Simon
te Schlüsselergebnisse (z. B. die Einhaltung (ramon.anger@capgemini.com) (frank.simon@bluecarat.de)
arbeitet als Managing Solution Architect im leitet bei der BLUECARAT AG den Bereich
von Service Level Agreements (SLAs)) ab-
Bereich Service Industries bei Capgemini. Er Business Development und entwickelt neue
lesbar sein sollten.
beschäftigt sich insbesondere mit neuen Techno- Technologie und Beratungsansätze. Im BITKOM
logien, Softwarearchitektur und agilen Methoden. leitet er den Lenkungsausschuss Software und
Fazit Außerdem arbeitet er aktiv im BITKOM-Arbeits- ist Leiter der Arbeitskreise Software-Engineering
Die Industrialisierung der IT ist heute ein kreis Software-Architekturen mit und promoviert und Software-Architekturen. Außerdem ist er im
berufsbegleitend an der TU Ilmenau. Vorstand des German Testing-Boards.
unumkehrbarer Trend. Der für eines der
26
Sie können auch lesen
