Grundlagen der Softwarearchitektur: Teil 3

Dr. Gernot Starke

This article is also available in English

• Teil 1: Gebäude, Zweck, Ästhetik
• Teil 2: Begriffe
• Teil 3: Aufgaben und Tätigkeiten (dieser Artikel)
• Teil 4: Wer macht was?
• Teil 5: Wie geht es weiter?

In der letzten Folge haben Sie die wesentlichen Bestandteile von Softwarearchitektur kennengelernt: System, Komponenten, Schnittstellen und (querschnittliche) Konzepte.

• das (gesamte) System besteht aus
• Komponenten und deren Schnittstellen, also Beziehungen zueinander, und
• Schnittstellen zur Umgebung, sogenannte externe Schnittstellen
• Prinzipien, synonym (querschnittliche) Konzepte von Entwicklung, Betrieb und Evolution — beispielsweise die Auswahl von Programmiertechnologie, eines Technologiestacks oder die Verwendung definierter Werkzeuge oder Vorgehensweisen bei Entwicklung, Test oder Rollout/Release.

Damit gibt uns die Definition von Softwarearchitektur bereits zwei Aufgaben vor: einerseits das Entwerfen von Strukturen (Komponenten und Schnittstellen), andererseits das Entwerfen dieser querschnittlichen Konzepte oder Prinzipien.

Grundlage: Angemessene Anforderungen

Aber halt. Bevor wir in der Architektur mit “Entwerfen” loslegen, sollten wir angemessene Anforderungen haben: Was soll das System leisten, welche Aufgaben oder Prozesse soll es unterstützen (aka funktionale Anforderungen)? Dazu kommt das schwierige Thema der Qualitätsanforderungen (siehe dazu [1]), wie Performanz, Durchsatz, Sicherheit, Änderbarkeit und so weiter. Schließlich müssen Sie auch die Rand- oder Rahmenbedingungen kennen (constraints), die Entscheidungsmöglichkeiten von Architekt:innen einschränken.

Es geht hier nicht um alle Anforderungen – denn dann wären wir ja bei einem waterfallish-upfront Ansatz – sondern um die aktuell bekannten und relevanten Themen. Primär sollten Sie sich um architekturrelevante Anforderungen (engl:architecturally significant requirements) kümmern. Dazu gehören Anforderungen, die von besonders wichtigen Stakeholdern stammen (etwa: oberes Management, Auftraggeber, etc.), besonders kritisch bzw. riskant sind, besonders kritische Qualitätseigenschaften betreffen oder ausgeprägten innovativen Charakter besitzen.

Sollten diese Anforderungen zu schwammig, unklar und widersprüchlich sein, oder gar komplett fehlen, müssen Sie in der Architektur handeln statt jammern, also gemeinsam mit Stakeholdern nachbessern oder zumindest über die für Requirements verantwortlichen Personen nachfordern. Daher sehen Sie in Abbildung 1 auch verschiedene solcher Stakeholder symbolisch mit der Aufgabe “Anforderungen klären” verbunden.

In dieser Abbildung erkennen Sie auch eine Reihe weiterer Aktivitäten, die ich den nachfolgenden Abschnitten kurz erläutern werde.

Entwerfen im Doppelpack

Schon im vorherigen Artikel dieser Serie haben Sie die Kernbegriffe “Strukturen” und “Konzepte” kennengelernt. Für beide müssen Sie im Rahmen Ihrer Architekturarbeit Entscheidungen treffen, also sowohl Strukturen als auch Konzepte entwerfen.

Ob Sie persönlich diese Entscheidungen treffen, oder sich mit anderen Personen oder sogar dem gesamten Entwicklungsteam abstimmen, ist eine komplett andere Frage, der wir uns im Teil 4 dieser Serie ausführlich widmen werden. Deswegen schreibe ich hier ganz unpersönlich “Architektur”, statt Sie persönlich oder eine andere Person zu adressieren.

• Durch “Strukturen entwerfen” legt die Architektur die Zerlegung (auch genannt: Schnitt) Ihres Systems fest. Sie bestimmt dabei die Bestandteile (Komponenten, Module, Services, Pakete oder wie auch immer in Ihrer gewählten Technologie die einzelnen Bestandteile eines Gesamtsystems heißen). Ganz wesentlich hierbei sind die Schnittstellen zwischen den einzelnen Bestandteilen sowie zur Umwelt.
• Durch “Konzepte entwerfen” legt die Architektur beispielsweise die genutzten Technologien und Frameworks fest. Sie bestimmt die Art und Weise, wie die Technologien eingesetzt werden und gibt Patterns (Muster) und Regeln für architekturrelevante Themen vor.

