Gibt es wirklich keine Zukunft für Software-Architekten? Ilker Cetinkaya hat in seinem Blog-Artikel so geurteilt.
Wohlgemerkt meint er die Rolle bzw. Position des Software-Architekten, nicht den Aspekt Software-Architektur. Im Gegenteil!
"[Ich empfinde] es als absolut notwendig, die Aufgaben der Architektur nicht auf Positionen oder Personen zu restriktieren, sondern sie als allgemeines Aufgabenfeld in der Software-Entwicklung zu betrachten."
"Schlußendlich sollte es in einem agilen Team meiner Auffassung nach das Ziel sein, auch die Aufgaben der Architektur gemeinschaftlich im Team umzusetzen. "Ich finde Ilkers Beitrag besonnen. Sein Standpunkt gefällt mir. Ich sehe es grundsätzlich genauso. Deshalb ist mir auch wichtig, mit einem Training wie dem für Agile Architektur Entwickler zu adressieren. Wenn alle zusammensitzen und Architektur planen, kommen mehr Ideen zusammen, das geteilte Verständnis für die Architektur steigt und das gemeinsame Verantwortungsgefühl für das Ergebnis ist höher.
Nichts schlimmer als Astronautenarchitekten, die keinen Bezug zur Entwicklung mehr haben. Nichts konfliktträchtiger als Architekturen, die nach dem Motto "friss oder stirb" über einen Organisationszaun den Entwicklern vor die Tastaturen gekippt werden. Die Entfremdung zwischen Architektur und Anforderungen und Code lauert überall.
Und dennoch... Ein bisschen zucke ich noch bei Ilkers Ergebnis. Weil ich fühle, dass was Ilker beschreibt, für mich an den Persönlichkeiten und Kompetenzen der real existierenden Entwickler vorbeigeht. Ich zucke, weil ich eine Differenz zwischen Wollen und Können sehe.
Viele wollen das, was Ilker beschreibt. Es klingt in der Sache richtig und es hat Appeal für die Persönlichkeit vieler Entwickler, die pragmatisch sind und sich nicht lange mit Organisation aufhalten wollen. Sie sind sensibel für die Verluste, die Distanz zwischen den Beteiligten erzeugen kann.
In meiner Beratungs- und Trainingspraxis sehe ich dann allerdings, dass eben nicht alle Entwickler gleich sind. Sie unterscheiden sich in ihrer technischen Kompetenz, sie unterscheiden sich in ihrer Methodenkompetenz, sie unterscheiden sich in ihrem Charakter und in ihren Bedürfnissen. Und das ist ja auch gut so. Teams, die gemischt zusammengesetzt sind, liefern bessere Ergebnisse.
Verschiedenartigkeit ist grundsätzlich zu begrüßen - sie führt aber auch zu Konflikten und es bleiben blinde Flecken. Wie wird das kompensiert? Wer führt Konflikte zu einem Ergebnis? Wer leuchtet blinde Flecken aus?
Für die Konflikte gibt es Moderatoren. Das weiß inzwischen jeder. Die können aus einer Gruppe kommen oder von außen. Sie stellen sicher, dass Gruppentreffen eine zielführende Form haben. Moderator ist gewöhnlich 1 Person. Dass eine Gruppe sich selbst durch gleich verteilte "Eingriffe" aller Mitglieder moderiert, ist eher selten. Meist gibt es einen de facto Moderator, der nicht mal ausgebildet sein muss. Dennoch erkennt ihn die Gruppe an.
Dieses Muster ist akzeptiert. Im besten Fall dominiert dieser Moderator die Gruppe nicht, sondern kann eine Balance halten zwischen seinem Mitgliedsstatus und seiner Moderatorenrolle. Er ist nur temporär Erster unter Gleichen in Bezug auf eine Aufgabe.
Ein Moderator verkörpert den Aspekt "Kommunikationsform", ohne dessen Berücksichtigung das Ergebnis einer Besprechung schnell suboptimal ausfällt.
Ich denke auch, wir können uns darauf einigen, dass nicht jeder die Rolle eines Moderators gleich gerne und/oder gut ausfüllt - selbst wenn der Aspekt allen Gruppenmitgliedern wichtig ist. Es braucht dafür eben eine gewisse Kompetenz.
Und wer leuchtet blinde Flecken aus? Die gibt es ja unweigerlich und sei es nur temporär. Wenn die Diskussion hoch her geht, dann fällt der eine oder andere Aspekt gern mal unter den Tisch. Ein Übriges tut dann das Tagesgeschäft mit seinem Druck in Richtung bestimmter Aspekte - und Ignoranz gegenüber anderen.
Einer dieser Aspekte ist aus meiner Sicht die Architektur. Architektur ist ein nicht-funktionaler Aspekt der Softwareentwicklung. Und darüber hinaus auch noch einer, dessen Qualität nicht so schnell zu einem Feedback vom Kunden führt. Wenn die Performance der Software nicht stimmt oder die Usability, dann sagt steht der Kunde sehr schnell auf der Matte. Rückkopplungszeit Stunden oder Tage.
Wenn aber die Architektur nicht stimmt... dann ist die Rückkopplungszeit Wochen, Monate oder gar Jahre. (Ja, ich glaube, man kann nicht-funktionale Anforderungen wie Performancelimits erfüllen, auch wenn die Architektur suboptimal ist. Das passiert sogar häufig.)
Weil nun die Rückkopplung bei der Architektur vergleichsweise lange auf sich warten lässt, fällt sie leicht unter den Tisch. Manager haben dafür oft wenig Sinn. Sie sind es aber, die sich letztlich durchsetzen. Jedenfalls normalerweise. Heute noch ;-)
Bei gegebener schlechter Ausbildung in puncto Softwareentwurf - das schließt für mich Architektur ein - und gegebenem Tagesgeschäftfokus ist für mich die Realität von Teamsitzungen, dass Architektur schnell zu einem blinden Fleck wird. Nicht sofort, nicht immer, aber tendenziell.
Dazu kommt, dass die Kompetenzen, die für den Entwurf von Software-Architektur nötig sind, nicht gleich verteilt sind bei Entwicklern. Es ist damit wie mit den Moderatorenkompetenzen. Das ist also ganz natürlich.
Und daraus leite ich nun wiederum ab, dass es wichtig ist, darauf zu achten, dass der Aspekt Software-Architektur verlässlich verkörpert wird.
Wie diese Verkörperung aussieht, ist mir egal. Es muss keine Position eines Software-Architekten geben. Es muss auch niemand zwangsläufig fix die Rolle eines Software-Architekten innehaben. An irgendwem muss das Thema jedoch hängen, glaube ich. Und zwar nicht am ganzen Team, sondern an einer Untermenge.
Alle sind mit der Plattform und der Domäne und hoffentlich Clean Code Developer ;-) vertraut. Jenseits dessen beginnen dann allerdings die Unterschiede. Es ist immer so, dass einer die GUI-Technologie besser beherrscht als andere. Und eine kann besser mit dem Build-Tool umgehen als andere. Und manche fühlen sich eher zum Umgang mit Datenbanken hingezogen als andere.
Genauso denkt eine konzeptioneller als andere. Und einem ist das big picture wichtiger als anderen.
Ich glaube, diese ganz selbstverständlichen Unterschiede sollten wir nicht leugnen. Wir sollten auch nicht glauben, sie wegschleifen oder auffüllen zu können. Dafür geht gerade das Thema Software-Architektur zu sehr an Persönlichkeitsmerkmale, die schon früh geprägt werden.
Um also nicht davon überrascht zu werden, dass das kollektive Kümmern um Architektur irgendwie nicht funktioniert hat, sollte jedes Teams schauen, dass es möglichst schnell herausfindet, wie es den Aspekt Architektur am besten verkörpert.
Manchmal mag es einen Entwickler geben, der sich den Schuh anzieht - und die anderen sind froh drüber, dass er sie beim Thema an die Hand nimmt. Manchmal mag es eine kleine Gruppe innerhalb des Teams sein. Oder vielleicht rotiert die Aufgabe durch das Team, so dass bei jeder Besprechung ein anderer das "Architektur-Gewissen" ist?
Eine andere Verkörperung muss natürlich in der Zeit stattfinden. Sie muss für alle Entwickler fester Bestandteil ihrer Wochenkalender sein. Das ist der erste Schritt.
In Summe helfen Experimente. Solange die dafür sorgen, dass die Verkörperung der Architektur nicht in eine außerkörperliche Erfahrung ;-) umschlägt, d.h. abhebt und entfremdet von Code und Anforderungen, solange ist alles erlaubt.
Software-Architektur geht alle an. Da bin ich ganz dabei. Allerdings möchte ich daraus ungern eine zwingende Form ableiten: weder eine Position des Software-Architekten, noch die komplette Abwesenheit jeder Rolle oder anderer Form von Kompetenzkonzentration oder Interessenverteilung. Architekturbewusstsein verkörpern, in geeigneter Form, darum geht es.
Solange am Ende das ganze Team ein solides Verständnis der Architektur hat und sie mitträgt, ist alles gut.
