Follow my new blog

Montag, 29. März 2010

Architekten programmieren nicht [OOP 2010]

Habe ich Ihre Aufmerksamkeit? Architekten programmieren nicht, ja das glaube ich – und stehe damit wohl gegen den (agilen?) Mainstream. Aber etwas “Gegenstrom” macht frisch und kregel ;-)

Wer etwas auf sich hält, sagt mal etwas zur Rolle des Architekten. Nach Lektüre eines weiteren Artikels von Neal Ford habe ich mir gedacht, darin sollte ich anderen nicht nachstehen. Also hier mal einige Gedanken zur Aufgabe des Architekten in der Softwareentwicklung.

Architekt als Rolle

Zunächst: Architekt ist für mich eine Rolle. Das ist ganz wichtig. Denn sonst wäre es unmöglich, dass sich kleinere Projekte einen Architekten leisten könnten. Idealerweise nimmt dann ein Projektbeteiligter (oder eine kleine Gruppe) die Rolle des Architekten ausschließlich ein – doch das ist eben nicht immer möglich. Also kann in kleinen Teams dieselbe Person sowohl Architekt wie noch etwas anderes sein.

Architekt als Schnittstellenfunktion

In Übereinstimmung mit vielen anderen bin ich sicher auch noch, wenn ich den Architekten als eine Person an der Schnittstelle zwischen anderen Projektbeteiligten sehe. Der Architekt ist insofern ein Übersetzer. Er hat Kontakt mit dem Kunden. Er muss mit der Projektleitung auf Augenhöhe sprechen. Er ist ein wichtiger technischer Ansprechpartner für das Entwicklerteam.

image

Ein Architekt muss daher ein gerüttelt Maß an Softskills besitzen. Er ist in ständigen Gesprächen und Verhandlungen. Er muss immer wieder auf dem Verständnisniveau seiner Gesprächspartner erklären. Er muss gut zuhören können. Er muss vermitteln/moderieren können. Und er braucht auch Durchsetzungskraft.

Architektur von Systemen von Funktionseinheiten

Ein Architekt hat aber natürlich nicht nur mit Menschen zu tun. Sein Metier ist die Software. Und da dreht sich seine Verantwortung ganz allgemein darum, Systeme von Funktionseinheiten zu entwerfen. Ja, genau so allgemeine denke ich das. Eine Funktionseinheit kann ein Betriebssystem Prozess (oder EXE) sein, das kann eine Maschine sein oder eine ganze Anwendung oder ein Cluster. In jedem Fall geht es um “Bausteine”, die Software sind oder Software ermöglichen, die zusammengeschaltet einen Kundennutzen bieten.

So allgemein möchte ich die Definition halten, um der ewigen Diskussion, was denn der Unterschied zwischen Application Architect und Enterprise Architect usw. sei, aus dem Weg zu gehen. Das sind einfach alles Architekten, die mit dem Entwurf von Funktionseinheiten zu tun haben, die nur eben auf unterschiedlichen Abstraktionsebenen liegen. Die Prinzipien sind jedoch auf allen Ebenen eher mehr als weniger gleich. Flexibilität und Effizienz müssen auch immer in Balance gehalten werden.

Und wenn Sie daraus jetzt lesen, dass dann doch jeder Entwickler auch Architekt sei, weil er Funktionseinheiten plane (allemal Klassen und Methoden), dann haben Sie Recht. Jeder Entwickler ist auch immer auf einer gewissen Ebene Architekt. (Manche nennen dann das, was er plant, Design statt Architektur, aber den Unterschied möchte ich grad mal vernachlässigen.)

Architektur als Abstraktion

Architekten gehen mit Funktionseinheiten um, Entwickler auch. Wo ist dann der Unterschied zwischen beiden?

Architekten planen, Entwickler bauen.

Das ist der entscheidende Unterschied. Er liegt wieder mal im Abstraktionsniveau. Architekten haben Überblick, Entwickler Detailblick. Architekten stehen auf einem Hügel und entwickeln Strategien, Entwickler führen aus.

