Perspektivwechsel als Methode

TL;DR

• Perspektiven fokussieren jeweils auf bestimmte Aspekte eines Systems und blenden andere bewusst aus. Das ist das Prinzip Separation of Concerns.
• Jede Sicht liefert Erkenntnisse, die die anderen nicht liefern: Die Gästeliste kippt das Dessert, der Zeitplan verlangt vier Herdplatten, die Küche hat aber nur zwei.
• Auch die Gebäudearchitektur arbeitet seit Langem mit getrennten Perspektiven und iteriert zwischen ihnen. Standards wie RIBA und HOAI schreiben das sogar formal vor.
• Fürs Software-Engineering schlägt arc42 fünf hilfreiche Sichten vor: Außensicht, Bausteinsicht, Laufzeitsicht, Verteilungssicht und Querschnittskonzepte.
• Sichten sind ein Werkzeug zum Entwerfen und Entscheiden, nicht nur zur Dokumentation.

Sichten oder Perspektiven gehören zu den wichtigen methodischen Werkzeugen in Engineering-Disziplinen. Sie helfen sowohl bei der Konstruktion von Systemen als auch bei deren Dokumentation und Kommunikation.

Fangen wir mal mit einer ganz anderen Aufgabenstellung an:

Hilfe, die Familie kommt zu Besuch

Tante Trude und Onkel Otto haben sich mit ihren Kindern Mira (7) und Timo (5) für den kommenden Samstag bei uns, Ulrike und Gernot, zum Mittagessen angekündigt. Sie bringen Oma Maria und Schwager Tim mit.

Unsere Challenge: Ein vernünftiges Mittagessen für alle.

Die Grundidee (Parti)

(ihr kennt das Wort Parti nicht? Seid geduldig, erkläre ich gleich).

Ein Sommermenü in drei Gängen, alles frisch, alles zeitgleich serviert.

Ganz spontan fällt uns dieser sommerliche Salat aus Wassermelone und Fetakäse als Vorspeise ein, und als Hauptgericht dann Lachs mit Sahnesoße und Bandnudeln. Dazu als Nachtisch eine leckere Panna-Cotta mit Erdbeersauce.

Ein Parti heißt in der Gebäudearchitektur die „erste Lösungsidee" oder „grobe Skizze". Gehen wir mit unserer Menü-Idee systematisch an die Verfeinerung:

Dazu wählen wir mal die Gäste-Perspektive, und zählen auf, wer was mag oder verträgt.

Gast	Fisch	Fleisch	Fetakäse	Milchprodukte
Tante Trude	❌	✅	✅	❌
Onkel Otto	✅	✅	❌	✅
Mira (7)	❌	❌	✅	✅
Timo (5)	❌	✅	❌	✅
Oma Maria	✅	✅	❌	✅
Schwager Tim	❌	❌	❌	❌
Gernot	✅	✅	✅	✅
Ulrike	✅	✅	✅	❌

Hmm, das ist kompliziert, leider passt unsere erste Idee nicht für alle Gäste!

Schon klar, bei engen Verwandten würdet ihr im Kopf diese Prüfung (wer mag was?) direkt beim Brainstorming der Gerichte durchführen. Hier möchte ich den expliziten Perspektivenwechsel als methodischen Ansatz vorstellen, daher betrachten wir einige solcher „Blickwinkel" bewusst nacheinander.

Aufgrund der diversen „mag-etwas-nicht" oder „verträgt-etwas-nicht" müssen wir unsere initiale Vorstellung anpassen: Beim Wassermelonensalat müssen wir den Feta getrennt servieren (damit z.B. Otto, Timo, Maria und Tim ihre Vorspeise ohne Fetakäse genießen können).

Trude, Tim, Ulrike und die Kinder brauchen eine Alternative zum Lachs, also gibt es Veggie-Burger mit Pommes. Die Panna-Cotta müssen wir durch ein milchfreies Dessert ersetzen, sagen wir Mango-Sorbet.

Erste Iteration geschafft

