Knigge für Software-Architekten: Zwölftes Muster

Erfolgsmuster: Der Vereinfachungskobold

Peter Hruschka und Gernot Starke

Willkommen in der zwölften Ausgabe unserer Kolumne rund um Verhaltensmuster von Softwarearchitekten.


Frage: Wie bootet ein Softwarearchitekt?

Antwort: Nach dem meist akustischen Wake-up-Event geschieht der Übergang von Runlevel 0 auf Runlevel 1. Darin findet sich das noch schlaftrunkene Individuum kurze Zeit später vis-a-vis der durch eine Zeitschaltuhr bereits eingeschalteten Kaffeemaschine. Es fordert per Knopfdruck ein koffeinhaltiges Heißgetränk und führt die statische Methode „drinkSlurp( coffee )“ aus. Dadurch gelangt das Wesen in Runlevel 2, den vorläufigen Wachzustand. Jetzt werden diverse Demon-Prozesse gestartet (speakd, seed, feeld, thinkd). Die höchste Priorität erhält dabei der simplifyd, der überflüssige Komplexität erkennt und automatisch reduziert. simplifyd ist non-interruptible.

Wir nennen den simplifyd auch den Vereinfachungskobold, der tief eingebettet in Ihrem Architektengehirn im Hintergrund ständig nach Vereinfachungspotenzial sucht. Dummerweise gibt es im realen Leben keine Kobolde in Ihrem Gehirn, sodass Sie die mit der Vereinfachung verbundenen Aufwände doch noch selbst leisten müssen.

Einfach ist gut

Einfachheit ist grundsätzlich ein erstrebenswertes Entwurfsziel für Softwarearchitekten. Einfache Systeme sind leichter verständlich, enthalten weniger Risiko, lassen sich mit weniger oder leichter verständlichem Code implementieren und sind meistens leichter erweiterbar. In einfacheren Systemen können Sie leichter Fehler finden, und höchstwahrscheinlich sind auch erheblich weniger Fehler darin enthalten. Einfache Systeme reduzieren Kosten und Aufwand gegenüber komplizierten. Einfachere Systeme sind schlichtweg besser als komplizierte Systeme.

Ziel: Einfache Lösung

Wir merken in der Praxis oft leichte Verwirrung der Begriffe „kompliziert“ und „komplex“ – beides Antagonisten unserer gewünschten Einfachheit:

  • Kompliziert sind Dinge, die viele Einflussfaktoren in nachvollziehbaren, linearen Zusammenhängen enthalten. Komplizierte Systeme können wir mit „Wissen“ verstehen. Zur Behandlung komplizierter Situationen genügen Regelwerke.
  • Komplex sind Dinge, bei denen viele Einflussfaktoren in nichtlinearen, meist dynamischen Zusammenhängen stehen. Zur Behandlung komplexer Situationen benötigen Sie Erfahrung und Heuristiken – aber selbst dann gibt es keine Garantie für Erfolg.

Sehen Sie kurz auf Abbildung 1 – dort können Sie den Übergang zwischen kompliziert und komplex erkennen [1], [2]. In der Realität ist diese Grenze oftmals fließend – in jedem Fall jedoch ist Einfachheit besser als kompl*.

Abb. 1: Kompliziert und komplex (nach [1])
Allein auf weiter Flur

Wahrscheinlich sind Sie als Softwarearchitekt im Projekt der Einzige auf der Suche nach Einfachheit: Entwickler arbeiten häufig mit stark lokalem Fokus und können dadurch kaum übergreifendes Vereinfachungspotenzial erkennen oder umsetzen. Ihr Business stellt Forderung über Forderung und ist an Einfachheit der Technik gar nicht interessiert. Auch Projektleiter denken nicht notwendigerweise an Vereinfachungen. Sie unterstützen die Tendenz zur Einfachheit jedoch indirekt: durch knappe Budgets oder Zeitpläne.

Komplizierte Technik vereinfachen

Häufig leiden unsere technischen Lösungen („Architekturen“) an einer eigenen Kompliziertheit: Wir haben zu viele Bausteine mit zu vielen Abhängigkeiten, wir haben komplizierte Technik für einfache Probleme verwendet. Wir haben zu komplizierte Schnittstellen, zu aufwändige Frameworks und kranken an Featuritis.

Das sind genau die Bereiche, die Ihr allmorgendlich gestarteter Vereinfachungskobold simplifyd finden und entsorgen soll. Helfen Sie ihm dabei.

Komplizierte Technik vereinfachen

Unsere Lösungen, Strukturen, Konzepte und eingesetzten Technologien triefen oftmals vor Kompliziertheit. Scharen optimistischer Entwickler und technikgläubiger Entscheider haben über die Jahre Lösungen geschaffen, die sie selbst als „historisch gewachsen“ bezeichnen. Wir nennen solche gordischen Techno-Knoten bestenfalls „historisch gewuchert“. Sie als Softwarearchitekt können Ihren privaten Vereinfachungskobold darauf ansetzen, hier für nachhaltige Verbesserung zu sorgen. Gestalten Sie Lösungen einfach, verständlich, nachvollziehbar. Ohne überflüssige Schnörkel, geradeaus, schlicht. Stellen Sie Abhängigkeitsgeflechte in Frage. Manchmal sind direkte Wege besser als Pfade durch Dutzende von Schichten, Layers und Frameworks.

Vor komplexer Fachlichkeit warnen

Unsere Fachlichkeiten oder Geschäftsprozesse sind hingegen häufig inhärent komplex. Diese fachliche Schwierigkeit können wir als Softwarearchitekten nicht reduzieren, sondern lediglich auf diese Komplexität hinweisen und vor deren Folgen warnen: Komplexe Fachlichkeit erzeugt hohen Implementierungs- und Pflegeaufwand. Häufig lassen sich auch fachliche Aufgaben, Prozesse oder Strukturen vereinfachen – jedoch liegt das eindeutig außerhalb Ihres Verantwortungsbereichs als Softwarearchitekt.

Einfachheit wertschätzen

Erziehen Sie sich selbst und Ihre Teams dazu, Einfachheit wertzuschätzen. Nutzen Sie die ohnehin regelmäßigen Treffen in der Kaffeeküche zu einem kurzen Gespräch und fragen Ihr Team nach Vereinfachungsmöglichkeiten. Gezielt darauf angesprochen, kann Ihnen jeder Entwickler Stellen im Quellcode nennen, die es Wert wären, vereinfacht zu werden. Wir nennen ein solches Ritual die „Vereinfachungsminute“ – das geht schnell und liefert (garantiert!) gute Anregungen für Ihre weitere Architekturarbeit. Heben Sie die Ergebnisse dieser Vereinfachungsminute – analog der Risikoliste von Projektleitern – an prominenter Stelle im Projekt auf. Planen Sie gezielt Maßnahmen ein, damit diese Liste auch mal bearbeitet wird und nicht nur eine Sammlung guter Ideen bleibt.

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

Geschrieben von
Peter Hruschka und Gernot Starke
Kommentare

Schreibe einen Kommentar

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