schwerpunkt: moderne programmierpraktiken - SIGS DATACOM

Mit Sonderbeilage
Quality Management
Januar / Februar 2012 • Nr. 1
€ 8,90 Österreich 9,90 Schweiz sfr 16,50
www.OBJEKTspektrum.de
SCHWERPUNKT MODERNE PROGRAMMIERPRAKTIKEN
Die Zeitschrift für Software-Engineering und -Management
SCHWERPUNKT:
MODERNE PROGRAMMIERPRAKTIKEN
DI und AOP: Eine Bilanz
Steve, Gregg und
Duke im Gespräch
SPECIAL
Mit Diana Larsen,
Johanna Rothman und
Matthias Bohlen
Flow in Lean –
Flow im Team
FACHTHEMEN
G 6540F
Sicherer Smartphone-
Einsatz
Betrieb von SOAbasierten
Lösungen

editorial – ordnung im chaos
„Compilerbau ist die am besten durchdrungene
Disziplin in der ansonsten
chefredakteur
doch noch recht unreifen Informatik!“
So oder so ähnlich hat sich mein
Doktorvater Prof. Nagl gern ausgedrückt,
um seine Freude über diese gereifte
Mischung aus Theoretischer Informatik,
Programmiersprachen konzep ten und
Best Practices in der technischen
Umsetzung auszudrücken. Und daran
muss te ich während der Entstehung dieser Ausgabe von
OBJEKTspektrum immer wieder denken.
Wenn wir hier und heute über moderne Program -
mierpraktiken sprechen, dann sind wir in genau dieser guten
Tradition des Compilerbaus, nur 25 Jahre nach dem oben
genannten Zitat meines Lehrers. Heute wird nicht mehr über
die Vor- und Nachteile modularer Programmier sprachen -
konzepte diskutiert und auch die Welle objektorientierter
Sprachen wie C++ und Smalltalk ist über uns hinweg
geschwappt. Und wenn auch in der heutigen kommerziellen
Anwendungsentwicklungswelt eher über Ruby, Java und
ObjectiveC diskutiert wird, wie in dem unterhaltsamen
Artikel von Holger Bohlmann, Manuel Küblböck und
Henning Spille, so hat doch jede dieser vergangenen Wellen
deutliche Spuren bei den modernen Praktiken hinterlassen.
Erich Gamma war beispielsweise mit seinen Design Patterns
auch der Pate für deren kleine Brüder, die Idiome, die André
Janus und Jens Jäger ebenso beschreiben wie die schmutzigen
kleinen Brüder der Anti-Pattern, die Code Smells.
Der wesentliche Sinn vieler modernen Praktiken liegt wie der
vieler Konzepte aus der Vergangenheit in der losen Kopplung
von Komponenten und der sauberer Kapselungen. Aber es
geht eben auch um mehr als eine logische Strukturierung: Es
geht um immer mehr Flexibilität in der Konstruktion von
Software, selbst bei sehr komplexen Anwendungsstrukturen.
Und Flexibilität bedeutet eben auch, dass man sich von einer
zentralen Steuerung endgültig verabschiedet und Kontrolle
zunehmend dezentralisiert, wie Eberhard Wolff in seiner
Bilanz über die Dependency Injection und aspektorientierte
Programmierung herleitet.
Und damit bilden die Praktiken ein praktisches Hilfsmittel für
eine konkrete Umsetzung flexibler Services in einer sauberen
Architektur im Sinne der SOA-Evangelisten früherer Jahre.
Auch Veit Köppen und Liane Will beschreiben übrigens in
ihrem Artikel über die praktische Umsetzung beim professionellen
ITIL-basierten Betrieb von SOA-Anwendungen eine
besondere Herausforderung beim Einsatz von SOA.
Komme ich aber zurück auf die „neue Flexibilität“ unserer
Programmierpraktiken. Sie bildet auch die Basis moderner flexibler
Management-Disziplinen. Marko Schulz und Andreas
Havenstein betonen daher in ihrem Artikel über den Certified
Scrum Developer: „Scrum erfordert flexible Strukturen, damit
das Team jederzeit auf geänderte Anforderungen reagieren
kann, die der Product Owner (PO) einbringt. Ein CSD muss
Entwurfsprinzipien kennen und anwenden können, die zu entkoppelten
Strukturen führen.“ Aber auch der CSD ist mit dem
Drang nach Flexibilität immer in der Gefahr, eine saubere
Architektur zu vernachlässigen.
Damit haben wir auch schon den Bogen gespannt von den
Programmierpraktiken zu den Programmierern und den anderen
Menschen im Entwicklungsprozess, die allen meinen
Gesprächs partner im OOP-Special dieses Heftes so sehr am
Herzen liegen. Matthias Bohlen zieht die Parallelen zwischen
dem „Flow im Lean“ und dem „Flow im Team“, Johanna
Rothman gibt Tipps, um die richtigen Leute einzustellen und
wie man mit Hilfe dieser Menschen seine Arbeit erledigt
bekommt. Diana Larsen umschreibt die Softwareentwicklung
als einen komplexen Tanz von dem Ganzen (dem organisatorischen
System) und seinen Teilen (den betroffenen
Menschen).
Ich finde es wirklich auffällig, dass so viele Technik-Freaks
irgendwann den Weg hin zur Arbeitsorganisation finden, die
einen über Kanban, die anderen über systemische
Betrachtungen von Teams. Oft hatte ich ja den Verdacht, dass
der Grund darin zu suchen ist, dass man mit zunehmendem
Alter nicht mehr der doch sehr schnellen technischen
Entwicklung standhält (Autoren und Leser des
OBJEKTspektrums sind hier natürlich ausgenommen. ☺) Aber
in diesem Heft ist mir der Zusammenhang zwischen diesen
scheinbar weichen Themen und den eher technischen Themen
wieder so richtig bewusst geworden: Wir bauen immer komplexere
Systeme und merken, dass eine zentrale Kontrolle dieser
Komplexität nicht mehr Herr wird. Sowohl die
Programmierpraktiken als auch die Managementpraktiken
versuchen, Ordnung im Chaos zu halten, indem sie Kontrolle
dezentralisieren. Oder wie Diana Larsen sagt: „Es ist eigentlich
paradox, dass wir erst dadurch mehr Kontrolle über komplexe
Ergebnisse bekommen, dass wir auf Kontrolle über die
Teile verzichten.”
Ihr Thorsten Janning
Meet the Editor @ OOP 2012
am SIGS DATACOM-Stand
Di, 24.01.2012 15.45–16.15 Uhr
Mi, 25.01.2012 10.30–11.00 Uhr
1/2012

CHWERPUNKT: MODERNE PROGRAMMIERPRAKTIKEN
SCHWERPUNKT:
MODERNE PROGRAMMIERPRAKTIKEN
Holger Bohlmann
Manuel Küblböck
Henning Spille
EIN KAFFEE NACH DEM MITTAG:
AUS DEM ALLTAG VON
DREI ENTWICKLERN · · · · · · · · · · · · · · · · · · · 10
Moderne Programmierpraktiken haben sich mit Java schon vor
Jahren verbreitet. Mittlerweile arbeiten viele Java-Entwickler mit
aktuellen Plattformen, wie z. B. der App-Entwicklung fürs iPhone.
Die Autoren zeigen in einem kleinen Spiel auf, wie sich moderne
Programmier praktiken in verschiedenen Plattformen gemausert
haben. Hierzu treffen sich der Apple-iOS-Entwickler Steve, der
Rubyist Gregg und Duke, der in Java entwickelt, auf einen Kaffee
in der Mittagspause und berichten von ihren Erfahrungen.
EDITORIAL · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 3
AKTUELLES · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 6
PRODUKTNEUHEITEN · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 8
LESERBRIEF · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 9
BUCHBESPRECHUNG: YVES STALGIES REZENSIERT:
THE LEAN STARTUP · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 40
BUCHBESPRECHUNG: MICHAEL STAL REZENSIERT:
BASISWISSEN SOFTWAREARCHITEKTUR · · · · · · · · · · 74
STELLENMARKT · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 46
IMPRESSUM · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 57
SEMINARE & VERANSTALTUNGEN · · · · · · · · · · · · · · · 77
THEMENVORSCHAU & INSERENTENVERZEICHNIS · · 79
schwerpunkt
Holger Bohlmann
Manuel Küblböck
Henning Spille
EIN KAFFEE NACH DEM MITTAG:
AUS DEM ALLTAG VON DREI ENTWICKLERN · · · · · · 10
Der IDE-Glaubenskrieg visualisiert.
André Janus
Jens Jäger
CODE-FLAVOURS:
NÜTZLICHE JAVA-IDIOME · · · · · · · · · · · · · · 20
Während Anti-Pattern das negative Gegenstück zu den bekannten
Design-Pattern bzw. Entwurfsmustern sind, gibt es auf niedriger
Abstraktionsebene die Code-Smells als Gegensatz zu den
weniger bekannten Idiomen. Die Autoren stellen in diesem
Artikel einige alt bekannte und auch neue Java-Idiome vor.
Andreas Havenstein
Marko Schulz
CERTIFIED SCRUM DEVELOPER:
DER GANZHEITLICHE ENTWICKLER · · · · · · · · · · · · · · · 16
André Janus
Jens Jäger
CODE-FLAVOURS:
NÜTZLICHE JAVA-IDIOME · · · · · · · · · · · · · · · · · · · · · · · · 20
Eberhard Wolff
DI UND AOP:
EINE BILANZ · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 24
4 5 www.objektspektrum.de

Das OBJEKTspektrum-Team
wünscht Ihnen
frohe Weihnachten und
einen guten Rutsch ins neue Jahr.
ausblick auf die OOP 2012
Johanna Rothman
SECHS VERHALTENSWEISEN …
… DIE MITARBEITER EINES
AGILEN TEAMS BESITZEN SOLLTEN · · · · · · · · · · · · · · 27
Matthias Bohlen
FLOW IN LEAN, FLOW IM TEAM:
WAS LEAN MIT DEM PERSÖNLICHEN
ERLEBEN ZU TUN HAT · · · · · · · · · · · · · · · · · · · · · · · · · · · · 30
Diana Larsen
WAS UNS ZU ERFOLGREICHEN PROJEKTEN FÜHRT …
… UND MANCHMAL AUCH DAVON ABHÄLT · · · · · · 38
Matthias Bohlen
FLOW IN LEAN, FLOW IM TEAM:
WAS LEAN MIT DEM PERSÖNLICHEN
ERLEBEN ZU TUN HAT · · · · · · · · · · · · · · · · · · 30
Flow herrscht in der Arbeit, wenn Bedarf und Lieferfähigkeit
gegeneinander ausbalanciert sind, z. B. durch den Einsatz
von Lean-Verfahren in der Produktentwicklung. Flow gibt es
auch in der Psyche, wenn vom Einzelnen soviel gefordert
wird, wie er auch leisten kann. Im Flow-Zustand entstehen
die besten Ergebnisse, die Arbeit ist angenehm, man vergisst
die Zeit. Dass man für Flow im Sinne von „Lean
Product Development” dasselbe Wort verwendet wie in der
Psycholo gie, ist kein Zufall. In dem Artikel geht es darum, die
Beziehung zwischen Flow in Lean und Flow in der Psyche
herzustellen und zu erforschen.
fachartikel
Veit Köppen
Liane Will
LIVING SOA:
EVOLUTION DES BETRIEBS VON
SOA-BASIERTEN LÖSUNGEN · · · · · · · · · · · · · · · · · · · · · 42
Albert Zündorf
GEH MIR AUS DEM WEG!
WAS MODELLIERUNGSWERKZEUGE VON
WHITE-BOARDS LERNEN KÖNNEN · · · · · · · · · · · · · · · 52
Eldar Sultanow
MIGRATIONSMANAGEMENT:
FALLSTUDIE ZUR MIGRATION EINER
INDUSTRIELLEN RICH-CLIENT-ANWENDUNG · · · · · · 58
Albert Zündorf
GEH MIR AUS DEM WEG!
WAS MODELLIERUNGSWERKZEUGE VON
WHITE-BOARDS LERNEN KÖNNEN · · · · · · 52
Viele grafische Editoren unterbrechen den Benutzer bei seiner
Arbeit. Insbesondere UML-Modellierungswerkzeuge
stören den Arbeitsfluss des Entwicklers mit Pop-Ups und
der Notwendigkeit, in Werkzeugleisten herumzusuchen.
Gleichwohl werden Softwarearchitekten nicht in
Mausmetern bezahlt. Um die Bedienbarkeit von grafischen
Benutzungsoberflächen zu verbessern, muss man die
Menschen dabei beobachten, wie sie arbeiten. Die daraus
resultierenden Erkenntnisse können den Arbeitsablauf
erheblich beschleunigen.
Bernd Körner
ABGRENZUNG ALS METHODE DER
ANFORDERUNGSANALYSE:
TEIL 2: ABGRENZUNGEN HERAUSARBEITEN · · · · · · · 66
Isabel Münch
TECHNIK PLUS SENSIBILITÄT:
SICHERER SMARTPHONE-EINSATZ
IN UNTERNEHMEN · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 75
Klassendiagramm am Whiteboard.
1/2012 www.sigs-datacom.de

schwerpunkt
mehr zum thema:
http://www.it-agile.de/agile-entwicklung.html
die autoren
EIN KAFFEE NACH DEM MITTAG:
AUS DEM ALLTAG VON DREI
ENTWICKLERN
Moderne Programmierpraktiken haben sich mit Java schon vor Jahren verbreitet. Mittlerweile
arbeiten viele Java-Entwickler mit aktuellen Plattformen, wie z. B. der App-Entwicklung fürs
iPhone. Wir möchten in einem kleinen Spiel aufzeigen, wie sich moderne Programmier -
praktiken in verschiedenen Plattformen gemausert haben. Hierzu treffen sich der Apple-iOS-
Entwickler Steve, der Rubyist Gregg und Duke, der in Java entwickelt, auf einen Kaffee in der
Mittagspause und berichten von ihren Erfahrungen.
Holger Bohlmann
(E-Mail: holger.bohlmann@it-agile.de)
arbeitet seit fast 10 Jahren als Softwareentwickler
in verschiedenen Projekten. Ursprünglich im
Java/J2EE-Bereich, dann auch mit Ruby on Rails
und seit kurzem auch in der iPhone-Entwicklung.
Thema: Entwicklungsumgebungen
(IDE)
Duke: In der Java-Welt gibt es eine Vielzahl
ziemlich guter IDEs. Die Frage, welche
davon die beste ist, artet schon mal gerne in
einen Glaubenskrieg aus (Duke zeichnet
dabei Abbildung 1). Dabei bekämpfen sich
gleich mehrere große Lager aus Eclipse-,
IntelliJ IDEA-, NetBeans- und JDeveloper-
An hä ngern. Es ist eine Schlacht auf sehr
hohem Niveau, die auch insgesamt die
Reife und Vielfalt an Java-Tools widerspiegelt.
Alle genannten IDEs bieten automatische
Refaktorisierungen, Syntax prüfung
und gute Debugging-Unterstüt zung. Ich
persönlich benutze am liebsten Eclipse
wegen der schier unendlichen Anzahl an
Plug-Ins. Egal, was man machen möchte,
mit sehr hoher Wahrscheinlichkeit gibt es
schon ein Eclipse-Plug-In dafür.
Gregg: Die IDE-Glaubenskriege sind
schon legendär. Insgesamt sind aber mittlerweile
alle Entwicklungsumgebungen im
Java-Bereich so gut, dass sie für den
Entwickler eine echte Hilfe in der täglichen
Arbeit darstellen. Vor zehn Jahren habe ich
noch Java-Code mit einem Texteditor
namens Ultra-Edit geschrieben. Wenn ich
jetzt auf Ruby schaue, könnte ich etwas
bösartig sagen, ich bin wieder bei Ultra-
Edit angekommen. Okay, ich habe auch
viel mit Textmate und Rubymine von
JetBrains gemacht. Letztere haben ja auch
schon IntelliJ IDEA gebaut. Textmate sieht
erst einmal wie ein einfacher Editor aus,
hat aber dazu eine riesige Sammlung von
so genannten Bundles, die einen, wenn man
sie denn kennt, auch effektiv unterstützen.
Was ich ein wenig vermisse, sind die
Refaktorisierungsmöglichkeiten aus
Manuel Küblböck
(E-Mail: manuel.kueblboeck@it-agile.de)
interessiert sich für alles, was das Entwickeln von
qualitativ hochwertiger Software einfacher und
effektiver macht. Aktuell befasst er sich mit objektfunktionalen
Sprachen und Continuous Delivery.
Henning Spille
(E-Mail: henning.spille@it-agile.de)
arbeitet seit einigen Jahren bei der it-agile GmbH.
Ursprünglich entwickelte er mit Java und schreibt
heute native iPhone-Anwendungen.
Abb. 1: Der IDE-Glaubenskrieg visualisiert.
Ec lipse. Hier ist man leider noch viel auf
Textersetzung angewiesen, eine automatische
Refaktorisierung ist nicht in der Art
und Weise möglich wie bei einer statischen
Programmiersprache, auch wenn sich
Entwicklungsumgebungen wie Rubymine
da große Mühe geben. Insgesamt bleibt
aber das Gefühl, dass man wieder wie früher
entwi ckelt.
Steve: Als iOS-Entwickler habe ich nicht
viel Auswahl. Es bleibt mir eigentlich nur
eins: Xcode zu verwenden. Die Entwick -
lungsumgebung aus dem Hause Apple ist
seit OS X für fast jegliche Software für Mac
oder iOS der Ursprung. Erweiterungen zur
IDE wie für Eclipse gibt es keine. Apple
gibt den Weg strikt vor. Refaktori -
10 11

