Embed Size (px)
Citation preview
Lean Architecture
2012 Lean Architecture oder auch Schlanke Architektur ist ein Lösungsansatz, der die Aufgabe adressiert, das richtige Maß an Architektur zu finden und die richtigen Elemente in die Architekturplanung einzubeziehen.
Lean Architecture 2012
2
Inhaltsverzeichnis
1 Abstract ........................................................................................................................................... 4
2 Begriffe ............................................................................................................................................ 5
2.1 Architektur ............................................................................................................................... 5
2.2 Lean ......................................................................................................................................... 5
2.3 Lean Architecture .................................................................................................................... 8
3 Vorgehensmethoden in der Softwareentwicklung ....................................................................... 11
3.1 Plangetriebene Methoden am Beispiel Wasserfall ............................................................... 11
3.1.1 Die Vorgehensweise ...................................................................................................... 11
3.1.2 Wasserfallmodell und Architektur ................................................................................ 12
3.1.3 Auswirkung auf die Architektur ..................................................................................... 13
3.2 Agile Methoden am Beispiel Scrum ...................................................................................... 14
3.2.1 Die Vorgehensweise ...................................................................................................... 14
3.2.2 Scrum und Architektur .................................................................................................. 15
3.2.3 Auswirkung auf die Architektur ..................................................................................... 16
3.3 Artefakte und Regeln............................................................................................................. 17
4 Ansätze .......................................................................................................................................... 20
4.1 Angemessenheit der Geschäftsprozesse ............................................................................... 20
4.2 Refactoring ............................................................................................................................ 22
4.3 Evolutionäres Design ............................................................................................................. 23
4.3.1 Divide, Conquer and Integrate ...................................................................................... 24
4.3.2 Inkrementelles Design ................................................................................................... 24
4.3.3 Rapid Prototyping .......................................................................................................... 25
4.4 Tools haben kaum Auswirkung auf Qualität der Architektur ................................................ 25
4.5 Architektur-Dokumentation .................................................................................................. 26
4.6 YAGNI vs. BFUD ..................................................................................................................... 27
4.7 Minimale Transaktionskosten ............................................................................................... 28
5 Fazit – Wie kann Lean Architecture erreicht werden .................................................................... 30
6 Quellen .......................................................................................................................................... 32
7 Forschung und Lehre leben vom Gedankenaustausch, dabei helfen klare Vereinbarungen ....... 34
Lean Architecture 2012
3
Tabellenverzeichnis
Tabelle 1: Die 14 Lean Prinzipien ............................................................................................................ 7
Tabelle 2: Die 14 Lean Prinzipien im Kontext Architektur ..................................................................... 10
Tabelle 3: Artefakte und Regeln je Vorgehensmethode ...................................................................... 17
Tabelle 4: Lean Prinzipien in plangetriebenen und agilen Vorgehensmethoden ................................. 18
Abbildungsverzeichnis
Abbildung 1: Phasenübergänge im Wasserfallmodell .......................................................................... 12
Abbildung 2: Wie häufig werden Features eines Systems durchschnittlich genutzt [Standish Group
1994] ...................................................................................................................................................... 21
Abbildung 3: Koevolutionsmodell des Designs nach Maher, Poon und Boulanger von 1996
[BROOKS11, S. 79] ................................................................................................................................. 23
Abbildung 4: Kosten der Softwareentwicklung [nach Lui 2008] ........................................................... 27
Abbildung 5: Gegenüberstellung von YAGNI und BUFD (siehe [COPLIEN11]) ...................................... 28
Abbildung 6: Erweiterung der Vorgehensmodelle hin zu Lean Prinzipien ............................................ 31
Lean Architecture 2012
4
1 Abstract
In der Ära der plangetriebenen Methoden befassten sich Softwarearchitekten mit langwierigem Big
Front-Up Design. Dessen Ergebnisse neigten dazu, schon bei kleinen Umweltveränderungen oder gar
Design-Fehlern auseinanderzufallen. Was verstärkend hinzukommt, ist, dass die Ära der
plangetriebenen Methoden noch lange nicht vorbei ist.
In der agilen Welt wird Architekturplanung häufig gar nicht in Betracht bezogen. Hier scheint der
Fokus einzig auf schnellem Geschäftserfolg zu liegen. Kurzfristig funktioniert dies zumeist, auf lange
Sicht wirkt sich die Vernachlässigung der Architektur eines Softwaresystems eher nachteilig aus.
Meine These lautet, das, wenn weder Big Front-Up Design noch Vernachlässigung von
Architekturplanung funktionieren, ein Lösungsweg in einer Mischung zwischen plangetriebenen und
agilen Vorgehensmethoden liegen könnte.
Lean Architecture oder auch Schlanke Architektur ist solch ein Lösungsansatz, der die Aufgabe
adressiert, das richtige Maß an Architektur zu finden und die richtigen Elemente in die
Architekturplanung einzubeziehen.
Lean Architecture 2012
5
2 Begriffe
In den folgenden Abschnitten sollen grundlegende Begriffe bekannt gemacht werden.
2.1 Architektur
Der Architekturbegriff ist für IT-Systeme nicht eindeutig definiert. Grundsätzlich werden hier unter
Architektur die Fundamente und tragenden Säulen eines Software-Systems verstanden. Sie
beschreibt
die grundlegenden Bestandteile eines Systems und deren Funktion
die Beziehungen (Schnittstellen) dieser Bestandteile untereinander
die Umwelt des Systems, also z.B. seine Partnersysteme
die Beziehungen (Schnittstellen) zwischen System und Umwelt
Die Architektur liefert darüber hinaus einen Überblick über die Komplexität eines Systems.
Implementierungsdetails des Systems gehören nicht zu dessen Architektur (siehe [Vogel08, S. 8ff]).
Architektur liegt nicht auf der Straße, sie wird entweder mühsam aus Anforderungen und
Rahmenbedingungen gewonnen oder unter Nutzung von Erfahrungen aus vergangenen Projekten,
z.B. unter Einbeziehung von Entwurfsmustern oder Referenzarchitekturen, hergeleitet. Dabei ist der
Anspruch, nicht einfach eine Architektur zu entwerfen, sondern vielmehr eine gute und
angemessene Architektur, die den Anforderungen und Rahmenbedingungen gerecht wird.
Also entwickeln wir eine gute Architektur. Laut James Shore zeichnet sich gute Architektur dadurch
aus, leicht verständlich zu sein und die sie beschreibende Software mit vertretbarem Aufwand
erstell- und anpassbar zu machen, während die Software ein angemessenes Laufzeitverhalten zeigt
(siehe [SHORE06]).
Das die leichte Änderbarkeit einer Software eine wichtige Eigenschaft ist, die von ihrer Architektur
unterstützt werden muss, zeigt sich daran, dass die Kosten einer Software durchschnittlich zwischen
40 und 90 Prozent während ihrer Wartungsphase entstehen, also wenn die Software bereits
produktiv eingesetzt wird (POPPENDIEC07, S. 20).
Wodurch unterstützt eine Architektur eine leichte Änderbarkeit der Software, die sie beschreibt? Die
Antwort auf diese Frage folgt später.
2.2 Lean
Lean bzw. Lean Management ist ein System zur Optimierung von Wertschöpfungsketten aus Sicht
von Kunden und Anbietern, wobei überflüssige Tätigkeiten vermieden werden. Ergebnis der
Optimierung sind effiziente Prozesse, die flexibel auf Veränderung reagieren können.
Lean Management hat seinen Ursprung bei Toyota, bzw. genauer im Toyota Produktionssystem
(TPS), das seinen größten Entwicklungsschub während des Ölschocks 1973 hatte, als Toyota praktisch
alle Einzelteile und Rohstoffe für seine Produktion importieren musste (siehe LIKER04, S. 15ff).
Zu den Zielen von Lean zählen beispielsweise beste Qualität, geringste Kosten, nachhaltig kurze
Durchlaufzeiten und größter Kundennutzen. Dabei basiert Lean auf zwei Grundpfeilern:
Lean Architecture 2012
6
Wertschätzung für die am Prozess beteiligten Menschen und der Wille, den Prozess ständig zu
verbessern.
Ohne kompetente Mitarbeiter, die gern ihrer Tätigkeit nachgehen, ist die Einführung von Lean oder
das Ausleben der Prinzipien von Lean nicht denkbar. Um einen Prozess verbessern zu können, muss
ich mich damit auseinandersetzen und das tue ich lieber, wenn ich dafür von meinen Kollegen
Wertschätzung erhalte und dafür aber auch meinen Kollegen dieselbe Wertschätzung zu teil werden
lasse. Dabei darf es keine Rolle spielen, ob ich Manager oder Architekt oder Entwickler bin.
Kontinuierliche Prozessverbesserung kann auf vielfältige Art und Weise durchgeführt werden. Bei
Lean wird beispielsweise aktives Wissensmanagement betrieben und mit den Mitarbeitern
Retrospektiven durchgeführt, deren Ergebnisse wiederum in die Prozessverbesserung einfließen. Bei
Problemen wird beispielsweise Root-Cause-Analysis1 durchgeführt. Prozessverbesserung im Kontext
Lean meint hier Kaizen2, nicht den Kontinuierlichen Verbesserungsprozess (KVP)3 in deutschen
Unternehmen und Behörden.
Eine wichtige Grundlage dafür, dass Lean bzw. Lean Management in einer Organisation funktioniert,
ist die langfristige, tatkräftige Unterstützung des Lean Ansatzes durch das Management der
Organisation.
Ähnlich den Prinzipien hinter dem Agilen Manifest gibt es Lean Prinzipien, mit deren Hilfe die Ziele
von Lean erreicht werden können. Im Folgenden werden diese 14 Prinzipien kurz beschrieben.
Weiterführende Informationen können [LARMAN08, S. 65ff] entnommen werden.
Lean Prinzip Interpretation
Workflow visualisieren
Bilde den durchgeführten Prozess grafisch so einfach wie möglich ab. Stelle ihn so dar, wie er tatsächlich gelebt wird und nicht, wie er eigentlich sein sollte. Das ist eine der Regeln in Kanban (siehe [ANDERSON11, S. 44f]).
Einsatz der richtigen Werkzeuge
Die Software-Werkzeuge, die den Prozess und die Mitarbeiter bei ihrer Arbeit unterstützen, sollten auch eingesetzt werden. Erinnert mich an den Joel-Test in [SPOLSKI07]: 9. Do you use the best software money can buy?
Gleichmäßige Aufgabenverteilung
Ziel dieses Prinzips ist es, ein Arbeitstempo zu finden, das von den Mitarbeitern über einen langen Zeitraum eingehalten werden kann, ohne die Mitarbeiter zu überlasten, aber auch ohne sie zu unterfordern. Korreliert mit dem Prinzip Pull statt Push.
Pull statt Push Anstatt von Managementseite vorzugeben, wie viel einer Aufgabe bis zu einem Termin fertiggestellt sein muss (Push), werden die am Prozess Beteiligten dazu angehalten, selbst festzulegen, wie viel bis zu diesem Termin geschafft werden kann (Pull). Eine implizite Konsequenz dieses Vorgehens ist eine nachhaltige Geschwindigkeit im Prozess. Zum besseren Verständnis sind an dieser Stelle Ausflüge in die Warteschlangentheorie und zu Kanban empfohlen. Der Einfachheit halber verweise ich auf [Goldratt90] und [ANDERSON11]. In Pull statt Push steckt implizit noch ein weiteres Paradigma: „Entscheide so spät wie möglich.“ Plane und führe Aufgaben genau zur richtigen Zeit4
1 Mehr Informationen zur Root-Cause-Analysis siehe [BELLINGER04]
2 Siehe [BRUNNER08, S. 11ff]
3 KVP stellt durch seine Schwerfälligkeit eher einen Kontinuierlichen Verbesserungs-Verhinderungsprozess dar.
4 Just in Time
Lean Architecture 2012
7
Lean Prinzip Interpretation
aus und nicht deutlich vorher, da sich Anforderungen und Rahmenbedingungen bis dahin geändert haben können, deine Arbeit wertlos wird und es dadurch zu Verschwendung von Ressourcen kommt.
Wertflussoptimierung Hier geht es darum, den Kundenauftrag zum frühesten möglichen Zeitpunkt zu erfüllen, zum einen, um den Kunden zufrieden zu stellen und nicht unwichtiger, zum frühesten möglichen Zeitpunkt Feedback vom Kunden zu erhalten und dieses Feedback in den Wertschöpfungsprozess einfließen zu lassen.
Entscheidungen mit langfristigem Fokus treffen
Auf den ersten Blick kollidiert dieses Paradigma mit Wertflussoptimierung und Pull statt Push. Es gilt, für Entscheidungen nicht nur das aktuell relevante Problem zu beachten, sondern mindestens die bis jetzt absehbaren künftigen Aufgaben in den Entscheidungsprozess mit einzubeziehen.
Probleme zuerst lösen Kommt es zu Fehlern oder Problemen, soll nach der Ursache gesucht werden. Erst dann darf mit der eigentlichen Aufgabe fortgefahren werden.
Menschen und Teams weiterentwickeln
Ist ein Team der Ansicht, dass eine bestimmte Vorgehensweise den Prozess besser unterstützt als die bisher genutzte Methode, soll das Team dazu bevollmächtigt werden, die Vorgehensweise auszuprobieren und ausreichend Unterstützung bekommen, sein Ziel zu erreichen. Im Idealfall tritt die Prozessverbesserung tatsächlich ein. Ist die Vorgehensweise wider Erwarten nicht zielführend, hat das Team dennoch wichtige Erfahrungen gesammelt.
Entscheider aus dem Team
Idealerweise werden Entscheider aus den eigenen Mitarbeitern rekrutiert. Sie kennen das Aufgabenumfeld und sind durch ihre konkrete Erfahrung eher in der Lage, die richtigen Entscheidungen zu treffen.
Selbst kümmern Dieses Prinzip korreliert mit den Prinzipien Entscheider aus dem Team, Probleme zuerst lösen und Menschen und Teams weiterentwickeln. Das Team muss bevollmächtigt sein, sich eigenständig um Probleme und um Prozessverbesserung zu kümmern.
Entscheidungen im Konsens treffen
Ein bevollmächtigtes Team trifft Entscheidungen im Idealfall im Konsens. Die anschließende Umsetzung dieser Entscheidung kann dann effektiver/schneller erfolgen, da alle Teammitglieder hinter der Entscheidung stehen.
Lean weitertragen Dort wo Lean erfolgreich ist, sollte es an die Umgebung weitergegeben werden. Setzen Partner und Kunden Lean ein? Bringt ihnen Lean Vorteile bei der eigenen Prozessgestaltung?
Kontinuierliche Verbesserung
Es reicht uns nicht, zu verstehen, warum Dinge sind wie sie sind. Wir gehen weiter: Müssen die Dinge sein, wie sie sind? Gibt es bessere Lösungen, die die anderen Prinzipien von Lean besser unterstützen? Suche im Fehlerfall den Grund des Fehlers, nicht den Schuldigen.
Regeln gemeinsam definieren
Das Prinzip meint die Festlegung von Regeln mit denen der Prozess eingehalten bzw. die Prozesserfüllung gemessen werden kann. Die am Prozess beteiligten Mitarbeiter stimmen die Regeln ab (siehe Entscheidungen im Konsens treffen).
Tabelle 1: Die 14 Lean Prinzipien
An Lean Interessierte seien auf [LARMAN08, S. 44ff] verwiesen. Hier ist mit dem Lean Thinking House
das Modell hinter Lean, Lean Management und Lean Thinking trefflich beschrieben. Wem dies noch
nicht reicht, kann sich die empfohlener Literatur in [LARMAN08, S. 90f] zu Gemüte führen.
Lean Architecture 2012
8
Die Prinzipien hinter dem Agilen Manifest weisen mehrere Überschneidungen mit den Prinzipien von
Lean auf. Eine Folge davon ist, dass Lean bzw. Lean Management bereits auf die eine oder andere Art
und Weise in den verschiedenen Agilen Methoden integriert ist.
2.3 Lean Architecture
Wenn ich versuche, ein Problem auf die einfachste mögliche Art und Weise zu lösen, ist die Lösung
bezogen auf das konkrete Problem optimal, auf der anderen Seite aber bei sich veränderten
Anforderungen schwer anpassbar. Wer einmal die Erfahrung gemacht hat und Anforderungen, die
ursprünglich nicht vorgesehen waren, in ein System zu planen oder umzusetzen, weiß, wie aufwändig
dies sein kann. Wer diese Erfahrung mehr als einmal gemacht hat, lernt recht schnell, seine Software
so zu entwerfen und zu bauen, dass sie für ungeplante Änderungen offen ist. Diese Änderbarkeit
kommt allerdings nicht kostenlos ins System.
Hooks bieten eine Möglichkeit, einen Softwareentwurf offen für Änderungen zu gestalten. Dabei
schätzt der Architekt oder der Entwickler die Wahrscheinlichkeit von Änderungen innerhalb einer
Komponente im Voraus ab und sieht dafür „Haken“ vor, also leere Methoden mit vorgegebenen
Rückgabewerten und Parametern, in die Funktionalität bei Bedarf integriert werden kann, ohne den
Rest des Entwurfs zu verändern. Nun können wir nur schwer vorhersagen, an welchen Punkten eines
Entwurfs künftig Änderungen auftreten könnten, also werden Hooks an beliebig vielen Stellen
vorgesehen. Der Nachteil dieses Ansatzes ist eine Architektur, die komplexer ist, als die aktuellen
Anforderungen verlangen würden. Die Kunst ist, den Mittelweg zwischen Planung bisher nicht
vorgesehener Änderungen und starren, unflexiblen Systemen zu finden.
In Abschnitt 2.2 wurden die 14 Prinzipien von Lean kurz beschrieben. Wir versuchen, diese Prinzipien
in einen Kontext mit Softwarearchitektur zu bringen und so eine Definition für Lean Architecture zu
finden.
Lean Prinzip Lean Prinzip auf Softwarearchitektur angewendet
Workflow visualisieren Es existiert eine Reihe von Architekturmanagement-Frameworks im Kontext von Enterprise Architektur, die einen Prozess vorgeben. In Softwareprojekten wird in der Regel nach einem Vorgehensmodell verfahren, das den Prozess vorgibt. Der Architekturentwurf ist häufig in diesen Prozess eingebettet und mit sehr wenigen eigenen Regeln ausgestattet.
Einsatz der richtigen Werkzeuge Welche Werkzeuge stehen zur Unterstützung eines Architekturentwurfs zur Verfügung? Aus meiner Sicht gibt es kein Werkzeug für den Architekturentwurf, dass gegenüber anderen Tools herausragt, also unbedingt eingesetzt werden muss. Wenn Toolunterstützung zur Verfügung steht, sollte sie auch genutzt werden. Wenn allerdings Tools zum Selbstzweck eingesetzt werden, leidet die Architektur in der Regel darunter.
Gleichmäßige Aufgabenverteilung Korreliert mit dem Prinzip Pull statt Push. Wenn der sich in Arbeit befindliche Architekturentwurf andere Teammitglieder behindert, weil er bezogen auf ein konkretes Problem noch nicht fertig ist, müssen die Teammitglieder beim
Lean Architecture 2012
9
Lean Prinzip Lean Prinzip auf Softwarearchitektur angewendet
Entwurf unterstützen. Prinzipiell steckt in jedem Entwickler ein Architekt. Alternativ entsteht bei den Architekten Überlastung und die Qualität des Entwurfs lässt zu wünschen übrig.
Pull statt Push Ich beschreibe die Architektur nicht vollständig im Voraus, sondern kümmere mich nur um den Teil, der für mein aktuelles Problem erforderlich ist. Sinnvollerweise betrachte ich auch die in der nahen Zukunft geplanten Anforderungen und versuche, sie bei der Lösung meines aktuellen Problems zu berücksichtigen. Warum ist ein vollständiger Entwurf nicht sinnvoller? Unter Umständen ist mein Entwurf veraltet, wenn ich endlich an den kritischen Stellen ankomme. Bereits geleisteter Aufwand wäre verschwendet und das ist bei Lean Management verpönt.
Wertflussoptimierung Eine Softwareauslieferung an den Kunden erfolgt, sobald sie für ihn nutzbar ist und nicht erst, wenn sie vollständig fertig ist. Der Kunde hat so Gelegenheit, die Software zu nutzen bzw. zu prüfen und mir Feedback zu geben. Als Konsequenz daraus kann ich sein Feedback in die Architektur des Systems einfließen lassen und bei der Weiterentwicklung des Systems berücksichtigen. Im Kontext Architektur ist das Feedback von größerer Relevanz als die frühzeitige Auslieferung der Software an den Kunden. Wichtig ist hier das iterative Vorgehen – das Feedback muss regelmäßig kommen, also muss regelmäßig geliefert werden.
Entscheidungen mit langfristigem Fokus treffen
Dieses Prinzip kommt dem Bedarf nach Architekturplanung sehr entgegen. Es reicht nicht aus, Architekturentscheidungen für das aktuelle Problem zu treffen. Sinnvollerweise werden die Probleme, die in der nahen Zukunft bearbeitet werden sollen, in den Planungsprozess einbezogen (siehe Pull statt Push).
Probleme zuerst lösen Treten Fehler in der Architektur auf, muss der tiefere Grund gesucht werden. Ein im Kontext Lean empfohlenes Mittel ist die Root-Cause-Analyse. Frage bis zu fünf Mal, Warum ein Problem besteht, um dem eigentlichen Problem auf den Grund zu gehen.
1. Warum trägt die Architektur nicht?
Weil sie den neuen Anforderungen des Kunden nicht mehr gerecht wird.
2. Warum wird die Architektur den neuen Anforderungen des Kunden nicht mehr gerecht?
Weil seine neuen Anforderungen eine Services bedingen und diese mit der aktuellen Architektur nicht abgebildet werden können.
3. Warum kann die Architektur keine Services abbilden?
Weil die Architektur bisher auf Client-Server basiert hat und dort keine Services vorgesehen sind.
Ach so!
Menschen und Teams weiterentwickeln
Den Architekten wird wie den anderen Teammitgliedern auch, Freiraum eingeräumt, Methoden, Frameworks, Muster
Lean Architecture 2012
10
Lean Prinzip Lean Prinzip auf Softwarearchitektur angewendet
daraufhin zu untersuchen, ob sie für die Architektur eines Systems eine Verbesserung darstellen. Ist die Evaluierung erfolgreich, profitiert das gesamte Team.
Entscheider aus dem Team Idealerweise sind die Architekten die erfahrensten Mitarbeiter der jeweiligen Problemdomäne. Durch ihr tiefes Wissen sind sie in der Lage, konkrete Probleme leichter zu erfassen und zu lösen als domänenfremde Kollegen. Der Ansatz birgt natürlich auch Probleme; je nach Situation kann domänenfremde Erfahrung ebenfalls von Vorteil sein.
Selbst kümmern Genau wie jedes andere Teammitglied gehen Architekten aktiv auf Probleme und Herausforderungen zu. Geschieht dies nicht, besteht die Gefahr, dass die Architektur technische Schulden aufhäuft und unflexibel wird.
Entscheidungen im Konsens treffen
Konsens in Bezug auf die Architektur erreiche ich als Architekt, wenn ich meine Entwicklerkollegen als Kunden verstehe und die Architektur das Produkt ist, mit dem sie arbeiten wollen / müssen. Ich hole Feedback ein und lasse dieses Feedback, wo es möglich und sinnvoll ist, in die Architektur einfließen.
Lean weitertragen Wenn die Lean Prinzipien im Kontext Softwarearchitektur in meinem Projekt bzw. für mein Produkt funktionieren, können sie auch in Nachbarprojekten funktionieren. Architekten neigen ohnehin dazu, sich mit Kollegen auszutauschen.
Kontinuierliche Verbesserung Ich habe eine Architektur vorliegen und hinterfrage sie immer wieder, um sie zu optimieren bzw. an geänderte Bedingungen anzupassen.
Regeln gemeinsam definieren Im Kontext Architektur kann dies bedeuten, dass Architekten und Entwickler vereinbaren, welche Artefakte in welcher Detailtiefe von den Architekten zur Verfügung gestellt werden sollen, damit Architektur für die Entwickler greifbar wird.
Tabelle 2: Die 14 Lean Prinzipien im Kontext Architektur
Eine aus meiner Sicht naheliegende Annahme ist, dass aus dem Maß der Anwendbarkeit bzw.
Anwendung der Lean Prinzipien auf die mit der Erstellung und Pflege einer Softwarearchitektur
verbundenen Tätigkeiten und Regeln ableitbar ist, ob in einem konkreten Projekt eine Lean
Architecture vorliegt bzw. realisierbar ist.
Lean Architecture 2012
11
3 Vorgehensmethoden in der Softwareentwicklung
In der heutigen Welt der Softwareentwicklung können wir grundsätzlich zwei Arten von
Vorgehensmethoden5 beobachten: plangetriebene und agile Methoden. Mischformen beider
Methoden sind, abgesehen von der Anwendung von Extreme Programming-Praktiken in
plangetriebenen Vorgehensmethoden, eher ungebräuchlich.6
Plangetriebene Methoden zeichnen sich durch abgeschlossene, aufeinanderfolgende Projektphasen
aus, in denen jeweils bestimmte Prozesse eingehalten, Artefakte erstellt und Regeln erfüllt sein
müssen, bevor die nächste Phase begonnen werden kann. Zu den klassischen, plangetriebenen
Methoden zählen beispielsweise
Wasserfallmethode, weiterführende Informationen siehe [ROYCE87]
V-Modell XT, siehe [VMODEL10] und
Rational Unified Process (RUP), siehe [RUP11]
Agile Methoden zeichnen sich durch zeit- oder aufgabengesteuertes, iterativ-inkrementelles
Vorgehen aus. In ihrem Mittelpunkt stehen Personen und Kommunikation. Agile Methoden sind
unter anderen
Scrum, weiterführende Informationen siehe [Pichler08],
Crystal, siehe [COCKBURN05],
Feature-Driven Development (FDD), siehe [PALMER02] und
Extreme Programming, siehe [BECK05]
In den folgenden Abschnitten wird der Umgang mit Architektur in plangetriebenen und agilen
Vorgehensmethoden am Beispiel von Wasserfallmethode und Scrum beschrieben.
3.1 Plangetriebene Methoden am Beispiel Wasserfall
3.1.1 Die Vorgehensweise
Mit plangetriebenen Vorgehensmodellen zu erstellende Systeme starten mit einer Analysephase, in
der Anforderungen7 an das System erhoben werden. In der Konzeptionsphase wird beschrieben, was
getan werden muss, damit das System diesen Anforderungen gerecht wird, während in der
Entwurfsphase festgelegt wird, wie die Anforderungen umzusetzen sind. Wenig überraschend
werden Anforderungen in der Implementierungsphase gemäß dem Entwurf, also dem „Wie“
umgesetzt und in der Testphase die korrekte Realisierung des Systems gemäß dem „Was“ aus der
Konzeptionsphase geprüft. Ist diese Prüfung erfolgreich, kann das System mit der abschließenden
Einführungsphase seinem Bestimmungszweck zugeführt und benutzt werden.
5 Ich verwende die Begriffe Vorgehensmodell und Vorgehensmethode synonym.
6 Wer jetzt über V-Modell XT mit Scrum nachdenkt, betrachte bitte den Fokus beider Methoden?
Angenommen, es soll die Leistungsfähigkeit einer Autobahn festgestellt werden, dann liefert V-Modell XT die Anzahl der Autos, die auf der Autobahn geparkt werden kann. Scrum hingegen liefert die Anzahl der Autos, die die Autobahn pro Zeiteinheit passieren können. Die erste Zahl ist mit der zweiten in keiner Weise vergleichbar und so verhält es sich auch mit den beiden Modellen. 7 Es wird in der Regel zwischen funktionalen und nicht-funktionalen Anforderungen sowie Rahmenbedingungen
unterschieden (siehe [VOGEL08, Seite 107ff]).
Lean Architecture 2012
12
Im Wasserfallmodell sind Phasenübergänge in beiden Richtungen nur zur zwischen benachbarten
Phasen zugelassen (siehe Abbildung 1). Eine neue oder geänderte Anforderung muss zwingend über
die Analysephase in das System einfließen und Schritt für Schritt die folgenden Phasen bis zur
Einführung durchlaufen. Ein im Betrieb des Systems entdeckter Fehler in einer Anforderung muss
schrittweise über alle vorangehenden Phasen an den jeweiligen Vorgänger übergeben werden. Die
fehlerhafte Anforderung wird in der Anforderungsanalyse korrigiert und die erforderliche Anpassung
über die nachgelagerten Phasen nachgezogen.
In jeder Phase des Wasserfallmodells müssen zwingend Artefakte erstellt werden, deren Existenz und
Qualität Bedingung8 für den Start der jeweils nächsten Phase ist, z.B. der Anforderungskatalog in der
Analysephase, das Grobkonzept in der Konzeptionsphase, das Feinkonzept in der Entwurfsphase, die
Programmierdokumentation in der Implementierungsphase usw. Bei einer neuen oder geänderten
Anforderung müssen alle von der Änderung betroffenen Artefakte angepasst werden und die
Qualität dieser Artefakte erneut bewertet werden.
3.1.2 Wasserfallmodell und Architektur
Die Software- und Systemarchitektur im Wasserfallmodell wird während der Konzeptions- und
Entwurfsphase definiert. Während in der Konzeptionsphase die Grobarchitektur beschrieben werden
soll, muss in der Entwurfsphase die Feinarchitektur festgelegt werden. Dabei gilt es, die Architektur
so vollständig wie möglich zu beschreiben. Architekturaspekte, die in dieser Phase nicht vorhanden
bzw. nicht bereits in allgemeingültigen Dokumenten z.B. für Referenz- oder
Unternehmensarchitektur beschrieben sind, stehen für die Implementierungsphase nicht zur
Verfügung und können nicht umgesetzt werden. Wird eine solche Lücke während der
Implementierung entdeckt, muss der fehlende, falsche oder unvollständige Architekturaspekt
ergänzt/korrigiert werden. Die Implementierung des Architekturaspekts darf erst
begonnen/fortgesetzt werden, wenn die entsprechende Dokumentation zur Verfügung steht.
In plangetriebenen Vorgehensmodellen wird häufig zwischen fachlicher und technischer Architektur
unterschieden und diese beiden Architektursichten in getrennten Dokumenten festgeschrieben. Die
technische Architektur ist dabei in der Regel von der fachlichen Architektur abhängig. Im Idealfall
8 Der Abschluss einer Phase kann z.B. durch Passieren sogenannter Quality Gates geprüft und dokumentiert
werden (siehe [AARON09]).
Analyse
Konzeption
Entwurf
Implementierung
Test
Einführung
Abbildung 1: Phasenübergänge im Wasserfallmodell
Lean Architecture 2012
13
steht die fachliche Architektur bereits fest, wenn mit der Beschreibung der technischen Architektur
begonnen wird.
Die im vorangegangenen Abschnitt beschriebene Prüfung von Artefakten gilt auch für
Architekturartefakte. Big Picture, Grob- und Feinarchitektur aus fachlicher und technischer Sicht
müssen in ausreichender Qualität vorhanden sein, bevor die Implementierungsphase begonnen
werden darf.
3.1.3 Auswirkung auf die Architektur
Die Software- und Systemarchitektur in mit plangetriebenen Methoden durchgeführten Projekten
kann monolithische Strukturen aufweisen und auf Grund der Mächtigkeit der Methode schwer
änderbar sein.9 Eine Ursache hierfür ist die Annahme, dass die Anforderungen, die mit der Software-
und Systemarchitektur erfüllt werden sollen, vollständig beschrieben sind. Entsprechend wird
Änderungen oder Änderbarkeit der Software auf Architekturebene wenig bis kein Raum gewährt.
Kommt es trotzdem zu Änderungen, sind häufig hohe Kosten bei Planung und Durchführung von
Änderungen die Folge.
Eine weitere Ursache für die Schwerfälligkeit gegenüber Änderungen ist in der umfangreichen
Konzeption und Dokumentation der Architektur zu finden. Um dem Prozess der plangesteuerten
Methode gerecht zu werden, ist eine hohe Anzahl von architekturrelevanten Artefakten zu erstellen.
Diese Artefakte gehören teilweise nur indirekt zur Architektur, sind aber für deren Beschreibung im
Rahmen der Methode zwingend erforderlich. Werden diese Architektur-Artefakte nicht in
ausreichender Qualität zur Verfügung gestellt, werden Quality Gates der plangetriebenen Methode
nicht erfüllt und das Softwareprojekt darf nicht fortgeführt werden. Zu diesen Architekturartefakten
können folgende Dokumente gezählt werden.
Big Picture bzw. Architekturüberblick
Grobkonzept oder Grobarchitektur
Feinkonzept oder Detailarchitektur
Schnittstellenverträge und -beschreibungen
Serviceverträge und -beschreibungen
Sicherheitskonzept
Formal müssen unabhängig vom Zeitpunkt eines Änderungsbedarfs alle diese Dokumente angepasst
werden, bevor die Änderung durchgeführt werden darf. In der Realität werden die Anpassung der
Dokumente und die Änderung am System oft parallel vorgenommen, da aus den Dokumenten heraus
teilweise schwer ersichtlich ist, welche Änderung am System durchgeführt werden müssen, damit
der Änderungsbedarf erfüllt werden kann. Damit wird zum einen die plangetriebene Methode
konterkariert und eher ein iteratives Vorgehen wie in Abschnitt 4.3 beschrieben durchgeführt, zum
anderen gezeigt, dass die gewählte plangetriebene Vorgehensmethode in ihrer Reinform schwer
anwendbar ist.
Wenn sich ein Vorgehensmodell nicht für Änderungen eignet, warum sollte es dann überhaupt für
die Durchführung eines Softwareprojekts angewendet werden? Sind die Agilen Methoden nicht
9 Die Einschränkung ist keine seltene Ausnahme, gilt aber nicht für jeden Architekturentwurf. Es sind durchaus
Systeme denkbar, bei denen monolithische Architekturen nicht als Nachteil betrachtet werden.
Lean Architecture 2012
14
ohnehin die bessere Wahl für die Softwareentwicklung? Ja und Nein. Es kommt darauf an, welchen
Fokus die Software, die entwickelt werden soll, hat.
Besteht die Gefahr, dass durch Fehler im System Leben auf dem Spiel steht oder große Summen
Geldes verloren gehen können, gleichzeitig aber die Änderungswahrscheinlichkeit von
Anforderungen an das System gering ist oder diese Änderungen nicht zeit-, finanz- und lebenskritisch
sind, ist eine plangetriebene Vorgehensmethode durchaus die bessere Wahl.
Besteht die Gefahr, dass durch die Schwerfälligkeit einer plangetriebenen Methode Änderungen am
System nicht rechtzeitig durchgeführt werden können und dadurch Leben oder große Geldbeträge
auf dem Spiel stehen, tendiere ich eher zur Anwendung von Agilen Methoden.
Die Steuerungssoftware eines Satelliten oder eines Raumschiffes beispielsweise wird eher mit Hilfe
einer klassischen, plangetriebenen Vorgehensmethode erstellt werden. In [Boehm04, S. 54ff] sind
fünf kritische Faktoren beschrieben, an Hand derer abgewogen werden kann, ob für eine konkrete
Aufgabenstellung plangetriebene oder agile Methoden angewendet werden sollen. Die Architektur
spielt bei der Abwägung eine eher untergeordnete Rolle, da die Architektur der gewählten Methodik
folgt.
3.2 Agile Methoden am Beispiel Scrum
3.2.1 Die Vorgehensweise
Scrum ist eine agile Vorgehensmethode, die unter anderem für die Durchführung von
Softwareprojekten genutzt werden kann. Scrum legt dabei Wert auf die Menschen im Umfeld des
Projekts und die Kommunikation dieser Personen untereinander. Scrum kennt im Gegensatz zu
plangetriebenen Methoden nur sehr wenige Regeln und Artefakte, was die Methode zu einem
Prozessleichtgewicht macht. Die Vorgehensweise ist iterativ-inkrementell, d.h. innerhalb eines
vorgegebenen Zeitfensters von zwei bis sechs Wochen soll ein vereinbarter Funktionsumfang zur
Verfügung gestellt werden und in diesem Zeitfenster alle für die Erstellung der vereinbarten
Funktionalität erforderlichen Tätigkeiten durchgeführt werden. Scrum kennt nur drei Projektrollen:
Scrum Master, Product Owner und Scrum Team. Scrum kennt weder Projektleiter, noch Risiko- oder
Release Manager, allerdings auch keinen Architekten.
Scrum zeichnet sich wie alle Agilen Methoden dadurch aus, leichter auf geänderte Anforderungen
oder Umweltbedingungen reagieren zu können als dies mit plangetriebenen Vorgehensmodellen
möglich ist. Dadurch, dass ein System oder eine Software nicht erst komplett geplant und nach
diesem Plan umgesetzt wird, sondern in kleinen Schritten vorgegangen wird und nach jedem Schritt
geprüft wird, ob sich die Entwicklung noch in die richtige Richtung bewegt, fällt es leichter, den
Abgrund oder den reißenden Fluss zu erkennen, der sich plötzlich vor dem System auftut.10
Die Prüfung, ob sich das Projekt noch in die richtige Richtung bewegt, wird durch den Product Owner
im Sprint Review Meeting im Idealfall im Beisein von Kunden vorgenommen. Das Scrum Team
präsentiert die für den Sprint vereinbarte Funktionalität; der Product Owner bewertet live, ob die
Funktionalität der Vereinbarung entspricht. Vielleicht entscheidet der Product Owner, dass eine
Funktionalität zwar umgesetzt wurde, er aber eine Ergänzung wünscht, die gleich im nächsten Sprint
10
In klassischen Vorgehensmodellen werden diese plötzlich auftretenden Abgründe und Flüsse in der Regel erkannt, wenn sich das Projekt im freien Fall oder im Wasser befindet.
Lean Architecture 2012
15
geliefert werden soll oder dass jetzt, wo eine bestimmte Funktionalität bereit gestellt wurde, eine
ähnliche Funktionalität, die auf der eben gelieferten aufsetzt, angefordert werden kann.11
3.2.2 Scrum und Architektur
Oberflächlich betrachtet wird in Scrum-Projekten kein Augenmerk auf Architektur gelegt. So gibt es
keine Regel, die festlegt, wann und in welchem Umfang Architektur geplant oder berücksichtigt
werden muss. Die Verantwortung für die Architektur liegt beim Scrum Team.
Während der Vorbereitung auf ein Scrum-Projekt, in der Regel im Sprint 0 (die allererste
Iteration) sollen grundlegende Architekturentscheidungen getroffen werden
bei der Planung jedes weiteren Sprints im Sprint Planning Meeting muss für jede User Story
geprüft werden, inwiefern ihre Realisierung Auswirkungen auf die bereits bestehende
Architektur hat oder inwiefern die Architektur des Systems angepasst werden muss, um die
User Story sinnvoll umsetzen zu können.
„Muss“ und „soll“ wurde hier bewusst gewählt; die Realität sieht leider etwas anders aus. User
Stories, die Anforderungen in Scrum, müssen den Geschäftswert einer Software bzw. eines Systems
für den Kunden erhöhen.
„Als Sachbearbeiter benötige ich eine Übersicht über meine offenen Aufgaben, um ihre
zeitgerechte Erledigung gewährleisten zu können.“
Aktivitäten, die den Geschäftswert einer Software nicht direkt erhöhen, werden je nach Projekt nicht
ausgeführt oder vor dem Kunden versteckt. Die Umstellung des Komponentenschnitts einer Software
erhöht den Geschäftswert nicht und wird deswegen entweder nicht durchgeführt, was z.B. die
Änderbarkeit der Software in der Zukunft behindern kann, oder heimlich ausgeführt. Der Kunde
wundert sich vielleicht, dass eine User Story während der Umsetzung aufwändiger ist, als sie ihm
erscheint. Da der Kunde seine Funktionalität letztlich wie gewünscht geliefert bekommt, spielt der
Aufwand für ihn nur eine untergeordnete Rolle. Eine User Story wie die folgende würde heute beim
Agilen Kunden einen Sturm der Empörung hervorrufen.
„Als Systemeigentümer möchte ich eine leicht wartbare Software, um mit vertretbarem
Aufwand auf Änderungen reagieren zu können.“
In dieser User Story ist für den Kunden auf den ersten Blick kein Geschäftswert erkennbar, sollte man
denken. Vielleicht ist es in der Agilen Welt an der Zeit, den Kunden den Geschäftswert leicht
wartbarer Software zu erklären, in der neue oder geänderte Anforderungen untergebracht werden
können, ohne die Software komplett umbauen zu müssen oder neu zu schreiben. Der Aufwand einer
Änderung ist ein Geschäftswert, der minimiert werden kann.
Im Gegensatz zu plangetriebenen Vorgehensmethoden wird bei Scrum-Projekten kein expliziter Wert
auf Architekturdokumentation gelegt. Scrum selbst kennt keine Regel die die Dokumentation einer
Software oder gar der Architektur festschreibt. Zur Einhaltung entsprechender Regeln müssen eher
11
In klassischen Vorgehensmodellen sieht der Kunde in der Regel erst nach Fertigstellung der Software, wie und ob seine Anforderungen erfüllt wurden. Frühes Kundenfeedback wie bei den agilen Methoden ist in plangesteuerten Modellen eher unüblich.
Lean Architecture 2012
16
das Agile Manifest12 oder parallel zu Scrum betriebene Agile Methoden wie Extreme Programming13
herhalten.
3.2.3 Auswirkung auf die Architektur
In meiner Wahrnehmung fällt das Los der Architektur in Agilen Projekten in zwei Kategorien:
Berücksichtigung und Vernachlässigung.
Ein Teil der Agilen Projekte neigt in der Realität dazu, Architekturaspekte zu vernachlässigen oder
deren Berücksichtigung vor den Kunden zu verstecken (siehe Abschnitt 3.2.2). Eine Folge dieses
Verhaltens sind Systeme, deren Änderbarkeit mit steigender Lebensdauer immer stärker abnimmt. Je
stärker das System geändert wurde, desto länger dauert es, eine Änderung vorzunehmen. Zwingend
notwendige Refactorings (siehe Abschnitt 4.2) werden nicht durchgeführt, weil sie den
Geschäftswert der Software nicht erhöhen. Werden neben der Architektur auch noch automatische
Tests außer Acht gelassen, steigt unter Umständen auch die Fehlerhäufigkeit und die
Fehleranfälligkeit im System. Der Endzustand eines solchen Verhaltens ist ein nicht wartbares
System, dessen Schicksal eine Neuentwicklung ist. Im schlechtesten möglichen Fall werden bei dieser
Neuentwicklung dieselben Fehler wiederholt.
In der idealen Scrum-Welt, die glücklicherweise häufig genug auch die reale Welt streift, werden
Architekturaspekte entsprechend aktueller Anforderungen sehr wohl berücksichtigt. Was diesen
Projekten jedoch fehlt ist der ganzheitliche Architekturansatz. Anstatt Architektur vorausschauend zu
planen, wird sie aufgabenbezogen berücksichtigt. Eine Folge ist, dass metaphorisch zehnmal ein
Schritt gemacht wird statt einmal fünf, um zum selben Ergebnis im Kontext der Architektur zu
kommen. Mit vorausschauender Planung meine ich nicht den Architekturansatz der plangetriebenen
Vorgehensmethoden, sondern Architekturplanung für die nächsten drei bis fünf Iterationen. Diese
Vorgehensweise widerspricht in gewissem Maß den Prinzipien von Scrum. Scrum hat allerdings nicht
den Anspruch allgemeingültig zu sein; Anpassungen am Prozess sind sehr wohl zulässig, sofern sie
notwendig sind.14 Eine wichtige Voraussetzung für die vorausschauende Architekturplanung in Scrum
ist ein gut gepflegte Product Backlog und ein Product Owner, der genug Weitblick für die nächsten
Iterationen im Projekt hat.
Architektur muss in Scrum dokumentiert werden, allerdings wird in einem agilen Projekt niemand auf
die Idee kommen, die Systemarchitektur vollständig nach zu dokumentieren. Dies würde bedeuten,
einen wichtigen Vorteil agiler Methoden, Reaktionsfähigkeit auf Änderungen, zu verspielen, denn in
dem Moment, wo eine umfangreiche Dokumentation vorhanden ist, muss sie auch (aufwändig)
gepflegt werden.
Wichtig aus meiner Sicht ist, in Architekturentscheidungen festzuhalten, warum die Architektur an
einer bestimmten Stelle das Entwurfsmuster X enthält und warum man sich gegen Alternative Y
entschieden hat. Verfügt das System dazu noch über ein Big Picture, das den aktuellen Zustand der
12
Siehe http://agilemanifesto.org/ 13
Siehe [BECK04] 14
Eine Anwendung, bei dem in Scrum vorausschauend geplant wird, sind Projekte mit mehreren Teams, wenn zwischen den Teams Abhängigkeiten entstehen, z.B. ein Team eine Zulieferung für ein anderes Team macht und dieses andere Team mit einer Aufgabe erst dann beginnen kann, wenn diese Zulieferung erfolgt ist (siehe [LARMAN09, S. 289ff]).
Lean Architecture 2012
17
Systemarchitektur widerspiegelt, steht dem System aus Architektursicht eine lange Lebensdauer
bevor.
3.3 Artefakte und Regeln
Alle Vorgehensmodelle, egal ob RUP, Scrum, Kanban oder V-Modell XT, haben eine Gemeinsamkeit:
Um das jeweilige Vorgehensmodell zu erfüllen, müssen Regeln eingehalten und Artefakte gepflegt
werden. Je nach Anzahl der zu erfüllenden Regeln bzw. erforderlichen Artefakte wird zwischen
schwer- und leichtgewichtigen Modellen unterschieden. Die nachfolgende Tabelle stellt beispielhaft
einige Vorgehensmodelle gegenüber.
Vorgehensmodell Regeln und Artefakte
Rational Unified Process (RUP) ca. 120
V-Modell XT 70 bis 100, je nach Konsequenz der Regelauslegung
Scrum 13
Extreme Programming (XP) 13
Kanban 4
Hacking 0 Tabelle 3: Artefakte und Regeln je Vorgehensmethode
Je mehr Regeln eingehalten und Artefakte erstellt/gepflegt werden müssen, desto aufwändiger ist es,
Änderungen durchzuführen und dabei den Prozess einzuhalten. Die Komplexität der Artefakte und
die Beziehungen der Artefakte untereinander z.B. über Querverweise oder Versionen von Artefakten,
erhöhen den Aufwand von Änderungen noch mehr.
Die Leichtgewichtigkeit von agilen Methoden wie Scrum oder XP suggeriert weniger Aufwand bei der
Durchführung von Änderungen. Scrum kennt vier durch die Methode vorgegebene Artefakte:
Product Backlog, Sprint Backlog, Taskboard und Burndown Chart. Besteht das Projekt aus mehreren
Teams, gibt es pro Team ein Sprint Backlog, Taskboard und Burndown Chart. Das Product Backlog
verwenden alle Teams, die am Produkt arbeiten, gemeinsam.
In Abschnitt 2.2 ist eine Übersicht der 14 Lean Prinzipien aufgeführt. Im Folgenden versuche ich,
diese Lean Prinzipien auf plangetriebene und agile Vorgehensmethoden anzuwenden. Meine
Annahme ist, dass die vielen Artefakte und Regeln der plangetriebenen Vorgehensmethoden im
Gegensatz zu agilen Methoden die Anwendbarkeit der Lean Prinzipien erschweren, wenn nicht sogar
verhindern.
Wird ein Prinzip von einer der Methoden weder unterstützt noch behindert, ist die entsprechende
Zelle grau markiert. Unterstützt eine Methode ein Lean Prinzip, ist der Hintergrund der Zelle grün,
behindert sie ein Prinzip, ist sie rot hinterlegt.
Lean Prinzip Plangetriebene Methode Agile Methode
Workflow visualisieren Anwendung möglich. Anwendung möglich.
Einsatz der richtigen Werkzeuge
Anwendung möglich. Anwendung möglich.
Gleichmäßige Aufgabenverteilung
Plangetriebene Methoden legen konkret fest, welche Aufgaben in welchem Zeitraum erledigt werden müssen.
Anwendung je nach Methode möglich.
Pull statt Push Siehe vorheriger Punkt. Anwendung möglich.
Lean Architecture 2012
18
Lean Prinzip Plangetriebene Methode Agile Methode
Wertflussoptimierung Eine Prozessoptimierung bedingt Plananpassungen. Dies ist in plangetriebenen Methoden unerwünscht. Plangetriebene Methoden neigen dazu, gegen Optimierung resistent zu sein.
Anwendung möglich.
Entscheidungen mit langfristigem Fokus treffen
Anwendung möglich. Anwendung möglich.
Probleme zuerst lösen Fokus ist die Planerfüllung. Für Aufgaben außerhalb des Plans müssen Puffer vorgesehen werden, sonst scheint eine Planerfüllung schwer möglich.
Anwendung möglich.
Menschen und Teams weiterentwickeln
Eher von der Organisationskultur als von der Methode abhängig.
Eher von der Organisationskultur als von der Methode abhängig.
Entscheider aus dem Team
Siehe vorhergehender Punkt Siehe vorhergehender Punkt
Selbst kümmern Klare Vorgaben für Rollen und Aufgaben. Proaktives Handeln wird eher verhindert als unterstützt.
Anwendung möglich.
Entscheidungen im Konsens treffen
Entscheidungen werden durch das Management getroffen bzw. sind bereits durch die Methode vorgegeben.
Anwendung möglich.
Lean weitertragen Anwendung scheint nicht möglich Anwendung möglich.
Kontinuierliche Verbesserung
Eine Prozessoptimierung bedingt Plananpassungen. Dies ist in plangetriebenen Methoden unerwünscht. Plangetriebene Methoden neigen dazu, gegen Optimierung resistent zu sein.
Anwendung möglich.
Regeln gemeinsam definieren
Regeln werden durch die Methode und das Management festgelegt.
Anwendung möglich.
Tabelle 4: Lean Prinzipien in plangetriebenen und agilen Vorgehensmethoden
Aus dieser Gegenüberstellung lassen sich aus meiner Sicht die folgenden Schlüsse ziehen.
Plangetriebene Vorgehensmethoden sind für die Anwendung der Lean Prinzipien ungeeignet.
Überall dort, wo Interaktionen mit Projektteilnehmern erforderlich sind, sind durch die
Methode klare Regeln vorgegeben.
Agile Methoden unterstützen die Lean Prinzipien. Dort, wo keine explizite Unterstützung
vorliegt, werden die Prinzipien zumindest nicht behindert.
Aus diesen beiden Feststellungen lassen sich folgende Schlüsse für Architekturaspekte in Projekten
mit plangetriebenen und agilen Methoden ziehen.
In einem mit agilen Vorgehensmethoden durchgeführten Projekt kann durch die Anwendung
der Lean Prinzipien eine Lean Architecture erreicht werden. Voraussetzung dafür ist, dass die
Regeln der Methode in Bezug auf die Architektur um die Lean Prinzipien erweitert werden.
Lean Architecture 2012
19
In Projekten mit plangetriebenen Vorgehensmethoden ist dies wegen fehlender
Unterstützung der Lean Prinzipien nicht denkbar.
Lean Architecture 2012
20
4 Ansätze
In den Abschnitten 3.2.2 und 3.2.3 wurde beschrieben, dass architekturgetriebene Tätigkeiten bei
Anwendung agiler Methoden, konkret am Beispiel Scrum, eher vernachlässigt oder versteckt werden.
Mit Abschnitt 3.3 wurde abgeleitet, dass agile Vorgehensmethoden gut geeignet sind, Lean Prinzipien
und ihre Ausprägungen im Zusammenhang mit Architektur zu unterstützen. Hier besteht insofern ein
Widerspruch dass Eignung für Lean Prinzipien nicht automatisch zu deren tatsächlicher Verwendung
führt. Was augenscheinlich fehlt, sind Methoden, die den konkreten Lean Prinzipien Anwendung
verschaffen.
In den folgenden Abschnitten werden mehrere Ansätze beschrieben, die die Einhaltung der Lean
Prinzipien bei der Erstellung und Pflege von Softwarearchitektur unterstützen oder darüber hinaus
wichtige Denkanstöße liefern können. Zu jedem der Ansätze werden der oder die
korrespondierenden Lean Prinzipien genannt.
4.1 Angemessenheit der Geschäftsprozesse
Ein häufig beobachtetes Muster bei der Implementierung eines Systems ist das fehlende
Hinterfragen der Angemessenheit der zu implementierenden Features. Wenn die Klärung z.B.
folgender Punkte nicht stattfindet, besteht eine hohe Wahrscheinlichkeit, dass die Features des
Systems dem in Abbildung 2 dargestellten Schema entsprechen.
Sind die Prozesse optimal geschnitten?
Befasst sich das System mit mehr als einer Aufgabenstellung?
Enthalten die Prozesse überflüssige Features oder fehlen Features?
Ist das System klar von seiner Umwelt abgegrenzt?
Lean Architecture 2012
21
Abbildung 2: Wie häufig werden Features eines Systems durchschnittlich genutzt [Standish Group 1994]
Die Erhebung aus dem Jahr 1994 in Abbildung 2 mag veraltet erscheinen, die enthaltenen Zahlen sind
aus eigener Erfahrung aktuell. Im Kontext Lean Architecture erscheint folgende Interpretation
angebracht.
64 Prozent der Features einer Software sind unwichtig, da sie nicht oder nur selten genutzt
werden; von einer Realisierung muss aus Kostengründen abgesehen werden
20 Prozent der Features sind wichtig; diese Features müssen umgesetzt werden
16 Prozent der Features werden manchmal genutzt; die Realisierung muss für jedes der
betroffenen Features genau abgewogen werden
Im Ergebnis werden durchschnittlich zwischen 20 und 36 Prozent der Features eines Systems wirklich
benötigt. Nur diese Features sind wichtig, über die Realisierung der restlichen 64 bis 80 Prozent der
Features darf gar nicht erst nachgedacht werden. Die Komplexität des Systems reduziert sich auf
etwa ein Drittel der Gesamtmenge der Features, was jedoch nicht mit einem Drittel des
angenommenen Umfangs verwechselt werden darf. Diese verringerte Komplexität beeinflusst
hoffentlich die Architektur des betroffenen Systems, da sie mit dem Wissen um die wichtigen
Features ebenfalls weniger komplex ausfällt.
Leider lässt sich der Schnitt zwischen wichtigen und unwichtigen Features im Vorfeld zur
Implementierung eines Systems nur selten zuverlässig ermitteln. Es gibt mindestens zwei denkbare
Vorgehensweisen
inkrementelles Vorgehen, bei dem nach jedem Inkrement erneut abgewogen wird, ob und
welche weiteren wichtigen Features im System noch fehlen (siehe Abschnitt 4.3)
45
19
16
13
7
Niemals
Selten
Manchmal
Oft
Immer
Lean Architecture 2012
22
irrtümlich als wichtig betrachtete Features werden wieder aus dem System entfernt und
damit Abhängigkeiten im System verringert (siehe Abschnitt 4.2)
Der in diesem Abschnitt beschriebene Abstraktionslevel „System und seine Features“ ist nur ein
Beispiel für das hier beschriebene Prinzip. Die Regel kann analog auf die Funktionalität einer
einzelnen Komponente oder die Gesamtheit der Systeme einer Organisation angewendet werden.
Eine Komponente neigt zu Funktionalität, die künftig „ganz sicher gebraucht wird“, letztlich aber nie
verwendet und irgendwann zurückgebaut wird. Auf der Ebene der Systeme einer Organisation
wiederum tauchen zwischen den Systemen sich häufig überschneidende Funktionsumfänge auf.
Die Prüfung der Angemessenheit einer Lösung / eines Systems unterstützt implizit die Lean Prinzipien
Kontinuierliche Verbesserung, Entscheidungen mit langfristigem Fokus treffen und
Wertflussoptimierung an.
4.2 Refactoring
Unter Refactoring oder auch Refaktorisierung wird ein Prozess zur Anpassung der inneren Struktur
bzw. des inneren Verhaltens einer Software verstanden, während das äußere Verhalten der Software
unverändert bleibt. Die interne Anpassung der Software erfolgt zur Verbesserung ihres Designs
(siehe [FOWLER05, S. XVIII]).
Ändern sich Anforderungen oder kommen neue Anforderungen hinzu, muss bestehender Code
häufig angepasst werden, damit das System diesen neuen oder geänderten Anforderungen gerecht
werden kann. Wird dabei ausschließlich Wert auf die Realisierung der Anforderungen gelegt, leidet
die Qualität des Codes. Die Wartbarkeit der Software verschlechtert sich. Änderungen können im
Lauf der Zeit nur mit immer größeren Aufwänden vorgenommen werden. Die Entwickler hinterlassen
im System technische Schulden.
Spätestens jetzt sind Refactorings zwingend erforderlich, um die Software wieder in einen wartbaren
Zustand zu überführen. Das äußere Verhalten der Software wird mit Hilfe automatischer Tests
festgestellt und nach der Anpassung mit Hilfe derselben Tests verifiziert. Verfügt die Software über
keine automatischen Tests, ist ein Refactoring praktisch nicht möglich, da nicht sichergestellt werden
kann, dass das äußere Verhalten der Software nach dem Refactoring unverändert geblieben ist.
Verbesserung des Designs einer Software meint im Kontext Refactoring auch eine Verbesserung der
Architektur. Weiterführende Informationen zum Refactoring auf Code- und Designebene können
beispielsweise [FOWLER05] entnommen werden.
Refactoring auf die Code- und Designebene zu beschränken, greift aus meiner Sicht zu kurz. Die
Konsolidierung der Anwendungslandschaft einer Organisation oder die Aktualisierung eines
Standards kann ich durchaus als Refactoring interpretieren. Auf dieser Abstraktionsebene sind
allerdings automatische Tests schwer erzeugbar. Die Beibehaltung des äußeren Verhaltens muss
durch ein anderes Konstrukt überprüft werden können.
In Abschnitt 4.1 wurde beschrieben, dass durchschnittlich 64 bis 80 Prozent der Features einer
Software nicht oder nur selten verwendet werden. Wenn ein System mit 100 Prozent der Features
entwickelt wurde, weil alle Features aus Kundensicht hohe Priorität hatten, lohnt sich die Erhebung
der Häufigkeitsklassen im Nachhinein immer noch. Wenn wir es schaffen, dem Kunden die Erkenntnis
Lean Architecture 2012
23
der nicht verwendeten Features zu vermitteln, können diese Features im Rahmen eines Refactoring
entfernt und die Flexibilität der Software für künftige Änderungen erhöht bzw. wieder hergestellt
werden.
Refactoring zielt implizit auf die Lean Prinzipien Kontinuierliche Verbesserung, Probleme zuerst lösen,
Selbst kümmern und Wertflussoptimierung ab.
4.3 Evolutionäres Design
Evolutionäres Design zeichnet sich durch einen regelmäßigen Abgleich zwischen Problem- und
Lösungsdomäne aus. Unter Problemdomäne kann im Kontext mit Architektur der Verbund aus
Anforderungen und Rahmenbedingungen verstanden werden; die Lösungsdomäne umfasst alle
Aktivitäten, die mit der Erfüllung dieser Anforderungen verbunden sind.
Zur Verdeutlichung des Abgleichs zwischen Problem- und Lösungsdomäne zeigt Abbildung 3 das
Koevolutionsmodell des Designs nach Maher, Poon und Boulanger. Nach diesem Modell kommt es
während des Designs nicht darauf an, ein Problem vollständig zu beschreiben und anschließend eine
Lösung für dieses Problem zu suchen, sondern vielmehr darum, Problem und Lösung kontinuierlich
zu entwickeln und so dafür zu sorgen, dass sich Problem- und Lösungsraum mit fortschreitender
Entwicklung immer mehr annähern [BROOKS11, S. 79f].
Abbildung 3: Koevolutionsmodell des Designs nach Maher, Poon und Boulanger von 1996 [BROOKS11, S. 79]
Bei evolutionärem Design wird grundsätzlich zwischen drei Ansätzen unterschieden.
Divide, Conquer and Integrate (DCI)
Inkrementelles Design
Rapid Prototyping
In den folgenden Abschnitten werden diese drei Ansätze beschrieben. Der Kontext zu den Lean
Prinzipien wird für jeden der Ansätze hergestellt.
Lean Architecture 2012
24
4.3.1 Divide, Conquer and Integrate
Im Rahmen der Methode Divide, Conquer and Integrate (DCI) werden Anforderungen in
überschaubare Portionen aufgeteilt, verfeinert und implementiert. Nach der Implementierung
werden die umgesetzten Teilanforderungen miteinander integriert und in die eventuell bereits
produktive Anwendung eingebaut. Der Kunde kann zu jedem Zeitpunkt neue Anforderungen stellen.
Sie werden nach Priorität umgesetzt und integriert [siehe LUI08].
Die Aufteilung der Anforderungen kann neben der Orientierung an der Größe (Arbeitsaufwand) so
durchgeführt werden, dass resultierende Aufgaben parallel durch mehrere Entwickler/Architekten
durchgeführt werden können. Divide & Conquer Strategien kommen ursprünglich aus der Welt der
Parallelrechner und sind beispielsweise in [NIEUWPOO00] beschrieben.
Auf den ersten Blick scheint Scrum diesen Ansatz zu vertreten. Im Rahmen von einem Sprint auf den
nächsten kann sich ein Kunde entscheiden, welche Anforderungen er im nächsten Sprint umgesetzt
sehen will. Die Anforderungen werden, wenn der Aufwand in den Sprint passt, in handhabbare
Pakete unterteilt, umgesetzt und anschließend miteinander integriert – DCI.
Die Aufteilung eines Problems in Teilprobleme und deren parallele Bearbeitung ist beim
Architekturentwurf nicht in jedem Fall möglich, aber durchaus üblich und erstrebenswert.
Im DCI-Ansatz kommen die Lean Prinzipien Gleichmäßige Aufgabenverteilung, Pull statt Push,
Wertflussoptimierung und Probleme zuerst lösen zur Anwendung.
4.3.2 Inkrementelles Design
Inkrementelles Design kommt in seiner Reinform aus dem Extreme Programming (XP) Umfeld. Ein
zentrales Paradigma in XP lautet, Designentscheidungen im letzten verantwortbaren Moment zu
treffen. Hintergrund ist weniger, dass Vorausplanung beim Design grundsätzlich schlecht ist, sondern
dass zeitnahes Design eine höhere Effizienz aufweist: Designentscheidungen, die weit in der
Vergangenheit liegen, neigen dazu, veraltet und nicht mehr angemessen zu sein.
Die Investition ins Design darf nicht so gering wie möglich gehalten werden, sondern darf sich in
einem gesunden Verhältnis mit dem Gesamtaufwand einer Anpassung oder Neuentwicklung
bewegen.15 Meine Annahme lautet, je intensiver in das Design investiert wurde desto leichter fallen
potentiell künftige Anpassungen und Erweiterungen.
Designänderungen sollen bei inkrementellem Design in kleinen, überschaubaren Schritten
vorgenommen werden, damit für jeden dieser Schritte konkrete Auswirkungen erkannt und bei
Bedarf gegengesteuert werden kann. Im Idealfall kann ein solcher kleiner Schritt im System
umgesetzt und über automatische Tests und kontinuierliche Integration geprüft werden.
Ein recht einfacher, erster Schritt, dass Design eines Systems zu verbessern, ist, Dubletten zu
eliminieren. Logik, die sich nur an einer Stelle im Code befindet, neigt dazu, leicht änderbar zu sein.
Die Alternative, also Duplikate, bedeutet, bei Änderungen oder Ergänzungen, Anpassungen an
mehreren Stellen im Code vorzunehmen.
15
Meine Interpretation von angemessen lautet: etwa Drittel bis die Hälfte des Implementierungsaufwands.
Lean Architecture 2012
25
Der Code trifft hierbei wohl nur die unterste Stufe inkrementellen Designs. Dubletten sind
üblicherweise auch auf Klassen-, Paket-, Bibliotheks- oder Anwendungsebene vorhanden und dürfen
dort gern eliminiert werden.
Designverbesserungen auf Codeebene lassen durch die Eliminierung von Code Smells finden.
Duplizierter Code (siehe weiter oben in diesem Abschnitt) ist ein typischer Code Smell. Weitere
typische Vertreter sind zu große Methoden und Klassen, exzessive Überladung oder parallele
Vererbungshierarchien.
Was Code Smells auf Codeebene sind, sind Anti-Patterns auf Komponenten-, Bibliotheks- oder
Anwendungsebene. Weiterführende Informationen zu Code Smells können [CUNNINGH00] und
[FOWLER05] entnommen werden. Architektur-Anti-Patterns sind gut16 in [BUCKLER08] beschrieben.
Inkrementelles Design wird in [BECK04, S. 51ff] beschrieben.
Inkrementelles Design beinhaltet die Lean Prinzipien Kontinuierliche Verbesserung, Pull statt Push,
Wertflussoptimierung und weitere.
4.3.3 Rapid Prototyping
Rapid Prototyping bzw. Schneller Modellbau gehört in der IT ebenfalls in die Kategorie Iteratives
Design. Beim Rapid Prototyping wird iterativ eine Musterlösung entworfen und implementiert, bis
das Ziel des Prototyps erreicht ist oder als nicht erreichbar erkannt wird. Der Prototyp wird im
Anschluss für das Projekt/Produkt nicht weiterverwendet bzw. weiterentwickelt. Argument gegen die
Weiterentwicklung ist häufig mangelhafte Qualität oder Erweiterbarkeit des Prototyps, so dass eine
Neuentwicklung kostengünstiger erscheint. Ich versuche Rapid Prototyping zu vermeiden.
Natürlich kann argumentiert werden, dass der Erkenntnisgewinn aus dem Prototyp keine
Verschwendung darstellt. Dann muss allerdings auch belegbar sein, dass die Erkenntnis ohne
Prototyp, z.B. nur durch Überlegung, nicht gewonnen werden konnte.
Weiterführende Informationen zu Rapid Prototyping können [MCCONNELL96 S. 433f] entnommen
werden.
Rapid Prototyping unterstützt die Lean Prinzipien Kontinuierliche Verbesserung und
Wertflussoptimierung.
4.4 Tools haben kaum Auswirkung auf Qualität der Architektur
Softwareentwicklung und damit auch der Architekturentwurf spielt sich in einer Welt voller Tools ab.
Hinter Tools stehen häufig kommerzielle Anbieter, die uns als Kunden davon überzeugen wollen,
dass ihr Tool dasjenige ist, dass wir schon immer haben wollten und unsere Anforderungen zu
mindestens 110 Prozent erfüllt.
Im Normalfall stehen mir für ein Problem mindestens zehn Tools zur Verfügung, deren nutzbare
Funktionalität sich mehr oder weniger aufhebt. Etwa die Hälfte der Werkzeuge sind Open Source
oder unterliegen einer vergleichbaren Lizenz. Dabei hat jedes Werkzeug, egal ob Open Source oder
16
und kurz
Lean Architecture 2012
26
kommerziell seine Schwächen und Eigenheiten, die eine sinnvolle Nutzung auf die eine oder andere
Art behindern17.
Daher bleibt dem Architekten aus meiner Sicht wenig anderes übrig, als den eigenen Verstand für die
Lösung von Problemen beim Architekturentwurf zu nutzen. Im Kontext Lean und Lean Architecture
ist das kein schlechter Ansatz, hat Lean doch den Anspruch, Dinge zu hinterfragen und Optimierung
voranzutreiben. Legt man zu viel Wert auf den Einsatz von Tools, besteht die Gefahr, die
Einschränkungen des Werkzeugs als die Grenzen der Anpassungsfähigkeit eines Prozesses, einer Idee
oder einer Methode zu begreifen.
James Coplien18, Autor eines Buches zu Lean Architecture, meint dazu recht treffend:
Lean doesn’t mean less work but more thinking.
Welche Lean Prinzipien unterstützt der Ansatz, seinen eigenen Verstand einzusetzen? Ich denke alle.
4.5 Architektur-Dokumentation
Ein beträchtlicher Teil der Kosten von Softwareentwicklungsprojekten entsteht bei deren
Dokumentation, wobei ich hier unter Dokumentation entwicklungsnahe Dokumentation wie Grob-
oder Feinkonzept verstehe. Dokumentation der Software- bzw. Systemarchitektur wie Big Picture
oder Architekturübersicht, Grobarchitektur- und Detailarchitekturbeschreibung zähle ich ebenfalls
dazu. Je besser Software dokumentiert ist, desto leichter kann sie potentiell von einem neuen
Entwickler oder Architekten verstanden werden.
Ist eine Software mangels Dokumentation hingegen nicht leicht verständlich, steigt der
Kommunikationsaufwand, um die fehlende Dokumentation auf anderem Weg zu erlangen. Entweder
wird die Dokumentation nachgeholt oder der Kommunikationsaufwand entsteht bei der Einarbeitung
jedes neuen Entwicklers oder Architekten erneut. Werden Architekturentscheidungen nicht
festgehalten, besteht das Risiko, dass für gleichartige Probleme jedes Mal erneut abgewogen wird,
welcher Weg eingeschlagen werden soll.
17
Ich suche seit etwa zehn Jahren ein UML-Tool, das seine Artefakte versionieren kann. 18
Siehe [COPLIEN10]
Lean Architecture 2012
27
Dokumentation beinhaltet entwicklungsfremde Kosten. Je mehr Aufwand in entwicklungsfremde
Kosten gesteckt wird, desto geringer wird aus meiner Sicht der erforderliche
Kommunikationsaufwand.
Auf der anderen Seite stellt Dokumentation, die nicht benutzt wird, Verschwendung dar, die nicht
nur im Kontext von Lean vermieden werden muss. Ziel muss es sein, nur Architekturdokumentation
zu erzeugen, für die Bedarf besteht. Es muss für jedes Projekt abgewogen werden, mit welchem
Aufwand Architekturdokumentation betrieben werden muss.
Lean Prinzipien sind hier Wertflussoptimierung, Kontinuierliche Verbesserung und Regeln gemeinsam
definieren.
4.6 YAGNI vs. BFUD
You Ain’t Gonna Need It – Du wirst es nicht brauchen – ist ein relative altes agiles Prinzip, dass
empfiehlt, keine Annahmen über die zukünftige Entwicklung einer Software zu treffen. Wir tun uns
erfahrungsgemäß schwer, Annahmen zu treffen, besonders, wenn diese Annahmen die Zukunft
betreffen. Aussagen wie „Die Anforderung kommt garantiert im nächsten Release, also können wir
sie auch gleich vorsehen.“ habe ich in den vergangenen Jahren zu häufig gehört, um sie noch ernst
nehmen zu können.
Abbildung 4: Kosten der Softwareentwicklung [nach Lui 2008]
Code Benutzermasken
Dokumente Diagramme
Ko
sten
Code Benutzermasken --------------------> Entwicklungskosten
Gesamtkosten
Kommunikations-kosten
Entwicklungsfremde Kosten
Lean Architecture 2012
28
Hinter dem Anti-Pattern Swiss Army Knife verbirgt sich beispielsweise eine Klasse, eine Bibliothek
oder ein System, dass „alles“ kann. Es ist natürlich auch geeignet, ohne Anpassung zukünftige
Anforderungen abzudecken. In der Realität verbirgt sich hinter einer solchen Komponente
hochkomplexer, unwartbarer Code, den ein Architekt, ein Entwickler oder ein ganzes Team in einem
Rausch von kreativer Planung und/oder Entwicklung verursacht hat und für den es nur zwei künftige
Visionen gibt: Refactoring (siehe Abschnitt 4.2) mit hohem Aufwand oder Entsorgung.
Mit viel Fantasie kann ich ein Swiss Army Knife als Big Up-Front Design interpretieren und natürlich
steckt in einem solchen Konstrukt eine Menge Aufwand. Aufwand steckt allerdings auch hinter dem
YAGNI-Ansatz. In dem Moment, in dem ein konkretes, aktuelles Problem bearbeitet wird, entsteht
unter Umständen Mehraufwand, der mit etwas vorausschauender Planung hätte minimiert werden
können (siehe Abbildung 5).
Abbildung 5: Gegenüberstellung von YAGNI und BUFD (siehe [COPLIEN11])
Über einen längeren Zeitraum macht es sich bezahlt, einen Mittelweg zwischen BFUD und YAGNI zu
finden. Aus meiner Sicht ist das ideale Maß aus vorausschauender Planung und kurzfristiger
Entscheidung vom konkreten Problem abhängig und kann nicht pauschal bemessen/benannt
werden.
Die Differenzierung von YAGNI und BFUD entspricht Wertflussoptimierung, Kontinuierliche
Verbesserung, Pull statt Push und Entscheidungen mit langfristigem Fokus treffen.
4.7 Minimale Transaktionskosten
Unter Transaktionskosten wird bei der Erstellung einer Software der Aufwand verstanden, ein
Inkrement oder ein Release der Software zusammenzustellen und zu liefern.
Lean Architecture 2012
29
Ein naheliegender Anspruch sollte sein, diese Transaktionskosten so gering wie möglich zu halten. Die
Lieferungskosten einer Software gehört zu deren Änderung dazu. Wenn eine Software leicht
änderbar sein soll, muss sie auch leicht lieferbar sein.
Nehmen wir an, in einer Software wurde ein kritischer Fehler entdeckt. Die Aufwände für die
Behebung des Fehlers und der Test zur Validierung der Behebung betragen zwei Arbeitstage. Wenn
der Aufwand für die Erstellung des neuen Release und seine Lieferung dagegen 14 Arbeitstage
beträgt, z.B. weil
kein automatischer Build möglich ist
die Software manuell installiert werden muss
kein automatischer Regressionstest möglich ist
der Lieferprozess viele Formalismen und Beteiligte enthält
Hier liegt ein deutliches Missverhältnis zwischen Änderungsaufwand und Transaktionskosten vor. Die
Kosten für den gesamten Prozess sind aus meiner Sicht unvertretbar hoch.
Ziel muss es sein, durch ein automatisiertes Build, die automatische Installation der Software und
durch automatische Regressionstests minimale Transaktionskosten zu erreichen. Für die Erstellung
eines neuen Release halte ich einen Zeitaufwand von zehn Minuten für erstrebenswert. Die
Transaktionskosten fallen bei jeder Lieferung an. Welcher Aufwand erscheint hierfür eher
erstrebenswert: jedes Mal 14 Tage oder jedes Mal zehn Minuten?
So weit so gut. Wo besteht hier der Zusammenhang zu Architektur oder zu Lean Prinzipien? Die
leichte Lieferung einer Software steht aus meiner Sicht in Beziehung zu leichter Änderbarkeit. Der
Build- und Lieferprozess setzt dabei auf Artefakten auf, die direkt oder indirekt aus der vorliegenden
Architektur entstanden sind. Der Architekturentwurf muss bereits berücksichtigen, in welcher Form
eine Software für ihre Nutzung zur Verfügung gestellt werden kann.
Die durch die minimalen Transaktionskosten unterstützten Lean Prinzipien sind
Wertflussoptimierung, Einsatz der richtigen Werkzeuge und gleichmäßige Aufgabenverteilung.
Weiterführende Informationen zu minimalen Transaktionskosten können [ANDERSON11]
entnommen werden.
Lean Architecture 2012
30
5 Fazit – Wie kann Lean Architecture erreicht werden
Plangetriebene Vorgehensmodelle sind nicht de-facto schlecht. Je größer ein Projekt ist bzw. je mehr
Mitarbeiter ein Projekt hat, desto ausgeprägter müssen die Spielregeln im Projekt sein. Wird dies
vernachlässigt, können die Kommunikationskosten im Projekt so weit ansteigen, dass das Projekt
zum Stillstand kommt. Schlecht ist nach meiner Erfahrung die Konsequenz, mit der Regeln
vorgegeben werden. Was mir in plangetriebenen Projekten häufig fehlt, ist eine Prüfung der
Angemessenheit der Projektspielregeln.19
Entgegen der aus Tabelle 4 abgeleiteten weitestgehenden Nichtanwendbarkeit der Lean Prinzipien
auf plangetriebene Methoden halte ich die Lean Prinzipien hier für anwendbar, wenn die Spielregeln
im Projekt angemessen ausgewählt und angewendet werden. Bei der Regelanwendung sollte
Pragmatismus vor Konvention stehen. Als Konsequenz daraus kann sich für die Architektur
ausreichend Freiraum bieten, einer Lean Architecture näher zu kommen, als dies in plangetriebenen
Projekten normalerweise der Fall ist.
Wo plangetriebene Vorgehensmodelle zu viele Regeln aufweisen, neigen agile Vorgehensmodelle
dazu, zu wenig Regeln zu verwenden, um eine angemessene Architektur zu unterstützen. Nach
meiner Erfahrung werden Aktivitäten im Zusammenhang mit Architektur eher vernachlässigt – es
droht ein Architekturchaos. Hier kommt es aus meiner Sicht darauf an, das Regelset agiler Verfahren
um Hilfsmittel zu erweitern, die Architekturentwurf und –pflege unterstützen (siehe Abschnitt 4).
Konsequenz kann eine Architektur sein, die den Lean Prinzipien in ihrer Gänze entspricht. Da Agile
Vorgehensmethoden die Lean Prinzipien nach Tabelle 4 unterstützen, bietet sich die Möglichkeit der
Erweiterung der Methoden, ohne die bereits enthaltenen Regeln zu verletzen.
Meine These, vom Anfang dieses Dokuments muss insofern angepasst werden, dass eine Lösung hin
zu angemessenen Architekturentwürfen unter Berücksichtigung der Lean Prinzipien nur indirekt
zwischen Agilität und plangetriebenen Verfahren liegt. Die Regeln plangetriebener Verfahren müssen
aufgeweicht, die Regeln agiler Verfahren erweitert werden, um zu einem Architekturentwurf zu
kommen, der die Kriterien guter Architektur20 erfüllt. Agile und plangetriebene Verfahren müssen
sich im Kontext Architektur annähern, allerdings ohne den Anspruch zu haben, je aufeinander
abbildbar zu sein (siehe Abbildung 6).
19
Wenn ein Webservice-Projekt ein Quality Gate nicht passieren darf, weil kein GUI-Konzept vorliegt, wurden die Projektspielregeln deutlich zu eng gefasst. Webservices haben laut Standard keine Oberfläche. 20
Siehe Abschnitt 2.1
Lean Architecture 2012
31
Der Ehrgeiz, plangetriebene Vorgehensmodelle generell durch agile zu ersetzen, besteht aus meiner
Sicht ohnehin nicht. Auch in zwanzig Jahren wird hoffentlich niemand auf die Idee kommen, eine
Satelliten- oder Flugzeugsteuerung mit einem agilen Vorgehensmodell umzusetzen, vielleicht aber
mit einem Modell, dass zumindest einige agile Ansätze übernimmt, um mit vertretbaren Kosten
anpassbar zu sein.
Erweiterung zur
Unterstützung der
Lean Prinzipien
Chaos Ordnung
Plan-
getriebene
Vorgehens-
modelle
Agile
Vorgehens-
modelle
Abbildung 6: Erweiterung der Vorgehensmodelle hin zu Lean Prinzipien
Lean Architecture 2012
32
6 Quellen
AARON09 John Aaron: Quality Gates: A PRIMMS Tutorial,
http://milestoneplanning.net/whitepapers/Quality%20Gates%20A%20Tutorial.pdf,
2009
ANDERSON11 David J. Anderson: Kanban – Evolutionäres Change Management für IT-
Organisationen, dpunkt.Verlag, 2011
BECK04 Kent Beck, Cynthia Andres: Extreme Programming Explained, Addison-Wesley, 2004
BELLINGER04 Gene Bellinger: Root Cause Analysis, http://www.systems-
thinking.org/rca/rootca.htm, 2004
BOEHM04 Barry Boehm, Richard Turner: Balancing Agility and Discipline – A Guide for the
perplexed, Addison-Wesley, 2004
BROOKS11 Frederick P. Brooks - Erfolgreiches Design, MITP Heidelberg, 2011
BRUNNER08 Franz J. Brunner: Japanische Erfolgsrezepte: Kaizen, KVP, Lean Production
Management, Total Productive Maintenance, Shopfloor Management, Toyota
Production Management, Hanser Verlag, 2008
BUCKLER08 Christoph Buckler: Software Architecture Anti-Patterns, http://www.cs.uni-
paderborn.de/fileadmin/Informatik/AG-Wehrheim/Lehre/SS08/Seminar/Buckler.pdf,
2008
COCKBURN05 Alistair Cockburn: Crystal Clear – A Human-Powered Methodology for Small Teams,
Addison-Wesley, 2005
COPLIEN10 James Coplien: Lean Architecture for Agile Software Development, Wiley & Sons,
2010
CUNNINGH00 Ward Cunningham: Code Smell, http://c2.com/cgi/wiki?CodeSmell, 2000
FOWLER05 Martin Fowler: Refactoring oder: wie Sie das Design vorhandener Software
verbessern, Addison-Wesley, 2005
GOLDRATT90 Eliahu M. Goldratt: What is this thing called Theory of Constraints and how should it
be implemented, North River Press, 1990
LARMAN09 Craig Larman, Bas Vodde: Scaling Lean & Agile Development – Thinking and
Organizational Tools for Large-Scale-Scrum, Addison-Wesley, 2009
LIKER04 Jeffrey K. Liker: The Toyota way: 14 Management principles from the world largest
manufacturer, McGraw-Hill Professional, 2004
LUI08 Kim Man Lui, C. C. Chan: Software Development Rhythms: Harmonizing Agile
Practices for Synergy; Wiley & Sons, 2008
Lean Architecture 2012
33
MCCONNELL96 Steve McConnell: Rapid Development - Taming wild software schedules, Microsoft
Press, 1996
NIEUWPOO00 Rob V. van Nieuwpoort, Thilo Kielmann, Henri E. Bal: Satin: Efficient Parallel Divide-
and-Conquer in Java, http://www.springerlink.com/content/6nb781jqrkafxc18/, 2000
PALMER02 Stephen R. Palmer, John M. Felsing: A practical guide to Feature-Driven
Development, Prentice Hall, 2002
PICHLER08 Roman Pichler: Scrum – Agiles Projektmanagement erfolgreich einsetzen, d.punkt
Verlag, 2008
POPPENDIEC07 Mary Poppendieck, Tom Poppendieck: Implementing Lean Software Development –
From Concept To Cash, Addison-Wesley, 2007
ROYCE87 Winston W. Royce: Managing the development of large software systems,
http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf, 1987
RUP11 IBM RUP: Rational Unified Process, http://www-
01.ibm.com/software/awdtools/rup/, 2011
SHORE06 James Shore: Quality With a Name, http://jamesshore.com/Articles/Quality-With-a-
Name.html, 2006
SPOLSKI07 Joel Spolski: Smart & Gets Things Done, Springer-Verlag, 2007
VMODEL10 V-Modell XT Autoren und andere: V-Modell XT, http://ftp.tu-
clausthal.de/pub/institute/informatik/v-modell-xt/Releases/1.3/Dokumentation/V-
Modell%20XT%20HTML/index.html, 2006
VOGEL08 Oliver Vogel et al: Software-Architektur: Grundlagen - Konzepte - Praxis, Springer-
Verlag, 2008
Lean Architecture 2012
34
7 Forschung und Lehre leben vom Gedankenaustausch, dabei helfen klare
Vereinbarungen
Die Inhalte dieses Dokuments (u.a. Texte, Grafiken, Fotos, Logos etc.) sowie die Präsentation selbst
sind urheberrechtlich geschützt. Alle Rechte stehen, soweit nicht anders gekennzeichnet,
Capgemini zu.
Capgemini gestattet ausdrücklich die öffentliche Zugänglichmachung kleiner Teile der Präsentation
zu Zwecken der nicht kommerziellen Lehre und Forschung.
Jede darüber hinausgehende Nutzung ist nur mit ausdrücklicher, schriftlicher Einwilligung
von Capgemini zulässig.
Haftungsausschluss
Auch wenn diese Präsentation und die damit zusammenhängenden Ergebnisse nach bestem Wissen
und sorgfältig erstellt wurden, übernimmt weder Capgemini, noch der/die Autoren,
eine Haftung für deren Verwendung.
Bei Fragen wenden Sie sich bitte an:
Ramon Anger
Master of Computer Science
Technischer Architekt
Capgemini Deutschland GmbH
Kürfürstendamm 22
10719 Berlin
0151/4025 1902
ramon.anger [at] capgemini.com
![PROJEKT- UND HAUPTSEMINAR SSE · JAVA-Programmierung, GUI, ... Javascript+Html, ... Einfuehrungsvortrag Seminare WS11.ppt [Kompatibilitätsmodus] Author:](https://img.pdfslide.org/doc/110x75/5ac819977f8b9a51678bee44/projekt-und-hauptseminar-sse-gui-javascripthtml-einfuehrungsvortrag.jpg)
