Achieving interoperability of systems and platforms would be a simple proposition for the buy side if firms custom built all their own solutions. Then, tech teams would know where their data repositories resided, they would follow the same security protocols, and generally abide by the same standards for reference data such as securities identifiers. Sending data from system to system would be easy.

The tech estates of most asset managers, however, look nothing like this, as they comprise myriad applications, from in-house solutions to third- and fourth-party platforms, each of which is built in its own way, with its own embedded workflows.

On its own journey to interop, asset manager Natixis began developing a canonical data model (CDM), a design pattern that is used to communicate between different systems, about a decade ago. The CDM, which is now shared across its main investment management systems, laid the groundwork for better operations across its order and execution management capabilities.

George Marootian, head of technology at the asset manager, joined the firm in 2014 and led the project’s next phase. Off the back of the CDM, his team developed an API messaging framework to allow different platforms—new and old—across the front office to “speak” to one another.

The CDM enabled this next step “because the data was ready and the systems were at a point where they didn’t need a complete lift or refactoring to integrate a messaging framework into everything,” Marootian says, speaking to WatersTechnology on the sidelines of the TradeTech conference in Paris.

Under his leadership, the team initially studied its third-party order management systems (OMSs) and core execution applications, run by Charles River Development. They had to identify some of the “key software and technology patterns” that needed to be put in place to allow data to flow in and out of the systems, figuring out what technical protocols and workflows in which Charles Rivers’ system operates and what was the best way to construct a messaging framework around the technology.

Depending on the type of OMS, this can be done by pushing data through the service or using the OMSs internal APIs, Marootian says.

In Natixis’ case, the tech team, with the help of Charles Rivers’ professional services business, developed an API framework that wraps around the vendor’s front-office solutions. The custom API software also leverages open-source technology such as PostgreSQL and Camunda.

“This allowed us to decouple, for instance, from the core portfolio tools that Charles River has and allowed us to build our own portfolio management suite of applications,” Marootian says.

While Natixis’ core tech team is around 50 technologists, the wider interop project—including the development of the model and the open API framework—drew in some 50 more engineers from other parts of the business, Marootian says.

“Heritage systems”

For buy-side firms that want to implement this kind of interop project, it’s never going to be possible to pull out legacy systems completely, panelists at TradeTech agreed.

Marootian said on a panel about centralized data frameworks that from a workflow perspective, much of Natixis’ technology does not align with its newer platforms. These “heritage systems” sit outside the main OMS and front-office apps and are treated as “satellite” components that don’t operate with the main standard data model but are still connected to the other systems using the API messaging framework.

“This ability to create the free flow of information in and out has been a really important part of our tech strategy, simply because there are still use cases for those legacy systems. We are keeping them running for a particular reason, because there are maybe some themes that align very well with it, or we have a regulatory requirement somewhere. So, to make it all interoperable is always a high priority and a significant investment,” Marootian said.

Natixis has a federated data model, which means the data is housed in federated data repositories, which interact with or are assigned to support different services or workflows. Marootian says this is because not all datasets marry well: some might be structured data, and others unstructured.

“To try and shoehorn it all into one particular tech stack is never really a favorable approach,” he tells WatersTechnology.

Speaking on the same panel, Cosaic CEO Dan Schleifer said most of his company’s customers are asking it to integrate new and old systems. He added that his client base all have technologies that are older than five or 10 years and that it’s unrealistic for any firm to move off legacy technologies completely.

“That will never happen, and if you’re waiting for that until you can actually improve the lives of the traders on your desks, you’re just going to be waiting forever,” he said.

But the journey to interoperability is worth embarking on, for the efficiencies it brings and the chance to alleviate vendor lock-in. Marootian says no single vendor can provide one solution to meet the front-to-back investment needs of all clients: if an asset manager wants to invest in the customization of the platforms it uses, it should have the freedom to do that. Many buy-side vendors, like Charles River and SimCorp, have pivoted to opening their tech and allowing users to integrate their platforms with other third-party systems.

“The vendor pool is not scalable enough to be able to satisfy the needs of everyone,” he says.

Schleifer agrees. In the past, users preferred to have a tightly integrated user experience and get their products from the same vendor. But asset managers today are demanding more optionality and trying to avoid overreliance on single providers

“Interoperability has become such a hot topic because buy-side firms don’t want to get everything from one vendor, first because of lock-ins; second because no single vendor is going to be great at everything, but they do want a great, integrated workflow experience,” Schleifer tells WatersTechnology on the sidelines of the conference.

No shortcuts

But there’s no quick fix or “silver bullet” solution to developing an interoperable system, Marootian says. These projects take time and effort to implement, and often the work is never fully completed, as firms regularly update and customize their tech to the needs of traders and portfolio managers.

And new customization has become easier than ever with the growing popularity of low code and no code environments, which enable users—such as traders or PMs—with little or no programming expertise to add functionality to tech platforms.

As part of Natixis’ open framework, the team also built a proprietary environment for low-code development to allow engineers that sit within trading, portfolio management, or risk departments to code new capabilities. Marootian says the buy side is also looking at the option of using Amazon Web Services’ new low-code/ no-code platform for building out new applications.

“We’re decoupling that old monolithic approach of needing 50 use cases, and then saying, ‘I’ll see you in six months when the software is ready,’” Marootian says. “We’re trying to completely decouple that model, look at monolithic projects, and look at how to continue to build out the core [stack], around the canonical data, as well as the service catalog.”