---
title: Softwarearchitekt und Softwarecraftsman - ein Widerspruch? - JAXenter
source: https://jaxenter.de/softwarearchitekt-und-softwarecraftsman-ein-widerspruch-2207
---

Softwarearchitektur beschäftigt sich damit, ein Software-System in mehrere Komponenten zu zerlegen und die Beziehungen zwischen den Komponenten zu [definieren](http://de.wikipedia.org/wiki/Softwarearchitektur). Dies ist notwendig, da ein typisches Software-System so komplex ist, dass es ohne eine solche Aufteilung nicht verständlich ist. Das Ziel ist es also, einzelne Komponenten so zu wählen, dass sie isoliert verstanden werden können. Außerdem kann durch die Softwarearchitektur die Beziehungen der Komponenten untereinander definiert und verstanden werden – das “Big Picture”.

Für eine sinnvolle Architektur müssen Komponenten anhand der funktionalen Zuständigkeiten und Anforderungen strukturiert werden. Beispielsweise könnten in einer Geschäftsanwendung Komponenten für die Handhabung des Kunden oder der Aufträge identifiziert werden. Schließlich ist die Umsetzung solcher Anforderungen in einem Software-System der Grund, dass das System überhaupt implementiert wird. Eine Architektur anhand dieser Elemente erlaubt die einfache und effiziente Umsetzung der fachlichen Anforderungen. Leider wird in der Praxis oft eine Aufteilung ausschließlich anhand technischer Zuständigkeiten wie Persistenz oder GUI gewählt. Als zusätzliche Strukturierung neben der Strukturierung durch fachliche Anforderungen ist das sinnvoll – nicht jedoch als Ersatz für eine fachliche Struktur.

Ebenso hat die Architektur entscheidenden Einfluss darauf, wie nicht-funktionale Anforderungen umgesetzt werden. In der Architektur werden auch rein technische Komponenten und Basistechnologien definiert – also beispielsweise eine Auswahl von Frameworks oder Application Servern. Außerdem müssen die definierten fachlichen Komponenten geeignet technisch umgesetzt werden. So kann eine Komponente beispielsweise als Web-Anwendung implementiert werden. Die richtige Wahl solcher Ansätze und Technologie ist entscheidend, wenn es um nicht-funktionale Anforderungen wie Performance, Sicherheit oder Wartbarkeit geht.

Damit entsteht die Architektur also im Spannungsfeld zwischen der fachliche Domäne und der technischen Umsetzung. Schließlich wird am Ende der Erfolg der Software an der Erfüllung der Anwendungsfälle gemessen. Im Gegensatz zum Requirements Engineering geht es aber nicht darum, die Anforderungen detailliert zu beschreiben und festzulegen, sondern es werden die Grundlagen für eine konkrete Implementierung geschaffen.

Damit ist eigentlich auch klar, was ein Softwarearchitekt tut: Er definiert die Architektur und sorgt dafür, dass sie auch entsprechend umgesetzt wird. Damit ist er letztendlich dafür verantwortlich, dass die nicht-funktionalen Anforderungen eingehalten werden – und natürlich auch die Umsetzung der funktionalen Anforderungen, sofern sie zuvor sinnvoll erfasst worden sind. Wegen der nicht-funktionalen Anforderungen muss er zum einen die Technologien verstehen – aber auch die Domäne und die Anwendungsfälle wegen der funktionalen Anforderungen. Dieses Verständnis gilt es nun, auf den Prüfstand zu stellen.

### Unterschiedliche Interpretationen der Architektenrolle

Typischerweise wird die Rolle des Architekten unterschiedlich interpretiert und umgesetzt. Das Spektrum reicht von Architekten, die ingenieurhaft mit Modellen einen wichtigen Beitrag leisten, bis zu Architekten, die als Lead Developer mit am Code arbeiten.

#### Der Powerpoint-Architekt

Dieser Softwarearchitekt plant und entwirft die Architektur des zu entwickelnden Systems. Dazu erstellt er in frühen Phasen des Projektes Modelle, die wichtige Architektur-Entscheidungen kommunizieren. Diese Entscheidungen berücksichtigen die gegebenen funktionalen und nicht-funktionalen Anforderungen. Um dies zu tun, arbeitet der Architekt in der Regel eng mit dem Projektmanager, Product Owner oder Srcum Master zusammen. Ein wichtiges Element der Architekturentscheidungen sind deren Begründungen (englisch: rationale) \[1\]. Diese Begründungen helfen die Entscheidungen in späteren Phasen nachzuvollziehen. Der Architekt trifft diese wichtigen Entscheidungen, so dass andere Teammitglieder diesen folgen können. Die Teammitglieder können so auch von der Erfahrung und Kompetenz des Architekten profitieren.

Die beschriebene konzeptionelle Arbeit ist gerade am Anfang eines Projektes sehr wichtig. Die Arbeit eines Architekten darf aber an dieser Stelle nicht enden, deswegen auch die zugespitzte Bezeichnung Powerpoint-Architekt. Ein anderer wichtiger Punkt ist die konzeptionelle Integrität, die durch den Architekten sichergestellt werden muss. Integrität stellt aber meist am Anfang des Projektes kein großes Problem dar. Schwierig wird es erst dann, wenn sich Änderungen ergeben, die nicht zur realisierten Architektur passen. Der Architekt muss dann entscheiden, ob ein Kompromiss zugunsten eines straffen Zeitplans oder wichtigen Kundentermins akzeptable ist. Vielleicht muss aber die bestehende Architektur erweitert oder geändert werden. Das Ändern der Architektur ist in der Regel jedoch mit großen Aufwänden verbunden. Dennoch sollte der Architekt derartige Investitionen mit ihren Vor- und Nachteilen identifizieren, gegebenenfalls empfehlen und deren Umsetzung unterstützen.

Auch während der Implementierung werden Entwurfsentscheidungen getroffen. Die Summe dieser vielen kleinen Detailentscheidungen hat großen Einfluss auf die Gesamtarchitektur des Systems. Wenn der Architekt nicht eng mit den Entwicklern in dieser Zeit zusammenarbeitet, ist er hiervon ausgeschlossen und könnte keinen Einfluss nehmen. Nur durch die Enge kooperation mit den Entwicklern erhält der Architekt das notwendige Feedback, um seine Entscheidungen zu validieren. Einerseits will er sicherstellen, dass diese tatsächlich umgesetzt werden und andererseits will er erkennen, wo eventuell Anpassungen notwendig werden.

Entwurf und Implementierung sind zwei Seiten ein und derselben [Medaille](http://c2.com/cgi/wiki?ArchitectsDontCode). Ein Architekt kann nicht ohne Programmierkenntnisse über technische Details urteilen und er kann keine guten Designentscheidungen fällen, wenn er deren spätere Implikationen nicht kennt. Und umgekehrt, kann ein Entwickler keine „[gut gefertigte Software](http://manifesto.softwarecraftsmanship.org/#/de)“ ohne Kenntnisse über Design und Architektur [erstellen](http://c2.com/cgi/wiki?TheSourceCodeIsTheDesign). Architektur- und Designentscheidungen sollten somit keine Elite-Aufgaben sein, die ausschließlich vom Architekten getroffen werden. Stattdessen sollte der Architekt versuchen von den Fähigkeiten und Spezialkenntnissen aller Teammitglieder zu profitieren, in dem er diese in die Entscheidungsfindung miteinbezieht und eine moderierende Rolle innerhalb des Teams übernimmt.

\[ header = Seite 2: Der Architekt als Softwarecraftsman mit Meisterbrief \]

### Der Architekt als Softwarecraftsman mit Meisterbrief

Sich an der Implementierung zu orientieren, ist auch in anderen Bereichen ein Trend. Softwarecraftsmanship ist eine Bewegung, die das Niveau der professionellen Softwareentwicklung heben will. Die Softwareentwicklung wird in diesem Zusammenhang als anspruchsvolles Handwerk verstanden, welches lebenslanges Lernen voraussetzt. Die Idee hinter Softwarecraftsmanship wird durch guten Code, das Schaffen von Mehrwert, Expertengemeinschaften und produktive Partnerschaften [charakterisiert](http://manifesto.softwarecraftsmanship.org/#/de).

Softwarecraftsmanship stellt die Programmierfähigkeiten der Entwickler in den Mittelpunkt und distanziert sich damit vom ingenieursmäßigen Software Engineering, das durch definierte Prozesse, Inspektionen, Metriken, standardisierte Programmier- und Dokumentationsrichtlinien sowie rigorose Planung und Kontrolle geprägt ist. Sogar Tom DeMarco, berühmt für seine Beiträge zum Software Engineering, relativiert seine mehrere Jahrzehnte alten Vorstellung und räumt ein, dass Softwareentwicklung immer auch eine experimentelle Komponente hat, für die die Disziplinen des Software Engineering [nicht entscheidend sind](http://www2.computer.org/cms/Computer.org/ComputingNow/homepage/2009/0709/rW_SO_Viewpoints.pdf).

Also lohnt sich ein genauerer Blick auf die Metapher des Architekten. Sie kommt aus dem Baugewerbe, wo es ja auch Bauarbeiter gibt. Das Problem ist, dass in der Softwareentwicklung die Grenzen nicht so klar gezogen werden können wie dies scheinbar in der Baubranche möglich ist. Ein Architekt sollte in der Softwareentwicklung als Softwarecraftsman nahe am Code arbeiten. Das bedeutet nicht zwangsläufig, dass er selbst Code schreibt. Das wird aufgrund seiner endlichen Arbeitszeit nicht immer möglich sein. Entscheidend ist, dass er als eine Art Mentor des Entwicklungsteams fungiert. Sein Ziel ist es, die Fähigkeiten des Entwicklungsteams zu verbessern, um nicht als alleiniger Entscheidungsträger [zum Flaschenhals zu werden](http://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf).

Design und Architektur kommen somit von allen Entwicklern eines Teams. In agilen Teams findet die Praxis des [Collective Code Ownership](http://www.extremeprogramming.org/rules/collective.html) sogar explizit Anwendung. Das bedeutet einerseits, dass die Code-Verantwortung von allen Entwicklern getragen wird und andererseits, dass alle Entwickler das Recht haben den Code und indirekt damit auch das Design zu ändern. Selbstverständlich wird der Architekt bei wichtigen Entscheidungen einbezogen und verantwortet die technische Realisierung. Er muss aber nicht in allen Gebieten ein Spezialist sein. Hier hilft die Idee des [T-Modells](http://jaxenter.de/artikel/Gretchenfrage-20-Sind-Sie-Architekt-oder-Entwickler): Demnach sollte jede Person in einem Bereich ein Spezialist, in dem er in die Tiefe geht – wie der senkrechte Strich des Buchstaben T. In den anderen Bereichen hat eine Person hingegen typischerweise nur Grundlagenwissen – entsprechend dem horizontale Strichs des Ts. Nach dem T-Modell sollte ein Architekt also mindestens in einem Bereich tiefe Expertise haben, wie beispielsweise Portalentwicklung, SOA oder Persistenz, um im Team als Architekt akzeptiert zu werden. Als [Generalizing Specialist](http://www.agilemodeling.com/essays/generalizingSpecialists.htm), der aktiv sein Wissen auch außerhalb seines Spezialgebietes erweitert, kann er außerdem mit verschiedenen Experten sprechen und von ihrem Wissen profitieren.

### Wer ist ein Softwarearchitekt?

Nun findet sich “Softwarearchitekt” als Berufsbezeichnung auf sehr vielen Visitenkarten. Softwarearchitekt ist eben nicht nur eine Rolle im Projekt, sondern auch eine technische Laufbahnstufe, die Entwickler oder Berater im Laufe ihrer Karriere erreichen können.

In einem Projekt-Team geht es aber nicht um diesen Titel, sonder in erster Linie darum, die Architektur zu definieren. In diesem Kontext steht die Rolle im Vordergrund: Wenn ein Teammitglied durch Kompetenz überzeugt, wird es die Architektur im Team entscheidend beeinflussen. Der Titel kann helfen, denn dadurch kann es einfacher sein, Teammitglieder von der eigenen Kompetenz zu überzeugen und den eigenen Entscheidungen Nachdruck zu verleihen. Am Ende ist die Kompetenz aber wesentlich wichtiger. Es geht vor allem um Kenntnisse über Architekturmuster und andere Ansätze sowie deren Vor- und Nachteile. Ebenso ist die Kenntnis von Frameworks, Sprachen und anderen Technologien wie beispielsweise Datenbanken wichtig. Durch die Kenntnis der verschiedenen Ansätze kann in einem konkreten Projekt eine passende Entscheidung für oder gegen eine Technologie untermauert werden.

Diese Wahrnehmung der Rolle des Softwarearchiteten entspricht auch dem Selbstverständnis agiler Teams. Sie setzten auf Selbstorganisation. Daher findet sich in einem agilen Umfeld der Architekt sozusagen von selbst: Es ist einfach die Person, die bei anstehenden Entscheidungen am meisten involviert wird – einfach aufgrund der Kompetenz. Dieses Verständnis ist deutlich anders als das klassische Rollenverständnis: Entscheidungen werden nicht erzwungen oder durchgedrückt, sondern moderiert und gemeinsam getroffen – dadurch sind sie auch viel besser im Team verankert.

Dann muss allerdings auch das gesamte Team die Verantwortung für die Architektur übernehmen – wobei die erfahrenen Teammitglieder sicher ein großer Teil der Verantwortung übernehmen müssen. Schließlich übernehmen sie ja auch den größeren Teil der Entscheidungen.

### Wie Architekten ausbilden?

Die Ausbildung eines Architekten muss sehr umfassend sein: Aus der definierten Rolle ergibt sich, dass Architekten zum einen eine hohe technische Kompetenz haben müssen, aber gleichzeitig auch Soft-Skills beherrschen müssen. Nur dann können sie das Wissen auch effektiv im Team einsetzen. Ebenso müssen sie einen breiten Überblick über verschiedene technologische Ansätze und Best Practices haben, um für den Einsatz der jeweiligen Technologien sinnvoll ausgestalten zu können. Am besten sollte das durch permanente Weiterbildung und Neugierde “von selber kommen”.

Solche Elemente sind mit theoretischem Unterricht vermittelbar. Hilfreich sind aber auf jeden Fall umfangreiche eigene Erfahrungen. Eine rein theoretische Ausbildung ist aber kaum sinnvoll. Denn die theoretische Ausbildung ist noch lange nicht ausreichend, um das Gelernte auch in der Praxis umzusetzen.

Das Architekten-Programm bei der adesso AG setzt daher neben einer umfangreichen theoretischen Ausbildung auch auf ein “Meisterstück”. Der angehende Architekt wird mit Hilfe eines Coaching bei der Umsetzung des Gelernten begleitet. So wird die Ausbildung auf besser auf die jeweilige Person wie auch den Kontext anzupassen. Außerdem wird vermittelt, wo der berühmte Unterschied zwischen Theorie und Praxis liegt – und wie man mit ihm umgeht.

Auch hier hilft die Metapher der Software Craftsman weiter: Ein Handwerker, der zwar den Inhalt seinen Werkzeugkoffer kennt, aber keine Übung im Umgang mit seinen Werkzeugen hat, wird wenig Erfolg haben. Durch viel Übung und Erfahrung wird aus einem Lehrling ein Meister, der sein Team anleitet und unterstützt. Genau so wie ein Handwerksmeister können tatsächlich auch Software Architekten ausgebildet werden.

### Zusammenfassung

Der klassische “Powerpoint-Architekt” ist also für einige Bereiche wie die Konzeption des Big Pictures durchaus sinnvoll – aber eine Orientierung an Software Craftsmanship it ebenso notwendig. Dadurch kann der Architekt die praktische Umsetzung der Architektur im Code und die Auswirkungen auf die Arbeit der Entwickler viel besser verstehen. Ebenso hilft die Metapher bei der Definition der Rolle: Als Experte und Coach ist sie durchaus mit dem Handwerksmeister vergleichbar. Ebenso kann die Ausbildung von Architekten neben der Theorie auch am praktischen Projekt erfolgen – wie dies im Handwerk ja auch der Fall ist.

Software Craftsmanship und Software Architektur müssen also keine Gegensätze sein. Die beiden Ansätze können sich vielmehr hervorragend ergänzen.

*Aufmacherbild: [Closeup of tablet computer and hammer in carpenter`s tool belt](http://www.shutterstock.com/de/pic-159957014/stock-photo-closeup-of-tablet-computer-and-hammer-in-carpenter-s-tool-belt-outdoors.html?src=PVFDbg4zDeANjuquBUeVXg-1-35 "Closeup of tablet computer and hammer in carpenter`s tool belt<br />&#10; von Shutterstock / Uhrheberrecht: Tyler Olson ") von Shutterstock / Urheberrecht: Tyler Olson*