The Software Architect Elevator - Notizen & Zusammenfassung

In diesem Post archiviere ich meine iterativen Notizen und Zusammenfassungen zum Buch “The Software Architect Elevator” von Gregor Hohpe.

Das Kernkonzept des Buches: In grossen, komplexen Unternehmen (“Enterprises”) gibt es oft eine starke Trennung zwischen dem “Maschinenraum” (der IT / den Entwicklern) und dem “Penthouse” (dem C-Level / Management). Ein guter Softwarearchitekt muss den Fahrstuhl bedienen können und auf beiden Ebenen fliessend kommunizieren.

🏗️ Teil 1: Architects

Kapitel 1: Architects

Es ist oft einfacher zu beschreiben, was ein Softwarearchitekt nicht ist, anstatt eine exakte Definition für die Rolle zu finden.

❌ Was ein Architekt NICHT ist:

RolleWarum der Architekt abweicht
“Senior Developer”Es handelt sich um einen völlig anderen Karrierepfad. Entwickler spezialisieren sich tiefgehend und liefern lauffähige Software aus. Architekten hingegen müssen strategische und organisatorische Aspekte mit in ihre Arbeit einbeziehen.
Die “Feuerwehr”Architekten haben meist ein breites Verständnis der Systemlandschaft und könnten Krisen lösen. Natürlich sollten sie Produktionsfehler nicht ignorieren (da sie wertvolles Feedback über Schwächen liefern!). Aber: Ein Architekt, der nur von Feuer zu Feuer rennt, hat keine Zeit mehr, über die Architektur nachzudenken.
ProjektmanagerDie Themen überschneiden sich zwar, aber der PM kümmert sich um das “Was” und “Wann” (Umfang, Budget, Zeitpläne). Der Architekt kümmert sich um das “Wie” (Technologie-Entscheidungen, Kompromisse/Trade-offs, Qualitätsmerkmale).
WissenschaftlerArchitekten müssen zwar abstrakt in Systemen und Modellen denken, doch ihre Entscheidungen haben immer spürbare Konsequenzen in realen, produktiven Projekten. Ein Elfenbeinturm funktioniert hier nicht.

🌍 Die vielen Ausprägungen von Architekten

Genauso wie es in der echten Welt Stadtplaner, Hochbau-, Landschafts- und Innenarchitekten gibt, existieren in der IT verschiedene Spezialisierungen auf unterschiedlichen Abstraktionsebenen:

  • Network Architects
  • Security Architects
  • Software Architects
  • Solution Architects
  • Enterprise Architects

Wichtig: Keine dieser Ausprägungen ist “wichtiger” (oder leitet gar die anderen). Sie operieren lediglich auf verschiedenen Flughöhen.

🕵️‍♂️ Architekten kümmern sich um “Nicht-Anforderungen” (Nonrequirements)

Oft heisst es: “Entwickler kümmern sich um funktionale Anforderungen, Architekten um nicht-funktionale”. Diese nicht-funktionalen Anforderungen werden gerne als die “ilities” zusammengefasst:

  • Scalability (Skalierbarkeit)
  • Maintainability (Wartbarkeit)
  • Availability (Verfügbarkeit)
  • Interoperability (Interoperabilität) u.v.m.

Doch die Realität ist komplexer. Architekten kümmern sich vor allem um “Nonrequirements”. Das sind keineswegs Dinge, die “nicht benötigt” werden, sondern vielmehr Anforderungen, die nirgendwo explizit aufgeschrieben wurden. Dazu gehören:

  • Der übergreifende geschäftliche Kontext
  • Stillschweigende Annahmen (Tacit assumptions)
  • Versteckte Abhängigkeiten (Hidden dependencies)
  • Alles, was von Beteiligten einfach “vorausgesetzt” wird, ohne es zu benennen

💡 Die wertvollste Aufgabe eines Architekten: Diese impliziten “Nicht-Anforderungen” auszugraben und sie für alle Beteiligten ausdrücklich (explizit) sichtbar zu machen.

📈 Wie misst man den Wert eines Architekten? (Value)

  1. Punkte verbinden (“Connect the dots”): Wenn einzelne IT-Elemente für sich zwar toll gebaut sind, aber das fertige Gesamtsystem trotzdem nicht liefert, was das Business braucht, greift der Architekt ein. Er schaut zwischen die Boxen eines Organigramms, um zu garantieren, dass alle Abhängigkeiten verstanden wurden.
  2. Kompromisse erkennen (“See trade-offs”): In der IT gibt es keine perfekten Lösungen, fast jede Entscheidung hat Vor- und Nachteile (trade-offs). Der Architekt sieht beide Seiten der Medaille und balanciert sie gemäss den übergeordneten Zielen aus.
  3. Über Produkte hinausblicken (“Look beyond products”): Viel zu viele IT-Entscheidungen werden bloss als “Produktauswahl” getroffen. Architekten durchschauen die Feature-Listen und Marketing-Namen und betrachten die tatsächlichen technischen Eigenschaften und Kompromisse, die ein Produkt mitbringt.
  4. Strategie übersetzen (“Articulate strategy”): Die IT existiert aus einem einzigen Grund: Um die Geschäftsstrategie zu unterstützen! Architekten bilden das notwendige Bindeglied, indem sie geschäftliche Bedürfnisse in greifbare technische Treiber übersetzen.
  5. Abliefern (“Deliver”): Ein Architekt muss mit beiden Beinen in der Realität stehen. Er muss sich das direkte Feedback seiner Entscheidungen direkt aus der Projektumsetzung abholen (den Maschinenraum besuchen!). Ohne diesen Realitätsabgleich bleibt Kontrolle nur eine Illusion.

Kapitel 2: What is an Architect?

🛗 Teil 2: Architecture

Kapitel X: The Architecture Elevator

  • Fahrstuhl-Analogie: Der Architekt bringt technische Realitäten ins Management und übersetzt Business-Strategien in Code-Architekturen.
  • Illusion of Control: Das Top-Management denkt oft, es hat Kontrolle, weil es viele Diagramme besitzt, während im Maschinenraum das blanke Chaos herrscht.

(Hier geht es für dich weiter, füge einfach die weiteren Kapitelnamen ein)

🔀 Teil 3: Communication

Platzhalter für deine Notizen zur Kommunikation…

⚙️ Teil 4: Organization

Platzhalter für Notizen zur Organisation…

Tipp für meine Notizen: Jederzeit, wenn ich ein neues Kapitel im Zug oder abends lese, kann ich in diesen Block-Post zurückkehren, die Änderungen ergänzen und den Blogpushen!

📚 Weiterführende Links & Quellen