Was ist Systemarchitektur?

Inhaltsverzeichnis

Architektur ist die Beschäftigung mit der Frage, wie man Code strukturiert und orchestriert. Welche Architekturmöglichkeiten gibt es, und welche Vor- und Nachteile haben diese?

Wer sich mit Softwareentwicklung beschäftigt, kümmert sich häufig primär um das Schreiben von Code. Tatsächlich ist das aber nicht alles, sondern es gilt auch, die Struktur des Codes zu planen und zu entwerfen – genau mit diesem Thema beschäftigt sich das große Feld der Architektur.

Grundsätzlich lässt sich Architektur auf System- und auf Softwareebene betreiben. Während sich die Systemarchitektur mit prozessübergreifenden Strukturen und deren Orchestrierung befasst, geht es bei der Softwarearchitektur um die Struktur innerhalb eines Prozesses. Einige Architekturtypen gibt es auf beiden Ebenen, andere nur auf der Ebene der System- oder der Softwarearchitektur.

Die monolithische Architektur

Die einfachste Architektur ist dabei der Monolith – es gibt nämlich nur ein einziges, großes, in sich geschlossenes Gebilde. Der Monolith funktioniert ohne Schichten oder sonstige Struktur, weshalb er am ehesten einer "Nicht-Architektur" entspricht, über die man nicht nachdenken muss, sondern die in gewissem Sinne einfach entsteht.

Client-Server

Der nächstkomplexere Ansatz ist die Client-Server-Architektur, bei der eine Anwendung in zwei Teile zerlegt wird – ein Frontend und ein Backend. In einigen Situationen ist diese Architektur das natürliche Vorgehen, beispielsweise bei der Webentwicklung, die generell die im Webbrowser ausführbare UI von der auf dem Server ausgeführten Geschäftslogik und dem Datenzugriff trennt. Auch mobile Anwendung folgen häufig diesem Ansatz.

Der große Vorteil dieses Ansatzes ist die Möglichkeit, Konsistenz und Integrität an zentraler Stelle kontrollieren und sicherstellen zu können – das ist jedoch zugleich auch der größte Nachteil, denn derartig gestaltete Systeme weisen mit dem zentralen Server einen Single Point of Failure auf, der das System im Vergleich zu anderen Ansätzen anfälliger für Angriffe oder Zensurmaßnahmen macht.

Peer to Peer (P2P)

Eine Alternative dazu stellen P2P-Architekturen dar, die dezentral und verteilt arbeiten, aber gänzlich ohne Server auskommen: Stattdessen sind alle Knoten einander gleichgestellt, und sie tauschen die Daten direkt aus. Eine derart aufgebaute Anwendung nachhaltig zu stören, ist sehr aufwendig, da sich das System um entstandene Löcher sozusagen selbst neue Wege sucht – im Zweifelsfall über andere Knoten.

Historisch gesehen sind P2P-Systeme primär aus den verschiedenen mehr oder minder legalen Tauschbörsen bekannt, die vor allem um die Jahrtausendwende verbreitet waren. Die gleichen Konzepte, Protokolle und Methoden lassen sich aber auch zur Entwicklung von Geschäftsanwendungen verwenden.

Servicebasierte Architektur

Eine Mischung von all dem stellen die verteilten servicebasierten Architekturen dar, die auf der Idee basieren, eine Anwendung in kleinere fachliche Einheiten zu zerlegen, die unabhängig voneinander entwickelt, betrieben, getestet und aktualisiert werden können. Das Grundprinzip ist dabei nicht neu, denn bereits Mitte der 90er-Jahre gab es mit SOA und WOA entsprechende Ansätze, die aber technisch noch sehr aufwendig waren.

Inzwischen stellen Micro- und Nanoservices die gängige Vorgehensweise bei diesem Architekturtyp dar, was häufig zudem mit Serverless-Ansätzen aus der Cloud kombiniert wird. Die Ideen dahinter sind aber nach wie vor die gleichen, nämlich eine Anwendung als einen Verbund von einzelnen, autarken und autonomen Diensten aufzubauen, statt eine einzige große Software zu entwickeln.

tl;dr: Architektur beschäftigt sich mit dem Strukturieren und Orchestrieren von Software und den dazugehörigen Komponenten. Es gibt verschiedene Architekturtypen, die jeweils über individuelle Vor- und Nachteile verfügen – vom Monolith über Client-Server und P2P bis hin zu servicebasierten Architekturen. ()