schwerpunkt
sierungshilfen, wie z. B. Extrahieren, Um -
benennen, Verschieben oder automatisches
Einfügen von Boilerplate-Code, den es in
Objective-C viel gibt, existieren leider
nicht. Syntax-Checks des gerade getippten
Codes kann Xcode auch nicht – das liegt
aber vielleicht auch mit an der dynamisch
typisierten Sprache Objective-C. Dafür
kommt Xcode mit einigen Entwicklungs -
werkzeugen daher. Diese beinhalten beispielsweise
den Interface Builder – ein
WYSIWYG-Editor für die Oberflächen der
Apps. Dieser ist zwar selbst auf aktuellen
Mac-Notebooks eher langsam, funktioniert
aber halbwegs zuverlässig. Interessant ist
auch der eingebaute Profiler Instruments.
In Kombination mit dem iPhone-Simulator
kann man hier zuverlässig nach Speicher -
löchern, Zombis (freigegebenen, aber noch
im Zugriff befindlichen Objekten) und
Zeitfressern in der Anwendung fahnden. In
der neuesten Version wird sogar die Ver -
sionsverwaltung Git unterstützt.
Abb. 2: Dependency Injection.
Thema: Dependency-
Injection (DI)
Duke: Auch bei DI profitiert man als Java-
Ent wickler von der Fülle und Reife an Ent -
wicklerwerkzeugen. Die ersten Berührun -
gen mit DI hatte ich mit Struts, das Anfang
des neuen Jahrtausends das vorherrschende
MVC-Framework für die Web-Entwick lung
war. Da es ziemlich konfigurationslastig
war, wurde ihm aber bald durch Spring der
Rang abgelaufen. Obwohl beide
Frameworks mittlerweile auch andere
Optionen anbieten, findet das Zusammen -
bauen von Applikationen aus Komponen -
ten meistens in XML-Konfigurations -
dateien statt. Das ist ungünstig, weil
da durch die Fehlererkennung zur Kompi -
lierzeit – einer der großen Vorteile von statisch
getypten Sprachen – verloren geht.
Außerdem werden diese Konfigurations -
dateien leicht unübersichtlich und sind nicht
Debugger-freundlich. Mittlerweile geht der
Trend daher weg von schwergewichtigen
Frameworks hin zu „Convention over
Configuration” und spezialisierten Biblio -
theken. Nicht zuletzt, weil wir uns da einiges
von Ruby & Rails abgeschaut haben
(Gregg nickt und lächelt). Google Juice
erfreut sich hierbei großer Beliebtheit. Es
kommen aber auch immer mehr und mehr
Stimmen auf, die generell anzweifeln, ob DI
überhaupt einem Framework oder einer
Bibliothek überlassen werden soll. Der
Einfachheit und Verständlichkeit wegen setzen
viele daher auf eine Imple mentierung
von DI in einfachen Assembler-Klassen.
Gregg: Als ich mit Ruby & Rails angefangen
habe, habe ich mich schon gewundert:
Wie macht man hier eigentlich DI? In Java
fand ich es sehr hilfreich, wenn einem die
(technischen) Abhängigkeiten von außen
gegeben wurden. Damit wurde das Testen einzelner
Teile meiner Anwendung erst möglich
(Gregg zeichnet Abbildung 2). Sonst konnte
ich da keinen Schnitt ansetzen und hatte sofort
alle möglichen technischen Systeme an der
Backe. Mittlerweile habe ich gemerkt, dass
das bei Ruby eigentlich völlig unnötig ist.
Nein, jetzt nicht das Testen, sondern das
Problem mit den Abhängigkeiten. Es ist zum
Beispiel möglich, eine Methode an einer
Klasse dynamisch neu zu definieren und durch
einen Mock zu ersetzen. Den Mock schreibe
ich ganz einfach, my_mock = mock(), und mit
meinem aktuellen Mock-Framework, (zum
Beispiel my_mock.should_receive(:my_method).
Es ist nicht nötig, dafür extra irgendwelche
Interfaces zu definieren. Und nebenbei: Der
Klassiker Datenbank ist so eng an meinem
Modell dran, da möchte ich vielleicht auch
nichts abkoppeln. Das lässt sich alles so einfach
und schnell testen, wozu sollte man da
nicht direkt gegen eine In-Memory-Daten -
bank Tests fahren?
Steve: Bislang ist mir für DI auch nichts
Brauchbares untergekommen. Gefühlt
habe ich es aber auch noch nicht vermisst,
was vielleicht daran liegt, dass die iPhone-
Apps eher spezialisiert und klein sind. Die
Oberfläche kann über den Interface-
Builder zusammengebaut werden und man
konfiguriert die Abhängigkeiten graphisch.
Obwohl: Unsere Controller sind schon
recht groß und mehr oder minder fest an
die GUI und an das Datenmodell geknüpft.
Wenn man Daten lokal speichert, dann
muss man Core-Data von Apple benutzen,
das sehr fest an das Modell geknüpft ist.
Ich wüsste nicht, wie ich da die Abhän -
gigkeit zur Persistenz entkoppeln könnte
(Steve blickt fragend in die Runde).
Thema: Release-Prozess
Duke: Die meisten Anwendungen laufen ja
in irgendeinem Applikationsserver, wie
z. B. Tomcat. Die Integration mit Buildund
CI-Werkzeugen ist da recht gut, sodass
das auf Knopfdruck passieren kann. Mit
den richtigen Tools (z. B. [JRe], [Liv]) entfällt
auch das lästige neu Kompilieren und
ein neues Deployment. Das zeitaufwändige
Hoch- und Runterfahren des Servers kann
einem schon ziemlich auf den Geist gehen,
wenn man erst einmal erlebt hat, wie viel
schneller man bei dynamischen Sprachen
vom Schreiben des Codes zur laufenden
Anwendung wechseln kann. Alle Java-
Anwendungen laufen auf der Java Virtual
Machine (JVM) und sind somit selbstverständlich
plattformunabhängig. Diese ist
mittlerweile auch richtig schnell. Teilweise
ist ja JRuby sogar schneller als Ruby selbst.
Gregg: Und bald ist JRuby bestimmt
auch noch schneller als Java (Gregg lacht).
Ja, wenn ich da an klassische Client/Server-
Anwendungen denke, das war schon
schlimm, ein Release auszurollen. Mit den
Web-Anwendungen ist es ja viel einfacher
1/2012

Thema: Continuous
Integration (CI)
Duke: Ich würde behaupten, dass fast alle
Java-Projekte zumindest rudimentärer CI
einsetzen. Die Bandbreite ist hier aber
ziemlich hoch. Einen CI-Server zu haben,
der bei jedem Check-in die Anwendung
baut und testet, ist hier bei Weitem noch
nicht das Ende der Fahnenstange. Dabei ist
CI nicht nur eine Tool-, sondern vielmehr
eine Kulturfrage. Wer seinen Code nicht
mehrmals täglich integriert und Build-
Fehler sofort behebt, macht kein CI. Uns
hat es CI ermöglicht, die Release-Zyklen
von Monaten auf Wochen bzw. Tage zu
verkürzen. Wir sind zwar noch nicht bei
Continuous Deployment, also dem autoschwerpunkt
geworden, ich tippe nur einen einzigen
Befehl und schon ist meine Anwendung
live, die Datenbank ist migriert und alles
läuft rund. Das kann über mehrere Server,
z. B. mit Capistrano (vgl. [Cap]), erfolgen.
Sehr hilfreich ist natürlich die Tatsache,
dass es keinen klassischen Build-Prozess
gibt, der einem viel Kopfschmerzen bereiten
könnte. Ich bin sehr froh, dass ich mich
damit nicht mehr herumschlagen muss. Ich
habe zu viel Zeit in Werkzeuge wie Ant
oder später dann Maven investiert, die beide
einen ganz einfachen Build-Prozess versprochen
haben. Es ist besser geworden,
aber ich finde, das Thema ist nie zufriedenstellend
gelöst worden. Dann lieber Skript-
Sprachen benutzen, die sich damit noch nie
wirklich herumärgern muss ten.
Steve: Der Release einer App über den
Appstore gestaltet sich relativ einfach. In
Xcode erzeugt man ein Binary, das direkt
über Xcode in den Appstore geladen werden
kann. Nach einer circa einwöchigen
Prüfung durch Apple, ob die Anwendung
reif für den Appstore ist, wird die App je
nach Wunsch automatisch oder per Maus -
klick in der App-Verwaltung bei Apple freigegeben.
Vorher muss man sich allerdings
bei Apple als Entwickler oder Firma regis -
trieren, um Anwendungen in den Appstore
laden zu dürfen. Der Nachteil ist natürlich
die nicht vorhandene Vorhersag barkeit:
zum Einen, wann das Update zur
Verfügung steht, und zum anderen, wann
der Anwender die Applikation tatsächlich
aktualisiert. Da verhält es sich mit Apps
eher so, wie mit klassischen Client/Server-
Anwendungen: Wenn man dem Benutzer
nicht mit Fehlermeldungen oder Fehlfunk -
tionen nerven möchte, muss die App
abwärtskompatibel bleiben.
Abb. 3: Der TDD-Zyklus.
matischen Ausliefern in der Produktion bei
jedem Commit, angelangt, aber wir haben
zumindest jederzeit eine lauffähige Version,
die wir ausliefern könnten.
Gregg: Build-Fehler? Nun, einen Build
kenne ich ja nicht (zwinkert). Bei uns ist es
so, dass die Tests auf den lokalen Rechnern
schon eine Weile brauchen, da fühlt sich
das kontinuierliche Testen nicht immer so
gut an. Am schlimmsten sind unsere Ober -
flächentests, die mit Hilfe von Cucumber
und RSpec laufen. Diese testen gegen eine
laufende Web-Applikation (vgl. [Che10]).
Gut, aber auch langsam. Und das alte
Problem haben wir auch: Eine große
Anwendung mit einer komplexen Daten -
struktur erfordert schon ein wenig Setup an
Daten – und es dauert, das für jeden Test
wieder und wieder aufzubauen. Es gibt
technische Tricks und Hilfsmittel, aber das
Problem ist nicht gelöst. Ein echter Fort -
schritt sind übrigens Multi-Core-Systeme.
Da sich Tests in Ruby leicht parallel ausführen
lassen, kann man auf einem
Rechner mit vielen Rechnerkernen auch
eine deutliche Geschwindigkeits stei gerung
erleben. Damit haben wir auch unserem
CI-Server so richtig Beine ge macht. Auf
dem läuft auch das CI-System der Wahl:
Jenkins, oder wie es früher hieß, Hudson.
Steve: Als CI-Server nutzen wir natürlich
auch einen Mac. Auf einer anderen
Plattform könnten wir den Objective-C-
Code für eine iPhone-App gar nicht kompilieren.
Dieser wird über den Konsolen -
befehl xcodebuild gestartet. Das wiederum
setzt auf der Konfiguration in Xcode auf,
welche nur für OSX zu haben ist. Zum
Glück kann man Jenkins direkt von der
Konsole aus starten und auch zuverlässig in
OSX integrieren, sodass Jenkins auch nach
einem ungewolltem Neustart des Rechners
wieder hochfährt. Mit ein wenig Kenntnis
der Konsole und dem Tool Betabuilder (vgl.
[Han10]) oder Testflight (vgl. [Tes]) ist es
auch möglich, direkt eine Betaversion zum
Download zur Verfügung zu stellen. Diese
können sich der Product Owner und die
Tester direkt auf ihrem iOS-Gerät installieren,
sofern sie eine halbwegs aktuelle
Version des Betriebs systems haben. Über
den App-Store lässt sich ja nichts schnell
aktualisieren, schon gar nicht für einen eingeschränkten
Benutzerkreis (Gregg und
Duke schütteln den Kopf). Vorher führt
unser CI-Server Tests mit einem Akzep -
tanztest-Framework namens Frank (vgl.
[Fra]) durch. Diese dauern zwar inzwischen
eine halbe Stunde, haben sich aber schon
mehrfach als Regressionstests bewährt.
Frank benutzt den iPhone-Simulator für
Akzeptanztests, der nur einmal gestartet
werden kann. Darum ist es trotz Mehrkern-
Rechner und Cucumber nicht möglich,
mehrere Tests gleichzeitig auszuführen.
Thema: Test-Driven
Development (TDD)
Duke: Der Vater von TDD, Kent Beck, ist
auch der Macher von JUnit, dem TDD-
12 13

schwerpunkt
Abb. 4: Auszug der Entwicklung von Programmiersprachen.
Framework für Java. Damit sollte doch
wohl klar sein, dass TDD zu Java gehört
wie zu keiner anderen Sprache. Man kann
mit Java auch tatsächlich richtig gut TDD-
Style programmieren. Das Problem liegt
eher darin, dass man in Java meist an
Legacy-Code rumschraubt, der eben nicht
mit TDD erstellt wurde, und daher meist
kein testbares und damit gutes Design aufweist.
Da kann es dann schon mal etwas
schwieriger werden.
Gregg: Klar machen wir auch TDD, wer
nicht? Ich muss auch sagen, dass es bei
Ruby on Rails noch viel wichtiger ist, Tests
zu haben. Das hilft, die vielen kleinen
Flüchtigkeitsfehler auszumerzen, die man
ganz schnell mal macht. Schließlich haut
einem ja nicht ständig ein Compiler oder
eine Entwicklungsumgebung auf die Finger.
Aber ich fühle im Team doch einen gewissen
Druck, mehr und mehr Richtung
Akzeptanztests der Web-Seiten zu gehen,
denn die testen ja dann alles im Zusam -
menspiel durch. Damit verlässt man jedoch
TDD-Zyklen (Gregg zeichnet dabei Abbil -
dung 3). Ich selbst würde die Unit-Tests, mit
denen das Thema Testen erst richtig anfing,
nicht vernachlässigen. Akzeptanz tests sind
aufwändiger zu schreiben: So kann ich zum
Beispiel für eine Anwendung mit 100
Suchoptionen entsprechend viele, langsame
Akzeptanztests schreiben oder aber die
Suche an sich testen und tiefer im System
dann die 100 Suchoptionen, die sich nur in
Datenbankzugriffen unterscheiden.
Eins habe ich fast vergessen: Testen soll
das Design treiben. Man kann natürlich
dagegen halten, dass Rails einem ein festes
Rahmenwerk vorgibt und es nicht so viel
Design zu steuern gibt. Ich kann jedem
auch empfehlen, im großen weiten Netz
nachzuschauen, wie es andere so machen.
Das gehört bei Ruby on Rails zum guten
Ton (vgl. [Rai]).
Steve: Die Anwendung ist insgesamt sehr
eng mit dem SDK verwoben, was TDD
nicht leicht macht. Zum Beispiel ist genau
festgelegt, wie eine View sich beim zugehörigen
View-Controller zu melden hat. Eine
Table-View (wie z. B. in Kontakte) ruft
beim Berühren eines Kontakts die Methode
(void)tableView:(UITableView*)tableView
didSelectRowAtIndexPath:(NSIndexPath*)indexPath
auf und der entsprechende View-Controller
entscheidet dann anhand des IndexPaths, was
zu tun ist. Gelegentlich schafft man es dennoch,
die Fachlogik – die ja eigentlich ohnehin
nicht in der App, sondern im Server bleiben
sollte – von der View und dem
allgegenwärtigen ManagedObjectContext zu
trennen und vernünftig zu testen. Während
des Projekt alltags neigen wir dazu, nach der
Imple mentierung Akzeptanztests zu schreiben,
um Regression vorzubeugen.
Thema: Programmiersprache
Duke: Java ist weit verbreitet und man findet
Java-Entwickler sprichwörtlich an jeder
Ecke. Das macht sie sehr attraktiv für viele
Firmen. Leider entwickelt sich die Sprache
nur sehr langsam weiter und daher schiele
ich schon öfter mal neidisch auf neuere
Sprachen, die mit Features wie Closures
und Higher-Order-Functions aufwarten.
Die können zwar oft auch auf der JVM laufen,
sind aber meist zu instabil oder komplex,
um sich gegen den Platzhirsch durchzusetzen.
Viele kolportieren ja schon das
Ende der Java-Vormachtstellung, können
sich aber noch nicht darauf einigen, wer
denn gegen Java antreten soll.
Gregg: Wenn Leute von Ruby sprechen,
bekomme ich immer wieder zu hören: „Das
ist doch nur eine Skriptsprache”. Da kann
ich nur müde lächeln. Früher fand ich statisch
typisierte Sprachen auch toll. Alles
wird überprüft, alles ist festgezurrt. Und
das ist auch das Problem: Einige Dinge sind
einfach so simpel zu machen, wenn man
keine statischen Typen hat. Versuch doch
einmal, in einer statisch getypten Sprache
eine Methode an eine bestehende Klasse
zur Laufzeit hinzuzufügen oder gar zu
ändern! Die statische Typisierung ist auch
der Grund für all die Interfaces, Delegates
und was auch immer, die man sich schaffen
muss, um ein System flexibel zu gestalten.
Das macht es aber auch unübersichtlicher
und aufgeblähter. In Ruby ist es oft deutlich
einfacher, kürzer und damit eleganter möglich
sich auszudrücken. Apropos kurz: In
Ruby on Rails hat das DRY-Prinzip (Don’t
repeat yourself) einen sehr hohen
Stellenwert. Wiederholungen werden geradezu
gehasst und auch durch die
Möglichkeiten, die Ruby bietet, sehr effektiv
vermieden.
Steve: Objective-C ist eine Erweiterung
von C (Steve zeichnet zusammen mit den
anderen nebenbei Abbildung 4). Einsatz -
gebiet von Objective-C ist Mac-OS und
iOS von Apple. Wer für die Geräte von
Apple Software schreiben will, kommt nur
schwer um Objective-C herum. Als Apple-
Jünger merkt man sehr schnell, wenn das
typische Look & Feel einer Mac-Anwen -
dungen nicht gegeben ist. Ein Versuch von
Apple, in Xcode eine Cocoa-Java-Bridge
einzubauen, wurde schnell wieder unterlassen.
Die Lernkurve für Objective-C empfinden
viele Java-Entwickler als steil wie
eine Wand. Verwöhnt von der JVM, die
brav jedes Objekt wegräumt, das nicht
mehr benötigt wird, muss man sich stark
umgewöhnen, um jedes erzeugte Objekt
von Hand wieder aufzuräumen. Beim
Weiterreichen von Instanzen können
Anfänger schnell den Überblick verlieren,
1/2012

schwerpunkt
wer da gerade welche Instanz eines Objekts
hält (retain) und wann diese freigegeben
(released) werden darf. Beim Implemen -
tieren einer Klasse und seiner Properties
(Instanzvariablen in Java) muss man sich
hierüber auch schon Gedanken machen.
Die Allgegenwärtigkeit des Umstands führt
nach kurzer Übung zum speicherschonenden
Entwickeln. Als dynamisch typisierte
Sprache kann man zur Laufzeit mittels
Kategorien bestehende Klassen um Metho -
den erweitern. Dies gilt auch für Klassen
des SDKs, wie etwa NSString, die nicht als
Quellcode vorliegen.
Thema: Externe Systeme
Duke: Hier wurde früher viel mit RMI und
– falls man zu einem nicht-Java-System
sprechen wollte – CORBA gearbeitet.
Danach waren Web-Services für eine Weile
sehr populär. Wie immer findet man dafür
jeweils leicht entsprechende Bibliotheken.
Wobei man bei den vielen APIs in Sachen
Web-Services schon mal den Überblick verlieren
kann. Nicht umsonst gibt es bei
Oracle einen eigenen Web-Services-Kurs,
um bei JAX-RPC, JAXB, JAXR, SAAJ, etc.
(Gregg und Steve schauen sich fragend an)
nicht den Über- und Durchblick zu verlieren.
Heutzutage machen wir das natürlich
auch gerne mit REST-Schnittstellen.
Gregg: Heute gibt es immer mehr externe
Systeme, die angebunden werden. Mittler -
weile geht das ja glücklicherweise nicht
mehr über proprietäre Schnittstellen, sondern
in meinem Bereich einfach über eine
passende REST-Schnittstelle. Die Daten
werden über XML oder besser noch über
JSON übertragen. Damit ist der Zugriff
offen, leicht anzubinden und auch von
allen System aus möglich. Rails bietet hierfür
eine geradezu natürliche Unterstüt zung.
Das ist ein deutlicher Schritt nach vorne.
Dazu gibt es über Ruby-Gems noch die
Möglichkeit, sich Bibliotheken jeglicher
Art in seine Anwendung zu holen.
Softwareverteilung ist ja eigentlich ein alter
Hut, wenn man auf UNIX-Paketverwal -
tungswerkzeuge schaut. Aber es hat eine
Weile gedauert, bis es das auch für
Software-Frameworks gab. Jedenfalls ist es
damit heutzutage möglich, sich auch noch
für alle möglichen Fremdsysteme passende
Bibliotheken zu installieren.
Steve: Apps für mobile Geräte sind die
Endpunkte in den Systemlandschaften.
Leistungsfähig genug, um als eigenständiger
Client zu agieren, versuchen native
Literatur & Links
Apps, eine möglichst flüssige Bedienung zu
erzeugen. Auf dem iPhone können dazu in
der SqLite-Datenbank alle nötigen Daten
abgespeichert werden. Datenaustausch
sollte möglichst viel im Hintergrund stattfinden,
um dem Benutzer bei langsamen
Verbindungen nicht unnötig warten zu lassen
– was viele Apps leider falsch machen.
Häufig werden bereits vorhandene
Schnittstellen an Systemen mitbenutzt. Oft
sind das nicht die modernen, leichtgewichtigen
Schnittstellen, die für langsame
Verbindungen vonnöten wären. Optimal
sind zustandslose Protokolle, wie JSON
über eine REST Schnittstelle. So können
viele Daten auch bei langsamen Verbin -
dungen schnell und zuverlässig in beide
Richtungen wechseln und die View mit
Inhalt füllen.
■
[Cap] Capistrano, Utility and framework for executing commands, siehe:
https://github.com/capistrano/capistrano/
[Che10] D. Chelimsky, D. Astels, Z. Dennis, A. Hellesøy, B. Helmkamp, D. North, The RSpec
Book: Behaviour Driven Development with RSpec, Cucumber, and Friends, The Pragmatic
Programmers 2010
[Fow04] M. Fowler, Inversion of Control Containers and the Dependency Injection pattern, 2004,
siehe: http://martinfowler.com/articles/injection.html
[Fra] Frank, siehe: http://blog.thepete.net/2010/07/frank-automated-acceptance-tests-for.html
[Han10] Hanchor LLC, Introducing iOS Beta Builder, 2010, siehe:
http://www.hanchorllc.com/2010/08/24/introducing-ios-beta-builder/
[Inf11] InfoWorld, Review: Top Java programming tools, 2011, siehe:
http://www.infoworld.com/d/developer-world/infoworld-review-top-java-programming-tools-191
[JRe] JRebel, What does JRebel do?, http://www.zeroturnaround.com/jrebel/
[Liv] LiveRebel siehe: http://www.zeroturnaround.com/liverebel/
[Rai] Ruby on Rails Screencasts, siehe: http://railscasts.com/
[Tes] Testflight, siehe: http://testflightapp.com
14 15

schwerpunkt
mehr zum thema:
http://scrumalliance.org/CSD
http://www.it-agile.de/csd.html
die autoren
CERTIFIED SCRUM DEVELOPER:
DER GANZHEITLICHE
ENTWICKLER
Scrum trat einst als allgemeines Projekt-Rahmenwerk an, mit dem sich nicht nur Softwareent -
wicklung betreiben lässt, sondern beispielsweise auch Marketing und Projektmanagement. In
der Praxis merkten viele Teams jedoch, dass es schwer ist, mit Scrum zu arbeiten, wenn man
nicht auch moderne Programmierpraktiken benutzt. Diesem Umstand zollte die Scrum
Alliance Tribut und führte den „Certified Scrum Developer” ein. So finden Teams noch besser zu
einem runden Vorgehen nach Scrum. In diesem Artikel zeigen wir, welche Praktiken die Scrum
Alliance für Softwareentwickler empfiehlt, welche Gefahren drohen, falls sie sie nicht beherrschen,
und welchen Nutzen sie daraus ziehen, wenn sie sie erlernen und einsetzen.
Andreas Havenstein
(E-Mail: andreas.havenstein@it-agile.de)
ist bei der it-agile GmbH Trainer, Senior-
Softwareentwickler und Architekt. Sein
Schwerpunkte sind flexible Architekturen und die
Anwendungsentwicklung unter Einsatz agiler
Methoden, insbesondere von XP.
Als Mitte der Neunziger Jahre schwergewichtige,
dokumentenlastige Prozesse den
Markt dominierten, gab es eine Gruppe
von Softwareentwicklern und Projekt -
managern, die der Trägheit der Wasserfall-
Prozesse eine leichtgewichtige Alternative
entgegenstellen wollten. Kent Beck beispielsweise
erkannte, dass die bis zum
Maximum gesteigerte Anwendung bewährter
Engineering-Praktiken in Kombination
mit vielen kurzen Feedback-Schleifen ein
Softwareprojekt zum Erfolg führen kann.
Er fasste Entwicklungspraktiken zum
eXtreme Programming (XP) zusammen
und schuf und beschrieb in [Bec00] den
ersten großen Vertreter dessen, was später
als agile Softwareentwicklung bezeichnet
wurde.
Scrum entstand zu einer ähnlichen Zeit
wie XP und wurde Anfang des neuen
Jahrtausends bekannter, als Ken Schwaber
ein erstes Buch hierzu veröffentlichte (vgl.
[Sch01]). In den darauf folgenden Jahren
setzte ein so großer Scrum-Boom ein, dass
Marko Schulz
(E-Mail: marko.schulz@it-agile.de)
unterstützt Teams dabei, agile Softwareentwick -
lungs praktiken umzusetzen. Neben Schulungen
legt er bevorzugt selber mit Hand an und programmiert
mit. Insbesondere beachtet er technische
Grundlagen wie TDD und evolutionäres Design.
agile Softwareentwicklung und Scrum für
viele synonym wurden. Entwicklungs -
praktiken, in XP noch dominierender
Bestandteil, rückten in den Hintergrund.
Scrum ist ein Methodenrahmen, der prinzipiell
unabhängig von der Software erstel -
lung angewandt werden kann und der keine
Aussage darüber trifft, mit welchen
Mitteln Anforderungen in Software umgesetzt
werden sollen.
Abb. 1: Der ganzheitliche Mensch, wie Leonardo da Vinci ihn sah.
Scrum ohne Unterbau
Die Erfahrung der letzten Jahre hat gezeigt,
dass es vielen Scrum-Teams nicht gelingt,
Sprint-Ergebnisse mit ausreichend hoher
Qualität zu erstellen. Martin Fowler
bezeichnete dies in [Fow09] als Flaccid
Scrum und auch Ken Schwaber gestand in
einem Interview ein, dass viele Entwick -
lungsteams nicht ausreichend mit modernen
Entwicklungspraktiken vertraut sind
(vgl. [Inf]).
Auch die Scrum Alliance hat diesen Miss -
stand erkannt und eine neue Zertifizierung,
den Certified Scrum Developer (CSD), de -
finiert. Zusätzlich zu der Kenntnis des
Scrum-Prozesses muss ein CSD auch weitere
technischen Fähigkeiten zur Erstellung
von Software erlernen.
16 17

Continuous Integration
Um permanentes Feedback über den Ent wicklungsstand zu
bekommen, muss ein gemeinsames Quellcode-Repository vorschwerpunkt
Grundsätzlicher Nutzen und Schaden von Zertifizierungen
wurden unter anderem in [Col09] diskutiert, ohne dass wir es
hier wiederholen wollen. Ob die CSD-Zertifizierung als
Werbe-Etikett sinnvoll ist, sollte jeder für sich selbst entscheiden.
Unseren Erfahrungen nach ist die mit dem CSD-
Zertifikat verbundene Schu lung aber so wertvoll, dass wir
sie jedem Entwickler – gerade im Scrum-Kontext – ans Herz
legen.
Kasten 1: Braucht die Welt eine weitere
Zertifizierung?
Praktiken eines
Scrum-Entwicklers
Insbesondere Fähigkeiten und Kenntnisse in den im Folgenden
beschriebenen Be reichen sind notwendig, um als CSD im
Scrum-Kontext qualitativ hochwertige Soft ware erstellen zu
können.
Architektur und Design
Scrum erfordert flexible Strukturen, damit das Team jederzeit
auf geänderte Anfor derungen reagieren kann, die der Product
Owner (PO) einbringt. Ohne flexible Strukturen kommt es zu
der gefürchteten steilen Aufwandskurve, bei der Änderungen
und komplett neue Features mit dem Fortschritt der
Entwicklung so teuer werden, dass sie schließlich nicht mehr
vertretbar umzusetzen sind. Ein CSD muss Entwurfsprinzipien
kennen und anwenden können, die zu entkoppelten Strukturen
führen.
Test Driven Development
Die Grundregeln von TDD sind sehr einfach Bob Martin hat sie
in [Mar] auf nur drei Gesetze heruntergebrochen:
■ Schreibe keinen Produktivcode ohne einen fehlschlagenden
Test.
■ Schreibe nur soviel Testcode, bis du einen fehlschlagenden
Test hast.
■ Du darfst nur genau so viel Pro duktivcode schreiben, wie
gerade notwendig ist, um den einen fehlschlagenden Test zu
erfüllen.
Jeder, der versucht hat, konsequent TDD zu betreiben, hat
jedoch gemerkt, wie herausfordernd diese Regeln sind. So setzen
viele Teams nur ansatzweise TDD um und kommen nicht
dazu, sein eigentliches Potenzial auszuschöpfen. Die konsequente
Anwendung von TDD-Praktiken führt zu flexiblem
Design und erzeugt ein Sicher heitsnetz für Refaktorisierungen
und funktionale Umstrukturierungen.
handen sein. Darauf basierend müssen auto matisierte, getestete
Builds mit hoher Geschwindigkeit erstellt werden können.
Das ist der erste, fundamentale Schritt, um letztendlich zu
Continuous Deployment (vgl. [Rie09]) zu gelangen, wie es von
im mer mehr Entwicklungsteams betrieben wird.
Collaboration
Scrum fordert und fördert eine enge Zu sam menarbeit – sowohl
innerhalb des Ent wicklerteams, als auch mit dem PO und
Stakeholdern. Wie dies geschehen kann, ist jedoch nicht näher
festgehalten. So kommt es im oder kurz vor dem Sprint-Review
immer wieder zu Überraschungen, was implizit angenommen
und nicht klar kommuniziert wurde.
Ein CSD muss dagegen in der Lage sein, kommunikativ
sowohl innerhalb des Teams (z. B. mit Pair-Programming) als
auch mit dem Kunden (z. B. durch das Schreiben von automatisierten
Akzeptanz tests) zusammenzuarbeiten.
Refaktorisierung
So, wie der PO erst mit der Zeit eine Vor stellung davon
gewinnt, welches die wertvollsten Features einer Software sind,
bekommt auch das Entwicklungsteam erst mit der Zeit eine
Vorstellung davon, welches die passende Architektur ist, um
diese Features bestmöglich umzusetzen.
Viele Entwickler schieben die Fortent wick lung der
Architektur vor sich her – und das vor allem aus zwei Gründen:
■ Es fällt ihnen schwer zu entscheiden, wann eine
Refaktorisierung angebracht ist.
■ Es fällt ihnen schwer, einen sicheren, zügigen Weg zu einer
besseren Architektur zu finden, insbesondere falls dieser
den begrenzten Rahmen der in integrierten
Entwicklungsumge bungen eingebauten Refaktorisierungs -
möglichkeiten sprengt.
Ein CSD muss wissen, wann und wie Refaktorisierungen
durchgeführt werden sollen, um die Architektur zu gestalten
und fortzuentwickeln.
Für die Zertifizierung als CSD fordert die Scrum Alliance,
dass ein Entwickler sowohl den Scrum-Prozess, als auch agile
Entwicklungspraktiken kennt (vgl. [Scr]). Ein verbreiteter
Weg zur CSD-Zertifizierung besteht darin, die Scrum-
Grundlagen über einen CSM-Kurs und die
Entwicklungspraktiken über einen AEP-Kurs (Agile
Entwicklungsprak tiken) zu lernen.
Alternativ zum CSM-Kurs kann ein Entwickler auch einen
CSPO-Kurs (Certified Scrum Product Owner) oder eine
Einführung in die Scrum-Grundlagen (SG) sowie eine zusätzliche
Wahlpflichtvertiefung (WV) besuchen, wie in
Abbildung 2 zu sehen ist. Viele Entwickler haben jedoch
schon einen CSM-Kurs besucht, um die Scrum-Grundlagen
kennenzulernen, selbst wenn sie nicht als Scrum-Master
arbeiten.
Kasten 2: Die CSD-Zertifizierung.
1/2012

schwerpunkt
Abb. 2: Das CSD-Zertifizierungsschema.
Der ganzheitliche Entwickler
Ein CSD ist damit ein „ganzheitlicher”
Entwickler. Er kennt den Scrum-Prozess
und die XP-Entwicklungspraktiken und
kann damit qualitativ hochwertige Sprint-
Inkremente erstellen.
Damit wurde für Scrum nicht wirklich
etwas Neues gefunden, sondern – wie schon
XP – entdeckt der CSD bereits bekannte
Praktiken neu. Warum? Weil wir merken,
was für große Probleme wir haben, wenn wir
diese Praktiken nicht verfolgen. Und weil wir
wieder merken, dass dies kein Selbstläufer ist,
sondern wir uns als Entwickler mit diesen
Praktiken allein und im Team immer wieder
auseinandersetzen müssen.
■
Literatur & Links
[Bec00] K. Beck, Extreme Programming Explained, Addison-Wesley 2000
[Col09] J. Coldewey, J. Link, Die Ent-Zertifizierung des Fortschritts, in: OBJEKTspektrum
03/2009
[Fow09] M. Fowler, Flaccid Scrum, 2009, siehe: http://martinfowler.com/bliki/FlaccidScrum.html
[Inf] InfoQ, Interview with Ken Schwaber – Part 3, siehe:
http://www.infoq.com/news/2010/09/kenschwaber-interview-part3
[Mar] B. Martin, The Three Laws of TDD, siehe:
http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd
[Rie09] E. Ries, Continuous deployment in 5 easy steps, 2009, siehe:
http://radar.oreilly.com/2009/03/continuous-deployment-5-eas.html
[Sch01] K. Schwaber, M. Beedle, Agile Software Development with Scrum, Prentice Hall 2001
[Scr] Scrum Alliance, Certified Scrum Developer, siehe: http://www.scrumalliance.org/CSD
18 19

schwerpunkt
die autoren
CODE-FLAVOURS:
NÜTZLICHE JAVA-IDIOME
Während Anti-Pattern das negative Gegenstück zu den bekannten Design-Pattern bzw.
Entwurfsmustern sind, gibt es auf niedriger Abstraktionsebene die Code-Smells als Gegensatz
zu den weniger bekannten Idiomen. Wir stellen in diesem Artikel einige alt bekannte und auch
neue Java-Idiome vor. Denn man verbessert sich und lernt besser durch positive statt durch
negative Beispiele.
In der Begriffswelt der Softwaretechnik
begegnen einem Design-Pattern, Anti-
Pattern sowie Code-Smells und Idiome in
vielen Zusammenhängen. Die genaue
Bedeutung der Begriffe ist oft aber nicht
explizit erklärt oder wird einfach vorausgesetzt.
Dabei sind die Definitionen keineswegs
einfach oder eindeutig.
Pattern und Anti-Pattern
Nachdem sich Entwurfsmuster (Design
Pattern, vgl. [Gam96]) als nützliche
Lösungen für wiederkehrende Probleme in
der objektorientierten Softwareentwick -
lung etabliert haben, wurden bald darauf
ihre negativen Gegenstücke, die Anti-
Pattern (vgl. [Bro07]), beschrieben. Anti-
Pattern schildern schlechte Lösungen und
Beispiele, wie sie oft in der Praxis anzutreffen
sind. Im Gegensatz zu den Entwurfs -
mustern bezieht sich der Begriff Anti-
Pattern nicht nur auf den Entwurf
ob jekt orientierter Software, sondern auch
Abb. 1: Sprachspezifität vs. Abstraktion.
auf Architektur-, Prozess- und Mana -
gement probleme.
Idiome und Code-Smells
Neben den Anti-Pattern gab es auch deren
„kleine Brüder”, die Code-Smells (vgl.
[Fow01]). Diese „schlechten Gerüche”
beschreiben schlechten Stil oder ungünstige
Lösungen auf der Ebene weniger oder zum
Teil nur einer Codezeile (Beispiel: „Magic
Number”). Das Gegenstück sind die
Idiome (vgl. [Wik-a]), die zwar für „echte”
Entwurfsmuster zu klein sind bzw. sich auf
einer zu niedrigen Abstraktionsebene befinden,
aber dennoch in vielen Kontexten einsetzbar
sind.
Zielsetzung und Abgrenzung
Genau wie die Entwurfsmuster passen
Idiome nicht immer. Und eine übertriebene
oder erzwungene Anwendung verwirrt
eher, als dass sie hilft. Der Hintergrund der
André Janus
(E-Mail: mail@andre-janus.de)
ist freiberuflicher Software Engineer/Consultant
und Doktorand der AG Softwaretechnik an der Uni
Magdeburg. Er beschäftigt sich mit Systeminte -
gration, Web-Anwendungen auf Basis von Java-
Technologien und Qualitätssicherung im Kontext
agiler Softwareentwicklung.
Jens Jäger
(E-Mail: mail@jensjaeger.com)
ist freiberuflicher Software-Engineer. Er beschäftige
sich mit agiler Softwareentwicklung und
Usability sowie der Analyse, Modellierung und
Implementierung komplexer datenbankgestützter
Systeme mit den Technologien JavaEE und Ruby on
Rails.
Pattern und Idiome ist es nämlich nicht nur,
gelungene Lösungen wiederzuverwenden,
sondern auch Strukturen zu schaffen, die
für alle am Code schreibenden Entwickler
zu verstehen sind – und damit eine Basis für
Architektur- und Design-Diskussionen zu
schaffen.
Die Grenze zwischen Entwurfsmuster
und Idiom ist zudem nicht eindeutig zu ziehen.
In der Regel sind Idiome sprachspezifisch
(vgl. [Idi]), weswegen wir in diesem
Artikel von „Java-Idiomen” sprechen. Es
gibt sogar Java-EE-Pattern (vgl. [Ora10]),
die noch spezifischer nur für die Java-EE-
Plattform gelten. Die Code-Smells andererseits
werden wieder als sprachunabhängig
angesehen. Die Terminologie im Bereich
Pattern und Idiome ist also alles andere als
eindeutig. Wir haben daher versucht, die
Situation in Abbildung 1 anschaulich darzustellen.
Nützliche Java-Idiome
Im Folgenden werden wir auf einige be -
kannte Java-Idiome eingehen, aber auch
20 21

schwerpunkt
public class Singleton
{
/**
* Privater Konstruktor verhindert externe Instanzierung
*/
private Singleton()
{
}
/**
* Innere statische Holder-Klasse
*/
private static class Holder
{
private static final Singleton INSTANCE = new Singleton();
private Holder()
{
}
}
/**
* Statische Factory-Methode
*/
public static Singleton getInstance()
{
return Holder.INSTANCE;
}
}
Listing 1: Singleton-Implementierung mit
dem Holder-Idiom.
eher unbekanntere „Code Flavours” vorstellen.
Quellen für Idiome gibt es im Web
viele, besonders umfangreich ist beispielsweise
[Jav], neu und innovativ, aber auch
streitbar ist aus unserer Sicht etwa [Cod].
Holder-Idiom
Das Holder-Idiom – auch Holder Pattern
genannt – dient der thread-sicheren Imple -
mentierung von Singletons in Java. Das
Singleton-Pattern (vgl. [Gam96]) ist eines
der bekanntesten Entwurfsmuster. Es wird
verwendet, wenn nur eine Instanz einer
Klasse existieren darf. Singletons haben bei
falscher Verwendung einige Nachteile. Sie
ermöglichen z. B. die Verwendung als globale
Variable, um prozedural statt objektorientiert
zu programmieren. Unter anderem
sind Singletons nur schwer zu testen. Das
Entwurfsmuster Singleton sollte also nur
sehr sparsam verwendet werden. In
Legacy-Code wird man jedoch sehr wahrscheinlich
auf einige Singletons treffen, die
im schlimmsten Fall nicht thread-sicher
implementiert sind.
Das Holder Idiom (vgl. [Jen]) gewährleis -
tet die Thread-Sicherheit durch die
Verwendung einer inneren statischen Klasse.
Die Initialisierungsphase einer Klasse ist
durch die Java Language Specification (vgl.
[Sun]) garantiert nicht nebenläufig. Ein weiterer
Vorteil ist, dass die Initialisierung erst so
spät wie möglich – bei der ersten
Verwendung – stattfindet (siehe Listing 1).
Localized-Instance-Idiom
Das Localized-Instance-Idiom eignet sich
zum dynamischen Verwenden länderspezifischer
Klassen – daher wird es auch
Localized Class genannt. Auch in Zeiten
von Dependency Injection (DI) und
Inversion of Control gibt es sinnvolle
Anwendungen für dieses Idiom, gerade
wenn in älteren Anwendungen keine DI-
Frameworks zur Verfügung stehen oder
deren Einsatz aus irgendwelchen Gründen
nicht möglich ist.
Zu einer Basisklasse MyBusinessClass exis -
tieren auch länderspezifische Varianten,
wie z. B. MyBusinessClass_DE oder
MyBusinessClass_US, die von der Basisklasse
erben und Methoden mit länderspezifischer
Logik überschreiben. In der Basisklasse findet
sich eine Methode, die automatisch die
jeweilige Klasse instanziiert und – in dieser
Variante des Idioms – als Fallback ein
Objekt der Basisklasse zurückgibt. Die
Vorteile liegen auf der Hand: Länder -
spezifische Logiken können voneinander
getrennt implementiert werden – gleichzeitig
kann der Aufruf der entsprechenden
Logik völlig transparent und einheitlich
erfolgen. Beim Aufruf muss man nicht einmal
wissen, ob es eine länderspezifische
Logik gibt (siehe Listing 2).
Dieses Idiom ist relativ komplex und
kann auch schon zu den Entwurfsmustern
gezählt werden. Dennoch ist es sprachspezifisch
(und damit ein Idiom), da das
Instanziieren der Klasse so nicht in allen
Sprachen möglich ist.
Transfer-Container
Aktuelle Anwendungen stehen nicht allein
im luftleeren Raum – heutzutage ist es
üblich, verschiedene Systeme über unterschiedliche
Schnittstellen zu verbinden. Die
genaue technische Umsetzung kann durch
Web-Services (SOAP, REST) oder mit
Message Queueing (z. B. mit „MQSeries”)
public class MyBusinessClass
{
protected MyBusinessClass()
{
}
public static MyBusinessClass localizedInstance()
{
Class< ? > myClass = MyBusinessClass.class;
String context = … // get context from somewhere, for
example "DE”
String myClassName = myClass.getName() + context;
Class< ? > myLocalizedClass;
try
{
myLocalizedClass = Class.forName(myClassName);
}
catch (ClassNotFoundException e)
{
myLocalizedClass = myClass;
}
MyBusinessClass myInstance;
try
{
myInstance = (MyBusinessClass)
myLocalizedClass.newInstance();
}
catch (InstantiationException e)
{
myInstance = new MyBusinessClass ();
} catch (IllegalAccessException e)
{
myInstance = new MyBusinessClass ();
}
return myInstance;
}
public doBusinessLogic()
{
// implement the standard behaviour here
}
}
public class MyBusinessClass_DE extends MyBusinessClass
{
@Override
public doBusinessLogic()
{
// implement the country-specific behaviour here
}
}
// usage of localized instances
MyBusinessClass.localizedInstance().doBusinessLogic();
Listing 2: Basis-Implementierung des
Localized-Instance-Idioms.
1/2012

schwerpunkt
public class TransferContainer()
{
private Status status;
private Object buisnessObject;
public enum Status { OK,
NOT_SUPPORTED_IN_THIS_COUNTRY }
…
}
StringBuilder sql = new StringBuilder();
sql.append("SELECT *");
sql.append(" FROM table1");
sql.append(" WHERE column1 = "value"");
sql.append(" AND column2 = "uelav"");
Listing 4: Mit StringBuilder-
Concatenation in Java eingebettetes SQL.
final Bar bar;
public void doCalulation(final Foo foo)
{
bar = calculate(foo);
}
Listing 5: Finale Variablen als lokale
Variable und als Methoden-Parameter.
Listing 3: Einfaches Beispiel für einen
Transfer-Container.
Enum Business Constants
In fast jedem Projekt, das fachliche Pro -
zesse abbildet, gibt es Konstanten für vererfolgen.
Die entsprechenden Bibliotheken
abstrahieren die Transportschicht und sorgen
für eine Fehlerbehandlung bei Kom -
muni kationsfehlern.
Es gibt jedoch zahlreiche Anwendungs -
fälle, bei denen eine Fehlerbehandlung nicht
sinnvoll in der Transportschicht abgehandelt
werden kann. Beispielsweise sei ein System
genannt, das für mehrere Länder in
Produktion ist, aber bestimmte Schnitt -
stellen nicht in allen Ländern zur Verfügung
stellt. Hier ist es sinnvoll, nach dem Vorbild
der Internet-Protokolle (vgl. [Int91]) eine
weitere Schicht zwischen Transportschicht
und fachlicher Logik einzuziehen: den
Transfer-Container. Im einfachsten Fall ist
dieser ein „Umschlag” um das fachliche
Objekt mit einer Variable, die den
Rückgabestatus enthält (siehe Listing 3).
Der Transfer-Container sorgt für eine
Separation of Concerns, indem Dinge, die
nicht wirklich technisch sind, aber auch
nicht in ein fachliches Objekt gehören, klar
gekapselt sind. Je nach Implementierung
bekommt der Aufrufer des Transfer-
Containers eine genaue Rückmeldung, was
eigentlich passiert, statt eines wenig aussagekräftigen
http-500-Fehlers (Internal
Server Error).
StringBuilder-Concatenation
Da es in Java nicht, wie in JRuby, die so
genannten Multiline Strings gibt und
zudem ältere Versionen des Java-Compilers
beim Konkatenieren von Strings jedes Mal
ein neues String-Objekt erzeugen, werden
in Java oft StringBuilder als Notlösung verwendet.
Diese werden benutzt, um größere
Strings – z. B. eingebettetes SQL für JDBC
oder JavaScript – zusammenzusetzen und
dabei trotzdem noch die Lesbarkeit zu
erhalten. Auch wenn es sich hier um ein
recht naives Idiom handelt, ist die Lösung
dennoch häufig anzutreffen und sowohl
hilfreich als auch übersichtlich (siehe
Listing 4).
Bei der StringBuilder-Concatenation
handelt es sich eindeutig um ein Idiom, da
es sowohl zu klein für ein Entwurfsmuster
als auch zu spezifisch für die Sprache Java
ist. Auch wenn modernere Compiler den +-
Operator wie beispielsweise in Java 1.4
durch den StringBuffer und seit Java 5 durch
den StringBuilder ersetzen, gibt es dennoch
Fälle, in denen die automatische Umset -
zung nicht optimal ist (vgl. [Cap11]).
Außerdem kann man durch eine manuelles
Verwenden des StringBuilder zum Beispiel
SQL gut lesbar im Java-Code einbetten.
Finale Variablen
Alle lokalen Variablen und Variablen in der
Parameterliste einer Methode sollten mit
dem Schlüsselwort final versehen sein. Zur
Erinnerung: Finale Variablen können nur
einmalig initialisiert werden. Die Initia li -
sierung muss nicht mit der Deklaration
erfolgen (siehe Listing 5).
Auf den ersten Blick sieht es etwas ungewohnt
aus, jede Variable mit final zu versehen.
Es führt jedoch zu weniger Fehlern und
erzwingt einen sauberen Program mierstil.
Wenn eine Variable ein zweites Mal beschrieben
wird, ist dies eine Mehrfachverwendung,
die man eigentlich vermeiden sollte (vgl.
[Mar08]). Code analyse-Tools, wie
„Findbugs” (vgl. [Sou-a]) oder „PMD” (vgl.
[Sou-b]), werten dies daher auch als Fehler.
Mit dem Schlüssel wort final kann man so mit
Mitteln der Sprache Java logische Fehler und
Schreib fehler effektiv verhindern, die im
Zweifel erst durch Codeanalyse-Werkzeuge
und im schlechtesten Fall gar nicht gefunden
würden.
schiedenste Dinge. Sobald jedoch mehr als
eine Konstante des gleichen fachlichen Typs
existiert, sollten Enums bevorzugt werden.
Dadurch ist der fachliche Kontext zusam -
mengehörender Werte im Code abgebildet.
Da Enum-Typen wie vollwertige Klassen
behandelt werden, können sie beliebig
komplex entworfen werden (vgl. [Kra06]).
Dies kann man sich geschickt zu Nutze
machen, um Geschäftslogik abzubilden
(siehe Listing 6). In dem Beispiel werden
drei Fabriken angelegt und für jede Fabrik
werden die dort hergestellten Produkte im
Konstruktor übergeben. Somit ist für jeden
Programmierer sofort klar, welche Pro -
dukte aus welcher Fabrik kommen.
Das Enum-Business-Constants-Idiom
hilft, Logik an einer Stelle zu halten, und
vereinfacht so den Code und hilft Fehler zu
vermeiden.
Fazit
Durch Code-Flavours bzw. Idiome können
allgemein bekannte und gute Lösungen
wiederverwendet werden. Code-Flavours
machen den Code damit lesbar und wartbar.
Entwickler haben Begriffe, die die
Struktur des Codes beschreiben und damit
Design-Diskussionen vereinfachen.
Da aber die Abstraktionsebene niedriger
und die Lösungen (sprach-)spezifischer
sind als bei den Pattern, ist die Gefahr auch
größer, hier durch ein Over-Engineering,
also das übertriebene oder falsche Nutzen
der Idiome, den Code komplexer zu
machen als notwendig. Außerdem sind einzelne
Pattern und Idiome durchaus umstritten:
So gilt Singleton in Zeiten von DI vielen
als Anti-Pattern. Und auch der
StringBuilder wird von vielen nicht
genutzt, da der Compiler dies in den meis -
ten Fällen erledigt. Auch andere Idiome
und Pattern – gerade solche, die wir hier
vorgestellt haben – finden sicher nicht bei
22 23

schwerpunkt
public enum Factory
{
STUTTGART, NEW_YORK(Product.P2, Product.P3), TOKIO;
private final Product[] products;
Factory(Product … products)
{
this.products = products;
}
public Product[] getProducts()
{
return this.products;
}
}
Listing 6: Fabrik-Beispiel für Enum-
Business-Constants.
allen Gefallen. Wir freuen uns daher über
kritisches Feedback – natürlich auch über
positives.
Trotz aller Kritik sind Code-Flavours
eine gute Wahl, um die Entwicklung von
Software und deren Qualität weiter zu verbessern.
Für bestimmte Probleme in
bestimmten Kontexten stellen sie genau die
richtige Lösung dar. Daher sollten angehende
Entwickler, auch im Sinne eines besseren
Lernens, eher die guten Beispiele als
die schlechten Beispiele kennen und verstehen.
■
Literatur & Links
[Bro07] W.J. Brown, R.C. Malveau, H.W. McCormick III, T.J. Mowbray, Anti Patterns:
Entwurfsfehler erkennen und vermeiden, mitp 2007
[Cap11] M. Caprari, Java bytecode, string concatenation and StringBuilder, 2011, siehe:
http://caprazzi.net/posts/java-bytecode-string-concatenation-and-stringbuilder/
[Cod] Code Monkeyism, siehe: http://codemonkeyism.com/generation-java-programming-style/
[Fow01] M. Fowler, K. Beck, J. Brant, W. Opdyke, Refactoring, Improving the Design of Existing
Code, Addison-Wesley 2001
[Gam96] E. Gamma, R. Helm, R. Johnson, J. Vlissides, Entwurfsmuster: Elemente wieder verwendbarer
objektorientierter Software, Addison-Wesley 1996
[Idi] Idiom or Pattern, siehe: http://c2.com/ppr/wiki/JavaIdioms/IdiomOrPattern.html
[Int91] Internet Protocol, 1991, siehe: http://tools.ietf.org/html/rfc791
[Jav] Java Idioms, siehe: http://c2.com/ppr/wiki/JavaIdioms/JavaIdioms.html
[Jen] jensjaeger.com, Singletons in Java mit dem Holder-Pattern, siehe:
http://www.jensjaeger.com/2010/04/singletons-in-java-mit-dem-holder-pattern
[Kra06] K. Kreft, A. Langer, Effective Java: Neue Sprachmittel für Java 5.0 - Teil 1: Einführung
in Aufzählungstypen, in:JavaSpektrum 6/2006
[Mar08] R.C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship, Prentice Hall
2008
[Ora10] Oracle, Java EE Pattern, 2010, siehe: http://java.sun.com/developer/technicalArticles/J2EE/patterns/
[Sou-a] Sourceforge.net, Find Bugs in Java Programs, siehe: http://findbugs.sourceforge.net/
[Sou-b] Sourceforge.net, PMD, siehe: http://pmd.sourceforge.net/
[Sun] Sun, Java Language Specification, Kap. 12.4, siehe:
http://java.sun.com/docs/books/jls/third_edition/html/execution.html#44557
[Wik-a] Wikipedia, Idiom, siehe: http://de.wikipedia.org/wiki/Idiom_%28Softwaretechnik%29
1/2012

Vorteile von DI
DI weist eine ganze Reihe von Vorteilen auf:
Die Softwarestruktur wird verbessert.
Der Bestellservice weiß nicht mehr, welche
Klasse die Kundenverwaltung konkret
implementiert. Natürlich muss er noch die
Schnittstelle kennen, aber mehr nicht.
Dadurch werden die Abhängigkeiten der
einzelnen Objekte reduziert. Ohne DI können
die Objekte zum Beispiel Factories nutschwerpunkt
der autor
DI UND AOP:
EINE BILANZ
„Dependency Injection” (DI) und Aspektorientierte Programmierung (AOP) sind seit Jahren
wesentliche Grundlage für Enterprise-Java-Anwendungen im Java-EE- und Spring-Umfeld. Es ist
an der Zeit, Bilanz zu ziehen, den bisherigen Erfolg in der Praxis und die Vorteile dieser Ansätze
darzustellen und einen Blick in die Zukunft beider Technologien zu wagen.
Normalerweise muss jedes Objekt in einem
System sich die anderen Objekte, deren
Methoden es aufrufen will, zusammensuchen.
Bei Dependency Injection (DI) werden
die Objekte von außen zugewiesen,
also, metaphorisch gesprochen, „injiziert”.
Neben der Zuweisung der abhängigen
Objekte werden diese Objekte meistens
auch erzeugt. Daher gehört DI zur
Kategorie der Ent wurfs muster, die sich um
das Erzeugen von Objekten kümmern, wie
z. B. Factory Method, Singleton oder
Abstract Factory (vgl. [Gam94]). Ähnlich
wie DI beschreiben diese Patterns nicht nur,
wie die Objekte erzeugt werden, sondern
auch, wie auf sie zugegriffen werden kann.
So gibt es beim Singleton meistens eine
Methode, die Zugriff auf die einzige
Instanz gewährt. Im Extremfall muss das
Objekt noch nicht einmal erzeugt werden,
sondern es kann bereits vorhanden sein.
DI hat hier aber eine andere Vorgehens -
weise als Singleton oder Factory Method
entsprechend der Inversion of Control: Der
eigene Code sucht sich keine Objekte
zusammen und erzeugt auch keine, sondern
sie werden von außen in den Code injiziert.
Nehmen wir als Beispiel einen Service für
die Verarbeitung von Bestellungen: Dieser
bekommt abhängige Objekte, wie z. B. die
Kundenverwaltung, „injiziert”. Konkret:
Eine Set-Methode wird aufgerufen oder der
Service wird dem Konstruktor als Para -
meter übergeben. Um dies zu erreichen,
kann der Entwickler selbst Code schreiben
– dieser wird jedoch schnell unübersichtlich,
sodass sich in der Praxis DI-Container
wie Spring oder Java EE durchgesetzt
haben.
zen, um Abhängigkeiten aufzulösen. Ins -
besondere dieses Vorgehen führt zu
Problemen in der Architektur: Jedes Objekt
nutzt die Factory, die wiederum jedes
Objekt erzeugen kann (siehe Abbildung 1).
Also hängt jedes Objekt über die Factory
von jedem anderen Objekt im System ab.
Möglichst wenige Abhängigkeiten sind
aber Voraussetzung für die leichte Änderbarkeit
von Software. Mit DI hängt jedes
Objekt nur von den genutzten Schnittstel -
len ab. Die Implementierung der Schnitt -
stelle ist nur dem DI-Container bekannt, zu
dem die Objekte aber keine Abhängigkeit
haben. (siehe Abbildung 2)
Das Testen wird vereinfacht. Dem
Bestell service kann sehr einfach eine
Kundenverwaltung injiziert werden, die
immer einen bestimmten Kunden zurück -
gibt, der zum Testen eines bestimmten
Szenarios nützlich ist. Dieser Ansatz ist für
Unit-Tests sinnvoll. Dabei wird eine einzelne
Klasse getestet und alle abhängigen
Objekte werden durch entsprechende einfachere
Versionen (so genannte Mocks oder
Stubs) ersetzt, die entsprechende konstante
Testdaten zurückliefern. Durch DI kann
man solche Mocks oder Stubs sehr einfach
Eberhard Wolff
(E-Mail: eberhard.wolff@adesso.de)
arbeitet als Architektur- und Technologie-Manager
für die adesso AG in Berlin. Er wurde von Oracle in
die Gruppe der Java-Champions aufgenommen, ist
Autor einiger Fachbücher und spricht regelmäßiger
auf verschiedenen Konferenzen.
injizieren: Man erzeugt das zu testende
Objekt, ohne den sonst üblichen DI-
Mecha nismus zu nutzen. Dann injiziert
man die entsprechenden Mocks oder Stubs.
Oft wird die Konfigurierbarkeit der
Kompo nenten als weiterer Vorteil von DI
übersehen. Neben abhängigen Objekten
wie der Kundenverwaltung können für den
Bestellservice auch Einstellungen wie der
Mindestbestellwert durch DI konfiguriert
werden. Bei Spring beispielsweise können
Einstellungen aus Properties-Dateien oder
System-Properties genutzt werden und
natürlich ist der Mechanismus auch
erweiterbar, sodass Einstellungen aus praktisch
jeder Quelle ausgelesen werden können.
Das ist von Vorteil, weil so Fehler –
wie nicht vorhandene Konfigurations -
einstellungen oder Konfigurationsdateien –
durch den DI-Container behandelt werden.
Das reduziert den rein technischen
Infrastruktur-Code in den Anwendungen.
Auf den ersten Blick ist DI eine Erfolgs -
geschichte: Ursprünglich in Spring und
Abb. 1: Ohne DI nutzen Services häufig Factories, um Referenzen auf andere Services
zu erzeugen. So entsteht eine Struktur, in der jeder Service die Factory kennt und die
Factory dann jeden Service. Letztendlich hängt das gesamte System voneinander ab,
was Wiederverwendbarkeit behindert und ein Zeichen für eine schlechte Architektur ist.
24 25

schwerpunkt
Abb. 2: Mit DI werden die Services durch den DI-Container erzeugt. Dadurch haben
sie weniger Abhängigkeiten und können leicht in einem anderen Kontext eingesetzt
werden oder für Tests mit anderen Abhängigkeiten versehen werden.
anderen Projekten, wie z. B. „PicoCon -
tainer” (vgl. [Pic]), implementiert, hat es
über EJB 3.0, JSR 299 (CDI) und JSR 330
Einzug in Java EE gefunden und mittlerweile
kommt keine Java-EE-Anwendung
mehr ohne diesen Ansatz aus. Dadurch
sollte sich zumindest die Strukturver bes -
serung tatsächlich auch in den meisten
Projekten manifestiert haben. Bei den anderen
beiden Punkten ist ein solcher Opti -
mismus nicht angebracht:
DI vereinfacht, wie bereits dargestellt,
Unit-Tests. Neben diesen Tests bieten DI-
Container wie Spring oder EJB 3.1 als
Alternative die Flexibilität, auch außerhalb
eines Applikationsservers komplexe Infra -
strukturen zu starten. Dort können die echten
Implementierungen des Kundenservice
mit allen abhängigen Objekten ablaufen,
um damit Tests durchzuführen. Diese Tests
decken Fehler im Zusammenspiel der
Komponenten auf, zählen also zu den
Integrationstests. Vorteil der DI bei
Integrationstests ist die Flexi bilität, den
Code in unterschiedlichen Umgebungen
laufen zu lassen, also auch außerhalb eines
Applikationsservers. Die zunehmende
Popularität von Tools wie „Arquilian” (vgl.
[JBo-a]) zeigt aber, dass Tests in
Applikationsservern zunehmend genutzt
werden. Die Vorteile von DI werden also
nur teilweise realisiert.
Die Konfiguration von Objekten ist leider
nicht bei allen DI-Containern gegeben.
Abb. 3: Mit AOP wird die Logik für die Behandlung der Transaktionen zentral implementiert
und dann an die passenden Stellen in der Geschäftslogik integriert.
Viele Projekte laden immer noch ihre
Konfigurationen selbst – mit manchmal
erheblichen Aufwand und nicht immer fehlerfrei.
Hier werden die Möglichkeiten der
DI-Lösungen immer noch zu wenig
genutzt.
Lange wurde gegen DI auch ins Feld
geführt, dass DI „Programmierung in
XML” sei. Durch die Möglichkeit zur
Nutzung von Java-Annotationen hat sich
dieses Problem mittlerweile erledigt. Aber
die Annotation haben auch Nachteile:
Änderungen an der Konfiguration können
oft nur durch Änderungen im Programm -
code erreicht werden. Das bedeutet auch
ein erneutes Kompilieren und Installieren
der Anwendung. Bei XML reichen eine
Änderung an einer Konfigurationsdatei
und ein Neustart. Dadurch sind die
Systeme mit XML flexibler anpassbar.
Wie sieht die Nutzung von DI in neuen
Sprachen aus? Für DI in Scala wird das
Cake Pattern (vgl. [Ode08]) empfohlen.
Dieses beschreibt die Umsetzung von DI in
Scala mit bestimmten Codestrukturen.
Beim Scala-Framework „Lift” sind die
Konfiguration und die benötigten
Abhängigkeiten der Objekte vollständig im
Code implementiert. Dieser Ansatz benötigt
sehr viel (siehe oben). Trotz der
Unterstützung von DI in Lift nannte der
Entwickler des Frameworks Dave Pollack
den größten Teil von DI einen „load of horse
poop” (vgl. [Osd]). Vielleicht baut Lift
deswegen nicht auf den Erfahrungen der
etablierten DI-Frameworks auf. Zusam -
men fassend kann man sagen, dass sich DI
mittlerweile in den Frameworks und in der
Infrastruktur etabliert hat, auch wenn nicht
der volle Wert dieser Ansätze genutzt wird.
Aspektorientierte
Programmierung
Ideen zur Aspektorientierten Program -
mierung (AOP) lassen sich bis in die 1990er
Jahre zurückverfolgen. Der Aspekt wird in
den eigentlichen Code „eingewebt”, um
dadurch so genannte Cross Cutting
Concerns zentral an einer Stelle zu implementieren
(siehe Abbildung 3), statt dies
ständig im Code zu tun (siehe Abbildung 4).
Eine zentrale Implementierung von einigen
speziellen Cross Cutting Concern – wie
Sicherheit und Transaktionen in Enterprise-
Anwendungen – wurde bereits in EJB 1.0
angeboten. EJB enthielt damals aber kein
AOP-System, mit dem ein Entwickler ähnliche
Erweiterungen implementieren könnte.
Um eine solche Basis zu schaffen, wurde
1/2012

schwerpunkt
Abb. 4: Ohne AOP muss in jedem
Service in jeder Methode Code – zum
Beispiel für die Behandlung von
Transaktionen – geschrieben werden.
AOP plötzlich interessant und es entstanden
Projekte wie das mäßig erfolgreiche JBoss
AOP (vgl. [JBo-b]) oder Spring mit der AOP-
Unterstützung. Spring AOP führte später
eine Kompatibilität mit AspectJ ein.
Dadurch hatten Entwickler ein sehr
mächtiges Werkzeug, um selbst Erwei -
terungen analog zu Transaktionen und
Sicherheit zu implementieren. Spring bietet
auch einige Aspekte an, die über
Transaktionen und Sicherheit hinaus
gehen. Aber AOP hatte dann irgendwann
den Ruf, komplex zu sein, vielleicht, weil
der Entwickler eine neue Sprache für die
Definition der Stellen im Code lernen muss -
te, an denen die Aspekte ansetzen sollen:
die Pointcut Expressions. Ein typischer
Entwickler nutzt diese Sprache nicht sehr
häufig, was das Erlernen nicht erleichtert.
Eine andere Befürchtung ist oft, dass der
Code an irgendwelchen Stellen erweitert
wird und so die Entwickler den Überblick
verlieren, was wo passiert. Wenn aber technische
Dienste, wie die Behandlung von
Exceptions durch AOP, getrennt von der
Hauptlogik implementiert werden, sind die
Aufgaben klar getrennt – wie das bei anderen
technischen Services auch der Fall ist.
Durch die konsequente Nutzung von
AOP können also viele Anwendungen vereinfacht
und viele technische Elemente zentral
implementiert werden. Diese Möglich -
keiten werden bei Spring leider nur selten
genutzt. In der Java-EE-Welt hat sich inzwischen
ein Ansatz etabliert, in dem nur
Interceptoren implementiert werden und
keine vollständige Sprache für Pointcuts
wie in der Spring/AspectJ-Welt.
Noch ein Blick auf neuere Sprache: Scala
unterstützt AOP gar nicht. Es ist allerdings
möglich, einzelne Methoden mit Trans -
aktionen oder Sicherheitsabfragen zu versehen.
Dafür nutzt man Funktionen, denen
man die ursprüngliche Methode übergibt.
Die Funktion führt dann vor und nach der
Methode Logik für Transaktionen oder
Sicherheit aus. Dazu nutzt man das Scala-
Literatur & Links
Feature der Higher Order Functions. Das
sind Funktionen, die selber Funktionen bzw.
Methoden als Parameter akzeptieren. Mit
Scala ist es aber nicht möglich, alle
Methoden einer Klasse oder gar aller Klas -
sen mit einer bestimmten Annotation mit
solcher Funktionalität auszustatten. Das ist
erstaunlich, denn ein solches Feature ist für
Enterprise-Anwendungen sehr hilfreich. Bei
dynamischen Sprachen wie Groovy sind im
Gegensatz zu Scala ähnliche Features durch
Meta-Progamming elegant implementierbar.
Fazit
Bei AOP nutzt Java EE einfachere, aber
auch weit weniger mächtige Ansätze. Die
vollständige Mächtigkeit von AOP wird
nur in wenigen Projekten realisiert. Bei DI
ist die Situation besser, aber sicher gibt es
auch dort Optimierungspotenzial. Haupt -
problem ist, dass die Nutzungsmöglich -
keiten von DI und AOP vielen Entwicklern
nicht vollständig bekannt sind. Diese
Werkzeuge sind recht mächtig, sodass sich
eine intensive Auseinandersetzung auf
jeden Fall lohnt. Schade ist, dass die
Entwickler neuer Technologien nicht
immer auf den Erfahrungen mit dem
Einsatz der vorhandenen Frameworks aufbauen.
■
[Gam94] E. Gamma, R. Helm, R.E. Johnson, Design Patterns. Elements of Reusable Object-
Oriented Software, Addison-Wesley 1994
[JBo-a] JBoss, Arquillian, siehe: http://www.jboss.org/arquillian
[JBo-b] JBoss, AOP, siehe: http://www.jboss.org/jbossaop
[Ode08] Martin Odersky, Lex Spoon, Bill V.: Programming in Scala, artima Press, 2008
[Osd] Osdir.com, Liftweb, siehe: http://osdir.com/ml/liftweb/2011-07/msg00048.html
[Pic] PicoContainer, siehe: http://picocontainer.org/
26 27

ausblick auf die
die autorin
mehr zum thema:
www.stickyminds.com
SECHS VERHALTENSWEISEN …
… DIE MITARBEITER EINES
AGILEN TEAMS BESITZEN SOLLTEN
Wenn man mit der Bildung eines agilen Teams beauftragt wird, sollte man zunächst überlegen,
was ein agiles Team von einem nicht-agilen unterscheidet. In diesem Artikel stelle ich sechs
Verhaltensweisen vor, die Bewerber für ein erfolgreiches agiles Team besitzen sollten.
Johanna Rothman
(E-Mail: jr@jrothman.com)
hilft Firmen dabei, das Management ihrer
Produktentwicklung zu verbessern. Sie ist Autorin
zahlreicher Bücher und gilt als zentrale Figur der
agilen Bewegung.
Unterscheiden sich Mitglieder agiler Teams
von Personen in anderen Teams? Ja und
nein. Ja, weil einige der Verhaltensweisen,
die wir bei agilen Teams beobachten,
betonter sind als die Verhaltensweisen in
nicht-agilen Teams. Und nein, weil wir über
Menschen reden.
Erfolgreiche Mitglieder agiler Teams zeigen
bestimmte Verhaltensweisen häufiger
als Teammitglieder von nicht-agilen
Projekten, weil Agilität diese Verhaltens -
weisen voraussetzt, um ein erfolgreiches
Team und Produkt zu erhalten. Wenn Sie
damit beauftragt werden, ein agiles Team
zu bilden, nach welchen Eigenschaften sollten
Sie dann suchen? Im Folgenden
beschreibe ich sechs wesentliche Verhal -
tens weisen, über die Personen in erfolgreichen
agilen Teams verfügen sollten. Ich
habe außerdem einige Interview-Fragen
eingefügt, mit denen Sie herausfinden können,
ob ein Bewerber für ein agiles Team
die notwendigen Voraussetzungen erfüllt.
1. Menschen,
die zusammenarbeiten
Menschen, die zusammenarbeiten können,
also mit Schulterschluss kollaborieren, sind
viel nützlicher als solche, die allein arbeiten
müssen. Aber was bedeutet es, richtig
zusammenzuarbeiten?
Das erste, was man bei agilen Teams beobachten
kann, ist die Tatsache, dass die
Mitarbeiter gemeinsam an Features arbeiten.
In nicht-agilen Teams ist es üblich, dass die
Mitglieder Features oder Vorausset zungen
übernehmen und allein daran arbeiten – in
einem gut funktionierenden agilen Team hingegen
nicht. Hier arbeiten mehrere
Entwickler und ein bis zwei Tester zusammen
und stellen sicher, dass sie als Team eine
„Geschichte” vollständig abschließen. Man
kann beobachten, dass mehrere Tester
zusammenarbeiten, um Tests zu entwickeln,
oder (einer meiner Favoriten) Entwickler und
Tester arbeiten gemeinsam an der
Entwicklung des Testautomatisierungs-
Frameworks für das Projekt.
Das gesamte Team arbeitet zusammen,
um Features zu definieren, mit deren
Entwicklung zu beginnen und diese zu
beenden. Erfolgreiche agile Teams vermeiden
das Problem, viele Features zu beginnen,
sie aber am Ende des Entwick lungs -
schritts nicht zu beenden, denn sie wirken
zusammen und schließen die Features ab.
Eine Frage, die man einem Bewerber stellen
kann, ist in diesem Zusammenhang:
„Denken sie an ein zurück liegendes
Projekt. Geben Sie mir ein Beispiel für eine
Zeit, wo sie mit anderen zusammen arbeiten
mussten, um sicherzustellen, etwas
beenden zu können. Was passierte?”
2. Menschen, die um Hilfe bitten
Vielen Menschen fällt es nicht leicht, andere
um Hilfe zu bitten. In vielen
Unternehmen ist es nicht einmal erlaubt,
um Hilfe zu bitten. Aber Personen, die um
Hilfe bitten können, sind genau die, die wir
in einem agilen Team haben möchten.
Warum ist es so wichtig, um Hilfe bitten
zu können? Wir wissen alle etwas über das
Projekt, aber niemand von uns weiß alles,
was wir wissen müssen. Also müssen wir in
der Lage sein, um Hilfe zu bitten, und wir
müssen dies aus einer Position der Stärke
heraus tun, nicht der Schwäche. In einem
agilen Team ist es kein Problem, um Hilfe
zu bitten. Bei der Agilität wollen wir keine
Verzögerung dadurch erleiden, dass eine
Person fest steckt, bevor sie um Hilfe bittet.
Es ist wichtiger, dass das Team alle verein-
barten Features rechtzeitig ausliefert, als
dass einer als Held dasteht.
In diesem Zusammenhang können Sie
einem Bewerber zu seiner Fähigkeit, um
Hilfe zu bitten, die folgende Frage stellen:
„Denken Sie an Ihr letztes Projekt. Erzählen
Sie von einer Situation, in der Sie etwas nicht
verstanden haben. Was haben Sie getan?”
3. Menschen, die kleine
Schritte gehen und Feedback
bekommen wollen
Agilität besteht hauptsächlich aus Feedback.
Wir benutzen Entwicklungs schritte, um
etwas zu tun und Feedback zu bekommen.
Wir entwickeln schrittweise, sodass unsere
Kunden die Gelegenheit haben, ihr Feedback
zu unserer derzeitigen Arbeit abzugeben.
Eine Verhaltensweise, nach der man bei
einem Bewerber suchen möchte, ist die
Fähigkeit, kleine Schritte zu gehen und
Feedback zu erhalten – egal welche Arbeit
sie oder er ausgeführt hat. Menschen (egal
ob es sich um Entwickler, Tester, Autoren
oder andere handelt), die ein Feature
augenscheinlich perfekt beenden müssen,
bevor jemand anders es sieht, sind für ein
agiles Team nicht geeignet.
Fragen, die Sie hierzu stellen können,
sind: „Erzählen Sie mir, wie sie arbeiten
wollen. Denken Sie an das letzte Feature,
an dem Sie gearbeitet haben. Haben Sie
versucht, das Ganze zu vervollständigen,
bevor Sie um Feedback gesucht haben?”
Warten Sie auf die Antwort. Dann fragen
Sie: „Warum?” Vielleicht sagt der
Bewerber, er habe einmal versucht, Feed -
back zu erhalten. Oder er sagt, von ihm sei
erwartet worden, alles perfekt zu vervollständigen.
Nun können sie fragen: „Wenn
Sie außerhalb der Arbeit an ihrem Projekt
arbeiten, wie gehen Sie da vor?”
1/2012

ausblick auf die
4. Menschen, die bereit sind,
etwas „gut genug für den
Moment” zu machen
Menschen, die in der Lage sind, kleine
Schritte zu gehen und Feedback zu
bekommen, sind wahrscheinlich ebenso in
der Lage, etwas „gut genug für den
Moment” zu machen. Eines der Probleme
bei der Agilität ist, dass wir nicht genügend
Zeit haben, alles auf einmal perfekt zu
machen. Deshalb benutzen wir Zeitfenster.
Wir tun, was gerade benötigt wird, und
entscheiden auf Grundlage des Feedbacks,
ob oder wann wir darauf wieder zurück -
kommen.
Die Fähigkeit, etwas gerade gut genug zu
machen und darauf zurückzukommen, wenn
es mehr Nutzen für das Geschäft bringt, ist
kein übliches Verhalten. Man kann das bei
Testern sehen, die das absolut beste
Testsystem am Beginn eines Projekts haben
wollen. Man kann es auch bei Architekten
sehen, die die Architektur zu Beginn des
Projekts vollständig definieren wollen.
Eines der Probleme der Agilität besteht
darin, dass wir zu Beginn eines Projekts
nicht sagen können, was perfekt ist.
Manchmal können wir es nicht einmal in
der Mitte sagen. Also müssen wir es gut
genug für den Moment machen und später
darauf zurückkommen, wenn wir mehr
Nutzen daraus ziehen können, wenn wir
uns darauf konzentrieren.
Um sagen zu können, ob ein Bewerber
diese Fähigkeit besitzt, etwas gut genug für
den Moment zu machen und den perfekten
Abschluss auf später verschieben kann, fragen
Sie: „Erzählen Sie mir vom letzten Mal,
als Sie zu Beginn eines Projekts überhaupt
nichts wussten? Was haben Sie getan?”
5. Anpassungsfähige
Menschen
In agilen Projekten sind, wie in allen Arten
von Projekten, die Bedingungen nicht
immer perfekt. Beispielsweise kann es vorkommen,
dass wir keinen Teamraum
haben, dass es keine Kriterien für die
Auswahl von Features gibt oder dass wir
vielleicht nicht einmal in der Lage sind,
Hindernisse zu beseitigen. Und trotzdem
müssen wir die Arbeit fertig bekommen
Wir suchen nicht nach Heiligen. Wir
suchen nach Menschen, die sich an die
herrschenden Bedingungen anpassen können.
Wir wollen, dass die Mitarbeiter ihre
Arbeit tun, auch wenn die Bedingungen
unzureichend sind.
Aufgrund der Antwort, die Sie auf die
folgende Frage erhalten, werden Sie wissen,
ob Sie einen anpassungsfähigen Menschen
Warum es so wichtig ist, die richtigen Leute einzustellen
Interview mit Johanna Rothman.
■■? Sie haben ein bekanntes Buch über pragmatisches
Projektmanagement ge schrie ben und Sie favorisieren agile
Systeme. Was halten Sie vom klassischen PMI und seinem
Wert für den Software-Entwicklungsprozess?
■■! Das ursprüngliche PMBOK beinhaltete keine Vorgabe für
den Projektmanager bezüglich des zu verwendenden Lebens -
zyklus. Ich mochte das. Auch wenn ich vor Kurzem das
PMBOK falsch interpretiert haben sollte, macht es für den
Projekt manager immer noch keine strenge Vorgabe, welcher
Lebenszyklus zu verwenden ist. Auf der anderen Seite ist das
PMBOK sehr wasserfallartig ausgelegt, sodass man leicht im
klassischen Lebenszyklus-Denken verhaftet bleibt. Das
PMBOK leitet die Projektmanager nicht einmal an, über den
für sie geeigneten Lebenszyklus nachzudenken – und das ist
eine Schande. Die Wahl des Lebenszyklus, der auf die Risiken
deines Projekts und deines Teams am besten passt, ist die
schnellste und billigste Art, wie ein Projekt manager von Beginn
an die Projektrisiken managen kann. Also, warum nicht?
■■? In Ihrem OOP-Tutorial „Influence and Authority: Using
Your Personal Power to Get Things Done” legen Sie den
Schwer punkt auf die Menschen, nicht auf irgendeine
Managementdisziplin. Ist der Mensch der eigentliche kritische
Erfolgsfaktor in der Softwareentwicklung?
■■! Software ist eine menschenintensive Disziplin. Das ist der
Grund, warum es so wichtig ist, die richtigen Leute einzustellen
(das ist der Inhalt meines Vortrags) und zu wissen, wie
man mit Hilfe dieser Menschen seine Arbeit erledigt bekommt
(Inhalt meines Tutorials). Das gilt für Projektmanager,
Softwareentwickler, Tester, Produktmana ger, Marketingleute
und alle anderen gleichermaßen.
■■? Vor Kurzem waren Sie auf der AYE-Konferenz. Was war
Ihr Eindruck?
■■! Ich hat eine großartige Zeit – ich denke, alle Teilnehmer
hatten das. Bis jetzt haben wir von mehr als einem Dutzend
Leute Feedback bekommen. Wir haben Vorschläge für die
Zukunft bekommen, was immer gut ist. Aber die meisten
Kommentare waren in der Art wie: „Was für eine wundervolle
Umgebung, um zu lernen, und was für eine großartige
Gruppe von Teilnehmern!”
■■? Worauf freuen Sie sich am meisten auf der kommenden
OOP?
■■! Ich liebe es, neue Menschen zu treffen. Deshalb ist das ein
Punkt, auf den ich mich auf jeden Fall freue. Ich vermute, dass
es kulturelle Unterschiede zwischen dem gibt, was ich normalerweise
in US-Firmen sehe, und deutschen Firmen. Diesem
Unter schied möchte ich in meinem Tutorial auf den Grund
gehen. Wenn du solche kulturellen Probleme nicht beachtest,
kannst du sie auch nicht wirksam beeinflussen.
28 29

ausblick auf die oop 2012
vor sich haben: „Erzählen Sie mir von einer
Situation, in der Sie nicht die Bedingungen
vorgefunden haben, die Sie sich für Ihr Pro -
jekt gewünscht haben. Was haben Sie
getan?”
6. Menschen, die bereit sind,
außerhalb ihres Erfahrungsbereichs
zu arbeiten
Ein Zeichen für Anpassungsfähigkeit ist die
Bereitschaft eines Menschen, auch außerhalb
seines Erfahrungsbereichs zu arbeiten.
Ich schlage nicht vor, dass jemand etwas
tun soll, von dem er keine Ahnung hat –
z. B. sollte sich ein Entwickler nicht in einen
Vermarkter verwandeln (es sei denn, er
möchte es). Ich schlage aber vor, dass
jemand, der sich sehr gut mit Datenbanken
auskennt, auch versuchen sollte, sich ein
bisschen mit der GUI zu befassen. Wenn
jemand mit der Middleware vertraut ist,
würde er vielleicht auch gerne auf Be -
triebssystem-Ebene oder auf dem oberen
Level einer Anwendung arbeiten. Wenn
jemand die ganze Test-Karriere lang eine
For schungstesterin war, möchte sie vielleicht
ein wenig Skripting versuchen. Wenn
sie ein „Automatisierungs-Würstchen” ist
(also die arme Person, die immer wieder die
gleichen Tests durchführen muss), ist es
vielleicht an der Zeit, es mit ein wenig For -
schungstests zu versuchen.
Wir sehen diese Bereitschaft zur Arbeit
außerhalb des eigenen Erfahrungsbereichs
in agilen Teams, wenn Menschen zusam -
menarbeiten und sich um ein Feature drän-
Johanna Rothman
Increase Your Capacity and
Finish More Projects
O'Reilly 2009
250 Seiten (auf englisch)
32,00 €
ISBN 978-1-934356-29-6
geln. Menschen sind bereit, außerhalb ihres
Erfahrungsbereichs zu arbeiten, aber nicht
zu weit davon entfernt. Um etwas über diese
Fähigkeit zu erfahren, fragen Sie:
„Erzählen Sie mir von einer Situation, in
der Sie eine Arbeit übernommen haben, um
dem Team zu helfen. Wie war das?”
Ein Bewerber kann unter Umständen diese
Frage nicht beantworten. Sie können
dann einen Kontext vorgeben, wie z. B. den
Folgenden: „Wir arbeiten an Dingen, mit
denen wir vielleicht nicht vertraut sind, um
ein Feature für eine Iteration fertigzustellen.
Waren Sie jemals in dieser Situation?”
Wenn der Bewerber nicht ja sagt, müssen
Sie die Frage anders stellen. Zum Beispiel
hatte ich mit folgender Frage Erfolg:
„Erzählen Sie mir von einer Situation, in
der Sie etwas taten, was Ihrer Meinung
nach nicht zu Ihrer Jobbeschreibung
gehört. Was haben Sie getan?”
Zusammenfassung
Dies sind wahrscheinlich nicht die einzigen
Verhaltensweisen, die man für ein agiles
Team benötigt. Führen Sie auf jeden Fall
eine Jobanalyse durch, um zu sehen, wie
sich Ihr agiles Team von anderen unterscheidet.
Dann werden Sie die Art von
Bewerbern erkennen, die zu berücksichtigen
sind.
Aus dem Englischen von Elke Niedermair.
1/2012

ausblick auf die
der autor
mehr zum thema:
www.sigs-datacom.de/OOP2012/konferenz
FLOW IN LEAN, FLOW IM TEAM:
WAS LEAN MIT DEM PERSÖN-
LICHEN ERLEBEN ZU TUN HAT
Flow herrscht in der Arbeit, wenn Bedarf und Lieferfähigkeit gegeneinander ausbalanciert sind,
z. B. durch den Einsatz von Lean-Verfahren in der Produktentwicklung. Flow gibt es auch in der
Psyche, wenn vom Einzelnen soviel gefordert wird, wie er auch leisten kann. Im Flow-Zustand
entstehen die besten Ergebnisse, die Arbeit ist angenehm, man vergisst die Zeit. Dass man für
Flow im Sinne von „Lean Product Development” dasselbe Wort verwendet wie in der Psycholo -
gie, ist nach meiner Ansicht kein Zufall. In diesem Artikel geht es darum, die Beziehung zwischen
Flow in Lean und Flow in der Psyche herzustellen und zu erforschen.
Matthias Bohlen
(E-Mail: mbohlen@mbohlen.de)
ist unabhängiger Coach für effektive Produkt -
entwicklung. Teams und Manager arbeiten mit seiner
Hilfe bewusster, flüssiger und effektiver. Er ist
Mitglied des OBJEKTspektrum-Redaktionsteams.
Der Begriff Flow wurde von dem ungarischen
Psychologen Mihaly Csikszent -
mihalyi für einen bestimmten Zustand der
menschlichen Psyche verwendet (vgl.
[Csi08]). Er meint damit die optimale
Erfahrung der Wirklichkeit – ein Zustand,
der sich unter bestimmten Bedingungen
einstellt. Der Mensch im Flow-Zustand ist
in seiner ganzen Person gefordert. Seine
Aufmerksamkeit und die Aktivität, die er
gerade ausführt (z. B. entwickeln oder entwerfen),
sind eins miteinander. Das geht
nur mit klaren Zielen und einem zeitnahen
Feedback. Dadurch wird es ihm ermöglicht,
sich ganz auf das zu konzentrieren,
was er gerade tut. Er hat das Gefühl, das,
womit er sich beschäftigt, unter Kontrolle
zu haben. Schließlich wird die Aktivität zu
ihrem eigenen Ziel – Flow wird zur autotelischen
Erfahrung.
Produktentwicklung ist eine Tätigkeit,
die kreatives Problemlösen erfordert. Sie ist
nicht mit der Fertigung zu vergleichen, bei
der das gewünschte Endergebnis im
Vorhinein feststeht. Deshalb kann der Weg
zu diesem Ergebnis auch nicht im Voraus
beschrieben, sondern muss im Gegenteil
erst gefunden werden, während man ihn
geht. Dennoch hat Produktentwicklung ein
klares Ziel, nämlich das Finden dieser
guten und allseits akzeptierten Lösung: das
funktionierende Produkt.
Produktentwicklung fordert uns dazu
heraus, unsere gesamten Fähigkeiten einzusetzen.
Die einzelnen Aktivitäten führen zu
Zwischenzielen hin, z. B. eine Funktion, die
endlich so arbeitet, wie sie soll, eine Farbe,
die endlich so aussieht, wie sie soll, oder
eine Produktgestaltung, die den Benutzer
begeistert. Gleichzeitig gelten Regeln für
jede einzelne Aktivität, die man nicht ohne
die richtigen Fähigkeiten einhalten kann.
Das Produkt wird sich „weigern”, das zu
tun, was gefordert ist, wenn man nicht alle
Fähigkeiten einsetzt, um es dazu zu bringen.
Flow in der Psyche
Wenn eine Person alle ihre Fähigkeiten einsetzen
kann oder muss, um in der
Produktentwicklung zu einem Ziel zu
gelangen, dann wird sie durch die Aktivität
völlig aufgesogen. Als Architekt, Ent -
wickler, Designer oder Tester achtet man
nicht mehr auf sich selbst, auf den Stuhl,
auf dem man sitzt, auf die Computermaus,
die man in der Hand hält, auf die Umge -
bungs geräusche und alles andere. Wichtig
ist nur noch die Arbeit an dem aktuellen
Teil des Produkts, den man in Händen hält
oder auf dem Bildschirm vor sich sieht.
Es ergibt sich insgesamt eine Erfahrung,
die sonst von Tänzern, Musikern, Berg -
steigern, Schach- oder Go-Spielern, Mara -
thonläufern oder Börsenhändlern beschrie-
ben wird: Das ist Flow in der Psyche. Die
Aktivität wird so spontan, fast automatisch
ausgeführt, dass Person und Tat nicht mehr
getrennt, sondern eins miteinander sind.
Csikszentmihalyi 1 ), emeritierter Profes -
sor für Psychologie an der Universität von
Chicago, bezeichnet Flow auch als „die
optimale Erfahrung der Wirklichkeit”. Auf
Deutsch würde man sagen „Schaffens- oder
Tätigkeitsrausch”. Der deutsche Pädagoge
Kurt Hahn bezeichnete diesen Zustand als
„schöpferische Leidenschaft”. Maria Mon -
tes sori, italienische Ärztin und Reform -
päda gogin, beschrieb etwas ähnliches, das
sie „Polarisation der Aufmerksamkeit”
nannte.
Als Softwareentwickler sind wir vielleicht
geneigt, eine andere Definition zu
Rate zu ziehen. Sie stammt aus dem
1
) Er soll angeblich selbst gesagt haben, dass man seinen
Namen ausspricht wie „chicks sent me high”.
www.pixelio.de – Heike
30 31

