This article is also available in English
- Teil 1: Gebäude, Zweck, Ästhetik
- Teil 2: Begriffe (dieser Artikel)
- Teil 3: Aufgaben und Tätigkeiten
- Teil 4: Wer macht was?
- Teil 5: Wie geht es weiter?
In der ersten Folge hatten wir auf die Architektur von Gebäuden geschaut, und einige Begriffe und Herausforderungen dieser Disziplin geklärt. Diesmal wenden wir uns der Informationstechnik zu und erklären, was Softwarearchitektur bedeutet.
Was ist Softwarearchitektur?
In der Alltagssprache verwenden wir den Begriff Architektur primär für Entwurf und Form von Gebäuden.
In der IT nutzen wir Architektur mindestens in den folgenden Bereichen (ohne Anspruch auf Vollständigkeit):
- Organisation und Aufbau von Softwaresystemen
- Organisation und Aufbau von Kombinationen aus Hardware und Software (auch als Systemarchitektur bezeichnet)
- Organisation der Informationstechnologie innerhalb von Organisationen (auch als Unternehmens-IT-Architektur bezeichnet)
- Aufbau und technische Details integrierter Schaltkreise, insbesondere von CPUs (central processing units) - diese spezielle Interpretation von “Architektur”, beispielsweise ARM- oder x86-Architektur, möchte ich hier jedoch nicht weiter vertiefen
- andere, je nach Unternehmen oder Organisation
Eine praxistaugliche Definition
Meiner Meinung nach stammt die beste und pragmatischste Definition von “Softwarearchitektur” aus dem Standard IEEE 1471 (siehe auch [1]).
Softwarearchitektur: Die grundsätzliche Organisation eines Systems, wie sie sich in dessen Komponenten, deren Beziehung zueinander und zur Umgebung widerspiegelt, sowie die Prinzipien, die für seinen Entwurf und seine Evolution gelten.
System, Komponenten, Beziehungen, Prinzipien - diese Begriffe sind zwar umgangssprachlich sehr geläufig, ich möchte sie zur Sicherheit aber im Zusammenhang mit Architektur erläutern. Sie wissen schon, ein gemeinsames Verständnis von Begriffen gilt als Grundlage des gegenseitigen Verstehens. Also, legen wir los.
System
Das Merriam-Webster Wörterbuch definiert ein System als “eine regelmäßig interagierende oder voneinander abhängige Gruppe von Elementen, die ein einheitliches Ganzes bilden”.
Diese Definition ist so abstrakt, dass sie jedes Konglomerat beliebiger Elemente abdeckt, die entweder interagieren oder einfach nur zusammengestöpselt sind.
Systeme können insbesondere beliebige Größen haben, z.B.
- das einzelne Softwaresystem, über das wir oft schimpfen,
- die Mischung aus Hardware und Software eines komplexen Gerätes, etwa ein Steuergerät in einem Auto oder auch ein Smartphone,
- eine Menge von Servern und Netzwerken, die wir manchmal als Cloud bezeichnen,
- der riesige multinationale Konzern, dem sowohl Hard- als auch Software gehören, und so weiter.
In Software haben wir normalerweise Komponenten (siehe unten), die miteinander kooperieren, um bestimmte Anforderungen zu erfüllen. Alternativ (anstatt System) werden die Begriffe Anwendung oder Programm verwendet.
Jedes System ist in eine Umgebung eingebettet und interagiert mit einem oder mehreren anderen Systemen (siehe “Umgebung”, weiter unten).
Um Missverständnisse bei diesem zentralen Begriff zu vermeiden, sollten Sie also genau klären, was bei Ihrem System der Umfang(scope) sein soll. Wenn wir also über Systeme sprechen, sollten wir sehr klar sagen, was genau wir damit im konkreten Fall meinen.
Aber kommen wir zurück zur Definition von Softwarearchitektur, und klären noch ein paar weitere Begriffe:
Komponenten
Schon wieder so ein Begriff aus der Alltagssprache, für den wir eine Definition brauchen. Wikipedia definiert das wie folgt:
Komponente (von lateinisch componens ‚das Zusammensetzende‘) bezeichnet allgemein die Bestandteile größerer Einheiten.
In Software finden sich verschiedenste strukturelle (“zusammensetzende”) Einheiten: Applikationen, Subsysteme, Services, Module, Klassen, Funktionen. Ganz wichtig: Komponenten können auch zugeliefert werden, also 3rd-Party-Bestandteile oder auch Services sein.
Bezogen auf die Softwareentwicklung verwende ich für Komponenten den allgemeineren Begriff Baustein - konform zur Begriffswelt von arc42. Komponenten bestehen meistens aus Quellcode einer Programmiersprache, können aber auch andere Artefakte sein, beispielsweise Konfigurationen. Der Quellcode des gesamten Systems besteht aus mehreren solcher Komponenten.
Aus der Perspektive von Infrastruktur und Betrieb gehören auch Server, Container, Firewalls und andere (echte oder virtuelle) Hardware-Einheiten zu Komponenten. In arc42 finden sich solche Infrastruktur-Komponenten in der Verteilungssicht.
In typischen Architekturdiagrammen finden wir Komponenten als Kästchen (auf schweizerdeutsch charmant als Böxli bezeichnet).
Beziehungen
Schnittstellen, Abhängigkeiten, Assoziationen - viele Namen für dasselbe Phänomen: Komponenten müssen mit anderen Komponenten interagieren, sonst wäre keine Trennung von Belangen (Aufteilung der Verantwortung) möglich. Hauptproblem: Das Entwerfen guter Schnittstellen ist wirklich schwierig, und Missverständnisse bei Schnittstellen gelten als Ursache vieler Probleme in Softwaresystemen. Sie haben es sich bestimmt schon gedacht: Beziehungen stellen wir in Diagrammen üblicherweise als Pfeile dar.
Auch bei den Beziehungen gibt es eine Entsprechung aus Infrastruktur und Hardware: Dort bilden die Beziehungen die physischen Verbindungen zwischen Infrastrukturkomponenten, häufig realisiert durch Netzwerke oder Busse.
Umgebung
Jedes System hat eine Umgebung: Daten, Events oder Kommandos kommen aus dieser Umgebung. Andererseits fließen auch Ergebnisse in diese Umgebung zurück. Diese Außenbeziehungen heissen externe Schnittstellen.
Den einen Teil der Umgebung bilden andere IT-Systeme, Software oder auch Hardware. Den anderen Teil der Umgebung bilden Akteure, die das System verwenden, bedienen, konfigurieren oder auf andere Weise damit interagieren.
Die Kontextsicht auf Software hebt die Bedeutung dieser externen Schnittstellen hervor. Das folgende Beispiel entstammt arc42 by Examples und zeigt die Anwendung selbst in gelb und die Nachbarsysteme in grau).
Komponenten + Beziehungen = Strukturen
Obwohl der Begriff “Struktur” in der praktischen Definition von oben gar nicht vorkommt, möchte ich dennoch darauf eingehen. Wie gehabt, zuerst mal eine Definition:
Struktur (von lateinisch strūctūra „Bauart“ bzw. „Zusammenfügung, Sinngefüge“) bezeichnet die innere Ordnung eines Systems
Oftmals sprechen wir bei der Architekturarbeit von Strukturentscheidungen, wenn den Schnitt oder die Zerlegung des Systems in Komponenten und deren Beziehungen meinen, eben die innere Ordnung aus der Definition.
Strukturen bestehen aus Elementen (Komponenten oder Bausteine) und deren Beziehungen, sowohl zueinander als auch zur Umgebung. Sie kennen Strukturen garantiert aus den typischen Architekturdiagrammen, also Kästchen (aka Komponenten oder Bausteine) mit ihren Beziehungen.
Schon mal als Teaser: Das Duo aus Komponenten und Beziehungen (also die Struktur) wird in der kommenden Folge dieser kleinen Serie noch besondere Bedeutung erhalten. Insbesondere prophezeie ich Ihnen, dass Sie damit in der Praxis eine Menge Arbeit haben werden.
Prinzipien (synonym: Konzepte):
Prinzipien sind Regeln, Patterns oder sonstige querschnittliche Entscheidungen, die für mehrere Teile oder sogar das gesamte System gelten. Ich bevorzuge den Begriff Konzept anstelle von Prinzipien: Konzepte sind die Grundlage für Konzeptuelle Integrität oder Konsistenz, meiner Meinung nach eine der wichtigsten Eigenschaften von Softwaresystemen (ich habe darüber ausführlicher in einem Blogpost geschrieben).
Im Alltag beispielsweise sind innerhalb eines Gebäudes die Tür- und Fenstergriffe einheitlich beschaffen, ebenso die Art der Fensterrahmen oder Lichtschalter. In der folgenden Abbildung sehen Sie drei verschiedene Konzepte für Fenster, die für jeweils ein System (Gebäude) einheitlich angewendet worden sind. Einheitlich heißt dabei nicht unbedingt, dass alle völlig identisch aussehen, sondern ähnlichen Prinzipien, Mustern oder Regeln folgen.
Beispiele für Konzepte in IT-Systemen
- Build- und Deploy auf GitLab mit GitOps
- sämtliche grafischen Oberflächen werden mit React-Native implementiert
- sämtliche öffentlichen APIs werden vor jedem Major-Release durch einen extern vergebenen Penetration-Test auf mögliche Schwachstellen hin überprüft
- Speicherung der Anwendungsdaten bevorzugt in PostgreSQL
Konzepte bieten einheitliche Lösungen für wiederholt auftretende Probleme oder Aufgaben in Software.
Teams können Konzepte als Teil der systemspezifischen Entwicklung entwerfen und implementieren. Allerdings sind Konzepte oftmals wiederverwendbar, beispielsweise die Speicherung von Daten mit Hilfe von Spring Data. Teams können also Konzepte von anderen Systemen übernehmen. Konzepte enthalten oftmals konkrete Technologie- oder Produktentscheidungen (etwa: Spring Boot, Hibernate, .NET-Core, Angular, React, PostgreSQL). Konzepte können auch das spezifische Vorgehen in der Entwicklung oder dem Deployment von Systemen betreffen, siehe Penetration testing im obigen Kasten)
Oft bestimmen spezifische Qualitätsanforderungen (wie Performance, Skalierbarkeit, Robustheit oder Sicherheit) oder Randbedingungen (wie Budget oder gesetzliche Vorgaben) die Auswahl und Ausgestaltung solcher Konzepte.
Entwurf und Evolution
In der Softwarearchitektur werden übergreifende und systemweite Entscheidungen sowohl beim initialen Entwurf als auch während der laufenden Entwicklung (der Evolution) von Systemen getroffen. In diesem Sinne ist Architektur eine begleitende Tätigkeit. Architektur relevante Entscheidungen können zu jedem Zeitpunkt anfallen, an dem irgendwelche Änderungen am System, dessen unmittelbarer Umgebung (siehe oben, Kontext) oder dessen Infrastruktur nötig werden.
Damit haben wir die wesentlichen Begriffe rund um Softwarearchitektur geklärt. Bevor wir zu den konkret notwendigen Aufgaben und Tätigkeiten kommen, gibt es allerdings noch ein paar weitere Themen, die Sie für Softwarearchitektur beachten sollten:
Worauf müssen Sie bei Architektur noch achten?
In Softwarearchitektur müssen Sie neben den oben genannten Themen (Komponenten, Schnittstellen und Konzepten) noch ein paar mehr im Auge behalten:
- (Architektonische) Entscheidungen haben oft einen lang anhaltenden Einfluss und betreffen kritische oder komplizierte Probleme. Dafür sollten Sie explizite Entscheidungskriterien identifizieren und diese auch entsprechend kommunizieren. Hilfreich in diesem Zusammenhang finde ich den Architectural Significance Test von Olaf Zimmermann.
- Weil System oft lange leben, sollten Sie Architektur angemessen kommunizieren und/oder dokumentieren, je nach System mal mehr, mal weniger. Das pragmatische und bewährte Template arc42 erleichtert dies erheblich.
- Architekturstile und -muster (Patterns) geben Orientierung und bieten eine Art Musterlösung. Hierzu zählen beispielsweise Clean Architecture, aber auch Microservices oder Self-contained systems.
- Grundlegende Entwurfsprinzipien, wie Einfachheit, Modularisierung, lose Kopplung und hohe Kohäsion, die Trennung von Verantwortlichkeiten, das Geheimnisprinzip und andere.
- Technische Aspekte, wie Frameworks, Bibliotheken und Programmiersprachen, Protokolle, Netzwerke und Infrastruktur (Cloud, on-premise oder Custom-Hardware). Sie stellen wesentliche Zutaten für Systeme und deren Architektur bereit.
- Methodische Ansätze zur Strukturierung von Systemen, wie Domain-driven Design helfen bei der Identifikation geeigneter Komponenten (siehe oben) und deren Schnittstellen.
- Die Abwägung von make-or-buy, also die Frage, ob ein Team etwas selbst entwickeln oder von Dritten zukaufen soll. Hier spielen neben den klassischen Qualitätsanforderungen auch Themen wie Risikoabwägung, Time-to-Market, Langlebigkeit sowie Lizenz- und Supportkosten eine Rolle.
Jetzt wissen Sie grob, worauf Sie achten sollten, wenn Sie Softwarearchitektur machen wollen. Etwas genauer beleuchten wir das in der nächsten Folge dieser Serie, in der es um die Aufgaben und Aktivitäten der Rolle “Softwarearchitekt:in” geht.
Die wichtigste Regel: Kda
Es kommt drauf an: One size doesn’t fit all. Weder sind Microservices für alle Projekte geeignet, noch löst <Werkzeug X> (ersetzen Sie hier X durch ein beliebiges IT-Werkzeug Ihrer Wahl) sämtliche Probleme. Es gibt in der Software- und Systementwicklung keine universellen Standardlösungen - there is no silver bullet. Viele Muster, Vorgehensweisen, methodische Ansätze oder auch Technologien passen sicherlich häufig gut genug, aber in spezifischen Situationen müssen Sie manchmal auch spezifische Entscheidungen treffen. Es kommt eben darauf an, auf die Situation, das Team und dessen Erfahrungen, Risiken und Kritikalität des Systems, Geld oder Budget, verfügbare Zeit, Technologien, Infrastruktur, Entwicklungs-, Test- und Betriebsprozesse, und sicherlich noch auf andere Faktoren.
Es gehört zur Architekturarbeit, dieses “kommt-drauf-an” in gegebenen Situationen mit konkreten und zur jeweiligen Situation passenden Entscheidungen zu füllen. Aber damit sind wir schon beim Inhalt der nächsten Folge angelangt.
Ausblick
Im dritten Teil dieser Mini-Serien klären wir, welche konkrete Aufgaben oder Tätigkeiten systematisch zu angemessenen Architekturen führen (können).
Bis dahin möge die Macht angemessener Entscheidungen mit Ihnen sein.
Danksagung
Danke an “m”, Martin Weck und Benjamin Wolf für gründliche Reviews!
Bildnachweise
-
Mark Maier, David Emery and Rich Hilliard: Introducing the IEEE 1471, IEEE Computer April 2001, West–Virginia University. ↩