Launching into a discussion about practical strategies for bringing legacy technology into the 21st century, Jonathan Leibbrandt, Senior Solutions Architect at TrueMark, describes application modernisation as ‘a fun topic’. “The first thing you need to know is that what’s often described as ‘legacy architecture’ or ‘legacy applications’ doesn’t mean it is old. Instead, legacy is not defined by age, but by risk – specifically, how difficult and dangerous a system is to change, and where those limitations ripple through into adverse implications for the business,” he sets out.
This is a crucial and sensible distinction, Leibbrandt points out, because this immediately determines which applications should be on the modernisation agenda, and which can continue to run as is.
“Other determining characteristics include aspects like coding tables with shared databases as an integration point causing bottlenecks; applications with low observability; and those depending on limited tribal knowledge for their support and maintenance (key man dependency). You also want to look out for architectures reflecting historical technical constraints rather than business needs,” he adds. “These factors are often the source of fragility, rather than the code or runtime.”
Modernising architecture, continues Leibbrandt, has little to do with adopting the "latest and greatest" platforms, and far more to do with creating systems that are evolvable, testable and resilient to change.
“You want results and you want to be cost aware, with measurable results structured around business capabilities rather than frameworks or platforms. Because, in some cases, a monolith works just fine, and attempting to move that to micro-services might cause more trouble than benefit.”
In other words, he says, shoehorning a problem into a standard ‘solution’ rarely delivers the desired results. “Any modernisation is about business alignment more than technological change.”
Asked where he starts when evaluating an application for modernisation, Leibbrandt says observation is step number one. “Most environments are brownfield, with existing customers and dependencies, and you need to respect that. That’s why, before changing anything, visibility is crucial. That includes logging, tracing and exposing real user journeys. You can’t refactor blind.”
The next step is mapping ‘real couplings’. “Believe me, what’s happening in reality is often pretty far from the contents of the architectural diagrams,” he smiles. “You want to tease out batch jobs hiding crucial business logic, find the hard-coded integrations, expose embedded credentials and reveal feature flags that cannot be removed.”
Close examination, he says, shows where the friction is, and where modularisation can be applied. “Extracting services too early is the biggest mistake we see. You want to group everything logically, assess impact and ownership and isolate context. This dramatically reduces risk and sets the scene for reducing the monolith with incremental change rather than replacing in one move.”
Notably, there is a major consideration needed on how to manage the changes required to modernise. This takes a disciplined approach to change management that, if ignored, can have dire consequences for the business. And that’s a practical strategy often ignored at considerable peril.
“Only decommission obsolete structure and functionality when the new components are trusted,” advises Leibbrandt. “Bear in mind that new architecture cannot survive alongside old operational practices. Culture has to change alongside new operations, or success becomes far more challenging. It may be the application we’re working on, but the business and its people have to evolve with it – because ultimately, that’s what application modernisation is really about. Not the technology, but the business.”
Share
