Knigge für Software-Architekten

Antimuster: Zuviel des Guten

Peter Hruschka und Gernot Starke

Dass Menschen alles übertreiben können, wussten Sie schon. Softwarearchitekten verfügen jedoch über ein ganz besonderes Portfolio möglicher Exzesse: Zu viele Fesseln, zuviel Freiheiten oder zuviel Dokumentation. Doch eines nach dem anderen…

Zu den schwersten Aufgaben von Softwarearchitekten gehört die Entscheidung, welche Maßnahme und wie viel davon in einer bestimmten Situation angemessen ist. Also nicht zu viel und nicht zu wenig. Für viele von Ihnen klingt das bestimmt wie der Ratschlag der guten Köchin: Würze solange nach, bis es lecker schmeckt (aber wehe, Sie würzen zu viel – dann war’s das mit dem Süppchen).

Zu viele Fesseln: Ideenstau

Ihr Team besteht aus jeder Menge kreativen und erfahrenen Köpfen, die nur darauf brennen, ihre Ideen und Vorkenntnisse zum Wohl des Projekts oder Systems einbringen zu können. Dafür allerdings brauchen diese Köpfe ein gewisses Maß an Freiheit, diese Kreativität ausleben zu können: Neue Ideen müssen reifen und ausprobiert (in IT-Slang: „evaluiert“) werden, bevor sie als gute Ideen in die Architektur einfließen können.

Geben Sie als Architekt zu viele Fesseln vor, so unterbindet das jegliche Form der positiven Kreativität. Ihr Team wird dann nur noch nach solchen Ideen suchen, die diese Fesseln, Vorgaben und Randbedingungen möglichst erträglich und schmerzfrei machen.

Ein paar Vorgaben jedoch braucht fast jedes Team, sonst droht Perfektionismus (über diese Form des Unfugs schreiben wir in unserer zehnten Kolumne in einigen Monaten) oder Anarchie.

Zuviel Freiheit: Anarchie

Wir haben schon erlebt, dass innerhalb eines recht kleinen Teams jeder Entwickler in seiner aktuell favorisierten Programmiersprache entwickelt hat (wir fanden Perl, C, SQL-StoredProcedures, Java und XSLT), weil die Architekten des Systems sämtliche mögliche Freiheiten gelassen hatten. Diese Überfreiheit ist sicherlich in den meisten Fällen auch nicht angemessen. Das Team wird viel Zeit darauf verschwenden, sinnvolle Grenzen selbst zu definieren, statt gute Lösungsideen zu entwickeln und umzusetzen.

Setzen Sie also Grenzen – aber fesseln Sie Ihr Team nicht! Um dem Team diese Grenzen, Lösungsansätze und Konzepte zu vermitteln, bedarf es sowohl der Kommunikation als auch Dokumentation.

Zuviel Dokumentation

Zugegeben, in den meisten Projekten kommt meist das gegenteilige Problem vor, nämlich zu wenig Dokumentation. Das betrachten wir eher als ein Projekt- denn ein Architekturproblem, und wollen es daher auch nicht weiter vertiefen.

Unser Antimuster bezieht sich auf ein Übermaß an Architektur- und Designdokumentation, das das Erkennen des Waldes vor lauter Bäumen erschwert. Seiten um Seiten, schier endlose Beschreibung aller möglichen Sachverhalte, interessante wie uninteressante, wichtige wie unwichtige. Scheinbar alles nur Mögliche findet sich da, persistiert auf Druckerpapier oder in Write-only-Wikis.

Abschreckendes Beispiel: Als Vorbereitung eines Architektur-Audits eines mittelgroßen Systems erhielten wir eine Kopie der gesamten Architekturdokumentation auf zwei DVDs – sage und schreibe 8 Gigabyte, verteilt auf mehrere Hundert einzelne Dokumente, ohne weitere Unterstruktur, ohne Navigationshilfe oder Übersichtsdokument. Wir finden Dokumentation ja wichtig für das langfristige Verständnis – aber in verständlichen Häppchen, leicht zu lesen und ebenso leicht zu aktualisieren. Dazu hatten wir Ihnen in einer früheren Kolumne ja bereits den Tipp gegeben, aus unterschiedlichen Perspektiven zu dokumentieren, um gezielt einzelne Aspekte der gesamten Architektur skizzieren zu können.

Nun möchten wir diesen Tipp noch um den Ratschlag der strukturierten Faulheit erweitern – nach dem Sie nur so viel dokumentieren, wie für das System, das Team angemessen ist, aber nicht mehr. Zuviel Dokumentation kostet nämlich zuerst viel Zeit bei der Erstellung, anschließend raubt sie den Lesern die dringend benötigte Zeit, und schlussendlich macht zu viel Doku deren Aktualisierung und Fortschreibung nahezu unmöglich.

Angemessenheit ist schwer zu entscheiden

Aber eine einfache Antwort gibt es doch darauf. Und sie beruht auf der Tatsache, dass Doku nicht für den Schreiber, sondern für die Leser gemacht wird. Hören Sie als Architekt also auf das Feedback Ihrer Leser. Und wenn die mit dem Tiefgang und Umfang zufrieden sind, dann haben Sie den Nagel auf den Kopf getroffen. Wenn sie trotzdem ständig suchen und fragen müssen, war es zu wenig. Und wenn sie nichts mehr finden im Überfluss, war es entweder zu schlecht strukturiert oder schlicht zu viel.

Peter Hruschka und Gernot Starke haben vor einigen Jahren http://www.arc42.de ins Leben gerufen, das freie Portal für Softwarearchitekten. Sie sind Gründungsmitglieder des International Software Architecture Qualification Board (http://www.iSAQB.org) sowie Autoren mehrerer Bücher rund um Softwarearchitektur, Softwareentwurf und Entwicklungsprozesse. Mehr finden Sie unter http://www.systemsguild.com (Peter) und http://www.gernotstarke.de (Gernot).
Geschrieben von
Peter Hruschka und Gernot Starke
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.