As asset managers grapple with new digital technology, FundsTech talks to Calastone’s Adam Belding about the importance of software architecture and the benefits of microservices.
The funds industry is seeing a wave of new technology with the potential to fundamentally change the market. It is not just the likes of digital assets, cryptocurrencies and security tokens and their ability to transform old, illiquid asset classes and create entirely new ones. Artificial intelligence, machine learning and natural language processing can provide entirely new ways of analysing data. And distributed ledger technology can make the post-trade side of the market much more efficient and resilient.
But despite all of these technological advances, there are still a number of asset managers and service providers running their operations on legacy architectures. If the industry is going to benefit from new technology, it needs to think differently about it at a conceptual level.
So says Adam Belding, chief technology officer at Calastone. Rather than relying on monolithic systems, firms should embrace a new type of system architecture, based on event-driven microservices and application programming interfaces (APIs), which create the basis for a more adaptable and scalable basis on which to build their systems.
The problems with legacy systems are well documented – monolithic structures involving millions of lines of code that the majority of staff do not understand, placed at the heart of the business. But replacing these systems is often more challenging than keeping them in place. “A failed re-platforming can be career-ending for the person responsible,” says Belding. “If these legacy systems are linked into an organisation’s overall systems, reasoning about them and understanding the impact of changes becomes increasingly complex over time.”
This is not to say that there have not been numerous efforts to solve these issues and develop alternative architectures. The late 1990s saw the advent of client/server platforms. Then we saw the emergence of service-oriented architecture (SOA) in the early 2000s, which was created to offer a more modular approach to system design and standardised approach to systems integration
“For many years, firms had tinkered around the edges of their legacy infrastructures with multiple add-ons. This problem then became worse as firms developed multiple apps for their front-end to appeal to clients without making the relevant changes at the back end.”
The starting point
Microservice architecture offers a genuine solution to these issues, and a different way to thinking about how to design complex financial services systems, says Belding. In this type of architecture, applications are arranged as a collection of loosely coupled services rather than a layer in a monolithic system. In essence, microservice architecture is designed to be flexible, adaptable, scalable with services that are autonomously developed, independently deployed and decentralised. By driving these systems through the creation and consumption of events, a much more scalable and less coupled system architecture is possible.
“Microservices ensure that different elements of a system operate much more separately from each other, minimising their interdependency to only what is required,” says Belding. “Consequently, different components of the software can be changed without affecting how the overall system operates, delivering a much more flexible technology infrastructure that can adapt to the organisation’s evolving needs without disruptive and expensive overhauls.”
For funds, this would create scalability and a much easier path to adopt new products and services, so changes can be made to the funds model more easily. For a transfer agent, for example, the core functionality comprises a unit register, order processing, fees and commission management, and corporate actions. There are also touchpoints that determine how data is presented to clients – a web portal for investors, a dashboard for fund managers and a data warehouse for the various analytics.
With the right architecture, if there are new rules on tax wrappers in a specific jurisdiction for example, it is possible to add a new application without having to amend all of the underlying systems. “It is about ensuring that from top to bottom, all of the applications are independent and not reliant on other applications or systems,” says Belding.
In a true microservices environment, there is a low level of ‘coupling’, the logic is separate and there is a clean interface between all of the applications. When the register publishes an event, or the order processing system raises an order, the relevant services understand that change and act accordingly.
Some firms are attempting a version of this approach where they connect their legacy systems to some microservices in an attempt to use the legacy system in a more modern way by breaking it into smaller parts, says Belding. But while this approach works in theory, it is much more complex in practice, with a labyrinth of connections and issues over data consistency.
There are a number of drivers that will push the case for a new approach to systems architecture, says Belding. Ongoing regulatory change is one. For example, the Retail Distribution Review (RDR) in the UK touched on all the processes that a TA’s monolithic legacy system would contain. With a new approach, it will be possible to make changes in one area that won’t affect other services.
Cost is another benefit. “Microservices are more portable and easier to run,” says Belding. “They can be cloud-based and paid for on-demand. Traffic can change over the course of the day or the week, so firms can scale up or down. And processes can be done in real-time rather than in end-of-day or end of month batches.”
Microservices also create a more secure architecture than one where new workarounds are constantly added to keep the system afloat, but create new exposures at the same time. And it is easier to innovate and allow staff to design and develop their own applications and services in a safe environment without putting core systems at risk.
But how can firms be assured that microservices architectures will not end up with the same fate as other aforementioned software strategies? Belding says that the technology should be fit for purpose for decades to come.
“Having developed banking, trading, and asset management applications for many years, the difference when applying this architectural approach is fairly stark. At Calastone we have used microservices in building our new platform for fund administration. It has been refreshing to see how much simpler the application of this approach is to the fund administration domain.”
(First published Funds Europe November 2021: https://www.funds-europe.com/november-2021/are-you-being-microserved)