Diese beiden Aufgaben stellen den inhaltlichen Kern der Architekturtätigkeit dar. In der Abbildung weiter oben sehen Sie eine Überschneidung, die ich in der folgenden Abbildung 2 etwas vergrößert habe:

Manche Entscheidungen betreffen sowohl Strukturen als auch querschnittliche Konzepte, beispielsweise:

• Die (querschnittliche) Entscheidung, sämtliche externen REST-Schnittstellen durch einen Penetration-Test auf Sicherheitsrisiken zu prüfen. Externe Schnittstellen gehören zu den Bausteinen, den Strukturelementen des Systems, Penetration-Tests stellen ein methodisches Konzept dar.
• Die (querschnittliche) Entscheidung, gemäß Domain-driven Design zu arbeiten, und dabei jeden fachlichen Baustein (bounded context) gemäß dem Clean-Architecture-Muster zu implementieren.
• Die (querschnittliche) Entscheidung für Apache Kafka als Produkt für Messaging zu verwenden, hat Konsequenzen für alle betroffenen Bausteine (Strukturelemente).

Kommunizieren (und dokumentieren)

Bisher haben Sie Anforderungen geklärt und daraus Entwurfsentscheidungen in Form von Komponenten, Schnittstellen und Konzepten getroffen. Wie aber gelangen diese Entscheidungen und deren Erläuterungen zum Entwicklungsteam oder anderen Beteiligten?

Offensichtlich müssen Sie diese Entscheidungen kommunizieren (geschieht in der Regel mündlich) oder dokumentieren (üblicherweise schriftlich), damit andere Menschen mit diesen Architekturentscheidungen arbeiten oder darauf mit Feedback reagieren können. Sie erkennen das an den bidirektionalen Pfeilen zwischen den Aktivitäten.

Als Architekt:in sollten Sie offen für konstruktive Kritik sein und aktiv Feedback zu Ihren Vorschlägen oder Entscheidungen einfordern.

Ach ja, etwas Werbung in eigener (Open-Source) Sache sei mir gestattet: Das arc42-Template bietet ein langjährig bewährtes Gerüst für Kommunikation und Dokumentation von Softwarearchitekturen an, inklusive zahlreicher Beispiele aus der Praxis. Es funktioniert komplett technologie- und prozessagnostisch. Aber das nur nebenbei, wie das Känguru zu sagen pflegt. Für die besonders sparsamen unter Ihnen gibt es auch einen arc42 Canvas, mit dessen Hilfe Sie Ihre Architekturen als one-pager in super-kompakter Form beschreiben können. Perfekt auch als elevator pitch geeignet!

Von Goldstücken und Missverständnissen

Es besteht beim Arbeiten im Team immer das Risiko, dass Menschen sich missverstehen. Dies ist ein menschliches Grund_problemfeature, daher können Sie das nicht grundlegend ändern. Wenn Sie dem Team etwas erklären, egal ob mündlich oder schriftlich, könnten Personen etwas anderes in diese Worte und Bilder hineininterpretieren, als das, was Sie damit eigentlich aussagen wollten.

Solche Missverständnisse haben wir alle in der Realität schon erlebt. Sie müssen in Ihrer Architekturarbeit aktiv etwas gegen diese Missverständnisse unternehmen: Begleiten Sie die Umsetzung! Prüfen Sie beispielsweise, ob der implementierte Code so beschaffen ist, wie Sie das in der Architektur vorgesehen haben. Codereviews, Pull-/Merge-Requests oder statische Codeanalyse sind nur einige der methodischen Mittel, die Sie hierfür einsetzen können. Design-Reviews, Pair- oder Mob-Programming, Coding-Styleguides, Referenzimplementierungen, Checklisten, und noch viele andere.

Umsetzung begleiten hat allerdings noch einen wichtigen zweiten Effekt: Ihre Teamkolleg:innen werden an manchen Stellen schlichtweg auf geeignetere (und somit bessere) Ideen kommen, als die ursprünglichen Architekturentscheidungen. Solche strukturellen oder technischen Verbesserungen, Vereinfachungen, geschicktere Ansätze oder Ähnliches bezeichne ich als “Goldstücke”, und die sollten Einzug in die Architektur halten – insbesondere weil Sie in Ihrer Rolle als Architekt:in eben nicht alles wissen (können). Aber darauf gehen wir in der vierten Folge noch genauer ein.

