A bank's nightly batch posts 40 million transactions on a mainframe in a 4-hour window, and everything downstream assumes balances are final by 06:00. A programme proposes replatforming the batch to a distributed processing engine. What is the right first move?
Show the full answer Hide the answer
The deciding property
The 4-hour window is not a performance target, it is a contract with everything downstream. Statements, regulatory extracts, interest accrual, card authorisation limits and a dozen reconciliations all assume balances are final by 06:00. A replatform that misses the window by twenty minutes on one night in ten is not a slower system; it is a breach of an agreement nobody has written down.
That makes the first move the one that reduces risk without touching the invariant.
Why offloading reads first
Most of what runs on the mainframe is not the posting engine. Reporting, extracts, analytics and read-mostly services typically account for a large share of the load and almost none of the risk, because they are consumers rather than the system of record. Streaming changes off the host and serving those consumers elsewhere does four useful things:
- It removes load from the window - often enough to make the batch comfortable again, which buys years of runway.
- It builds the data pipeline the eventual replacement needs anyway, and proves it against real data while the mainframe is still authoritative.
- It reduces the per-MIPS licence and capacity cost, which funds the next stage and gives the programme a result in months instead of years.
- It is reversible. If the pipeline is wrong, the authoritative system is untouched.
Why the other options fail
- "Rewrite the batch on a distributed engine and run both." This is the destination for some programmes and the wrong first step for almost all. It puts the hardest, most tightly-coupled component first, and parallel-running a posting engine means reconciling 40 million transactions a night against a system whose edge-case behaviour - rounding, back-dating, holiday calendars, correction entries - is documented only in its own source.
- "Convert the COBOL automatically and keep the design." Automated conversion produces code that behaves identically and that nobody can maintain: COBOL-shaped logic in another language, with the original's assumptions intact and its idioms gone. It is sometimes the right move to escape a hardware or licence dependency, and it buys none of the agility it is sold with.
- "Move to event-driven incremental posting." Architecturally the most attractive and the largest change in semantics. Batch posting gives a consistent cut-off: every account has one state at 06:00. Continuous posting gives balances that are always slightly different, which breaks reconciliation and regulatory reporting designed around the cut-off. It can be the right end state and it cannot be the first step.
What would flip the decision
| If this changes | Choose | Because |
|---|---|---|
| the window is already being missed | attack the batch directly | the invariant is already broken and buying runway is not available |
| the hardware or licence is being withdrawn on a date | automated conversion | the constraint is the platform, not the design |
| downstream consumers can accept eventual balances | incremental posting | the invariant was a technical artefact, not a business rule |
| the posting logic is small and well-understood | rewrite it properly | the usual blocker - undocumented behaviour - is absent |
When this is the wrong answer
If the mainframe's cost is the whole business case and the sponsor needs the host switched off within eighteen months, read-offloading alone will not deliver it and the programme should say so rather than start with a comfortable step and hope. A modernisation plan whose first phase cannot be followed by a second is worse than no plan, because it spends the political capital and leaves the posting engine exactly where it was.