Ein Zufallsfund beim Googlen zeigt mir, dass dies wohl auch in der Baubranche ein real existierendes Problem ist: “Falls Sie einen Architekt haben dem die harte Baustellenarbeit nicht liegen sollte, oder wenn Sie eine zusätzliche Kontrollfunktion installieren möchten, dann übernehmen wir gerne die Örtliche Bauaufsicht. Wir haben den Vorteil, dass unsere Mitarbeiter über langjährige Baustellenerfahrung verfügen und dadurch für diese Aufgabe bestens geeignet sind.”

Dennoch denke ich, dass im Baugewerbe Aufsicht und Leitung ernsthafter verfolgt werden, denn im Gegensatz zu unserer Branche, wo ein unbefriedigendes (zu langsam, fehlerhaft, unbedienbar, etc.) Softwareerzeugnis oft als naturgegeben hingenommen wird und selten zu persönlichen Konsequenzen führt, kann ein Fehler bei der Bauaufsicht für den Architekten schnell zu einem teuren Haftungsproblem werden.

Interessanterweise wird im Artikel das Thema Test – zum dem es in der Baustellenwelt meiner Ansicht nach keine direkte Entsprechung gibt – etwas stiefmütterlich behandelt. Ich denke, dass ein Softwarearchitekt nicht nur mit den Entwicklern, sondern auch mit dem Testteam eng zusammenarbeiten muß. So müssen zum Beispiel repräsentative Performancetests realisiert werden, um die Tragfähigkeit der Architektur zu validieren. Integrationstest, Lasttests und Feldversuche werden dem Architekten wertvolle Daten und Feedback über das Gesamtsystem liefern. Zudem kann es nicht schaden, wenn ein Softwarearchitekt ein Auge auf die im Test entstehene Software hat – auch die Tests werden sich über die Zeit fortentwickeln und müsen daher wartbar sein.

Zuletzt noch eine Vermutung meinerseits: kann es sein, dass die Kaste der nicht-programmierenden Softwararchitekten mit auch das Produkt einer Firmenkultur ist, in der es eine strenge Wertigkeitshierarchie zwischen Tätigkeiten gibt? Frei dem Motto “Designen ist besser als Programmieren und das ist allemal besser als Testen”?