RFP-Integrationsfragen trotz offener Schnittstellen beantworten

Beleglage

Eine Integrationszusage beginnt mit ihrem Geltungsbereich

Bestimmen Sie zuerst, was die Vergabestelle tatsächlich bewertet. Verlangt sie eine Methodik, ein ausgearbeitetes Konzept, vorhandene Konnektoren, eine verbindliche Leistungszusage oder Referenznachweise? Lesen Sie die Frage zusammen mit Zuschlagskriterien, Leistungsbeschreibung, Anlagen, Bieterinformationen, Preisblatt und Vertragsentwurf. § 58 VgV erlaubt im deutschen Vergabekontext qualitative Kriterien einschließlich technischer Eigenschaften. Daraus folgt nicht, dass jede Integrationsfrage gleich bewertet wird. Maßgeblich bleiben die veröffentlichten Unterlagen des konkreten Verfahrens.

Führen Sie für jede Aussage einen Status. Eine Vorgabe zitiert Dokument, Abschnitt und Version. Ein Befund stammt aus zulässiger Prüfung und trägt Datum und Umfang. Ein Vorschlag liegt im Einfluss des Bieters. Eine Annahme braucht Bestätigung und zeigt ihre Auswirkung. Eine Unbekannte erhält keinen erfundenen Wert. So bleibt sichtbar, ob „XÖV-fähig“ aus der Ausschreibung stammt, aus einer geprüften Schnittstellenbeschreibung oder nur aus einer Produktannahme.

Der fiktive Landkreis Birkenau beschafft einen Onlinedienst für Bauanträge. Anzubinden sind Servicekonto, Dokumentenmanagement, Fachverfahren und E-Payment. Die Unterlagen nennen FIT-Connect und „geeignete XÖV-Standards“, nennen aber für das Fachverfahren weder Produktversion noch unterstütztes Nachrichtenprofil. Das Angebot beschreibt deshalb den fachlichen Austausch und die angebotene Prüfkette. Es behauptet keine Kompatibilität mit einer nicht offengelegten Installation. Birkenau ist ein rein fiktives Beispiel.

Fachlicher Vertrag

Der Verwaltungsvorgang bestimmt die Bedeutung der Schnittstelle

Beschreiben Sie nicht zuerst die Leitung, sondern den Vorgang. Wer löst die Übergabe aus? Welches Objekt wird übertragen? Welches System führt dessen Identität und Zustand? Welche Quittung bestätigt nur den technischen Empfang und welche bestätigt die fachliche Übernahme? Ein Bauantrag kann technisch angenommen sein, obwohl Anhänge fehlen oder das Aktenzeichen nicht angelegt werden konnte. Die Antwort muss diese Zustände auseinanderhalten.

Für den Informationsvertrag werden Felder, Begriffe, Codes, Einheiten, Zeitbezug, Pflichtwerte, Leerwerte, Beziehungen, Kennungen und Beispiele beschrieben. Eine maschinenlesbare JSON- oder XML-Struktur verhindert noch keine semantische Verwechslung. „Eingangsdatum“ kann Zeitpunkt des Uploads, der erfolgreichen Prüfung oder der förmlichen Einreichung bedeuten. Der fachlich zuständige Auftraggeber muss die Bedeutung bestätigen; der Bieter kann sie strukturiert zur Entscheidung vorlegen.

Binden Sie danach Transport und Identität an. Nennen Sie das angebotene Protokoll, Endpunktverantwortung, Authentisierungsklasse, Berechtigungsumfang, Netzweg und Grenzen, ohne interne Adressen, Geheimnisse oder Schutzkonfiguration zu veröffentlichen. Detailentscheidungen zur Absicherung gehören in den Sicherheitsnachweis. Die Integrationsantwort zeigt nur, welche Vertrauensbeziehung für den Austausch erforderlich ist und wie sie getestet wird.

