Der Softwarearchitekt (Teil II)

iStock 000004940465Large
Softwarearchitekten übernehmen in Projekten eine zentrale Rolle und tragen eine große Verantwortung. Dass sie über ein ausgezeichnetes technisches Know-how verfügen müssen, ist allseits bekannt, aber auch wichtige Softskills sind unabdingbar. Im folgenden Artikel wollen wir beleuchten, welche Aufgaben der Architekt übernimmt und welche Fähigkeiten er dazu benötigt.
Mythos Elfenbeinturm

Das Bild von einem Softwarearchitekten, der sich in seinen Elfenbeinturm zurückzieht, einsam einen Plan ausarbeitet und diesen anschließend einem Heer von Entwicklern zur Ausführung vorlegt, ist längst überholt.

Softwarearchitekten stellen heute das Binde­glied zwischen den unterschiedlichen Interes­sensgruppen eines Projektes dar. Dazu zählen neben den Anwendern, Auftraggebern und dem Betrieb auch die Projektmanager sowie das komplette Entwicklungsteam. Entsprechend vielfältig und anspruchsvoll sind die Aufgaben, die die Softwarearchitekten zu bewältigen haben. Die Fähig­keiten, die sie auszeichnen sollen, machen sie zu echten Allroundern der IT.

Rollenverteilung

Die Rolle des Softwarearchitekten ist nicht immer klar definiert, in manchen Projekten wird sie von Personen in einer Doppelfunktion wahrgenommen.

Um der Verantwortung für eine hochwertige Softwarearchitektur im Projekt gerecht werden zu können, sollte der Architekt aber klassische Interessenskonflikte vermeiden. So sollten die Rollen des Projektleiters und des Software­architekten möglichst getrennt vergeben werden.

Während der Softwarearchitekt bzgl. der Architektur eher langfristige Ziele verfolgt (z.B. Wartbarkeit), neigen Projektleiter dazu, entsprechende Qualitätsmerkmale, Zeit- oder Budgetaspekten unterzuordnen.

In agil vorgehenden Projektteams kristallisiert sich meist relativ schnell, sofern der Aspekt der Selbstorganisation auch gelebt wird, eine Person (oft ein erfahrener Entwickler) heraus, der die Aufgaben eines Architekten übernimmt. Das gilt auch für jene agilen Vorgehensmodelle, die keine explizite Rolle eines Softwarearchitekten definieren.

Entwerfen von Architekturen

Zu den offensichtlichen Aufgaben des Architekten gehört das Entwerfen von Architekturen. Er konstruiert ein System aus einer Reihe von Subsystemen, die sich wiederum aus Komponenten zusammensetzen. Dieses Entwerfen beinhaltet die Definition der Verantwortlichkeiten der einzelnen Komponenten und deren Schnittstellen. Die eigentliche Funktionalität des Systems, das aus statischen und dynamischen Strukturen besteht, wird dann durch die Interaktion der Komponenten bestimmt.

Der Konstruktionsprozess beruht auf einer Reihe von Anforderungen und Annahmen, aus denen der Softwarearchitekt seine Entwurfsentscheidungen folgert. Daraus leitet sich eine sehr wichtige Aufgabe ab, die Überprüfung und Klärung der Anforderungen. Insbesondere die nicht-funktionalen Anforderungen haben entscheidenden Einfluss auf das Design eines Softwaresystems. Folgende Aspekte muss der Architekt deshalb im Vorfeld bezüglich der Anforderungen unbedingt klären:

  • Abgrenzung
    Durch das Feststellen der Systemgrenzen lassen sich die eigenen Aufgaben­gebiete abgrenzen. Gleichzeitig werden dadurch die Schnittstellen zu benachbarten Systemen klarer.
  • Vollständigkeit
    Ein vergessenes oder unterschätztes Qualitätsmerkmal kann im Nachhinein eine Architektur als ungeeignet disqualifizieren. Es muss also zu Beginn, am besten anhand von Checklisten, die Vollständigkeit der Anforderungen geprüft werden. Werden hier Lücken festgestellt, muss der Architekt die fehlenden Aspekte unbedingt in eigener Initiative einholen und ergänzen.
  • Qualität
    Sind alle Anforderungen vollständig erfasst, müssen sie detailliert beschrieben und priorisiert werden. Insbesondere die impliziten Annahmen (z.B.: „Das System muss performant sein.“) müssen konkretisiert werden (z.B.: „Das System muss mindesten 10 Aufträge mit jeweils 5 Positionen in weniger als 10 Sekunden verarbeiten können.“). Da nicht alle Qualitätsmerkmale gleichzeitig optimiert werden können, ist die Priorisierung wichtig (z.B.: Die Performance ist im Zweifelsfall wichtiger als die Erweiterbarkeit). Hierfüreignen sich beispielsweise Utility Trees hervorragend.

Design-Entscheidungen

Der Softwarearchitekt trifft während des Entwurfs der Architektur, basierend auf den Anforderungen, laufend Entscheidungen zum Design des Gesamtsystems. Das betrifft nicht nur die abstrakten Strukturen, sondern auch deren Abbildung auf konkrete technische Konzepte. Er bedient sich dabei neben seines eigenen Know-hows auch immer aus der Schatzkiste von Erfahrungen, die er oder andere Architekten bereits gesammelt haben.

Trotzdem wird es ihm nie gelingen, auf alle Eventualitäten vorbereitet zu sein. Er bewegt sich mit seinen Design-Entscheidungen in einem Spannungsfeld, in dem nicht alle Anforderungen gleichwertig erfüllt werden können (siehe Abbildung 1).

 

afl abb1
Abb. 1: Spannungsfeld der Design-Entscheidung.


Daher muss er ein besonderes Maß an Selbstvertrauen und Mut aufbringen und in der Lage sein, die getroffenen Entscheidungen anhand von vorliegenden Anforderungen und Randbedingungen begründen zu können und die damit verbundenen Risiken zu bewerten.

Oft wird er seine Lösung gegen andere Vorschläge verteidigen müssen. Das Wissen um suboptimale Entwurfsentscheidungen während der Architekturentwicklung fordert aber auch entsprechende Möglichkeiten zur Korrektur. So sollte die Entwicklung der Architektur sinnvollerweise in kurzen Iterationen durchgeführt werden (siehe Abbildung 2).

 

afl abb2
Abb. 2: Architekturentwicklung.


Daraus ergibt sich für den Architekten zeitnah die Möglichkeit, einmal getroffene Entscheidungen zu überdenken und ggf. mit kalkulierbarem Aufwand anzupassen. So kann er auf neue oder veränderte Situationen reagieren, ohne zu große Risiken für das Gesamtsystem eingehen zu müssen.

Dokumentation und Kommunikation

Die Ergebnisse aus der oben beschriebenen Klärung der Anforderungen müssen genauso, wie die entwickelte Softwarearchitektur und die Wahl der technologischen Konzepte dokumentiert werden.

Die Anforderungen sind die Grundlage und damit die Begründung aller Design-Entscheidungen. Sie müssen von allen Projektbeteiligten akzeptiert und vertreten werden. Für die Dokumentation gibt es unterschiedliche Methoden, von einfachen handschriftlichen Aufzeichnungen bis zur komplexen Software­lösung ist alles möglich. Wichtig ist, ein gutes Maß für den Umfang und die Art der Dokumentation zu finden, denn die Dokumentation soll gelesen werden. Zuviel Dokumentation ist mindestens genauso schädlich wie fehlende Dokumentation.

In diesem Zusammenhang kommt eine weitere wichtige Fähigkeit des Architekten zum Tragen. Er muss in der Lage sein, die Architektur zu kommunizieren. Da er gegenüber allen Projektbeteiligten in der Verantwortung steht, muss er für jede Zielgruppe die angemessene Form sowie den richtigen Umfang und Inhalt finden.

Während für das Management die Personal-, Zeit- und Budget-Aspekte von Interesse sind, trifft dies für die Systemadministratoren eher nicht zu. Sie benötigen für die betrieblichen Belange vielmehr Informationen bzgl. der Verfügbarkeit oder Skalierbarkeit des Systems. Dies ist für das Entwicklerteam zwar auch relevant, aber von nicht so entscheidender Bedeutung wie beispielsweise einzusetzende Technologien, Frameworks oder Entwurfsmuster.

Die richtige Sprache für alle Beteiligten zu finden ist ein entscheidender Faktor, um die Akzeptanz einer Architektur im gesamten Projekt zu erreichen. Der Softwarearchitekt muss hier vereinfachen, filtern und kanalisieren, damit die Informationen bei den einzelnen Personen bedarfsgerecht ankommen.

Außerdem ist der Softwarearchitekt gut beraten, Informationen aktiv einzufordern und das Feedback der unterschiedlichen Interessensgruppen in seine Überlegungen einfließen zu lassen. Die Kommunikation ist und bleibt einer der wichtigsten Aspekte.
Allerdings gelten hier ähnliche Regeln wie bei der Dokumentation. Auf das richtige Maß kommt es an. Projekte, in denen man vor lauter Meetings nicht mehr zur eigentlichen Tätigkeit kommt, gibt es leider immer noch.

