Die Grundsteinlegung (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.
• 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:

1. 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.
2. 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!
• 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
• 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.
• 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.
• 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]