Die Berufsbezeichnung Architekt innerhalb der Softwareentwicklung wird mittlerweile inflationär verwendet. Was früher beispielsweise als Programmrahmen bezeichnet wurde, heißt heute Mikroarchitektur, der Begriff "Design at Large" meint eine Softwarearchitektur und "Enterprise-Architektur" das ganze Unter-nehmen. Es gibt keine Designer mehr, sondern nur noch Architekten. Deren Aufgabengebiet gleicht einem Sammelbecken für alle möglichen Design- und Implementierungsrollen, die sich immer weiter spezialisieren. In Jobbörsen suchen Firmen heute Mitarbeiter für neue Berufsbilder wie etwa einen J2EE-Architekten, C#-Architekten, .NET-Architekten oder Data-Warehouse-Architekten.

Natürlich schmücken sich Softwarespezialisten ihrerseits mit dem Titel Architekt. Angeblich schafft es dieser technologische Tausendsassa, in die untersten Tiefen der Programmiersprache vorzudringen und gleichzeitig den Überblick über jedes System zu behalten. In der deutschsprachigen Literatur über Softwarearchitektur reicht das Anforderungsprofil vom Projekt-Management über Mitarbeiterführung, Kommunikation, kommerzielles Denken und Abstraktionsvermögen bis zur Didaktik und Erwachsenenpädagogik. Der Architekt fungiert als eine Art Supermann der Softwareentwicklung. Spötter behaupten auch, er treffe die meisten Entscheidungen, übernehme aber keinerlei Verantwortung.

Doch wie sieht die Realität aus? Die Studiengänge und Architekturkurse vermitteln den Studenten und Teilnehmern Methoden, um Software quasi auf der grünen Wiese zu bauen. Konzepte wie "Architektur", Effektivität, Ro-bustheit oder auch Performanz werden mit dem Fokus auf die Synthese und selten im Hinblick auf die Analyse vermittelt.

Mängel in der Ausbildung

Die Auseinandersetzung mit der tatsächlich eingesetzten Software gilt als unattraktiv und wird selten gelehrt. Diese Vorgehensweise steht in kras- sem Gegensatz zu anderen Gebieten, die sich mit Architektur beschäftigen, etwa dem Bauingenieurwesen, dem Städtebau oder der klassischen Architektur. Dort gilt es als Pflicht, beste- hende Objekte eingehend zu studieren, um aus der Vergangenheit zu ler- nen. Nicht so in der Softwareentwick- lung. Hier werden stets neue Methoden und Architekturen entwickelt, um neue Applikationen zu schaffen. Alles bisher Genutzte gilt plötzlich als überholt. Indem wertvolle Erfahrungen weder tradiert noch angesammeltes Wissen über Softwareentwicklung genutzt wird, wiederholen sich ständig gleiche Fehler.

Das Ziel sollte deshalb nicht sein, stets neue Software zu entwerfen - die Architekturverfechter würden jetzt sagen: eine gute Architektur ermöglicht Wiederverwendung - , das Ziel muss es sein, die bestehende Software besser zu nutzen und weiterzuentwickeln. Wenn eine Software seit 30 Jahren läuft, spricht das für ihre Entwickler. Diese Altsysteme haben auch eine Architektur, deren Struktur aber viele moderne Architekten nicht erkennen können, weil sie sie nie gelernt haben. Erstaunlich ist allerdings, dass über 80 Prozent der Software in Cobol geschrieben sind und nur die wenigsten Architekten diese Programmiersprache beherrschen.

Selbst wenn man die Altsysteme außer Acht lässt, stellt sich die Frage: Was zeichnet eine gute Architektur aus? Ohne quantifizierbare Größen wie Flexibilität, Volatilität, Effizienz oder Performanz lässt sich eine Architektur nicht bewerten. Quantifizierbare Größen fehlen sowohl innerhalb eines Unternehmens als auch in ganzen Industriezweigen. Deshalb sollten Benchmarks für Softwarearchitektur geschaffen werden. So lange diese Messgrößen fehlen, darf sich weiterhin jeder ungestraft Architekt nennen. (iw)