ARCHITEKTUR IN AGILEN TEAMS:

WAS SOFTWAREARCHITEKTEN

VON JAZZMUSIKERN

LERNEN KÖNNEN

Wie kann ich jedoch die Rolle des Soft -warearchitekten in meinem Team sinnvollverankern? Dabei werden sich die folgen-den Aus führungen auf die Umsetzung inkleinen Projekten mit einem agilen Teamkonzentrieren, um die grundlegenden Ideenzu vermitteln. Für große Projekte gibt esMög lichkeiten, die agilen Ansätze zu ska-lieren (vgl. [Eck11]) und die beschriebenenIdeen einzubinden.

Starten wir nun mit einer Situation, inder die Architektur außerhalb des Teamsentsteht. Wir schauen uns dazu eineAnalogie zum Komponisten in der Musikan, der ebenfalls außerhalb des Teams derMusiker agiert.

Der klassische KomponistWahrscheinlich waren auch Sie schon ein-mal in einem klassischen Konzert. MeinerErfahrung nach sind klassische Konzerterelativ lang und der Eintritt ist in der Regelrecht teuer. Es sind viele Musiker beteiligtund der Komponist gibt genau vor, wie dieMusiker zu spielen haben. Eine Partitur fürdas Musikstück (siehe Abbildung 2) unter-stützt dabei den Dirigenten. In dieser istexakt festgelegt, wer wann was mit wel-chem Instrument zu spielen hat. Dabei han-delt es sich um ein sehr gut durchgeplantesVor gehen. In der Musik funktioniert dies,weil das Orchester viel Zeit hat, um denAblauf immer und immer wieder zu pro-ben. Die dabei erworbenen Kenntnisse überden Ablauf können dann während desKonzerts zuverlässig und fehlerfrei umge-setzt werden.

Die Scrum-Einführung ist erfolgreich abgeschlossen, die Storys werden nach agilen Methodenin den Sprints umgesetzt, der Product Owner ist zufrieden. Aber was ist mit der Software -architektur? Entsteht diese nach wie vor außerhalb des Teams oder kümmert sich womöglichgar keiner mehr darum? Zwischen diesen beiden Extremen gilt es, einen neuen Weg für dieArchitekturentwicklung zu finden mit dem Ziel, die Übernahme von Architekturverantwortungim Team erfolgreich zu etablieren. Dieser Artikel stellt hierfür einige bewährte Prinzipien undPraktiken vor, wie Softwarearchitektur in agilen Teams entstehen und umgesetzt werden kann.

m e h r z u m t h e m a :http://blog.sybit.de/2013/02/software-architektur-in-agilen-teams/http://blog.sybit.de/2012/08/15-architekten-trainieren-fur-den-zehnkampf/

20 21

vorgenommen. Neue Erkenntnisse und sichändernde Rahmenbedingungen haben wie -derum Einfluss auf die Anforderungen.

Als Resultat dieser Tätigkeiten entstehtdie Struktur eines Softwaresystems mit sei-nen Komponenten und Bausteinen mitSchnittstellen und Beziehungen. Die Soft -ware architektur ist maßgeblich für dieQualität verantwortlich – durch die Erfül -lung der nicht-funktionalen Anforderun -gen. Letztendlich umfasst die Architekturdie Menge der übergreifenden Entwurfs -ent scheidungen mit systemweiten Konse -quen zen und muss sich durch lauffähigeSoftware beweisen. Eine weiterführendeBeschreibung zum Thema Software -architektur findet man in Gernot StarkesBuch „Effektive Software-Architekturen“(vgl. [Sta11]).

Aufgaben einesSoftwarearchitektenBefragt man mehrere Personen, was sieunter dem Begriff „Softwarearchitektur“verstehen, so bekommt man viele verschie-dene Antworten. Der Begriff der Soft -warearchitektur lässt sich nicht einfach ineiner knappen Definition zusammenfassen.Ich möchte den Begriff daher über dasErgebnis der Arbeit des Architekten einfüh-ren. Ein Softwarearchitekt hat ein sehrbreites Spektrum an Aufgaben, die weitüber technische Aspekte hinausreichen.Eine hervorragende Zusammenstellung derAufgaben stammt von Peter Hruschka undGernot Starke (vgl. [Hru09]). Die beidensprechen von den folgenden sechs wichtigs -ten Tätigkeiten:

