Artikel Softwarearchitektur (Teil I)

Eine allgemein akzeptierte Definition des Begriffes „Softwarearchitektur“ existiert nicht, er ist zu stark von unterschiedlichen Standpunkten geprägt. Trotzdem herrscht Einigkeit darüber, dass es die Architektur eines Softwaresystems ist, die maßgeblich dessen Qualität bestimmt. Aber was genau ist Softwarearchitektur und was sind deren Qualitätsmerkmale? Wie lässt sich diese Qualität messen und was müssen Softwarearchitekten und Entwickler tun, um sie in hohem Maße umzusetzen? Und schließlich, was sind die Ziele und der Mehrwert einer guten Architektur, die einen wichtigen wirtschaftlichen Erfolgsfaktor im Unternehmen darstellt?

Was ist Softwarearchitektur?

Diese neue Reihe soll Antworten auf die aufgeworfenen Fragen geben und beleuchten, wie Konzepte, Methoden und Technologien dabei helfen, gute Architekturen zu entwerfen. Dabei bleibt ein Aspekt immer im Fokus: Architektur ist kein Selbstzweck, sondern ein wichtiger Bestandteil einer IT-Unternehmensstrategie und damit ein ernst zu nehmender wirtschaftlicher Erfolgsfaktor. Zunächst gilt es zu klären, was wir unter dem Begriff Softwarearchitektur überhaupt verstehen. Eine allgemein anerkannte Definition wird auch uns nicht gelingen. Es hilft uns aber, für die weiteren Betrachtungen einen Rahmen abzustecken.

„Architecture is about the important things“

In diesem kurzen prägnanten Satz steckt zwar ein wahrer Kern, er wird der Sache aber noch nicht ganz gerecht. Ein Blick auf die vom renommierten Carnegie Mellon Software Engineering Institute (SEI) aus Büchern und Publikationen gesammelten Definitionen (SEI01) zeigt zwar auch kein einheitliches Bild, aber bestimmte immer wieder auftauchende Aussagen und Begrifflichkeiten lassen sich grob wie im Folgenden zusammenfassen:

Architektur ...

... beschreibt die Strukturen eines Softwaresystems auf einem hohen Abstraktionsniveau.

... legt die Strukturen eines Softwaresystems als Komponenten mit (extern sichtbarem) Verhalten und deren Beziehungen untereinander fest, sowie die Schnittstellen, über die die Komponenten interagieren.

... stellt für statische und dynamische Aspekte des Systems einen Bauplan bzw. Ablaufplan dar.

Softwarearchitektur befasst sich also mit den grundlegenden, strukturgebenden Eigenschaften eines Softwaresystems. Damit nimmt sie eine exponierte Stellung mit zentraler Bedeutung für die Entwicklung von Softwaresystemen ein (siehe Abbildung 1).

Abb. 1: Architektur beschreibt ein System mittels Komponenten, die über Schnittstellen interagieren.

Auf der anderen Seite des Bauzauns

Für die Definition der Softwarearchitektur ist es ebenso wichtig zu beschreiben, was Softwarearchitektur nicht ist. Um eine Abgrenzung vornehmen zu können, macht es Sinn sich zunächst einen Überblick über die allgemeine IT-Unternehmensarchitektur zu verschaffen. Die Pyramide in Abbildung 2 zeigt den prinzipiellen Aufbau.

Abb. 2: Architekturpyramide.

In den obersten beiden Ebenen sind die strategischen und organisatorischen Themen im Hinblick auf die IT eines Unternehmens angeordnet. Hier geht es um die Geschäftsstrategien und Prozesse und wie diese im IT Bereich umgesetzt werden. Fragen im Bezug auf das Budget, die Geografie oder das Management des IT-Bereichs werden in diesen Ebenen beantwortet. Mit wenigen Ausnahmen sind dies Aspekte, die für die technisch orientierte Softwarearchitektur die geringste Bedeutung haben. Diese Themenbereiche sind Gegenstand des Enterprise Architecture Managements (EAM) und klar abzugrenzen [2]. In dieser Serie werden wir nicht weiter auf das EAM eingehen. Standortbestimmung Aus der Perspektive der Softwarearchitektur, sind die unteren drei Ebenen der Pyramide interessant.

