Was unterscheidet Softwarearchitekten von Entwicklern?

Gretchenfrage 2.0: Sind Sie Architekt oder Entwickler?

Stefan Zörner

In Softwarearchitekturseminaren werde ich regelmäßig gefragt, was meiner Meinung nach der Unterschied zwischen einem Architekten und einem Entwickler sei. In Anbetracht meiner oft sehr heterogenen Teilnehmergruppen ist das pauschal nicht leicht zu beantworten. Denn unterschiedliche Unternehmen, Organisationen und Projekte leben die Rollen Softwarearchitekt und Entwickler sehr unterschiedlich.

Unterschiedliche Rollenverständnisse sind oft der Anfang von Unklarheiten. In einigen Projekten entwickeln Softwarearchitekten überhaupt nicht (mehr) selbst, sondern planen, entscheiden, entwerfen und überwachen die Entwicklung nur noch entsprechend. In Unformen kann dies zu einer geringeren Wertschätzung für Entwickler innerhalb der Organisation führen. Wer was werden will, wird Architekt. Dazu muss er verlernen zu programmieren – das berüchtigte Antipattern „Architects don’t code“ [1]. Ich habe ab und zu Teilnehmer in meinen Seminaren, die sich Richtung Architektur entwickeln wollen, weil sie sich einen Aufstieg innerhalb ihrer Organisation davon versprechen – höheres Ansehen und/oder höheres Gehalt.

Andernorts, insbesondere in kleineren Projekten, werden die Verantwortlichkeiten eines Softwarearchitekten ganz agil von Entwicklern mit übernommen. Explizite Architekten gibt es nicht. Architekturentscheidungen treffen die erfahrensten Entwickler im Team. Open-Source-Projekte zelebrieren diese Denkweise durch Diskussionen und Abstimmungen auf Mailing-Listen. Die Apache Software Foundation nennt dies Meritocracy, die Herrschaft der Verdienten.

Einige Organisationen schieben noch Rollen zwischen Architekt und Entwickler, z. B. Designer, oder legen sie quer drüber (Tester) oder darunter (Tester, aber andere Organisation).

Was ist Softwarearchitektur?

Ganz ähnlich, wie bei der Rolle des Softwarearchitekten ein einheitliches Verständnis fehlt, gibt es auch keine allgemein akzeptierte eine Definition des Begriffs „Softwarearchitektur“. Ein besonders griffiger Ansatz erklärt Architektur als Summe wichtiger Entscheidungen, die im weiteren Projektverlauf nur schwer zurückzunehmen sind. Wer diese Entscheidungen nachvollziehbar herleitet und verantwortet, der entwirft die Architektur. Ganz gleich, ob dies eine Person oder mehrere tun, und ob er oder sie sich Architekt nennt oder nicht. Der Übergang zwischen Architektur und Design ist ohnehin nicht trennscharf.

Bei dieser Bandbreite von Rollen- und Begriffsverständnissen ist es offensichtlich unmöglich, die ursprüngliche Frage – Was unterscheidet den Architekten vom Entwickler? – allgemeingültig zu beantworten. Meinen Teilnehmern liefere ich als Antwort daher stets ein Bild, das die Rollenbegriffe zunächst vermeidet und einen Aspekt fokussiert, der alle in unserer Branche angeht.

Modell T

Vereinfacht können wir jeden als T-förmig betrachten, der Softwarevorhaben mit umsetzt, ganz gleich ob Architekt, Entwickler, DB-Spezialist etc. – Abstraktion bewältigt Komplexität.

Damit ist gemeint, dass seine (oder ihre) Skills sich so darstellen lassen wie in Abbildung 1. Man führt in der Horizontalen alle Themen – Technologien, Notationen, Methoden – auf und trägt in der Vertikalen den jeweiligen Skilllevel ein (von Novize bis Master). Jeder wird zumindest ein bestimmtes Thema als sein Standbein betrachten. Das ist der Fuß des Ts. In den allermeisten Themen wird man jedoch bestenfalls über Basiswissen verfügen, z. B. gerade einmal einordnen können, was das ist. Das ist der Rest des Querbalkens.

Abb. 1: Der Mensch als T

Eins ist unstrittig: Im Zeitalter des schnellen Wandels in den Technologien ist lebenslanges Lernen unabdingbar, um am Markt bestehen zu können. Wer nicht zurückfallen möchte, bildet sich weiter.

Spezialist bleiben?

Ein Spezialist hält sein IT-Wissen tendenziell vor allem so auf dem aktuellen Stand, dass er an sein vorhandenes Expertenwissen anknüpft. Er liest z. B. Fachartikel aus diesem Themenkomplex, die neue Trends in dem Bereich aufzeigen, verfolgt Blogs und Tweets von einschlägigen Koryphäen und dergleichen mehr.

Abb. 2: Spezialisten-T

Wenn er beispielsweise ausgewiesene Kenntnisse in Java-Webapplikationen besitzt, und ein neues Webframework erscheint auf der Bildfläche, wird er es sofort begierig herunterladen und ausprobieren. Er wird es mit Lösungen vergleichen, die er bereits kennt, und so sein Spezialwissen im Bereich Java-Webapplikationen verbreitern bzw. up to date halten (Abb. 2). Aber eben auch nur genau das.

Viele Entwickler verhalten sich so. Java-Programmierer z. B. interessieren sich tendenziell überhaupt nicht für die .NET-Welt und umgekehrt.

Geschrieben von
Stefan Zörner
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.