Eine solche Aufgabenteilung halte ich für absolut natürlich und naheliegend. Führung und Ausführung sind zwei ganz unterschiedliche Tätigkeiten. Sozusagen unterschiedliche concerns der Softwareentwicklung.

Ein Dirigent führt ein Orchester, ein Musik spielt darin ein Instrument. Das heißt nicht, dass ein Dirigent kein Instrument spielen müsse. Im Gegenteil! Dirigenten sind immer ausgewiesene Instrumentalisten sogar auf mehreren Instrumenten. Aber während ein Dirigent dirigiert, spielt er (gewöhnlich) keines seiner Instrumente.

Daraus leite ich auch ab, dass ein Architekt eben nicht programmieren sollte. Zumindest nicht in dem Projekt, für das er Architekt ist. Das wäre ein Widerspruch zum Prinzip der Separation of Concerns, das auch auf Organisationen angewandt werden sollte.

Ein Architekt soll technisch absolut fit sein. Keine Frage! Er muss sich fit halten, er muss dem Team, das seine Architektur technisch auf Augenhöhe begegnen, er muss Erfahrung im Einsatz von Technologien haben, damit er sie planen kann. Dazu braucht es Praxis, Praxis, Praxis. Aber diese Praxis sollte ein Architekt sich nicht (!) in dem Projekt holen, in dem er Architekt ist.

Er mag im Pair Programming mit Entwicklern arbeiten – aber nicht als Driver. Er  mag Spikes entwickeln, um eine Architekturvision abzuklopfen. Er soll natürlich in Reviews eine sehr aktive Rolle spielen. Aber von Produktionscode sollte er die Hände lassen.

Der Grund ist ganz einfach: Wenn der Architekt seine Hände im Produktionscode schmutzig macht, gewinnt er soviel Detailwissen, verstrickt er sich so sehr im Tagesgeschäft, dass er seine Aufgabe als derjenige, der Überblick behält, nicht mehr erfüllen kann. Denn Überblick, Weitblick, Strategie: darum geht es bei Architektur. Bezogen auf die Abstraktionsebene soll der Architekt die Interessen des Großen Ganzen vertreten. Dazu braucht es jedoch Distanz von den nitty gritty details.

Architekt als Bewahrer

Und was ist das Große Ganze, für das der Architekt verantwortlich ist? Was ist das Ergebnis seiner Schnittstellenfunktion? Er grenzt sich zunächst von Projektmanagement oder auch einem ScrumMaster und ProductOwner ab, die auch das Große Ganze im Blick haben. Aber ganz untechnisch. Deren Interesse ist es, dass es voran geht. Die wollen nicht unter die Haube der Benutzeroberfläche einer Anwendung schauen. “Muss laufen!” ist ihr Credo. (Wobei der ScrumMaster sogar noch weniger Anspruch hat. Ihm geht es nur darum, dass das Vorgehensmodell korrekt gelebt wird. Wohin damit dann gegangen wird, ist ihm eigentlich egal.)

Der Architekt ist also der technische “Großverantwortliche”. Er muss den Einsatz von Technik und technischen Konzepten so planen, dass sie die Kundenwünsche erfüllt. Er wie die anderen ist er dabei selbstverständlich dem Zeit- und Kostenrahmen verpflichtet.

Konkret ist die Aufgabe des Architekten, dass die folgenden Aspekte von Software im Sinne des Kunden ausgeprägt und in Balance sind:

  • Nützlichkeit
  • Benutzbarkeit
  • Belastbarkeit
  • Evolvierbarkeit

Zu dieser Liste hat mich die Alte Definition von (Bau)Architektur in Wikipedia inspiriert. Nach der beruht Architektur auf drei Prinzipien: Stabilität, Nützlichkeit und Anmut (firmitas, utilitas, venustas).

