Heute schon gekontextet?

Der Kontext eines Systems beschreibt dessen Zusammenhang zu seiner Umgebung. Für Software kann das unterschiedliche Dinge bedeuten:

• Fachlicher Kontext
• Technischer Kontext
• Entwicklungskontext

Im Kontext finden wir sowohl die Nutzer von Systemen, wie auch dessen externen Schnittstellen. Alle Ereignisse und Daten die ein System produziert oder konsumiert sind im Kontext enthalten.

Kontext schafft Überblick

Stellen Sie bitte eine völlig verrostete Schraube vor – festgeschraubt in einer ebenfalls mit Rost überzogenen Metallplatte. Das Ganz ist von Spinnweben bedeckt und ziemlich staubig…. Sie inspizieren dieses Stilleben aus der Nähe, sozusagen bildfüllend.

Jetzt suchen wir mal nach Problemen und Lösungen: Als mögliche Verbesserungsvorschläge springen Rostentferner und eine Drahtbürste ins Auge, mit deren Hilfe Sie die offensichtliche Rostprobleme sicherlich gründlich lösen würden. Ein weicher Pinsel gegen die Spinnweben – und schon wäre das System wieder in Ordnung.

Aber: Wir würden uns mit Rostentferner und Drahtbürste nur vermeintlich sinnvoll beschäftigen – weil uns der Blick auf’s Ganze fehlt, der Kontext eben.

Was ich Ihnen nämlich unterschlagen habe: Die Metallplatte gehört zu einem größeren Metallregal, dass wiederum in einem modernen Hochregallager liegt. Ja – es liegt, umgefallen. Unser Regal blockiert den Weg zum Ausgang: Mit jedem Artikel, den wir aus dem Lager entnehmen möchten, müssen wir mühevoll über unser umgefallenes Regal (mit der rostigen Schraube) klettern.

Von oben mit Kontextblick auf die gesamte Situation sieht unser Rostlöser oder die Drahtbürste ziemlich lächerlich aus. In der Übersicht oder Vogelperspektive erkennen wir einen großen Problembereich (das umgefallene Regal), der aktuell geschäftsschädigende oder -behindernde Wirkung zeigt.

Sie erkennen jetzt, dass Rostlöser im ersten Schritt keinen sinnvollen Nutzen gestiftet hätte – obwohl genau das in der mikroskopischen Betrachtung durchaus sinnvoll schien…

Wir benötigen einen Kran, denn solange das gefallene Regal noch den Weg versperrt, ist die gesamte Systemfunktion (Lagerung) gefährdet…

Beispiel: Kontext von Software

Schauen wir uns ein Beispiel eines (fachlichen) Kontextdiagramms von Software an – hier bewußt klein gehalten (aus dem Open-Source Projekt htmlSanityCheck) – gefolgt von einer tabellarischen Erklärung seiner wesentlicher Bestandteile (hier nur auszugsweise).

Abb. 1: Fachlicher Kontext aus Starke/Hruschka, arc42, erschienen bei Hanser.

Sie sollten Kontextdiagramme zur besseren Verständlichkeit um tabellarische Erläuterung der wesentlichen Elemente ergänzen – Diagramme alleine lassen oftmals zuviel Interpretationsspielraum.

Kontext als Geheimnisträger

Egal in welchem Kontext, das System selbst bleibt darin eine Blackbox: Sein gesamtes Innenleben (etwa: interne Strukturen und Konzepte, Entwurfsentscheidungen) bleibt verborgen.

Sie können also entkoppelt von (internen) technischen Details mit System- oder Projektbeteiligten über Aspekte der Aussenwelt diskutieren, ohne mit solchen Details die Kommunikation zu belasten.

Der Kontext gibt bezüglich solcher Details keine Versprechungen, d.h. Sie können Entwurfsentscheidungen innerhalb des Systems von dessen Kontext entkoppeln Diese Form der Entkopplung gilt grundsätzlich für jede Blackbox, sie ist die Grundlage des Information Hiding oder Geheimnisprinzips.

Verwenden Sie in Ihren Systemen und Entwürfen Kontexte auf unterschiedlichen Abstraktionsebenen dazu, interne Geheimnisse von Bausteinen zu wahren.

