Grundsätzliches zur Software Architektur

Was ist Softwarearchitektur?

Definition gemäss Wikipedia:

Eine Definition von Helmut Balzert beschreibt den Begriff als „eine strukturierte oder hierarchische Anordnung der Systemkomponenten sowie Beschreibung ihrer Beziehungen“. Die Architekturkomponenten bilden eine Zerlegung des Gesamtsystems, was bedeutet, dass jedes Softwareelement genau einer Architekturkomponente zugeordnet ist.

Paul Clements beschreibt Softwarearchitektur als „Strukturen eines Softwaresystems: Softwareteile, die Beziehungen zwischen diesen und die Eigenschaften der Softwareteile und ihrer Beziehungen“.

Die Softwarearchitektur ist Teil des Softwareentwurfs (siehe SWEBOK), innerhalb dessen sie als Grobgliederung der Komponenten entsteht. Während der Softwareentwurf sich auch auf lokale Aspekte innerhalb des architektonischen Rahmens der Software bezieht und deshalb sehr detailliert sein kann, ist die Softwarearchitektur eine globale Eigenschaft des Gesamtsystems.

Die Rolle des Architekten

Grundsätzlich füllt der Architekt eine Dienstleister Rolle aus. Er erhält von einem Stakeholder (z. Bsp. Kunde) Anforderungen - im Idealfall (in gefühlten 2% aller Fälle) weiss der Kunde bereits genau was er will.

Die Aufgabe des Architekten besteht nun darin, zu Analysieren, wie diese Anforderungen umzusetzen sind. Er berücksichtigt dabei das bestehende Umfeld und vorhandene Werkzeuge (in einem Brownfield Projekt - was vermutlich der Regel entspricht) oder aber evaluiert neue Werkzeuge, mögliche Umsysteme etc. und schafft (bei Greenfield Projekten - was wohl einem Lottogewinn gleich kommt) ein komplett neues Umfeld (Organisation, Guidelines, Prozesse etc.).

Bild 1 veranschaulicht welche Stakeholder den Architekten "benutzen" und dass die Architektur das zentrale Produkt des Architekten darstellt. Der Architekt ist im Entwicklungsteam angegliedert. Es ist nicht ausgeschlossen (ich behaupte sogar: es ist sogar von Vorteil!), dass der Architekt mit dem Rest des Teams das System implementiert - sprich "Der Architekt arbeitet mit am Code!".

Bild 1 - Rolle des Architekten

Der Architekt kümmert sich um Themen wie:

• Strukturen
• • Bausteine und deren Zusammenhänge
  • Systemabläufe
  • Schnittstellen nach Aussen
  • interne Schnittstellen
  • Abhängigkeiten
  • Verteilung (Deployment)
  • ...
• Dokumentation und Kommunikation
• • Aufbau des Wissens und Erhaltung
  • "Verkauf" der Architektur
  • ...
• Technische Konzepte
• • User Expirience (UX)
  • Datenspeicherung
  • Ablaufsteuerung
  • Impl. sog. Businessrules
  • Exceptionhandling
  • Monitoring- & Healthmanagement
  • Verteilung
  • Konfigurierbarkeit
  • Lokalisierung (Internationalisierung)
  • Deployment
  • ...
• Qualität
• • Definiert diese nichfunktionale Anforderungen (NFA) mit Stakeholders
  • • Performance
    • Verfügbarkeit
    • Robustheit
    • Security
    • Flexibilität/Anpassbarkeit
    • Skalierbarkeit
    • Testbarkeit
    • Verständlichkeit
    • Betriebbarkeit
    • ...
  • Definiert Messbarkeit dieser NFA's
  • ...
• Anforderungen
• • Verwaltet die Anforderungen
  • • Verhandelt mit Stakeholden
  • ...
• Entscheidungen treffen
• • zur Struktur
  • zum technischen Konzept
  • Überwacht die Einhaltung und nimmt Korrekturen vor
  • ...

Entstehung der Architektur

Es ist keinesfalls so, dass der Architekt Anforderungen aufnimmt, Abklärungen trifft, Dokumente erstellt und "fertig ist die Architektur". Auch wenn gewisse Projektleiter es gerne sehen würden, dass der Task "Erstellen der Architektur" abgehakt werden kann - aber ist deren Unwissen oder "Beratungsresistenz" unser Problem? Nein! Architektur ist lebendig und wird iterativ (und auch agil) erschaffen - sie begleitet ein Projekt und definiert die Rahmenbedingungen, an welche sich Entwickler zu halten haben. Dem Auftraggeber dient sie als Bestätigung, dass sein Anliegen verstanden wurde. Zugegeben: es gibt Bereiche welche den Auftraggeber vermutlich eher verwirren, als bestätigen. Aber ein bisschen "Magie" darf sein.

In den meisten Fällen - nein, in der Regel - ist es so, dass der Kunde selber nicht genau weiss was er genau möchte. Das liegt zum einen in der Natur der Sache und zum Anderen darin, dass der Kunde sich ja von einem Fachmann (was ein Architekt sein sollte) beraten lassen will und muss und nicht im Stande ist, zu wissen was ein bestehendes System bereits kann. Daher hat man zu Beginn eines Projektes eine gewisse Unschärfe. Diese Unschärfe deckt der Architekt im Laufe seiner Arbeit auf und kann mit Fragen, Verhandlungen, Abklärungen usw. dem Projekt eine gewisse Schärfe verleihen - er "schiesst" auf ein sogenanntes "Moving target". Dadurch erfährt auch die Architektur immer wieder kleine Anpassungen und wächst mit. Im Idealfall stimmen am Ende des Projektes die Architektur mit dem System UND den Kundenanforderungen überein. 25% aller Projekte erfahren gemäss einer internationalen Statistik jedoch nie ein Ende, weil entweder die Anforderungen nie klar werden, das Budget gestrichen wird oder der Aufwand zu gross wird. Es wird auch der Verlust von Motivation als Grund erwähnt (ja das kommt anscheinend wirklich vor!).

Rolle der Architektur

Bild 2 macht deutlich, dass die Architektur wie auch das fertige Produkt (System) Einfluss auf deren Umfeld hat. Was jetzt abstrakt klingen mag bedeutet in der Realität, dass z. Bsp. die Windows Store App "SLUITEN" Einfluss haben wird auf deren Benutzer resp. die Organisationen und Sportvereine, welche diese App einsetzen. Organisationen, welche aufgrund hoher Investitionskosten und technischem Aufwand komplett auf Statistiken verzichten mussten, können mit SLUITEN  und den damit verbundenen sehr kleinen Einstiegshürden, von einem professionellen Werkzeug profitieren. Was dazu führen wird, dass auch im Amateursport vermehrt Ersatzspieler eine spannende und wichtige Aufgabe während eines Spieles erhalten werden.

Bild 2 - Rolle der Architektur (in Anlehnung an

Eine weitere Rolle nimmt die Architektur bei den Entwicklern ein: Sie bildet das Grundgerüst und trägt dazu bei, dass das komplette Team in EINE gemeinsame Richtung arbeitet und dient als Diskussionsgrundlage. 

Wie bereits erwähnt, darf und soll die Architektur sich stetig verändern - das Produkt und die Anforderungen tun dies ja auch. Allerdings soll auch darauf geachtet werden, dass eine Änderung immer aus einer fundierten Motivation entsteht und nicht aus einem Hype heraus oder nur weil ein Entwickler (oder auch der Kunde!) eine "Tischbomben-Idee" hat ... Ebensowenig darf eine Architektur isoliert entstehen und soll keine emotionale Effekthascherei enthalten.

Kontext

Bild 3 zeigt mögliche Einflüsse einer Software Architektur auf die Entwicklung einer Software.

 Natürlich können diese Einflüsse je nach Umfeld, Organisation oder Anforderungen stark varieren. Das zeigt wieder einmal mehr, dass es keine "richtige" oder "falsche" Architektur gibt sondern höchstens "gute" und "schlechte" - und "schlecht" ist sie dann, wenn die Entwickler nicht verstehen was sie tun sollen, der Kunde seine Anforderungen nicht wiedererkennt oder aber viele Fragen offen bleiben.

Fazit

Der Architekt vermittelt mit Hilfe seiner Architektur zwischen Kunde und Entwicklung und stellt sicher, dass sich die Anforderungen in einem tollen Produkt wiederfinden!