■ Anforderungen undRandbedin gun gen klären.

■ Strukturen entwerfen.■ Technische Konzepte entwerfen.■ Architektur kommunizieren.■ Umsetzung überwachen.■ Architektur bewerten.

Diese Aufgaben haben eine gewisse Ab -hängigkeit untereinander, werden jedochwährend des Lebenszyklus des Projektsbzw. Produkts immer wieder iterativ durch-laufen (siehe Abbildung 1). So wird manmit den Anforderungen und den erstenStrukturen beginnen. Bei den weiterenSchritten, insbesondere bei der iterativenUmsetzung der Anforderungen, werden dietechnischen Konzepte verfeinert und immerwieder Anpassungen an den Strukturen

schwerpunk t

Roland Mast

(roland.mast@sybit.de)

ist Softwarearchitekt und Scrum Master bei der

Sybit GmbH. Er beschäftigt sich hauptsächlich mit

der Entwicklung von großen Content-Management-

Systemen im Medienumfeld. Als Architekt arbeitet

er in agilen Teams und wirkt aktiv bei der

Entwicklung mit.

der au tor

Abb. 1: Die Aufgaben desSoftwarearchitekten.

5/2013

Der klassische ArchitektÜbertragen auf die Softwarearchitektur,würde das bedeuten, dass der Chef -architekt die Architektur erstellt und dieseumfangreich dokumentiert, z. B. in Formvon UML-Diagrammen, in denen exaktbeschrieben wird, welche Komponenten zuerstellen sind, wie diese miteinander intera-gieren und an welchen Stellen flexibleErwei terungsmöglichkeiten vorzusehensind. Anschließend überwacht er, dass die-se Vorgaben von den Entwicklern exaktumgesetzt werden.

In dieser Konstellation würde die Rolledes Architekten durch einen Generalistenabgedeckt, der neben Architektur-Know-

how über ein breites fachspezifisches undtechnologisches Wissen verfügt. Das Ent -wicklungsteam hingegen besteht ausSpezialisten in ihren jeweiligen Fachge -bieten (z. B. GUI, Datenbanken) und setztdie Vorgaben des Architekten nach Plan um(siehe Abbildung 3). Im Extremfall entferntsich der Architekt jedoch dabei so weit vomTeam, dass er sich in seinen Elfenbeinturmzurückzieht und nicht mehr erreichbar ist.Ich habe es schon erlebt, dass in einemEntwicklungsteam mit ca. 50 Personen derArchitekt von den Entwicklern nicht „ge -stört“ werden durfte, da er Wichtigeres zutun hatte. Andererseits durfte ich vor eini-gen Jahren in einem kleineren Team mitar-beiten, das mit einer Produkt-Neuent -wicklung beauftragt war. Ein erfahrenerArchitekt übernahm allein die Aufgabender Architektur. Das funktionierte in die-sem Fall hervorragend, nicht zuletzt auf-grund seiner sehr guten fachlichenKenntnisse und seiner hohen Sozialkompe -tenz. Als das Team jedoch auf mehr als 10Personen vergrößert wurde, war keine effi-ziente Kommunikation mit allen Beteiligtenmehr möglich und der Architekt wurdezum Flaschenhals.

Um diese Situation zu verbessern, kön-nen wir uns etwas Hilfe aus dem AgilenManifest (vgl. [Bec01]) besorgen. Überträgtman dessen Aussagen auf die Software -architektur, so lassen sich daraus folgendePunkte ableiten:

■ „Individuals and interactions over pro-cesses and tools“: Enge Zusam men -arbeit zwischen Architekt und Ent -wicklern, kein Big Upfront Design.

■ „Working software over comprehensi-ve documentaion“: Nur das Erfor der -liche zum richtigen Zeitpunkt doku-mentieren und frühzeitig Softwarelie fern, Risiken durch Prototypen undProof of Concept minimieren.

■ „Customer collaboration over contractnegotiation“: Zusammenarbeit mit denStakeholdern und den Entwicklern.

■ „Responding to change over followinga plan“: Architektur iterativ entwickelnund offen für Erweiterungen halten.

