KONTROVERSE:

AGILITÄT UND ARCHITEKTUR

len, da bereits existierender Code angepasstwerden muss (so genanntes Refactoring,vgl. [Fow99]), damit das neue Inkrementsauber integriert werden kann. Bei inkre-menteller Entwicklung muss existierenderCode daher immer wieder umgebaut wer-den (siehe Abb. 2). Damit nun derAufwand für diese Änderungen nicht denNutzen eines Inkrements übersteigt, mussder zu Grunde liegende Entwurf entspre-chend flexibel sein. Die Aufgabe eines

Über das Verhältnis zwischen agilem Vorgehen und Architektur gibt es hitzigeDiskussionen. Auf die Frage, wie man sicherstellen kann, dass auch bei fortgesetz-ten Änderungen der Aufwand für neue Funktionen nicht übermäßig steigt, gibt esoffensichtlich mehrere Antworten. Doch trotz aller Unterschiede in den Lösungs-ansätzen gibt es auch eine gemeinsame Basis, die wir hier vorstellen möchten.Der Artikel führt in die grundsätzliche Problematik ein – ergänzt wird er durch zweiweitere Artikel, in denen unterschiedliche Thesen vertreten werden, um in agilenProjekten mit dem Thema „Architektur” umzugehen.

m e h r z u m t h e m a :www.agilearchitect.orgwww.agilemodeling.com/

26 27

Inkrementelle unditerative EntwicklungBei einem agilen Vorgehen wird dieEntwicklung in kurzen Einheiten mit festerLänge – den so genannten Iterationen oderSprints – organisiert. Eine Iteration dauertimmer nur wenige Wochen; als Standard-länge hat sich ein Zeitraum von zweiWochen etabliert. Iterationen sind ge-schützt – das bedeutet, dass sich derIterationsinhalt während der Iterationnicht ändert. Beim Übergang von einerIteration zur nächsten können aber sehrwohl andere Features eingeplant werden,als ursprünglich vorgesehen. Die Itera-tionsübergänge sind also genau die Stellen,an denen agile Projekte auf geänderte oderneue Anforderungen reagieren.

Gleichzeitig sollen während des Sprintsvollständige Features entwickelt werden,sodass bei einer passenden fachlichenZusammenstellung der Features nach jederIteration das System an die Endanwendergeliefert werden kann (PotentiallyShippable Code). Für eine typischeGeschäftsanwendung bedeutet das, dassfür die entwickelten Features die Ober-fläche, die Fachlogik und das Backendinklusive der Datenhaltung implementiertwerden müssen.

Das System wird also nicht klassisch inSchichten von unten nach oben entwickelt,sondern vertikal in einzelnen Features, qua-si von links nach rechts.

Bei genauerer Betrachtung stellt manfest, dass die Darstellung in Abbildung 1die Situation vereinfacht darstellt. In derRealität lassen sich die einzelnen Inkre-mente nicht so einfach nebeneinander stel-

Refactoring alsFolge agilen VorgehensIn wohl jedem Projekt – insbesondere injedem erfolgreichen – wird ein einmalerstellter Code dann doch wieder geändert.Bei agilen Projekten werden diese Ände-rungen nicht nur in Kauf genommen, son-dern sind Bestandteil des Prozesses. Geradedieser explizite Umgang mit Änderungenist eine der Stärken agiler Vorgehensweisen,da dadurch die Möglichkeit besteht, imund am Projekt zu lernen. So kann sich dasProjekt auch in sehr komplexen Umge-bungen flexibel an die jeweiligen Bedingun-gen anpassen. Dennoch ist auch ein agilesVorgehen kein „Silver Bullet”. Das Ein-halten des Prozesses allein garantiert nochkein gutes Projektergebnis.

Bei agilen Projekten steht die Imple-mentierung im Vordergrund und besitzteinen höheren Stellenwert als die Doku-mentation. Statt ausufernde Dokumente zuerstellen, die dann doch nicht gelesen wer-den, kann frühzeitig mit der Umsetzungkonkreter Funktionen begonnen werden.Die Priorisierung der Anforderungen undderen iterative Umsetzung verhindertdabei, dass unnötige Funktionen imple-mentiert werden und das System belasten.Anstatt also am Anfang möglichst weit indie Zukunft zu planen und damit Änderun-gen zu vermeiden, setzt agiles Vorgehen aufdie inkrementelle Erweiterung einer funk-tionierenden Software. Dadurch ist dannnatürlich ein ständiges Refactoring derCodebasis notwendig. Wie aber kann manin diesem dynamischen Umfeld sicherstel-len, dass der Code sauber bleibt und sichauch morgen noch einfach ändern lässt?

