Schnittstelle vor der Auswahl beschreiben

Fachliche Leistung ohne Produktbegriffe formulieren

Die Beschreibung beginnt mit dem Ereignis, das Informationen überträgt, und dem fachlichen Ergebnis beim Empfänger. Produktnamen, vorhandene Menüpunkte und bevorzugte Protokolle bleiben zunächst außen vor. Statt „CRM-Connector“ steht dort beispielsweise, dass freigegebene Kundendaten nach einer Statusänderung innerhalb eines definierten Zeitfensters an ein Abrechnungssystem gelangen sollen. Dazu werden Sender, Empfänger, Richtung, Häufigkeit und verantwortliche Stelle genannt. Diese neutrale Fassung ermöglicht später den Vergleich verschiedener Lösungen und deckt auf, wenn ein vermeintliches Schnittstellenproblem eigentlich eine ungeklärte Prozessentscheidung ist.

Einordnung: Redaktioneller Arbeitsschritt; keine gesetzliche oder technische Vorgabe.

Datenvertrag mit Bedeutung und Grenzen erstellen

Für jedes Feld werden Name, fachliche Bedeutung, Format, Pflichtstatus, erlaubte Werte und Umgang mit fehlenden Angaben dokumentiert. Ein Beispielwert allein genügt nicht, weil er weder Grenzfälle noch Semantik erklärt. Identifikatoren erhalten Regeln zu Eindeutigkeit und Lebensdauer. Zeitangaben brauchen Zeitzone und Format; Beträge benötigen Währung und Rundungsregel. Zusätzlich wird festgelegt, welche Seite die Definition eines Feldes verantwortet. Änderungen am Datenvertrag erhalten eine Version und einen Übergangsweg. So kann die Auswahlprüfung klären, ob ein Produkt den tatsächlichen Vertrag abbildet oder nur ähnlich benannte Felder anbietet.

Einordnung: Redaktioneller Arbeitsschritt; keine gesetzliche oder technische Vorgabe.

Datenschutzanforderungen auf benötigte Daten beziehen

Die Datenschutz-Grundverordnung enthält unter anderem die Grundsätze der Zweckbindung, Datenminimierung, Richtigkeit und Speicherbegrenzung. Ob und wie sie im Einzelfall greifen, muss anhand von Zweck, Rollen und Verarbeitung geprüft werden. Für die Schnittstelle wird daher jedes personenbezogene Feld einem beschriebenen Bedarf zugeordnet; ein pauschaler Vollabzug ist kein neutraler Standard. Außerdem werden Empfänger, Löschbezug und Zugriffsmöglichkeiten sichtbar gemacht. Diese Dokumentation ersetzt weder eine Rechtsgrundlagenprüfung noch gegebenenfalls weitere Datenschutzprozesse, schafft aber eine überprüfbare technische Grundlage dafür.

Beleggrundlage: Verordnung (EU) 2016/679 (Datenschutz-Grundverordnung)

Verhalten bei Last, Verzögerung und Fehler festlegen

Eine Schnittstelle ist nicht vollständig beschrieben, solange nur erfolgreiche Einzelaufrufe betrachtet werden. Benötigt werden erwartete und maximale Mengen, Spitzen, zulässige Verzögerung, Zeitlimits und Größenbegrenzungen. Das Dokument unterscheidet vorübergehende Nichterreichbarkeit, fachliche Ablehnung und ungültige Nachricht. Für jede Klasse stehen Wiederholung, Abbruch, Benachrichtigung und Wiederaufnahme fest. Bei asynchroner Übertragung wird erklärt, wie Reihenfolge und Duplikate behandelt werden. Diese Anforderungen lassen sich in Auswahlgesprächen als konkrete Tests verwenden, statt sich auf die Aussage „hoch verfügbar“ ohne messbare Bezugsgröße zu verlassen.

Einordnung: Redaktioneller Arbeitsschritt; keine gesetzliche oder technische Vorgabe.

Authentisierung, Berechtigungen und Protokolle trennen

Das BSI stellt mit IT-Grundschutz einen methodischen Rahmen und Bausteine für Informationssicherheit bereit; die für eine bestimmte Verbindung angemessenen Maßnahmen hängen vom Schutzbedarf ab. Die Schnittstellenbeschreibung nennt deshalb, welcher technische Dienst sich wie ausweist, welche minimalen Aktionen er ausführen darf und wie Schlüssel oder Zertifikate gewechselt werden. Protokolle sollen den Vorgang nachvollziehbar machen, ohne unnötig Nutzdaten oder Geheimnisse zu vervielfältigen. Betriebszugriff, Entwicklungszugriff und fachliche Leserechte werden getrennt betrachtet. Eine Produktfunktion gilt erst dann als passend, wenn sie dieses Rollenmodell tatsächlich unterstützt.

Beleggrundlage: IT-Grundschutz-Kompendium

Anbieterantworten durch Abnahmeszenarien prüfen

Aus der Beschreibung entstehen wenige, aber aussagekräftige Szenarien: gültige Nachricht, fehlendes Pflichtfeld, Dublette, verzögerte Antwort, Berechtigungsfehler und Versionswechsel. Anbieter oder interne Teams zeigen daran nicht nur einen Bildschirm, sondern das beobachtbare Verhalten auf beiden Seiten. Ergebnisse werden gegen vorher definierte Kriterien protokolliert. Abweichungen erhalten eine verantwortliche Entscheidung; sie verschwinden nicht in einer allgemeinen Liste späterer Anpassungen. Ein erfolgreicher Prototyp beweist die getesteten Fälle, nicht die Eignung für jede Last oder jeden Sonderfall. Offene Betriebs- und Migrationsfragen bleiben bis zur Klärung sichtbar. Vor Vertrags- oder Umsetzungsentscheidung wird außerdem geprüft, ob Dokumentation, Testzugang und Export der eigenen Konfiguration verfügbar sind. So hängt die spätere Wartung nicht vollständig von einer einmaligen Vorführung oder den Aussagen einzelner Vertriebsbeteiligter ab.

Einordnung: Redaktioneller Arbeitsschritt; keine gesetzliche oder technische Vorgabe.

Im Zusammenhang weiterlesen

• Datenexport auf Wiederverwendbarkeit prüfen — Ein Export ist wiederverwendbar, wenn Empfänger Inhalt und Grenzen verstehen, ihn automatisiert prüfen und sicher weiterverarbeiten können.
• Abhängigkeiten in Workflows begrenzen — Abhängigkeiten verschwinden selten; beherrschbar werden sie durch klare Verträge, begrenzte Ketten und getestete Ersatzwege.
• Datenquelle und Dateneigner festlegen — Eine belastbare Datenverantwortung verbindet die maßgebliche Quelle mit Definition, Qualitätsentscheidung und Eskalationsweg.