Der Menüplan ist verfeinert, alle Beteiligten bekommen etwas für sie Passendes vorgesetzt. Jetzt zur nächsten Perspektive, der Beschaffung der Lebensmittel. Unsere favorisierte Händlerin führt leider keine Tiefkühlkost, und zum nächsten Supermarkt ist es ziemlich weit weg. Da wir unser Auto aktuell verliehen haben, stehen wir jetzt vor einem weiteren Problem: Wir haben zwar die Gerichte auf Gästetauglichkeit überprüft, aber der Einkauf der Zutaten stellt sich als komplett anderes Problem heraus. Aber: Wir können glücklicherweise auf nette Nachbar:innen zurückgreifen, die für uns alle notwendigen Zutaten mitbringen.

Nach der Beschaffung kümmern wir uns jetzt um die Herstellung des Menüs, also der Planung von Vor- und Zubereitung. Da wir die Hauptgerichte zeitgleich servieren möchten, und sowohl Lachs, Nudeln wie auch Pommes auf den Punkt zubereitet werden müssen, ist hier Koordination gefragt.

Auch wieder klar, für ein kleines Mittagessen ist ein grafischer Projektplan overkill, aber hier geht’s mir um den Wechsel der Perspektive: Bringen wir die notwendigen Arbeiten mal auf eine Zeitachse (siehe Abbildung 3).

Es fällt auf (anders gesagt: Es wird explizit sichtbar!), dass wir für die Hauptgerichte mehrere Dinge parallel erledigen müssen, insbesondere müssen wir Lachs und Veggie-Burger parallel braten.

Wechseln wir nochmals die Perspektive, und schauen auf die Gegebenheiten unserer (kleinen) Küche (aka Infrastruktur) sowie die Verfügbarkeit passender Gerätschaften: Laut der Zeitplanung aus Abbildung 3 benötigen wir vier Herdplatten für die gleichzeitige Zubereitung von Lachs, Veggie-Burgern, Nudeln und Soße.

Leider verfügt unsere Küche aber nur über 2 Herdplatten. Wir besitzen auch nur eine einzige Pfanne. Den Lachs im Ofen zu grillen funktioniert nicht, da wir den Ofen ja schon für die Pommes benötigen. Beides gleichzeitig klappt nicht, weil die Pommes den Ofen mit 200 °C Heißluft benötigen, der Lachs für sanfte Zubereitung aber höchstens 120 °C verträgt.

Nächste Erkenntnis: Unser Kühlschrank hat kein Eisfach, was die Idee vom Mango-Sorbet hinfällig macht.

Ja, und ihr habt schon wieder Recht: Kochen ist anders als Engineering. Beim Essen mit der Familie kommen wir auch ohne explizite Perspektivwechsel (manchmal mit etwas Stress verbunden) zu akzeptablen Lösungen.

Perspektiven bringen spezifische Erkenntnisse

An diesem kleinen Beispiel solltet ihr erkennen, dass verschiedene Perspektiven auf ein- und dasselbe System ganz unterschiedliche Arten von Erkenntnissen und Feedback liefern können.

Jede einzelne Perspektive fokussiert auf bestimmte Sachverhalte, und lässt dafür andere Themen außer Acht. Das grundlegende Prinzip von Separation of Concerns gilt auch für methodischen Entwurf von Systemen.

Bleibt die Frage, ob wir in der Softwareentwicklung wirklich verschiedene Sichten brauchen, und ob uns Perspektivenwechsel dabei helfen kann, angemessene oder bessere Entscheidungen zu treffen?

Meine Meinung und Erfahrung dazu ist ein deutliches „Ja, klar". Als Begründung unterbreite ich einen Vorschlag für hilfreiche Sichten im Software-Engineering. Einige davon kennt ihr schon aus unserer Küche: Die Beschaffung über die Nachbar:innen entspricht der Außensicht, unser Zeitplan der dynamischen Sicht, und die zu kleine Küche der Infrastruktur.

Dieser Vorschlag stammt aus dem bewährten und verbreiteten arc42-Framework[1]. Die konzeptionellen Grundlagen dafür hat Philippe Kruchten bereits 1995 mit seinem 4+1 View Model gelegt[2], Simon Brown greift erhebliche Teile davon in seinem C4-Model auf. Sehr ausführlich, mit etwas anderem Schnitt der Sichten, beschreiben Nick Rozanski und Eoin Woods solche Sichten in ihrem Standardwerk[3].

Wesentliche Sichten im Software-Engineering