schwerpunk t

Thomas Lieder

(E-Mail: thomas.lieder@setzwein.com)

ist Senior Project Manager bei der setzwein

IT-Management GmbH. Er ist Leiter agiler

Projekte und technischer Projektleiter mit

langjähriger Erfahrung in der Konzeption und

Implementierung von IT-Systemen.

Martin Lippert

(E-Mail: martin.lippert@it-agile.de)

ist Senior IT-Berater bei der it-agile GmbH in

Hamburg. Er ist langjähriger Coach für agile

Softwareentwicklung und hilft Teams und

Organisationen, agile Methoden einzusetzen

und anzupassen.

Stefan Roock

(E-Mail: stefan.roock@it-agile.de)

ist Senior IT-Berater bei der it-agile GmbH in

Hamburg. Er verfügt über mehrjährige

Erfahrung aus agilen Softwareprojekten

(Scrum. XP, FDD) als Coach, Scrum-

Master/Facilitator, Scrum-Trainer und

Entwickler.

d i e au toren

4 / 2 0 0 9

inkrementellen Entwurfs besteht damitganz wesentlich darin, dafür zu sorgen,dass solche Umbaumaßnahmen stets mitniedrigem Aufwand möglich sind. So kön-nen zukünftige Iterationen mit der gleichenGeschwindigkeit und zukünftige Anfor-derungen zu den gleichen Kosten wie in deraktuellen Iteration entwickelt werden. Wirsprechen dann von einer flachen Auf-wandskurve (siehe Abb. 3).

steigen die Kosten für neue Features überdie Zeit gar nicht oder nur langsam an. InProjekten mit klassischen Vorgehensweisen(wahlweise überhaupt kein strukturiertesVorgehen oder Wasserfall) findet man häu-fig steile Aufwandskurven: Irgendwannspät im Projektverlauf stellt sich heraus,dass man in der Planung ein wichtigesFeature übersehen hat. In der Folge sind dieRealisierungskosten für dieses Feature vielhöher als die der bereits implementierten.

Flache Aufwandskurven werden gerneals ein zentraler Vorteil agiler Vorgehens-weisen dargestellt: Man muss nicht alleAnforderungen über Jahre hinweg imVoraus kennen, sondern kann schnell undflexibel auf Veränderungen reagieren, ohnedie Kosten explosionsartig nach oben zutreiben. Leider lässt sich eine flacheAufwandskurve nicht allein durch ein agi-

les Projektmanagement (z. B. mit Scrum,vgl. [Pic08]) erreichen. Agile Projekte kön-nen sogar – naiv durchgeführt – nochschneller steile Aufwandskurven produzie-ren als bei klassischen Vorgehensweisen.Werden beispielsweise nötige Refactoringsaufgeschoben oder gar nicht durchgeführt,verrottet das innere Design der Softwareund zukünftige Erweiterungen können nurmit Mühe realisiert werden. Natürlich wer-den sie trotzdem in die Software integriert –und zwar irgendwie –, was wiederum dazuführt, dass das innere Design noch schlech-ter wird und sich neue Anforderungen nochschwieriger integrieren lassen. Ein Teufels-kreis beginnt.

Dieser Teufelskreis führt zum Verklum-pen des Systems: Mit der Zeit werdenimmer mehr Teile zum System hinzugefügtund existierender Code wird geändert.Dabei verlieren die Entwickler schnell denÜberblick, welche Klasse konkret von wel-cher anderen abhängt. In der Konsequenzwerden gerade benötigte Klassen einfachimportiert – die Lieblingstastenkombina-tion eines jeden Eclipse-Nutzers lautet„Strg+Shift+O”, um die fehlenden Importsautomatisch zu generieren. So entstehensehr schnell unkontrollierte und gerne aucheinmal zyklische Abhängigkeiten zwischenden Klassen und das System wird zu einemeinzigen großen Klumpen (Big Ball of Mud,vgl. [Foo97]).

Explorationsphasen undProduktvisionenGlücklicherweise hat sich inzwischen dieErkenntnis durchgesetzt, dass richtige agile

schwerpunk tschwerpunk t

Abb. 1: Klassisches und inkrementelles Vorgehen.

Abb. 2: Agiles Vorgehen.

Flache AufwandskurvenIn einem Softwareprojekt kann man lang-fristig nur dann inkrementell arbeiten,wenn es gelingt, eine flache Aufwands-kurve zu halten. Steigt der Aufwand fürÄnderungen jedoch stark an – liegt alsoeine steile Aufwandskurve vor – werdenÄnderungen und Erweiterungen unwirt-schaftlich. Das Projekt kann dann nichtmehr sinnvoll weitergeführt werden. Beieiner flachen Aufwandskurve hingegen Abb. 3: Steile und flache Aufwandskurve.

28 29

schwerpunk t

Quasar steht für Qualitätsorientierte Software-Architektur und kommt aus dem Umfeld der Firma Capgemini sd&m. Quasar ist sowohl ein kom-ponentenorientierter Architekturstil als auch ein konkretes Komponenten-Framework. In diesem Artikel interessiert uns nur der Architekturstil.Quasar ordnet Komponenten zunächst in die folgenden Komponentenkategorien ein:

■ 0: grundlegend ■ A: anwendungsfachlich ■ T: technisch

In der Kategorie 0 finden sich diejenigen Komponenten, die uneingeschränkt überall im System benutzt werden dürfen – die Komponenten derKategorie 0 bilden also die universelle Infrastruktur des Systems. Die Kategorie T enthält alle technischen Komponenten (z. B. „Hibernate”), dienur eingeschränkt verwendet werden sollen und damit nicht in Kategorie 0 fallen. Die Kategorie A umfasst die anwendungsfachlichenKomponenten.Interessant sind die sehr rigiden Regeln, die die erlaubten Abhängigkeiten definieren. T-Komponenten dürfen von 0-Komponenten und von T-Komponenten abhängen, aber nicht von A-Komponenten. Genauso dürfen A-Komponenten von 0-Komponenten und von A-Komponenten abhän-gen, aber nicht von T-Komponenten. Genauso verboten sind Komponenten, die A und T mischen (so genannte AT-Komponenten). Diese Regelnkann man sich gut mit Hilfe der Blutgruppen-Eselsbrücke merken: Die beiden Blutgruppen A und B darf man nicht miteinander mischen. DieBlutgruppe 0 hingegen kann man sowohl mit A wie auch mit B mischen.Offensichtlich kann man mit diesen Regeln kein sinnvolles System bauen. Irgendwann müssen A- und T-Komponenten miteinander kombiniertwerden. Wie sollte man sonst z. B. jemals einen Auftrag speichern können? Den Ausweg aus diesem Dilemma bietet eine vierteKomponentenkategorie:

■ R: Repräsentation

R-Komponenten dürfen von 0-, A-, T- und anderen R-Komponenten abhängen. Es ist jedochdarauf zu achten, dass R-Komponenten wirklich nur den Glue-Code zum Kombinieren der ande-ren Komponenten enthalten und nicht als Feigenblätter verwendet werden, hinter denen sich AT-Komponenten verstecken.Der Kategoriename Repräsentation sollte nicht missverstanden werden. R-Komponenten habennicht nur mit Benutungsoberflächen zu tun, sondern mit jeglicher Repräsentation gegenüber Tech-nologien. Soll z.B. ein Objekt in die Datenbank geschrieben werden, wandelt eine R-Komponentedas Objekt in die Datenbank-Repräsentation um.Die A- und T-Komponenten sollten möglichst viel Code und die R-Komponenten möglichstwenig Code enthalten.Besonders interessant ist die Kategorie 0. Es ist dem Projekt anheim gestellt, die Kategorie 0 selbst sinnvoll zu definieren. Prinzipiell lässt sich diegesamte Technologie eines Projekts in der Kategorie 0 definieren. Dann hat man oberhalb von 0 nur A-Komponenten und braucht weder T- nochR-Komponenten. Das macht den Architekturentwurf sehr einfach, birgt aber erhebliche Nachteile. Schließlich bedeutet Kategorie 0, dass die 0-Komponenten überall im System verwendet werden dürfen. Man muss also damit rechnen, dass die A- und T-Komponenten die 0-Komponentenvielfältig nutzen und sich selbst eng an die 0-Komponenten binden. Das bedeutet zusammengefasst:

■ Klassen aus A- und T-Komponenten lassen sich nicht ohne 0-Komponenten testen. Enthalten die 0-Komponenten Techno-logien, werden alle Tests zu Integrationstests, die häufig umGrößenordnungen langsamer laufen als Unit-Tests.

■ A-, T- und R-Komponenten lassen sich ohne die 0-Kompo-nenten nicht in einem anderen Kontext wiederverwenden. Mankann A- und T-Komponenten also nur dann in anderenProjekten wiederverwenden, wenn die Kategorie 0 des neuenProjekts mindestens die 0-Komponenten des alten Projekts ent-hält.

■ Relevante Änderungen an der Kategorie 0 lassen sich nichtökonomisch durchführen. Möchte man z. B. eine 0-Komponente austauschen oder durch eine neue Version mitgeänderter Schnittstelle ersetzen, muss man damit rechnen, alledarauf aufbauenden A-, T- und R-Komponenten neu program-mieren zu müssen.

■ Die Definition der Kategorie 0 bedeutet also auch: Wir sinduns sehr sicher, dass sich die dort definierten Technologienwährend der Projektlaufzeit nicht ändern werden.Nennenswerte Änderungen könnten schließlich dazu führen,dass das ganze System angepasst oder im schlimmsten Fall neugeschrieben werden muss. Nebenstehende Abbildung zeigteinen Auszug aus einem beispielhaften Quasar-Komponenten-modell (transitive Beziehungen sind nicht dargestellt).

Kasten 1: Der Quasar-Architekturstil im Überblick.

4 / 2 0 0 9

Projekte nicht unvorbereitet mit der erstenIterationsplanung beginnen. Stattdessenmuss es eine Vision vom zu erstellendenSystem geben: die Produktvision (vgl.[Pic08]). Diese adressiert neben fachlichenAspekten („Für wen ist das System?”,„Was leistet es prinzipiell?”, „Wie grenzt essich von anderen Systemen ab?”) auch dieessenziellen technischen Themen. Diese bil-den die Architekturvision, in der beschrie-ben ist, um was für eine Art von System essich auf technischer Ebene handelt:

■ Ist es ein Hochsicherheitssystem?■ Ist es eine hoch skalierbare Web-An-

wendung, die geclustert betrieben wer-den muss?

■ Ist es eine Fat-Client-Lösung für einenEinzelarbeitsplatz?

Im Gegensatz zu klassischer Vorgehens-weisen sollen Produkt- und Architektur-vision leichtgewichtig sein. Bei derProduktvision wird das dadurch erreicht,dass nur grobe Themen beschrieben wer-den, aber nicht die konkreten Anfor-derungen im Detail. Die Architekturvisionwird dadurch leichtgewichtig, dass nur dieThemen adressiert werden, die später imProjekt nur mit sehr hohem Aufwand geän-dert werden können. Das sind vor allem –aber nicht nur – Fragen der System-architektur, d. h. der Kombination vonSoftware und Hardware, wie etwa:

■ Gibt es Verteilungsschnitte im System?■ Wo verlaufen diese?■ Muss das System geclustert betrieben

werden können?

Produkt- und Architekturvisionen werdenvor der ersten Projekt-Iterationsplanungerstellt – in der Explorations- oderVisionierungsphase (vgl. [Wol05] und[Pic08]). Diese wird in der Regel mit weni-ger Personen durchgeführt als das anschlie-ßende Projekt. Aber natürlich werden auchhier die agilen Managementtechniken mitsehr kurzen Iterationen von meist einerWoche eingesetzt.

Was offen bleibtAuch mit Produkt- und Architekturvisionbleibt die Aufgabe bestehen, innerhalb desProjekts die dort nicht adressiertenBereiche der Architektur auszufüllen. Diekonkreten Entwurfseinheiten des Systems –