Die Ebene der Anwendungsarchitektur beinhaltet unsere eigentliche „Baustelle“. Die darüber liegende Ebene der Fach-/Informationsarchitektur beschreibt das Modell der Geschäftsobjekte und die Schnittstellen zu vorhandenen Diensten. Diese Informationen sind zur Erstellung einer neuen Softwarearchitektur ebenso notwendig, wie das Wissen um die technische, physikalische IT-Basisinfrastruktur, welche durch die unterste Ebene repräsentiert wird.

Wird beispielsweise die Architektur für einen Online-Shop entworfen, so benötigt man sowohl Informationen über die anzubietenden Produkte (Modelle aus der Fach-/Informationsarchitektur) als auch über den Standort bzw. die physikalische Anbindung (Protokolle, Bandbreite, Verfügbarkeit etc.), z.B. eines Datenbank- oder Applikationsservers (aus der IT-Basisinfrastruktur).

Eigenschaften von Software

Um uns die Ziele zu verdeutlichen, die wir mit einer guten Softwarearchitektur verfolgen, werden wir zunächst mit der Qualität eines Softwaresystems beschäftigen. Hierzu betrachten wir zwei fundamentale Eigenschaften

von Softwaresystemen:

Architektur kann nicht nicht existieren

Jedes Softwaresystem hat eine Architektur allein dadurch, dass es existiert. Es stellt sich nicht die Frage, ob eine Architektur vorhanden ist, sondern, ob sie gut oder schlecht im Sinne vorgegebener Anforderungen ist. In einem Softwaresystem entsteht und verändert sich Architektur von selbst.

Jedes Softwaresystem hat eine Architektur allein dadurch, dass es existiert. Es stellt sich nicht die Frage, ob eine Architektur vorhanden ist, sondern, ob sie gut oder schlecht im Sinne vorgegebener Anforderungen ist. In einem Softwaresystem entsteht und verändert sich Architektur von selbst. Software altert

Durch fortlaufende Pflege- und/oder Erweiterungsmaßnahmen kann die Software komplex und unübersichtlich werden. Änderungen werden schwierig und führen oft zu neuen Fehlern. Die Software verliert teilweise völlig ihre Wartbarkeit. Häufig werden als Folge mehr oder weniger große Teile eines Systems neu implementiert.

Aus den aufgeführten Eigenschaften ergeben sich für unsere Überlegungen zwei weitreichende Konsequenzen:

In jeder Phase der Entwicklung eines Systems ist es unumgänglich, sich mit dessen Architektur auseinanderzusetzen. Das gilt sowohl für die Planung eines Systems als auch für den gesamten weiteren Lebenszyklus, in dem Architektur weiterentwickelt und angepasst werden muss. Die Architektur muss so entwickelt werden, dass Degenerationsprozesse minimiert und Änderungsprozesse unkompliziert durchzuführen sind. Eine aktive Kontrolle ist notwendig, damit die Architektur sich nicht verselbstständigt. Damit wird die Motivation und Notwendigkeit zum planvollen Umgang mit der Softwarearchitektur klar. Wodurch zeichnet sich eine gute Architektur im Detail aus?

Indikatoren schlechter Architektur

Wir gehen das Problem von der anderen Seite an und sehen uns Phänomene an, die Hinweise auf eine schlechte Architektur liefern:

Es ist schwierig, einen Überblick über das Gesamtsystem zu gewinnen.Das System weist eine • Komplexität auf, die kaum noch beherrschbar ist.

Geringe Änderungen an den Anforderungen führen zu großen Anpassungsaufwänden.

Die Performance ist schlecht.

Fehlerbehebungen in einem Teil der Software führen zu neuen Fehlern in anderen Teilen.

Die Entwickler sind nicht in der Lage korrekte Aufwandsschätzungen abzugeben.

Die Wiederverwendung und Integration gestaltet sich schwierig.

