stefan TOTH VORGEHENSMUSTER FÜR SOFTWARE- ARCHITEKTUR KOMBINIERBARE PRAKTIKEN IN ZEITEN VON AGILE UND LEAN Im Internet: www.swamuster.de Toth Vorgehensmuster für Softwarearchitektur CHV Newsletterhinweis Computer Bleiben Sie auf dem Laufenden! Der Hanser Computerbuch-Newsletter informiert Sie regelmäßig über neue Bücher und Termine aus den verschiedenen Bereichen der IT. Profitieren Sie auch von Gewinnspielen und exklusiven Leseproben. Gleich anmelden unter www.hanser-fachbuch.de/newsletter Stefan Toth Vorgehensmuster für Softwarearchitektur Kombinierbare Praktiken in Zeiten von Agile und Lean Der Autor: Stefan Toth, Hamburg Alle in diesem Buch enthaltenen Informationen, Verfahren und Darstellungen wurden nach bestem Wissen zusammengestellt und mit Sorgfalt getestet. Dennoch sind Fehler nicht ganz aus­ zuschließen. Aus diesem Grund sind die im vorliegenden Buch enthaltenen Informationen mit keiner Verpflichtung oder Garantie irgendeiner Art verbunden. Autor und Verlag übernehmen infolgedessen keine juristische Verantwortung und werden keine daraus folgende oder sonstige Haftung übernehmen, die auf irgendeine Art aus der Benutzung dieser Informationen – oder Teilen davon – entsteht. Ebenso übernehmen Autor und Verlag keine Gewähr dafür, dass beschriebene Verfahren usw. frei von Schutzrechten Dritter sind. Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Waren­ bezeichnungen usw. in diesem Buch berechtigt deshalb auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen­ und Markenschutz­Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften. Bibliografische Information der Deutschen Nationalbibliothek: Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbiblio­ grafie; detaillierte bibliografische Daten sind im Internet über http://dnb.d­nb.de abrufbar. Dieses Werk ist urheberrechtlich geschützt. Alle Rechte, auch die der Übersetzung, des Nachdruckes und der Vervielfältigung des Buches, oder Teilen daraus, vorbehalten. Kein Teil des Werkes darf ohne schriftliche Genehmigung des Verlages in irgendeiner Form (Fotokopie, Mikrofilm oder ein anderes Verfahren) – auch nicht für Zwecke der Unterrichtsgestaltung – reproduziert oder unter Verwendung elektronischer Systeme verarbeitet, vervielfältigt oder verbreitet werden. © 2014 Carl Hanser Verlag München, www.hanser­fachbuch.de Lektorat: Brigitte Bauer­Schiewek Copy editing: Petra Kienle, Fürstenfeldbruck Herstellung: Irene Weilhart Layout: Manuela Treindl, Fürth Umschlagdesign: Marc Müller­Bremer, www.rebranding.de, München Umschlagrealisation: Stephan Rönigk Druck und Bindung: Kösel, Krugzell Ausstattung patentrechtlich geschützt. Kösel FD 351, Patent­Nr. 0748702 Printed in Germany Print­ISBN: 978­3­446­43615­2 E­Book­ISBN: 978­3­446­43762­3 Inhalt Geleitwort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . VII 1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.1 Kurze Motivation.........................................................1 1.2 Vorgehensmuster als Mittel der Wahl........................................2 1.3 Gegenstand: Softwarearchitektur ...........................................3 1.4 Mission Statement .......................................................4 1.4.1 Abgrenzung zu anderen Büchern....................................5 1.4.2 Für wen ich dieses Buch geschrieben habe............................7 1.5 Dieses Buch richtig verwenden.............................................8 1.5.1 Ein grober Überblick ..............................................8 1.5.2 Patterns lesen ....................................................9 1.5.3 Patterns anwenden................................................9 1.5.4 Agil und Lean sind Fremdwörter?...................................12 1.6 Webseite...............................................................14 1.7 Danksagung............................................................14 2 Einstieg samt Wegweiser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.1 Die inhaltliche Vision....................................................16 2.1.1 Durch Anforderungen getrieben....................................16 2.1.2 Vom Aufwand her dem Problem angemessen.........................17 2.1.3 Von aktuellen Erkenntnissen zu Zusammenarbeit und Vorgehen beeinflusst......................................................18 2.1.4 Gut mit der Implementierung verzahnt..............................19 2.1.5 Einfach in aktuelle Vorgehensmodelle integrierbar....................21 2.1.6 Warum Design alleine nicht hilft ...................................22 2.1.7 Warum agiles Vorgehen alleine nicht hilft............................23 2.2 Muster im Überblick.....................................................25 2.2.1 Kapitel 3 – die Basis für Architekturarbeit ...........................25 2.2.2 Kapitel 4 – richtig entscheiden.....................................25 2.2.3 Kapitel 5 – Zusammenarbeit und Interaktion.........................28 2.2.4 Kapitel 6 – Abgleich mit der Realität ................................28 2.2.5 Muster kategorisiert..............................................31 2.3 Muster im Vorgehen einsortiert ...........................................32 2.4 Muster und die Architektenfrage ..........................................35 VI Inhalt 2.4.1 Die theoretisch beste Rollenverteilung...............................37 2.4.2 Die praktisch beste Rollenverteilung ................................39 2.5 Kurze Einführung ins Fallbeispiel .........................................43 3 Die Basis für Architekturarbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .45 3.1 Initialer Anforderungs­Workshop..........................................48 3.2 Anforderungspflege­Workshops ...........................................53 3.3 Szenarien als Architekturanforderungen....................................57 3.4 Szenarien kategorisieren.................................................62 3.5 Technische Schulden als Architekturanforderungen ..........................66 3.6 Architekturarbeit im Backlog .............................................74 3.7 Architekturarbeit auf Kanban .............................................77 4 Richtig entscheiden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83 4.1 Architekturarbeit vom Rest trennen........................................85 4.2 Der letzte vernünftige Moment............................................90 4.3 Gerade genug Architektur vorweg .........................................95 4.4 Architekturentscheidungen treffen........................................101 4.5 Release­Planung mit Architekturfragen....................................110 4.6 Risiken aktiv behandeln.................................................116 4.7 Im Prinzip entscheiden .................................................123 4.8 Ad­hoc­Architekturtreffen ...............................................127 5 Zusammenarbeit und Interaktion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 5.1 Informativer Arbeitsplatz................................................135 5.2 Gemeinsam entscheiden ................................................140 5.3 Analog modellieren.....................................................146 5.4 Stakeholder involvieren .................................................152 5.5 Wiederkehrende Reflexion...............................................159 5.6 Architecture Owner ....................................................166 5.7 Architekturcommunities ................................................172 6 Abgleich mit der Realität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 6.1 Frühes Zeigen .........................................................181 6.2 Realitätscheck für Architekturziele .......................................186 6.3 Qualitative Eigenschaften testen..........................................191 6.4 Qualitätsindikatoren nutzen .............................................201 6.5 Code und Architektur verbinden..........................................212 6.6 Kontinuierlich integrieren und ausliefern..................................220 6.7 Problemen auf den Grund gehen .........................................225 Literaturverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231 Stichwortverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237 Geleitwort Das Märchen vom agilen Architekten „Heißt du etwa Rumpelstilzchen?“ – „Das hat dir der Teufel gesagt, das hat dir der Teufel gesagt!“ (Kinder­ und Hausmärchen der Brüder Grimm, 7. Auflage 1857) Die schöne Müllerstochter, die aus Stroh Gold spinnen sollte, hat den Namen von Rumpel­ stilzchen nicht etwa geraten. Dazu hätte sie mehr als die drei bei den Gebrüdern Grimm beschriebenen Iterationen gebraucht. Sie hatte Wissen (nicht vom Teufel). Und als Ali Baba „Sesam, öffne Dich“ sprach, um in die Höhle mit unermesslichen Schätzen zu gelangen, hat er sich das auch nicht selbst ausgedacht. Er hat es sich abgeguckt von 40 Leuten, die schon mal drin waren in der Höhle. Er konnte auf deren Erfahrung zurückgreifen. Der Schatz, um den es in diesem Buch von Stefan Toth geht, lässt sich verkürzt als Antwort auf folgende Frage beschreiben: Wie passt Softwarearchitekturmethodik zu einem zeitge­ mäßen Vorgehen? Oder besser noch: Wie können sie gemeinsam größeren Nutzen bringen? Dass diese Frage viele bewegt, erlebe ich selbst regelmäßig in Workshops zu meinem Lieb­ lingsthema Architekturdokumentation. Dort geht es darum, wie man Softwarearchitektur nachvollziehbar festhält und kommuniziert; in den Veranstaltungen drehen sich Fragen und Diskussionen regelmäßig darum, ob und wenn ja wie die gezeigten Zutaten zu einem agilen Vorgehen wie beispielsweise Scrum passen. Ganz allgemein können Sie das Interesse aber auch an den zahlreichen Blog­ und Konferenzbeiträgen der letzten Jahre ablesen. Diese verknüpfen die Begriffe „agil“ (als griffigstes Wort für zeitgemäßes Vorgehen) und „Archi­ tektur“ mal mehr mal weniger pfiffig im Titel, etwa: „Jenseits des Elfenbeinturms – der agile Architekt“ oder „Architektur und agiles Vorgehen – ein Widerspruch?“. Und mehr noch ist es abzulesen an den vollen Sälen, wenn solche Vorträge stattfinden. Die Frage weckt Interesse. Gibt es gute Antworten? Konferenzbeiträge – zumindest die, die ich gesehen habe – folgten in ihrem Ablauf häufig einem Schema: Zunächst werden die Begriffe „Agilität“ und „Architektur“ ausführlich defi­ niert oder zumindest geklärt. Bei Agilität ist es dabei Folklore, das agile Manifest mit seinen berühmten vier Wertpaaren („Individuen und Interaktionen vor Prozessen und Werkzeugen“ etc.) auf eine Folie zu bannen. Dann wird der angebliche Widerspruch herausgearbeitet, der umso dramatischer ausfällt, je schwergewichtiger und klassischer das Verständnis von Softwarearchitektur, der zugrunde liegende Entwicklungsprozess und die damit verbundenen Artefakte in Notationen der 1990er­Jahre geschildert werden. Schließlich wird der Wider­ spruch durch sogenannte Best Practices aufgelöst („funktioniert doch super zusammen“). VIII Geleitwort Wolkige Tipps wie zum Beispiel: kein „Big Upfront Design“, auf die SOLID­Prinzipien achten, die Architektur iterativ und inkrementell entwickeln wie „den Rest“ auch … Die Zuhörer verlassen den Saal etwas enttäuscht. Alles richtig, gut und schön, aber wie genau machen wir das jetzt in unserem Projekt? Wo fangen wir an? Wenn schon kein Big Upfront Design, wie klein ist dann das richtige Small? Es liegt wohl auch, aber nicht nur am Format des Frontalvortrags und der oft kurzen Vortragsdauer (beliebt: 45 Minuten), dass die wirk­ lich spannenden Fragen auf Konferenzen oft unbeantwortet bleiben. Mitunter fehlt es auch schlicht an ausreichenden praktischen Projekterfahrungen. Märchenstunde? Für mich steht außer Zweifel, dass Stefan Toth die nötige Erfahrung besitzt. Er hat sehr unter­ schiedliche Projekte über einen längeren Zeitraum begleitet und zahlreiche einschlägige Workshops durchgeführt. Bei den Kunden wurde mal klassisch, mal agil, mal irgendwie dazwischen vorgegangen und auch die Branchen könnten unterschiedlicher kaum sein. Vom Finanzsektor bis zur Gaming­Plattform war alles dabei. Das Themenspektrum um­ fasste die methodische Softwarearchitektur vom Entwurf bis zur Bewertung von konkreten Architekturentscheidungen. So hat Stefan beispielsweise ein agiles Team begleitet und be­ fähigt, regelmäßige Architekturbewertungen in ihren Entwicklungsprozess zu integrieren und eigenverantwortlich durchzuführen. Während viele bei Architekturbewertung sofort an schwergewichtige Methoden wie ATAM denken, wirkt hier nun ein schlankes, aber wir­ kungsvolles Set an Elementen, bei großer Akzeptanz im Team. Das ist vielleicht auch schon die Grundidee des Buchs: Es gibt nicht den einen Weg für alle Projekte. Aber es gibt bewährte und schlanke Praktiken in Form von Puzzleteilen, die Nutzen stiften. In einigen Projekten und Workshop­Situationen, eigentlich in zu wenigen, hatte ich als Kollege das Vergnügen, mit Stefan Toth zusammenzuarbeiten, und konnte wie die Mitarbeiter der Kunden an seinem Wissen und seinen Erfahrungen teilhaben. Und so freut es mich, dass Sie nun als Leser dieses Buchs ebenfalls davon profitieren können. Denn Stefan Toth hat ein passendes Format zur Vermittlung seines Wissens und Könnens gewählt. Anders als es in einem knappen Vortrag möglich wäre, stellt er hier im Buch seine Ideen ausführlich dar und illustriert sie mit Beispielen. Gleichzeitig ist das Buch lebendig und kein langweiliger Schmöker. Stefan hat viel von seinem Witz in die Zitate und Antipatterns einfließen lassen, ohne dabei albern oder unsachlich zu werden. Die Idee, die einzelnen Zu­ taten als kombinierbare Muster darzustellen, macht die Inhalte nicht nur leichter erlernbar, sondern vor allem auch einzeln anwendbar. Das erleichtert den Start in Ihrem Projekt un­ gemein. Die einzelnen Zutaten sind trotzdem kein loses Schüttgut, sondern gut aufeinander abgestimmt und in ihrer Gesamtheit schlüssig. Ausdrucksstarke Visualisierungen – eine besondere Spezialität von Stefan – vermitteln komplizierte Inhalte gut erinnerbar und ver­ knüpfen die einzelnen Muster. Aus eigener Erfahrung kann ich sagen, dass die Erarbeitung und Aufbereitung von Inhalten in Form eines Buchs große Vorteile bietet (die hier auch ausgeschöpft wurden), aber auch einen nicht zu unterschätzenden Nachteil, zumindest verglichen mit Vorträgen oder einem Workshop. Es besteht die Gefahr, dass man als Autor weniger Feedback bekommt. Ich möchte Sie daher ermutigen, Erfahrungen, die Sie mit den dargestellten Praktiken machen konnten, zu teilen. Tauschen Sie sich aus, mit dem Autor und auch mit anderen Lesern. Um zum Schluss noch mal auf Rumpelstilzchen zurückzukommen: In diesem Buch lernen Sie nicht, wie Sie aus Stroh Gold spinnen. Dafür viele andere Dinge, die Sie jetzt vermutlich Geleitwort IX auch noch nicht können. Und es ist kein Märchen. Alles ist wahr. Wenn Sie mögen, schließen Sie das Buch nun kurz, sprechen mir nach: „Sesam, öffne Dich“, und schlagen es wieder auf. Und es tut sich tatsächlich ein reicher Schatz an Erfahrungswissen auf, der nur darauf wartet, Stück für Stück heraus in Ihr Projekt getragen zu werden. Mir bleibt nur noch, Ihnen viel Freude damit zu wünschen. Stefan Zörner im Herbst 2013