• Empfang, syntaktische Prüfung, fachliche Annahme und Abschluss getrennt benennen.
• Eine führende Stelle für jede Kennung und jeden Zustand festlegen.
• Codewerte und Nachrichtenprofile gemeinsam versionieren.
• Korrelation zwischen Antrag, Dokument, Zahlung und Akte erhalten.
• Vom Auftraggeber kontrollierte Semantik als Abhängigkeit markieren.

Standards und Profile

Der Name eines Standards ist noch kein ausführbarer Vertrag

§ 31 VgV regelt in seinem Anwendungsbereich die Leistungsbeschreibung und den Bezug auf technische Anforderungen. Für die Antwort bleibt entscheidend, welche Fassung, welches Profil und welche Optionen die Vergabestelle verlangt. XÖV unterstützt standardisierte fachliche Nachrichten, doch das konkrete Vorhaben braucht den passenden Standard, Release, Nachrichtentyp und die zulässigen Erweiterungen. Halten Sie diese Merkmale im Antwortvertrag fest und zitieren Sie die zum Angebotsstichtag maßgebliche Dokumentation.

FIT-Connect trennt sendende und empfangende Systeme und veröffentlicht technische Vertragsbestandteile, Metadaten und Versionsinformationen. Die Dokumentation zu FIT-Connect 2.0 zeigt zugleich, dass Plattformen Releases weiterentwickeln und ältere Linien auslaufen können. Wer lediglich „Anbindung an FIT-Connect“ verspricht, lässt offen, welche API-Fassung, Metadatenschemata, Rollen und Zeitbedingungen kalkuliert wurden. Das Angebot braucht einen Versionsstand sowie einen kontrollierten Weg zu späteren Fassungen.

OpenAPI eignet sich für HTTP-Schnittstellen, AsyncAPI für ereignisorientierte Verträge und JSON Schema für strukturierte Datenregeln. Wählen Sie nur die Beschreibung, die zum angebotenen Austausch passt. Ein OpenAPI-Dokument für einen Dateiimport erzeugt keine bessere Architektur. Wichtig sind stabile Spezifikation, Beispiele, Fehlerdefinitionen, Testfälle und eine benannte Autorität für Änderungen.

Fehlerverhalten

Nach einem Timeout braucht der Vorgang eine eindeutige Fortsetzung

Beschreiben Sie ungültige Nachricht, fehlende Berechtigung, Nichterreichbarkeit, Timeout, Mengenbegrenzung, Teilverarbeitung, Dublette, falsche Reihenfolge, abgelaufene Datei und unbekannte Fachreferenz. Jede Klasse erhält ein beobachtbares Ergebnis, eine sichere Reaktion und eine zuständige Stelle. RFC 9457 stellt für HTTP-APIs maschinenlesbare Problemdetails bereit. Es entscheidet nicht, ob ein abgelehnter Bauantrag korrigiert, neu eingereicht oder fachlich eskaliert werden muss.

Wiederholen Sie nur vorübergehende technische Fehler und nur mit Begrenzung, Verzögerung und Abbruchregel. HTTP-Idempotenz aus RFC 9110 ist eine Eigenschaft der Methodensemantik, nicht automatisch des dahinterliegenden Verwaltungsvorgangs. Eine stabile Einreichungskennung kann ermöglichen, dass ein zweiter identischer Aufruf das vorhandene Ergebnis zurückgibt. Ist das beim fremden Fachverfahren nicht gesichert, muss die Lösung zuerst den bestehenden Ausgang abfragen oder abgleichen.

Ein Puffer verhindert Datenverlust, aber nicht fachliche Verspätung. Definieren Sie maximales Alter, Rückstand, Priorisierung und Entscheidung bei Fristüberschreitung. Für Birkenau darf ein Zahlungsstatus nicht unbegrenzt warten, wenn davon die förmliche Antragseinreichung abhängt. Die Antwort erklärt, ob der Vorgang pausiert, später ergänzt oder manuell entschieden wird. Diese fachliche Wahl muss aus den Verfahrensregeln kommen.