Die Ursachen dafür können vielfältig sein und von Fall zu Fall variieren, aber die Praxis zeigt, dass es meistens die üblichen Verdächtigen sind:

Es gibt keine definierten Verantwortlichkeiten einzelner Systemteile, einzelne Funktionalitäten sind über mehrere Bereiche verteilt.

Es gibt zu viele Abhängigkeiten zwischen den Teilen eines Systems.

Fachliche und technische Aspekte des Systems sind vermischt.

Der Quellcode weist Redundanzen auf, ist unsauber oder unklar.

Das System ist schlecht bzw. gar nicht testbar.

Prinzipien guter Architektur

Um den genannten Problemen entgegenzuwirken, ist es unerlässlich einige Prinzipien zu berücksichtigen, die sich beim Entwurf von Softwarearchitekturen und -systemen bewährt haben:

Keep it simple and stupid (KISS)

Eine alte Regel lautet: „Mache es so einfach wie möglich!“. Sie sollte sogar dahingehend interpretiert werden, dass alles ausgelassen wird, was aktuell nicht zwingend benötigt wird. Strukturen, die nicht existieren, können keine Fehler enthalten!

Eine alte Regel lautet: „Mache es so einfach wie möglich!“. Sie sollte sogar dahingehend interpretiert werden, dass alles ausgelassen wird, was aktuell nicht zwingend benötigt wird. Strukturen, die nicht existieren, können keine Fehler enthalten!

Don‘t repeat yourself (DRY)

Treten bestimmte Probleme an verschiedenen Stellen wiederholt auf, ist das ein deutlicher Hinweis darauf, dass es sich um Aspekte von erhöhter Wichtigkeit für das Gesamtsystem handelt. Das muss sich in einer Architektur durch besondere Maßnahmen widerspiegeln

Treten bestimmte Probleme an verschiedenen Stellen wiederholt auf, ist das ein deutlicher Hinweis darauf, dass es sich um Aspekte von erhöhter Wichtigkeit für das Gesamtsystem handelt. Das muss sich in einer Architektur durch besondere Maßnahmen widerspiegeln

Trennung der Verantwortlichkeiten (Separation of concern)

Jede Komponente als kleinste Einheit eines Systems sollte nur für einen klar definierten Aspekt zuständig sein. Dieser Aspekt sollte besonders bei der Trennung von fachlichen und technischen Belangen berücksichtigt werden.

Jede Komponente als kleinste Einheit eines Systems sollte nur für einen klar definierten Aspekt zuständig sein. Dieser Aspekt sollte besonders bei der Trennung von fachlichen und technischen Belangen berücksichtigt werden.

Lose Koppelung

Durch die Interaktion von Komponenten entstehen Abhängigkeiten. Um spätere Veränderungen zu vereinfachen, dürfen diese Abhängigkeiten nicht zu stark sein. Insbesondere zyklische Abhängigkeiten sollten unter allen Umständen vermieden werden.

Durch die Interaktion von Komponenten entstehen Abhängigkeiten. Um spätere Veränderungen zu vereinfachen, dürfen diese Abhängigkeiten nicht zu stark sein. Insbesondere zyklische Abhängigkeiten sollten unter allen Umständen vermieden werden.

Hohe Kohärenz

Innerhalb einer Komponente sollte es einen starken Zusammenhalt (Kohärenz) geben. Alle Strukturen, die die Komponente zur Erledigung seiner Aufgaben benötigt, sollten sich idealerweise auch innerhalb der Komponente befinden. Das reduziert Abhängigkeiten zu anderen Komponenten. Kohärenz ist demnach auch Folge loser Koppelung. Veranschaulicht wird das Zusammenspiel in Abbildung 3.

Abb. 3: Starke Kopplung mit geringer Kohäsion (links), Lose Kopplung mit hoher Kohäsion (rechts).

Offen/Geschlossen-Prinzip

