Kaj se najprej zalomi, ko ročni proces povežemo z API-jem

Boštjan Korošak predlaga, da ne začnemo z opisom običajnega poteka, ampak s primerom, pri katerem se je nekaj zalomilo. Ko opazujemo, kje se oseba med prepisovanjem ustavi, popravi vrednost ali vpraša sodelavca, vidimo odločitve, skrite v vnosu podatkov: da sta »Acme« in »Acme Ltd« ista stranka ali kaj pomeni prazen datum dobave. Pred avtomatizacijo je treba prepisovanje ločiti od presoje.

Na primeru naročila članek nato obravnava odobritve in odgovornost za podatke. Status »odobreno« ne pove, kaj je bilo odobreno – cena, količina ali plačilni pogoji –, zato odobritev vežemo na točno določeno različico naročila in določimo, katere spremembe zahtevajo ponovno odobritev. Vsaka skupna vrednost potrebuje sistem, ki je zanjo odgovoren; ko se izvedba naročila začne, spremembe potekajo kot dopolnitve in preklici, ne kot popravki zapisa.

Zadnji del govori o napakah. Pri zahtevi, ki ostane brez odgovora, izida ne poznamo, zato integracija pred ponovnim poskusom potrebuje idempotenčne ključe ali enolične zunanje reference, ponovni poskusi pa si sledijo z vse daljšimi presledki. Ljudje potrebujejo sporočila o napakah, na podlagi katerih lahko ukrepajo, zgodovino dosedanjih poskusov in določeno osebo, ki skrbi za nerešene primere. Članek se zaključi s seznamom vprašanj, ki jih je smiselno zastaviti pred začetkom razvoja integracije.