• Außensicht: Externe Schnittstellen (arc42: Kontextabgrenzung)
• Innensicht: Sub- oder Teilsysteme, Komponenten und interne Schnittstellen (arc42: Bausteinsicht)
• Dynamische Sicht: Wesentliche Abläufe (arc42: Laufzeitsicht)
• Infrastruktur, Hardware, Betriebsplattform (arc42: Deployment- oder Verteilungssicht)
• Welche Technologien (etwa: Frameworks, Bibliotheken, Programmiersprachen) kommen wie und wo zum Einsatz? Wie sind im System übergreifende Aufgaben gelöst, wie etwa Testing, Konfiguration, Deployment oder Ähnliches (arc42: Querschnittskonzepte)

Damit das nicht zu abstrakt bleibt, begleitet uns ein Beispiel: Nehmen wir an, ihr baut eine Anwendung, die sich auf Filme und Filmkritiken/-rezensionen spezialisiert hat, nennen wir sie CineScope-NE (für non-existing). Viele Daten über Filme und Serien bekommt ihr über öffentliche Quellen, möchtet aber auch den brandneuen und (erfundenen) Streamingdienst moviePedia integrieren. Die Leute hinter dieser fiktiven Filmsammlung geben euch Daten preiswert, dafür müsst ihr allerdings mit ihrem spannenden Set an Datenformaten umgehen:

• DICOM (Digital Imaging and Communications in Medicine) für die Trailer (das Format verwenden z.B. viele Röntgengeräte)
• Rezension, Inhaltsangaben, sonstige Informationen als proprietäres PID-Format (Private Data Stream), ASN.1 mit UPER (Unaligned Packed Encoding Rules), codiert mit einer filmspezifischen Grammatikdatei.

Solche, fast boshaften, Formate bietet das reale Leben zuhauf.

Die Außensicht (Kontextabgrenzung)

Die Außensicht zeigt die externen Schnittstellen unseres Systems. Welche Nachbarsysteme liefern oder erwarten Daten von unserem System? Das können beliebige Dinge sein, Daten, Dateien, Events, Dokumente; was immer unser System liefern oder konsumieren muss.

Die Außensicht trennt unseren Einflussbereich (unser System, unsere Spielwiese) vom Rest der Welt: Unser System kommuniziert über genau diese Außenschnittstellen mit seinem Umfeld. Auf die Nachbarsysteme haben wir als Entwicklungsteam keinen oder nur sehr mittelbaren Einfluss: Von Nachbarn angebotene Schnittstellen müssen wir konsumieren, ob uns die jeweiligen Datenformate nun gefallen oder nicht. Umgekehrt: Wenn wir einem Nachbarsystem ein bestimmtes Datenformat anbieten, können wir unter Umständen dieses Format nicht einfach ändern, ohne diesen Nachbarn sehr zu verärgern 😬

In unserem Beispiel treten die öffentlichen Filmdatenbanken sowie die seltsame moviePedia als externe Systeme auf, dazu Filmfans und Redaktion als Nutzer (siehe Abbildung 6).

Die Innensicht (Bausteinsicht)

Für Software- oder IT-Systeme wollen Stakeholder oftmals deren strukturellen Aufbau sehen und verstehen, also die inneren Bestandteile des gesamten Systems sowie deren Abhängigkeiten. Das typische Kästen-und-Pfeile-Diagramm, mit Subsystemen, Komponenten oder wie auch immer die Bestandteile eines Systems so genannt werden.

Diese Innensicht bildet die Grundlage der Aufgabenverteilung auf Entwicklungsteams oder Personen oder Make-or-Buy-Entscheidungen. Methoden wie Domain-Driven Design zielen darauf ab, eine der fachlichen Aufgabenstellung möglichst adäquate Innensicht (Context Map) zu entwerfen.

Viele der publizierten Architekturmuster (architecture patterns) wie etwa Schichten, Pipes-and-Filters, Clean-Architecture fokussieren auf diese statische Perspektive.

Falls ihr euch immer noch fragt, ob wir diese verschiedenen Perspektiven wirklich zum Entwerfen oder Entscheiden benötigen (und nicht nur als Dokumentation): Schaut euch nochmal CineScope-NE an. Die abstrusen Formate von moviePedia haben immense Konsequenzen für eure Innensicht, weil ihr sehr spezielle Bausteine und Funktionalitäten implementieren müsst, die ihr ohne diese Außenschnittstelle nicht hättet. Ihr könnt also die Innensicht nicht ohne Kenntnis der Außensicht entwerfen. Konkret braucht ihr im Inneren einen DICOM-Adapter sowie einen Parser für das PID-Format.

