Mit Struktur an Schnittstellen

Inhaltsverzeichnis

In diesem Beitrag geht es um die strukturierte Herangehensweise an Schnittstellen. Ziel ist es, sich selbst einen Überblick zu verschaffen beziehungsweise anderen einen Überblick zu geben.

Wie in meinem ersten Beitrag angekündigt, geht es in meinen Blog-Artikeln um die Organisation unseres Entwickleralltags. Nehmen wir nun mal einen Klassiker: Schnittstellen sind ein Thema, mit denen Entwickler immer wieder zu tun haben. Gemeint sind hier Schnittstellen zwischen Systemen beziehungsweise zwischen unterschiedlicher Software. Nicht die Schnittstellen, die wir etwa aus der objektorientierten Programmierung kennen.

Um eine Schnittstelle zu entwickeln, gilt es, verschiedene Aspekte zu berücksichtigen. Nachfolgend ein Modell, das sich für mich über die Jahre bewährt hat. Man kann es anwenden, wenn man mitten im Projekt hinzugezogen wird. Dann hilft es, sich einen Überblick zu verschaffen. Oder aber auch, wenn man noch ganz am Anfang steht. Also sozusagen als Leitfaden für den ersten Workshop mit allen Beteiligten, den Stakeholdern.

Auf jeden Fall ergeben sich aus dem Modell Fragen und Antworten, die ganz allgemein das Verständnis für die Schnittstelle bei allen Beteiligten verbessern.

Das Modell besteht aus vier Kategorien.

1. Prozesse
2. Daten
3. Systeme
4. Kommunikation

Die Kategorien im Detail

Im Rahmen der Kategorie "Prozesse" werden betriebswirtschaftliche Prozesse besprochen. Worum geht es eigentlich? Sind es mehrere Prozesse, sollte über ihre Wichtigkeit und Reihenfolge gesprochen werden? Was sind mögliche Voraussetzungen? Wer nutzt diese Prozesse, wer betreut sie? Lassen sich Business-Objekte identifizieren?

Aus den Prozessen ergeben sich Daten. Damit sind wir in der zweiten Kategorie. Denn Prozesse leben von Daten (Stichwort "Stammdaten") und produzieren auch Daten (Stichwort "Bewegungsdaten"). In dieser Kategorie geht es um Themen wie Menge, Vollständigkeit, Zeitabhängigkeit, Herkunft, Verfügbarkeit, Reihenfolge, Struktur und vieles andere mehr.

Daten müssen irgendwo gespeichert sein. So kommen wir zur dritten Kategorie. Jetzt geht es um Systeme. Hier hat sich für mich zunächst eine Typisierung der Systeme bewährt. Ich unterscheide nach Quell-, Ziel- und Vermittlersystemen. Nun gilt es, eine ganze Reihe an Fragen zu klären. Welches System ist führend? Physischer und netzwerktechnischer Standort? Bereits gekoppelt? Verfügbarkeit? Zuständigkeit? Wird betreut von wem? Die Liste an Fragen ist schnell wirklich lange.

In der letzten Kategorie geht es um "Kommunikation". Wer soll mit wem kommunizieren? Welche Protokolle spielen eine Rollen. Wie oft und zu welchen Zeitpunkten wird kommuniziert? Welche Sicherheitsvorkehrungen werden getroffen? Welche Struktur erhält die Kommunikation? Ist eine Konvertierung oder Anreicherung der transportierten Daten notwendig? Handelt es sich um eine synchrone oder aysnchrone Kommunikation? In welcher Reihenfolge wird kommuniziert? Bestehen Abhängigkeiten?

Erweiterung möglich und gewünscht

Die Fragen pro Kategorie lassen sich ganz nach Bedarf erweitern. Das gilt auch für die Kategorien. Sicherheitsaspekte kann man zum Beispiel einer eigenen Kategorie zuordnen.

Wer neben seiner Entwicklerrolle auch organisatorische Aufgaben wahrnimmt, zum Beispiel in der Rolle eines Teilprojektleiters, sollte eine Kategorie "Organisation" aufnehmen. In dieser Kategorie widmet man sich typischen Verwaltungsfragen. Das können Fragen nach dem Zeitplan, dem Budget, der Verfügbarkeit von Projektmitgliedern, vereinbarten Meilensteinen und einiges andere mehr sein.

Anwendung und weiterführender Nutzen

Das Schöne an diesem Modell ist, dass es sich in unterschiedlichen Situationen einfach anwenden lässt. Die Fragen geben Orientierung, was als Nächstes zu klären ist. Die Antworten wiederum geben Aufschluss und führen möglicherweise zu neuen Fragen. Den jeweils beteiligten Personen ist das Modell auch schnell erklärt. Davon einmal abgesehen schafft ein strukturiertes Vorgehen Vertrauen. Die schriftliche Fixierung der Fragen und Antworten ist selbstredend. Daraus lässt sich wunderbar ein Konzept beziehungsweise eine Dokumentation ableiten.

Die Geschichte hinter diesem Beitrag

Zum Schluss noch ein Satz, warum ich heute über dieses Thema geschrieben habe. Vor einigen Wochen hatte ich eine Schnittstellendokumentation in der Hand. Auf Seite 3 standen zwei Sätze, was die Schnittstelle betriebswirtschaftlich leistet. Dann folgten ungefähr zehn Seiten tabellarischer Auflistung über Feldnamen, Feldlängen und einigen Informationen mehr.

Alleine dieses Missverhältnis hat mich schon überrascht. Ach was, misstrauisch gemacht. Man sehe es mir nach, aber da hat die innere Alarmglocke gefühlt fünf Minuten keine Ruhe gegeben.

Ein paar Worte zum Schluss

Auf GitHub findet ihr ein Repository, in dem ich via draw.io das voran beschriebene Modell etwas visualisiert habe. Das könnt ihr euch gerne ansehen. Verbesserungsvorschläge sind natürlich auch willkommen. Bringt schließlich allen etwas.

In diesem Sinne, bleibt gesund und strukturiert
euer Michael ()