Geschiedenis van de vraag: In initiatieven voor bedrijfsmodernisering komen bedrijfsanalisten vaak kennisverval tegen - een fenomeen waarbij kritische bedrijfslogica alleen voortleeft in onleesbare legacy-code. Deze vraag kwam voort uit mainframe-naar-cloud migraties waarbij de oorspronkelijke architecten tientallen jaren geleden met pensioen gingen, met achterlating van COBOL programma's die perfect functioneren maar moeilijk te interpreteren zijn. De historische context omvat de overgang van monolithische batchverwerking naar gedistribueerde microservices, waarbij implicatiefbeheer expliciete API-contracten moet worden.
Het probleem concentreert zich rondom epistemische opaciteit: het systeem werkt, maar niemand weet waarom. De COBOL codebase bevat impliciete bedrijfsregels - randgevallen, regulatoire patches en handmatige overrides - die nooit zijn gedocumenteerd omdat de oorspronkelijke ontwikkelaars deze in hun geheugen hielden. De huidige operationele staff begrijpt de invoer- en uitvoerwaarden, maar niet de beslissinglogica. Ondertussen vereist de nieuwe cloud-native architectuur dat deze regels worden ontkoppeld, gedocumenteerd en via REST eindpunten worden blootgesteld voor realtime consumptie. De vaste regulatoire deadline voorkomt een meerjarige archeologische zoektocht, maar fouten in de extractie van regels kunnen leiden tot schendingen van GDPR gegevensverwerkingsmandaten of onjuistheid in financiële rapportages.
De oplossing maakt gebruik van een ge- trianguleerd reverse-engineering aanpak. Ten eerste, voer Event Storming workshops uit met operationele medewerkers om observeerbare bedrijfsgedragingen in kaart te brengen en "zwarte doos" processen te identificeren. Ten tweede, gebruik statische code-analysetools om controle-stroomgrafieken van de COBOL programma's te genereren, waarbij variabele mutaties worden gekruist met zakelijke resultaten. Ten derde, implementeer een parallel lopende schaduwmodus, waarin de nieuwe microservice processen transacties spiegelen tegen het legacy-systeem zonder productie-impact, en afwijkingen markeren voor onderzoek. Dit creëert een feedbackloop waarbij code-archeologie de herinneringen van belanghebbenden valideert, en de context van belanghebbenden code-anomalieën verklaart.
Een regionale verzekeringsmaatschappij moest een beoordelingsmachine voor polissen in COBOL uit de jaren '80 vervangen door een Python/FastAPI microservices suite om realtime mobiele offertes mogelijk te maken. De oorspronkelijke berekeningslogica omvatte complexe territoriale risicowegingen, seizoensgebonden aanpassingsfactoren en clausules voor herverzekering die in de afgelopen veertig jaar waren gepatcht. De drie overgebleven COBOL-ontwikkelaars waren met pensioen gegaan, en het huidige IT-personeel beschouwde het systeem als een "magische doos" die correcte premies produceerde maar niet de wiskundige afgeleiden voor specifieke randgevallen kon uitleggen. De regulatoire autoriteit had de migratie binnen acht maanden verplicht gesteld om schikkingen voor onbeheerde infrastructuur te voorkomen.
Er werden verschillende benaderingen geëvalueerd om de vereisten vast te leggen. De eerste optie stelde een code-aan-spec transcriberen voor, waarbij ontwikkelaars handmatig elke IF-verklaring en MOVE-bewerking in de COBOL brondocumenten. De voordelen waren theoretische volledigheid en behoud van exacte logica. De nadelen waren ernstig: de codebase bevatte meer dan twee miljoen regels spaghetti-code met ongedocumenteerde globale variabelen, waardoor dit een multi-jaren inspanning zou zijn die de deadline zou missen en waarschijnlijk transcriptiefouten zou introduceren.
De tweede optie stelde black-box vereiste afleiding voor, waarbij invoer (polisseigenschappen) en uitvoer (premiebedragen) werden geobserveerd om regels af te leiden via statistische regressie. De voordelen waren snelheid en focus op huidige zakelijke waarde in plaats van technische schuld. De nadelen omvatten de onmogelijkheid om inactieve codepaden voor zeldzame claimscenario's te detecteren en het risico dat bugs als functies gecodificeerd worden.
De derde optie, gedragsarcheologie met parallelle validatie, betrof het extraheren van voorbeeldgegevens uit vijf jaar productie-logs, het bouwen van beslisbomen uit daadwerkelijke transacties en deze valideren tegen de COBOL bron met behulp van geautomatiseerde diff-tools.
Het team koos de derde oplossing omdat deze snelheid met nauwkeurigheid in evenwicht hield terwijl het de agile principe van werkende software boven uitgebreide documentatie eert. Door te focussen op uitgevoerde codepaden in plaats van dode functies, verlaagden ze de scope met 60%, terwijl ze garandeerden dat actieve bedrijfsregels correct werden vastgelegd. Ze stichtten een data lake met geanonimiseerde historische transacties en lieten deze door zowel de legacy JCL-taken als de nieuwe FastAPI-diensten lopen, waarbij automatisch premiecalculatiemismatches groter dan 0,01% werden gemarkeerd. Dit onthulde drie kritieke ongedocumenteerde voorwaarden: een hurricane-deductible override voor Florida-policies uitgegeven vóór 1992, een speciale commissie-berekening voor gepensioneerde agenten, en een afrondingsfout in kwartaalbelastingrapportage die decennia lang was "gecorrigeerd" door handmatige spreadsheet-aanpassingen. De microservices werden herontworpen om deze randgevallen expliciet te behandelen als configureerbare bedrijfsregels in plaats van hardcoded constanten.
Wanneer reverse-engineering legacy code, hoe onderscheid je een kritieke zakelijke beperking van een technische oplossing die veilig kan worden geëlimineerd tijdens migratie?
Kandidaten gaan vaak uit van de veronderstelling dat alle bestaande logica een actuele zakelijke functie dient, en vallen in de verzonken kostenval van legacy-bescherming. De juiste aanpak omvat temporale contextanalyse: het onderzoeken van de datumstempels van codewijzigingen om te correleren met bekende regulatoire veranderingen, fusies of technologiebeperkingen die niet meer bestaan. Bijvoorbeeld, een gegevensafkortingsroutine in COBOL kan alleen bestaan omdat het oorspronkelijke DB2-schema vaste breedtevelden gebruikte, terwijl moderne PostgreSQL variabele lengte-strings ondersteunt - waardoor de noodzaak voor de afkortingsregel geheel vervalt. BAs moeten intent verificatiesessies met zakelijke belanghebbenden voeren, waarbij ze vermoedelijke oplossingen presenteren als "We kunnen dit vereenvoudigen door X te verwijderen; heeft dit invloed op uw naleving?" in plaats van te vragen "Moeten we X behouden?" Dit verschuift de bewijslast naar noodzaak in plaats van behoud.
Hoe voorkom je het "cargo cult" anti-patroon waarbij het nieuwe systeem inefficiënte batchverwerkingsworkflows eenvoudigweg herhaalt omdat deze bestaan in de COBOL monoliet?
Veel kandidaten focussen uitsluitend op functionele pariteit zonder procesherontwerp. De mislukking vindt plaats wanneer BAs de huidige status documenteren (bijv. "Het systeem draait een nachtelijke batch om 2 uur 's nachts") als een vereiste voor de toekomst, zonder te erkennen dat evenementgedreven architecturen die gebruikmaken van Apache Kafka of RabbitMQ realtime verwerking mogelijk kunnen maken. De oplossing vereist capaciteitsmapping: het scheiden van het "wat" (risicoberekening moet plaatsvinden) van het "hoe" (batch versus streaming). BAs zouden waarde-stroommapping moeten uitvoeren om wachttijden in het batchschema te identificeren die operationele gemakken dienden in plaats van bedrijfsregels. Door aan te tonen dat REST eindpunten onmiddellijke feedback kunnen bieden aan acceptanten - het verminderen van de tijd van offerte tot binding van 24 uur tot 30 seconden - rechtvaardigen ze architecturale veranderingen die anders zouden worden afgewezen als "te verschillend van het oude systeem."
Wat is jouw methodologie voor het kwantificeren en communiceren van het risico van "onbekende onbekenden" - impliciete regels die nooit zijn geactiveerd tijdens je observatieperiode van monsterdata maar catastrofaal kunnen optreden na migratie?
Kandidaten presenteren vaak belanghebbenden valse zekerheid op basis van 100% testslagen tegen historische gegevens. Het geavanceerde antwoord erkent monsternemingsbias in legacy gegevens en pleit voor stress-testing tegen synthetische scenario's. Dit houdt in dat fuzzed input data wordt gegenereerd die grensvoorwaarden oefent die niet zijn gezien in productie-logs, en vervolgens de output van COBOL en het nieuwe systeem worden vergeleken. Bovendien moeten BAs een circuit-breaker patroon in de nieuwe architectuur vaststellen: als de microservice een transactie-structuur tegenkomt die het niet kan verwerken (wat wijst op een gemiste regel), moet deze elegant afbreken naar het aanroepen van de legacy SOAP wrapper (indien beschikbaar) of markeren voor menselijke beoordeling, in plaats van stilletjes te falen of standaard naar null-waarden over te schakelen. De communicatiestrategie omvat probabilistische risicomatrices die aantonen dat hoewel 95% van de regels gevalideerd zijn, een 5% residuale onzekerheid een periode van drie maanden hypercare vereist met verdubbelde handmatige reconciliatiecontroles.