Implementierung

Sobald das Entwicklerteam mit der Umsetzung der Architektur beginnt, ist der Softwarearchitekt mit weiteren Aufgaben gefordert. Es gilt nun die Umsetzung der Architektur zu begleiten und zu überprüfen, ob die Gesamt­lösung auch wie geplant den Anforderungen genügt.

An dieser Stelle muss der Architekt im Dialog mit allen Beteiligten immer wieder prüfen, ob es neue oder geänderte Anforderungen und Randbedingungen gibt. Er bewertet die aktuelle Architektur, wägt Chancen und Risiken ab und führt Anpassungen an der Architektur und der technischen Umsetzung durch. So führt er die Architektur Schritt für Schritt auf die gewünschte Lösung hin.

Für die Bewertung der Architektur stehen dem Softwarearchitekten verschiedene Möglichkeiten zur Verfügung. Oft werden Kombinationen von unterschiedlichen Vorgehensweisen verwendet, die aus dem gesamten Spektrum, beginnend vom subjektiven Erfahrungsschatz des Architekten bis hin zu stark formalisierten Verfahren, der Situation entsprechend ausgewählt werden.

Beratung

Neben der Kommunikation der eigentlichen Softwarearchitektur kommt dem Architekten immer die Aufgabe der Beratung zu. Auch diese Aufgabe betrifft alle Projektbeteiligten.

Dem Management und der Projektleitung steht der Architekt in Fragen der Projekt- oder Teamorganisation zur Seite. Die Teamorganisation wird z.B. nach Conways Gesetz („Wenn Sie einen Compiler durch vier Teams entwickeln lassen, werden Sie mit sehr hoher Wahrscheinlichkeit als Ergebnis einen 4-Phasen-Compiler bekommen.“) Einfluss auf die Architektur haben.

Der Betrieb wird Informationen zu Anforderungen an Hardware und Infrastruktur benötigen und Hinweise zur Inbetriebnahme, Migration und Wartung.

Das Entwicklerteam wird Unterstützung bei der Implementierung benötigen. Die Schulung bestimmter Technologien und Methoden, die Erläuterung von Einzelheiten der Architektur oder der Aufbau von Umgebungen für Tests und Migration gehören genauso, wie die Beratung bei der Wahl von Werkzeugen zu den Aufgaben des Architekten.

Nicht zuletzt ist es wichtig, dass ein Architekt in der Lage ist, die Implementierung zu unterstützen. Im Gegensatz zu der Ansicht „Architects don‘t implement“ kann der Architekt beim Entwicklungsteam großes Vertrauen gewinnen, wenn er genau weiß, was er von den Entwicklern verlangt und auch in der Lage ist, dies vorzuleben und zu unterstützen.

Fazit

Der Softwarearchitekt besitzt in einem Projekt eine zentrale Rolle. Er bildet die Schnittstelle zu allen Beteiligten. Zudem trägt er eine hohe Verantwortung für den erfolgreichen Ausgang eines Projektes und entsprechend breit ist sein Spektrum an Aufgaben und Fähigkeiten (siehe Abbildung 3).

afl abb2
Abb. 3: Umfeld der Softwareachitekten.


Neben seiner technischen Expertise ist besonders seine Rolle als Vermittler und Moderator hervorzuheben. Er muss zwischen unterschiedlichen Interessen ausgleichen, was nicht nur die klassischen nicht-funktionalen Qualitätsmerkmale oder Zeit- und Budget-Aspekte betrifft, sondern auch persönliche oder politische Ziele der Beteiligten.

Wegen seiner exponierten Stellung ist und bleibt ein guter Softwarearchitekt für den Erfolg eines IT-Projektes eine wichtige Grundvoraussetzung.

Im nächsten Artikel dieser Reihe werden wir betrachten, wie eine Software­architektur konkret entwickelt wird.

 

afl

Andreas Flügge

Projektmanager
Java-Entwickler
Softwarearchitekt
und Autor von Fachartikeln
in den ORDIX news und Java Aktuell

Diesen Artikel als PDF

pdf-symbol

Sie wollen den Artikel nochmal in Ruhe nachlesen?
Laden Sie sich einfach die PDF aus der ORDIX news 2/2011 herunter.

Lesen Sie auch Teil III

Die Architekturentwicklung

1170906 18791888 1

„Wie kommt der Architekt zu einer tragfähigen Architektur für ein zu entwickelndes Softwaresystem?“

Erfahren Sie mehr ...


 

Bildquelle

Das Titelbild dieses Artikels entstand aus dem folgenden Bild:
© istockphoto.de/ blueprint / © mariusFM77