Komponenten sollten offen für Erweiterungen,aber geschlossen für Änderungen sein. Das bedeutet, dass Komponenten so gestaltet werden, dass sie nur durch Hinzufügen von Elementen erweitert werden können, ohne dass Veränderungen an vorhandenen Strukturen durchgeführt werden müssen. Die Folge ist, dass zukünftige Erweiterungen keinen Einfluss auf die bestehende Funktionalität der Komponente haben, da diese nicht modifiziert wird.

Qualitätsmerkmale

Werden die genannten Prinzipien beim Entwurf einer Architektur berücksichtigt, lassen sich die wesentlichen Qualitätsmerkmale eines Softwaresystems gezielt steuern. Die Qualitätsmerkmale definieren die wichtigsten funktionalen und nichtfunktionalen Anforderungen, die an ein System gestellt werden:

funktionale (fachliche) Anforderungen Funktionalität

Das System implementiert alle geforderten fachlichen Funktionen in korrekter Weise

nichtfunktionale Anforderungen Performanz

Das System arbeitet mit ausreichender Geschwindigkeit und liefert die Ergebnisse im vorgegebenen Zeitrahmen. Erweiterbarkeit/Wartbarkeit

Korrekturen und Erweiterungen am System lassen sich mit vorhersagbarem Aufwand durchführen. Zuverlässigkeit

Das System arbeitet ohne Abstürze, Fehlersituationen werden in vorgegebener Art und Weise behandelt. Wiederverwendbarkeit

Teile des Systems können innerhalb oder von externen Systemen mehrfach verwendet werden. Verfügbarkeit

Das System arbeitet unter festgelegten Lastbedingungen mit vorhersagbarer Leistung ohne Störungen und Ausfälle. Skalierbarkeit

Die Leistung des Systems kann durch Hinzufügen weiterer Komponenten (Software, Hardware, Infrastruktur etc.) um ein definiertes Maß gesteigert werden.

Durch die Steuerung der Qualitätsmerkmale kann die Architektur entsprechend den priorisierten Anforderungen an das Softwaresystem ausbalanciert werden. Es können nicht alle Merkmale in gleicher Weise optimiert werden. Wie Abbildung 4 zeigt (die Anordung ist beispielhaft, diese kann variieren), wirken einige Merkmale einander entgegen.

Abb. 4: Architektur im Kräftefeld der Anforderung.

Die Architektur steht im Kräftefeld der Anforderungen.Ein System, das auf Wartbarkeit und Erweiterbarkeit optimiert ist, wird (z.B. auf Grund zusätzlich notwendiger Softwareschichten) weniger hohen Maßstäben im Bezug auf Performanz entsprechen.

Ziele guter Architektur

Gelingt es, die genannten Qualitätsmerkmale im Kontext eines Anforderungskataloges auf hohem Niveau umzusetzen, resultiert daraus eine Architektur, die folgende Möglichkeiten eröffnet:

Einschätzung, Vorhersage und Steuerung von Qualitätsmerkmalen.

Reduzierung von Fehlern und Ausfällen.

Bessere Vorhersage von Änderungsaufwänden (Zeit und Kosten).

Schnelle Umsetzung neuer Anforderungen (Time to Market).

Effizienter Betrieb (Verfügbarkeit und Verteilung).

Vorhersage und Einschätzung von Risiken

Grundlage zur Kommunikation mit allen Beteiligten

In diesen Aspekten liegt das eigentliche Potential. Die Fähigkeit gute Softwarearchitekturen zu entwerfen, führt zu besseren Softwaresystemen und effektiveren IT-Landschaften. Der gewonnene Mehrwert spiegelt sich in Wettbewerbsvorteilen und somit auch in wirtschaftlichen Erfolgen wider. Softwarearchitektur ist kein Selbstzweck.

Architekturrelevante Themen

Durch welche konkreten Konzepte, Methoden und Technologien sich die genannten Ziele erreichen lassen wird Gegenstand weiterer Artikel sein.

Dazu werden wir die Rolle des Softwarearchitekten genauer beleuchten und unterschiedliche Architekturstile und Patterns betrachten. Wir werden die Wichtigkeit von Dokumentation und Kommunikation darstellen und aufzeigen, wie Architektur-Review-Methoden zur Qualitätssicherung beitragen. Desweiteren wollen wir natürlich einen Blick auf die rein technologischen Aspekte werfen

