Praxis-Tipps für angehende Software-Architekten

Urs Enzler ist Software Architekt, Speaker und Co-Gründer der .NET Usergroup Zentralschweiz. Seine Lieblingsthemen sind architektonische Herausforderungen und Lernen als Team. In diesem zweiten Teil des Interviews spreche ich mit ihm über den Weg vom Software-Entwickler zum Software-Architekten.

Was ist für dich ein guter Software-Architekt?

Jemand, der in Zusammenhängen und Abhängigkeiten denkt, der die Modularisierung erkennt. Und er ist ein guter Kommunikator und auch ein Coach. Ausserdem ist Business-Know-how ideal.
Kommunikation ist wichtig, um die Konzepte ans Entwicklungsteam oder an die Business-Vertreter zu vermitteln und das Zuhören, um die Stakeholder zu verstehen. Als Coach soll er das Team weiterbringen und nicht einfach Entscheide top-down an die Entwickler kommunizieren.

Was ist für dich der grosse Unterschied zwischen Software-Entwicklern und Software-Architekten?

Der Software-Entwickler kann für gut ein umrahmtes Problem mit Technologie X eine Lösung erarbeiten. Der Architekt versteht die Zusammenhänge, sieht die Modularisierung, steuert das Abhängigkeitsmanagement und versteht das Denken des Business.

Wächst man mit Erfahrung automatisch in dieses umfassendere Denken hinein?

Kann sein, muss aber nicht. Man kann eine Karriere als Software-Entwickler machen und sich wenig um das Konzeptionelle kümmern. Wenn man aber ein konzeptionelles Verständnis hat, macht das vieles einfacher. Zudem hat konzeptionelles Wissen eine bessere Halbwertszeit als technologisches Wissen.

Wie kann man sich konzeptionelles Denken aneignen?

Zum einen geht es um Abstraktionsfähigkeit. Hier stossen gewisse Personen an Grenzen. Einige Kollegen sind immer sehr schnell ins Detail gegangen, alles musste immer sehr spezifisch sein. So eine Person wird kaum je Architekt. Bei anderen spürt man hingegen sofort, dass sie das Muster erkennen, das Konzept. Daneben ist es auch eine Frage der Übung.

Wie kann man das üben?

Ich habe oft Architektur-Katas durchgeführt. Der Begriff Kata kommt aus dem Kampfsport, wo man gewisse Bewegungen wiederholt, bis sie vollkommen automatisiert sind. Ich stelle eine Aufgabe und wir üben den Architekturdefinitionsprozess. Immer und immer wieder. Bis man nicht mehr nachdenken muss. Mit einem Architekten habe ich das über ein halbes Jahr lang wöchentlich gemacht. So gilt bei der Architektur immer: Wo sind die Schnittstellen? Was geht über die Schnittstellen?

Es ist wie bei TDD. Man könnte denken, dass es egal ist, ob man den Test vorher oder nachher schreibt. Die Magie liegt aber im Vorgehen. Was muss ich am Ende haben? Lass mich das mal als Test aufschreiben. Der Rest ergibt sich dann. Ansonsten muss ich alles gleichzeitig im Kopf behalten. Das ist viel schwieriger.

Hast du Literaturtipps, wenn sich jemand zum Architekten entwickeln möchte?

Für Konzepte sind Architekturbücher sicher okay. Oft wird aber nicht das Vorgehen geübt, sondern verschiedene Architekturtypen werden aufgezählt.

Wertvoll sind aber sicher diese Bücher:

«Effektive Software-Architekturen – ein praktischer Leitfaden» von Gernot Starke
«Vorgehensmuster für Softwarearchitektur: kombinierbare Praktiken in Zeiten von Agile and Lean» von Stefan Toth
«Knigge für Softwarearchitekten» von Peter Hruschka und Gernot Starke
«Driving Technical Change – Why people on your team don’t act on good ideas, and how to convince them they should» von Terrence Ryan.
«This is lean – resolving the efficiency paradox» von Niklas Modig und Pär Ahlström

Kurse und Zertifikate?

Von Zertifikaten halte ich generell wenig. Ich habe aber von verschiedene Seiten gehört, dass iSAQB und SEI gute Kurse zu den Zertifikaten anbieten.

Weitere Ressourcen?

Martin Fowler’s Blog, Videos, beispielsweise von NDC, einer UserGroup beitreten resp. eine gründen oder natürlich mir auf Twitter (@ursenzler) folgen …

Herzlichen Dank, Urs, für das aufschlussreiche Gespräch!