Der Blick aufs große Ganze

Die IT gehört zu den Branchen mit hohem Anteil an Neuerungen und auch die fachlichen Anforderungen unserer Projekte unterliegen teilweise heftigem Wandel. Daher sollten Sie ab und zu (vielleicht halbjährlich oder jährlich) mal die grundsätzliche Frage stellen, ob Architektur (aka Lösungsansatz) und der aktuelle Stand der Anforderungen überhaupt noch zueinander passen. Ein ergebnisoffenes Review, mindestens aber eine qualitative Architekturanalyse, kann hier hilfreiche Impulse für zukünftige Verbesserungen geben.

Neugierde gefragt

Als Architekt:in sollten Sie am Ball bleiben, was Neuerungen angeht. Sie sollten zumindest einen Überblick bei neuen Technologien, Werkzeugen oder Methoden behalten. Vielleicht das ein oder andere aktuelle Framework mal ausprobieren. Die neueste Version wichtiger Werkzeuge kennen, und ab und zu mal auf Fachkonferenzen Inspiration sammeln. Ich weiß, das kostet Zeit, und bei der hohen Innovationsrate in der IT können Sie niemals in allen Aspekten sämtliche relevanten Details verstehen. Aber nur mit Neugierde und Offenheit für andere Ansätze können Sie auch zukünftig angemessene Lösungen konstruieren. Ohne diese Bereitschaft, ständig zu lernen, nimmt der Wert von Architekturwissen und -fähigkeiten mit der Zeit immer mehr ab. Sie kennen ja die kurzen Halbwertszeiten vieler Themen in der IT.

Die Reihenfolge

Sie kennen sie schon, die KDA-Regel: Kommt Drauf An. Architektur ist keine exakte Wissenschaft. Anders als in Mathematik und Physik können wir Ergebnisse nicht exakt berechnen und unsere Entscheidungen nicht exakt bewerten. Ich kann Ihnen also keine allgemeingültige Reihenfolge oder Gewichtung der Aufgaben vorgeben. Das müssen Sie, gemäß der KDA-Regel, selbst entscheiden.

Kompetenzen und Fähigkeiten

Bis hierhin haben wir konkrete Aufgaben und Tätigkeiten der Softwarearchitektur besprochen. Um diese Aufgaben angemessen erledigen zu können, benötigen Sie eine Reihe von Fähigkeiten und Kompetenzen. Einige davon möchte ich hier noch kurz ansprechen:

Sie entwerfen und bauen Software im Team und sollten daher eine Menge Verständnis für Menschen und deren Eigenarten mitbringen. Neben dem technischen und methodischen Verständnis für die oben genannten Aufgaben gehören also noch Softskills zum Wunschprofil erfolgreicher Softwarearchitekt:innen.

Darunter fällt auf der einen Seite das Einfühlungsvermögen – wobei der Fachbegriff Empathie möglicherweise besser klingt. Andererseits gehören auch Kommunikationsfähigkeiten wie Überzeugungskraft und Durchsetzungsvermögen zu wünschenswerten Eigenschaften.

Damit nicht genug, wäre eine gehörige Portion Kritikfähigkeit und Flexibilität noch passend. Das alles klingt nach einem Universaltalent, das schwer zu finden ist. Darf ich umgekehrt fragen: Auf welche der genannten Kompetenzen und Fähigkeiten können Sie denn bei kritischen, teuren oder riskanten Projekten verzichten?

Damit ausgestattet steht allerdings Ihrer Kernaufgabe nichts mehr im Weg – nämlich für die bestmöglichen Voraussetzungen zu sorgen, damit Ihr Team gute Software bauen kann.

Wer soll das tun?

Bei diesen ganzen Aufgaben und Fähigkeiten kommt die Frage auf, wer das alles erledigen soll? Eine Person, die nichts anderes außer Architektur verantwortet? Eine kleine Gruppe, die sich diese Aufgaben aufteilt? Oder sollen wir die Aufgaben im gesamten im Team verteilen?

Diese Frage beantwortet die vierte Folge dieser Serie. Stay tuned.

Danksagung

Danke an Martina “m”, Martin Weck und Benjamin Wolf für gründliche Reviews!

Quellen