ausblick auf die oop 2012
Wörterbuch für Hacker von Eric S. Ray -
mond. Er nennt den Zustand, der hier
gemeint ist, hack mode und beschreibt ihn
als „einen Zen-artigen Zustand mit totalem
Fokus auf das [zu lösende] Problem, der
erreicht werden kann, indem man hackt”.
Für einen außenstehenden Beobachter, der
diesen Zustand nicht kennt, kann das sehr
seltsam aussehen. Wenn beispielsweise
jemand an Ihrer Tür erscheint, und Sie sich
gerade im hack mode befinden, so ist es
nach der Hacker-Etikette völlig okay, wenn
Sie Ihre Hand hochhalten und den Blick
nicht vom Bildschirm nehmen, um einer
Unterbrechung des hack mode vorzubeugen.
Dann können Sie unter Umständen
noch lange lesen, tippen, mit der Maus
klicken, bis Sie Ihre Hand senken. Der
Mensch an der Tür kann sich aussuchen,
ob er so lange warten oder inzwischen
wortlos gehen will. Das Verständnis dahinter
ist, dass Sie im hack mode eine Menge
an zerbrechlichem Zustand halten – wie bei
einem zustandsbehafteten Server, der seinen
Kontext nicht wechseln möchte, bis er
den Zustand gesichert und einen guten
Punkt zum Pausieren gefunden hat.
Csikszentmihalyi erforschte, wie der
Flow-Zustand bei verschiedenen Menschen
aussieht (vgl. [Csi08]). Er führte Befragun -
gen in unterschiedlichen sozialen Gruppen
und in unterschiedlichen Berufen durch. Zu
seinem Erstaunen fand er heraus, dass
Menschen über dieselben acht Grundeigen -
schaften berichteten – unabhängig von
ihrer Kultur, dem Stand der Moderni -
sierung, der sozialen Klasse sowie Alter
und Geschlecht:
■ G1: Das Erlebnis entsteht, wenn wir
mit Aufgaben konfrontiert sind, die wir
auch vollenden können.
■ G2: Wir müssen uns auf das, was wir
tun, konzentrieren können.
■ G3: Die Aufgabe hat klare Ziele.
■ G4: Die Aufgabe bringt uns sofortiges
Feedback.
■ G5:Man agiert in tiefem und gleichzeitig
anstrengungslosem Beteiligtsein, das
die Sorgen und Frustrationen des All -
tags aus dem Bewusstsein verdrängt.
■ G6: Das Erleben erlaubt es den Men -
schen, ein Gefühl von Kontrolle über
ihr Tun zu haben.
■ G7: Interesse am eigenen Selbst (und
zugehörige Bedenken) verschwinden,
doch nach Ende der Flow-Erfahrung
bildet sich das Selbstgefühl paradoxerweise
stärker heraus als je zuvor.
■ G8: Das Zeitgefühl verändert sich:
von Matthias Bohlen
gibt
es auch
bei
Flow in der Produktentwicklung
Produktentwicklung planen,
durchführen und genießen!
28.
– 29.
Feb.
2012, Köln
1.590,-
€ zzgl. MwSt.
Kontakt:
SIGS DATACOM ACOM GmbH
Anja Keß,
Tel. +49 (0)2241/2341-20141-201
Email:
anja.kesssigs-datacom.de
www.sigs-datacom.de
de
Stunden vergehen in Minuten und
Minuten können sich ausdehnen wie
Stunden.
G1 bis G4 sind Bedingungen, die gelten
müssen, damit Flow entstehen kann. G5 bis
G8 sind Beobachtungen, die man regelmäßig
machen kann, wenn Flow entsteht.
Lean Software Development
Mary und Tom Poppendieck haben Er -
kennt nisse aus dem Lean Manufacturing in
die Softwareentwicklung übertragen und
den Begriff Lean Software Development
geprägt (vgl. [Pop03]). In der Gedanken -
welt von Lean liegt der Fokus auf dem
Wert, der für den Kunden erzeugt wird. Ein
grundlegendes Lean-Prinzip lautet: „Füge
nichts außer Wert hinzu”, auch bekannt als
„Eliminiere Verschwendung”. Verschwen -
dung erkennen wir in der Softwareent -
wicklung hinter verschiedenen Masken: zu
viele Features, die keiner benutzt, zu viele
im voraus erhobene Anforderungen, die
Suche nach Personen, die einem Entwickler
eine fehlende Information geben können,
Übergaben von einem Spezialisten zum
anderen und vieles mehr.
Lean hat es sich deshalb auf die Fahne
geschrieben, immer auf die Menschen zu
achten, die den Wert produzieren. Wert,
das ist das lauffähige System und angemessene
Dokumentation, um das System warten
und betreiben zu können. Den
Menschen, die diesen Wert schaffen, gibt
man Ressourcen, Informationen, die Ho -
heit über ihren eigenen Prozess, Entschei -
dungsgewalt, so weit es sie betrifft, und
Energie, so viel sie brauchen. Man stellt
Teams zusammen, die ihren eigenen
Prozess leben und die in sich geschlossene
Probleme lösen – und nicht solche, die
jemand anders für sie in Einzelaufgaben
aufgeteilt hat. Nicht stumpfes Coding ist
Trumpf, sondern intelligentes Engineering.
Flow in Lean
In Lean gibt es eine Grundidee, die man dort
ebenfalls Flow nennt. Wenn man als Ziel
hat, nichts anderes zu tun, außer Wert hinzuzufügen,
sollte man versuchen, diesen
Wert in einem Fluss zu erschaffen, der so
schnell fließt, wie es geht. Es beginnt mit den
Produktideen, die reichlich entstehen und
gar nicht so schnell abgearbeitet werden
können. Hier ist der Ansatz, die Ideen nur
grob zu beschreiben, um nicht zu viel
Zwischenergebnisse auf Halde zu legen. Die
Ideen, die tatsächlich in die Ent wicklung
gehen, untersucht man „just in time”, möglichst
spät und trotzdem rechtzeitig.
Aus den Ideen werden Anforderungen an
das zukünftige System, beispielsweise in
Form von Benutzergeschichten und
Qualitätseigenschaften. Auch von diesen
Anforderungen spezifiziert man nur so viele,
wie sofort in die Software- und System -
architektur einfließen können – wiederum
keine Produktion auf Halde, sondern ein
gleichmäßiger Fluss in die nächsten
Prozessschritte. Und es geht so weiter: Nur
so viel Architektur entwerfen wie nötig,
nur so viel Code schreiben, wie man auch
testen kann, nur so viel testen, wie man in
Betrieb nehmen kann (und natürlich nur
soviel in Betrieb nehmen, wie der Kunde
bezahlen kann).
Flow in Lean bedeutet: Die Arbeit muss
fließen. Flow bedeutet nicht, dass die
Arbeiter ausgelastet sein müssen. Überhaupt
verlagert sich der Blick des
Managements: Er richtet sich auf die einzelnen
Arbeitspakete, nicht mehr so sehr
auf die Personen, die die Arbeit tun, nicht
mehr auf das Geld, das die Personen
kosten, und nicht mehr auf deren Aus -
lastung. Wäre die Produktentwicklung eine
Autobahn, würde man es so zusammenfassen:
Es kommt darauf an, eine möglichst
gleichmäßig hohe Zahl von Autos pro
Stunde durchzubringen, und nicht darauf,
die Autobahn mit Autos zuzupflastern.
Flow in Lean ist kostengünstig
Warum sollte das Management sich für
Flow interessieren? Weil Flow die Pro -
duktentwicklung sowohl kostengünstig als
auch angenehm gestaltet. Wenn Sie in der
Produktentwicklung ohne Flow arbeiten,
1/2012

