© Excellent backgrounds/Shutterstock.com
Kolumne: Knigge für Softwarearchitekten

Kolumne: Knigge für Softwarearchitekten


Unserer Einschätzung nach werden Schnittstellen oft als Dinge dritter Klasse behandelt. Technologie auswählen, Features bauen und Bugs fixen gehen vor. Sogar Dokumentation schreiben scheint uns in manchen Projekten wichtiger als effektive Schnittstellen zu entwerfen. Wir wünschen Ihnen und uns die API-tektin, die gemeinsam mit Softwarearchitekten den Schnittstellen auf die Sprünge hilft.

Aber was ist eine Schnittstelle? Der einfachste Fall: Sie haben einen Consumer und einen Provider. Consumer benötigt irgendetwas vom Provider, seien es Rechen- oder Abfrageergebnisse, Daten oder Dateien, Messwerte von Sensoren oder Statusinformationen; also eine digitale Antwort auf eine ebenso digitale Frage. Sie können diesen einfachen Fall durch Fragen von Zeitverhalten (sync, async) oder Antwortverhalten (request-response, fire-and-forget, single-consumer, multiple-consumer etc.) noch verkomplizieren. Aber schauen wir mal auf den einfachsten Fall: Ein Consumer muss die Anfrage irgendwie an den Provider übermitteln. Oft geschieht das über einen Funktions- oder Methodenaufruf mit Parametern und Rückgabewert. Viele der üblichen Interaktionen zwischen Consumern und Providern können wir auf solch einfache Aufrufe zurückführen. Diese Art der Zusammenarbeit zwischen Bausteinen ist die Grund­lage von Modularisierung und Komponentenbildung und kommt in Systemen aller Art an beliebig vielen Stellen vor. Damit ist Schnittstellenentwurf ein alltägliches Allerweltsproblem. Und wir sollten überlegen, welche der jeweiligen Personen (Stakeholder) eigentlich an solchen Entscheidungen beteiligt sind.

Wer entscheidet über Schnittstellen?

Abbildung 1 zeigt diese Situation – völlig verallgemeinert – mit möglichen Beteiligten: Das Consumer-Team C, Providerteam P, eine Architektin A, Management M sowie sonstige Stakeholder S. In einer solchen Situation müssen für die Schnittstellen jede Menge Detailentscheidungen getroffen werden. Und dabei können sich die Stakeholder A, C, P sowie M und S wie in Tabelle 1 gezeigt einbringen.

hruschka_starke_knigge_1.tif_fmt1.jpgAbb. 1: Wer entscheidet über Schnittstellen?

Wer?

Begründung

C + P

Consumer und Provider stimmen sich über Details ab.

A + C + P

API-tektin sorgt bei der Schnittstelle für das Einhalten querschnittlicher Konzepte, die C oder P möglicherweise nicht kennen oder beachten.

A

API-tektin bestimmt allein; das reduziert den Abstimmungsaufwand für C und P.

C

Consumer definiert, weil C am besten entscheiden kann, was wirklich ­benötigt wird.

P

Provider entscheidet, weil P am b...

Exklusives Abo-Special

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang