Recovering the business logic from an integration platform
Unversioned Java 6 running in production, too big to execute. The only way in was to test fractions of it until the business rules fell out.
A food company was building a new integration platform for products delivered by subcontractors. The system it was replacing was live, unversioned, and the only remaining record of a large amount of business logic.
Context
August to October 2022, through Sopra Steria.
The legacy system had to move, but a great deal of its business logic was not easy to reach. The deployed Java was unversioned — no history to read and no intermediate states to compare, so the reasoning behind any given behaviour was not recoverable from the code alone. Alongside it sat databases whose stored procedures also needed investigating and documenting. The logic had to be improved and optimised on the way out, not simply transcribed.
The task was to reverse-engineer all of it and map the business logic as input for the new platform’s development projects.
My role
Reverse engineering and documentation, producing the business logic map the new platform was built from.
Key decisions
Work backwards from implementation to intent, by fractions. The system could not be run at full scale to test against, so the method was to isolate fragments and verify business use cases against those instead — establishing what a piece of code did, then arguing from that to what it was for.
This forced an unusually literal reading of old Java. Behaviour that sits below the level you normally think at — built-in function semantics, version-specific details of the language itself — becomes load-bearing when you cannot simply execute the thing and watch. Reading an implementation when you cannot run it is a different skill from reading one when you can.
Not being able to test it was what forced the depth. When you can run code, you can stay at the level of its intent and let the machine confirm the details. When you cannot, the details are all you have, and understanding the language itself becomes the only route to understanding the program.
Tradeoffs
Fraction-level verification gives high confidence in each fragment and no guarantee about how the fragments behave together. That gap was accepted rather than closed — there was no way to close it without being able to run the system.
What offset it was reading at a larger granularity alongside the testing: taking functions and classes as whole units and understanding them structurally, not just verifying their pieces in isolation. Execution proved the fragments; reading carried the composition.
The logic was also improved and optimised rather than ported as-is, which means separating behaviour that was a genuine business rule from behaviour that had simply become established over time. With no specification and no version history, there was no authority to appeal to. That call sat with whoever was reading the code — which is to say, with me.
Outcome
The work handed over the business processes and a large set of business use cases — an account of what the system actually did in business terms rather than in code.
What the new platform’s development projects needed was not the code but the layer above it: the processes and use cases, stated in the language of the business, that the implementation had been serving all along.
Java 6 · MS SQL · DB2 · Reverse Engineering