ausblick auf die
Wie Flow in Lean entsteht
Flow entsteht dann, wenn Nachfrage und
Durchsatz gegeneinander ausbalanciert sind.
Nachfrage ist das, was vom Kunden gefordert
wird. Durchsatz ist das, was die Teams
an Ergebnissen pro Zeiteinheit erzeugen
können. Gibt man den Teams das Recht,
sich Nachfrage auf den Schreibtisch zu ziesind
Ihre Mitarbeiter traditionell hoch ausgelastet.
Die To-Do-Listen, die Backlogs
und Taskboards, die Projektpläne – was
immer auch zur Planung und Verfolgung
benutzt wird – es ist voll von noch nicht
getaner Arbeit. Das kollektive Gedächtnis
der Teams ist mit der Zukunft beschäftigt,
nicht mit der Gegenwart. Überall bilden
sich Warteschlangen, Termine können nicht
gehalten werden und man fragt sich:
Warum geht es bei uns nicht vorwärts?
Lange Warteschlangen mit gestapelter
Arbeit kosten viel Geld. Ein Feature, das in
das lauffähige System eingebaut werden
soll, kann erst Geld einbringen, wenn der
erste Kunde dafür bezahlt. Je später man
mit einem Feature (oder Feature-Paket) auf
den Markt kommt, desto eher kann die
Konkurrenz den Markt besetzen. Die Zeit,
die die Entwickler für ein Feature benötigen,
hängt nicht nur davon ab, wie lange
sie dafür arbeiten, sondern ebenso stark
davon, wie viele Features sie noch gleichzeitig
entwickeln: je mehr davon gleichzeitig,
desto länger dauert jedes einzelne
Feature. Führt man Flow ein, wird diese
Menge klein, die Warteschlangen verkürzen
sich und man investiert die Arbeitszeit
nur dort, wo es sich lohnt.
Die Kosten für die Zeit, die die Arbeit in
Warteschlangen verbringt, sind kaufmännisch
wie Abschreibungskosten auf Inventar
zu behandeln, über die in der Software -
entwicklung selten nachgedacht wird.
Hier ein Beispiel aus [Boh10]: Man
schreibt ein Anforderungsdokument und
investiert dafür 60.000 Euro. Dann ist das
Dokument ein Inventar im Wert von
60.000 Euro. Das Wissen über die Inhalte
und Zusammenhänge des Dokuments
beginnt zu verfallen, weil Projektbeteiligte
Menschen sind, die im Laufe der Zeit
Dinge vergessen. Es dauert etwa drei
Monate, bis keiner mehr weiß, was mit
dem Dokument gemeint war. Danach hat
das Dokument also einen Wert von 0 Euro.
Wir kommen bei einem Wertverlust von
60.000 Euro in drei Monaten auf eine
Abschreibung von 20.000 Euro pro
Monat. Demnach trägt dieses Dokument
ab Fertigstellung mit knapp 1.000 Euro pro
Arbeitstag zu den operativen Ausgaben des
Projekts bei. Es wäre also gut, wenn die
Teams das Dokument vor Ablauf des
Mindesthaltbarkeitsdatums in lauffähigen
Code verwandelten.
Die Lean-Alternative dazu sieht so aus:
Man investiert in die Anforderungen erst
einmal nur 10.000 Euro. Danach entstehen
Kosten von 10.000 Euro für Code und
20.000 Euro für Tests. Schließlich bringt
man das Ganze für 20.000 Euro in
Produktion. Die Kunden zahlen für die
neuen Features 75.000 Euro Lizenz -
gebühren. Damit ergibt sich folgender
Return on Investment: (Einnahmen-Ausga -
ben)/Anfangsinvestitionen = (75.000-
60.000)/10.000 = 150 %. Anstatt ein
Dokument in einer Warteschlange verderben
zu lassen, führt man es lean schnell und
in kleinen Schritten der Realisierung zu,
ehe man in neues Inventar (z. B. weitere
Anforderungen) investiert.
Das Management müsste an Flow höchst
interessiert sein, weil es Kosten spart und
Wert schnell realisiert.
Flow in der Psyche macht
Arbeit angenehm
In Deutschland fehlen Fachkräfte, heißt es.
Firmen beginnen zu verstehen, dass sie auf
das Umfeld achten müssen, das sie ihren
Mitarbeitern bieten, wenn sie möchten,
dass diese über lange Zeit zufrieden bei
ihnen arbeiten. In einer Firma, in der es beide
Arten von Flow gibt, ist die Situation für
den einzelnen Mitarbeiter optimal. Er ist
genau im richtigen Maße gefordert, mit
interessanten Problemstellungen konfrontiert,
ohne jedoch den Überblick zu verlieren.
Die Teams sind autonom, weil sie
selbst entscheiden können, wie viel Arbeit
sie sich auf die Schreibtische ziehen. Sie
können zu Meistern ihres Fachs werden,
wenn die Firmenkultur von ihnen verlangt,
sich ständig zu verbessern. Und: Wenn die
Führungskräfte ihren Job gut machen,
erkennen die Mitarbeiter, was der Sinn und
Zweck ihrer Arbeit ist, welche Strategie
damit verfolgt wird und wo der Nutzen für
den Kunden liegt. Autonomie und
Meisterschaft, gerichtet auf Sinn und
Zweck – das sind die besten Zutaten für
eine intrinsische, also eine von innen kommende
Motivation der Mitarbeiter.
Wenn solche Bedingungen gegeben sind,
werden gute Leute dazu tendieren, in dieser
Firma zu bleiben. Es wird sich eine Kultur
von vertrauensvoller Zusammenarbeit entwickeln.
Man sagt auch: Es entsteht „soziales
Kapital”.
hen (Pull-Prinzip) und durch Ent wick lung in
Durchsatz zu verwandeln, stellt sich dieses
günstige Gleichgewicht ein. Es wird dann
niemals etwas analysiert, was nicht auch
gleich entwickelt werden kann. Es wird
nichts entwickelt, was nicht getestet werden
kann. Es wird nur so viel getestet, wie auch
in Produktion genommen werden kann.
Jeder Prozessschritt wird nur durchgeführt,
wenn auch ein Abnehmer für das Ergebnis
frei ist. Der letzte solche Abnehmer in der
Kette ist der Kunde.
Um Flow im Sinne von Lean erreichen zu
können, gibt es verschiedene Methoden.
Eine davon ist Kanban, wie es von David
Anderson definiert wurde (vgl. [And10]).
In OBJEKTspektrum wurde schon häufig
über Kanban berichtet (z. B. in Ausgabe
2/2010), sodass es ausreicht, wenn wir hier
noch einmal die fünf Kerneigenschaften
von Kanban in Erinnerung rufen:
■ Visualisieren Sie den Workflow: An der
Wand hängt man eine Tafel auf, die in
Spalten eingeteilt ist (siehe Abbildung 1).
Jede Spalte repräsentiert einen Work -
flow-Zustand. In den Spalten bewegen
sich Klebezettel, auf denen die
Bezeichnung eines Arbeits pakets steht.
So ist jederzeit sichtbar, welches Arbeits -
paket in welchem Zustand ist.
■ Limitieren Sie Work-in-Progress: Pro
Spalte oder Zeile auf der Tafel dürfen
sich nur so viele Arbeitspakete befinden,
wie das Team auch sinnvoll bearbeiten
kann.
■ Messen Sie den Flow und optimieren sie
ihn: Wann immer die Arbeit stockt
(erkennbar an einem Zettel, der sich
nicht bewegt), finden Sie die Ursache
heraus und beseitigen Sie diese.
■ Machen Sie Prozessregeln explizit:
Werden Sie sich klar, warum Sie so
arbeiten, wie Sie arbeiten.
■ Verwenden Sie Modelle, um Verbes -
serungs möglichkeiten zu erkennen: Bei -
spiele hierfür sind systemisches Denken
(vgl. [Sen10]), Theory of Constraints
(vgl. [Gol90]) oder Demings Ideen (vgl.
[Dem00]).
Flow im Sinne von Lean können Sie also
mit Hilfe von Kanban entstehen lassen.
Kommen wir jetzt zu Flow in der Psyche.
Wie Flow in der
Organisation entsteht
Flow in der Organisation zu erzeugen, ist
Aufgabe des Managements. Manager müs-
32 33

ausblick auf die oop 2012
Mission, Zweck und Ziele
Für die Mitarbeiter ist es schwer, sich auf
die Ziele der Firma zu konzentrieren, wenn
sie diese Ziele nicht verstehen oder sie missverstehen.
Für alle – angefangen beim
CEO, über das mittlere Management, bis
hin zu den Teammitgliedern – sollte klar
sein:
■ Warum tun wir diesen Job?
■ Warum führen wir diesen Feldzug?
■ Was ist der Zweck dieses Unterneh -
mens?
■ Was ist mein spezieller Beitrag zu diesem
Zweck?
Abb. 1: Von Flow in Lean zu Flow in der Psyche.
sen sich in erster Linie darauf konzentrieren,
eine Organisation zu bauen. Diese
Organisation kann dann Produkte bauen,
die den Markt überraschen und weiteres
Wachstum der Organisation ermöglichen.
Die beste Strategie dafür ist es, Bedin -
gungen zu schaffen und eine Atmosphäre
herzustellen, in der Flow in den Menschen
entstehen kann. Realistisch betrachtet hat
ein Mensch – in dem Fall der Manager –
keinen direkten Einfluss darauf, ob ein
anderer Mensch (z. B. ein Teammitglied) in
den Flow kommt. Er kann jedoch die
Umgebung so gestalten, dass die Wahr -
schein lichkeit dafür hoch wird.
Es fängt mit einem Ort und einer Zeit an.
Der Ort, an dem die Menschen arbeiten,
sollte angenehm und besonders gestaltet
sein. Saubere Räume, genügend Licht und
Luft, Sichtbarkeit der Teams untereinander,
Plätze zur Kommunikation (z. B. Espresso -
maschine), und Plätze zum Halten des
gemeinsamen Gedächtnisses (z. B. Kanban-
Tafeln) sind Grundbedingungen. Darüber
hinaus können ein Betriebskindergarten,
eine schöne Kantine oder Räume zum
Tischfußball-Spielen förderlich sein.
Natürlich kann man Software auch in
einer Geek-Wohngemeinschaft oder einer
Garage entwickeln (nicht selten haben erfolgreiche
Firmen so angefangen). Doch die
Erfahrung zeigt, dass Entwickler in solchen
Umgebungen nur vorübergehend wie eine
Larve überwintern. Für gewisse Zeit wird
Hacken wichtiger als Essen, Geschirr abwaschen
oder Freunde treffen. Flow wird im
Hack Mode erlebt. Dieser Zustand dauert
jedoch nicht ewig – Entwickler schlüpfen aus
der Hacker-Larve und wollen Profis werden,
der eine früher, der andere später.
Csikszentmihalyi hat in [Csi04] beschrieben,
welche Bedingungen nach diesem
Zeitpunkt geeignet sind, um den persönlichen
Flow in der Organisation zu ermöglichen
und zu fördern (siehe auch Abbil -
dung 2):
■
■
■
Klare Ziele: Jeder Mitarbeiter sollte
wissen, was die Mission der Organi -
sation und der Zweck des Produkts ist,
das entwickelt wird.
Gutes, zeitnahes Feedback: Mitar bei ter
sollten jederzeit erkennen können, ob
sie auf dem richtigen Weg sind.
Inkrementelle Herausforderungen: Das
steigert die Fähigkeiten der Mitarbeiter
und vermeidet Langeweile.
In manchen Organisationen kommt es vor,
dass sich noch nicht einmal der CEO oder
Vorstandsmitglieder die Mühe gemacht
haben, den Zweck der Firma näher zu definieren.
In diesem Fall liegt es in der
Verantwortung der darunter liegenden
Führungsebene, das auf den Tisch zu bringen
und mit den Vorgesetzten zu klären.
Geschäftsgrundlage und Kernwerte der
Firma müssen im Verhalten der Führung
sichtbar werden. Führen bedeutet, die
Aufmerksamkeit auf die Ziele zu lenken,
die zu verfolgen sind. Daher müssen
Führungskräfte stark in der Kommunika -
tion sein, die zur Lenkung der Aufmerk -
samkeit dient.
In anderen Organisationen sind der
Zweck und die Mission bei der mittleren
Führungsebene unklar, aber diese Men -
schen trauen sich nicht nachzufragen, um
nicht als uninformiert dazustehen. Es gibt
mehrere Wege, wie man seinem Team oder
seiner Abteilung die Ziele klarmachen
kann. Dazu gehört intensives Nachdenken,
bei dem man allein ist, und intensive
Gespräche mit Kollegen, Vorgesetzten und
Untergebenen zur Ideenfindung und als
Realitätscheck.
Schließlich kann es sein, dass die Mission
den Untergebenen nicht klar ist. Das
kommt am häufigsten vor, ist jedoch nicht
unbedingt den Mitarbeitern geschuldet,
sondern kann mehrere Ursachen haben.
Meist liegt es daran, dass Führungskräfte
glauben, die Mitarbeiter verstehen eine
Situation dann, wenn die Führungskraft sie
verstanden hat. Das ist jedoch nicht der
Fall. Als Führungskraft müssen Sie durch
häufige Gespräche sicherstellen, dass alle
dasselbe Bild sehen. Schließlich kommen
ständig neue Mitarbeiter hinzu und die
Grundbedingungen des Geschäfts ändern
sich ständig.
1/2012

ausblick auf die
Zeitnahes Feedback
Es reicht nicht aus, wenn ein Mitarbeiter
genau weiß, was zu tun ist. Er muss bei
jedem Schritt, den er geht, auch wissen, ob
er mit diesem dem Ziel näher kommt oder
ob er sich davon entfernt. Darüber informiert
er sich am besten durch Feedback,
das aus drei wichtigen Quellen stammt:
■
■
■
Feedback von anderen Menschen.
Feedback aus der Arbeit selbst.
Feedback aus eigenen persönlichen
Standards.
Manager haben das Gefühl, dass Kom -
muni kation zu ihren wichtigsten Aufgaben
gehört und dass es davon in ihrer Orga -
nisation immer noch zu wenig gibt. Das
stimmt in vielen Fällen: Feedback von
anderen Menschen zu bekommen, ist
immer noch selten. Es ist wichtig, mit den
eigenen Leuten in wirklichen Kontakt zu
kommen, ihnen zuzuhören und Gelegen -
heiten zu guter Arbeit für sie zu schaffen.
Alle zu kennen, mit ihnen zu sprechen, sie
um Rat zu fragen und ihnen zu berichten,
was daraus geworden ist, sind gute
Möglichkeiten, um ein Umfeld für Feed -
back zu schaffen. Feedback gibt den
Teammitgliedern die Möglichkeit, ihre
Arbeit mit Freude zu machen und im Laufe
des Prozesses zu wachsen. Auch das erfordert
natürlich, dass der Manager sich einen
Teil seiner psychischen Energie (auch
Aufmerksamkeit genannt) für diesen
Prozess reserviert.
Dem Kunden oder den Benutzern die
Zwischenergebnisse der Softwareentwick -
lung zu zeigen, ist auch eine Form, um
Feedback von anderen Menschen einzuholen.
Dabei ist es wichtig, mit den
Stakeholdern ein gemeinsames Gedächtnis
aufzubauen: „Vor zwei Wochen hatten wir
versprochen, Feature X einzubauen. Sie
hatten es sich so und so gewünscht – heute
können Sie es anschauen und uns sagen, ob
wir es richtig implementiert haben.”
Feedback kann auch aus dem Arbeits -
prozess selbst kommen. Gerade die
Softwareentwicklung hat eingebaute
Indika toren dafür, ob man sich in die richtige
Richtung bewegt oder nicht. Man kann
die Anzahl der Features messen, die man
ausliefert, die Anzahl der Fehler, die man
dabei macht, die Zykluszeit, die man vom
Beginn bis zum Ende einer Entwicklung
braucht, die Länge von Warteschlangen vor
einem Workflow-Schritt und vieles mehr.
Quantitatives Management hat Teams
geholfen, sich das Feedback zu holen, das
Abb. 2: Wie entsteht Flow in der Organisation?
sie brauchen, um sich selbst zu organisieren.
Die eben genannten Metriken verändern
im Alltag dadurch ihren Charakter:
Sie werden nicht mehr als Kontrolle von
oben erlebt, sondern als Mechanismus der
Selbstbeobachtung und Verbesserung.
Schließlich gibt es noch das Feedback, das
von innen aus der eigenen Person und ihren
Standards kommt. Ein guter Entwickler hat
intuitiv ein Gefühl dafür, wie guter Code
aussieht. Die Technik des Refaktorisierens
ba siert auf „Code-Gerüchen”, die nichts
anderes sind als persönliche Standards, die
man aus Erfahrung gewonnen hat: „Diese
Stelle im Code sieht aber kompliziert aus –
muss diese Klasse das wirklich alles können
oder sollten wir sie besser aufspalten?” oder
„Die se Stelle im Code hat noch nie richtig
funktioniert, komm lass uns sie endlich einmal
aufräumen, so kann das einfach nicht
bleiben!”, sind Feedback-Aussagen, die von
innen kommen.
Solche Überzeugungen gründen sich auf
Erfahrung, werden aber manchmal so sehr
zur zweiten Natur, dass sie wie ein intuitives,
selbstverständliches Urteil daherkommen.
Für Führungskräfte, wie Architekten
zum Beispiel, ist es schwierig, in den
Kollegen einen Sinn für so etwas zu wecken,
denn meist können sie selbst nicht erklären,
wie sie zu dieser Ansicht gekommen sind.
Das Beste ist, Sie machen sich zunächst Ihre
eigenen Standards explizit klar und nutzen
anschließend jede Gelegenheit, um sie im
Job anzuwenden und darüber zu sprechen.
So können auch andere die Standards
erkennen und daraus lernen.
Inkrementelle
Herausforderungen
Lean strebt einen gleichmäßigen Arbeits -
fluss an. Jedes Arbeitspaket braucht seine
Zeit, um einmal durch den Workflow zu
gehen. Der Workflow ist teamspezifisch,
typische Stationen können z. B. so heißen:
Backlog, ausgewählt, Verstehen, Umsetzen,
Bereitstellen, Akzeptanz testen, Fertig. Den
Durchlauf eines Arbeitspakets durch diesen
Workflow nennt man einen Zyklus. Die
Zeit, die dafür benötigt wird, nennt man
die Zykluszeit (Cycle Time). In Lean versuchen
Teams, diese Zykluszeit kontinuierlich
zu reduzieren, um den Anteil an
Verschwendung, der darin steckt, zu verringern
und den Anteil des geschaffenen
Wertes zu maximieren.
Die zweite Verbesserung gilt dem Service,
der für den Kunden geboten wird. Zum
Beispiel misst das Team die Zykluszeiten
für typische Arbeitspakete und versucht,
daraus eine Gesetzmäßigkeit zu erkennen.
Diese kann das Team dem Kunden dann als
Service-Vereinbarung anbieten: „Wenn du
Kunde uns ein Arbeitspaket der und der
Größe und Art gibst, liefern wir dir die
34 35

ausblick auf die oop 2012
■ Das Pull-Prinzip in Lean erlaubt es den
Mitarbeitern, sich nur so viel Arbeit zu
ziehen, wie sie gleichzeitig erledigen
(G2) und auch vollenden können (G1).
■ Der Fokus auf den Wert, der für den Kun -
den erzeugt wird, liefert die klaren Ziele
(G3) und ermöglicht Konzen tration (G2).
Tabelle 1: Einfluss der vier Lean-Praktiken auf den Flow in der Psyche.
Lösung in typischerweise 40 Tagen, inklusive
Deployment und aller Tests.” Das
Team misst dann, in wie viel Prozent der
Fälle es diese Vereinbarung einhalten konnte,
und versucht, diesen Prozentsatz ständig
zu verbessern.
Entwickler, Software- oder Systemarchi -
tek ten und Oberflächen-Designer – sie alle
versuchen, ihre Fähigkeiten immer weiter
zu perfektionieren. Meisterschaft ist ein
wesentlicher Treiber von Flow. Damit stellt
sich das Team selbst eine inkrementelle
Herausforderung im Sinne des Flow-
Begriffs von Csikszentmihalyi. Flow in
Lean und Flow in der Psyche wachsen
zusammen – das eine führt zum jeweils
anderen (siehe Abbildung 1).
Gegenwart oder Zukunft
Flow zeigt sich auch bei der Planung und
Fortschrittsverfolgung. Der Kunde fragt das
Team möglicherweise: „Wann werdet ihr
mit dem fertig sein, was ich fordere?”. In
traditionellen Projektmanagement-Verfah -
ren (und in manchen agilen Verfah ren ebenso)
versucht das Team, eine Schätzung nach
bestem Wissen und Gewis sen abzugeben
und zum Endtermin, der aus dieser Schät -
zung resultiert, fertig zu sein. Unterwegs
vergleicht es die Abweichungen von
Schätzung und Realität. Die Menschen
befinden sich mit ihren Gedanken dabei fast
immer in der Vergangenheit („Was haben
wir neulich versprochen?”) oder in der
Zukunft („Oh, der vorausgesagte Termin
naht!”). Das Gefühl für die vergehende Zeit
tritt stark in den Vordergrund, und es entsteht
eine Kultur des Schätzens und
Verschätzens, des Verhandelns und Nach -
verhandelns. Diese Kultur steht im direkten
Widerspruch zu Flow, ja sie verhindert Flow
in der Psyche fast sofort. Je wichtiger die
vergehende Zeit wird, desto weniger wichtig
wird die Software, die man schreibt.
In Lean versucht man, mit seinen
Gedanken in der Gegenwart zu sein. Das
Team hört auf, zu schätzen und das zu
betrachten, was in der Zukunft liegt. Es
beginnt, das zu messen, was gerade im
Moment stattfindet und ist deshalb mit den
Gedanken in der Gegenwart. Das Gefühl
für die vergehende Zeit tritt in den
Hintergrund, so kann Flow in der Psyche
entstehen. Der Kunde bekommt dieselbe
Auskunft, die er in den traditionellen
Verfahren auch bekam, nur basiert diese in
einem Fall auf Schätzen, im Lean-Fall auf
Messen und Extrapolieren. „Lieber Kunde,
du forderst zehn kleine und acht große
Arbeitspakete. Die Messungen für kleine
Pakete haben eine durchschnittliche
Zyklus zeit von 5 Tagen ergeben, die für
große Pakete eine von 15 Tagen. Wir bearbeiten
immer 3 Pakete gleichzeitig, also
werden wir deinen Stapel voraussichtlich in
(10*5+8*15)/3=57 Tagen fertig haben.”
Flow in Lean fördert Flow
in der Psyche
In diesem Beitrag habe ich gezeigt, dass es
zwei Arten von Flow gibt: Flow in Lean
und Flow in der Psyche. Ich behaupte nun:
Flow in Lean ist geeignet, bei der Arbeit
Flow in der Psyche hervorzurufen, weil
Lean Eigen schaften hat, die die am Anfang
des Artikels genannten Bedingungen G1 bis
G4 erfüllen, unter denen Flow in der
Psyche entstehen kann (siehe Tabelle 1):
Visualisieren und Messen liefern das sofortige
Feedback (G4).
Das Pull-Prinzip fördert außerdem das
Gefühl, dass man Kontrolle über die eigene
Arbeit hat (G6). Wenn die Firmenkultur
(wie in Lean üblich) auf Stockungen im
Fluss und nicht so sehr auf den Schuldigen
achtet, kann das bei den Mitarbeitern dazu
führen, weniger besorgt um die eigene
Zulänglichkeit zu sein – paradoxerweise
steigt diese gerade mit den Fähigkeiten, die
man im Flow erwirbt, an (G7). Die besondere
Art von Messen und Planen in Lean
bringt die Gedanken in die Gegenwart, die
man sonst an die Zukunft verschwendet.
Das reduziert die mentale Anstrengung und
verändert das Zeitgefühl (G5, G8).
Als Manager einer Produktentwicklungs -
orga nisation sind Sie also im Vorteil, wenn
Sie Flow explizit fördern. Sie reduzieren
Kosten (durch Flow in Lean) und erzeugen
ein Klima, in dem Mitarbeiter gern arbeiten
(durch Flow in der Psyche) – ein Weg zur
nachhaltigen Stärkung Ihrer Firma. ■
Literatur
[And10] D.J. Anderson, Kanban, Blue Hole
Press 2010
[Boh10] M. Bohlen, Softwareprojekte quantitativ
managen: Ein Weg zum performanten
Team, in: OBJEKTspektrum 4/2010
[Csi04] M. Csikszentmihalyi, Good business:
leadership, flow, and the making of meaning
(Reprint), Penguin Books 2004
[Csi08] M. Csikszentmihalyi, Flow : The
Psychology of Optimal Experience, Harper
Collins 2008
[Dem00] W.E. Deming, Out of the crisis, MIT
Press 2000
[Gol90] E.M. Goldratt, What is this thing called
theory of constraints and how should it be
implemented?, North River Press 1990
[Pop03] M. Poppendieck, T. Poppendieck,
Lean software development: an agile toolkit,
Addison-Wesley Professional 2003
[Sen10] P.M. Senge, The Fifth Discipline: The
Art and Practice of the Learning Organization,
Random House 2010
1/2012

ausblick auf die
„ICH HABE TEAMS
BUCHSTÄBLICH VERRÜCKT WERDEN SEHEN”
Interview mit Matthias Bohlen
■■? Matthias, du bist verantwortlich für
den diesjährigen OOP-Track „People &
Soft Skills”. Ich habe dich als
Softwarearchitekten kennen gelernt. Bist
du der Technologie untreu geworden, da
du dich nun den „weichen” Themen widmest?
■■! (Lacht) Untreu auf keinen Fall, doch
ich habe gesehen, wie viel technisches
Know-how, wie viel Gehirnschmalz und
Motivation wirklich guter Software -
architekten im Dickicht der Unternehmens -
organisation verschwinden kann. Architek -
ten sind notorisch überlastete Menschen,
laufen von Meeting zu Meeting und sind
mit der Architekturdokumentation doch
ständig im Hintertreffen. Später habe ich
gesehen, dass dieses Phänomen nicht nur
bei Architekten auftritt, sondern bei allen,
die in der Softwareentwicklung tätig sind.
Das möchte ich ändern. Ich habe mich deshalb
verstärkt damit beschäftigt, wie
Menschen arbeiten, wie sie ihre Zusam -
men arbeit organisieren und was sich dabei
im Hirn und Gemüt der Leute abspielt.
■■? Glaubst du, dass in der Beherrschung
der weichen Themen ein größerer Hebel
für den Erfolg bei der Softwareentwicklung
liegt als in den technischen Themen, wie
Architektur oder Datenbank-Design?
■■! Das kommt auf die Situation an, in der
die Leute stecken. Ein typisches Beispiel:
Ein Team entwickelt ein Produkt, das
bereits bei einigen Kunden im Einsatz ist.
Von diesen Kunden kommen Bugs und
Change-Requests, die von den Consultants
aufgenommen und ins Team getragen werden.
Gleichzeitig arbeitet der Vertrieb an
neuen Interessenten und versucht, sie zu
Kunden für dasselbe Produkt zu machen,
indem er die Bedürfnisse der Interessenten
in Features des Produkts verwandelt.
Schließlich gibt es noch den Unternehmens -
gründer, der eine strategische Vorstellung
davon hat, wohin er mit dem Produkt kommen
will. Er stellt also auch Anforderungen
für neue Features.
Was macht jetzt das Team, das dieses
Produkt entwickelt? Folgt es dem Chef,
dem Vertrieb oder den Consultants? Und
zu wie viel Prozent folgt es wem? Ich habe
Teams buchstäblich verrückt werden sehen
(und war auch selbst schon Mitglied solcher
Teams, allerdings nicht als der Coach,
der ich jetzt bin). Im Alltag hat man gerade
ein neues Feature angefangen, da kommt
plötzlich ein dringender Bug dazwischen,
also Griffel fallen lassen und erst den Bug
beseitigen, dann am Feature weitermachen
und nach drei Monaten fragt der Chef,
warum seine Strategie noch keinen Deut
weitergekommen ist.
Ich hatte einfach das Gefühl: Da kann ich
als Architekt, Entwickler, QA-Mensch oder
Betreiber technisch noch so gut sein, ich
werde in solch einer Organisation für den
Kunden keinen Blumentopf gewinnen können.
Seit 2001 hatte ich mich mit agilen
Methoden wie XP und Scrum beschäftigt,
in 2009 hörte ich von Kanban, und da hat
es „klick” gemacht. Endlich ein Ansatz -
punkt, um zu verstehen, wie Menschen ti -
cken und wie man die Arbeit so gestalten
kann, dass sie dem auch wirklich entspricht.
Lean und Kanban brachten in meinem
Kopf die Ideen zusammen, die ich vorher
schon gesammelt hatte: systemisches
Denken, komplexe adaptive Systeme und
Kognitionswissenschaft.
■■? In deinem Artikel „Flow in Lean, Flow
im Team” ziehst du den Vergleich zwischen
dem Fluss in der Arbeit und dem Fluss in
der Seele. Was sind deine persönlichen
Erfahrungen damit?
■■! Ich hatte einen serverbasierten Kalen -
der, in dem ich meine Termine verwaltete.
Leute schickten mir Anfragen, die ich
annahm oder ablehnte. Vor Jahren hatte
ich als Architekt die Angewohnheit, die
Termine dicht zu legen, also von 09:00 bis
10:00, dann von 10:15 bis 11:15, dann von
13:00 bis 15:00, dann von 15:15 bis …
usw. Du weißt, was ich meine. Ich merkte
bald, dass das nicht funktioniert. Ich konnte
zwar an Meetings teilnehmen, aber ich
konnte die Themen nicht mehr sauber vorund
nachbereiten. Fast keines der Themen
kam richtig zu einem Abschluss – ich wuss -
te jedoch nicht, woran das liegt. Also ließ
ich mir größere Abstände zwischen den
Meetings, doch auch das funktionierte
nicht wirklich gut.
„Es ist wie auf einer Autobahn,
die du nach Autos pro Quadratmeter
(Kapazität) belegst, anstatt nach
Autos pro Stunde (Flow)”.
Hinter dem Ganzen steckte ein Denkfehler.
Ich hatte das falsche mentale Modell.
Wissensarbeit ist ein Flow-Problem, kein
Kapazitätsproblem. Ich hatte mit meinem
Kalender versucht, die Nachfrage gegen
meine Zeitkapazität auszubalancieren. Das
taugte nichts, weil jede nachgefragte
Tätigkeit in sich Variabilität enthält, die
sich bei Ketten voneinander abhängiger
Tätigkeiten so aufaddiert, dass die verplante
Kapazität plötzlich durch andere Dinge
belegt wird. Es ist wie auf einer Autobahn,
die du nach Autos pro Quadratmeter
(Kapazität) belegst anstatt nach Autos pro
Stunde (Flow). Also habe ich umgestellt. Es
geht mir heute nicht mehr darum, die
Stunden möglichst effizient zu belegen,
sondern möglichst ein bis zwei Themen pro
Woche wirklich durchzubringen. Ich lehne
heute ein Meeting nicht mehr ab, wenn die
Stunden belegt sind, sondern wenn in meinem
Kopf noch ein bis zwei weitere
Themen sind, die erst weiterfließen wollen,
bevor der Kopf ein neues angehen kann.
Kommt ein Meeting zum selben Thema,
nehme ich es trotzdem an. Und siehe da:
Ich habe mehr Freude an der Arbeit, bin
mit den Gedanken mehr in der Gegenwart,
habe das Gefühl, endlich mal etwas fertig
zu kriegen und dadurch Wert für meine
Kunden und für mich zu schaffen.
■■? Damit hast du dann ja deine persönlichen
Zielkoordinaten für die Arbeit der
nächsten Zeit. Schauen wir uns aber einmal
in der IT-Welt um uns herum um: Was sind
36 37

ausblick auf die oop 2012
deiner Meinung nach die einflussreichsten
IT-Trends der nächsten Jahre?
■■! Wechseln wir also mal in den Glas -
kugelmodus (lacht). Das Denken in Flow
und in Systemen wird der Trend werden.
Ideen bewegen sich in einem System wie
Agenten, die miteinander und mit dem
System interagieren und das System
dadurch verändern. Das Ganze gehorcht
Regeln, die neu entstehen, sich bewähren
und wieder sterben. Das Business läuft heute
schon so – nichts ist mehr fest, alles fließt
und verändert sich. Jetzt müssen wir in der
IT noch hinterher, dasselbe Verständnis
aufbauen und uns geeignet verhalten. Hier
ein paar Beispiele: Die Lean-Startup-Szene
macht uns das gerade explizit vor – von
denen können wir viel lernen. DevOps wird
auch so ein Trend werden, denn es macht
uns aktionsfähig. Im Verhältnis von
Kunden zu Entwicklungsorganisationen
wird sich einiges verschieben: Man wird
von großen „One-Shot”-Projekten zu längerfristiger,
vertrauensvoller Zusammen -
arbeit kommen und den Blick mehr und
mehr von den Kosten auf den Wert lenken
können. One-Shots werden weiter scheitern.
Es wird jedoch bestimmt noch 20
Jahre dauern, bis endlich auch der öffentliche
Sektor mit One-Shots aufhört, die er
per europaweiter Ausschreibung an den
billigsten Anbieter vergibt. Das wird so lange
dauern, weil der Gesetzgeber erst mitmachen
muss.
■■? Auf was freust du dich am meisten,
wenn du auf das Programm der OOP
schaust?
■■! Auf den Austausch der kreativen Leute
untereinander. Wir haben in diesem Jahr
Sprecher aus so vielen verschiedenen
Richtungen dabei, die etwas komplett
Neues schaffen können, indem sie sich
zusammentun. In London z. B. bringt man
Softwareleute, Künstler, Juristen und
Wirtschaftswissenschaftler in einem neuen
Studiengang zusammen, in dem Kreativität
explizit gefördert wird. Neil Maiden ist
Professor dort und kommt als Sprecher auf
die OOP. Seine Kollegin Bianca Hollis und
er werden uns davon berichten, wie man
Kreativtechniken in agilen Projekten nutzen
kann, um Anforderungen besser zu
beschreiben. Johanna Rothman, Diana
Larsen und alle, die ich gar nicht so schnell
aufzählen kann, bringen Wissen darüber
mit, wie man kreative Menschen erkennt
und einstellt, mit ihnen innovative und
komplexe Vorhaben startet, darin die
Konflikte löst, in den Flow kommt, durch
Selbstorganisation eine Verantwortungs -
kultur aufbaut und seinen Einfluss ausübt,
um mit diesen Menschen Dinge erledigt zu
bekommen. Ich hoffe, dass die Teilnehmer
und Sprecher auch die Open-Arena rege
nutzen werden. Dort kann man eigene
Themen angehen, die heute noch nicht im
Konferenzprogramm stehen. Ich bin
gespannt, wie das klappt, und freue mich
darauf.
■
1/2012

ausblick auf die
interview mit ...
WAS UNS ZU ERFOLGREICHEN
PROJEKTEN FÜHRT …
… UND MANCHMAL
AUCH DAVON ABHÄLT
… Diana Larsen,
die als Partner und Senior Consultant der Firma
Future Works Consulting an der Schaffung von
Arbeitsplätzen beteiligt ist, wo Teams in Ruhe hochproduktive
Softwarelösungen entwickeln können.
Unter anderem coacht sie Teamleiter in Change-
Mangement-Prozessen.
■■? In Ihrem OOP-Tutorial sprechen Sie
über Verhaltensweisen, die drei Hinder -
nisse für ein effektives Management eines
Agilen Unternehmens verursachen: 1) ma -
gi sches Denken, 2) die Illusion von Kon -
trolle, 3) die Phantasie von individueller
Schuld. Welches sind Ihre persönlich wichtigsten
Erfahrungen damit?
■■! Alle drei üben starke Kräfte aus, die die
Organisationen davon abhalten, die
Ergebnisse zu erreichen, die sie eigentlich
wollen, obwohl das konventionelle Denken
uns (Managern und dem Rest von uns) suggeriert,
dass sie der Pfad zum Erfolg sind.
Das übergreifende und sie zusammenfassende
Prinzip fokussiert auf die verschiedenen
Teile (ein Termin, ein Mitarbeiter, ein
Plan), anstatt die Aufmerksamkeit auf das
ganze System (ein Team, eine Abteilung, ein
„Es ist eigentlich paradox, dass
wir erst dadurch mehr Kontrolle
über komplexe Ergebnisse
bekommen, dass wir auf die Kontrolle
über die Teile verzichten.”
Unternehmen) oder das große Ganze
(Industrie, Markt, Wirtschaft) zu richten.
Wenn meine Kunden beginnen, systemisch
zu denken, eröffnen sie neue Möglichkeiten
für sich selbst und kommen den Er -
gebnissen näher, die sie wirklich wollen. Es
ist eigentlich paradox, dass wir erst
dadurch mehr Kontrolle über komplexe
Ergebnisse bekommen, dass wir auf die
Kontrolle über die Teile verzichten.
■■? Sie sind Software-Engineering-Bera -
terin. Was ist für Sie der wesentliche Unter -
schied zwischen der Arbeit mit Entwicklern
und der mit Managern?
■■! Der Unterschied liegt in der Pers -
pektive. Jede Gruppe hat unterschiedliche
Informationen und ein unterschiedliches
Gefühl für den Kontext, der uns zu Kom -
munikationsproblemen und Missver -
ständnis sen von Handlungen, aber auch zu
unverständlichen Verhaltensweisen und
Entscheidungen führt. Ich habe viel Spaß
daran, jedem mehr Klarheit über die Sicht
des anderen zu verschaffen, ihn verstehen
zu lassen, welchen Wert das schafft, und
ihn lernen zu lassen, um seine
Wahrnehmungslücken zu schließen. In der
Softwareentwicklung ist die „universelle
Sprache”, über die Eric Evans in seinem
Domain Driven Design schreibt, ein Schritt
in die richtige Richtung.
■■? In Ihrem neuen Buch „Liftoff: Laun -
ching Agile Teams and Projects” betonen
Sie auch die Bedeutung von Zielbildung für
den Projekterfolg. Ist das nicht der wich -
tigs te kritische Erfolgsfaktor in der Soft -
wareentwicklung?
„Wenn die Menschen verstehen, zu welchem
Gesamtergebnis ihre Arbeit beitragen
soll, blüht ihre Performance auf.”
■■! In unserem Buch diskutieren wir viele
Aspekte, wie man mit seinem Projekt gut
aus den Startlöchern kommt, und eben
auch den vielleicht wirkungsvollsten
Aspekt in unserem Agile-Chartering-Mo -
dell: das Element Zielbildung. Daniel Pink
beschreibt in seinem Buch „Drive” die
Motivationskraft von Selbstbestimmung,
Macht und Ziel. Wenn die Leute verstehen,
zu welchem Gesamtergebnis ihre Arbeit
beitragen soll und wie diese Arbeit andere
positiv beeinflussen kann, blüht ihre
Performance auf – mit durch Studien belegten
Steigerungen, bis hin zur Verdoppelung
gegenüber vorher.
Ich habe immer wieder gemerkt, dass die
frühzeitige Definition des Ziels – bereits zu
Beginn des Projekts – und insbesondere die
Möglichkeit für Teammitglieder, dieses Ziel
mit dem Produktmanager zu diskutieren, es
gründlich zu verstehen und nach Mög -
lichkeit zu beeinflussen, wesentlich zur
Motivation des Teams beiträgt und die mit
neuen Projekten verbundene Lernkurve
beschleunigt. Ein definiertes Ziel hilft, das
Bewusstsein für die Erwartungen, das
Potenzial und die Intention des Projekts
schon zu Beginn zu fassen. Deshalb haben
wir (neben Alignment und Kontext)
Zielbildung als eines der der drei Elemente
des Agile Chartering aufgenommen. Wenn
wir bei der Arbeit ein Bewusstsein für die
Zielbildung haben, vertieft sich unser
Commitment, unser Antrieb wächst und
die Performance steigt.
■■? Mit dieser Einschätzung stehen Sie
aber nicht allein da, oder?
■■! Stimmt. Jeffrey Katzenbach und
Douglas Smith nennen in „Wisdom of
Teams” die gemeinsame Zielbildung als
wichtigste Charakteristik von effektiven
Teams. Diesen Standpunkt unterstützen
38 39

