Architektur

Es gibt wenige (Freiberufler-)Profile, wahrscheinlich gilt das auch für Bewerbungen, in denen sich ein Software-Entwickler nicht automatisch auch Software-Architekt nennt. Manch einer nimmt gleich auch noch Projektleitung in seine Skills auf, denn zumindest letzteres "kann ja wirklich auch jeder". Diejenigen, die dies wirklich mal (wenn auch im Kleinen), praktiziert haben, werden wissen, dass sich die Architektenrolle (insbes. bei größeren Projekten) von der Entwicklertätigkeit recht stark unterscheidet - und nicht jeder Instrumentalist ist auch ein guter Komponist, und umgekehrt ebenso wenig. Entwickler neigen dazu, Instrumentalist, Komponist und noch Dirigent in einem sein zu wollen.

Beim ersten Mal ist der Architektenhut zunächst einmal befremdlich, kommen neben den in der einschlägigen Literatur beschriebenen handwerklichen Fertigkeiten (Bausteine, Sichten, Pattern, usw.) noch ein paar ganz wesentliche nicht-technische Aspekte hinzu. An erster Stelle wäre da zu nennen die

Verantwortung für die Qualität der Software

Letztendlich ist der Software-Architekt im Wesentlichen für die Qualität der Software verantwortlich. Und schon ist er da, der fortan projektbegleitende Konflikt, denn wie heißt es so schön: "Qualität kostet", und bei dem Wort "kostet" erschrecken Projektleiter & Kunde - beide, immer! Der Software-Architekt muss also den Spagat zwischen diesen zwei Aspekten hinbekommen. Da an den Kosten unermüdlich von der dunklen Seite der Macht gearbeitet wird, sollte der Architekt eine starke Tendenz zur Qualität zeigen - und dazu benötigt er eine feste innere Überzeugung, Diplomatie und Durchsetzungstalent. Weiter wird man sehr bald konfrontiert mit den

Die wichtigen Entscheidungen

Zu Beginn eines Projekts müssen Entscheidungen getroffen werden, die den Rahmen für die gesamte weitere Entwicklung vorgeben. Dies sind jene Art von Entscheidungen, die sich im späteren Verlauf nicht bzw. nur äusterst aufwändig ändern lassen. Der weise Architekt weiß: Hierbei liegt "in der Ruhe die Kraft", auch wenn Kunde (und Projektleiter) bald mit der obligaorischen Frage kommen werden: "Wann kann man denn mal was sehen?". Häufig wird vorschnell mit einem Prototypen begonnen, der dann die Grundlage für die gesamte Software wird. An dieser Stelle ein Geheimtipp: Prototypen löschen, nochmals reflektieren, dann erst richtig starten. Ggf. ist gar ein ditter Start noch besser. Jeder kennt die Kurve, die die späteren Kosten von anfänglichen Designfehlern zeigt.

Die Unsicherheit am Anfang eines Projekts ist völlig normal und auch gut. Ich profitiere heutzutage sehr stark von Treffen mit Gleich- und (besser noch) Ungleichgesinnten, denn auch Architektur befindet sich im steten Wandel. Erst in gemeinsamen Diskussionen stellten wir z.B. probate Pattern wie MVC, Schichtenmodell, etc. in Frage, hielt man sie einst noch für unausweichlich.

Und trotzdem passiert es, dass sich während der Projektzeit herausstellt, dass manch anfängliche Entscheidung weniger gut war. Refactoring ja oder nein? Wie rein darf der Wein sein, den man dem Kunden einschenkt?

Das Schiff droht zu kentern

Eine wirklich schwierige Situation für den Architekten tritt meiner Erfahrung nach immer dann ein, wenn das Projekt im Laufe der Entwicklungzeit in Schieflage gerät. Eine typische und gefährliche Kombination kennt jeder: Wechselnde Anforderungen und fehlende Testabdeckung. Wenn man nicht aufpasst, ist die Software bereits vor der Version 1.0 verhunzt. Auch diese Problematik ist ein Belang, der wenig im Kontext von Architektur erwähnt wird. Dabei geht es hier doch um das sehr kostspielige Qualitätsmerkmal Wartung. Wie häufig unternimmt (allgemein) die Industrie Anstregungen, um 10%ige Einsparung zu erreichen. Bei der Wartung von Software sind Einsparungen von über 50% gar kein Thema, falls vernünftig vorgesorgt würde (s.auch Hoffnung).

Die Aufgabe, ein nachhaltig sauber arbeitendes Team zu formen, ist hingegen schwieriger als man denkt. Hat der Architekt seinen Hut deswegen aufbekommen, weil er einer der erfahrenste und sauberste Entwickler ist, so heißt dies natürlich noch längst nicht, dass sich sein Geist ganz von allein auf die Entwickler überträgt. Auch hier muss der Architekt organisieren (Meetings, Prozesse) und überzeugen können, denn, da die gemeine Entwickler-Diva "sehr vieles besser weiß", führt ein autoritäter Führungsstil nicht selten zu einem 9-2-5-Protest (s.auch Clean Code). Berechtigte Frage: Ist das nicht Aufgabe des Projektleiters? Es ging mir hier um die Betonung auf nachhaltig sauber. Ja, der Projektleiter sollte den Softwareentwicklungsprozess mitgestalten, aber das Bewusstsein und die Fertigkeiten für sauberes Arbeiten ist doch eher wieder ein Architektur-Belang.

Die politischen Spielchen

Und zu guter Letzt eine Frage, der man als Architekt immer nachgehen sollte ist: Wie ist das Projektumfeld eigentlich aufgestellt? Ohne die Hilfe von Stakeholdern auf Seiten des Kunden hat man wenig Chancen. Ist man z.B. ein externer Dienstleister, so kann man nicht automatisch Sympathie erwarten, vor allem nicht, falls das Unternehmen eine eigene interne IT betreibt.

Mit alle diesen Themen hat der Entwickler i.d.R. wenig zu tun - dessen sollte die/derjenige sich bewusst sein, bevor sie/er allzuschnell "ja" zu einem Architekturangebot sagt. Alternativ lässt sich überlegen, ob sich diese schwere Last nicht auf das Team verteilen lässt. Macht es beispielsweise Sinn, Architekutur-Entscheidungen demokratisch zu fällen? Dieses Theme wird zurzeit hitzig diskutiert und war u.a. ein Hauptthema der iSAQB-Architekturtage 2012 (s.u).

 

Weitere Quellen

iSAQB Verein zur Ausbildung und Zertifizierung zum Software-Architekten