Cruxly

Cruxly › Forward deployed engineer › Decomposition Cases

Legacy Claims-System Integration

the customer's own system is the thing standing between you and the problem

Open the interactive lesson

Prompt: an insurance company says their claims-adjuster team spends too much time manually cross-referencing new claims against a fifteen-year-old policy database to check for coverage conflicts. They want this "automated." The database is a mainframe system nobody at the company fully understands anymore; the original vendor no longer exists.

45 minutes first. The tempting read is "build a conflict-detection service." The actual first problem is that you cannot safely query, and cannot fully trust, the system you'd need to check against.

Clarifying questions that matter here

"Who currently knows how to query this mainframe, and how do they do it today?" If the answer is "one retiring employee who runs a nightly report by hand," the integration surface isn't an API — it might be that employee's process, which is a completely different and much riskier dependency than a documented system.

"Has anyone tried to extract or mirror this data before, and what happened?" A "yes, and it corrupted a batch job" answer changes the entire approach — it tells you the mainframe is fragile under load in ways nobody has fully mapped, which argues strongly for read-only, low-frequency access rather than anything resembling a live integration.

"When the adjuster finds a conflict manually, how do they know it's real and not a data-entry error in the old system?" This is the question that most candidates skip, and it's the one that matters most: if the mainframe's own data has a known error rate, an automated conflict detector inherits that error rate and amplifies it, because it will flag every ambiguous case, including the ones the humans currently resolve through informal judgment.

"What's the cost of a missed conflict versus a false alarm?" A missed real conflict might mean the company pays out on a policy it shouldn't have — expensive and slow to discover. A false alarm costs an adjuster a few minutes of double-checking. That asymmetry argues for a design that's deliberately over-cautious (favoring false alarms) rather than one tuned for precision.

The decomposition: wrap, don't replace, and prove access before building logic

Slice 1 — a read-only, low-frequency mirror, not a live query path. Given a fragile, undocumented mainframe, the first buildable thing is not conflict detection at all: it's a nightly batch export into a modern, queryable store that the rest of the system can safely hit without ever touching the mainframe directly again. This slice produces zero customer-visible value on its own, and that's fine — it's there to de-risk everything after it, and to surface exactly how unreliable the source data actually is once you can finally query it properly.

Slice 2 — surface known data-quality issues to a human, before automating anything. Once the mirror exists, run simple consistency checks (duplicate policy numbers, contradictory coverage dates) and show the results to the claims team, framed as "here's what we found in your own data" rather than "here's our conflict detector." This does two things at once: it's useful to the customer immediately, and it calibrates how much you can trust the source for the real feature.

Slice 3 — rule-based conflict flagging on the mirrored, cleaned data, tuned deliberately toward false alarms given the earlier answer about asymmetric cost. Not a learned model — a small number of explicit rules an adjuster can read and understand, because the team needs to trust why something was flagged, not just that it was.

Why this order, specifically: building the conflict logic first, against a mainframe you don't yet trust, means every wrong flag is ambiguous — is the logic wrong, or is the underlying data wrong? Slicing the trust-building step out first turns that ambiguity into a solved problem before the feature the customer actually asked for is built at all.

The riskiest unknown, and what a week-one prototype actually tests

The single biggest unknown is not "can we detect conflicts" — it's "will the mainframe even tolerate a nightly export without breaking." Given the earlier finding that extraction has caused problems before, the first week's actual deliverable is not a demo of conflict detection at all: it's a successful, unattended nightly export running for five consecutive nights without incident, against the real system, at the real data volume.

This reframes what "progress" looks like to the customer in week one, and that reframing has to be said out loud, because a customer expecting a flashy demo will be unsettled by "we spent the week proving we can safely read your data." The honest framing: "the thing most likely to derail this project isn't the detection logic, it's whether your mainframe can support any automated access at all — so that's what we're testing first, and I'd rather find out in week one than after we've built the feature on top of it."

If the export destabilizes anything, the whole plan changes — maybe access has to be even less frequent, maybe it has to go through the retiring employee's existing process rather than a new direct connection. Finding this out with a low-stakes export job costs a week. Finding it out after building conflict-detection logic on top of an assumed-stable connection costs the length of the entire engagement.

Follow-ups they will ask

"The retiring employee leaves in two months. What changes?" This is a deadline on the discovery phase, not just an HR detail — whatever undocumented knowledge lives only in that person's head has to be extracted into the mirror's logic and written down before they go. Naming this as a scheduling constraint that reorders the slices, rather than a sad fact, is what an interviewer is listening for: the mirror work moves up, and a knowledge-capture session with that employee becomes an explicit, calendared deliverable rather than an intention.

"The customer asks you to just replace the mainframe entirely — it's obviously the root problem." The honest answer is that replacement is plausibly correct long-term and almost certainly wrong as a first move: the mainframe's behavior is the only existing specification of what the business rules actually are, and nobody currently understands it well enough to write a replacement that matches. The mirror from slice 1 is what eventually makes replacement possible, because it's the first time anyone can see the data clearly enough to specify the rules. Framing replacement as "a later project this work unlocks" rather than refusing it outright is both true and the better customer conversation.

"Your conflict rules flag a claim the adjusters are certain is fine. Who wins?" The adjusters — and the more important answer is what happens next: a disagreement is a signal that either a rule encodes a misunderstanding, or the source data for that claim is wrong, and both are worth investigating rather than overriding. Building a lightweight way for an adjuster to mark a flag as wrong, with a reason, turns disagreements into the feedback that improves the rules instead of into quiet distrust of the whole tool.

"Can this run in real time instead of nightly?" Given everything learned about the mainframe's fragility, the honest answer is "not against that system, and I'd want to know why real-time is needed before designing around it" — if claims are reviewed on a next-day cycle anyway, nightly matches the actual business rhythm and real-time buys nothing for real operational risk.

How to say it in the interview

"Before I design a conflict-detection anything, I need to know what I'm actually allowed to touch — a fifteen-year-old mainframe with no living expert is not a data source, it's a constraint that shapes every later decision. My first slice has nothing to do with detecting conflicts; it's about finding out what that system will actually let me safely read."

Checklist

Practice this interactively
Share this lessonWhatsAppLinkedInX

Related lessons