Software ist kein Bauwerk. Also geht es bei Softwarearchitektur auch um anderes als Bauarchitektur. Dennoch glaube ich daran, dass Softwarearchitektur genauso scharf definiert werden sollte. Diese Aspekte scheinen mir das so zu leisten, dass keiner wegfallen darf und keiner mehr dazu kommen muss. (Oder habe ich eine –keit übersehen?)

Nützlichkeit: Software hat nur einen Zweck: Dem Kunden zu nutzen nach seinen Anforderungen. Das technisch sicherzustellen, ist die vornehmste Aufgabe des Architekten. Software die nicht nutzt, ist ihr Geld nicht wert. Nützlichkeit ist hergestellt, wenn die funktionalen Anforderungen wie auch nicht funktionale Anforderungen erfüllt sind. Nur wenn die Software tut, was sie tun soll, wenn sie das schnell genug tut und sicher genug usw., dann nützt sie. Darauf ist das System der Funktionseinheiten und die Nutzung von Technologien auszurichten.

Benutzbarkeit: Alle Nützlichkeit nützt nichts, wenn sie dem Anwender nur schwer zugänglich oder verständlich ist. Den Architekten sehe ich daher – vielleicht etwas untypisch – in der Verantwortung, die Usability im Blick zu behalten. Er muss das Team immer wieder dazu anhalten, Funktionalität nicht nur irgendwie auf die Straße zu bringen, sondern in einer Weise, dass sie dem Anwender auch “ohne Verrenkungen” zur Verfügung steht. Dem Kunden (ProductOwner) kann es nicht überlassen werden, schon bei der Anforderungsdarlegung oder durch Nörgeln beim Test von Releases Usability einzufordern. Die Softwareentwicklung selbst muss davon eine Vision haben – und die vertritt der Architekt.

Belastbarkeit: Software läuft nicht immer nur in Schönwetter. Benutzerzahlen steigen ungeplant, Datenvolumina nehmen unerwartet zu, Angreifer suchen nach Schlupflöchern, Anwender gehen unsachgemäß mit ihr um, Hardware fällt aus… Software ist vielen Belastungen diesseits und jenseits expliziter Kundenanforderungen ausgesetzt. Der Architekt muss das voraussehen und seine Planung angemessen darauf abstellen. Er  muss Toleranzen “einrechnen” und Spielräume schaffen. Dazu ist natürlich Erfahrung nötig – aber keine Glaskugel ;-) Belastbarkeit bedeutet, dass Software ihre Nützlichkeit auch über die unmittelbaren Anforderungen hinaus behält oder mit wenig Aufwand wiedergewinnen kann.

Evolierbarkeit: Zuguterletzt ist der Architekt dafür zuständig, über die Anforderungen des Kunden heute hinaus zu sehen. Zumindest er muss das Verständnis haben, dass Software sich ständig wandelt und daher eine Struktur haben muss, die sich an solchen Wandel immer wieder leicht anpassen lässt. Ein Architekt kennt den Kunden insofern besser als der sich selbst ;-) Auch wenn der Kunde meint, alle Wünsche geäußert zu haben, weiß der Architekt, dass das hochwahrscheinlich nicht der Fall ist – und muss seine Architektur (angemessen) flexibel halten. Software soll dem Kunden nicht nur heute dienen, sondern auch morgen und übermorgen. Evolvierbarkeit ist die Bedingung für die Möglichkeit zukünftiger Nützlichkeit.

Zur Evolvierbarkeit gehört auch, dass Veränderungen nicht nur möglich sind, sondern das auch mit vertretbarem Aufwand. Allemal hier schwingt also auch die Produktionseffizienz als Aspekt mit. Speziell herausgehoben habe ich sie jedoch nicht, da sie ansonsten der allgemeinen Verantwortung des Architekten unterliegt, der – wie die anderen Projektverantwortlichen auch – darauf achtet, dass mit Zeit und Geld sorgsam umgegangen wird.