Zuständigkeiten

Die Betriebsgrenze ist umfangreicher als der Adapter

Ordnen Sie für jeden Austausch Spezifikation, Endpunkte, Adapter, Transformation, Netzfreigabe, Identitäten, Zertifikate, Testdaten, Umgebungen, Monitoring, Alarmannahme, Fehleranalyse, Wiederholung, Datenkorrektur, Support und Änderung zu. Benennen Sie Liefergegenstand und Entscheidungsrecht. Ein DMS-Hersteller kann das Produkt betreiben, der Landkreis das Dokumentenmodell besitzen und der Bieter den Adapter liefern. Ohne gemeinsames Abnahmebild bleibt trotzdem eine Lücke.

Machen Sie fremde Beiträge zu datierten Voraussetzungen. Statt „Testzugang durch Auftraggeber“ braucht die Antwort Umgebung, Rolle, Datensatz, Konnektivitätsbeleg, benötigten Termin und blockierte Aktivität. Zeigen Sie, welche Arbeiten bei Verspätung weiterlaufen können und wann der verbindliche Pfad betroffen ist. Erfinden Sie keinen Anspruch auf Frist- oder Preisänderung. Die Behandlung muss zum Vertragsentwurf und zur kaufmännisch genehmigten Risikoposition passen.

Betriebliche Sichtbarkeit wird ebenfalls geteilt. Eine technische Trace-Kennung kann bei unterstützter Weitergabe gemäß W3C Trace Context helfen. Sie ersetzt weder das fachliche Journal noch eine verantwortliche Entstörung. Definieren Sie, welche Seite Eingang, Laufzeit, Rückstand, Ablehnung und Ergebnis sieht, welche Belege für den Support ausgetauscht werden dürfen und wer eine Wiederholung freigibt.

• Jede Voraussetzung mit Termin, Annahmebeleg und Folge verbinden.
• Alarmannahme, technische Diagnose und fachliche Korrektur getrennt zuordnen.
• Vollmachten für Wiederholung, Sperre und Abweichung ausdrücklich benennen.
• Drittanbieter-Fristen im Angebotsplan sichtbar machen.
• Nur Beobachtbarkeit zusagen, die die jeweilige Partei tatsächlich bereitstellt.

Nachweisführung

Ein Simulator beweist nur den Vertrag, den er abbildet

Leiten Sie Tests aus dem Vertrag ab. Die statische Prüfung findet Lücken in Operationen, Feldern, Codes und Fehlern. Schema- und Vertragstests vergleichen Beispiele und Implementierung. Komponententests prüfen den Bieteranteil. Ende-zu-Ende-Tests schließen fremden Endpunkt, Identität, Netzwerk und Fachzustand ein. Negativ-, Last- und Störfalltests prüfen Ablehnung, Rückstand, Wiederanlauf und Abgleich. Kein einzelner grüner Test ersetzt diese unterschiedlichen Aussagen.

Jeder Test nennt Umgebung, Spezifikationsversion, Eingaben, erwartetes Ergebnis, Messwert, Beleg, Mangelbehandlung und Abnahmebefugnis. Ein Test-Mandant kann Berechtigungslogik zeigen, nicht zwingend produktive Zertifikate oder Spitzenlast. Ein Mock kann frühe Entwicklung ermöglichen, nicht die Produktkompatibilität des DMS bestätigen. Begrenzen Sie die Schlussfolgerung auf das, was der Aufbau tatsächlich enthält.

Birkenau prüft eine Einreichung mit mehreren Dokumenten, eine abgelehnte Dateigröße, eine unterbrochene Übertragung und einen erneuten Zustellversuch derselben Antragskennung. Abnahme verlangt genau eine Fachakte, ein vollständiges Manifest, nachvollziehbare Ablehnungen und übereinstimmende Zustände im Onlinedienst und Fachverfahren. Die Sicherheitsprüfung und die fachliche Rechtswirkung bleiben bei den dafür zuständigen Nachweisen und Behörden.

