After decades of oscillating between enterprise platforms and best-of-breed solutions, investment managers are pivoting towards a new technology model that promises flexibility without chaos: microservices – or, as some in the industry now call it, the ‘Lego block’ approach to technology architecture.
The problem statement is a familiar one. For decades, institutional investors have tried to reconcile two competing priorities: the efficiency of a single enterprise platform and the flexibility and adaptability of best-of-breed solutions. The result, in many cases, has been a patchwork of risk engines, performance tools, and – despite years of digital transformation – a persistent reliance on spreadsheets to plug any gaps. Meanwhile, multiple systems mean inconsistent methodologies, timing mismatches, and user experiences that vary wildly across the business.
Speaking at the 10th Investment Data and Technology Summit in Sydney, Peter Sherriff, Director – Product Strategy APAC at Charles River Development (which is part of State Street), said that part of the challenge is in the fact that there simply is no one single solution that can solve for every single use case in every single organisation at the level of detail that individual firms require. “Everybody has a different set of business requirements, a different way to solve for that, a different capability in terms of what they can manage internally and externally,” he said.
“Over the years, we’ve seen a cycle between best-of-breed and enterprise solutions, with people trying to close the gap between the best-of-breed solutions they have, or trying to build something around their core enterprise platform. What tends to then happen is that people revert back to spreadsheets as a quick and easy ‘citizen development’ solution, when in reality the business would be better off looking for meaningful solutions when there’s something a platform isn’t capable of doing,” Sherriff said.
That’s where microservices come in. Instead of writing applications as one large monolithic block of code applications or loosely stitched “Franken-stacks,” microservices break functionality into small, independent components that can be deployed, scaled, and evolved without overhauling the entire system. The concept is simple, which is where the ‘Lego block’ analogy comes in. Each capability is treated like an individual ‘block’ that can be stacked together. Need new analytics? Add a block. Want to replace an outdated function? Swap a block. Each service operates independently but connects through standard APIs, creating an ecosystem rather than a single structure.
Adoption is still nascent. An audience poll at the Investment Data and Technology Summit found that 48 per cent had never heard of the concept; 36 per cent were aware and exploring and just 15 per cent had implemented or were implementing.
However, for early adopters, the benefits are tangible. Insignia Financial started its journey into microservices as early as 2012. “We had a monolithic application that just wouldn’t scale, calculations would take many hours. Using microservices allowed us to take our legacy applications as they were and start to carve off little bits of functionality to get more real-time information,” Darren Thorpe, Head of Enterprise Engineering at Insignia Financial told the audience.
Thorpe said that these days, calculations that once took hours now run in near real-time. Teams can deploy updates without impacting the entire system, the system is more resilient, more secure and agnostic to both technology and cloud provider.
“It sped up that feedback loop in terms of data, it allowed our developers to move much quicker in terms of evolving client expectations. But it also delivered something that’s more secure. It’s more resilient. When you have all these microservices running, you spin up the ones you need – just those – and you’ve got a lot of resilience. If one fails, it doesn’t have any impact on any of the other microservices,” Thorpe said.
Why Microservices, Not SOA?
The industry isn’t unfamiliar with modular approaches. Service-oriented architecture (SOA) has also been heralded as a solution. But according to panellists at the 10th Investment Data and Technology Summit, microservices differ in two critical ways: elasticity and cost control.
A major benefit is in agility. New business requirements can be addressed without waiting for major release cycles or resorting to tactical spreadsheets. “Microservices offers our clients a choice to fill those gaps without having to wait for cycle enhancements, new capabilities, not just in our platform, but across that core ecosystem,” Sherriff said.
He also said that while the costs of microservices are variable – against the fixed costs of a legacy SOA infrastructure – microservices are not necessarily more expensive, and they may well come out cheaper, particularly for asset managers with cyclical workloads such as quarterly reporting. “The advantage of the microservices perspective is to provide that on-demand elasticity. Being able to scale that on-demand for that once a quarter cycle actually means you have much better control and manage your costs overall,” Sherriff said.
Insignia’s Thorpe also said that compared to the complexity of solutions that can be built quickly, microservices have proven cost effective. “We use a lot of open-source frameworks, which means much of the heavy lifting is done for us. As a result, the maintenance is a lot smaller than we had before we moved to a microservices architecture.”
Barriers to Adoption
Despite the promise, moving to microservices isn’t without challenges. Governance and complexity are top concerns.
“From a governance framework point of view, you want to align your microservices to your domain-driven design. The biggest challenge I can see is in data,” Sreesubha Chandrakaladharan, Owner Investment Platforms at AMP, which is considering implementing a microservices architecture, said. “When you talk about microservices architecture, each of these microservices comes with its own database, and you need to align each of these standards to your final reporting requirements, whether it is for regulatory or internal reporting. So that is something which we need to be really careful about,” Chandrakaladharan said.
She added that successful implementation will require a significant inhouse skills. “Unless you have a really mature DevOps practice, it’s not easy to get into microservices model of delivery or more agile model of delivery,” Chandrakaladharan said.
Successful adopters emphasise governance and design discipline. Aligning microservices to domain-driven architecture ensures clarity on ownership and data standards.
“With monolithic apps it is very hard to control down to individual personas what they should and should not be able to have access to. Within microservices, our principle is that each service is owned end-to-end, including the data, so we can deliver persona-specific interaction. It gives us much stronger control and resilience than we had before,” Thorpe said.
The shift also requires cultural change. Engineers need the tools and autonomy to deliver services independently, while product and business teams must adapt to more iterative delivery models.
Insignia’s Thorpe said a rule of thumb is to ensure services are “as big as your head”: small enough to understand, but large enough to handle a domain problem, and then focusing on “quick wins” to get the business on board.
“It’s about as much information as you can hold in your head at any one time. Our principle was that services should be limited to one customer domain, but probably do more than one thing. So smaller than the SOA model we were talking about,” he said.
Thorpe said that AI tools are now available that can help to identify optimal service boundaries and re-factor existing services when needed.
“AI is actually helping you now to identify what the shape of those little Lego blocks should be and it’s helping you really quickly re-factor it if you don’t quite get it right. Our experience has been that giving the engineers the tools and working with product to determine the shape and size of those microservices been really effective,” Thorpe said.