Und ein Wort noch zur Korrektheit: Nützlichkeit schließt Korrektheit ein. Deshalb habe ich die Korrektheit nicht in dieser Verantwortlichkeitsliste ausdrücklich aufgeführt. Sie ist so grundlegend, dass sie eigentlich keiner Erwähnung bedarf. Ohne die Möglichkeit, Korrektheit jeder Funktionseinheit “auf Zuruf” belegen (oder zumindest überprüfen) zu können, ist das Ergebnis der Planung eines Architekten nicht wirklich Architektur zu nennen. Nützlichkeit und Evolvierbarkeit sind ohne Korrektheit bzw. ihre ständige systematische und damit automatisierte Prüfung nicht denkbar.

Der Architekt plant eine Software, d.h. ein System aus Funktionseinheiten, so, dass die Aspekte Nützlichkeit, Benutzbarkeit, Belastbarkeit und Evolvierbarkeit im Sinne absehbarer Kundenanforderungen ausbalanciert sind. Das ist keine leichte Aufgabe. Sie erfordert viel Erfahrung und technisches Know-How.

Vor allem erfordert sie aber eben ein strategisches Denken, das sich nicht gemein machen darf mit Codierungsdetails. Deshalb glaube ich ganz fest, dass ein Architekt nicht in seinem Architekturprojekt programmieren sollte. Er verliert sonst die Distanz, die nötig ist, um sich für diese vier wichtigen Aspekte gegen den Druck zu stemmen, den unweigerlich Projektmanagement, Kunde und Team auf ihn ausüben.

Kommentare:

Thomas hat gesagt…

Hallo Ralf,

2 Anmerkungen.

1. Dein Diagramm ist etwas irreführend. Oder soll das Projektmanagement nur über den Architekten mit dem Kunden kommunizieren? ;-)

2. Der Architekt als Usability-Experte? Sorry, aber das kann nicht gut gehen (Ausnahmen bestätigen die Regel).

Schuster bleib bei deinen Leisten ... heißt, da sollen sich Leute darum kümmern, die sich damit auskennen - eben Usability-Experten, im Zweifel ist das am ehesten ein (Web-/Interface-) Designer. Ein Punkt, der leider aus dem eher technischen Betrachtungswinkel häufig vernachlässigt wird und zu Software und Websites/Webanwendungen führt, wie man sie als Benutzer eben kennt (und verflucht).

Gruß, Thomas

Ralf Westphal - One Man Think Tank hat gesagt…

@Thomas: Nein, das Team darf gern mit dem Kunden direkt kommunizieren. Aber in technischen Dingen, die das Ganze betreffen, muss der Architekt für Entscheidungen hinzugezogen werden.

Dabei geht es nicht um Micromanagement durch den Architekten, sondern darum, dass Missverständnisse vermieden werden, Moderation möglich ist und das Big Picture nicht aus den Augen verloren wird.

Der Architekt ist kein allwissender und allmächtiger Steuerer. Er ist nicht der Homunkulus im Kopf des Projektes. Er ist vielmehr derjenige der sicherstellt, dass der "Tonus" des Projektes stimmt. Insofern ist er eine "balancierende Kraft".

Und natürlich soll ein Webdesigner oder wer immer konkret die Usability herstellen. Aber es muss auch hier einer überhaupt den Willen zur Usability haben und den Fortschritt verfolgen. Das kann nicht der Webdesigner sein. Der führt aus, ist im Konkreten kreativ. Aber die Vision von Usability, dass (!) sie überhaupt existiert, dass sie nicht einfach so anderem geopfert wird, dafür ist der Architekt zuständig.

Wie beim Bau: Der Architekt mauert nicht und ist kein Glaser. Aber er hat die Vision davon, wie Mauern und Glasfassaden aussehen sollen.

-Ralf

Thomas hat gesagt…

Zur Usability:

Ich denke genau da hinkt der Vergleich mit einem "echten" Architekten. Wenn ich einem Techie die Verantwortung über die Usability einer, sagen wir Website, überlasse, dann bin ich verlassen (natürlich muss er in die Prozesse einbezogen werden, irgendwer muss ja auch mal Stop sagen, wenn etwas technisch nicht umgesetzt werden kann, was da entworfen wird).

Das ist einfach meine Erfahrung aus dem Pendeln zwischen beiden Welten (der der Pixelschubser und der der Entwickler).

Aber ich lasse dir deine Meinung, bin ja froh dass du sie kund tust :-) :-) :-).

Ralf hat gesagt…

Hallo,

ich stimme absolut mit deiner Schlussfolgerung überein. Aber wie geht man mit Situationen um, in denen das Team sehr klein ist und nur aus 3-4 Entwicklern besteht?

Aus meiner Sicht hat man dort zwangsläufig schlechtere Karten, da man nur einen "Teilzeitarchitekten" aufstellen kann. Dafür ist das Projekt üblicherweise auch nicht so groß dimensioniert.

Ist die Architektenrolle überhaupt effektiv auf ein Team (von Entwicklern) aufteilbar?

Grüße,
Ralf C.

Ralf Westphal - One Man Think Tank hat gesagt…

@Ralf C.: Mir war es wichtig über die Architektenrolle zu sprechen, nicht eine Person.

In einem kleinen Team macht das natürlich Probleme, wenn die Personen in Personalunion mehrere Rollen ausfüllen müssen.

Was kann da helfen?

1. Die Anerkenntnis dessen, dass es überhaupt Rollen gibt, die ganz eigene Interessen vertreten.
2. Stetiges Üben von Bewusstheit als Individuum und Team. Nur dann hat man eine Chance, zwischen Rollen zu trennen.
3. Zumindest gelegentlich von außen Reflexionhilfe einholen, da bei allem Bemühen um Bewusstheit blinde Flecken bleiben. Die sind umso größer, je kleiner das Team ist.

Bei gegebener Rollendefinition für einen Architekten kommt es also vor allem auf Softskills an, um die Mehrfachrollen in kleinen Teams zu kompensieren.

-Ralf

Thomas Kratz hat gesagt…

Hallo Ralf,

ich frage mich echt wie das gehen soll, der Architekt soll nicht mitprgrammieren aber trotzdem soll er technisch absolut fit sein. Für mich ist das ein Widerspruch in sich. Ich hatte öfters solche Architekten und ich hab keinen von Ihnen ernst nehmen können. Der architekt muss in Sachen Technik dem Team vorangehen und er muss soziale Kompetenz haben, eine Kombination die man IMHO äusserst selten findet. Die meisten Architekten die ich erlebt habe sind mir nur auf den Keks gegangen, waren Wichtigtuer oder beliebt beim Chef. Wenn ich selbst in der architektenrolle war, habe ich immer versucht mit guten Codebeispielen voranzugehen, habe dafür gesorgt das der Technikstack rebiungslos funktioniert und ich würde das auch jederzeit wieder so machen.

Ralf Westphal - One Man Think Tank hat gesagt…

@Thomas: Ich habe nicht gesagt, dass ein Architekt nicht programmieren können soll oder nicht programmieren soll.

Mir geht es um eine "Separation of Concerns": Ein Architekt soll im Projekt, für das er Architekt ist, nicht programmieren. Er kann sonst seine Architektenziele nicht sauber vertreten, sondern gerät immer wieder in Interessenkonflikte.

Ein Architekt soll technisch sehr kompetent sein. Er soll Implementierungserfahrung haben und auch ständig ausbauen. Nur eben nicht als Mitprogrammierer in einem Projekt.

Dass das oft nicht geht, mag so sein. Das macht es nur nicht besser, sondern kann eben ein erster "project smell" sein. Im Projekt mitprogrammierende Architekten sind für mich ein Anti-Pattern. Und als solches soll es vor allem erstmal das Bewusstsein schärfen und vorsichtig machen.

-Ralf