Kontext zeigt Existenzberechtigung

Der Kontext zeigt ein System eingebettet in umgebende Geschäftsprozesse oder Nachbarsysteme und macht somit den Zweck oder den Mehrwert des Systems erkenn- und erklärbar. Das vereinfacht und unterstütz die Kommunikation mit den am System beteiligten Personen, denn erkennbarer Mehrwert oder Nutzen motiviert Menschen auch zu Mitarbeit und Engagement.

Mit dem Kontext eines Systems können Sie dessen Existenzberechtigung auf dem höchsten Abstraktionsgrad erklären – und damit in der kompaktesten und wahrscheinlich einfachsten Form.

Kontext als Risikoindikator

Im Kontext finden wir die externen Schnittstellen von Systemen, eine Übersicht aller ein- und ausgehenden Daten, Ereignissen, Nachrichten und den relevanten Benutzergruppen.

Meiner Einschätzung nach treten an diesen externen Schnittstellen überproportional viele Schwierigkeiten und Fehler auf, sowohl bei Entwurf, Entwicklung und Betrieb von Systemen: Systeme brechen oftmals an ihren Schnittstellen.

Lassen Sie mich einige Beispiele dafür aufzeigen:

• Externe Systeme liefern versprochene Daten nicht oder in falschen
• Externe Systeme halten ihre Zusagen bezüglich Verfügbarkeit oder Performance nicht ein – was gravierenden Einfluss auf Ihre eigenen Qualities-of-Service haben könnte.
• Die Nutzung externer Systeme verursacht Kosten, etwa Kreditkartenprüfung.
• Externe Systeme sind nur schwerer testbar als interne Komponenten, weil die externen Nachbarn Ihnen keine Testsysteme oder Testdaten bereitstellen können.

Und damit komme ich zum nächsten Stichwort:

Kontext zeigt Verantwortungsbereiche

Der Kontext eines Systems zeigt Verantwortungs- oder Einflussbereiche. Insbesondere auf externe Nachbarn haben Sie als Entwickler oder Entwicklungsteam keinen direkten Einfluss. Entscheidet sich ein Nachbarsystem kurzfristig für eine gravierende Schnittstellenänderung – dann müssen Sie im schlimmsten Fall diese Änderung innerhalb Ihres Systems nachziehen.

Meine Erfahrung sagt: solche Änderungen kommen immer zum schlechtest möglichen Zeitpunkt und oftmals am Ende Ihres Budgets

Da hilft der Kontext, solche Verantwortungen klar aufzuzeigen bzw. gegeneinander abzugrenzen.

Kontext als Kompass

Auch in der realen Welt benötigen Menschen Kontext zur Orientierung. Wie sagt das Sprichwort: „Vor lauter Bäumen den Wald nicht erkennen“. Da hat jemand den Kontext verloren, sieht unter einer Vielzahl von Detailinformationen den gesamten Zusammenhang nicht mehr.

Dieses big picture jedoch hilft beim Verständnis und der Einordnung von Sachverhalten. Nutzen Sie den Kontext von Systemen als Einstiegs- oder Navigationshilfe, sozusagen als Kompass in der Weltkarte Ihres Systems.

Fazit: Niemals ohne Kontext

Für jegliche Art der Arbeit an Systemen sollten Sie deren Kontext genau kennen:

• Legen Sie alle Nachbarsysteme und deren Schnittstellen offen, ohne Ausnahme.
• Legen Sie ebenfalls sämtliche Benutzergruppen offen, neben den reinen Anwendern könnten fachliche und technische Administratoren, oder beliebige weitere Benutzergruppen mit Ihrem System interagieren.

Quellen

[1] HtmlSanityChecker: Open-Source Tool zur semantischen Prüfung von (generiertem) HTML. Findet defekte interne Links, fehlende Bilder und weitere Fehlerchen. Entwickelt als Beispielprojekt für arc42-Architekturdokumentation. Code und Doku verfügbar auf Github

[2] Gernot Starke, Peter Hruschka: arc42: Pragmatische Hilfe für Softwarearchitekten. Carl-Hanser, 2015.