3 oorzaken (en oplossingen) bij een geëxplodeerd IT-systeem na livegang

Hoe komt dit en hoe los je het op? In deze blog behandel ik, Jeroen Kooij, principal consultant bij AMIS, 3 oorzaken en oplossingen. Ze gaan over risico-inventarisatie, een uitgekleed Minimum Viable product (MVP) en het ontbreken van standaardoplossingen. Ik verklap alvast: Meer tijd voor nadenken, bouwen en testen staat niet op het lijstje. Budget en doorlooptijd zijn nooit onbegrensd en dat is maar goed ook.

Een ‘no-brainer’ wellicht, maar ik zie genoeg voorbeelden waarbij vooraf onvoldoende wordt stilgestaan bij wat er in het te bouwen systeem fout kan gaan en wat er nodig is om dat te voorkomen. Testers zijn hier altijd op gefocust, maar die worden vaak pas aangehaakt zodra er al van alles bedacht en gebouwd is. Dit is meteen een pleidooi voor test-driven development en Agile werken in het algemeen.  Ook waar deze methoden niet worden gehanteerd, kun je veel bereiken met risicoanalyse.

Misschien herken je ‘risicoanalyse’ als een sessie rond een Excellijst met gekwantificeerde kansen maal effectwaarden plus maatregelen. Om de leden van een Agile development team niet van hun levensvreugde te ontdoen, pak ik het liever anders aan. In refinementsessies zijn teams prima in staat om samen via een rondje doemdenken de scenario's te vinden waarbij het systeem stuk gaat als je niks doet.

De kernvragen die worden gesteld, zijn:

• Welke restricties zijn nodig in request messages, om te waarborgen dat de input verwerkbaar is?
• Zijn er vanuit het achterliggende proces criteria voor verwerking?
• Is er vanuit de gebruikte tooling een kans dat we berichten kwijtraken?
• Hoe zal de service reageren als het request-aantal of -patroon de verwachting overstijgt?
• Merken we het als er fouten optreden aan onze kant en hoe erg is dat?

Overigens: niet zelden zie ik dat de risico’s zitten in matig functioneel ontkoppelde systemen. Daarmee bedoel ik systemen die logica hebben die over en weer gebaseerd is op impliciete aannames over wat er in de data zit en via welke regels dit verwerkt wordt. Het helpt op voorhand om daar architectuur uitgangspunten over af te spreken.

Tijdsdruk en onduidelijke communicatie kunnen ervoor zorgen dat kritische kwaliteitscriteria uit het product voor de eerste productiegang verdwijnen. Het meest absurde voorbeeld dat ik heb meegemaakt, draaide om spraakverwarring rondom het begrip 'happy flow'. Deze term werd door business analisten uitgelegd als de proces-scenario’s waar de grootste aantallen doorheen gingen en niet de uitzonderingen. De uitleg van de development teams van ‘happy flow’, was dat gebouwde IT-services voor de 'minimal viable product' niet rekening hoefden te houden met technische foutpaden. De product owner nam aan dat de teams het product een minimale robuustheid meegaven. De teams verwachtten hier specifiek omschreven requirements voor en gingen bij afwezigheid daarvan voor de snelst te bouwen oplossing. Dit leverde een steady stroom van bugs op, met alle vertraging en efficiency van dien.

Wat werkt dan wel? Streef als development team altijd een minimale robuustheid na en baseer daar je tijdsinschattingen op. Opdrachtgevers verwachten kwaliteit en die verwachting is niet altijd expliciet gemaakt. Als team zou ik daarom altijd in alle openheid heel terughoudend zijn in het onderhandelen op robuustheid ten gunste van doorlooptijd. Als je toch compromissen aangaat, zorg dan dat de risico’s bekend zijn.

Het proces is wel tricky. Developers hebben niet zelden ‘gold plating’ neigingen in de techniek. Het zijn mensen die door hun uitstekend ontwikkelde analytisch vermogen het allerlaatste non- ‘happy flow’ pad weten te vinden en vervolgens niet kunnen rusten voordat er een oplossing voor is. Voor een aantal is het erg lastig om iets dat in theorie fout kan gaan, bewust te laten zitten.

IT-projecten hebben maar al te vaak een carrousel van ingehuurde teamleden die het wiel opnieuw uitvinden. De robuustheid is niet zelden volledig afhankelijk van meegebrachte best practices vanuit de ervaring van developers. Veranderingen in de bemensing, of het bijschakelen van hele teams kunnen een teruggang veroorzaken.

Het verdient zich snel terug om robuustheid oplossingen herbruikbaar te maken, zowel in best practices ‘zo doen wij dit’ als in herbruikbare code. Het is een enorme tijdbespaarder en ik nomineer graag alvast wat patronen die veel ellende besparen:

• Hanteer in system-2-system interfacing het ‘fail fast’ principe, wat betekent dat je request validaties zo streng mogelijk en aan de poort doet, om te voorkomen dat er verderop in het systeem iets misgaat.
• Bouw standaard idempotente interfaces, wat inhoudt dat hetzelfde request niet nogmaals tot verwerking leidt.
• Zorg dat data nooit kwijt kan raken via retry-mechanismen en dead letter queues. Het gebruik van applicatie templates is aan te raden als je ontwikkelt via serverless computing services van de bekende Cloud Service aanbieders.
• Zorg voor fail-over en auto-scaling oplossingen waar het verwachte gebruik dat vereist.

Een IT-systeem dat na livegang uitstekend werkt en klaar is voor doorontwikkeling. Maandenlang heb je hard gewerkt aan je data koppelingen met de buitenwereld en op een paar minor bugs na zijn er geen problemen. De lat lag voldoende hoog bij eerste productiegang en team-gedreven, herbruikbare maatregelen leverden ingebakken robuustheid op.

Er is nog veel meer te schrijven over dit onderwerp. Voor de IT’ers in mijn netwerk: Wat zijn jullie ervaringen met dit onderwerp en wat zou je toevoegen?

Jeroen Kooij is principal consultant bij AMIS/Conclusion. Hij helpt klanten om hun IT-landschap te ontvlechten en toekomst vaste integraties tussen IT-systemen te realiseren.
Ben je benieuwd naar de werkzaamheden van Jeroen of wil je meer weten over het bedrijf dat zich bezig houdt met Internet of Things, Data- en Integratie Engineering, Datagedreven toepassingen en Data Platforms? Check werken bij Amis