In januari 2020 zijn we gestart met hoofdstuk 1 (link), in februari met hoofdstuk 2 (link), in april met hoofdstuk 3 (link), in mei met hoofdstuk 4 (link), in juni met hoofdstuk 5 (link), in juli met hoofdstuk 6 (link), in augustus hoofdstuk 7 (link), in september hoofdstuk 8 (link), in november hoofdstuk 9 (link), in februari 2021 hoofdstuk 10 (link) en nu wordt het tijd voor hoofdstuk 11.
De titel van hoofdstuk 11 is "Intermission: an insurance policy for free".
Na alle hoofdstukken over acties om je systeem beter (en daardoor ook veiliger) te maken is dit hoofdstuk even een "pauze" in het boek. Voor we straks bij hoofdstuk 12 in het deel zitten waarbij we de zaken van hoofdstuk 3 tot en met 10 gaan toepassen, gaan we in dit hoofdstuk naar een praktijksituatie kijken. Het gaat over een verzekeringsmaatschappij die verzekeringen verkocht... zonder er geld voor te krijgen. En we gaan natuurlijk ook kijken hoe dit voorkomen had kunnen worden.
De verzekeringsmaatschappij had in het verleden kantoren in verschillende steden. Mensen die hun huis of auto wilden verzekeren gingen naar het kantoor, betaalden contant voor hun polis (om deze aan te kopen/verlengen), er werd een mail naar het hoofdkantoor gestuurd en de klant ontving dan een polis. Omdat de boel geautomatiseerd moest worden, werd dat verder afgehandeld bij het hoofdkantoor.
Omdat er verschillende polistypes kwamen, contracten met leveranciers, reparatiebedrijven kwam er een splitsing binnen het hoofdkantoor, financiën die de betalingen beheert en de polis-afdeling, die de polissen afhandelen, een soort micro-services configuratie. Doordat er via financiën een "betaling" binnenkomt, is dat de trigger voor de polis-afdeling om een polis uit te geven of een polis te verlengen.
Vervolgens komt naast de cash-afhandeling ook een bank-giro betaalmogelijkheid. Ook hier is een "betaling"-actie. Deze wordt 1-op-1 meegenomen in het systeem van de verzekeringsmaatschappij. Dat lijkt allemaal goed te gaan, tot iemand schade heeft, blijkt dat die persoon wel een polis gekregen heeft, maar niet betaald heeft (en dit later na schade rijden alsnog heeft gedaan om te kunnen zeggen: zie je wel dat ik betaald heb). Omdat deze persoon een polis gekregen heeft, oordeelt de rechter dat de verzekeringsmaatschappij gewoon moet uitbetalen.
De bug is ontstaan door een gebrek aan communicatie. De documentatie van de bank-giro maatschappij was beknopt, maar hierin kon je wel lezen dat je een Payment-actie had (de klant heeft een verzoek gedaan om een betaalactie uit te voeren), confirm (de betaling is succesvol uitgevoerd en bounce (betaling mislukt, nog x pogingen om het te proberen). Waarbij als die x op 0 staat de betaling als mislukt beschouwd kon worden.
De afdeling financiën had eerder een bug veroorzaakt en probeert het systeem zo weinig mogelijk aan te passen en verwerkt de Payment-actie (betaling) als een betaling in het eigen systeem. Foutief, want alleen een confirm-actie had als betaling aangemaakt moeten worden.
Conclusie, doe geen aannames, woorden die in het ene systeem X betekenen, kunnen in een andere systeem Y betekenen (een order bij BOL.com is iets anders dan een order die een soldaat krijgt) en zorg voor goed intern en extern overleg. En zoals ook in het boek getoond wordt, maak schema's om zaken visueel duidelijk te krijgen, het zegt soms meer dan een A4 vol met tekst.