■ „That is, while there is value in the itemson the right, we value the items on the leftmore.“: Auch bei der Soft warearchitekturkann und darf nicht komplett aufProzesse, Werkzeuge, Doku mentationund Pläne verzichtet werden. Sie solltenjedoch den Prak tiken auf der linken Seiteder Aussagen nicht im Wege stehen, son-dern diese vielmehr unterstützen.

Werfen wir nun noch einen Blick in diedazugehörigen Prinzipien, so finden wir:

■ „The best architectures, requirements,and designs emerge from self-organi-zing teams.“

Diese Aussage beruht auf der Tatsache,dass die besten Entscheidungen diejenigentreffen, die am nächsten an den Gründender Entscheidung und deren Auswirkungenstehen. Entscheidungen, die in der Gruppebasierend auf gemeinsamem Zielen undTaten getroffen werden, sind zudem effi-zienter umzusetzen.

Hierzu gibt es ein interessantes Experi -ment von Manfred Spitzer (vgl. [Spi12],siehe Abbildung 4): Zwei Probanden saßen

schwerpunk t

Abb. 2: Auszug aus der Partitur von „Brandenburgisches Konzert” (Quelle: MuseScore) .

Abb. 3: Der „klassische” Architekt alsGeneralist im Elfenbeinturm.

Abb. 4: Prof. Dr. Dr. Manfred Spitzer(Quelle BR alpha: www.br.de/fernsehen/br-alpha/sendungen/geist-und-gehirn/gehirn-gemeinsam-improvisieren100.html).

Dieses Vorgehen funktioniert nicht mehrmit einem Softwarearchitekten als Einzel -person. Vielmehr muss diese Rolle im Teamverteilt werden. Im Idealfall der selbst-organisierenden Teams übernehmen dieTeammitglieder diese Aufgaben selbststän-dig. Was aber tun, wenn das Team dieseFähigkeiten noch nicht entwickelt hat?Gibt es einen Architekten, der bisher alsEinzelperson diese Aufgabe wahrgenom-men hat, so muss er nach und nach seineAufgaben und Verantwortung abgeben. Einmöglicher Weg ist, dass er im TeamEntwicklungsaufgaben mit übernimmt undsomit das Team als generalistischer Spe -zialist unterstützt (siehe Abbildung 6).Dabei kann er die Entwickler nach undnach an die architektonischen Aufgabenheranführen. Sie werden zu Spezialisten,die offen sind für übergeordnete Themen.

Bei Teams, in denen bislang kein Archi -tekt vorhanden ist, sollte einer der erfahre-nen Entwickler diese überblickende Rolleeinnehmen. Er sollte die Verantwortungübernehmen, das Team für architektoni-sche Aufgaben zu sensibilisieren.

Gute Erfahrungen habe ich gemacht,wenn ich Entwicklern die Ausarbeitung dertechnischen Konzepte überlassen habe.Dabei geht es darum, für übergeordneteThemen – wie Exception Handling, dieTrennung der View von der Business-Logikdurch Model-Klassen oder das Design vonZustandsmaschinen – einen für das Projektallgemeingültigen Ansatz zu entwickeln

22 23

durch weitere wichtige Informationenergänzt werden, z. B. Tempo oder dieBasslinie bei Chameleon. Das Leadsheet istkompakt und meist nicht größer als eineSeite. Es enthält alle wichtigen Informa -tionen und lässt den Musikern dennochgenügend Freiraum, sich zu entfalten.

Auch das Improvisieren im Jazz musserlernt werden. Allerdings bereitet derJazzmusiker nicht Note für Note vor, son-dern entwickelt einen passenden Sound,der beim Auftritt ausgestaltet wird.

Architektur im TeamÜberträgt man diesen Ansatz aus dem Jazzauf die Softwarearchitektur, dann bedeutetdas:

■ Am Anfang entsteht nur eine Vision derArchitektur, die die wichtigsten Rah -menbedingungen vorgibt, die aberwährend der Entwicklung noch genü-gend Spielraum für neue oder sichändernde Anforderungen lässt.