bei der objektorientierten Programmierungsind dies Komponenten und Klassen – müs-sen definiert, zueinander in Beziehunggesetzt und implementiert werden. Alsleicht änderbar eingestufte Aspekte derSystemarchitektur werden ebenfalls erstwährend des Projekts festgelegt – dazugehört häufig die konkrete Verteilung desSystems auf Hardware sowie die Wahlbenötigter Bibliotheken (z. B. für XML-Parsing).

Bei einigen Lesern drängt sich nun wahr-scheinlich die Frage auf, ob man dann nichtdoch alle Möglichkeiten voraus denkensollte. So könnte man gleich von Beginn analles richtig machen und hätte bei späterenÄnderungen kaum Zusatzkosten. Tatsäch-lich ist diese Einstellung auch unter Ent-wicklern anzutreffen, die in agilen Pro-jekten arbeiten. Oft beruht diese Sichtweiseauf schlechten Erfahrungen. So hat manbeispielsweise jahrelang an einem Legacy-System gearbeitet, das mit jeder Änderungwiderspenstiger wurde. Solch eine Situa-tion will man verständlicherweise keinzweites Mal erleben.

Allerdings hilft langfristiges Voraus-denken hier wenig. Auch dem widerspens-tigen Legacy-System lag möglicherweise einumfangreiches Vorausdenken zu Grunde,doch die Erfahrung zeigt, dass die Zukunftsich eben nicht vollständig vorhersagenlässt. Je weiter man in die Zukunft plant,desto unsicherer wird diese Planung. Undein Projekt über mehrere Jahr im Voraus zuplanen, ist schlichtweg nicht sinnvoll. Umes mit anderen Worten zu sagen: „Thingsare hard to predict, especially if they con-cern the future.”

Und so verfallen die meisten Projekte, diesehr viel Wert auf Vorausschau legen, häu-fig in Paralyse. Vor lauter Vorausschauenund Bedenken wird gar nichts mehr ent-wickelt oder das, was entwickelt wird,resultiert in so komplizierte Basis-Frame-works, dass nie mit der Entwicklung fach-licher Funktionen begonnen wird.

FazitDer Ansatz der allumfassenden Voraus-schau ist kein vernünftiges Modell für eineerfolgreiche Systementwicklung. Vielmehrbenötigen wir Techniken, um im Projektunser Unwissen schrittweise durch Wissenzu ersetzen und gleichzeitig eine flacheAufwandskurve zu erzielen. In den folgen-den beiden Artikeln werden zwei unter-

schiedliche – und teilweise konträre –Thesen vertreten, wie mit der schrittweisenArchitekturentwicklung umgegangen wer-den kann.

Thomas Lieder setzt auf einen prozessu-alen Lösungsansatz. Architektur wirddabei expliziert und größere Umbaumaß-nahmen werden dadurch zum Bestandteildes Produkt-Backlog, die mit demProduktverantwortlichen diskutiert wer-den.

Martin Lippert und Stefan Roock vertre-ten dagegen die Auffassung, dass keineErgänzung agiler Prozesse notwendig ist.Stattdessen sollte das System so strukturiertsein, dass Änderungen auch langfristigkostengünstig durchführbar sind. Sie setzendafür auf Entwicklungstechniken wie test-getriebene Entwicklung (vgl. [Wes05]) undentkoppelnde Architekturstile wie „Qua-sar” (vgl. [Sie04] und siehe Kasten 1). ■

schwerpunk t

Literatur

[Foo97] B. Foote, J. Yoder, Big Ball of Mud, in:

Proc. of 4th Conf. on Patterns Languages of

Programs (PLoP '97/EuroPLoP '97), Monti-

cello, 1997

[Fow99] M. Fowler, Refactoring: Improving

the Design of Existing Code, Addison-Wesley

Longman, 1999

[Pic08] R. Pichler, Agiles Projektmanagement

mit Scrum, dpunkt.verlag, 2008

[Sie04] J. Siedersleben, Moderne Software-

architektur: umsichtig planen, robust bauen

mit Quasar, dpunkt.verlag, 2004

[Wes05] F. Westphal, Testgetriebene Entwick-

lung mit JUnit & FIT: Wie Software änderbar

bleibt, dpunkt.verlag, 2005

[Wol05] H. Wolf, S. Roock, M. Lippert,

eXtreme Programming: Eine Einführung mit

Empfehlungen und Erfahrungen aus der Praxis

(2. Auflage), dpunkt.verlag, 2005