ausblick auf die oop 2012
auch Geoffrey Bellman und Kathleen Ryan
in ihrem Modell von den Bedürfnissen
außerordentlicher Teams: „Die gemeinsame
Zielbildung ist der Grund, warum wir
zusammen kommen […], wo gebündelte
Energie und Fähigkeit eine gemeinsame
Basis dafür sind, etwas zu erreichen, das
von einzelnen Individuen nicht erreichbar
wäre”.
Zielbildung verleiht auch die notwendige
Kraft im Angesicht von widrigen oder sich
ändernden Bedingungen. John Baldoni
schreibt in einem CNN-Artikel: „Gerade in
schwierigen Zeiten ist die Zielbildung
besonders notwendig. Und auch der
Präsident der University of Central Okla -
homa sagte in einem Interview: „Wenn die
Menschen die Zielbildung nicht fühlen und
wissen, dass sie Dinge zu dieser Zielbildung
beitragen und damit die Sache voranbringen,
können schlechte Nachrichten sie
wirklich runterziehen.” Folglich verlangsamen
schlechte Nachrichten – egal welcher
Art – die Produktivität, während das
Verständnis der Zielbildung das Team
gewissermaßen dagegen immunisiert.
■■? Was genau verstehen Sie denn unter
Zielbildung?
■■! In unserem Modell beinhaltet die
Zielbildung drei Komponenten: die
Produktvision, die Projektziele und Ziel-
Tests. Die Produktvision beschreibt in groben
Zügen den angestrebten Geschäftsund
Kundennutzen, Unterscheidungsmerk -
male und Features, die die Idee und den
Sinn des Produkts widerspiegeln. Die
Projektziele beschreiben den eindeutigen
Beitrag dieses Projekts und dieses Teams
auf dem Weg zur Realisierung der
Produktvision. Zur Produktvision tragen
mehrere Projekte und Teams bei und jedes
braucht das Verständnis für seinen Platz.
Die Abnahmekriterien ermöglichen es uns,
das erfolgreiche Projektergebnis zu erkennen.
Zusammen mit ihnen hält man wenige
kritische qualitative und quantitative
„Definitions of Done” in seinem Projekt
fest. Sie verändern sich aber im Laufe eines
Projekts durchaus auch einmal, wenn das
Team besser versteht, was wirklich
gewünscht wird und erreichbar ist.
Ich treffe immer wieder auf hoch talentierte
Teams – egal ob agil oder nicht –, die
daran scheitern, die richtigen Ergebnisse zu
produzieren, weil ihre Produktmanager
oder Product Owner nicht in de Lage sind,
„Ich bin immer wieder auf hoch
talentierte Teams getroffen,
die daran scheitern, die richtigen
Ergebnisse zu produzieren, weil ihre
Produktmanager nicht in der Lage
sind, eine klare Produktvision und ein
klares Projektziel zu vermitteln.”
eine klare Produktvision und ein klares
Projektziel zu vermitteln. Indem wir uns die
Zeit nehmen, die Vision zu formulieren,
schaffen wir bessere Standards zur
Priorisierung der Bewertung der Backlog-
Einträge.
■■? Diana, auch auf der OOP halten Sie
einen Vortrag darüber, wie man Teams und
Projekt zum Erfolg führt. Glauben Sie, dass
die Menschen der kritische Faktor für den
Projekterfolg sind? Und wie groß ist der
Einfluss von Prozessen und Werkzeugen?
■■! Das sind jetzt zwei Fragen! Natürlich
sind die Menschen der kritische Erfolgs -
faktor und natürlich machen gute Men -
schen in einem schlecht geführten System
schlechte Arbeit oder verbrennen. Schlecht
oder falsch vorbereitete Menschen können
in einem an Ergebnissen orientierten
System die Produktivitätsstandards nicht
erreichen. Es ist ein komplexer Tanz von
dem Ganzen (dem organisatorischen
System) und seinen Teilen (den betroffenen
Menschen). Im Übrigen sind Manager ja
auch Menschen, also beeinflusst auch ihr
Verhalten das Gesamtergebnis. Definierte
Prozesse und Werkzeuge können die Arbeit
unterstützen und auf den Weg bringen. Es
lohnt sich, das Arbeitssystem als Ganzes
und die angestrebten Ergebnisse sorgfältig
zu überdenken und die Menschen mit ihrer
Arbeit einzubeziehen, wenn man über
Prozesse und Werkzeuge nachdenkt. Also:
Es sind die Individuen und die Inter -
aktionen durch Prozesse und Werkzeuge.
■■? Worauf freuen Sie sich am meisten auf
der kommenden OOP?
■■! Ich freue mich auf das, was in den
Open-Area-Sessions entstehen wird, wenn
neue Kollegen und alte Bekannte sich treffen
und gegenseitig Ideen austauschen –
sowohl über meine Session als auch über
mein oben genanntes Buch, das ich gemeinsam
mit Ainsley Nies geschrieben habe,
und natürlich auf die neuen Erkenntnisse
und Arbeiten der anderen. Ich liebe es, agile
Praxiserfahrungen zu hören, sowohl die
guten als auch die schlechten, denn jede
gute Sache braucht eine gute Krise. ■
1/2012

uchbesprechung für sie gelesen von ...
mehr zum thema:
http://www.theleanstartup.com
THE LEAN STARTUP
Die Zielgruppe des Buchs „The Lean Startup” von Eric Ries ergibt sich aus dessen Definition
des Begriffs „Startup”: Ein Startup ist eine Unternehmung, die mit dem Ziel gegründet wurde,
in einem hoch dynamischen und dadurch unsicheren Marktumfeld innovative Produkte und
Dienstleistungen zum Erfolg zu bringen. Dieses Buch richtet sich also nicht nur an kleine
Garagenfirmen, sondern genauso an die Produktentwicklungsbereiche großer Konzerne.
... Dr. Yves Stalgies,
(E-Mail: stalgies@etracker.com),
PMP, Direktor IT bei der etracker GmbH in Hamburg.
Mit der The Lean Startup-Methode, die
Eric Ries in seinem Buch vorstellt, möchte
er die Erfolgsrate dieser Unternehmungen
deutlich steigern.
Der Schlüssel ist die Erkenntnis, dass
auch ein Startup systematisch gemanagt
werden kann (und muss) und daher Entre -
preneurship nicht Heldentum ist, sondern
eine Management-Disziplin und dass der
Entrepreneur derjenige ist, der dafür sorgt,
dass die richtige Balance zwischen „just do
it” und monatelanger Business-Planung
gefunden wird. Auch wenn Innovationen
schwer vorhersagbar sind, können sie
gemanagt werden. Das Motto ist: „Work
smarter, not harder”. Eric Ries beschreibt
in seinem englischsprachigen Buch auf 336
Seiten, wie das geht.
Das Buch gliedert sich in drei Teile:
■ Vision: Im ersten Teil werden die Be -
griffe „Startup” und „Entrepreneur”
definiert. Außerdem werden die
Kernelemente der Methode, die Pro -
zess kette „Build-Measure-Learn” und
„Validated Learning” eingeführt.
■ Steer: Basierend auf der grundlegenden
Methodik werden in diesem Kapitel
Werkzeuge vorgestellt, mit denen
sichergestellt werden kann, dass die
Unternehmung die richtige Richtung
einschlägt. Dazu werden die Konzepte
des „Minimal Viable Products” und
das „Innovation Accounting” erläutert.
■ Accelerate: Wenn die richtige Richtung
eingeschlagen ist, geht es darum, die
Geschwindigkeit zu erhöhen. In diesem
Kapitel wird beschrieben, an welchen
Stellschrauben gedreht werden kann.
Teil 1: Die Vision
Der Entrepreneur ist verantwortlich für die
Vision der Unternehmung und leitet daraus
eine Strategie ab, aus der sich wiederum die
Produktdefinition ergibt. Er hat die Auf -
gabe, die Unternehmung durch Chaos und
Unsicherheit zu lenken, indem er zum richtigen
Zeitpunkt Entscheidungen trifft, die
messbar und nachvollziehbar sind. Diese
Eric Ries
The Lean
Startup:
How Today's
Entrepreneurs
Use Continuous
Innovation to
Create Radically
Successful Businesses
ACrown Business, September 2011
336 Seiten (auf englisch)
18,80 € (Kindle 13,32 €)
ISBN-13: 978-0307887894
Entscheidungen sind im Modell des Autors
entweder Pivots, d. h. radikale und mutige
Änderungen in der Strategie (während die
Vision beibehalten wird), oder aber die
Erkenntnis, die aktuelle Richtung beizubehalten
und nur am Produkt zu tunen
(Preserve).
Die Entscheidung wird am Ende der
Feedback-Schleife Build-Measure-Learn
getroffen (ein Durchlauf durch die BML-
Schleife wird im Folgenden auch als
Experiment bezeichnet). Der Lernerfolg
muss sich dabei in Metriken widerspiegeln,
die demonstrieren, dass das Team wertvolle
Erkenntnisse über die aktuelle Lage des
Startups und dessen Fortschritt herausgefunden
hat. Ries nennt das „Validated
Learning” – für ihn handelt es sich dabei
um das wichtigste Fortschritt-Messgerät
des Startups. Analog zum Lean-
Management geht es auch beim Lean-
Startup-Modell um die Vermeidung von
Verschwendung: Es geht darum, dass alles,
was zu keinem nachvollziehbaren
Lerneffekt führt, Ver schwendung ist.
Um einen Lerneffekt erreichen zu können,
muss ein Build – das Minimal Viable
Product (MVP) – erstellt und potenziellen
Kunden zur Verfügung gestellt werden.
Gemeint ist dasjenige Produkt, mit dem in
minimaler Zeit die komplette BML-Schleife
durchlaufen werden kann und das minimale
Zeit zur Herstellung gekostet hat – jedes
Feature zu viel ist Verschwendung. Es muss
dabei für den Kunden natürlich einen
Mehrwert schaffen.
Teil 2: Der Weg
Der zweite Teil beschäftigt sich mit der
Frage, wie die Unternehmung in die richtige
Richtung gesteuert werden kann. Die
Vision und damit auch die Strategie werden
auf Grundlage einiger weniger Grund -
voraussetzungen abgeleitet. Die Grund -
voraussetzungen werden in Hypo thesen
zerlegt, um sie dann in der Build-Measure-
Learn-Schleife mit Hilfe eines MVPs zu
testen.
Von der Vision bis zur Auslieferung an
den Kunden sind viele Abteilungen oder
Teams eines Unterneh mens beteiligt. Eine
Optimierung lokal in einer Abteilung führt
in der Regel nicht dazu, dass die Schleife
insgesamt schneller durchlaufen werden
kann. Es ist daher essentiell, das System als
Ganzes zu be trachten. Ries schlägt die
Verwendung eines Kanban-Systems vor. In
dem System wird eine beschränkte Menge
von gleichzeitigen Experimenten durchgeführt,
diese dann aber konsequent vom
Anfang bis zum Ende, bis der Lerneffekt
sichergestellt ist. Auf diese Weise werden
der Fortschritt und der Erfolg an den
Lernprozess gehängt und nicht an das
Erstellen von Features.
Bevor das MVP gebaut wird, muss festgelegt
werden, wie eine mögliche Metrik
zum validierten Lernen aussehen soll,
damit diese im Rahmen des Innovations-
Controllings kontinuierlich gemessen werden
kann. Ziel dieses Controllings ist es,
Transparenz im Unternehmen zu schaffen
und dem Entrepreneur eine Ent schei -
dungsgrundlage für eine grundlegende
Richtungsänderung (Pivot) bzw. für das
Beibehalten der eingeschlagenen Richtung
zu geben.
Bei der Erstellung der Metriken muss
darauf geachtet werden, keine kosmetischen
Zahlen (Vanity Metrics) zu verfolgen,
40 41

uchbesprechung
Experimente initialisiert werden. Die
Plattform muss dafür sorgen, dass die
Gesamtun terneh mung geschützt bleibt,
auch wenn ein MVP ausgespielt wird, das
qualitativ nicht der Firmenkultur entspricht.
Zudem muss sie sicherstellen, dass
Ergebnisse und Inno vationen offen (im
Unternehmen) kommuniziert werden und
nicht der Eindruck entsteht, dass niemand
wissen darf, was dort passiert. Eris Ries
listet im Detail auf, wie eine solche
„Innovation Sandbox” aussehen könnte.
Abb. 1: Build-Measure-Learn-Continuous-Innovation (Abdruck mit freundlicher
Genehmigung von Dan Martell).
sondern Metriken, die vollständig verstanden,
für jeden einsehbar und möglichst einfach
verständlich sowie nachprüfbar und
nachvollziehbar sind. Die Ergebnisse des
Innovations-Controllings werden schließlich
für den Abschluss der BML-Schleife
verwendet. Zu diesem Zweck werden
regelmäßig Pivot-or-Preserve-Meetings
abge halten, in denen anhand der aktuellen
Metriken die entsprechende Entscheidung
getroffen wird.
Teil 3: Das Tempo
Sobald das Startup in die richtige Richtung
läuft, geht es darum, die Geschwindigkeit
kontinuierlich zu erhöhen. Die Beschleu -
nigung wird durch vier Elemente erreicht:
■ Geringe Paketgrößen: Die BML-
Feedback-Schleife wird umso schneller
durchlaufen, je kleiner das Experiment
ist. Aus der Kanban-Methode ist zudem
bekannt, dass Tasks eine Prozesskette
schneller durchlaufen, wenn der
Prozess nicht nach dem Push- sondern
nach dem Pull-Prinzip funktioniert.
Beim Lean-Startup-Modell steht am
Anfang die aus der Strategie abgeleitete
Hypothese, die es zu überprüfen gilt.
Dazu wird zunächst festgelegt, was
beim Experiment gelernt werden soll
(Learn), wie der Lernerfolg gemessen
wird (Measure) und welches MVP aus
diesem Zweck gebaut werden muss
(Build).
■ Identifikation und Tuning des Wachs -
tums motors: Damit der Entrepreneur
durch seine Entscheidungen Wachstum
herbeiführen kann, müssen die Wachs -
tumsmotoren identifiziert werden. Ries
führt beispielhaft einige Wachstums -
motoren auf und erläutert, aus welchen
Quellen diese gespeist werden. Um die
Komplexität gering zu halten, ist es
günstig, sich auf einen Motor zu konzentrieren
und die Priorisierungen auf
das Tuning dieses Motors abzustimmen.
■ Aufbau einer adaptiven Organisation:
Die größte Herausforderung stellt die
Notwendigkeit dar, das Lean-Startup-
Modell abteilungsübergreifend zu
implementieren. Dies erfordert ein
generelles Umdenken aller Beteiligten,
weshalb Ries in diesem Zusammen -
hang entsprechende Trainings pro -
gramme empfiehlt.
■ Bereitstellung einer Innovationsum -
gebung für das Team: Ein Team benötigt
drei Dinge, um Innovationen vorantreiben
zu können: Beschränkte, aber
gesicherte Ressourcen (ein Überfluss an
Mitteln ist ebenso wenig hilfreich, wie
ein Mangel). Die Unabhängigkeit,
Entscheidungen treffen zu können und
das Business voranzutreiben (wenn
ständig Approvals der Geschäfts -
führung eingeholt werden müssen, wird
Kreativität erstickt). Ein persönliches
Interesse am Ergebnis (die beteiligten
Personen müssen sichtbar mit dem
Erfolg der Unternehmung verbunden
sein).
Ist dieser Rahmen aufgespannt, kann eine
Plattform („Sandbox”) für die innovativen
Epilog
Der Autor fasst im vorletzten Kapitel zu -
sammen, worum es ihm neben der
Steigerung der Erfolgsrate innovativer
Produktentwicklung in seinem Lean-
Startup-Movement geht: um die Vermei -
dung von Zeitverschwendung. „Es gibt
nichts nutzloseres, als mit großartiger
Effizienz Dinge zu tun, die überhaupt nicht
getan werden brauchen”, zitiert er Peter
Drucker. Lokale Effizienzsteigerung ist
nahezu sinnlos, wenn nicht das Gesamt -
system optimiert wird. Ein Produkt zu bauen,
ohne sich vorher zu überlegen, wie man
den Erfolg messen will bzw. was man daraus
lernen möchte, ist Zeitver schwen dung.
Fazit
Der Aufbau des Buchs erschließt sich dem
Leser erst auf den zweiten Blick. Durch die
Zahl an kurzweiligen Fallstudien (beispielsweise
Groupon und Dropbox) geht auf der
einen Seite häufiger der rote Faden verloren.
Auf der anderen Seite führt das dazu,
dass immer wieder Bezug genommen werden
muss auf Methoden und Artefakte, die
erst im Laufe des Buchs im Detail erläutert
werden. Hier wäre eventuell eine Trennung
zwischen Methodik und Fallstudien gut
gewesen.
Die Stärken der Lean-Startup-Methode
liegen darin, bekannte und bewährte
Verfahren (Lean Thinking, Systemtheorie,
minimale Produktinkremente usw.) so zu
bündeln, dass sich ein Framework zur
systematischen und kontinuierlichen Inno -
vationsentwicklung ergibt. Das hilft auf der
einen Seite den kreativsten Innovatoren
dabei, ein nachhaltiges Business aufzubauen,
und gibt auf der anderen Seite den
Konzernabteilungen die Hoffnung, dass
auch dort wieder Entrepreneur-Wind
wehen kann. Vorausgesetzt man begibt sich
auf den Weg, eine adaptive Organisation zu
entwickeln, in der gemeinsam abteilungsübergreifend
innovative Experimente
gestartet werden.
■
1/2012

fachartikel
mehr zum thema:
www.oasis-open.org
die autoren
LIVING SOA:
EVOLUTION DES BETRIEBS VON
SOA-BASIERTEN LÖSUNGEN
Als vor einigen Jahren die Evolution hin zu serviceorientierten Architekturen (SOAs) begann,
war eines der wesentlichen Argumente die höhere Flexibilität von Lösungen auf dieser Basis. In
diesem Artikel wird aufgezeigt, welche Auswirkungen die versprochene Flexibilität von SOA auf
den IT-Betrieb hat und ob die Flexibilität tatsächlich ausgenutzt werden kann. Werden Services
mit gleicher Leistung, aber z. B. auf der Basis unterschiedlicher Technologien ausgetauscht,
kann dies auch den Wechsel der Werkzeuge erfordern, was einen erhöhten Aufwand beim
Betrieb von SOA-basierten Lösungen zur Folge hat. In dem Artikel wird gezeigt, welchen neuen
Anforderungen Betriebswerkzeuge und Services gerecht werden müssen
Dr. Veit Köppen
(E-Mail: veit.koeppen@ovgu.de)
ist geschäftsführender Leiter des Center for Digital
Engineering an der Otto-von-Guericke-Universität
Magdeburg und Assistent im Institut für
Technische und Betriebliche Informationssysteme.
SOA und Flexibilität
Mit der Umsetzung des Konzepts service -
orientierter Architekturen (SOA) ergeben
sich für den Betrieb derartiger IT-Lösungen
neue Herausforderungen. Während Client/
Server-basierte IT-Lösungen in ihrem technischen
Aufbau und ihrer Implementierung
eher stabil und systemorientiert sind, erfordert
die Serviceorientierung neue Werk -
zeuge und Ansätze für den Betrieb der IT-
Lösungen. Anders als beim Übergang von
monolithischen Systemen zu Client/Server-
Architekturen ist die Entwicklung zu SOA
evolutionär. Die Entscheidung, ob eine vorliegende
Architektur bereits den SOA-
Prinzipien genügt, ist daher nicht immer
eindeutig. Gleichzeitig entwickelt sich auch
die Definition von SOA weiter. Während
man anfangs die Definition von SOA eher
mittels der zugehörigen technischen Be -
stand teile herausstellte, werden inzwischen
dafür die Eigenschaften der Architektur
herangezogen.
Unter einer SOA versteht man eine
Systemarchitektur, die vielfältige, verschiedene
und eventuell inkompatible Metho -
den oder Applikationen als wiederverwendbare
und offen zugreifbare Dienste
(Services) repräsentiert und dadurch eine
plattform- und sprachunabhängige Nut -
zung und Wiederverwertung ermöglicht.
Die Organization for the Advancement of
Structured Information Standards (OASIS)
definiert den Begriff Services als einen
Mechanismus, der den Zugang zu einer
oder mehreren Leistungen ermöglicht,
wobei der Anschluss der Services durch
vorbestimmte Schnittstellen unterstützt
und konsistent mit den Bedingungen und
Methoden gemäß der Spezifikation in der
Service-Beschreibung ausgeführt wird (vgl.
[Oas06]). Die folgenden vier Bestandteile
sind für SOA charakteristisch:
■ das Applikations-Frontend
■ die Services
■ das Service-Repository
■ der Service-Bus
Ein Service besteht aus einem Auftrag, einem
oder mehreren Interfaces und der
Implementierung. Das Service-Repository
umfasst alle Informationen, die benötigt werden,
um Services entsprechend den geänderten
Anforderungen auszuwählen oder durch
gleichwertige Services auszutauschen. Der
Service-Bus dient dem Datenaustausch zwischen
Services. Gegen über dem direkten
Datenaustausch zwischen Services hat der
Service-Bus den Vorteil, dass er heterogene
Technologien in Schnittstellen und Kom -
munikation integrieren kann. Daten können
servicespezifisch und zentralisiert im Service-
Bus aufbereitet und verteilt werden. Dadurch
reduziert sich eine Mehrfachbear beitung
gleicher Daten.
Nicht zuletzt dient das einheitliche
Appli kations-Frontend als Benutzerzugang
zu der SOA-Lösung. Komplexität und
Technik der Realisierung bleiben dem
Benutzer verborgen. Auf technische oder
inhaltliche Erfordernisse kann durch den
Austausch von Services reagiert werden,
ohne dass diese Änderungen für den
Benutzer in der Oberfläche oder Hand -
habung sichtbar werden.
Ein Service kann aus einer Aktivität
bestehen oder sich aus mehreren
Aktivitäten zusammensetzen. Ausschlagge -
bendes Kriterium ist letztlich die Definition
von Services, die sich insbesondere auf die
Austauschbarkeit und Wiederverwend -
barkeit der Dienste bezieht. Der Umfang
eines Services wird als Granularität
bezeichnet (vgl. [Mel08]). Es gibt keine
zwingende Granularität von Services, aus
denen ein Prozess zusammengesetzt wird.
Liane Will
(E-Mail: liane.will@sap.com)
ist Chief Service Architect im Support der SAP AG.
Zu ihren Schwerpunkten gehört die Optimierung
von Systembetrieb und Applikationslebenszyklus.
Als Promotionsstudentin befasst sie sich mit neuen
Herausforderungen im IT-Betrieb und deren
Bewältigung beim Einsatz von SOA.
Der Umfang eines Service wird beim
Entwurf der SOA-basierten Lösung festgelegt.
Werden Services zu fein granular
gewählt, erhält man eine hohe Anzahl von
Services, was die Verwaltung und Übersicht
erschwert. Wird ein Service dagegen zu
umfassend gefasst, erschwert dies die
Austauschbarkeit. Die Granularität ist so
zu wählen, dass der fachliche Zusam men -
hang zu den Teilaktivitäten eines Ge -
schäfts prozesses erkennbar ist.
Um Services austauschen zu können,
müssen zusätzliche Informationen verfügbar
sein. Im Laufe der Entwicklung hat sich
bereits gezeigt, dass Services auch nichtfunktionalen
Anforderungen gerecht werden
müssen, um insbesondere Service-Bus
und -Repository entsprechend zu bedienen.
Bisher unzureichend untersucht ist, welche
Anforderungen sich für den laufenden
Betrieb an SOA ergeben, wenn die viel
beschriebene Flexibilität SOA-basierter
Lösungen wirklich in Anspruch genommen
wird. Durch die Möglichkeit, Services und
die Zusammensetzung eines Prozesses aus
Services zu verändern, ohne die Benutzer
mit diesen Änderungen zu konfrontieren,
kann die Flexibilität der Lösung maßgeblich
erhöht werden. Für den Begriff
42 43

fachartikel
„Flexibilität” gibt es jedoch keine einheitliche
Definition. J.S. Evans hat die verschiedenen
Begriffe und Verwendungen in Bezug
auf Flexibilität in der Literatur zusammengetragen,
normiert und als Matrix zusam -
mengestellt (vgl. [Eva91]). Er unterscheidet
drei Kriterien der Flexibilität:
Unternehmensschicht
Benutzer
RFID Mobile Geräte Webbrowser
Rendering
Office
Werkzeuge
■ Yielding to pressure – als Fähigkeit, auf
externen Druck zu reagieren und sich
anzupassen.
■ Capacity for new situation – als die
Menge von möglichen Anpassungen
auf bevorstehende sich ändernde Be -
dingungen und Wünsche.
■ Suspectibility – als Schwierigkeitsgrad,
Modifikationen durchzuführen.
In diesen Kriterien zeigen SOA-basierte
Lösungen ihre Stärken. Die Flexibilität
SOA-basierter Lösungen beruht auf ihrem
Potenzial, Services während der Laufzeit
auszutauschen oder anzupassen, um auf veränderte
Anforderungen aus der Umwelt zu
reagieren. Darauf richten Software hersteller
ihre Produkte aus. Vorteile ergeben sich insbesondere
für die Nutzer einer SOA durch
die schnellere Anpassungs fähigkeit auf
Veränderungen und die Wiederver wend -
barkeit von Services (vgl. [Sof10]). Tat -
sächlich wird dieses Potenzial von den
Betreibern und Anwendern von SOA nur
verhalten genutzt. Es gilt das alte Prinzip:
„Never touch a running system”. Im Folgen -
den zeigen wir, welche Anfor derungen sich
für den Betrieb ergeben, wenn die Flexi -
bilität durch den Austausch von Services
wirklich ausgeschöpft werden soll.
Systembetrieb versus
Lösungsbetrieb
Wenn man einen Service in einer komplexen
SOA-basierten Lösung ändern oder ersetzen
will, müssen bestimmte Vorausset zungen
erfüllt sein. Zwei Services können nur dann
gegeneinander ausgetauscht werden – ohne
einen bestehenden Geschäfts prozess zu stören
–, wenn sie hinsichtlich der
Geschäftslogik, der Funktionalität, des
Datenein- und -ausgangs sowie der Inter -
faces identisch sind. Ähnlich verhält es sich,
wenn ein bereits genutzter und innerhalb
eines Geschäftsprozesses integrierter Service
geändert werden soll. Der Prozess ablauf
muss erhalten werden. Um den Ablauf zu
gewährleisten, können Änderungen nur im
Rahmen gleicher Eingangs daten und eines
gleichen Ausgangs datenformats erfolgen.
Andernfalls würde dies auch Änderungen an
Prozessschicht
Zwischenschicht- Unterstützende Services wie Technologie Gateways, Adapter
Basisschicht- Grundlagen der SOA Business Logik und Datenmanagement
Abb. 1: Aufbau einer SOA-basierten Lösung am Beispiel eines
Kundenauftragsprozesses.
Vorgänger- und Nachfolge-Services erfordern,
was den Aufwand erhöht.
Die Geschäftsprozesslogik muss in jedem
Fall gewahrt bleiben bzw. darf nur im
Rahmen der Vorgaben verändert werden.
Ein Service kann aber auch innerhalb weiterer,
anderer Geschäftsprozesse genutzt
werden. Hier spielt die bereits erwähnte
Granularität eines Service eine Rolle. Ist ein
Service zu komplex bzw. leistet er extrem
unterschiedliche Aktivitäten, wird man
kaum einen Service mit vergleichbaren
Leistungsparametern finden. Somit ist der
Service faktisch nicht austauschbar. Genau
diese Situation findet sich heute häufig in
der Praxis. Es stellt sich die Frage, inwieweit
Softwarehersteller überhaupt interessiert
sind, ihre Services austauschbar zu
halten. Dadurch werden jedoch Rahmen -
bedingungen geschaffen, die die Flexibilität
von SOA-basierten Lösungen ungerechtfertigt
einschränken. Ebenso darf es, z. B. für
die verwendete Technologie eines Service,
keine Beschränkungen geben, d. h. ein
Service in einer SOA-basierten Lösung
kann durch einen anderen Service mit
anderer Technologie ausgetauscht werden.
Administrative Aufgaben sind bei heutigen
Lösungen herstellerspezifisch geprägt. Die
aktuell beim Betrieb verwendeten Werk -
zeuge sind zudem noch häufig den
Client/Server-basierten Lösungen verhaftet.
Das heißt, der Betrieb basiert auf:
■ Kunden- bzw. Outsource-Verantwor -
tung für den Betrieb
Service
Repository
Metadaten zu
Services
Service Bus
Interface
Management
zwischen
heterogenen
Services
■ system- und technologiespezifischen
administrativen Werkzeugen,
■ system- und technologiespezifischen
Aktionen und Qualitätskennzahlen,
■ system- und technologiespezifischem
Wis sen und Erfahrungen, um erstes
und zweites einzusetzen und erfüllen zu
können.
Mit dem Übergang zu SOA muss sich der
systemorientierte Ansatz hin zu einem
lösungsorientierten Ansatz verschieben.
Unterschiede zwischen Client/Server- und
SOA-basiertem Betrieb
Jeder Service innerhalb der SOA muss die
Anforderungen von Service-Repository und
Service-Bus bedienen. Ein wesentlicher
Vorteil für die Endbenutzer solcher SOAbasierten
Lösungen ist die Entkopplung
von technischer Implementierung und
Geschäftsfunktionalität. Es besteht keine
Notwendigkeit für den Benutzer, die eingesetzten
technischen Komponenten oder die
Hardware zu kennen. Das kann aus
Betriebssicht ein Nachteil sein. Wenn der
Endbenutzer eine Störung seines Geschäfts -
prozesses feststellt, ist er nicht in der Lage,
technische Informationen zur Unterstüt -
zung der Ursachenanalyse zu geben.
Abbildung 1 zeigt am Beispiel eines
Kundenauftragsprozesses in ARIS-No -
tation den Aufbau einer SOA-Lösung. Der
Benutzer berichtet über einen Ausfall des
Prozesses oder über Probleme beim Anle -
gen der Verkaufsorder. In Client/Server-
1/2012

fachartikel
basierten Lösungen wird mit einer
Systemanalyse begonnen, um die verursachende
technische Komponente zu ermitteln.
Das ist praktikabel, weil die Anzahl
der technischen Komponenten in Client/-
Server-Architekturen eher niedrig ist. In
vielen Fällen benennt der Benutzer bereits
das technisch fehlerhaft arbeitende System.
SOA-basierte Lösungen unterscheiden sich
von dieser Vorgehensweise maßgeblich.
Dem Benutzer sind der technische Aufbau
und insbesondere technische Komponenten
und Systeme verborgen. Er kann die verursachende
Komponente nicht benennen.
Versucht man, die aus Client/Serverbasierten
Lösungen bekannten systemorientierten
Methoden zu übertragen, geht
der lösungsorientierte Ansatz von SOA verloren.
Würde man dies dennoch versuchen,
müsste in einem ersten Schritt analysiert
werden, welche technische Komponente
die Störung verursacht, bevor überhaupt
mit der Analyse der Störungsursache be -
gonnen werden kann. Das führt in der
Praxis dazu, dass nach dem Ausschluss -
verfahren gearbeitet wird. Es werden die
Experten der jeweiligen technischen
Komponenten herangezogen und jeder
analysiert seine technische Komponente,
um eine Störung auszuschließen. Je mehr
Technologien in der SOA-basierten Lösung
eingesetzt werden, desto höher ist die
Anzahl der benötigten Experten und der
Aufwand steigt. Zudem werden häufige
Wechsel der Bearbeiter eine Störung wahrnehmen,
da das Ausschlussverfahren häufig
nicht zweifelsfrei funktioniert. Die
Störung wird langsam „eingekreist”.
Um das zu vermeiden, muss die systemorientierte
Analyse durch einen lösungsund
serviceorientierten Ansatz mit entsprechenden
Werkzeugen zur Analyse abgelöst
werden. In unserem Beispiel muss die
Bearbeitung des Kundenauftrags als
Prozess in seiner Gesamtheit erfasst und
analysiert sein. Davon ausgehend muss in
einem ersten Schritt der für die Störung verantwortliche
Service innerhalb des Pro -
zesses ermittelt werden. Nicht das System
oder die technische Komponente ist die zu
analysierende Einheit, sondern der Service.
Dafür werden neue Werkzeuge benötigt.
Wenn SOA-basierte Lösungen analog zu
Client/Server-basierten Lösungen betrieben
werden, hat das weitreichende Folgen:
■ Verlust der Vorteile von SOA.
■ Steigende Betriebskosten mit der An zahl
integrierter Services und Tech nologien.
■ Gefährdung allgemeiner Qualitäts -
Systemadministration in Client/-
Server-basierten Lösungen
Technologie- und systemorientierte Werkzeuge.
Systemorientierte Aktionen, Einheiten und Begriffe.
Einsatz der Werkzeuge und Durchführung
der Aktivitäten erfordern systemund
technologiespezifisches Know-how .
kriterien, wie Stabilität, Verfügbarkeit
und Performance.
Tabelle 1 stellt den Client/Server-basierten
und den SOA-basiertem Ansatz aus Be -
triebssicht einander gegenüber.
Anforderungen des IT Service-
Managements
Welche Anforderungen und Prozesse für den
IT-Service und -Support bestehen und wie sie
geeignet, aber herstellerunabhängig zu implementieren
sind, beschreibt die IT
Infrastructure Library (ITIL) (vgl. [Off07]).
ITIL formuliert Good Practices bei der
Etablierung und Durchführung von IT-
Service-Prozessen. Es ist darauf zu achten,
dass ein Service im ITIL-Sinne als Dienst -
leistung zu verstehen ist und nicht gleichzusetzen
ist mit Services als Teil der SOA. ITIL
definiert eine Dienstleistung als einen Service,
durch den ein Kunde einen Wert erlangt, in
dem ihm Ergebnisse bereitgestellt werden,
die der Kunde erreichen will, ohne selbst
Eigentümer der spezifischen Kosten und
Risiken der Erbringung zu sein. Das an dieser
Stelle im Mittelpunkt stehende tägliche
Betriebsgeschäft wird in ITIL in der Phase
„Operation” allgemein beschrieben. Zum
Lebenszyklus gehört auch das permanente
Streben nach Optimierung, sodass sich an die
Phase „Operation” die Phase „Continual
Service Improvement” anschließt, die zum
erneuten Beginn des Lebenszyklus führen
kann. Die im letzten Abschnitt beschriebene
Situation einer Störung und deren
Ursachenanalyse wären dem „Incident and
Problem Management” zuzurechnen.
Change-Management
Anhand des Prozesses Change-Manage -
ment aus der Transitionsphase zeigen wir,
wie sich die Anforderungen an diesen
Lösungsadministration in SOA-basierten
Lösungen
Vereinheitlichte zentrale Werkzeuge
mit Fokus auf der Lösung.
Service- und lösungsorientierte Aktivitäten,
Einheiten und Begriffe.
Vereinheitlichung der lösungs- und serviceorientierten
Administration gestattet den Betrieb ohne
tiefgreifende Kenntnis von Service-Technologie
und -Spezifika.
Tabelle 1: Gegenüberstellung der Anforderungen in Client/Server- und SOA-basierten
Lösungen.
Prozess beim Betrieb von SOA-basierten
Lösungen ändern. Aus Sicht von ITIL
bezieht sich ein Change auf jegliche Art von
Änderungen an der Dienstleistung eines
Providers, was auch Änderungen an Pro -
grammen, technischen Komponenten oder
auch Systemkonfigurationen beinhaltet.
Abbildung 2 zeigt den Change-Manage -
ment-Process, wie er für eine Standard -
änderung von ITIL vorgeschlagen wird.
Die Qualität des Change-Management-
Process ist von wesentlicher Bedeutung für
die kontinuierliche Evolution einer Lösung.
Die in ITIL beschriebenen Good Practices
für diesen Prozess können auf SOA-basierte
Lösungen übertragen werden. Der Prozess an
sich bleibt erhalten – inklusive seiner
Qualitätskriterien. Die eigentliche Heraus -
forderung entsteht bei der technischen
Umsetzung einer Änderung, da diese selbst
aus mehreren Änderungen bestehen kann,
die mehrere, abhängige Services gleichzeitig
betreffen. Damit sind eine Synchronisation
der einzelnen Änderungen und eine serviceübergreifende
Protokol lierung erforderlich.
Es ergeben sich drei wesentliche neue
Anforderungen im SOA-Umfeld:
■
■
■
Zentrale Kontrolle und Auswertung des
Change-Management-Process (lösungs-
orientierte Protokollierung).
Lösungsorientiertes Deployment von
Changes (Synchronisation von Changes
über Services hinweg).
Deployment von Changes, unabhängig
von der eigentlichen Technologie eines
Service.
Bisher ist es noch immer üblich, dass technische
Systeme und Services mit einem eigenen
und häufig herstellerspezifischen De -
ployment-Werkzeug einhergehen. Dadurch
ist es kaum möglich, komplexe Changes zu
realisieren, die die Synchronisation der dar-
44 45

fachartikel
Request for
Change
Dokumentation
&Review
Auswirkungen&
Risiken bewerten
Priorisieren
Planung der
Durchführung
Genehmigung
Implementierung
überwachen
Review&
Abschluss
in enthaltenden Changes an mehr als einem
Service verschiedener Hersteller erfordern.
Tatsächlich ist ein einheitliches Interface
erforderlich, das alle Services einer SOA
entsprechend unterstützt. Nur so kann mit
Hilfe eines zentralen Werkzeugs, einem
Cockpit, der Change-Management-Process
lösungsorientiert gesteuert und realisiert
werden. Wird ein Service ausgetauscht,
muss die Unterstützung dieses Cockpits
gewährleistet sein, um den Change-
Management-Process nicht zu stören.
Analyse der aktuellen Situation
In der Praxis wurde der Bedarf neuer Werk -
zeuge zum Teil erkannt. Einige Hersteller
von Softwarebausteinen haben für SOAbasierte
Lösungen eigene Konzepte entwi -
ckelt, wie zum Beispiel „HP OpenView”
oder „HP Quality Center”, „IBM Tivoli”
oder „SAP Solution Manager 7.x”. Allen
gemeinsam ist der Ansatz, verschiedene
technische Komponenten oder Services zentral
zu überwachen und zu administrieren.
Allerdings wird dazu jeweils ein spezielles
Interface entwickelt, um neue Services auf
Basis neuer Technologien zu integrieren.
Somit kann eine andere Technologie nur
eingebunden werden, wenn zuvor ein
Interface entwickelt wurde.
Jedes Werkzeug hat seine Stärken, insbesondere
beim Management der herstellereigenen
Produkte. Bisher wird jedoch ein
eher reaktiver Ansatz verfolgt. Erst wenn
eine Komponente oder ein Service eingesetzt
wird oder eine hinreichend große
Arbeitsaufträge
Arbeitsaufträge
Change Schedule
Abb. 2: Good Practices für den Standard-Change-Management-Process in ITIL.
Verbreitung zu erwarten ist, werden
Schnittstellen für die Überwachungs- und
Administrationswerkzeuge entwickelt, um
die komponenten- oder servicespezifischen
Techniken, Protokolle, Kennzahlen und
deren Messwerte in das Werkzeug einzubinden.
Dabei bleibt es den technischen
Komponenten selbst überlassen, was sie
bereitstellen. Welche der bereitgestellten
Methoden dann vom Administrations -
werkzeug übernommen werden, ist eine
weitere freie Entscheidung des Herstellers.
Die Interpretation von Messwerten oder
Protokollen und mögliche Reaktionen darauf
erfordern jeweils Spezialkenntnisse des
Administrators. Dadurch ist es unmöglich,
eine SOA-basierte Lösung in ihrer Ge -
samtheit zu analysieren und zu betreiben.
Stattdessen wird dem Betreiber eine werkzeug-
bzw. technologieorientierte Arbeits -
weise aufgezwungen. Um jedoch von der
Flexibilität von SOA profitieren zu können,
muss der Betrieb weitestgehend unbeeinflusst
von der verwendeten Technologie
einzelner Services bleiben. Dies ist nur
durch ein zentrales Betriebscockpit auf
Basis einheitlicher Methoden, Messwerte,
Aktionen usw. möglich. Für einige der
Anforderungen kann man allgemeine
Adapter entwickeln, die jeder Service
bedienen kann. Andere Anforderungen
werden nur erfüllt, wenn eine Art Standard
für nicht-funktionale Eigenschaf ten entwickelt
wird, die jeder Service erfüllen
muss. Abbildung 3 skizziert die Inte gration
eines Services aus unserem Kun den -
auftragsprozess, inklusive seiner Erwei -
terung um nicht-funktionale Eige nschaften
zur Unterstützung des zentralen Betriebs -
cockpits.
Bereits in die Service-Entwicklung muss
ein solches Regelwerk einbezogen werden.
Ziel muss es sein, eine Beschreibung eines
zentralen Administrationswerkzeugs auf
Basis der Standardisierung der nicht-funktionalen
Eigenschaften von Services zu liefern.
Zusammenfassung und
Ausblick
Der allgemeine Ansatz und die Qualitäts -
kriterien im IT-Betrieb bleiben beim Übergang
zu SOA-Lösungen identisch, jedoch
muss die Umsetzung lösungs- und service -
orientiert, statt system- und technologieorientiert
erfolgen. Für jede Lösung können
Qualitätskriterien unabhängig von ihrer
Architektur definiert werden. ITIL liefert
wiederverwendbare, allgemein gültige Be -
schreibungen der Prozesse in der Gover -
nance. ITIL kann somit auch weiterhin als
Stan dardwerk dienen. Die Realisierung dieser
Good Practices für SOA-basierte
Lösungen und deren gewünschter Flexi -
bilität erfordern jedoch eine Umstellung
und Ent wicklung von lösungs- und serviceorientierten
Werkzeugen zum Betrieb.
Die lose Koppelung von Services innerhalb
von SOA ist ein wesentlicher Unter -
Standardisierte
Bereitstellung von
Informationen und
Aktionen für den
Betrieb
Zentrales Betriebscockpit
Abb. 3: Schematische Darstellung der Integration von Services mit dem zentralen
Betriebscockpit.
1/2012

