Softwarearchitektur

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.

1. Der Architekt sollte als Mentor für andere Entwickler arbeiten
2. Der Architekt sollte verstehen, welche von anderen vorgeschlagene Komponenten zur Architektur des Gesamtsystems passen
3. 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:

• Architects Dont Code
• Should architects code?
• How to spot the dreaded non-coding architect
• Those Who Can, Code; Those Who Can’t, Architect
• A story about a technical architect – Pimp my architecture

Bisher habe ich Gunter Dueck nur von seiner regelmäßigen Kolumne im Informatikspektrum gekannt. In dieser Woche auf der OOP habe ich ihn zum ersten ‘mal live erlebt und man kann wirklich nur von einem Erlebnis reden. Sein Thema waren Infrastrukturen (The Smarter Planet) mit der für mich wesentlichen Aussage, daß Infrastruktur nicht um der Technik willen gebaut werden sollte. Er brachte ein schönes Beispiel, das ich nur sinngemäß zitieren kann:

Vor ca. 10 Jahren hat er sich mit den ersten digitalen Kameras beschäftigt. Diese waren schwer, hatten eine schlechte Auflösung und es war schwer, die Kamera mit einem Computer zu verbinden. Das war aber die einzige Möglichkeit, sich die Bilder anzusehen. Seine Frau hielt digitale Kameras daher auch für komplett überflüssig. Eines Tages kam seine Frau aus der Filiale einer Drogeriekette nach Hause und berichtete, daß man dort neuerdings digitale Bilder direkt von einer Diskette oder CD auf Papier drucken könne und sie nun auch gerne eine digitale Kamera hätte.

Zu diesem Zeitpunkt, der sicherlich 6 Jahre später kam, war also für den Kunden die richtige Infrastruktur verfügbar, um die Technik für sich nutzbringend einzusetzen. Es wird generell so sein, daß der Entwicklungsstand der Technik der tatsächlichen Nutzbarkeit durch den Anwender einige Innovationszyklen voraus ist. Was ist aber die Nachricht, die man daraus ablesen soll:

• soll man nur noch an Technik arbeiten, die der Kunde dann direkt einsetzen kann?
• nimmt man in Kauf, daß die Entwicklung der Nutzung voraus ist und daher der “Return of Invest” auf sich warten läßt?

Ich habe nach dem Vortrag natürlich sofort über die Entwicklung von OpenScape, das Produkt an dem ich arbeite, nachdenken müssen und mir kamen etliche Fragen in den Kopf. Sollen wir nur das umsetzen, was Kunden explizit als Anforderung formuliert haben? Können solchermaßen formulierte Anforderungen noch innovativ sein oder orientieren wir uns dann nur noch an dem was der Wettbewerb schon kann? Ist das Finden der Balance zwischen den Anforderungen der Kunden und der technologischen Innovation eine Aufgabe des Architekten?

Fangen wir mit der letzten Frage an, denn sie ist nur rhetorischer Natur. Von einem Softwarearchitekten werden mehr Fähigkeiten erwartet, als nur ein guter Entwickler zu sein. Dieses Thema hat Frank Buschmann auf der OOP in seinem Vortrag Was ein Software-Architekt wissen sollte ausgiebig ausgeleuchtet.

Wer außer dem Architekten kann denn beurteilen, ob eine Technologie notwendigerweise eingesetzt werden sollte oder vielmehr eine “Spielerei” ist, deren Einsatz für den Business Case nicht relevant ist. Die Schwierigkeit ist wie immer, die richtige Balance zu finden. Ob die Anforderung vom Produktmanagement, dem Endkunden, einem Servicetechniker oder einem der Entwickler definiert wurde, die wichtigste Grundlage die Anforderung umzusetzen ist der Kundennutzen. Andere Einflußfaktoren bei der Entscheidungsfindung sind

• Einsparmöglichkeiten
• das Ablösen von benutzten technischen Komponenten
• Innovationen

Bei der Beurteilung dieser Faktoren ist nicht nur das Produktmanagement sondern auch der Architekt gefragt: die Einführung einer neuen Installationsroutine ist nur dann sinnvoll, wenn der Servicetechniker die Installation oder ein Update in kürzerer Zeit durchführen oder mit weniger Fehlern durchführen kann. In diesem Fall kann man den Nutzen für die Firma wieder in Geld bemessen. Der Architekt hat die Verantwortung auszuschließen, daß hier eine Baustelle geöffnet wird, nur weil es ein neues Tool zur Programmierung eines Installers oder einen weiteren Packaging Mechanismus für Linux Distributionen gibt.

Der Architekt muß sich mit den aktuellen und relevanten Technologien auskennen und jederzeit überprüfen, ob die von ihm mitentwickelte Lösung nicht inzwischen durch eine Standardimplementation, ein OpenSource Projekt oder eine zugekaufte 3rd Party Komponente abgelöst werden kann. Das kostet Überwindung und und bedeutet notwendigerweise, daß der Architekt die notwendigen Soft-Skills benötigt, sein Team zu überzeugen, daß die eigene Implementation nicht mehr dem Stand der Kunst entspricht oder einfach nur deshalb abgelöst werden sollte, weil sich die Wartungskosten verringern.

Handelt es sich um ein besonders innovatives Thema, fällt es dem Architekten besonders schwer, den Kundennutzen zu bemessen. Wie soll er über etwas urteilen,was es so noch nicht gegeben hat? Der Bewegungssensor im iPhone, der vornehmlich ersteinmal dafür da ist automatisch den Bildschirm zu drehen, wenn man das Telefon in eine andere Position bringt, hat ein enormes Potential für neue Formen der Interaktion. Zuerst preschen natürlich die Spieleentwickler vor und nutzen einfach das gesamte Telefon zur Steuerung. Soll man dieses Konzept auf andere Anwendungsprogramme übertragen und ein Schütteln des Telefons nutzen, in einem Client den Serverzustand zu aktualisieren (Reload)? Ist das eine Spielerei, die ein verantwortungsvoller Architekt unterbinden sollte, oder ist es nur so möglich, alteingefahrene Wege zu verlassen und dem Kunden neue Erfahrungen zu vermitteln?

Orientiert sich die Entwicklung neuer Produkte nur an existierenden Anforderungen, werden anhand von Checklisten nur die Features der Konkurrenz nachgebaut. Ist die Produktentwicklung nur technologiegetrieben, besteht die Gefahr, daß man zwar der “First Mover” ist, sich das Produkt aber nicht verkaufen lässt. Deshalb ist es unabdingbar den Architekten in die Verantwortung zu nehmen, eine Balance zwichen Business Prioritäten, architekturellen Risiken und technologischen Innovationen zu finden.