und auch immer wieder die aktuellen Trends und Hypes kritisch unter die Lupe nehmen.

Fazit

Nach Grady Booch ist Softwarearchitektur das, was aufwändig und teuer ist, wenn es nachträglich korrigiert werden muss. In jedem Unternehmen sollte deshalb berücksichtigt werden, dass die Softwarearchitektur der entscheidende Erfolgsfaktor bei der Entwicklung komplexer IT-Systeme ist. In anspruchsvollen Entwicklungsprojekten fällt dabei dem Softwarearchitekten die zentrale Rolle zu. In folgenden Artikeln werden wir diesen Gedanken weiter verfolgen und zeigen, welcher Mehrwert in guten Softwarearchitekturen steckt.

[hier gehts zu Teil II] [zum Seitenanfang]

Erfolgreiche Softwarearchitektur

Die arc42-Methode

arc42 ist systematisch aber flexibel. Passend für große und kleine Teams in iterativen oder weniger agilen Prozessen. mehr dazu... arc42 Lesestoff

Es gibt viel zu lesen über arc42 und Architektur. Von der Methode über good practices bis hin zu kompletten Beispielen von Softwarearchitekturen.

Stöbern Sie in unseren Büchern, Artikeln, Vorträgen oder Videos. mehr dazu... Consulting

Wir helfen in allen Lebenslagen Ihrer IT-Projekte weiter.

Lesen Sie mehr über unsere Angebote an Beratung, Reviews oder praktische Unterstützung für Ihre Projekte. mehr dazu...

arc42 basiert auf der praktischen Erfahrung vieler Systeme in verschiedenen Bereichen, von Informations- und Websystemen über Echtzeit- und Embedded-Systeme bis hin zu Business Intelligence und Data Warehouses.

arc42 bietet eine Vorlage für die Dokumentation und Kommunikation von Software- und Systemarchitekturen.

arc42 unterstützt beliebige Technologien und Werkzeuge.

arc42 ist vollständig prozessagnostisch und eignet sich besonders gut für schlanke und agile Entwicklungsansätze.

arc42 ist Open-Source und kann sowohl im kommerziellen als auch im privaten Bereich kostenlos genutzt werden. Details finden Sie auf unserer Lizenzseite.

Basiswissen für Softwarearchitekten

Auf der OOP-Softwarekonferenz 2019 in München habe ich ein Gespräch mitbekommen, in dem der Satz fiel: „Basiswissen für Softwarearchitekten ist die Bibel der Softwarearchitektur.“ Eine vielversprechende Aussage, oder? Schauen wir mal, ob wir ihr unseren Segen geben können.

Basiswissen für Softwarearchitekten verspricht eine kompakte Einführung in die Welt der Softwarearchitektur und die Aufgaben der Softwarearchitekt:innen zu sein. Praxisnah und einsteigerfreundlich geschrieben, vermitteln Mahbouba Gharbi, Arne Koschel, Andreas Rausch und Gernot Starke auf 238 Seiten wichtige Begriffe und Konzepte sowie das technische und methodische Handwerkszeug, um Softwarearchitekturen zu entwerfen.

Softwarearchitektur ist die „Königsdisziplin des Software Engineering“, so Ernst Denert. Mit einer Softwarearchitektur, die 1. nicht die Anforderungen der Nutzer:innen und Kundinnen erfüllt, die 2. nicht stabil und anpassungsfähig konstruiert wurde und 3. unstrukturiert ist, ist ihr Softwareprojekt von Beginn an zum Scheitern verurteilt. Damit Ihnen genau das NICHT passiert haben die Autor:innen einen Leitfaden geschaffen, der Sie an die Hand nimmt und sicher ans Ziel führt: Mithilfe von Sichten, Architekturmustern und technischen Konzepten Softwarearchitekturen dokumentieren und kommunizieren sowie die Grundlagen des Architekturentwurfs verstehen, um selbst eine Softwarearchitektur für kleine und mittlere Systeme zu entwerfen.