fachartikel
schied zum fixierten Aufbau von
Client/Server-basierten Lösungen. Um das
Potenzial der Flexibilität von SOA wirklich
nutzen zu können, wird innerhalb von SOA
ein weiterer Baustein – das zentrale
Betriebs cockpit – benötigt. Dies erfordert
auf Seite der Services eine Standardisierung
von nicht-funktionalen Eigenschaften, die
jeder Service aufweisen muss, um in eine
SOA integriert zu werden. Diese
Vereinheitlichung und Normalisierung ist
erforderlich, um das erforderliche servicespezifische
Wissen zu reduzieren.
In diesem Artikel haben wir neue An -
forderungen und Probleme angedeutet, um
zu zeigen, dass neue Methoden erforderlich
sind, um den Betrieb SOA-basierter
Lösungen zu gewährleisten. Eine einfache
Weiterentwicklung Client/Server-basierter
Techniken ist nicht ausreichend. ■
Literatur & Links
[Eva91] J.S. Evans, Strategic Flexibility for
high technology manoeuvres, in: Journal of
Management Studies 1991
[Mel08] I. Melzer, S. Eberhard, Service-orientierte
Architekturen mit Web Services. Kon -
zepte – Standards – Praxis, Spektrum Aka de -
mischer Verlag 2008
[Oas06] OASIS, Reference Model for Service
Oriented Architecture, 2006, siehe:
http://docs.oasis-open.org/soa-rm/v1.0/
[Off07] Office of Governance Commerce,
Information Technology Infrastructure Library
Version 3 Core, Liwi Verlag 2007
[Sof10] Software AG, What is the Business
Value of SOA? Show It with KPIs, 2010, siehe:
http://www.softwareag.com/de/images/SAG_SOA-
KPI_WP_Oct10-web_tcm17-56981.pdf
46 47

fachartikel
mehr zum thema:
http://www.hessen-it.de/mm/Hessen-IT_NEWS_0310.pdf
der autor
GEH MIR AUS DEM WEG!
WAS MODELLIERUNGS-
WERKZEUGE VON WHITE-
BOARDS LERNEN KÖNNEN
Viele grafische Editoren unterbrechen den Benutzer bei seiner Arbeit. Insbesondere UML-
Modellierungswerkzeuge stören den Arbeitsfluss des Entwicklers mit Pop-Ups und der
Notwendigkeit, in Werkzeugleisten herumzusuchen. Gleichwohl werden Softwarearchitekten
nicht in Mausmetern bezahlt. Um die Bedienbarkeit von grafischen Benutzungsoberflächen zu
verbessern, muss man die Menschen dabei beobachten, wie sie arbeiten. Die daraus resultierenden
Erkenntnisse können den Arbeitsablauf dann aber auch erheblich beschleunigen.
Prof. Albert Zündorf
(E-Mail: zuendorf@cs.uni-kassel.de)
leitet das Fachgebiet Softwaretechnik der
Universität Kassel. Ausgehend vom Forschungs -
projekt Fujaba unternimmt er seit über 15 Jahren
Ausflüge in verschiedenste Bereiche der Software -
technik, immer basierend auf modellgetriebener
Softwareentwicklung.
„Und wer soll das lesen können?”, ist der
häufigste Kommentar, nachdem wir ein
Klassendiagramm am Whiteboard entworfen
haben. Trotzdem ist das Arbeiten am
Whiteboard angenehmer als die Ver wen -
dung eines Modellierungswerkzeugs: Man
hat zwar viel Platz und kann das
Endergebnis fotografieren und an alle verschicken
oder einchecken – aber das macht
die Diagramme nicht unbedingt leserlicher
(siehe Abbildung 1).
Wenn die Diagramme in irgendeiner
Dokumentation verwendet werden sollen,
lassen wir sie von jemandem nachzeichnen,
frei nach dem Motto: „Make it fancy!”
„Wie heißt denn die Kante da?” „Welche
Kardinalität soll die Assoziation da unten
haben?”
Bei einer Whiteboard-Skizze fehlen häufig
auch einige Details. Der Kollege, der das
Ganze „rein zeichnen” oder später umsetzen
soll, muss dann häufig noch einmal
nachfragen, was Zeit kostet, oder er
ergänzt selbstständig, was nicht immer
richtig sein muss. Da wünscht man sich
gelegentlich doch ein Werkzeug, das einen
auf fehlende Details hinweist.
Abb. 1: Klassendiagramm am
Whiteboard.
Abb. 2: PowerPoint-„Klassendiagramm” ohne Kardinalitäten.
Unabhängig davon benötigen manche
Kollegen oder Kolleginnen für dasselbe
Diagramm viel länger als andere. Das kann
natürlich an der jeweiligen Person liegen.
Oder liegt es am verwendeten Werkzeug?
Um diese Frage zu klären, haben wir eine
(leider nicht öffentliche) Untersuchung verschiedener
Modellierungswerkzeuge durchgeführt,
deren Ergebnisse von der Hessen-
IT, der Aktionslinie des Hessischen
Wirt schaftsministeriums für den gesamten
Informations- und Telekommunikations -
markt in Hessen, veröffentlicht wurde (vgl.
[Hes10]). Dabei haben wir sowohl die
jeweils benötigte Zeit, die Anzahl der
Mausklicks und Tastaturanschläge, die
zurück gelegten Mausmeter als auch die
Häufigkeit der Wechsel zwischen Tastatur
und Maus gemessen.
Vielleicht schon einmal einige Beobach -
tungen vorweg: Es gibt Unterschiede zwischen
den Personen, aber diese sind beim
reinen Abzeichnen nicht so dramatisch.
Viel dramatischer ist die Lernkurve: Je häufiger
die Kandidaten ein und dasselbe
Diagramm gezeichnet haben, desto schneller
wurden sie. Irgendwann kannten sie das
Diagramm auswendig und sparten die Zeit,
die Details auf der Vorlage nachzuschauen.
Dieser Effekt war praktisch unabhängig
davon, welches Werkzeug die Kandidaten
in welcher Reihenfolge verwendeten. Bei
der Anzahl der Maus- und Tastaturaktion
war dagegen kaum eine Lernkurve zu
beobachten – diese Zahlen sind eher werkzeugspezifisch.
Allgemeine Zeichenwerkzeuge
„Ich hab das eben mit PowerPoint ge -
macht.” Nicht nur Heimwerker erfinden
neue Anwendungen für ihr Werkzeug.
Auch junge Studenten missbrauchen Tools
– wie „MS PowerPoint” oder „LibreOffice
Draw” – für das Erstellen von Klassen -
52 53

fachartikel
Abb. 3: Dia verdeckt das Diagramm mit Dialogen.
diagrammen (oder sogar Excel). In der Tat
lassen sich Klassen durch einfaches
Gruppieren von drei Kästchen darstellen
und Assoziationen durch Verbindungen
abbilden (siehe Abbildung 2).
Assoziations- und Rollennamen sowie
Kardinalitäten fügen sie als Textfelder ein.
Leider müssen sie sich dann auch selbst um
das Layout und die korrekte Syntax von
Attributen, Methoden und Parametern
kümmern. „Hm, ich glaub 'Magazin' oben
links und 'Autor' unten rechts sieht besser
aus.” – „Wie lange brauchst du denn für
das ganze Layouten?” – „Ist 'erstellt'
eigentlich eine Zu-Eins- oder eine Zu-N-
Assoziation?” Den Studenten in unserem
Beispiel wird langsam deutlich, dass allgemeine
Zeichenwerkzeuge zwar einfach zu
bedienen sind, ihnen aber keine inhaltliche
Arbeit abnehmen können: Die Bedeutung
von Formen, Linien, und Text bleibt den
Programmen wie einem Whiteboard verschlossen.
UML-Zeichenwerkzeuge
„Nimm Dia oder yuml.me, mit denen kann
man Klassendiagramme zeichnen!” Beides
sind völlig unterschiedliche Werkzeuge,
deren Diagramme uns aber regelmäßig wieder
unterkommen. Dia kennt die einzelnen
Artefakte eines Klassen diagramms, aber
zum Bearbeiten der Elemente müssen die
Studenten sich durch Dialoge kämpfen, die
das Klassendiagramm verdecken. Das fühlt
sich ungefähr so an, als müsse man ein
Formular ausfüllen, das das Whiteboard
verdeckt, bloß weil man eine Klasse umbenennen
möchte (siehe Abbildung 3).
Der Web-Dienst yuml.me geht einen völlig
anderen Weg. Klassendiagramme werden
in einer DSL auf einer Web-Seite formuliert
und lassen sich anschließend über
eine URL im PNG-, SVG- oder PDF-
Format abrufen oder direkt in eine Web-
Seite einbinden. Auf das Layout hat man so
gut wie keinen Einfluss, aber die Dia -
gramme sind optisch relativ ansprechend
und ohne das Starten eines Extra-Tools
schnell zu erstellen (siehe Abbildung 4).
Die gemeinsame Schwäche der beiden
Tools wird den Studenten bewusst, wenn
sie anfangen, Klassen umzubenennen.
Dann müssen sie jedes Vorkommen von
Hand ändern. „Bei der Klasse, die du
umbenannt hast, hast du vergessen, die
Verwendungen als Parametertyp auch
umzubenennen!” Punktabzug für Inkonsis -
tenz.
Mit Dialogen zum Modell
„Bei Visio kann mir das nicht passieren:
Das baut ein Modell zum Diagramm auf.”
Das ist ein großer Schritt nach vorne, denn
Visio stellt die Diagrammelemente in einem
Modell-Explorer als Baum dar. Diagramme
sind Sichten, die Teile des Modells visualisieren.
Benennt man Elemente um, werden
alle Vorkommnisse in Diagrammen entsprechend
aktualisiert. Mit Ausnahme des
Klassennamens lassen sie sich allerdings
nur mit Dialogen bearbeiten.
Abb. 4: Von yuml.me generiertes Klassendiagramm.
Bei der Auswahl von Klassen als Typ
müssen sich die Studenten leider mit einer
einfachen Liste zufrieden geben. Je größer
das Modell wird, desto länger dauert das
Heraussuchen. Und wer sich unglücklich
durch die Eigenschaften der Elemente klickt,
hat schnell drei Dialoge gleichzeitig geöffnet
(siehe Abbildung 5). „Ich sehe das
Diagramm vor lauter Dialogen nicht.”
Der Mehrwert von Modellen
„Müsst ihr immer so lange Namen nehmen,
ich tippe mir ja die Finger blutig.” –
„Versuch es doch einmal mit 'Sparx
Systems Enterprise Architect', da kriegt
man mit + Completion.”
Die meisten Softwareentwickler kennen
diese Tastenkombination aus ihrer Ent -
wicklungsumgebung. Bei Enterprise
Architect kann man damit in Dialogen
nach Klassen suchen. Noch gewohnter ist
die Kombination, wenn man eine Methode
oder ein Attribut im Diagramm mit
bearbeitet und den Typ aus einer Liste mit
Vervollständigungen aussuchen kann (siehe
Abbildung 6). Auf diese Art lassen sich
ganze Methodensignaturen überarbeiten.
Studenten, die diese magischen Tasten
kennen, kommen so fast um jeden Dialog
herum. „Wau, das geht ja wie Brezeln ba -
cken.” Unsere kleine Werkzeug-Vergleichs -
studie ergab, dass Completion die Zahl der
benötigten Tastatureingaben dramatisch –
d. h. um bis zu 30 % – verringern kann.
Studenten, die die Tastenkürzel nicht nutzten,
konnten zwar noch von der Ver -
vollständigung profitieren, mussten aber
ähnlich wie bei Visio mit Dialogen arbeiten.
Das Diagramm wieder im
Vordergrund
„Rational hat sämtliche Dialoge wegoptimiert!”
Wer mit den älteren Versionen von
Rational Rose bereits in Kontakt gekommen
ist, wird sich kaum vorstellen können,
dass IBM den jüngeren Produkten einen
komplett überarbeiteten Editor spendiert
hat. Auf Dialoge wird konsequent verzichtet.
1/2012

fachartikel
Abb. 5: Visio legt sogar mehrere Dialoge übereinander.
Klassen, Attribute und Methoden werden
direkt im Diagramm editiert (siehe
Abbildung 7). „Wow, die sind weit gekommen!”
– „Naja, nach der dritten Klasse bin
ich ziemlich genervt. Ich muss jedes Mal
zwei Sekunden warten, wenn ich auf die
Diagrammfläche klicke, um eine neue
Klasse anzulegen.” Wie bereits einleitend
erwähnt, ist die Lernkurve bei den einzelnen
Werkzeugen relativ konstant. Dafür
baut sich eine Erwartungshaltung auf: Mit
der Zeit gewöhnt sich der Benutzer an
Mauswege und Abläufe. Er lernt, wo er
hinklicken muss. Im schlimmsten Fall muss
er dadurch auf das Tool warten, statt
anders herum.
Ein Whiteboard mit Modell
„Mit UML Lab kannst du wirklich wie an
einem Whiteboard arbeiten.” Bei Yatta
Solutions wurde ein Klassendiagramm-
Editor entwickelt, mit dem man seine
Klassen wie auf einem Whiteboard zeichnet
und dabei mit Vervollständigung aus
dem Modell unterstützt wird. Das Anlegen
von Klassen geschieht durch das Aufziehen
eines Rechtecks auf dem Diagramm.
Danach ist die Klasse selektiert und man
kann damit beginnen, Klassenname sowie
Attribut- und Methodensignaturen einzutippen.
Ähnlich wie bei Rational Software
Architect wird eine Vervollständigung
angeboten, die aber zwischen Klassen im
Diagramm und Modell unterscheiden
kann. Verbindungen zwischen den Klassen
werden mit der rechten Maustaste von
Klasse zu Klasse gezogen.
Diagrammelemente können überarbeitet
werden, indem man sie selektiert und einfach
anfängt zu tippen (siehe Abbildung 8).
„Beim Aufziehen von Klassen hat man wieder
das Gefühl, selbst ein Diagramm zu
zeichnen, aber warum muss ich das noch
selbst machen, wenn die Informationen
doch schon im Quellcode vorliegen?”
Agiles Reverse-Engineering
„Hast du einmal versucht, Code wieder
ein zu lesen?” Hier beginnt eine weitere Lei -
densgeschichte unserer Studenten. Sobald
Quellcode vorliegt, will niemand mehr die
Abb. 6: Enterprise Architect blendet passende Modellelemente ein.
54 55

fachartikel
Abb. 7: Rational Software Architect verzichtet vollständig auf
Dialoge.
Abb. 8: Vervollständigung und Arbeiten im Diagramm bei UML
Lab.
Klassendiagramme dafür selbst zeichnen. Alle professionellen
Modellierungswerk zeuge bieten das Einlesen von Quellcode an,
aber von den Ergebnissen sind die Studenten mehr als enttäuscht.
„Warum hat er die Assoziation jetzt nicht erkannt?” – „Warum
hat er die Getter und Setter für den Namen ausgeblendet, aber für
die Adresse nicht?” –„Na toll, die Klasse passt ja nicht mal auf den
Bildschirm!”
Technisch arbeiten die meisten Tools mit einer Heuristik, die versucht,
zusammengehörige Artefakte wieder zusammenzufassen. Bei
Zugriffsmethoden für JavaBean-Properties funktioniert das noch
relativ gut. Heuristiken versagen allerdings bei angepassten
Zugriffsmethoden oder Asso ziationsimplementierungen.
UML Lab beschreitet hier einen interessanten neuen Ansatz, bei
dem Imple mentierungsdetails über ein template-basiertes Reverse-
Engineering vor dem Modell verborgen werden. Je mehr
Implementierungsdetails man in Templates beschreibt, desto übersichtlicher
werden die Klassendiagramme. „Ich hab ein eigenes
Template für unseren PropertyChange-Mechanismus geschrieben.
Jetzt zeigt er das als Stereotyp für das Attribut an, anstatt Getter
und Setter im Diagramm zu zeigen. Die sind ja ohnehin überall
gleich implementiert.”
Kontextbezogene Diagramme
„Mich interessiert so einiges nicht, was ich im Klassendiagramm
sehe. Kann man nicht nur die Elemente anzeigen, an denen man
gearbeitet hat, wie bei Mylyn?” Wer schon einmal die Übersicht
über den eigenen Quellcode verloren hat, sollte sich mit den
Produkten von Tasktop beschäftigen. Mittlerweile gehört Mylyn
zum Bestandteil der Eclipse-IDE und auch eine Visual-Studio-
Integration ist verfügbar. Mylyn lernt, welche Methoden in einem
bestimmten Kontext, z. B. bei der Arbeit an einem Ticket, aus
einem Bug-Tracker verwendet wurden. Alle anderen Elemente werden
ausgeblendet: Im Project Explorer verschwinden nicht berührte
Klassen und Packages, nicht relevante Break-Points werden ausgeblendet
und lediglich der relevante Kontext bleibt übrig.
Yatta Solutions hat dieses Konzept in UML Lab auch auf
Klassendiagramme übertragen. Mit der Mylyn-Integration wird es
möglich, sich ein Klassendiagramm anzeigen zu lassen, in dem nur
die für einen Task relevanten Klassen, Attribute und Methoden
sichtbar sind, ohne dass man selbst zeichnen muss. Die Übersichtlichkeit
von Klassendiagrammen wird so auch in agilen Projekten
auf Knopfdruck nutzbar.
Verteiltes Arbeiten
„Super, wir haben jetzt das grobe Modell zusammen. Am besten
macht jeder von euch die Feinmodellierung für sich und wir treffen
uns morgen wieder, um das zusammenzuführen.” Eigentlich ist das
eine Horrorvorstellung für jeden, der schon eimal versucht hat,
Modellinformationen zu mischen. Woran liegt das?
Wenn mehrere Leute an dem gleichen Modell arbeiten wollen,
gibt es im Wesentlichen zwei Möglichkeiten: Entwe der hat man ein
mehrbenutzer-fähiges Tool, wie zum Beispiel TeamViewer oder
Google Docs, oder ein altes CASE-Tool, das die Modelle in einer
zentralen Datenbank editiert. Das heißt: Eigentlich arbeiten alle
auf dem gleichen Modell, nur mit vielen Mäusen und Tastaturen –
oder jeder hat seine eigene Modellkopie. Jeweils eigene Kopien der
Modelle zu haben, entkoppelt die einzelnen Modellierer. Jeder
kann seine Änderungen in Ruhe ausprobieren, ohne von den Änderungen
der anderen gestört zu werden. Aber wenn jeder seine eigene
Modellkopie hat, muss man die verschiedenen Änderungen
nachher wieder in eine gemeinsame Version zusammenführen. Bei
Quelltext macht man das mit Versions verwaltungssystemen wie
Subversion oder Git, wo das auch prima klappt. Bei Modelldateien
klappt das normalerweise gar nicht. Nach dem Merge sind die
Modelldateien nicht mehr ladbar und man muss mühsam in den
XML-Formaten herumbasteln, damit man überhaupt weiter arbeiten
kann. Abhilfe schaffen hier nur meist sehr teure
Modellierungswerkzeuge, die die Modelle selbst versionieren können.
Oder man nimmt einen universitären Prototyp wie Fujaba
oder SiDiff.
Neuerdings gibt es hier eine dritte Alternative durch Werkzeuge
mit guter Round-Trip-Engineering-Funktionalität. Jeder generiert
aus seiner Modellkopie einfach Quelltext, der dann versioniert und
gemerged wird. Nach dem Merge lädt man den Quelltext wieder
ins Model lierungswerkzeug – voila. Merge-Konflikte muss man
zwar auf der Quelltext-Ebene behandeln, aber das ist allemal besser
als in den XML-Modell-Dateien. Insgesamt funktioniert das bei
unseren Studenten mit UML Lab schon ganz gut. Man verliert
1/2012

fachartikel
Whiteboard
PowerPoint/
Libre Draw
Dia
yuml.me
Visio
Enterprise
Architect
Software
Architect
UML Lab
und Yatta Solutions haben für die
Werkzeuge „Papyrus” respektive „UML
Lab” bereits Prototypen für einen grafischen
Merge gezeigt, mit denen sie dieses
Problem angehen wollen.
Grafischer Editor ● ● ● ○ ● ● ● ●
Layout anpassbar ● ● ● ○ ● ● ● ●
Autolayout ○ ○ ○ ● ● ● ● ●
Modell ○ ○ ○ ○ ● ● ● ●
Views ○ ○ ○ ○ ● ● ● ●
Layers/Filter ○ ○ ○ ○ ● ● ● ○
Auto-Completion ○ ○ ○ ○ ○ ● ● ●
Dialogfrei ○ ● ○ ● ○ ○ ● ●
Wartezeitfrei ○ ● ● ○ ● ● ○ ●
Gestenerkennung ○ ○ ○ ○ ○ ○ ○ ●
Anpassbare Codegenerierung ○ ○ ○ ○ ○ ● ○ ●
Templates zum
Reverse-Engineering ○ ○ ○ ○ ○ ○ ○ ●
Round-Trip-Engineering ○ ○ ○ ○ ○ ○ ○ ●
Kontextbasierte Diagramme
(Mylyn Integration) ○ ○ ○ ○ ○ ○ ○ ●
Alle 14 UML-Diagrammarten ● ○ ○ ○ ● ● ● ○
Gemeinsames Modellieren ● ○ ○ ○ ○ ○ ○ ●
Verteiltes Arbeiten ○ ○ ○ ○ ○ ○ ○ ●
Geeignet für
[Hes10] Hessisches Ministerium für
Wirtschaft, Verkehr und Landesentwicklung,
Hessen-IT News, 2010, siehe: http://www.hessen-it.de/mm/Hessen-IT_NEWS_0310.pdf
Teambesprechung
Präsentationen
–
Darstellung von Reverse
Engineering Webseiten
Vermischen von
Diagrammarten
Design
Design
Round Trip,
Agiles Arbeiten
Fazit
Einfache Modellierungswerkzeuge wie Dia
oder Visio stehen dem Entwickler häufig im
Weg, da sie Teile des Diagramms unter
Dialogen begraben. Die professionellen
Werkzeuge von Sparx Systems und IBM
haben dieses Stadium größtenteils hinter
sich gelassen. Sie bieten die Möglichkeit, im
Diagramm zu arbeiten, und beschleunigen
die Arbeit, indem sie eine Vervoll ständi -
gung basierend auf dem Modell anbieten.
UML Lab ging aufgrund der neuen
Eingabemöglichkeiten im Klassendia -
gramm-Editor bereits in unserer Studie als
Sieger hervor. Die damals erreichten 16 %
Zeitersparnis kann es mit template-basiertem
Reverse-Engineering und kontextbasierten
Klassendiagrammen noch weiter
steigern. Die in diesem Artikel angesprochenen
Werkzeuge, Bewertungskriterien
und Einsatzzwecke fasst Tabelle 1 zusammen.
Viel wichtiger ist jedoch, dass Model -
lierungswerkzeuge nicht mehr nur Pro -
bleme am Anfang des Entwicklungs -
prozesses lösen. Sie dringen in die
Implementierungsphase vor, werden selbst
flexibler und helfen so, auch bei agilem
Vorgehen den Überblick über große
Software zu behalten.
Der Trend geht endlich in die richtige
Richtung. Es wird Zeit, dass Software -
entwickler sich nicht mehr mit umständlichen
Werkzeugen selbst quälen. Auf
meinem Tablet kann ich jetzt Klassen -
diagramme entwerfen, als wäre es ein intelligentes
Blatt Papier. Fehlt nur noch ein sechs
Quadratmeter großer Touchscreen. ■
Tabelle 1: Werkzeuge, Bewertungskriterien und Einsatzzwecke.
Link
zwar manchmal etwas Layout, aber die
logischen Dinge kriegt man ganz gut
zusammen.
Neben dem Merge möchte man manchmal
auch die Änderungen, also das Diff auf
Modellebene, angezeigt bekommen. OBEO
56 57

fachartikel
der autor
MIGRATIONSMANAGEMENT:
FALLSTUDIE ZUR MIGRATION
EINER INDUSTRIELLEN
RICH-CLIENT-ANWENDUNG
Die IT-Welt ist in einem ständigen Wandel begriffen. Softwaresysteme, die heute konstruiert
werden, sind sehr wahrscheinlich schon bald Altsysteme und müssen migriert werden. Das
bestätigt auch ein aktuelles Migrationsprojekt aus der Pharmaindustrie, dessen technologischer
Stand eher als „State of the art” bezeichnet werden kann. Am Beispiel dieses Projekts
geht der Artikel den Fragen nach, warum und wie migriert wurde. Konkret handelt es sich um
eine Rich-Client-Anwendung, die auf die OSGi-Plattform Eclipse migriert wurde, um modular zu
sein, was nicht zuletzt mit dem Ziel der Auslagerung einer Modulentwicklung nach China
zusammenhängt.
Eldar Sultanow
(E-Mail: sultanow@xqs-service.com)
ist CIO der XQS-Service GmbH, die zur in Hof ansässigen
Firmengruppe Max Service International AG
gehört. Er ist verantwortlich für internationale
Projekte mit Schwerpunkt auf JEE-Architekturen,
Web-Technologien und RFID-Anwendungen.
Bei dem in diesem Artikel beschriebenen
Beispiel handelt es sich um ein Pharma -
industrieprojekt, mit dem eine Infrastruk -
tur für die Fälschungs- und Qualitäts -
sicherheit von Arzneimitteln aufgebaut
wurde. Die Pharmaindustrie ist ein spezielles
Umfeld, das sich mit wenigen Beispiel -
ereignissen treffend beschreiben lässt.
Innerhalb von nur zwei Monaten konfiszierte
die EU bei gezielten Zollkontrollen in
allen Mitgliedsländern 34 Millionen ge -
fälschte Tabletten (vgl. [Schl09]). Laut
Weltgesundheitsorganisation (WHO) enthalten
60 % der gefälschten Arzneien keinen
Wirkstoff, 19 % enthalten eine falsche
Wirkstoffmenge und 16 % komplett falsche
Wirkstoffe (vgl. [Schw07]). Hierbei
tauchen 70 % der Arzneimittelfälschungen
in den Entwicklungsländern auf. Das jährliche
Umsatzvolumen mit Arzneimittel -
fälschungen wird auf 100 Milliarden US-
Dollar geschätzt. Im Jahr 2009 wurden
Chargen von HIV-Medikamenten aus deutschen
Apotheken zurückgerufen und im
selben Jahr gab es Chargenrückrufe, die
sich auf (gesundheitsgefährdende) Quali -
täts mängel wie z. B. bakterielle Konta -
minierung beziehen. Letztes Jahr starben
drei Säuglinge an einer verunreinigten
Infusion in der Klinik Mainz. Zu Beginn
dieses Jahres hat die Integrierte Ermitt -
lungseinheit Sachsen (INES) Ermittlungen
wegen banden- oder gewerbsmäßiger
Bestechung von Ärzten durch einen Leip -
ziger Parenteral-Hersteller 1 ) und Apotheker
eingeleitet.
1
) Ein Parenteral-Hersteller ist ein Hersteller von sterilen
Zubereitungen, die zur Injektion, Infusion oder
Implantation bestimmt sind.
Abb. 1: Infrastruktur für Fälschungs- und Qualitätssicherheit in der Pharmaindustrie.
58 59

fachartikel
Abbildung 1 zeigt schematisch die technische
Infrastruktur für Fälschungs- und
Qualitätssicherheit von Arzneimitteln. Sie
liegt dem Track & Trace – von der Medi -
kamentenherstellung bis hin zur -abgabe –
zu Grunde und wird derzeit im onkologischen
Bereich eingesetzt. Hersteller senden
ihre Originalprodukte an das Pharma-
Trust-Center, das diese mit RFID kennzeichnet
und in einer zentralen Datenbank
serialisiert. Die gesicherten Produkte gelangen
weiter in den Großhandel, in
Apotheken und Kliniken. Diese besitzen
jeweils ein oder mehrere Terminals zur
Verifizierung von Arzneimittelpackungen
und zur Überprüfung der Temperaturen.
Lieferungen sind hierzu mit einem RFIDbasierten
Temperatur-Logger ausgestattet.
Die Herkunft und der Distributionsweg
von Arzneien sowie die während Lagerung
und Transport gemessene Temperatur werden
damit nachvollzogen. Das ist wichtig,
weil das Verletzen des vorgeschriebenen
Temperaturintervalls (2–8 °C) kühlpflichtiger
Zytostatika zu Wirksamkeitsverlust
und schließlich zum Behandlungsmisserfolg
von schwer kranken Patienten führt.
Das Softwaresystem
Um sich ein genaueres Bild von der Art und
Größe der migrierten Anwendung machen
zu können, beschreibe ich im Folgenden
das Softwaresystem und charakterisiere seine
wesentlichen Bestandteile anhand von
Codezeilen (LoC).
In Abbildung 2 sind die Systemarchi -
tektur und -komponenten dargestellt. Die
eingesetzte Hardware umfasst RFID-
Lesegeräte. Der Tunnel-Reader ist ein Pulk-
Lesegerät, das mehrere 100 gekennzeichnete
Packungen in einem Schritt binnen
Millisekunden liest. Die Terminals enthalten
Einzel-Lesegeräte für das Steuern und
Auslesen der Temperatur-Logger sowie für
die Erfassung und Verifikation einzelner
Packungen und Infusionsbeutel.
Auf jedem Terminal ist eine Rich-Client-
Anwendung installiert, die über die (in
C/C++ geschriebene) XQS-Edgeware sämtliche
RFID-Lesegeräte ansteuert und über
XML-RPC/SOAP-Services Daten zur Arz -
neimittel-Verifikation aus der zentralen
Pharma-Datenbank abfragt und Tempera -
tur-Messreihen in der Datenbank speichert.
Diese Rich-Client-Anwendung steuert
ebenfalls (über die Edgeware) Pulk-Lese -
geräte an und serialisiert massenweise
Arzneimittelpackungen. Bei dem hier thematisierten
Migrationsprojekt handelt es
Abb. 2: Systemarchitektur und Komponenten der XQS-Infrastruktur (XQS =
Maximale Qualitätssicherheit).
sich genau um diese Rich-Client-Anwen dung. Die Art und Größe der genannten
Komponenten fasse ich hier kurz zusammen:
■ Edgeware (9.476 LoC): Die Edgeware umfasst in der Programmiersprache C/C++ entwickelte
Werkzeuge für Linux, Windows und Windows CE zur Ansteuerung der
RFID-Lesegeräte: Pulk-Lesegeräte (Tunnel-Reader), Ein zel-Lese geräte (Terminals) und
mobile Lesegeräte in Handhelds.
■ Web-Portal (16.726 LoC): Das Portal ist eine Web-Anwendung für den auf OSGi
(Open Services Gateway initiative) basierenden Applikationsserver „Virgo” (vgl.
[Sul10a]). Es umfasst: „Spring Controller”, „Java Server Pages”, „Cascading Style
Sheets”, „Java Scripts” und das „Object Relational Mapping” (ORM), basierend auf
dem JPA-Standard und der Referenzimplementierung „Eclips eLink”.
■ Rich-Client-Anwendung (23.324 LoC, 20.030 LoC nach Migration): Die
Ausgangsversion basiert auf Swing im Frontend und JPA (Java Persistence API) mit
Hibernate im Backend. Das Transaktionsmanagement übernahm „Atomikos”, weil es
in selbstständigen Desktop-Applikationen einsetzbar ist. Die gesamte Anwendung verwendete
das Spring-Framework, das ihren strukturellen Aufbau auf deklarative Weise
beschreibt.
■ Web-Dienste (4.842 LoC): Die Web-Dienste sind ein Sammelsurium unabhängiger
XML-RPC- und SOAP-Ser vices.
Die Rich-Client-Anwendung wird aktuell an 12 Lesestationen eines Pharmagroß handels,
an 8 Lesestationen in Apotheken und auch mittlerweile in der Lebensmittel industrie eingesetzt.
Insbesondere stellt die Temperatur-Sensorik (siehe Abbildung 3) eine interessante
Anwendung für den Lebensmittelgroßhandel dar. Bevor die Temperatur-Logger dem
Arzneimittel-Paket hinzugefügt werden, müssen sie scharf geschaltet werden (links). Nach
ihrer Ankunft in der Klinik oder Apotheke werden die Temperaturen ausgelesen (rechts).
Warum die Software technologie wechseln?
Die eingesetzten Frameworks sind nicht obsolet und gehören eher der neuen Generation
an. Was führte dennoch zu dem Gedanken, einen Technologiewechsel im Rahmen eines
umfangreichen Migrations projekts durchzuführen?
1/2012

Nicht geplante Produktderivate brachten das Spring-Framework
schnell an seine Grenzen und waren sicher der Hauptgrund für die
Migration. Funktionen bei Bedarf zu ergänzen, anzupassen oder zu
entfernen, gestaltet sich ohne den Einsatz eines Plug-In- bzw.
Modul-Systems als schwierig. Eine nicht ohne Weiteres abzubildende
Anforderung bestand beispielsweise darin, neben
Temperatur- auch Schock-Sensoren zu integrieren und eine
Administrator-Version mit erweiterten Funk tionen zu erstellen –
und dies in jeder möglichen Kombination. Das richtige Stich wortet
hierfür lautet „Produktlinien-Architektur” und ein etablierter
Standard ist OSGi, der dazu dient, Software zu modularisieren und
über ihren gesamten Lebenszyklus hinweg zu verwalten (vgl.
[Lie08]). Das der Modularisierung zu Grunde liegende
Komponentenmodell besteht aus so genannten Bundles (auch als
Services bezeichnet), deren Lebenszyklus die Service-Registry verwaltet.
Wie wurde das Plug-In-Problem vorerst mit dem Spring-
Framework gelöst? Für jeden Anwendungsfall wurde je eine entsprechende
Spring-Kontextdatei angelegt. Diese Lösung ist jedoch
ungeschickt, weil im Quellcode manuell geprüft werden muss, ob
optionale Komponenten vorliegen oder nicht, die dann auf proprietäre
Weise eingebunden und in der graphischen Benutzungs -
oberfläche verfügbar gemacht werden.
Begrenzungen des Umfangs und der Performance von Swing
bekräftigten die Entscheidung für eine Migration. Die Swingfachartikel
Abb. 3: Temperatur-Sensorik und Pulk-Lesen mit der ursprünglichen
Anwendung.
Oberfläche ist langsam, nicht son derlich schön und wenig umfangreich.
So ist beispielsweise keine Task-Leiste standardmäßig
enthalten, die zusätzlich aus SwingX, ein offenes Swing-Er -
weiterungs paket, übernommen wurde.
Die externe Entwicklung funktionaler Bausteine lässt sich auf
einfache Weise bewerkstelligen, wenn Schnittstellen für die zu entwickelnde
Anwendung definierbar und öffentlich sind. Der
Projektinhaber gründete ein deutsch-chinesisches Joint-Venture
HEMSN in der chinesischen Hafen stadt Dalian mit zwei Zustän -
dig keiten: Pharma und IT. Einen Großteil der Entwicklung sollen
nun die Entwickler in China übernehmen (siehe Abbildung 4).
Auch hier ist OSGi das Stichwort, unter dem das Konzept für die
Modularisierung und unabhängige Entwicklung funktionaler
Bausteine (Plug-Ins) fällt.
Produktlinien-Architektur
Im zuerst genannten der drei obigen Punkte zum Beweggrund des
Softwaretechnologie wechsels fiel das Stichwort „Produktlinien-
Architektur”. Diese ist das Kernstück einer Produktlinie und legt
fest, wie aus den Produktanforderungen das jeweilige Deri vat bzw.
die jeweiligen Produktlinien-Komponenten erstellt werden können
(vgl. [Zac07]). Jedes Produkt derivat muss dabei ein eigenes
Branding und – wie bereits erwähnt – unterschiedliche bestimmte
Features besitzen können. Die Produktlinien-Architektur ermöglicht
es, diverse Brandings anzulegen und einzelne Features wegzu-
Abb. 4: Outsourcing der Komponentenentwicklung für Pharma
& IT veranlasste die Migration der gesamten RFID-Anwendung
zur Fälschungs- und Qualitätssicherung onkologischer
Medikamente. Mittlerweile wurden vier Aufträge entsprechend
den formulierten Anforderungen abgewickelt.
60 61