■ Damit wird ein iteratives Vorgehenermöglicht und architektonische Ent -schei dungen können bis zum „LeastResponsible Moment“ hinausgezogenwerden, d. h. sie werden zum spätmög-lichsten Zeitpunkt getroffen und da -nach meist sofort umgesetzt.

■ Detaillierte Strukturen und technischeKonzepte entstehen unterwegs.

■ Die Architektur entsteht gemeinsam, abernicht unbedingt von allen zusammen.

vor einer Box mit zwei Schiebereglern.Aufgabe des Experiments war es, dieRegler möglichst synchron zu bewegen. Eswurden zwei unterschiedliche Szenarienuntersucht:

■ Führen-Folgen: Dabei musste ein Pro -band versuchen, den Bewegungen desanderen so gut wie möglich zu folgen.

■ Gemeinsames Improvisieren: Auch hierwar es die Aufgabe, die Regler mög-lichst synchron zu bewegen. Jedochkonnten die Teilnehmer beliebig dieFührung übernehmen.

Das Ergebnis war, dass die elektronischauf gezeichneten Bewegungen beim „Ge -meinsamen Improvisieren“ besser koordi-niert erfolgten. Es gab weniger Abwei -chungen zwischen den Bewegungen derbeiden Teilnehmer und es wurde eine höhe-re Maximalgeschwindigkeit erreicht. Aller -dings stellte Spitzer auch fest, dass dieseVerbesserung vor allem von Proban denerreicht wurde, die das Improvisieren ineinem anderen Gebiet praktizieren, z. B.Schauspieler oder Musiker.

Für die Softwareentwicklung heißt dies,dass ein Team, das gemeinsam improvisie-rend unterwegs ist, schneller zu besserenLösungen kommt. Das lässt sich auch aufdie Architektur übertragen. Statt einerPerson entwickeln die Teammitgliedergemeinsam die Architektur. Allerdings zeigtdas Experiment auch, dass dieses Vorgehenerlernt werden muss, um davon profitierenzu können.

Wie lässt sich dieses Wissen auf dieArchitekturarbeit in einem Softwareteamübertragen? Auch dazu gibt es ein passen-des Beispiel aus der Musik, diesmal demJazz.

Die Jazzband als TeamJazzmusiker organisieren sich musikalischselbst. Jeder hört auf die anderen und rea-giert auf deren Spiel. Die Musiker beginnenmit der Vision eines Stück und lassen sichvom Moment inspirieren. Die Solistenwechseln sich ab. Es gibt keine zentralePerson, die alles vorgibt.

Im Jazz werden die Musikstücke oft inForm eines Leadsheets1) festgehalten (sieheAbbildung 5). Sie geben die Melodielinieund die Harmonien vor, die manchmal

schwerpunk t

1) „Leadsheet“ ist ein in der Jazz- und Rock-Musikgeläufiger Begriff für eine einfache und knappeNotation eines Musikstückes.

Abb. 5: Leadsheet von Chameleon (Quelle: Realbook).

5/2013

schwerpunk t

und diesen entsprechend zu dokumentie-ren. Mit diesen Aufgaben erfahren die Ent -wickler, dass es auch wichtig ist, über denRand der aktuellen Anforderungsum -setzung hinauszusehen und ein Gefühl fürarchitektonisch relevante Themen zugewinnen.

Klar ist auch, dass die Architektur nichtnebenher in den Teams erledigt werdenkann. Sie benötigt Zeit: nicht nur Zeit, bisdie Teammitglieder ein Gespür für Archi -tekturrelevanz entwickelt haben, sondernauch Zeit, um ihre Ideen zu entwickeln,diese mit den Anforderungen abzustimmenund im erforderlichen Maß zu dokumentie-ren. Ein wesentlicher Bestandteil in diesemProzess sind die Auseinandersetzungen undDiskussionen mit den Kollegen und den

Stakeholdern, gemäß einem von GernotStarke zitierten Bonmot (vgl. [Sta11]):„Wenn Sie glauben, dass Ihre Architekturgut ist, dann haben Sie diese noch nieman-dem gezeigt.“

ArchitekturvisionDamit das Team vernünftig arbeiten kann,muss zumindest der Rahmen für das zu ent-wickelnde System abgesteckt werden – dasgeschieht am besten in Form einerArchitekturvision. Diese zeichnet sichgemäß Stefan Roock und Roman Pichler(vgl. [Roo11]) durch drei Faktoren aus:

■ Verständlichkeit: Die Architekturvisionwird von allen Teammitgliedern ver-standen.

■ Akzeptanz: Das Team steht gemeinsamzu den Inhalten der Vision.

■ Kürze: Die Architekturvision ist eineBeschränkung auf das Wesentliche (wasmeist nicht so einfach ist).

Die Architekturvision enthält Informatio -nen zum Systemkontext und die Abgren -zung zu Fremdsystemen. Die wesentlichenKomponenten der obersten Ebene werdendargestellt. Die priorisierten Qualitätszielezählen die wichtigsten nicht-funktionalenAnforderungen auf, die architekturrelevantsind. Hinzu kommen Randbedingungenorganisatorischer, technischer oder fach-licher Art, die Einfluss auf die Architekturnehmen. Die wichtigsten architektonischenRisiken sollten ebenfalls aufgeführt wer-den.

Die Vision erfordert nicht unbedingt eineformelle Dokumentation: In kleinerenProjekten sind einige Flipcharts ausrei-chend. Der Vorteil dabei ist, dass sie imTeamraum für alle ständig sichtbar aufge-hängt werden können. Gute Erfahrungenhabe ich gemacht, wenn die Team -mitglieder in die Erstellung der Vision miteinbezogen werden. Soll die Architektur imLaufe des Projekts formeller dokumentiertwerden, so bieten sich Dokumentations-Templates wie das „arc-42 Template“ (vgl.[arc42]) an. Die Strukturierung derThemen hilft, nichts Wesentliches zu ver-gessen.

UML-Diagramme sind ebenfalls ein adä-quates Mittel, um verschiedenste Aspekte derArchitektur festzuhalten. Aber auch hier giltdie Regel, „weniger ist mehr“. Es sollte unbe-dingt vermieden werden, zu sehr ins Detailzu gehen. Die Diagramme sollen die grobenZusammenhänge darstellen, um sich einenÜberblick über die Architektur verschaffenzu können. Dazu eignen sich Komponenten-, Verteilungs- und – zu einem gewissen Grad– Klassen-Dia gramme.

Der Vorteil eines Big Pictures ist in derRegel, dass es weniger anfällig bezüglichÄnderungs- und Pflegeaufwand ist. Fallsdann doch etwas angepasst werden muss,so ist es wichtig genug, dass sich derAufwand dafür lohnt. Der große Nachteilvon detaillierten Beschreibungen hingegenist, dass sie schnell von der tatsächlichenImplementierung abweichen und es nur mitgroßem Aufwand möglich ist, sie konsis -tent zu halten.

Abb. 6: Der Softwarearchitekt im agilenTeam.

Abb. 7: Architekturvision, entstanden während einer Architektur-Kata.

24 25

Architektur-KataDa das Erstellen einer Architekturvisionnicht allzu häufig im Projektalltag vor-kommt, ist es hilfreich, diese Fertigkeit zutrainieren. Dazu bieten sich Architektur-Katas an, wie sie von Ted Neward (vgl.[New10]) erstmalig auf der Überconf 2010und später auch auf der Jax 2011 (vgl.[Mas11]) durchgeführt wurden. Angelehntan die Praktiken aus den Kampfsportartenund aus den Code-Katas, sind Architektur-Katas kleine, wiederholbare Übungen, beidenen der Weg das Ziel ist und das Erar -beiten und Visualisieren von Software -architektur erlernt und geübt werden soll.Anhand einer Kurzspezifikation (eine Seite)eines zu erstellendes Softwaresystems wirdein Architekturvision erstellt und festgehal-ten (siehe Abbildung 7). Wichtig ist, dassdabei die Rolle eines Kundenvertreters vor-handen ist, der aufkommende fachlicheFragen beantworten kann.

Notwendig für eine gute Architektur -vision ist auch architektonisches Grund -lagenwissen. Bei der Firma Sybit hat sich2012 eine Gruppe von 15 Entwicklernintensiv mit diesem Thema auseinanderge-setzt und sich vom iSAQB zum „CertifiedSoftware Architect“ prüfen lassen (vgl.[ISAQB]). Zu Beginn und Ende derWeiterbildung führten wir Architektur-Katas durch, anhand derer wir den Erfolgdes Trainings selber erfahren konnten.