Änderungsweg

Kompatibilität umfasst Verhalten, nicht nur lesbare Felder

Baselinen Sie Fachstandard, Profil, Schema, Beispiele, Codewerte, Identitätsprofil, Mengengrenzen und Betriebshandbuch gemeinsam. Eine additive Änderung kann fachlich brechen. Ein zusätzlicher Status kann im empfangenden System unbekannt sein; eine neue Voreinstellung kann Entscheidungen verändern; ein engerer Berechtigungsumfang kann einen bestehenden Ablauf stoppen. Prüfen Sie deshalb Quell-, Übertragungs- und Verhaltenskompatibilität für bestehende Teilnehmer.

Beschreiben Sie Vorschlag, Auswirkungsanalyse, Freigabe, Benachrichtigung, Test, Parallelphase, Rückkehr und Dokumentationspflege. Versprechen Sie keine Frist, die ein fremder Hersteller nicht zugesagt hat. Für auftraggeber- oder drittbetriebene Endpunkte hält das Angebot die kalkulierte Änderungsannahme und den vertraglich zulässigen Entscheidungsweg fest. Ein technischer Standard macht zusätzlichen Aufwand nicht automatisch preisneutral.

Die FIT-Connect- und XÖV-Dokumentationen sind lebende Referenzen. Verwenden Sie im Angebot eine datierte, konkrete Fassung statt eines dynamischen Links als alleinige Leistungsdefinition. Nach Zuschlag kann ein kontrolliertes Upgrade sinnvoll sein. Es darf aber die geprüfte Baseline erst ersetzen, wenn Kompatibilität und betroffene Zusagen neu bewertet wurden.

Offene Punkte

Eine offene Version braucht einen Termin und eine Ausweichentscheidung

Fehlt vor Angebotsabgabe eine Information, die Muss-Erfüllung, wesentliche Architektur, Preis, Frist oder Vergleichbarkeit verändert, nutzen Sie rechtzeitig den vorgesehenen Fragekanal. Zitieren Sie die konkrete Stelle und fragen Sie nach dem kleinsten Merkmal, das die Angebotsentscheidung verändert. Der Prozess zur Klärung technischer Abhängigkeiten ist eine eigene Disziplin. Diese Integrationsantwort muss das Ergebnis anschließend als Vorgabe übernehmen oder die verbleibende Annahme klar zeigen.

Für eine Prüfung nach Zuschlag nennen Sie Entscheidung, benötigte Unterlagen, Beteiligte, Termin, angebotene Ausgangsoption, Erfolgskriterium und Folge einer Abweichung. Beispiel: Das Angebot nimmt an, dass das Fachverfahren das bezeichnete XÖV-Profil in der genannten Version verarbeitet. Nach autorisiertem Testzugang wird diese Annahme mit dem veröffentlichten Vertrag und vereinbarten Fällen geprüft. Bei Abweichung werden ein kompatibles Profil oder eine Transformation über den im Vertrag festgelegten Änderungsweg entschieden. Versionsnummer, Termin und Rechtsfolge müssen aus dem echten Verfahren stammen.

Formulieren Sie schließlich pro Austausch einen kompakten Block aus Ziel, Belegstatus, Verhalten, Verantwortung, Störung, Test, Abnahme und offener Bestätigung. Wiederholen Sie Sicherheits-, Datenschutz-, Migrations- oder Servicezusagen nicht in abweichender Form. Verweisen Sie auf die zuständigen Antwortteile. Die Integrationsverantwortlichen dürfen Verhalten und technische Nachweise entwerfen; fachliche, sicherheitsbezogene, rechtliche und kaufmännische Verpflichtungen brauchen ihre jeweiligen Freigaben.