fachartikel
konfigurieren. Im Fall von OSGI/Eclipse
sind das so genannte Pro duktkon -
figurationen, die in Form von XML-
Dateien vorliegen und genau spezifizieren,
welche Bundles und branding-spezifischen
Elemente beim Produktexport verwendet
werden sollen. Eclipse 4 re prä sentiert hierbei
als Plattform die Referenzarchitektur
mit dem Ziel, dass alle Mitglieder des
Produktlinien-Teams ein gemeinsames
Verständnis vom Aufbau der Komponenten
und Produkte besitzen. Damit einhergehend
stehen während des Produktions -
prozesses die fachliche Archi tektur und die
Diskussion über fachliche Schnittstellen,
Prozesse und Services im Fokus. Die technische
Architektur muss nach einer gewissen
Zeit so selbstverständlich sein, dass sie
intuitiv verwendet wird und nicht wie in
vielen Entwicklungs vorhaben Gegenstand
der typischen Diskussionen, wie etwa
„Sollen wir nicht doch Hibernate anstelle
von EclipseLink verwenden?”, ist (vgl.
[Zac07]).
Die Produktlinien-Architektur setzt eine
stark ausgeprägte Komponentenorien -
tierung voraus, die voneinander unabhängige,
jedoch kombinierbare Module mit
definierten Schnittstellen erzwingt. In OSGi
werden die Module durch Bundles und
Plug-Ins (z. B. für die Temperatur-Sensorik
oder für das Pulk-Lesen) abgebildet, wobei
die Modulschnittstelle auch klar angibt,
von welchen Bundles und Plug-Ins das
Modul wiederum abhängt.
Die zentrale für die gesamte Produktlinie
gültige Referenzarchitektur stellt für alle
Produkte und Produktderivate die Erfül -
lung sämtlicher nicht-funktionaler Anfor -
derungen (Performance, Verfügbarkeit,
Skalierbarkeit, Robustheit usw.) sicher, da
diese Anforderungen durch die Architektur
selbst abgedeckt werden.
Migration und Outsorcing
Ein entscheidender Vorteil von Modu -
larisierung besteht darin, dass sich Module
unabhängig von Teams entwickeln lassen –
und dies an weltweit entfernten Stand -
orten. Ein Großteil des Kommunikationsund
Koordinierungsbedarfs entfällt durch
die erzwungenen Modulschnittstellen. Das
heißt, eine permanente Rückkopplung zwischen
dem die Module entwickelnden
Team und dem Produktverantwortlichen –
also dem, der die Produkte für die Kunden
zusammenstellt und exportiert – ist nicht
mehr notwendig. Dasselbe gilt für die
Vier elementare Ausgangssituationen liegen dem heutigen Migrationsmanagement zu
Grunde und bilden die Basis des in Abbildung 5 dargestellten Situationsmodells. Der
geschilderte Praxisfall trifft passgenau auf Situation 1 zu: Obwohl die Technologie
aktuell ist, erfüllt sie die neuen Anforderungen nicht mehr. Situation 2 stellt den Idealfall
dar: Die eingesetzte Technologie ist aktuell und deckt alle gegenwärtigen und bestenfalls
auch künftigen Anforderungen ab. Dennoch kann Situation 2 mit der Zeit in Situation
3 oder 4 übergehen. Situation 3, also das zunehmende Übergewicht neuer Anforderun -
gen an eine mittlerweile obsolete Technologie, ist derzeit der am weitesten verbreitete
Fall: Etwa 70 % der unternehmerischen Daten und Geschäftsprozesse werden in
Altsystemen abgewickelt (vgl. [Sul10b]). In Situation 4 erfüllen die Altsysteme nach wie
vor alle Anforderungen und müssen nicht unbedingt migriert werden. Dennoch gibt es
mehr oder weniger rationale Beweggründe, trotzdem zu migrieren: Entweder, um sich
vorsorglich gegen einen am Horizont sichtbaren Ansturm neuer Anforderungen mit etablierten
Technologien zu wappnen oder um einfach nur den aktuellen Trend der
Softwareentwicklung zu erfüllen.
Abb. 5: Vier grundlegende Situationen des Migrationsmanagements.
Anforderungs- versus Trenderfüllung
Das Gesetz von Moore [Moo65] beschreibt den IT-Wandel mit einer Verdopplung der
Prozessor-Leistungsfähigkeit alle 18 Monate. Betriebssysteme müssen im Rhythmus von
36 Monaten für jede zweite Prozessorgeneration erneuert werden. Ihre Veränderung
wirkt sich auf Programmumgebung und Datenbanksysteme aus, die alle fünf Jahre angepasst
bzw. neu entwickelt werden müssen, woraus eine fünfjährige Halbwertzeit für
Anwendungssoftware resultiert (vgl. [Sne10]). Der Preisfall des Datentransports nach
dem Gesetz von Metcalfe (vgl. [Met95]) schafft eine Überkapazität an Kommunikations -
einrichtungen, die IT-Nutzer sinnvoll in Anspruch nehmen sollen und hierzu ihre
Anwendungen neu ausrichten müssen. Aus dem wirtschaftlichen Konkurrenzkampf, der
eine Anpassung an die veränderten Wettbewerbsbedingungen verlangt, resultiert zusätzlicher
Druck aus dem Markt: Unternehmen müssen sich geschäftlich anders aufstellen
und schneller, besser und flexibler auf die globale Nachfrage reagieren (vgl. [Sne10]).
Der Anspruch an die Änderbarkeit und Erweiterbarkeit von Anwendungssoftware
bedarf wiederum neuer Sprachen und Entwicklungsumgebungen.
Zu dem Trend der Leistungssteigerung von Hardware und der sich schneller ändernden
Anforderungen kommt ein personeller Trend hinzu: der Rückgang von Experten, die die
Altsysteme entwickeln und warten. Viele Anwendungssysteme sind für die Anwender
ohne geschäftskritische Relevanz und werden von Nicolas Carr (vgl. [Car03]) lediglich
als „Commodity” bezeichnet. Also spielt weniger die Funktionsweise als vielmehr die
Funktionsfähigkeit eine Rolle. Dennoch müssen auch solche Systeme gepflegt werden,
und irgendwann stirbt das „Pflegepersonal” aus, da junge Entwickler kaum bereit sind,
sich in alte Sprachen und Umgebungen einzuarbeiten (vgl. [Sne10]). IT-Manager sehen
sich immer häufiger dem Problem gegenüber, dass sie kein Personal mehr finden, um das
alte System zu pflegen. Ausgerechnet heute, wo die erste Entwicklergeneration die Bühne
verlässt, ist das Thema Migration aktueller denn je und sämtliche Eigenentwicklungen
der 70er- und 80er-Jahre stehen zur Disposition.
Kasten 1: Migrationsmanagement heute.
1/2012

fachartikel
Rückkopplung zwischen Modul- und
Architekturentwicklern. Erstere befassen
sich mit der Abdeckung funktionaler und
letztere mit der der nicht-funktionalen
Anforderungen. Weil die Referenzarchi -
tektur die Softwareentwicklung hinsichtlich
beider Anforderungen strikt trennt,
kann nun nach der Migration die Ent -
wicklung von Features ohne großen
Aufwand an die Entwickler des chinesischen
Partners übergeben werden. Die
Rückintegration bzw. Einbindung der off -
shore entwickelten Module erfolgt gemäß
OSGi automatisch, da die Modulent -
wickler die von der Referenzarchitektur
vorgegebenen und daher nicht umgehbaren
Schnittstellen verwenden müssen.
Mit der ursprünglichen auf dem Spring-
Framework basierenden Anwendung war
dies nicht möglich. Entwickler hätten
„irgendwelche” Klassen entwickeln, diese
an beliebiger Stelle in den Spring-Kontext
einbinden und dabei auch noch (unbewusst)
Eingriff in die gesamte Anwen -
dungsarchitektur nehmen können. Ein
ordentliches gemeinsames Entwickeln an
dem Projekt wäre ohne größeren Aufwand
nicht möglich: Schulungen, Erläuterungen
der proprietären Architektur, Schnitt -
stellen, Programmier-Richtlinien, zu verwendende
Frameworks/Packages usw.
wären erforderlich gewesen.
All dies wird ja bereits mit OSGi vorgegeben.
Letztendlich werden beim Export
der Produktversionen die Module einfach
eingeklinkt, wobei deren „Innereien” völlig
gekapselt sind. Die Praxis hat dennoch
gezeigt: Auch wenn Module nach dem
Black-Box-Prinzip offshore entwickelt und
mühelos in die neue migrierte Anwendung
eingebunden werden können, lohnt sich ab
und zu ein Blick auf das Modul-Innen -
leben.
barkeit” getrieben, der mit den zwei
Hauptzielen, Produktvarianten zu erstellen
und die Entwicklung nach China auszulagern,
im Zusammenhang steht. Deshalb
war für die Analyse der Migrationsnutzen
unbestritten. Die Anforderung an die
Modularisierbarkeit im Hinblick auf das
Erstellen von Produktvarianten und das
Outsourcing standen deutlich im Vorder -
grund:
■ Konfigurierbarkeit von eigenem
Branding: Jede Produktvariante muss
mit einem eigenen Branding (Begrü-
ßungsbildschirm, Titel, Programm-Icon
usw.) ausstattbar sein, damit ein unabhängiger
Vertrieb durch Dritte erfolgen
kann. Man spricht hierbei von einem so
genannten „Weißprodukt” (White-
Label-Produkt).
■ Kombinierbarkeit von Funktionen zu
Funktionsbündeln: Eine Produkt -
varian te definiert sich über das Kombi -
nieren von Funktionen, die sowohl
Standardfunktionen als auch individuelle
Erweiterungen sein können. Das
Bündeln dieser Funktionen muss in
einem simplen Arbeitsschritt durchführbar
sein.
■ Auslagerbarkeit nach dem Black-Box-
Prinzip: Für das Outsourcing der
Entwicklung von Funktionen bzw. von
Funktionsbündeln darf keine Offen -
legung interner Anwendungsbestand -
teile erforderlich sein. Funktionen müssen
autonom, lose gekoppelt und
mittels Schema gemäß einem Vertrag
definiert sein.
Diese drei Hauptanforderungen liegen der
Wahl einer geeigneten Zielplattform zu
Grunde.
Wahl der Zielplattform
Die Kombinierbarkeit von Funktionen und
die Auslagerbarkeit von deren Entwicklung
nach dem Black-Box-Prinzip führten zu
dem Standard OSGi, der speziell zur
Abdeckung dieser Anforderungen entwi -
ckelt wurde. Die Eclipse Rich Client
Platform (RCP) ist eine Implementierung
der OSGi-Spezi fikation und ermöglicht das
Umsetzen modu larer Applikationen, die
aus Plug-Ins bestehen. Damit sich die Wahl
der OSGi-Technologie oder genauer gesagt
Eclipse RCP endgültig treffen ließ, waren
funktionale sowie strukturelle Anfor -
derungen der zu migrierenden Anwendung
abzugleichen. Hierzu zählten eine Dia -
grammfunktion im Frontend, ein Persis -
tenz-/ORM-Frame work im Backend und
die Anwendbarkeit des vom Spring-Frame -
work bekannten Entwurfsmuster
Dependency Injection (DI). Dieser Ab -
gleich konnte schnell vollzogen werden: In
Eclipse ist das freie Werkzeug Business
Intelligence and Reporting Tools (BIRT)
enthalten, das eine umfassende Diagrammund
Report-Erstel lungsfunktion besitzt.
Eclipse liefert weiterhin EclipseLink für das
objekt-relationale Mapping und folgt in
seiner vierten Version auch dem DI-
Entwurfsmuster mittels An no tationen.
Damit fiel die Wahl der Eclipse-RCP als
Zielplattform leicht und man wendete sich
dem nächsten Schritt zu: dem Schätzen des
Aufwands für den Quellcode-Transfer.
Aufwandsschätzung des Transfers
Die eigentliche Umsetzung besteht in dem
Transfer des gesamten Quellcodes. Der
Aufwand wurde in den Systemschichten
Frontend, Backend und übergreifendes
Basissystem geschätzt (siehe Tabelle 1). Das
Fünf Hauptschritte
der Migration
Die Migration des Projekts erfolgte in fünf
wesentlichen Schritten: Migrationsanfor -
derungs analyse, Wahl der Zielplattform,
Aufwandsschätzung, Quellcode-Transfer
(die eigentliche Umsetzung) in die Ziel -
plattform und abschließende Validierung
der neuen Applikation.
Migrationsanforderungsanalyse
Die Migration des Industrieprojekts wurde
primär von dem Aspekt „Modularisier -
Ausgangstechnologie Zieltechnologie Geschätzter Migrationsaufwand
Frontend Swing, SwingX, SWT, JFace Programmierung 20 MT (Mittel)
JGoodies
der GUI
Event-Verwaltung 5 MT (Niedrig)
Backend JPA, Hibernate JPA, EclipseLink 20 MT (Mittel)
Basissystem Springframework E4/RCP Plug-In-Entwicklung 40 MT (Hoch)
und Integration
Produktkonfiguration 5 MT (Niedrig)
und -export
Tabelle 1: Geschätzter Aufwand der eigentlichen Umsetzung.
62 63

fachartikel
Schätzen erfolgte gemäß der Breitband-
Delphi-Methode, zu der die an der Um -
setzung beteiligten Experten (drei Ent -
wickler und ein Architekt) herangezogen
werden.
Die höher geschätzten Aufwände – 20
und 40 Personentage (PT) – weichen in vertretbarer
Weise von den tatsächlich
erbrachten Aufwänden ab: Die Abwei -
chungen liegen jeweils unter einer Woche
(5 PT). Demzufolge war der Transfer des
Basissystems am aufwändigsten, denn hier
war eine Einarbeitung in die neue Tech -
nologie „E4” und das Durchlaufen der
damit verbundenen Lernkurve erforderlich.
Die mit dem Umsetzen des Frontends und
Backends verbundenen Aufwände waren
geringer. Dazu hat insbesondere die (im
Backend gelagerte) standardisierte JPA-
Schnittstelle beigetragen.
Quellcodetransfer auf die Zielplattform
Der Quellcodetransfer – sprich: die Pro -
grammierung an sich – erfolgte reibungslos
und konnte gemäß der Schichtengliederung
in Tabelle 1 parallel durchgeführt werden.
Das heißt, Frontend, Backend und Basis -
system ließen sich unabhängig voneinander
migrieren. Das gilt insbesondere für die
Anfangsphase, die vorwiegend mit Auf -
wand für die Einarbeitung verbunden ist.
Im Zuge der Umprogrammierung von
Frontend und Backend stellte sich keine
Notwendigkeit einer Abstimmung heraus,
die sich keine Schnittstellen geändert
haben, sondern lediglich die JPA-Imple -
mentierung, die von Hibernate auf
Eclipselink umgestellt wurde. Die kausale
Abhängigkeit der Programmierarbeiten
beschränkt sich auf den Gesamttest, in dessen
Rahmen das Zusammenspiel von
Frontend und Backend auf der neuen
Zielplattform validiert wurde.
Validierung der migrierten Applikation
Die Validierung war Bestandteil der
Umsetzung. Das heißt jeder Entwickler
testete die migrierten Bestandteile gegen die
entsprechenden alten, ursprünglichen
Bestandteile. Das funktioniert auch sehr
gut innerhalb einer Systemschicht. Ins -
besondere existierten bereits unabhängige
Unit-Tests für jede Systemschicht. So konnte
etwa der für die Backend-Migration zu -
ständige Entwickler die vorhandenen Unit-
Tests der Hibernate-Datenzugriffsobjekte
für die neuen mit Eclipselink umgesetzten
Datenzugriffsobjekte wiederverwenden.
Diese Leichtgängigkeit beschränkt sich
jedoch leider auf die Validierung innerhalb
einer Systemschicht. Um das Zusammen -
spiel aller Komponenten und – neben den
Funktionstests – vor allem auch die Benutz -
barkeits- und Robustheitstests der gesamten
neuen Applikation testen zu können,
musste ein fertiges Produkt vorliegen. Das
Logistik-Personal bediente bereits die alte
Anwendung für die Temperaturkontrolle
von kühlpflichtigen Arzneien. Nach interner
Veröffentlichung einer migrierten
Produktversion wurde ein Parallelbetrieb
der alten und neuen (migrierten) Appli -
Abb. 6: Migrierte Anwendung – Starten und Auslesen der Temperatur-Logger sowie Pulk-Lesen von Arzneimittelpackungen.
1/2012

fachartikel
kation in der Logistik eingeführt. Innerhalb der ersten zwei
Wochen wurde ausreichend Feedback gesammelt, das sowohl Bug-
Reports als auch Feature-Wünsche enthielt, die voneinander
getrennt wurden.
Die Benutzbarkeit der migrierten Produkt version wurde als
höher angesehen, was wahrscheinlich auf den typischen (Windows-
)Look zurückzuführen ist. Die graphische Swing-Oberfläche der
alten Anwendung stieß auf weniger Gegenliebe. Gleichermaßen
war die Performance der Benutzungsoberfläche höher, die Anwen -
dung startete in spürbar kürzerer Zeit.
Bedeutend für die Validierung waren außerdem die genannten
Hauptgründe des Migrationsprojekts: die Validierung der
Produktderivat-Erstellung und die Aus lagerbarkeit der
Entwicklung funktionaler Bausteine durch externe Geschäftsein -
heiten. Hierzu wurde für drei in einer Stakeholder-Rolle befindliche
Partner jeweils eine individuelle Produktversion mit unterschiedlichen
Funktionen exportiert. So erhielt ein Endkunde aus dem
Lebensmittellogistik-Bereich eine Version, die über keine
Konfigurationsschnittstellen für Branding oder über weitere
Funktionen verfügte, die etwa für einen Weitervertrieb relevant
sind. Ein Vertriebspartner erhielt dagegen eine solche Version mit
Funktio nen, die den Weitervertrieb abbilden.
Die Auslagerbarkeit ließ sich mit einem Auftrag nach Übersee
prüfen, der die Implementierung eines PDF-Exports der gesamten
Temperaturhistorie einschließlich Diagramm umfasste. Dieser verlief
sehr gut und die erstellten Artefakte ließen sich dank der mit
OSGi definierten Schnitt stellen auf triviale Weise rückintegrieren.
Fazit
Entstanden ist ein lauffähiges Produkt, das mittlerweile produktiv
im Pharma- und Lebensmittelumfeld eingesetzt wird. Abbil dung 6
zeigt das Ergebnis.
Grundsätzlich sind IT-Entscheider nicht davor gefeit, ein System
zu migrieren, auch wenn es neuen Standards entspricht, da
Technologien nicht per se vor notwendigen Änderungen durch
neue Anforderungen schützen. In dem hier beschriebenen Fall wurde
die Applikation auf die OSGi-Technologie – genau genommen
auf die Eclipse-Plattform – migriert, damit sich leicht
Produktderivate erstellen und die Entwicklung von Modulen nach
Übersee auslagern lassen. Dies erfüllt die neue migrierte
Applikation. Im Rückblick lassen sich die mit dem
Migrationsprojekt gesammelten Erfahrungen und Lektionen wie
folgt zusammenfassen:
■
■
■
■
Nicht geplante Anforderungen können die Migration eines
bestehenden Systems erzwingen, obwohl es technologisch auf
dem aktuellen Stand ist.
Die Globalisierung der Softwareent wicklung hat einen entscheidenden
Einfluss auf die Architekturanfor derungen, die
eine Migration bedingen können.
Die Trennung von Architektur schich ten und der Einsatz von
bewährten Schnittstellen (z. B. JPA) reduzieren den Migrations -
aufwand immens.
Die Anfangsphase und die Einarbeitung in die Zieltechnologie
machen einen bedeutenden Anteil des gesamten Mi -
grationsaufwands aus.
Die Rich-Client-Anwendung auf der Basis von Eclipse 4 verfügt
über dieselben Funk tionen wie die ursprüngliche zu migrierende
Anwendung. Abbildung 6 zeigt die neue Anwendung für das
Starten und Auslesen der Temperatur-Logger und das Pulk-Lesen
analog zu Abbildung 3.
Sicherlich stellen Sie sich an dieser Stelle die Frage, inwiefern die
Architektur nun konzeptionell tragfähiger ist oder ob in ein paar
Jahren vielleicht eine Fortsetzung dieses Artikels erscheint, der die
Migration der neuen Anwendung wieder mit denselben Pro blemen
darlegt? Unbestritten ist die Plan barkeit des Einsatzes einer neuen
Techno logie weniger trivial. Die rasante Entwick lung von Plattformen
und Frame works macht es IT-Entscheidern nicht gerade einfach.
Die Kernfrage lautet: Inwieweit ist die Zukunft der gewählten
Zielplattform stabil, inwieweit ist also davon auszugehen, dass die
Zielplattform eher immer populärer und weiterentwickelt bzw. verbessert
wird, als dass sie irgendwann veraltet oder gar ausstirbt?
Häufig hilft es zu prüfen, wer die Zielplattform entwickelt bzw. wie
groß die hinter der Zielplattform-Entwicklung stehende
Community ist, ob die Zielplatt form einen verbreiteten Standard
(wie zum Beispiel OSGi) erfüllt oder proprietär ist, ob es einen entgegen
gerichteten Trend bzw. Ansatz gibt und vielleicht sogar dazu
eine entsprechende alternative Lösung, die bereits Einzug in die
Entwick lergemeinde nimmt.
■
Literatur & Links
[Car03] N.G. Carr, IT Doesn't Matter, Harvard Business Review, Mai 2003
[Kro06] P. Kroha, L. Rosenhainer, Textuelle Anforderungen und Software-Migration, in: U. Kaiser, P. Kroha, A. Winter (Hrsg.), Proc. of 3. Workshop
Reengineering Prozesse (RePro 2006) Software Migration, Mainzer Informatik-Berichte, Informatik-Bericht Nr. 2/2006
[Lie08] D. Liebhart et al., Integration Architecture Blueprint: Leitfaden zur Konstruktion von Integrationslösungen., Carl Hanser Verlag 2008
[Met95] R. Metcalfe, A network becomes more valuable as it reaches more users, InfoWorld, Oct. 1995
[Moo65] G. Moore, Cramming more components onto integrated circuits, in: Electronics Magazine, Vol. 38, Number 8, April 1965
[Schl09] C.B. Schiltz, EU warnt vor Boom bei gefälschten Medikamenten, Welt Online, 07.12.2009, siehe:
http://www.welt.de/wirtschaft/article5449188/EU-warnt-vor-Boom-bei-gefaelschten-Medikamenten.html
[Schw07] H.G. Schweim, Gefälschte Arzneimittel – aus der Dritten Welt in die Industrienationen, 2007, siehe: http://www.pharmtech.unibonn.de/dra/hintergrundinformationen
[Sne10] M.H. Sneed, E. Wolf, H. Heilmann, Softwaremigration in der Praxis: Übertragung alter Softwaresysteme in eine moderne Umgebung,
dpunkt.verlag 2010
[Sul10a] E. Sultanow, Virgo: Serverseitige Webanwendungen aus Komponenten, in: iX – Magazin für professionelle Informationstechnik 11/2011
[Sul10b] E. Sultanow, Zusammenarbeit in verteilten Projekten: Dekomposition, Barrieren und Lösungen im Kontext der Webent wick lung, Gito 2010
[Zac07] R. Zacharias, Produktlinien: Der nächste Schritt in Richtung Software-Industrialisierung, in: Javamagazin 3/2007
64 65

fachartikel
der autor
ABGRENZUNG ALS METHODE
DER ANFORDERUNGSANALYSE:
TEIL 2: ABGRENZUNGEN
HERAUSARBEITEN
Wer in Modellen, Beschreibungen und Anforderungen mit Abgrenzungen arbeitet, stößt oft auf
Unverständnis, Ablehnung oder zumindest ein gewisses Unbehagen bei den Lesern und
Begutachtern. Durch negative Aussagen scheint der Gegenstand der Betrachtungen viel weniger
präzise beschrieben zu sein als durch positive Bestimmungen. Manchmal entsteht der
Eindruck, dass der Autor dadurch nur eine Unvollständigkeit der Analyse und Beschreibung verdeckt.
Dennoch sind treffende Abgrenzungen notwendig und sogar ein Indiz für gute Arbeit.
Warum das so ist, auf welchen Gebieten nach ihnen gefahndet werden sollte und wie Abgren -
zungen formuliert werden könnten, ist Thema dieses Artikels. Im ersten Teil, der in der letzten
Ausgabe von OBJEKTspektrum erschienen ist, ging es um Abstimmungen zwischen
Arbeitgeber und -nehmer.
Bernd Körner
(E-Mail: bernd.koerner@t-systems.com)
ist Softwareentwickler und Requirements-Engineer,
davon 13 Jahre in Projekten für Personaleinsatz -
planung, Managementinformations- und Projekt -
abrechungssysteme für die Deutsche Post AG.
Analyse und Modellierung sieht er als eine Art
angewandter Philosophie.
Wie gewinnt man die Abgrenzungen, aus
welchen Quellen entspringen sie, welche
Prozesse fördern sie ans Licht und wie
trennt man Relevantes von Irrelevantem?
Vor der Analyse muss sich der Bearbeiter
über die geforderte bzw. angestrebte
Detailliertheit, also die Fertigungstiefe, im
Klaren sein. Sie bestimmt, welche Probleme
er in diesem Bearbeitungsschritt erkennen
und lösen muss und welche er für einen
Folgeschritt offen lassen kann. Maßstab
dafür ist das angestrebte Abstraktions -
niveau. Nur wenn die beschreibenden
Elemente sich auf annähernd demselben
Abstraktionsniveau befinden, lässt sich die
Vollständigkeit der Analyse prüfen oder
abschätzen. Es könnte beispielsweise festgelegt
werden, dass die aktuelle Beschrei -
bung nur die Elemente einer Benutzungs -
schnittstelle aufzählen soll, nicht aber
deren Anordnung, Bedingungen, graphische
Gestaltung usw. Diese Anforderungen
an das Beschreibungslevel tragen also selbst
abgrenzende Elemente in sich.
Zum anderen fordert die Analyse eine
konsequente Systemsicht. Der Bearbeiter
muss alle eingehenden Informationen
dahingehend interpretieren, was sie für das
System bedeuten und an welchen Stellen sie
das System überschreiten. In den Ein -
gangsdokumenten konstatierte Tatsachen
muss er in systembezogene Anforderungen
übersetzen. Das ist ein wichtiger Schritt, da
er Implikationen von Tatsachen auf das
System und damit deren Relevanz für das
System aufdeckt. Wenn z. B. die Aussage
„Kein Mensch ist älter als 200 Jahre” sich
als systemrelevant herausstellt, sieht das
System die Abgrenzung „Ich brauche keine
Menschen mit einem Lebensalter >200
Jahre berücksichtigen”, was immer das für
Konsequenzen hat.
Die Aufgabe enthält als Eingangsgrößen
neben der expliziten Formulierung der
Anforderungen, meistens auch noch
Verweise auf Dokumente und Aspekte, die
als Randbedingungen zu berücksichtigen
sind. Diese Dokumente sind in der Regel
für einen größeren Rahmen gedacht.
Deswe gen muss der Bearbeiter zunächst die
relevanten Bestandteile herausarbeiten.
Einige sind unstrittig relevant oder irrelevant,
für andere ist es unklar, ob sie einbezogen
werden sollen. Stellt sich auf
Nachfrage die Irrelevanz heraus, ergibt das
Abgren zungen.
Ein Teil davon betrifft die Einbettung der
Aufgabe in eine übergeordnete Aufgabe
oder einen größeren Rahmen. Dieser übergeordnete
Rahmen enthält bereits Struk tur -
elemente, Funktionen, Status und Aspekte.
Der Bearbeiter prüft, welche auf seine
Aufgabe Einfluss haben könnten, und formuliert
als unklar bestimmte und vom
Auftraggeber ausgeschlossene Elemente als
Abgrenzung.
Dann geht es an die Analyse der Aufgabe
selbst, indem unter anderem Vor- und
Nachbedingungen, Teilschritte und Fehler -
fälle herausgearbeitet werden. Durch Ein -
gangsgrößen und Ergebnisobjekte ist ein
Teil der nötigen Strukturen bereits vorgegeben,
Zwischenergebnisse und Prozess -
status ergänzen diese. Aus Strukturen
erwachsen Möglichkeiten, Status und
Konstellationen, die eine bestimmte
Situation in der Aufgabe vorfinden kann.
So kommt bisher Implizites zutage: Teile,
Wege, Bedingungen, Substrukturen, Pro -
bleme und Abhängigkeiten. Eine vorher
ungesehene Welt tut sich auf, erweitert sich
wie ein Luftballon, der aufgeblasen wird –
und es entsteht ein expandierendes Uni -
versum. Wer versucht, in ein fremdes
Fachgebiet einzusteigen, z. B. die Bäckerei,
wird überrascht sein, wie viele Einfluss -
größen, Möglichkeiten und Wechsel -
beziehungen das Gelingen des Backens ausmachen
und so eine leise Ahnung davon
bekommen.
Diese zunächst unüberschaubare Menge
von Möglichkeiten gilt es, handhabbar zu
machen, so weit zu reduzieren, dass überschaubare
Abläufe entstehen, sie einerseits
zu kategorisieren und zusammenzufassen
und andererseits eine möglichst große
Menge auszuschließen – sei es, weil sie irrelevant
sind, sei es, weil sie mit nur sehr geringer
Wahrscheinlichkeit eintreffen können.
Diese Ausschlüsse von Möglichkeiten formuliert
der Bearbeiter als Abgren zun gen.
Ein Ergebnis-Artefakt ist nicht beliebig
aufgebaut, sondern nach den Erfor -
dernissen der Aufgabe strukturiert. So
kann das Ergebnis auch nicht auf beliebigen
Wegen erreicht werden, sondern aus
der Fülle der Möglichkeiten gibt es entweder
einige festgelegte oder einige nicht
erlaubte. Daraus erwachsen Notwendig -
keiten, die als Ab grenzungen definiert werden
können.
66 67

fachartikel
Wenn für eine Analyseaufgabe als solcher
deren Umfang bekannt ist – aus der
Erfahrung oder idealerweise durch Punkte
einer Checkliste –, lassen sich damit leicht
relevante von irrelevanten Punkten trennen
sowie eine gewisse Vollständigkeit der
Analyse erreichen und dokumentieren.
Das System muss es dem Benutzer ermöglichen, xxx.
Das System soll fähig sein, dass xxx.
Das System wird fähig sein, dass xxx.
Tabelle 1: Anforderungsmuster.
Rechtlich zugesicherte Eigenschaft.
Empfohlene Eigenschaft.
Zukünftig zugesicherte Eigenschaft.
Formulierung von
Abgrenzungen
Anforderungen an ein System werden
gewöhnlich nach dem in Tabelle 1 zu -
sammengefassten prinzipiellen Muster formuliert.
„Muss” und „Soll” zeigen dabei
die rechtliche Verbindlichkeit an und beanspruchen
damit Raum für den Auf -
traggeber. Die Formulierung in Tabelle 2 ist
zwar negativ, aber im Kern eine positive
Aussage und eine echte Anforderung. Sie
begegnet einer Befürchtung des Auftrag -
gebers und zwingt den Aufragnehmer zu
einer bestimmten Aktion.
Abgrenzungen sind aus Systemsicht und
negativ formuliert. Sie beschreiben, was
das System nicht können oder tun soll. Der
Auftraggeber soll sie so verstehen: Das
kannst du nicht erwarten, über diesen
Aspekt habe ich nicht nachgedacht, weil er
mir als irrelevant erschien (Tabelle 3). Dem
Auftragnehmer dagegen lassen Abgrenzun -
gen Spielräume (Tabelle 4).
Da ein beschreibendes Dokument oder
Anfor derungsdokument für Auftraggeber
und -nehmer gleichermaßen gültig sein und
es nicht für jeden eine eigene Variante
geben soll, müssen die Formulierungen beiden
genügen. Dementsprechend schlage ich
die Formulierungen in Tabelle 5 vor.
Abgren zungen werden darüber hinaus zur
Dar stellung von „Verschwindendem”
genutzt (Tabelle 6). Zu einer Abgrenzung
gehört idealerweise eine Begründung,
warum sie gerechtfertigt ist. So können
spätere Irritationen vermieden werden:
„Warum bloß haben wir das damals ausgeschlossen?”.
■
Das System braucht nicht xxx (zu
berücksichtigen), weil yyy.
Der Auftragnehmer versucht durch Ab -
gren zungen möglichst viel Land auszugrenzen.
Die Verwendung von All-Quantoren
(wie „alle”, „keine”) sind in den positiv
formulierten Anforderungen ein Risiko.
Hier aber kommen sie ihm entgegen:
■ Das System braucht kein xxx zu be -
rück sichtigen, weil yyy.
Das System darf nicht zulassen, dass xxx.
Tabelle 2: Negative Formulierung, aber echte Anforderung.
Das System wird nicht xxx.
Es ist nicht betrachtet, ob xxx.
Tabelle 3: Abgrenzung aus Auftraggeber-Sicht.
Das System muss nicht xxx.
Es ist nicht festgelegt, ob xxx.
Tabelle 4: Abgrenzung aus Auftragnehmer-Sicht.
Das System braucht nicht xxx (zu berücksichtigen).
Es ist nicht betrachtet/festgelegt, ob …
xxx ist ausschließlich für yyy (vorgesehen, gültig, …).
Der Aufraggeber toleriert, dass das System nicht xxx.
Tabelle 5: Formulierungsvorschläge.
Das System braucht nicht mehr xxx
(zu berücksichtigen, zu realisieren, anzubieten).
Tabelle 6: Darstellung von Verschwindendem.
■ Keine anderen Aspekte sind in diesem
Zusammenhang relevant.
■ Alle anderen Möglichkeiten sind in diesem
Zusammenhang ausgeschlossen.
Die Eigenschaft, die Möglichkeit oder das
Verhalten muss ausgeschlossen werden.
Das wird das System definitiv nicht leisten.
Wenn der Aspekt dennoch Einfluss auf das
Ergebnis der Aufgabe hat, könnte es zu negativen
Auswirkungen kommen.
Die Eigenschaft oder das Verhalten ist nicht
gefordert, aber möglich.
Eine Lösung zu diesem Problem muss gefunden
werden, aber die Auswahl der Lösung steht frei.
Auf die Eigenschaft wird jetzt oder immer verzichtet.
Die Art der Lösung ist für den Sinn der
Aufgabe irrelevant.
Abgrenzung von Geltungsbereichen.
Die Lösung entspricht nicht den ursprünglichen
Intentionen des Auftraggebers, wird aber akzeptiert.
Eine Funktionalität wird (gegebenenfalls ab einem
Zeitpunkt) nicht mehr benötigt.
Der Auftraggeber hingegen möchte verlorenes
Land zurückgewinnen und deswegen
die All-Quantoren eliminieren:
1/2012

fachartikel
■
■
■
Das System braucht nicht x1, x2, x3
berücksichtigen, weil yyy.
Keine anderen Aspekte sind für xxx
relevant.
Alle anderen Möglichkeiten sind für
xxx ausgeschlossen.
Distanz zur Aufgabe
Weit entfernt.
Behandlung des Aspekts
• Wird nicht beachtet, nicht analysiert und nicht erwähnt, weil
nicht der geringste Bezug zur Aufgabe ersichtlich ist.
• Betrifft die unendliche Vielfalt der „restlichen” Welt außerhalb
der Aufgabe.
Die letzten beiden Abgrenzungen bergen
für den Auftraggeber ein hohes Risiko, da
der Geltungsbereich („In diesem Zusam -
menhang”) schwer abgrenzbar und wiederum
von einer Grauzone umgeben ist. Will
er diese wegdiskutieren, kann der Auf -
tragnehmer antworten: „Bitte in positiven
Aussagen formulieren.” Die beste Gegen -
strategie ist es hier wohl, den Geltungs -
bereich stringent einzugrenzen. Das kann
leicht ins Unendliche führen, wenn man
dafür eine ähnliche Aussage verwendet, wie
z. B.: „Das betrifft xxx und sonst nichts.”
Gebiete der Abgrenzung
Zu welchen Sachverhalten ist es sinnvoll,
Abgrenzungen zu formulieren? Wo sind die
Eier versteckt, wo und wie soll man am
besten nach ihnen suchen? Welche Pro -
bleme sind damit verbunden? Je nach
(gedanklicher) Entfernung eines Aspekts
zur Aufgabe finden sich verschiedene Arten
von Abgrenzungen. In allen Distanz -
bereichen sollte man suchen. Die verschiedenen
möglichen Adressaten sollten
berück sichtigt werden, für jeden kann es
spezielle Abgrenzungen geben.
Abgrenzungen kann es sowohl für eine
Sache selbst (ein System, Anforderungen an
ein System) als auch für die Beschreibung
der Sache als Metaebene geben. Je nach
Bezugsobjekt wollen verschiedene Abgren -
zungen entdeckt werden.
Die Sache selbst wird in der Analyse zerlegt
und in Teile gegliedert. Jedes verdient
eigene Aufmerksamkeit hinsichtlich möglicher
Abgrenzungen. Einige Typen dieser
Teile, hier Gegenstände der Abgrenzung
genannt, entfalten in dieser Hinsicht besondere
Eigenheiten.
Distanzbereiche zur Aufgabe
Zunächst lassen sich Suchbereiche in
verschiedenen Entfernungen zur Aufgabe
denken. Gedanklich weit entfernte Such -
bereiche in die Be trachtungen aufzuneh -
men, wäre wegen ihrer Unendlichkeit ein
sinnloses Unter fangen.
Näher liegende Tatsachen sind in Ob jek -
ten, Prozessen und Bemerkungen der übergeordneten
Ebene zu finden. Sie verdienen,
Mittlere Entfernung.
Nah angrenzend.
Schneidet die Aufgabe.
Innerhalb.
in groben Zügen, als nicht betrachtet ausgeschlossen
zu werden. Es bleibt die
Möglichkeit, dass doch noch relevante
Aspekte gefunden werden, wenn das
Problem nur analysiert würde. Die
Abgrenzung gibt dem Auftraggeber die
Möglichkeit, solche Fehler zu erkennen.
Nah angrenzende Bereiche haben direkte
Schnittstellen zur Aufgabe. Sie sind nicht
Teil der Aufgabe, betreffen sie aber durch
ihre Existenz. Deswegen lohnt es, sie grob
zu analysieren. Wenn sich keinerlei relevante
Teilaspekte ergeben, kann der
Komplex ausgegrenzt werden. Finden sich
aber einige relevante Teilaspekte, dann gilt
es, die übrigen explizit auszuschließen.
Ist die aktuelle nicht die unterste Ebene,
gibt es innerhalb der Aufgabe Löcher in der
• Wird beachtet, aber nicht analysiert. Bezugspunkte in
übergeordneten Ebenen sind zu finden, aber sie berühren mit
großer Sicherheit nicht die Aufgabe.
• Abgrenzung: Aspekt ist nicht betrachtet.
• Wird analysiert. Es ergeben sich ausschließlich irrelevante
Teilaspekte.
• Abgrenzung: Es werden keine Anforderungen gestellt bezüglich …
• Wird analysiert. Es ergeben sich relevante und irrelevante
Teilaspekte.
• Letztere sind möglicherweise von anderen zu leisten und
werden abgegrenzt: Das System braucht nicht …
• Die Beschreibungsebene ist nicht die tiefste, es bleiben
Analyseaufgaben und Freiräume für folgende Bearbeiter.
• Abgrenzung: Detaillierung ist nicht betrachtet.
Tabelle 7: Suchbereiche für Abgrenzungen in verschiedenen Entfernungen zur
Aufgabe.
Abb. 1: Distanz der Abgrenzungen zur Aufgabe.
Beschreibung. Die Aussagen bilden sozusagen
ein noch lockeres Gespinst. Aufgabe
der nachfolgenden Bearbeitungsschritte ist
es, die Löcher mit noch feineren Fäden
zuzuspinnen, so dass eine homogene Be -
schreibungsfläche entsteht. Diese geschlossene
Aufgabe kann pauschal durch die
Abgrenzung der Bearbeitungstiefe, aber
auch explizit durch Abgrenzungen an die
Nachfolger übergeben werden (Tabelle 7).
Adressaten von Abgrenzungen
Abgrenzungen können verschiedene Adres -
saten haben (Tabelle 8). Für Abgrenzungen
gegenüber den Auftraggebern reicht es, diese
zu konstatieren. Ob die Sache irrelevant
ist oder von einem anderen übernommen
68 69

