Don't Panic!

Der neue Blog "Der pragmatische Architekt" beschäftigt sich mit Konzepten für Software- und Systemarchitekturen aus der Brille eines praktizierenden Architekten. Welche Inhalte zur Sprache kommen, beschreibt der Auftakt.

Im "Hitchhiker's Guide to the Galaxy" von Douglas Adams steht in großen, leuchtenden Lettern "Don't Panic". Das ist auch oft mein erster Gedanke, wenn ich in Sachen Architektursupport beim Kunden auftauche. Gerade bei sehr wichtigen Entwicklungsprojekten, die in Schieflage geraten, herrscht meistens Panikmodus. In einem lang zurückliegenden Fall war ein Top-Manager so nervös, dass er ständig hinter seinen an der Workstation arbeitenden Schlüssel-Entwicklern stand, um ihnen gute Ratschläge für die softwaretechnische Umsetzung zu erteilen. Allerdings hatte er von Softwareentwicklung nur wenig bis gar keine Ahnung, weshalb die Produktivität noch schneller gegen gefühlte 0.0 konvergierte.

Von Softwarearchitektur war damals noch keine Rede, und ich spreche hier von systematisch entworfener Architektur. Ohnehin war das Projekt reich an Erfahrungen. Ich denke beispielsweise an die prototypische Hardware in einem Raum, den die Systemingenieure absperrten, bevor sie in Urlaub fuhren, damit wir "unfähigen" Softies damit nichts anstellen konnten – wie etwa Integrations- und Systemtests. Oder an das Schwarze-Peter-Spiel, weil in der Hostumgebung ein unerklärlicher Fehler an den Nerven des Teams zehrte. Hinterher wurde der wahre Täter auf frischer Tat ertappt: Es war das Betriebssystem. Damit hatte keiner gerechnet.

Durch Muster gelernt

Die meisten dieser Probleme basierten allerdings auf einer gemeinsame Ursache: die Systemarchitektur beziehungsweise ihre zufällig durch Ad-hoc-Maßnahmen zustande gekommene Struktur. Nachdem wir eine passende Architektur auf Basis von Mustern auf die Beine gestellt hatten, kam der Erfolg. Und mein "Ritterschlag" durch den Bereichsvorstand.

Was lernen wir daraus? Zum einen ist es wichtig, einen systematischen Architekturentwurf durch ein kleines Architektenteam als Fundament zu nutzen. Zum anderen benötigt man zu diesem Zweck entsprechende architektonische Konzepte und Werkzeuge. Beispiele hierfür sind Muster, Komponenten, Produktlinien, Softwareökosysteme, Referenzarchitekturen, Designtaktiken, Architekturbewertung, risikobasierte Teststrategien, architektonische Schulden, Refactoring, Agilität. Aber auch nichttechnische Aspekte wie der Umgang mit Geschäftszielen oder Führen ohne Macht.

Wie sollte die Toolbox eines Architekten also ausgestattet sein und wie lassen sich die vorhandenen Tools bzw. Methoden in der Praxis effektiv und effizient zum Entwurf eines hochqualitativen Systems nutzen? Wie spielen die Werkzeuge zusammen? Wann bietet sich welche Lösung an? Was sind hierbei die Verantwortlichkeiten eines Architekten und mit welchen Rollen ist eine (enge) Interaktion notwendig?

Architektur für alle

Ein solcher Baukasten muss selbstverständlich die gesamte Lebenszeit eines Systems unterstützen und für Nachhaltigkeit sorgen. Und wie erwähnt, ist Architektur nicht eine ausschließliche Angelegenheit von Architekten, sondern muss Rücksicht auf die Interessen der Beteiligten nehmen.

Der vorliegende Blog greift in jedem Posting einzelne Bausteine dieser Toolbox heraus, um sie pragmatisch zu beleuchten. Leser haben die Möglichkeit, durch Kommentare auf die Themenwahl Einfluss zu nehmen. Ich freue mich schon auf die Interaktion. Auch Themenvorschläge sind jederzeit willkommen.

Einige Themen werde ich mit einem Schuss Humor und Philosophie garnieren. Das Leben in den Gefilden der Software ist ohnehin schon ernst genug. Und schließlich gibt es auch bei Softwarearchitekturkonzepten "religiöse Dispute". ()