Was ist eigentlich eine funktionale Architektur?

Ich habe in der Vergangenheit mehrfach funktionale Architekturen erwähnt. Nicht beantwortet habe ich aber die Frage: Was ist überhaupt eine funktionale Architektur, und warum kann diese sinnvoll sein? Darum geht es in diesem Artikel.

Funktionale Architektur entkoppelt von Funktion von Technologie (Twittern)

Grundsätzlich werden bei der Entwicklung immer Funktionen berücksichtigt, bspw. über funktionale Anforderungen. Aber es ist nicht ungewöhnlich, recht schnell bei einem konkreten physikalischen System zu landen. Bei einer funktionalen Architektur wird darauf geachtet,

  • dass die Funktionen als Hauptelemente der Architektur beibehalten werden.
  • dass die Entwicklung des physikalischen Systems ganz klar der funktionalen Struktur untergeordnet ist.

Dieser Ansatz hat zwei Vorteile:

  • Der Architekt kann sich voll und ganz auf die Funktionalität des Systems konzentrieren, ohne dass diese durch eine konkrete technische Lösung verkompliziert wird.
  • Die Architektur ist wesentlich robuster hinsichtlich Technologiewandel.

Beispiel: Fotografie

Ein gutes Beispiel ist das der Fotografie, aus dem Buch Model-Based System Architecture. Bildaufnahmen gibt es bereits seit über hundert Jahren. Die eigentliche Funktion, „ein Bild aufnehmen“, hat sich auch in dieser Zeit nicht geändert. Geändert hat sich lediglich die Technologie, von Lochkamera über Filmkamera mit Linse, zur Spiegelreflexkamera bis zur Handykamera. Auf der funktionalen Ebene besteht Kontinuität trotz Technologiewandel.

Für den Nutzer ist die Funktion wichtig, egal, mit welcher Technologie diese umgesetzt wird. Daher schaffen funktionale Architekturen Kontinuität. (Twittern)

Der Nutzer, der das Bild aufnehmen will, interessiert sich auch nicht für das Innere der Kamera, sondern lediglich für das Ergebnis. Diesbezügliche Erkenntnisse hinsichtlich der Funktionalität können auch bei einer neuen Technologie berücksichtigt werden.

Technologie-spezifische Funktionen

Eine erste funktionale Architektur kann zum großen Teil Technologie-neutral festgehalten werden. Allerdings muss diese im Laufe der Entwicklung weiter verfeinert werden. Und in Rahmen dieser Verfeinerung muss dann doch auf spezifische Technologien eingegangen werden. Hier ist es wichtig, die Funktionen von den technischen Entscheidungen zu entkoppeln. Für diesen Zweck eignet sich das SYSMOD Zigzag pattern. Bei diesem Vorgehen wird stufenweise auf verschiedenen Ebenen gearbeitet. Auf der obersten Ebene würde man möglichst technologieneutral die Funktionen beschreiben. Eine Ebene tiefer werden dann Technologieentscheidungen getroffen. Unterschiedliche Technologien würden zu verschiedenen Varianten führen. Um diese Varianten zu realisieren, müssen neue, Technologie-spezifische Funktionen eingeführt werden.

Funktionale Architekturen unterstützen Varianten-Management (Twittern)

Um bei dem Kamera-Beispiel zu bleiben: Eine technologieneutrale Funktion wäre „Bild aufnehmen“. Bei der Konkretisierung muss eine Technologie ausgewählt werden, also bspw. chemisch (Film) oder CCD-Sensor. Im ersten Fall gäbe es die neue (Technologie-spezifische) Funktion „Filmträger wechseln“. Diese Funktion ist jedoch auch wieder „nach unten“ Technologie-Neutral gehalten. Es bleibt bspw. offen, ob das Filmmaterial auf Rollen oder Platten aufgetragen wurde. Diese Technologie-Entscheidung kann in der nächsten „Zigzag“-Runde getroffen werden.

Praktische Anwendung

Wenn die Prinzipien hinter der funktionalen Architektur erst einmal verstanden sind, ist es nicht schwer, diese Anzuwenden. Schließlich war Funktionalität bei der Systementwicklung schon immer relevant. Neu ist lediglich, das disziplinierte Vertagen der Technologienetscheidungen.

Etwas formaler

In ihrem Buch Model-Based System Architecture beschreiben Tim Weilkiens und Jesko Lamm etwas formaler unter dem Namen FAS einen Ansatz für die funktionale Architektur mit SysML. Dabei wird wie aus der SysML-Modellierung bekannt mit Anwendungsfällen (Use Cases) und Aktivitätsdiagrammen gearbeitet. Neu ist, dass die Aktivitäten in „Funktionale Gruppen“ zusammengefasst werden, und darauf basierend „Funktionale Blöcke“ gebildet werden. Funktionale Gruppen wiederum enthalten funktionale Blöcke. Hier gibt es optional die Möglichkeit, über Operationen noch detaillierter zu modellieren.

Zurück in die physikalische Welt

Da eine reine funktionale Architektur nicht implementiert werden kann, müssen wir das ganze nun in die physikalische Welt bringen. Dabei wird zwischen der logischen Architektur und der Produktarchitektur unterschieden. Die logische beschreibt die physikalischen Konzepte, also bspw. CCD-Sensor. Dann kann die funktionale Architektur auf die logische Architektur abgebildet werden. Die Produktarchitektur schließlich konkretisiert die logische Architektur, also im laufenden Beispiel die Auflösung des Sensors.

Das Abbilden der Funktionen auf Komponenten erfordert einen erfahrenen Architekten. Da auch selten Produkte komplett neu entwickelt werden, gibt es hier in der Regel auch schon viel Vorwissen.

Fazit

Gerade in der heutigen, schnelllebigen Welt kann eine funktionale Architektur einen wesentlichen Wettbewerbsvorteil darstellen. Denn mit einer funktionalen Architektur kann man schnell auf technische Neuentwicklungen reagieren und dabei sicherstellen, dass bereits gewonnene Erkenntnisse in der Funktionalität nicht verloren gehen. Wie formal hier vorgegangen werden soll, ist natürlich eine andere Frage. Allein ein gutes Bewusstsein für funktionale Architekturen hat schon einen hohen Mehrwert. Einen formaleren Ansatz wie die FAS-Methode empfehle ich allerdings nur erfahrenen Teams, die bereits ein gutes Verständnis von Modellierung haben.

 

 

Dieser Artikel erschien zuerst bei se-trends.de.

  • Gast

    Eine verständliche Zusammenfassung und ein gutes Plädoyer für die funktionale Architektur.
    Ich möchte nur auf die Probleme bei der Definition der Funktionen slebst hinweisen:
    Für jede Funktion müssen folgende Fragen beantwortet werden:
    -Welche Ressourcen benötigt die Funktion?
    -Welche Inputs/Outpus hat die Funktion?
    -Welche zeitlichen Anforderungen gelten für die Funktion (Verarbeitungszeit, Durchsatz)?
    -Wieviele Daten müssen vorhanden sein?
    -Wie wird das Vehalten der einzelnen Funktion beschrieben?
    -Ist das Verhalten vollständig bescheibbar oder nur beispielhaft?
    -Welche Fehler kann die Funktion selbst erkennen?
    -Ist die Funktion fehlertoerant bezüglich der Inputs?
    -Welche Fehler kann die Funktion selbst produzieren?
    -Welche Abhängigkeiten zu anderen Funktionen gibt es?

    • Danke für die Liste – die zeigt deutlich, dass funktionale Architektur nicht „ganz ohne“ ist. Tim Weilkien’s Buch geht auch auf einige dieser Aspekte ein.