Antwort.

Historischer Hintergrund:

In den letzten Jahren ist die Nachfrage nach Integrationslösungen gestiegen, bei denen die transparente Dokumentation von Verarbeitungs- und Übertragungsregeln von entscheidender Bedeutung ist, insbesondere beim Einsatz von externen Diensten und künstlicher Intelligenz. Unformalisierte Daten und das Fehlen klarer Geschäftsregeln führen zu Fehlern und Vorfällen.

Problem:

Der Einsatz von KI und externen Diensten erfordert klar beschriebene Regeln für den Umgang mit Daten: Was zu senden ist, wie zu validieren ist, was im Falle eines Fehlers zu tun ist, wie Aktionen zu protokollieren sind, was dem Benutzer zurückzugeben ist. Ohne formale Beschreibung dieser Regeln steigt das technische und geschäftliche Risiko.

Lösung:

Die folgenden Methoden werden verwendet:

UML-Aktivitätsdiagramm und BPMN zur Visualisierung von Datenflüssen, Eingangs- und Ausgangsdaten
Datenflussdiagramm (DFD) zur Dokumentation von Informationsrouten
Tabellarische Beschreibung von Regeln (Entscheidungstabellen) mit klaren Bedingungen und Aktionen
Glossare für einheitliche lexikalische Begriffe in Systemen und Geschäftsbereichen
Specification by Example — Formalisierung durch spezifische Benutzer-/System-Szenarien

Schlüsselmerkmale:

Eindeutige Trennung von System- und Geschäftsregeln
Unterstützung der Nachverfolgbarkeit vom Ursprung bis zum Ort des Datenverbrauchs
Formalisierung in einem einheitlichen Register und ständige Aktualisierung dieser Regeln

Trickfragen.

Kann man sich nur auf Diagramme zur Beschreibung von Datenverarbeitungsregeln verlassen?

Nein, Diagramme allein sind nicht ausreichend. Auch eine textuelle Beschreibung, Bedingungstabellen und Beispiele sind notwendig, um Missverständnisse zu minimieren.

Muss man negative Szenarien (Ausfälle, Fehler) bei der Arbeit mit Integrationen dokumentieren?

Ja, unbedingt! Ohne solche Szenarien ist es unmöglich, eine korrekte Fehlerbearbeitung im Voraus zu planen und SLA zu gewährleisten.

Reicht es aus, nur technische Terminologie bei der Formalisierung von Datenverarbeitungsregeln zu verwenden?

Nein, für Transparenz und korrektes Zusammenarbeiten müssen Glossare verwendet und geschäftliche sowie technische Begriffe miteinander verknüpft werden.

Typische Fehler und Anti-Patterns

Beschreibung nur von Happy Path-Szenarien ohne negative und randliche Fälle
Unzureichende klare Dekomposition der Regeln, Vermischung von Zugriffssteuerungslogik, Validierung und Geschäftslogik
Fehlendes einheitliches Repository für formalisierten Regeln

Beispiel aus der Praxis

Negativer Fall:

Integration mit einem Cloud-Service zur Dokumentenerkennung. Der Systemanalytiker dokumentierte nur den grundlegenden Austausch und ließ randliche Fälle aus (z. B. Wartezeit auf eine Antwort, Rückgabe ungültiger Daten, Validierungsfehler im Format).

Vorteile:

Schneller Fortschritt in der Pilotphase

Nachteile:

Massenhafte Vorfälle nach dem Start aufgrund unbehandelter Fehler, instabile Funktionsweise

Positiver Fall:

Der Analytiker dokumentierte nicht nur den Happy Path, sondern auch alle randlichen und Ausnahmeszenarien, erstellte eine einheitliche Entscheidungstabelle für die Verarbeitungsregeln. Er führte eine Reihe von Workshops durch, überarbeitete das Glossar der Begriffe zwischen den Mitgliedern des KI-Teams und dem technischen Support.