Was zuerst schiefgeht, wenn ein manueller Geschäftsprozess an eine API angebunden wird

Boštjan Korošak empfiehlt, nicht mit der Beschreibung des Normalablaufs zu beginnen, sondern mit einem Fall, bei dem etwas schiefgegangen ist. Wer beobachtet, wo jemand beim Übertragen innehält, einen Wert korrigiert oder im Team nachfragt, erkennt die Entscheidungen, die in der Dateneingabe stecken: dass »Acme« und »Acme Ltd« derselbe Kunde sind oder was ein leeres Lieferdatum bedeutet. Vor der Automatisierung muss das Übertragen von der Beurteilung getrennt werden.

Anhand eines Bestellprozesses behandelt der Artikel anschließend Freigaben und die Zuständigkeit für Daten. Der Status »freigegeben« sagt nicht, was freigegeben wurde – Preis, Menge oder Zahlungsbedingungen –, deshalb wird die Freigabe an eine bestimmte Version gebunden und festgelegt, welche Änderungen eine erneute Freigabe erfordern. Jeder gemeinsam genutzte Wert braucht ein System, das für ihn zuständig ist; sobald die Abwicklung begonnen hat, laufen Änderungen als Nachträge und Stornierungen, nicht als Bearbeitung des Datensatzes.

Der letzte Teil befasst sich mit Fehlern. Bleibt eine Anfrage unbeantwortet, ist ihr Ergebnis unbekannt; vor einem erneuten Versuch braucht die Integration daher Idempotenzschlüssel oder eindeutige externe Referenzen, und die Versuche erfolgen in wachsenden Abständen. Menschen brauchen Fehlermeldungen, mit denen sie handeln können, eine Historie der bisherigen Versuche und eine zuständige Person für ungelöste Fälle. Zum Schluss nennt der Artikel Fragen, die vor der Entwicklung einer Integration geklärt werden sollten.