Können Sie Sich vorstellen, daß Sie einen Architekten beauftragen, ein schickes Einfamilienhaus für Sie zu bauen um dann feststellen zu müssen, daß er auch das Fundament gießt und die Wände mauert? Natürlich nicht. Er wird Ihnen Entwürfe des Hauses vorstellen und den von Ihnen gewählten Entwurf dann durch einen Bauunternehmer umsetzen lassen. Eventuell übernimmt er noch die Bauleitung, er wird aber keinesfalls selbst Hand anlegen.
Warum also sollte ein Softwarearchitekt programmieren?
Auf den ersten Blick ist die Forderung, daß ein Softwarearchitekt programmieren soll unsinnig. Er ist doch eine Autorität seines Faches, weiß wie Systeme in Komponenten zerlegt werden und kann das wunderbar in UML beschreiben. Er wird also einen Entwurf erstellen, diesen in Form einer Powerpoint-Präsentation dem Management vorstellen, mit Hilfe eines passenden MDA-Tools den Code generieren und fertig ist das gewünschte System.
Die Praxis sieht in der Regel anders aus:
- Das Deployment muß aufgrund von Performanz-Anforderungen so geändert werden, daß eine Komponente mal auf dem einen und mal auf dem anderen Knotentyp installiert wird.
- Das Protokoll zur Kommunikation zwischen zwei Knoten erzeugt zu viel Kontrolldaten und muß optimiert werden. Hierfür setzt man am besten eine bestehende Komponente aus einem Open Source Projekt ein, da man Inter-Prozeß-Kommunikation nicht wirklich als seine Business Domain ansieht.
- Im Feldversuch stellt sich heraus, daß ein Teil der Software nicht auf die parallele Nutzung vorbereitet ist und deshalb leider nicht reproduzierbare Ergebnisse liefert.
Hätte man diese Aspekte der Software in einem Entwurf festhalten können oder wird man sie nach der Änderung der Software in Entwurfsdiagramm einfügen? In der Regel nicht und das ist für mich eine wesentliche Eigenschaft von Software: die endgültige Architektur findet sich nur in der Software selbst wieder. Software ist im Gegensatz zu einem Gebäude so leicht veränderbar, daß der Entwurf sich während der Programmierung wiederholt ändert.
Der Softwarearchitekt muß daher Programmcode lesen können, mit der Entwicklungsumgebung umgehen können und in der Lage sein, die dynamischen Aspekte des entwickelten Systems auf der Basis von Logfiles, Coredumps und Heapdumps zu verstehen.
Das Verhältnis zwischen Architekten und Entwicklern
Neben der Anforderung an den Architekten, das laufende System zu verstehen um es modellieren zu können, benötigt er seine Programmierkentnisse auch, um seine Rolle im Team wahrnehmen zu können.
- Der Architekt sollte als Mentor für andere Entwickler arbeiten
- Der Architekt sollte verstehen, welche von anderen vorgeschlagene Komponenten zur Architektur des Gesamtsystems passen
- Der Architekt sollte Code anderer beurteilen können
Es ist klar, daß der Architekt nicht zu hundert Prozent mit Programmieraufgaben verplant sein darf. Er muß diese aber zumindest übernehmen können. Er muß in der Lage sein, mit anderen als „Pair“ an einem neuen Thema arbeiten können. Er muß Fehlermeldungen der Kunden auf den aktuellen Code beziehen und gemeinsam mit anderen Lösungsansätze erarbeiten können. Vielleicht beschränkt sich seine Programmiertätigkeit im Projekt auf die Erstellung von Prototypen; wichtig ist aber, daß er Programmieren kann und von allen Teammitgliedern auch in dieser Rolle als Autorität wahrgenommen wird. Nur dann werden die Entwickler bei schwierigen Fragestellungen, und vor allem wenn sie vom ursprünglichen Entwurf abweichen wollen, das Gespräch mit dem Softwarearchitekten suchen. Diese Kommunikation ist die unabdingbare Voraussetzung dafür, daß eine Software nicht wuchert und entartet, sondern auch nach mehreren Versionen ein Entwurf noch erkennbar und im Team bekannt ist und die Software somit auch wartbar bleibt.
Links
Es ist nicht so, daß ich der erste bin, der über nicht programmierende Architekten nachdenkt. Das Thema ist alt und wird wieder und wieder diskutiert. Ich habe das Thema aufgrund eines aktuellen Erlebnisses aus meiner täglichen Arbeit aufgegriffen. Einige Artikel zu dem Thema sind zu finden unter:
#1 von alexander am 8. Juli 2009 - 14:26
Das Gegenstück zum Softwarearchitekten, der sich mal lieber nicht die „Finger an Code schmutzig“ machen will, ist für mich eher der Architekt, der sich weigert, die Baustelle zu betreten und Bauaufsicht/-leitung lieber per Bauplan und Telefon erledigt.
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“?