Definition von architek -tonischer RelevanzWährend der Sprints steht die Umsetzungder Anforderungen im Vordergrund. Damitdabei die Softwarearchitektur nicht außerAcht gelassen wird, bietet es sich an, eine„Definition von architektonischer Rele -vanz“ aufzustellen. Ähnlich wie bei der„Definition of Done“, in der die Kriterienfestgehalten sind, wann eine Story (An -forderung) komplett umgesetzt ist, werdenhier die Punkte aufgeführt, bei denen dasTeam wachsam sein muss. Diese Punktesind von Projekt zu Projekt und vor allemauch von Team zu Team unterschiedlichund müssen zuallererst gemeinsam aufge-stellt werden. Ziel ist es, eine Checkliste zurVerfügung zu haben, anhand derer festge-stellt werden kann, ob eine Designent -scheidung architekturrelevant ist und mitgrößerem Überblick betrachtet werdenmuss (Kasten 1 zeigt ein Beispiel).

Auch hier gilt: „Der Weg ist das Ziel“.Denn schon allein die geführten Dis -kussionen bei der Erstellung der Checkliste

schaffen ein wertvolles gemeinsames Ver -ständnis über die Softwarearchitektur desSystems.

Flexible Strukturen in derSoftwarearchitekturVon Grady Booch stammt eine der vielenDefinitionen von Softwarearchitektur, diemir persönlich sehr gut gefällt (vgl.[Boo06]: „All architecture is design but notall design is architecture. Architecturerepresents the significant design decisionsthat shape a system, where significant ismeasured by cost of change.“ Damit bringter zum Ausdruck, dass Softwarearchitekturaus der Menge der Designentscheidungenbesteht, deren Änderung hohe Kosten ver-ursachen.

Mit der „Definition von architektoni-scher Relevanz“ hat das Entwicklungsteamein Mittel an der Hand, mit dem es die teu-ren Designentscheidungen erkennen kann.Durch die Architekturvision ist der Rah -men abgesteckt, innerhalb dessen dieEntscheidungen getroffen werden können.Nichtsdestotrotz sind die Spielräume nachwie vor groß genug, um die falsche Rich -tung einschlagen zu können.

Das Team muss es schaffen, ein Soft -wares ystem zu entwerfen, das auf der einenSeite einfach genug ist, um unnötigenAufwand bzw. Komplexität zu vermeiden,und auf der anderen Seite flexibel genug,um spätere Anforderungen aufnehmen zukönnen.

Flexibilität einzubauen, ist eigentlich einerelativ einfache Aufgabe. Es stehen jedeMenge Patterns zur Verfügung, um Punktein der Architektur zu erschaffen, an denen

später Anpassungen und Erweiterungenerfolgen können. Beispiele hierfür sindSchichten-Modelle, Abstraktions-Layer,Strategien, Observer usw. Zusammen mitDependency Injection steht ein mächtigesWerkzeug zur Bewältigung von Abhängig -kei ten zur Verfügung.

Die Schwierigkeit der Flexibilität liegtjedoch darin, diejenigen Stellen zu erken-nen, an denen diese überhaupt benötigtwird. Baut man jede erdenkliche Flexi -bilität ein, so verschwendet man immensenEntwicklungsaufwand für Dinge, die niegenutzt werden. Zusätzlich wird dieArchitektur unnötig kompliziert. AlsGegensatz könnte frei nach dem Motto,„Wir sind agil und bauen immer erst danndie Flexibilität ein, wenn wir sie tatsächlichbenötigen!“, zu Beginn komplett aufFlexibilität verzichtet werden. Hierbei lan-det man jedoch früher oder später in derSackgasse, in der durch Ignoranz die Dingeso stark miteinander verflochten sind, dasskeine einfachen Anpassungen mehr mög-lich sind.

Wie so oft, muss ein guter Kompromisszwischen beiden Extremen gefunden wer-den. Die Anforderungen (funktional undnicht-funktional) sind ein guter Ausgangs -punkt. Damit lässt sich klären, an welchenTeilen bei zukünftigen AnforderungenÄnderungen zu erwarten sind, wo die größ-ten Risiken liegen und welche Schnittstellen(z. B. zu Fremdsystem oder Frameworks)fragil sind. Dies sind alles Hinweise, dieeine gewisse Flexibilität in der Architekturerforderlich machen.

Ziel einer guten Architektur ist es, diepassenden Strukturen und die zugehörigenAbhängigkeiten zu finden. Als erster Schrittbietet es sich an, das System in Teile zu zer-legen, die sich an den unterschiedlichenVerantwortungen ausrichten. Diese könnentechnischer Natur (Separation of Con -cerns), aber vor allem fachlicher Natur(Single Responsibilty Principle) sein (vgl.[Cle]).

Wenn die Strukturen des Systemsgemeinsam von mehreren Teammitgliedernerstellt werden, ergeben sich zwangsläufigDiskussionen. Hin und wieder kommt esdabei auch vor, dass kein gemeinsamerKonsens gefunden werden kann. Das deu-tet oft auf eine Unsicherheit bezüglich zu -künftiger Anforderungen hin. EineMöglichkeit wäre es, diese Unklarheit mitdem Product Owner bzw. dem Anfor -derungsmanagement abzuklären. Falls dasjedoch auch nicht weiterhilft, sollte man

schwerpunk t

Architekturrelevant sind Entscheidun gen,■ die Top-Level Strukturen betreffen,■ die das Qualitätsmerkmal X maßgeb-

lich beeinflussen (z. B. Performance,Sicherheit, Wartbarkeit),

■ die mit mehr als X Euro kostenrele-vant sind,

■ die Auswirkungen auf externeSchnittstellen besitzen,

■ die Auswirkungen auf den System be -trieb haben,

■ die besondere Risiken hinsichtlichder Implementierung oder Test besit-zen.

Kasten 1: Beispiel einer „Definition vonarchitektonischer Relevanz”.

5/2013

schwerpunk t

diesen Teil des Systems so kapseln, dass erspäter einfach ausgetauscht werden kann.Somit ist es möglich, mit einer einfachenLösung zu starten, die im Bedarfsfall aus-getauscht werden kann.

Abhängigkeiten zwischenden StrukturenSobald die Strukturen festgelegt sind, gehtes darum, die Abhängigkeiten zwischenihnen zu finden. Diese sollten so gering wiemöglich sein und auch über deren Richtungmuss man sich Gedanken machen.

Ein mögliches Vorgehen ist das Story-Dot-Voting. Dabei wird die Komponenten -struktur dahingehend überprüft, an wel-chen Stellen Änderungen bei der iterativenUmsetzung der Storys erforderlich werden.Dazu wird für jede Story die betroffeneKomponente mit einem Punkt markiert.Die Pakete mit den meisten Punkten müs-sen näher betrachtet werden. Im nächstenSchritt können diese gegebenenfalls aufge-teilt oder durch geeignete Maßnahmen ent-koppelt werden. Wichtig sind auch dieAbhängigkeiten, die zum einen so geringwie möglich gehalten werden müssen, zumanderen jedoch auch in die richtige Rich -tung weisen müssen. Komponenten, diesich häufig ändern, sollten von stabilerenKomponenten abhängen und nicht umge-kehrt.

Die Änderungshäufigkeit lässt sich nebendem erwähnten Story-Dot-Voting z. B.auch anhand geplanter zukünftiger Erwei -terungen (Epics) und bei bereits produkti-ven Systemen anhand der von Bugs betrof-fenen Komponenten ermitteln.

Abbildung 8 illustriert am Beispiel einesFußball-Tippspiels das Ergebnis einesStory-Dot-Votings. Dabei stellte sich derScore-Kalkulator als die fragilste Stelle desSystems heraus. Demzufolge wurde die Ab -hängigkeit zum Tippspiel hin umgedreht.Erreicht werden kann dies beispielsweisedurch die Bereitstellung einer Schnittstellein der Tippspiel-Komponente, die vomScore-Kalkulator implementiert wird.Damit wird Instabiles abhängig von Sta -bilem.

Software CraftsmanshipDie hier beschriebenen Vorgehensweisensetzen entsprechende handwerkliche Fertig -keiten und agile Praktiken voraus. DasErkennen der architekturrelevanten Punktekann z. B. bereits beim Schätzen der Storysoder in der Sprint-Planung erfolgen. Damitkönnen entsprechende Spikes, Proofs ofConcept oder Tasks sinnvoll geplant wer-den. Zum Handwerkszeug jedes Entwick -lers sollten Kenntnisse über Design-Pattern,Refactoring, automatisierte Tests, Conti -nuous Integration und Clean-Code (vgl.[Cle]) gehören.

ZusammenfassungAuch in agilen Teams muss man sich umdie Softwarearchitektur kümmern. Dieklassischen Ansätze, bei denen die Rolle

des Softwarearchitekten von einer Personwahrgenommen wird, stoßen nicht nur inagilen Teams schnell an ihre Grenzen.Bessere Architekturen entstehen, wenn dieAufgaben und die Verantwortung vomTeam übernommen werden. Dabei unter-stützen – neben einer guten Aus- undWeiterbildung – Hilfsmittel wie eineArchitekturvision, die Definition von archi-tektonischer Relevanz und ein intensivergemeinsamer Sprint-Planungsprozess. Füreinen erfolgreichen Wechsel zu agilerArchitektur sind alle gefragt:

Das Management ist behilflich bei derEvakuierung der Elfenbeintürme undunter stützt die Teambildung mit den Archi -tekten. Die Architekten gehen als Genera -listen mit einer Vision in die Teams undarbeiten eng mit den Spezialisten zusam-men. Die Entwickler übernehmen Mitver -antwortung für die Architektur und erken-nen architekturrelevante Entscheidungen.Sie entwickeln Strukturen, die gerade flexi-bel genug sind, und verlassen sich dabei aufihr Software-Craftsmanship.

Damit gerüstet entstehen leichtgewichti-ge Softwarearchitekturen ohne unnötigenBallast, die von allen Beteiligten getragenwerden und dank der nötigen Flexibilitätauch zukünftigen Anforderungen Standhalten können: eine Arbeit, auf die manauch noch nach Jahren stolz sein kann. ■

Literatur & Links

[arc42] Template für Architekturdokumentation, siehe: www.arc42.de/template/template.html

[Bec01] K. Beck et al., Agiles Manifest, 2001, siehe: www.agilemanifesto.org

[Boo06] Blog von Grady Booch „Software architecture, software engineering, and Renaissance

Jazz“, siehe: https://www.ibm.com/developerworks/mydeveloperworks/blogs/gradybooch/entry/on_design

[Cle] Clean Code Developer, siehe: www.clean-code-developer.de

[Eck11] J. Eckstein, Agile Softwareentwicklung in großen Projekten, dpunkt.verlag 2011

[Hru09] P. Hruschka, G. Starke, Softwarearchitekten: Die Zehnkämpfer der IT, in:

OBJEKTspektrum 04/2009

[ISAQB] International Software Architecture Qualification Board (ISAQB), siehe: www.isaqb.de

[Mas11] R. Mast, Blogeintrag über die Jax 2011 und den Besuch einer Architektur-Kata, 2011,

siehe: http://blog.sybit.de/2011/05/jax-2011-interaktiv

[New10] T. Neward’s Technical Blog, Architectural Kata, 2010, siehe:

blogs.tedneward.com/2010/06/17/Architectural+Katas.aspx

[Roo11] S. Roock, R. Pichler, Die Architekturvision in Scrum: Vorausplanung und emergentes

Design balancieren, in: OBJEKTspektrum 04/2011

[SEI] Software Engineering Institute (SEI), Community Software Architecture Definitions, siehe:

www.sei.cmu.edu/architecture/start/glossary/community.cfm#definitions

[Spi12] M. Spitzer, Imitieren und/oder Improvisieren (?) Gemeinsam mehr Freude und Effektivität

(Geist & Gehirn), in: Nervenheilkunde, 31:180-184, 2012

[Sta11] G. Starke, Effektive Software-Architekturen – Ein praktischer Leitfaden, Hanser 2011

Abb. 8: Nach dem „Story Dot-Voting“wurde die Abhängigkeit zwischen Tipp -spiel und Score-Kalkulator umgedreht.