Rootcause onderzoek met IBM Bob
Stijn heeft gebruikgemaakt van IBM Bob tijdens een complex root-cause onderzoek.
Gebruikers zagen in een export hashes in plaats van herkenbare bestandsnamen. Op het eerste gezicht lijkt dat een relatief eenvoudig probleem, maar de oorzaak bleek verspreid te zitten over meerdere applicaties, repositories en afhankelijkheden.
Om het probleem te doorgronden moest worden onderzocht waar de hashes vandaan kwamen, hoe deze werden verwerkt tijdens import en export en welke impact mogelijke wijzigingen zouden hebben op de rest van het systeem. Daarbij was het niet alleen belangrijk om de oorzaak te vinden, maar ook om mogelijke regressie risico's inzichtelijk te maken.
Met ondersteuning van IBM Bob kon Stijn sneller verbanden leggen, hypotheses toetsen en de juiste plekken in de codebase vinden. De verschillende onderzoeksstappen kostten samen ongeveer 3,5 uur. Op basis van ervaring schatten we dat dezelfde analyse handmatig ongeveer 12 uur had gekost.
Dat betekent ruim 8 uur tijdwinst op één analyse.
Voor ons laat dit zien dat de waarde van AI niet alleen zit in het genereren van code, maar juist ook in het sneller begrijppen van complexe softwarelandschappen en het ondersteunen van technische besluitvorming.
Dat is precies waar we bij Migrato steeds meer potentie zien in IBM Bob.
Bij de MICC Export zagen de eindgebruikers geen herkenbare bestandsnamen meer.
Eindgebruikers zagen in het resultaat van de MICC Export bij het aanvinken van de optie tot inkorten van namen, een resultaat waarbij de bestandsnaam aan het eind vier nietszeggende cijfers kreeg, hierdoor raakten medewerkers verward, omdat ze de nieuwe naam niet meer konden koppelen aan de oude naam, bijvoorbeeld: 'Factuur_2024.pdf' werd nu 'Factuur_5976.pdf'. De link naar het jaartal is hiermee verdwenen.
Om de oorzaak te vinden, zijn er met behulp van IBM Bob de volgende stappen ondernomen. Eerst moest er uitgezocht worden waar de codes vandaan kwamen en hoe documenten door verschillende werden verwerkt.
Met ondersteuning van Bob konden er sneller verbanden worden gelegd
Vaststellen wat de hash is. asset_id is een 32-tokens MD5 over 'folder path + filename' (TestQueries.java:6), gegenereerd door een upstream library die alleen als jar bestaat en via decompiled code is gelezen. De conclusie: onomkeerbaar en een primary key, dus traceerbaarheid moet eromheen worden opgelost.
Zoeken waar de hash zichtbaar wordt. Drie exports tonen de asset_id, maar als kolom/JSON-sleutel, niet als bestandsnaam. De reden hiervoor is de tonende app is de eerste logische plek. Dit verklaart het symptoon niet, dus het probleem splitste in twee agen (import-oorzaak vs. export-leesbaarheid) en de zoektocht ging upstream. Met de hulp van IBM Bob werd er gezien dat de drie exports die de asset_id tonen, en kon er meteen worden vastgesteld dat het in een kolom/sleutel gaat en niet om de bestandsnaam, waarmee de 'display-bug'-verklaring afvil. Handmatig had dit veel langer geduurd en ook flink meer handelingen.
Naar de importer. Toen de tonende app, de jars en het MICC framework geen verantwoordelijke code bevatten, bleef het importpad over. De reden hiervan was dat daar de opgeslagen bestandsnaam wordt gezet. Met de hulp van Bob werd al snel duidelijk dat de oorzaak in een tweede repo (MICC Import) moest liggen. Handmatig is juist het besef dat er een tweede repo meespeelt het lastigst
Oorzaak aantonen
Bij import wordt een UUID gegenereerd en als bestandsnaam weggeschreven naar core_assets.filename. De originele naam is beschikbaar en wordt wel voor object-rijen gebruikt, niet voor document-rijen. Met de hulp van Bob volgde ik de import-flow in ongeveer 30 minuten tot de exacte regels: de UUID wordt als filename weggeschreven, terwijl de originele naam wel voor object-rijen wordt gebruikt en niet voor document-rijen. Als dit handmatig had moeten gebeuren, was de kans groot dat dit over het hoofd was gezien. Door het gebruik van Bob heeft dit 4 uur gescheeld.
IBM Bob gebruikt voor een root-cause onderzoek.
Een rootcause onderzoek naar ongewenst gedrag en het valideren van mogelijke oplossingen hiervoor. Eindgebruikers zagen in de MICC-Export een has in plaats van een herkenbare bestandsnaam of folderpad waardoor documenten niet meer goed uit elkaar konden worden gehouden.
De manier van samenwerken met Bob is fijn. Bob stelt zich prettig op. Je blijft veel meer in controle wanneer je ermee werkt. Daarnaast is het opvallend eerlijk vergeleken met vergelijkbare tools. Wanneer Bob iets niet zeker weet, geeft het dat meestal aan in plaats van zelfverzekerd iets te verzinnen dat niet klopt. Voor het snel maken van een eerste opzet, het navigeren van een codebase en het valideren van een implementatie idee of een proefversie is het een aanrader.
Publicatiedatum: 07/08/26
Migrato
Nieuwsbrief
M - 06 41693236
© 2026. Alle rechten voorbehouden.
T - 010 3216244
E - info@migrato.nl
Navigatie
A - Nieuwe Haven 39
3291GA Strijen
Transforming Content To Knowledge