Dynamische Sicht

Wann genau innerhalb eines Systems welcher Baustein (Subsystem, Komponente o. Ä.) seine Aufgaben erfüllt, können wir aus einer rein statischen Sicht (etwa: Bausteinsicht) nicht entnehmen. Ob eine interne Schnittstelle zwischen Bausteinen ein- oder hunderte Male verwendet wird, verschweigt die Bausteinsicht.

Falls die Reihenfolge von Verarbeitungsschritten wichtig für das Verständnis eines Systems (oder Teilen davon) ist, hilft eine dynamische Sicht.

Abbildung 7 zeigt, wie CineScope-NE neue Rezensionen von moviePedia importiert. Nur diese Sicht verrät, wer den Ablauf steuert, dass vor dem Abruf eine Authentisierung nötig ist und wer die Indexierung triggert.

Infrastruktur

Software benötigt technische Infrastruktur (Prozessoren, Speicher, Netzwerk, sonstige I/O Geräte), damit überhaupt etwas abläuft. Diese Infrastruktur kann erhebliche Auswirkungen auf die Innensicht oder auch auf Abläufe haben.

Spezielle Hardware kann Funktionen übernehmen (etwa: Video-Codierung/Kompression, Gesichtserkennung, Audio-Rauschunterdrückung, Ethernet-Paket-Timing und andere), für die ansonsten aufwändige Software (sprich: Elemente der Innen- oder Bausteinsicht) notwendig wäre.

Detaillierte Kenntnis der technischen Infrastruktur und deren Leistungsmerkmale hat damit direkten Einfluss auf Baustein- und Implementierungsentscheidungen.

Ein weiterer Aspekt beim Zusammenhang zwischen Infrastruktur und Bausteinen besteht in der (physischen) Verteilung: Kommunikation zwischen verteilten Bausteinen verhält sich signifikant anders als Kommunikation innerhalb einer einzelnen Laufzeitumgebung: Neben höherer Latenz (Milli- statt oftmals Nanosekunden) kommen in verteilten Umgebungen völlig neue Fehlerquellen ins Spiel.

Bei CineScope-NE läuft der Import als eigener Worker, denn das Umwandeln von DICOM-Trailern ist rechenintensiv und soll den Rest nicht ausbremsen.

Technologie und andere Querschnittsthemen

Querschnittsthemen, wie etwa Persistenz (Datenspeicherung), grafische Benutzungsschnittstellen, Monitoring/Observability, Konfiguration und andere übergreifende Themen bestimmen in hohem Maße mit über Details der Bausteinsicht respektive der internen Abläufe (also der dynamischen Sicht).

Falls eure Datenbank beispielsweise über Mechanismen wie Indexierung, Volltext- oder semantische Suche verfügt, braucht ihr das nicht in der Bausteinsicht zu implementieren. Bietet die Datenbank von CineScope-NE schon Volltextsuche, schrumpft unser Suche-Baustein auf eine dünne Hülle. Und die Benutzungsoberfläche steckt bei CineScope-NE als Querschnittskonzept in jedem fachlichen Baustein (siehe Abbildung 6).

Damit möchte ich den Schnelldurchgang relevanter Architektursichten beenden. Jede Sicht hat bei CineScope-NE etwas gezeigt, das die anderen weg-abstrahieren (aka: verschweigen): die Außensicht die abstrusen Formate, die Innensicht die Adapter dafür, die Laufzeitsicht die Authentisierung. Genau das meine ich mit Perspektivwechsel als Methode. Weitere Beispiele für inhaltlich notwendige und sinnvolle Zusammenhänge dieser Sichten fallen euch sicher selbst ein. Mir ging es ja eher um den prinzipiellen Einsatz verschiedener Perspektiven (oder Sichten) als konstruktives Mittel beim Entwurf von Software, als eine Grundlage für systematische Architekturentscheidungen.

Exkurs: Das machen die Bauleute schon lange

Zum Abschluss noch ein kurzer Blick über den Tellerrand. Die IT hat das Wort „Architektur" aus einer sehr alten und etablierten Disziplin entlehnt, der Konstruktion von Gebäuden. Dort gibt es die Separation of Concerns (sprich: verschiedene Perspektiven) schon lange, in Form unterschiedlicher Arbeitsschritte und Pläne.