fachartikel
Adressat
Der Auftraggeber.
Ein oder mehrere Mitarbeiter.
Nachfolgende Bearbeiter bzw.
Auftragnehmer.
Tabelle 8: Adressaten von Abgrenzungen.
werden muss, liegt nicht in der Verant -
wortung des Abgrenzenden und muss nicht
unbedingt von ihm verstanden sein.
Anders sieht es aus, wenn es sich um eine
Teilaufgabe unter gleichberechtigten
Kollegen in einem größeren Rahmen handelt.
Dann gibt es den Anspruch, ein homogenes
Ganzes abzuliefern. Sowohl die
Abgrenzungen („Das musst du beschreiben!”)
als auch die Ansprüche („Das ist
meine Sache!”) richten sich dann gegen die
Mitarbeiter. Das können durchaus auch
mehrere sein, was eine Unterscheidung der
Abgrenzungen nötig macht. Die angrenzenden
Teile müssen verstanden sein, die
Abstimmungen bewegen sich nicht auf
einem prinzipiellen, sondern einem technischen
Niveau: In welchem Bereich ist der
Aspekt besser untergebracht, in welchem
Zusammenhang ist ein Problem effektiver
zu lösen? Als Eskalationsinstanz fungieren
der Architekt oder die Projektleitung.
Bezugsobjekte von Abgrenzungen
Abgrenzungen sind Inhalt von Dokumen ten
oder Beschreibungen. Diese Doku mente
betreffen aber eine Aufgabe, einen Sach -
verhalt oder ein System. Wie es Anfor -
derungen zur Sache selbst, zum System, aber
auch zur Beschreibung als Metaebene geben
kann, so auch Abgren zungen. Beide müssen
Bezugsobjekt
Dokument, Beschreibung.
System.
Tabelle 9: Bezugsobjekte von Abgrenzungen.
Inhalt der Abgrenzungen
Aspekte, die nicht im Rahmen der Aufgabe liegen.
Aspekte, die von anderen im Rahmen einer umfassenderen Aufgabe
übernommen werden sollen.
Aspekte, die unterhalb des Beschreibungslevels liegen, die noch nicht
ausformuliert sind, die Freiräume für den Bearbeiter lassen.
gedanklich getrennt werden, denn es macht
einen Unterschied, ob über eine Sache überhaupt
nicht nachgedacht oder im Ergebnis
des Nachdenkens eine Abgrenzung getroffen
wurde (Tabelle 9).
Dokumente sind meist in eine Doku -
menten- oder Gedankenlandschaft eingebettet.
Die Berücksichtigung mancher als
Quellen für die eigene Arbeit schließt andere
aus. Die Abgrenzungen beziehen sich
damit auf bekannte Tatsachen über die
Sache – also Sätze, Behauptungen und
Gegeben heiten im Hinblick auf die
Aufgabe. Diese Abgrenzungen haben die
folgende Struktur:
■
Es ist nicht berücksichtigt, dass xxx.
Anders für die Sache selbst: Hier stehen
Teilbereiche, Elemente der Sache, im
Fokus. Für sie gilt es zu entscheiden, ob sie
einbezogen oder ausgegrenzt werden sollen.
Das können Strukturelemente, Status
und Funktionen mit deren Vorausset -
zungen und Bedingungen sein. Hier findet
sich die folgende Struktur:
■
Das System braucht nicht xxx …
Im Verlauf der Abstimmung kann sich herausstellen,
dass bestimmte abgegrenzte
Inhalt der Abgrenzungen
• Nicht betrachtete Aspekte (Modellabgrenzung).
• Nicht betrachtete andere Dokumente im Umfeld.
• Bekannte, aber nicht berücksichtigte Tatsachen.
• Referenzen auf andere Dokumente.
• Beschreibungsebene, Abstraktionsgrad.
• Nicht zur Aufgabe gehörende Aspekte (Scope).
• Referenzen auf Anforderungen oder Funktionalitäten in
anderen Systemen
• Offen gelassene Entscheidungen
1. Generelle Abgrenzungen
a. Nicht betrachtete Aspekte
i. Nicht betrachtete Folgen
ii. Nicht berücksichtigte Aspekte
iii. Nicht berücksichtigte
Tatsachen
iv. Nicht berücksichtigte
Ereignisse
v. Nicht berücksichtigte
Einflussgrößen
b. Abgrenzung der Abstraktionstiefe
2. Die Sache betreffend
a. Generelle Abgrenzungen
b. Rahmenbedingungen
i. Nicht berücksichtigte Arten
nicht-funktionaler
Anforderungen
c. Struktur
i. Verantwortlichkeiten
ii. Nicht benötigte Klassen und
Elemente
iii. Wertebereiche
iv. Ausschluss von Veränderungen
v. Ausschluss von Wegen für
Veränderungen
d. Status
i. Ausschluss von
Wertekonstellationen
e. Prozess
i. Nicht nötige Teilschritte
ii. Nicht zu berücksichtigende
Parameter
iii. Nicht zu berücksichtigende
Tatsachen
iv. Nicht zu berücksichtigende
Ereignisse
v. Ausschluss von Aktionen in
Abhängigkeit vom Zustand
vi. Ausschluss von
Einschränkungen für Aktionen
Kasten 1: Die Struktur der Gegenstände
von Abgrenzungen darstellen (die
Beschreibung betreffend).
Tatsachen doch relevant sind. Deren Ana -
lyse gebiert nun wieder neue Anfor -
derungen und Abgrenzungen der zweiten,
bestimmte Elemente betreffenden Art.
Gegenstände der Abgrenzung
Die Bezugsobjekte haben eine typische
Struktur und die Struktur hat typische
Elemente mit jeweiligen Eigenheiten. Die
Elemente lassen sich in einer Struktur der
Gegenstände von Abgrenzungen darstellen
(Kasten 1). Einige dieser Gegenstände verdienen
eine nähere Erläuterung:
1/2012

fachartikel
Bedingung Folgerung Beispiel
Wenn Dann • Wenn die Ampel „rot” zeigt, dann muss man warten.
• Wenn die Temperatur 21°C beträgt, dann soll das
Wasserglas voll sein.
Wenn nicht Dann • Wenn die Ampel nicht „grün” zeigt, dann muss man warten.
• Wenn die Temperatur nicht 21°C beträgt, dann soll das
Wasserglas halb voll sein.
Wenn Dann nicht • Wenn die Ampel „rot” zeigt, dann darf man nicht gehen.
• Wenn die Temperatur 21°C beträgt, dann darf das
Wasserglas nicht halb voll sein.
Wenn nicht Dann nicht • Wenn die Ampel nicht „grün” zeigt, dann darf man nicht gehen.
• Wenn die Temperatur nicht 21°C beträgt, dann darf das
Wasserglas nicht voll sein.
Tabelle 10: Negative Wenn-Dann-Ausdrücke.
Die Abgrenzung gegen mögliche Folgen
einer Verfahrensweise oder Systembenut -
zung erfordert in einem nachfolgenden
Schritt eine Risikobewertung. Diese erst
rechtfertigt die Abgrenzung oder aber
erklärt die Folgen für untragbar und ersetzt
sie durch Forderungen.
Nicht berücksichtigte Aspekte betreffen
meist die Rahmenbedingungen einer
Aufgabe. Für ein System sind dies hauptsächlich
die nicht-funktionalen Anfor -
derun gen. Abgrenzungen dazu sind häufig
im Passiv formuliert: „xxx muss nicht
berücksichtigt werden” oder „Es werden
keine Anforderungen bezüglich xxx erhoben.”
Trotz dieser expliziten Abgrenzung
existiert im Hintergrund eine weitere
Frontlinie, die Gesetze, allgemeine Rege -
lungen, Betriebsvereinbarungen, Produkt -
bestim mungen, Style-Guides usw. bilden
und die konkrete Anforderungen implizieren.
Die Aufgabe und deren Abgrenzungen
definieren zunächst ein statisches Bild. So
wie es aber Anforderungen geben kann, die
die flexible Veränderung von Verhaltens -
weisen, Parametern und Aussehen – ja fast
allen Elementen und Aspekten eines
Systems – einfordern, so muss es im
Gegenzug auch entsprechende Abgren zun -
gen geben. Der Ausschluss von bestimmten
Veränderungen (z. B. Inhalten von Aus -
wahl listen) soll dies leisten. Wie wichtig das
ist, wird klar, wenn man bedenkt, dass das
Hinzufügen, Ändern oder Löschen, z. B.
eines Listeneintrags, im allgemeinen Fall
auch Änderungen in der Funktionalität
nach sich zieht.
Wertebereiche lassen sich sowohl als
explizite Anforderungen als auch als
Abgrenzungen sehen. Sie trennen einen
geforderten von einem nicht geforderten
Bereich. Es ist günstig, sie positiv als
Anforderung zu formulieren. Sie werden
dann nicht in den Abgrenzungen auftauchen.
Die Struktur von bedingten Aktionen
zeigt vier Ausprägungen (Tabelle 10). Das
Besondere am „nicht” ist, dass es eine
unbekannte (Rest)Menge bezeichnet. Die
Bedingung „Wenn nicht …” geht von einer
bestimmten positiven Erwartung aus, die
sich auf viele mögliche Arten getäuscht
sieht. Die Folgerung „Dann nicht …” verbietet
ein bestimmtes Verhalten oder einen
bestimmten Zustand aus vielen anderen
möglichen.
Im Ampelbeispiel (Tabelle 10) lassen sich
die negativen Aussagen leicht auflösen,
indem alle Zustände (rot, gelb, grün, warten,
aufmerksam sein, gehen) in der Wenn-
Dann-Struktur dargestellt werden. Für
kontinuierliche Werte oder offene bzw. sehr
große Mengen ist dies aber nicht möglich,
wie das zweite, etwas konstruierte Beispiel
(Zeile 2 in Tabelle 10) zeigt. Die drei
„Nicht”-Varianten lassen sich nicht in die
Wenn-Dann-Struktur übersetzen.
Wenn bestimmte Bedingungen oder
Zustände Aktionen ausschließen, gerät der
Benutzer des Systems in seinem Bear -
beitungsweg in eine Sackgasse. Diese
bedarf einer Erklärung und eines Auswegs.
Deswegen muss das System auf ausgeschlossene
Möglichkeiten mit einer
Fehlerbehandlung und Information reagieren.
Prozesswege können ins Abseits und in
fehlerhafte Zustände führen. Normaler -
weise begegnet der Planer dem mit
Geländern und Leitplanken, die den
Benutzer des Systems auf dem rechten Weg
halten. Aber manchmal sind diese unerwünschten
Möglichkeiten so vielfältig,
kompliziert und verzweigt, dass es sehr aufwändig
wäre, sie alle explizit zu behandeln.
Wenn der Auftraggeber diesen Aufwand
nicht tragen möchte, akzeptiert er Ab gren -
zungen, die die Verantwortung, nicht in
solche Situationen zu geraten, in die Hand
des Benutzers oder der Organisation legen.
Beispiel
Ein fiktives Beispiel soll das Vorange -
gangene illustrieren und zeigen, wie
Abgrenzungen konkret aussehen könnten.
Die Zustellung von Postsendungen soll
statt zu Fuß mit dem Auto erfolgen.
Der Abteilungsleiter betreut einen Mitar -
beiter, der sich in der Zustellung auskennt,
mit der Aufgabe, ein passendes Auto zu
bestellen. Er erklärt ihm die Ziele der
Maßnahme, übergibt eine knappe Prozess -
beschreibung und weist auf einzuhaltende
Gesetze und betriebliche Regelungen hin.
Der Mitarbeiter findet sich nun in der
Rolle des Aufragnehmers und muss die
Aufgabe analysieren und herausfinden, was
ein „passendes Auto” ist. Er greift dazu auf
sein Fachwissen zurück, erstellt eine Liste
von möglichen Situationen, in denen das
Auto eingesetzt werden soll, und erkundet,
was das Auto (das System) in diesen
Situationen können muss. Manche Ent -
scheidungen kann er aus seiner Sicht nicht
treffen und fragt seinen Auftraggeber und
andere Beteiligte und Betroffene:
■
■
Muss ich diesen oder jenen Aspekt
beachten?
Muss das Auto dies oder das können?
Er erhält positive und negative Antworten.
Aus den negativen formuliert er die
Abgrenzungen und spiegelt damit seinem
Auftraggeber wider:
■
■
■
Welche Aspekte des Autos und seines
Zusammenwirkens mit der Aufgabe
und der Umwelt er nicht untersucht
hat.
Was das Auto nicht leisten wird.
Welche Aspekte er nicht festgelegt hat
und dem Autohersteller als Freiheit
überlässt.
Nehmen wir an, der Auftraggeber akzeptiert
alle Abgrenzungen bis auf das
70 71

fachartikel
Dokument
Generelle Abgrenzung.
Nicht betrachtete Aspekte.
Nicht berücksichtigte Tatsachen.
Nicht berücksichtigte Ereignisse.
Nicht berücksichtigte Einflussgrößen.
Nicht betrachtete Folgen.
Abgrenzung der Abstraktionstiefe.
Anforderungen
Generelle Abgrenzungen.
Nicht berücksichtigte Aspekte.
Nicht benötigte Elemente.
Wertebereiche.
Ausschluss von Veränderungen.
Ausschluss von Wegen
für Veränderungen.
Ausschluss von Wertkonstellationen.
Nicht nötige Prozessschritte.
Nicht zu berücksichtigende
Parameter, Tatsachen, Ereignisse.
Ausschluss möglicher Aktionen.
Keine Verhinderung verbotener
Aktionen.
Ausschluss möglicher Ereignisse.
Nicht zu berücksichtigende Auslöser
von Ereignissen.
Auswahl aus Alternativen.
Ausschluss von Einschränkungen.
Beispiele
Keine anderen Aspekte als die hier beschriebenen sind für die Aufgabe
relevant.
• Der Einsatz der Autos ist ausschließlich im Inland geplant.
• Die Abnahme durch den TÜV ist hier nicht beschrieben.
• Die Anforderungen an die Abnahme legt der TÜV fest.
• Die Tatsache, dass die Verkehrsdichte in den nächsten 5 Jahren um
25% wachsen soll, ist nicht berücksichtigt.
• Die für nächstes Jahr geplante Veränderung von
Zulassungsbedingungen ist noch nicht berücksichtigt.
Mögliche Naturkatastrophen sind nicht berücksichtigt.
Mögliche Witterungseinflüsse sind nicht berücksichtigt.
Die Auswirkungen auf die Arbeitnehmerzufriedenheit sind nicht in die
Untersuchung einbezogen.
Ob die Autos mit Navigationssystemen ausgestattet werden sollen,
bleibt einer späteren Untersuchung vorbehalten.
Beispiele
Das Auto braucht keine weiteren Anforderungen zu erfüllen.
• Es werden keine expliziten Anforderungen zur Performance erhoben.
• Es ist keine Mindestlaufleistung gefordert.
• Anforderungen zur Verfügbarkeit sind in xxx beschrieben.
• Das Auto braucht kein Navigationssystem zu haben.
• Die Anforderungen an das Navigationssystem sind in [xxx] beschrieben.
• Das Auto muss in einem Temperaturbereich von -20°C bis +40°C
sicher arbeiten und alle anderen Anforderungen erfüllen.
• Das Auto wird nicht unter -20°C und nicht über +40°C eingesetzt.
Die Sitzhöhe braucht nicht verstellbar zu sein.
Die geplante Fahrtoute braucht dem Auto nicht über Funk übermittelt,
sondern kann manuell am Navigationsgerät eingegeben werden.
• Die Möglichkeit, dass bei voller Beladung über 60 km/h gefahren
wird, braucht nicht berücksichtigt werden, denn dies ist durch
betriebliche Regelungen untersagt.
• Das Auto muss nicht geländetauglich sein.
Das Auto darf alle Türen in einem Schritt öffnen; es braucht nicht zuerst
die Fahrertür und in einem zweiten Schritt die anderen Türen zu öffnen.
• Das Auto muss nicht regendicht sein.
• Die Scheinwerferneigung braucht sich nicht automatisch an die
Beladungssituation anzupassen.
• Die Anforderungen an den Winterbetrieb Kälte sind in [xxx] beschrieben.
• Das Auto braucht keinen Rückwärtsgang.
• Das Auto braucht und darf dem Fahrer das Linksabbiegen nicht
ermöglichen.
Das Auto braucht keine Wegfahrsperre, denn es wird nachts auf
gesicherten Höfen abgestellt.
Ein Wechsel des Fahrers an einem Tag ist
organisatorisch ausgeschlossen.
Das Auto braucht den Fahrer nicht über den nächst fälligen
Wartungstermin zu informieren, da dies über einen zentralen
Wartungsplan geregelt wird.
Die Farbe des Autos kann frei gewählt werden.
Die Höchstgeschwindigkeit muss nicht künstlich begrenzt werden.
Weglassen der Wegfahrsperre, denn er
erkennt, dass nicht alle in Frage kommenden
Höfe ausreichend gesichert sind. Dann
wird er die Abgrenzung durch die neue
Anforderung ersetzen: „Das Auto muss
eine Wegfahrsperre besitzen”. Der Auf -
tragnehmer analysiert das erneut, findet
verschiedene Möglichkeiten für Wegfahr -
sperren und so neue Anforderungen und
Abgrenzungen.
Die Anforderungen übergibt er als
Aufforderung zu einem Angebot an einige
Autohersteller. Er überlegt, ob er die bisher
formulierten Abgrenzungen mit übergeben
sollte. Einerseits ist damit die Gefahr verbunden,
dass ihm sonst (kostenfrei) enthaltene
Bestandteile seiner Lieferung verloren
gehen. Andererseits käme ohne Abgren -
zungen ein wohl teureres Angebot heraus.
Also entschließt er sich, sie mit einzubeziehen
– und liegt gut damit.
Abgrenzung
Über was haben wir hier nicht gesprochen?
Über fast alles andere in der Welt. Wir
haben nicht über Vulkanausbrüche gesprochen,
denn das hat ja nun wirklich nichts
mit dem Thema zu tun. Wir haben nicht
über Mitwirkungspflichten des Auftrag -
gebers gesprochen, obwohl diese ja eigentlich
Brüder der Abgrenzungen sind: Sie fallen
wie die Abgrenzungen nicht in den
Aufgabenbereich, aber der Auftragnehmer
ist im Gegensatz zu jenen auf die Zu -
lieferungen angewiesen. Doch andererseits
betreffen sie den Inhalt von Dokumenten
und Anforderungen nur mittelbar. Nicht
die Mitwirkungspflicht als solche ist für
unser Thema relevant, sondern der Inhalt
der Mitwirkungen. Wir haben nicht über
die Verarbeitung von Abgrenzungen in
Testfällen gesprochen, obwohl diese einen
wertvollen Input für jene liefern. Aber das
mag Aufgabe einer anderen Erörterung
sein.
Wir haben nicht darüber gesprochen,
was es hinsichtlich der einzelnen Gegen -
stände der Abgrenzungen bedeutet, wenn
die Aspekte irrelevant, out of Scope oder
im Scope sind, denn solche Details würden
wohl doch den Rahmen des Artikels sprengen.
Sind diese Abgrenzungen akzeptabel?
Lassen sie den Sinn des Artikels unversehrt?
Jetzt könnte man noch überlegen,
wie diese Abgrenzungen abgegrenzt werden
könnten usw.
■
Tabelle 11: Beispiele für Abgrenzungen.
1/2012

uchbesprechung für sie gelesen von ...
VOM ARCHITEKTONISCHEN
VERSTEHEN, ENTWERFEN UND
WIEDERVERWENDEN
Aus dem dpunkt.verlag stammt das Buch „Basiswissen Softwarearchitektur ”. Auf rund 380
Seiten adressiert die dritte Auflage verschiedene Aspekte des Themas Softwarearchitektur,
darunter Grundlagen, das Verhältnis von Architek tur zur Organisation, das Vorgehen beim
Entwurf, dessen Einflussfaktoren sowie die Dokumen tation von Architekturen, ein
Werkzeugkasten für Architekten, industrielle Softwareent wick lung, Produktlinien und modellbasierte
Ansätze.
... Michael Stal,
Chefredakteur von JavaSpektrum.
Wohltuend wirkt in dem Buch die Tat -
sache, dass es sich tatsächlich auf Archi -
tektur fokussiert und keine langatmigen
Abstecher in andere Gebiete macht. Es
richtet sich explizit an die Zielgruppe der
Projektleiter und Softwareentwickler.
Torsten Posch, Klaus Birken, Michael Gerdom
Basiswissen Softwarearchitektur:
Verstehen, entwerfen, wiederverwenden
In den ersten Kapiteln erfährt der Leser,
warum Softwarearchitektur überhaupt
wichtig ist und wie sich das Thema in
Projektorganisationen einbettet. Dass es
für größere Projekte nicht nur einen
Architekten geben kann, sondern ein
Architekturteam, dafür aber einen
Chefarchitekten, gehört zu den wichtigen
Ausführungen. Der sollte aber nicht
Kompromisse eingehen, wie die Autoren
anmerken, sondern gute und tragfähige
Entscheidungen mit anderen Rollen treffen.
In den nachfolgenden Kapiteln beschreiben
die Autoren die notwendigen Schritte zur
Vorbereitung des Entwurfs sowie den
Entwurf selbst.
Zu den Stärken des Buches gehört es,
dass es sich nicht nur auf Technologie und
Werkzeuge beschränkt, sondern auch verschiedene
Arten von Einflussfaktoren
beleuchtet. Für den Entwurf sollten
Architekten ein iterativ-inkrementelles
Vorgehen nutzen, weil sich Architek -
turentwurf nicht als Einbahnstraße entpuppt,
sondern als „Piecemeal Growth”,
bei dem der Entwurf Schicht für Schicht
wächst. Ein Big Bang lässt sich nicht mehr
kontrollieren, ein iterativer-inkrementeller
Ansatz hingegen schon. Damit der Leser
das alles nachvollziehen kann, bringen die
Autoren ein Fallbeispiel, das aber zu
schlank ist, um die konzeptionellen
Aussagen exemplarisch nachvollziehen zu
können. Im letzten Teil des Buchs streifen
die Autoren Posch, Birken und Gerdom
dpunkt.verlag 2011
380 Seiten
41,90 €
ISBN-10: 3898647366
ISBN-13: 978-3898647366
dann noch fortgeschrittene Themen wie
Produktlinien oder modellbasierte Ansätze
à la MDA und DSLs. Dadurch erhält der
Leser ein sehr abgerundetes und gutes Bild
davon, welchen Herausforderungen sich
Architekten heute stellen müssen.
Wo Licht ist, da ist bekanntlich auch
Schatten. Nicht umsonst steckt der Begriff
„Basiswissen” im Titel. Demzufolge können
viele der Kapitel einzelne Themen nur
anreißen, aber nicht vertiefen. Exem -
plarisch seien hier die Erläuterungen zu
architektonischen Bewertungen er wähnt,
die zwar einen guten, wenn auch nicht vollständigen
Einblick in die Materie geben.
Dadurch regen die Autoren zwar den
Appetit an, können ihn aber nicht stillen.
Zudem wäre ein Kapitel zu eingebetteten
Systemen bzw. zum Thema System-
Engineering wünschenswert, die besondere
Randbedingungen besitzen. Im Kapitel
über Softwareentwicklung im industriellen
Maßstab kommt zwar Wiederverwendung
zur Sprache, nicht aber Problematiken wie
Produkt- versus Lösungsgeschäft oder zum
Beispiel Entwurf über mehrere Standorte
hinweg. Auch sollten sich die Autoren für
weitere Neuauflagen überlegen, ob es wirklich
sinnvoll ist, MDA bei den modellbasierten
Verfahren in den Vordergrund zu
stellen. Jedenfalls hält sich dessen
Verbreitung in der Praxis sehr in Grenzen.
Das alles ist natürlich dem Problem
geschuldet, dass ein Buch es nicht allen
Lebenslagen und Bedürfnissen recht
machen kann.
Insgesamt erweist sich das Buch „Basis-
wissen Soft warearchitektur” als lesenswerte
und wichtige Lektüre für die angesprochene
Zielgruppe. Es verschafft einen
Einblick in architektonisches Arbeiten,
ohne den Leser mit Information zu erschlagen.
Für Manager in Entwick -
lungsabteilungen dürfte es auch eine interessant
Lektüre darstellen, für prak -
tizierende Softwarearchitekten hingegen
nur bedingt.
■
74 75

fachartikel
mehr zum thema:
www.it-grundschutz.de
www.bsi-fuer-buerger.de/smartphones
die autorin
TECHNIK PLUS SENSIBILITÄT:
SICHERER SMARTPHONE-
EINSATZ IN UNTERNEHMEN
Im Arbeitsalltag setzen sich Smartphones zunehmend durch. Doch Vergesslichkeit, Sorg -
losigkeit und technische Risiken stellen potenzielle Gefahren für die sensiblen Unternehmens -
daten dar, auf die mit den mobilen Endgeräten zugegriffen wird. Auch ist vielen Nutzern nicht
bewusst, dass der Schutzbedarf eines Smartphones dem eines normalen PCs entspricht.
Aufklärung der Mitarbeiter ist also genauso dringend angeraten wie die Integration der mobilen
Endgeräte in das unternehmensweite Sicherheitskonzept. Dieser Artiekl beschreibt die
wichtigsten Schritte, die ein Unternehmen ergreifen sollte, um Smartphones sicher einsetzen
zu können.
Isabel Münch
(E-Mail: Isabel.Muench@bsi.bund.de)
ist Referatsleiterin für IT-Sicherheitsmanagement
und IT-Grundschutz beim Bundesamt für Sicherheit
in der Informationstechnik. Ihre Arbeitsschwer -
punkte sind die Weiterentwicklung des IT-Grund -
schutzes sowie die Leitung und Koordination von
IT-Sicherheitsanalysen.
Aus dem Business-Alltag sind Smartphones
schon jetzt kaum noch wegzudenken, und
dabei steht ihre Entwicklung erst am Anfang.
So erwartet das Marktforschungs unter -
nehmen IDC in seinem Worldwide Quarterly
Mobile Phone Tracker (vgl. [IDC]), dass die
Zahl der intelligenten Handys in diesem Jahr
um 55 % auf 472 Millionen steigen und sich
bis zum Jahr 2015 noch einmal verdoppeln
wird. Dieser Boom kommt nicht von ungefähr.
Als Kombination aus Mobiltelefon und
Personal Digital Assistant (PDA) erfüllt die
jüngste Genera tion der Smartphones im
Arbeitsalltag immer mehr Funktionen.
Gerade wer viel beruflich unterwegs ist, nutzt
mit mobilen Endgeräten die früher oftmals
unproduktive Reisezeit für Arbeit und berufliche
Interaktion.
Dabei kommt der Geschäftswelt zugute,
dass die Benutzer in ihrem privaten Umfeld
gerne mobil erreichbar sind und diese
Erfahrung in der Arbeitswelt ebenfalls
nicht missen möchten. Doch stehen den
Vorteilen einige Nachteile gegenüber, beispielsweise
menschliche Nachlässigkeit.
Laut einer repräsentativen Umfrage im
Auftrag des BITKOM (vgl. [BIT]) vom
August 2010 haben rund 7 Millionen
Deutsche ihr Mobiltelefon bereits einmal
verloren, rund 4 Millionen ist es schon einmal
gestohlen worden. Dies ist erst recht
erschreckend, wenn man be denkt, wie viele
möglicherweise unternehmenskritische,
sicherheitsrelevante Daten auf diese Weise
abhanden gekommen sind – und zwar
umso mehr, je größer die Datenspeicher
werden. So bestehen dem Marktforscher
Gartner zufolge schon heute 47 % der
Informationen auf mobilen Endgeräten aus
Unternehmensdaten.
Abb. 1: Angriffsziel Smartphone: Schutzbedarf mit dem eines PC vergleichbar.
Menschliche Schwächen,
Diebstahl, technische Risiken
Hinzu kommt die Sorglosigkeit mancher
mobiler Nutzer, die aus Bequemlichkeit
eine einfache Bedienung der Sicherheit vorziehen
oder nach dem „Augen-zu-unddurch”-Prinzip
surfen und telefonieren.
Der Diebstahl mobiler Geräte durch offene
Türen oder Fenster, der Blickkontakt
Unbefugter auf Displays mit vertraulichen
Daten oder die Infizierung mit Schad -
programmen durch die private Nutzung
eines Business-Smartphones bergen glei -
cher maßen potenzielle Gefahren für Unter -
neh mensdaten.
Smartphones unterliegen den gleichen
technischen Risiken wie normale PCs.
Auch Smartphones sind potenzielle Ziele
für Attacken mit Viren, Trojanern oder
Spam, für Hackerangriffe oder gezielten
Datendiebstahl. Analog dazu lässt sich
auch der Schutzbedarf eines Smartphones
mit dem eines PC vergleichen – was aber
vielen Nutzern nicht bewusst ist. In der
aktuellen Bürgerumfrage des BSI (vgl. [BSIb])
war über einem Drittel der Befragten
1/2012

fachartikel
■ Halten Sie Ihre Zugangsdaten unter Verschluss. Geben Sie die PIN sowie Codes so
ein, dass niemand sie mitlesen kann, und wechseln Sie regelmäßig Ihre Passwörter.
■ Lassen Sie das Gerät niemals unbeaufsichtigt herumliegen, um unbefugte Zugriffe zu
vermeiden.
■ Halten Sie das Betriebssystem stets auf dem aktuellen Stand. Installieren Sie die vom
Hersteller empfohlenen Anwen dungs-Updates regelmäßig.
■ Installieren Sie nur solche Apps, die Sie auch regelmäßig nutzen. Wenn es möglich ist,
prüfen Sie kritisch, ob die Zugriffsrechte zum Erfüllen der Funktionalität wirklich
nötig sind – es könnte sich um potenzielle Trojaner-Software handeln.
■ Informieren Sie sich wenn möglich über den jeweiligen Anbieter der App und dessen
Vertrauenswürdigkeit. Hilfreich können dabei beispielsweise Kritiken anderer
Nutzer im Internet sein.
■ Deaktivieren Sie drahtlose Schnittstel len (z. B. WLAN oder Bluetooth), wenn Sie sie
nicht benötigen.
■ Seien Sie vorsichtig bei öffentlichen Hotspots oder ungesicherten bzw. unbekannten
WLAN-Angeboten.
■ Prüfen Sie in den Einstellungen regelmäßig den Akku-Verbrauch. Bei Auffälligkeiten
sollten Sie verdächtige Applikationen im Zweifelsfall deinstallieren.
■ Wenn Sie Ihr Smartphone verlieren, lassen Sie umgehend die SIM-Karte sperren.
Kasten 1: Hinweise zum Schutz Ihres Smartphones.
(36 %) nicht bekannt, dass ein Smartphone
dieselben Sicherheitsvorkehrungen wie ein
PC benötigt. Außerdem hat fast die Hälfte
der befragten Nutzer noch nie ein
Sicherheits-Update eingespielt. Aufklärung
der Mitarbeiter tut also dringend Not,
zumal Sicherheitsexperten von einer
Zunahme IT-gestützter Angriffe über mobile
Endgeräte ausgehen.
Entsprechend breit sollten deshalb die
Sicherheitsrichtlinien eines Unternehmens
angelegt werden. Ein solches Gesamt konzept
setzt bei der Geschäftsführung an, die sich
zunächst vor Augen führen sollte, dass
Sicherheit ein Prozess ist und nur im Ganzen
erreicht und gewährleistet werden kann.
Deshalb muss die Nutzung mobiler End -
geräte für Firmenzwecke von Anfang an in
das unternehmensweite Sicherheits kon zept
integriert werden. Außerdem sollte sich die
Geschäftsführung ihrer Vorbild funktion
bewusst sein und beispielsweise keine Smart -
phones oder Applikationen benutzen, die
Mitarbeitern verboten wurden.
Der Weg zur IT-Sicherheit
Als Standard für die Informationssicherheit
in Unternehmen hat das Bundesamt für
Sicherheit in der Informationstechnik (BSI)
(vgl. [BSI-a]) den IT-Grundschutz erarbeitet.
Dabei handelt es sich um ein betrieblich
einfach zu nutzendes Instrument, um dem
Stand der Technik entsprechende Sicher -
heitsmaßnahmen zu identifizieren und
umzusetzen. Die BSI-Standards zum Infor -
mationssicherheitsmanagement, die IT-
Grundschutz-Kataloge, aber auch die ISO-
27001-Zertifizierung auf der Basis von IT-
Grundschutz werden hierfür als Werk zeuge
eingesetzt. Nach modularem Prinzip lassen
sich für den Umgang mit mobilen End -
geräten einzelne Bausteine – wie etwa zum
Thema Sensibilisierung der Mitar beiter,
mobiler Arbeitsplatz, Schutz vor Schad -
programmen, Firewall oder Virtuelle Pri -
vate Netze (VPN) – zu einem kompletten
Sicherheitsgerüst zusammenfügen.
Schutzbedarf wie
ein Computer
Wenn es also darum geht, Smartphones in
die Unternehmens-IT einzubinden, sollte
zunächst Klarheit darüber herrschen, dass
diese auf Grund ihrer Funktio nalität eher
mit Computern als mit Handys vergleichbar
sind. Das müssen auch die Mitarbeiter
verinnerlichen. Denn im Fall ungenügender
Absicherung der Geräte und der Kom -
munikationsschnittstellen (z. B. WLAN
oder Bluetooth) können sowohl Gespräche
abgehört werden als auch sensible Daten –
wie Adressbucheinträge, Ter mine, SMS
oder E-Mails – von Kriminellen ausgespäht
werden.
Malware als Gefahrenquelle
Ein weiteres Risiko liegt in der Infektion
mit Schadprogrammen. Entsprechende
Malware kommt zunehmend in Umlauf.
Eine Infizierung funktioniert dabei wie bei
einem normalen Computer, nämlich beispielsweise
per E-Mail oder über manipulierte
Web-Seiten. Auch zum Download
angebotene Apps können eine Gefahren -
quelle darstellen. Ist ein Smartphone erst
einmal mit einem Schadprogramm infiziert,
können eventuell Daten mitgelesen oder
manipuliert werden. Das dritte wesentliche
Risiko besteht im Ausfall bzw. der Mani -
pulation des Fernzugriffs. Smartphones
werden häufig im beruflichen Umfeld
genutzt, um auf Unternehmensdaten zuzugreifen
– ein äußerst attraktives Ziel für
Angreifer.
Bewusst auf mögliche
Infektionen achten
Der notwendigen Sensibilisierung der Mit -
arbeiter schließt sich die nächste Frage an:
Woran ist eine Infektion mit Schadsoftware
zu erkennen? Dafür gibt es verschiedene
Indikatoren. Ist etwa der Akku-Verbrauch
ungewöhnlich hoch oder schaltet sich das
Gerät unerwartet aus, sollte der Nutzer
misstrauisch werden. Das gleiche gilt, wenn
das Smartphone unbekannte Rufnummern
anwählt. Denn es wäre möglich, dass dabei
persönliche Informationen abgefragt,
Konten bzw. Guthaben manipuliert werden
oder durch die Anwahl kostenpflichtiger
Rufnummern hohe Kosten entstehen.
Argwohn ist auch dann angebracht, wenn
ungewollt persönliche Daten oder SMS versendet
werden, sich ohne Zutun des
Nutzers die PIN verändert oder auf dem
Einzelverbindungsnachweis Verbindungen
aufgelistet sind, die der Nutzer nicht zuordnen
kann.
Notwendige Regelungen treffen
Neben der ständigen Aufmerksamkeit für
Auffälligkeiten dieser Art gehört eine ganze
Palette technischer sowie organisatorischer
Maßnahmen in das unternehmenseigene
Sicherheitspaket. Dafür sollte man im
Vorfeld eine Vielzahl von Regelungen treffen:
■ Welche Daten dürfen gespeichert und
verarbeitet werden?
■ Wie ist mit privaten Daten umzugehen?
■ Welchen Anforderungen an Betriebs -
syste me, Schnittstellen, zentrale Admi -
nis tration oder Sicherheit muss entsprochen
werden?
■ Welche zusätzlichen Sicherheitsmecha -
nismen werden verwendet?
76 77

fachartikel
Hinzu kommen die Besonderheiten der
mobilen Kommunikationsnetze sowie die
Nutzung von WLAN und Bluetooth.
Außerdem sollte man festlegen, unter
welchen Rahmenbedingungen Smart -
phones genutzt werden dürfen und wie sie
unterwegs zu schützen sind. In diese
Kategorie gehören auch Regelungen für
Geräte, die von Besuchern in die Unter -
nehmensräume mitgebracht werden.
Weiter hin sind die notwendigen Schritte bei
Verlust zu definieren. Darüber hinaus müssen
die Benutzer über die Grenzen der
Sicherheitsmaßnahmen ebenso Bescheid
wissen wie über die unternehmensweiten
Richtlinien für den sicheren Einsatz.
Zum Schutz vor Missbrauch oder Dieb -
stahl sollten Smartphones nicht an unsicheren
Orten unbeaufsichtigt zurückgelassen
werden. Verlorene oder gestohlene Geräte
sollten sofort gesperrt werden. Zudem ist
die Abfrage einer PIN oder eines Passworts
sowohl beim Einschalten des Geräts als
auch nach längerer Nichtnutzung oder
beim Wechsel der SIM-Karte eine
Standard-Sicherheitsmaßnahme.
Ob und auf welche Weise zusätzliche
Dienste wie Bluetooth oder WLAN genutzt
werden dürfen, bedarf ebenfalls der
Definition. Nicht benötigte Dienste sollten
generell deaktiviert sein. Vertrauliche
Daten und E-Mails müssen durch geeignete
Maßnahmen zur Authentisierung und
Verschlüsselung vor unbefugtem Zugriff
geschützt werden. Bei Online-Zugriffen
vom Smartphone auf das IT-Netz des
Unternehmens muss außerdem eine sichere
Kommunikation gewährleistet werden.
Hierbei sind Verfahren zu definieren, wie
Verbindungen über die unterschiedlichen
Schnittstellen, beispielsweise über VPN-
Techniken, aufgebaut werden. Bei beson -
ders hohem Schutzbedarf ist der Einsatz
von Krypto-Handys sinnvoll, die eine
durchgängig verschlüsselte Sprach- und
SMS-Kommunika tion ermöglichen.
Was die Speicherung von Daten und
Programmen betrifft, so empfiehlt es sich,
vertrauliche Daten gar nicht oder nur verschlüsselt
auf den Geräten oder zusätzlichen
Speicherkarten abzulegen und sensible
Informationen nicht unverschlüsselt
über das Mobiltelefon weiterzugeben. Zur
Ausfallvorsorge ist zudem eine regelmäßige
Datensicherung notwendig. Für den Fall
des Datenverlustes ist zu definieren, über
welche Mechanismen das letzte Backup
wieder eingespielt werden kann – vor allem
dann, wenn der Mitarbeiter gerade unterwegs
ist.
Links
Empfehlungen für die
Mitarbeiter veröffentlichen
Alle Sicherheitsempfehlungen zum Thema
Smartphones sollten zudem zielgruppengerecht
aufbereitet und in einer Benutzer -
richtlinie unternehmensweit veröffentlicht
werden. Dass sich dieser Aufwand für
Unternehmen lohnt, liegt auf der Hand.
Schließlich legen gesetzliche Regelungen
wie die Eigenkapital-Vorschriften des
Basler Ausschusses für Bankenaufsicht
(Basel II) oder das Gesetz zur Kontrolle und
Transparenz im Unternehmensbereich
(KonTraG) eindeutig fest, dass das
Geschäftsrisiko durch Sicherheitslücken
beim Unternehmer liegt.
Wichtig ist, dass bei allen technischen und
organisatorischen Maßnahmen niemals der
Faktor Mensch außer Acht gelassen wird.
Schließlich nützen die besten technischen
Sicherheitsvorkehrungen nichts, wenn ein
Mitarbeiter während eines Telefonats unterwegs
ungeniert und lautstark sensible Unter -
nehmensinformationen verrät. ■
[BIT] Bitkom, Handy-Diebstahl weit verbreitet, siehe: http://www.bitkom.org/de/presse/66442_64952.aspx
[BSI-a] Bundesamt für Sicherheit in der Informationstechnik, siehe: www.bsi.bund.de
[BSI-b] Bundesamt für Sicherheit in der Informationstechnik, BSI-Bürgerumfrage zur
Internetsicherheit, siehe:
https://www.bsi.bund.de/ContentBSI/Presse/Pressemitteilungen/Presse2011/BSI-Buergerumfrage-Internetsicherheit_11022011.html
[IDC] IDC, Worldwide Quarterly Mobile Phone Tracker, siehe:
http://www.idc.com/research/viewfactsheet.jsp?containerId=IDC_P8397
1/2012