Antwort.

Hintergrund:

Der Bedarf an klaren Integrationsspezifikationen entstand mit der Entwicklung der IT-Landschaft in Unternehmen, als ihre Geschäftsprozesse auf eine Vielzahl unterschiedlicher Softwareprodukte und -dienste angewiesen waren. In den 90er Jahren wurden für den Datenaustausch Papierdokumente und manuelle Exporte weit verbreitet verwendet, später kamen EDI-Austausch und Integrationsplattformen hinzu. Heute spielt die Schnittstellenspezifikation eine zentrale Rolle bei der Organisation eines effektiven Zusammenwirkens.

Problem:

Ohne eine detaillierte Integrationsspezifikation treten häufig Missverständnisse zwischen den Teams auf, es kann zu fehlerhaften Datenverarbeitungen, Doppelarbeiten oder sogar zu Ausfällen von Geschäftsprozessen kommen. Die Frage stellt sich: Wie dokumentiert und pflegt man die Spezifikation, damit beide Seiten (oder mehrere Seiten) die Anforderungen während des gesamten Lebenszyklus des Systems eindeutig verstehen?

Lösung:

Der Systemanalytiker entwickelt die Integrationsspezifikation unter Verwendung von allgemein anerkannten Standards zur Beschreibung (z.B. OpenAPI, WSDL, XSD, BPMN), Vorlagen und Modellierungswerkzeugen. In die Spezifikation müssen unbedingt Folgendes aufgenommen werden:

• Struktur der Nachrichten, Datenformate, Regeln zur Fehlerverarbeitung
• Beschreibung der Geschäftsszenarien für die Interaktion und Sicherheitsanforderungen
• Anforderungen an SLA, Überwachung und Protokollierung von Ereignissen
• Vorschriften zur Aktualisierung und Pflege der Dokumentation bei jedem Release

Wesentliche Merkmale:

• Klare Abgrenzung der Verantwortlichkeiten jedes beteiligten Systems.
• Verwendung formaler Beschreibungssprachen für Schnittstellen.
• Unterstützung und Aktualisierung der Spezifikationen während des gesamten Lebenszyklus der Integration.

Fangfragen.

Was ist der Unterschied zwischen synchroner und asynchroner Interaktion von Systemen, und ist der asynchrone Ansatz immer fehlerresistenter?

Asynchroner Austausch reduziert tatsächlich die Kopplung von Anwendungen und kann durch Warteschlangen stabiler sein, aber nicht in allen Szenarien ist er optimal: Für Anfragen mit hohen Anforderungen an die Reaktionszeit oder Transaktionssicherheit sollten synchronisierte Interaktionen verwendet werden.

Reicht die Beschreibung der API und der Datenstruktur für ein vollständiges Verständnis der Integration zwischen Systemen aus?

Nein, es ist auch notwendig, Geschäftsszenarien, Modelle für die Fehlerverarbeitung, Anforderungen an die Überwachung, SLA, zulässige Verzögerungen und die Versionierung zu dokumentieren.

Kann man sich ausschließlich auf mündliche Vereinbarungen zwischen Teams bei Änderungen am Integrationsformat verlassen?

Nein, alle Änderungen müssen in der Spezifikation formalisiert und schriftlich genehmigt werden, andernfalls besteht das Risiko von Diskrepanzen in den Implementierungen und möglichen Vorfällen.

Typische Fehler und Anti-Pattern

• Inkonsistenz der Versionsspezifikationen zwischen den Teams
• Vernachlässigung der Dokumentation von Ausnahmen, unkonventionellen Situationen
• Nichtaktualisierung der Spezifikation nach Änderungen

Beispiel aus dem Leben

Negativer Fall: Der Kunde hat das Datenformat in der API geändert und nur das Partnerteam per E-Mail informiert. Die Entwickler eines anderen integrierten Systems haben dies nicht berücksichtigt, und ein Teil der Transaktionen konnte nicht verarbeitet werden. Vorteile:

• Schnelle Einführung der Neuerung Nachteile:
• Es kam zu einem Ausfall, eine dringende Datenwiederherstellung war erforderlich, Zeit und Geld gingen verloren.

Positiver Fall: Der Analyst hat einen Änderungsantrag eingereicht, die Swagger-Spezifikation aktualisiert, alle betroffenen Teams über den internen Chat informiert und auf die Bestätigung der Änderungen gewartet. Vorteile:

• Alle Parteien waren im Voraus über die Änderungen informiert
• Risiko von Fehlern wurde gesenkt Nachteile:
• Es dauerte länger, um die Zustimmung zu erhalten