Viele (insbesondere neuartige oder stilistisch ausgefallene) Gebäude beginnen ihre Existenz mit einem Parti (auch genannt parti pris), einer ersten, oftmals skizzenhaften Idee[4].

Von einer solchen Skizze bis zum fertigen Gebäude braucht es natürlich noch viele Schritte und Detailentscheidungen. Im Bauwesen (zumindest in Deutschland) hat das alles seine behördlich geregelte Ordnung. Die Konkretisierung erfolgt aus mehreren Perspektiven und durch verschiedene Stakeholder: Die Architektur- oder Objektplanung kümmert sich um Räume, Nutzung und Gestaltung, die Tragwerksplanung um die tragende Konstruktion. Fachplanungen wie Brandschutz, Elektro oder Lüftung geben Feedback, etwa „der Fluchtweg ist zu lang". Die Architekturplanung übernimmt die Rückmeldungen in den Gesamtentwurf, die anderen prüfen erneut, bis eine gemeinsame, genehmigungsfähige Lösung vorliegt. Im Software-Engineering nennen wir das iteratives Arbeiten.

Perspektiven im Bauwesen

Das britische Royal Institute of British Architects (RIBA) hat bereits 1963 einen plan of work für die Projektierung und Umsetzung von Gebäudeprojekten veröffentlicht, und seither mehrmals aktualisiert, siehe RIBA-Overview. Darin kümmern sich verschiedene Stakeholder um jeweils spezifische Belange, nehmen damit spezifische Perspektiven ein: etwa Nachhaltigkeit, Recht, Sicherheit (Safety), Finanzen, Tragwerk, Innen- und Landschaftsarchitektur oder Brandschutz.

RIBA gilt als Vorbild diverser internationaler Standards im Bauwesen. Ähnliche Ansätze verfolgt unter anderem die deutsche Honorarordnung für Architekten und Ingenieure (HOAI), die Bauprojekte in gefühlt unendlichem Detailgrad in Teilaufgaben aufschlüsselt.

Kurz: Perspektiven gelten im Bauwesen als derart wesentlich, dass sie in vielen Staaten in Standards und Verordnungen geregelt sind.

Mit unseren Sichten in der Software sind wir also in guter Gesellschaft, und mit ISO/IEC/IEEE 42010 gibt es dafür inzwischen sogar einen eigenen Standard[5].

Quellen / Referenzen

1. Das Architektur-Template arc42 enthält vier Sichten (Kontextabgrenzung, Baustein-, Laufzeit- und Verteilungssicht), und als weitere Perspektive noch die querschnittlichen Konzepte, die oftmals die konkrete Anwendung von Technologien erklären.  ↩︎

2. Philippe Kruchten: The 4+1 Model  ↩︎

3. Nick Rozanski, Eoin Woods: Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives. Addison-Wesley 2005. Die Autoren haben mit ihrem Buch die Idee der Sichten (bei ihnen Viewpoints) für die Softwarearchitektur systematisch ausgearbeitet und konsequent an den Bedürfnissen der Stakeholder ausgerichtet, ganz im Sinne des Perspektivwechsels aus diesem Artikel. Achtung, Begriffsfalle: Was bei Rozanski/Woods Perspective heißt, sind übergreifende Qualitätseigenschaften wie Sicherheit oder Performance, die quer über alle Sichten wirken. Das entspricht eher den Querschnittskonzepten bzw. Qualitätsanforderungen von arc42 als meinem Gebrauch von „Perspektive“ als Synonym für „Sicht“.  ↩︎

4. Gregor Hohpe über „Architekturskizzen"  ↩︎

5. ISO/IEC/IEEE 42010:2022, Software, systems and enterprise — Architecture description (ISO, IEEE), Nachfolger von IEEE 1471:2000. Die Norm legt fest, wie Architekturbeschreibungen aufgebaut sind: Ausgehend von Stakeholdern und ihren Belangen (concerns) definieren Viewpoints, welche Sicht für wen mit welchen Mitteln entsteht. Damit hat auch die Software ihren Standard für Sichten, ähnlich wie RIBA und HOAI für das Bauwesen, allerdings (zum Glück) ohne behördliche Verpflichtung. Eine frei zugängliche Erklärung (ohne Paywall) gibt es auf quality.arc42.org.  ↩︎