Composable ETRM: The Next Generation Trading Platform

Executive summary

The monolithic ETRM, a single, all-encompassing system that must be taken or left as a whole, is giving way to a more flexible model: the composable platform. Composable architecture treats the platform as a set of capabilities that can be combined, extended, and adapted, rather than a fixed monolith, and it is emerging as the next generation of trading platform design.

Composability matters because it addresses the rigidity that makes monolithic platforms so hard and expensive to change. A composable platform lets a firm adopt the capabilities it needs, extend and integrate freely, and evolve incrementally, rather than being locked into a monolith’s all-or-nothing constraints. This flexibility, built on API-first and event-driven foundations, is what makes a platform adaptable to a firm’s changing needs.

This article covers what composable architecture is, why traditional platforms are evolving, the principles of composable ETRM, business capability modules, the API-first and event-driven foundations, AI and analytics in a composable platform, and a reference architecture. It builds on API-first architecture and the AI-native future.

What is composable architecture?

Composable architecture is an approach in which a platform is built as a set of well-defined, independent capabilities that can be combined, extended, and replaced, rather than as a single monolithic system. Each capability is a modular building block with a clean interface, and the platform is composed from these blocks rather than delivered as an indivisible whole.

The defining property is modularity with clean interfaces. Because capabilities are independent and interact through well-defined interfaces, they can be adopted selectively, extended individually, integrated with other systems, and evolved without disturbing the whole. This is the opposite of a monolith, where everything is entangled and any change ripples unpredictably. Composability is what gives a platform the flexibility to adapt to a firm’s specific and changing needs, and it rests directly on the API-first foundations that expose capabilities through clean, governed interfaces.

Why traditional ETRM platforms are evolving

Traditional ETRM platforms are typically monolithic, and that monolithic nature is precisely what makes them rigid, hard to change, and expensive to adapt. A monolith must be adopted as a whole, changed as a whole, and lived with as a whole, which is increasingly out of step with what firms need.

The pressures driving the evolution are the same ones behind modernisation generally: firms need to adopt capabilities selectively, integrate freely, extend to new needs, and evolve incrementally, none of which a monolith allows gracefully. A composable platform addresses exactly these needs, letting a firm take what it needs, integrate and extend freely, and change incrementally. This is why the industry is moving toward composability: it resolves the rigidity that makes monolithic platforms a constraint, and it aligns with the API-first, cloud-native direction of modern platform design generally. The monolith is giving way to the composable platform because flexibility has become essential.

Principles of composable ETRM

A composable ETRM rests on a set of architectural principles that together deliver flexibility.

The unifying idea is modularity on a governed foundation. The capabilities are independent and interact through clean interfaces, giving flexibility, but they share one governed canonical data model underneath, giving consistency. This combination is crucial: composability without a shared foundation would fragment the data (the very problem a good platform avoids), while a shared foundation without composability would be another monolith. A well-designed composable ETRM delivers both, flexible capabilities on a consistent, governed foundation, which is what distinguishes it from both the rigid monolith and a fragmented patchwork.

Business capability modules

In a composable ETRM, the platform’s functionality is organised as business capability modules, each a coherent, independent capability that a firm can adopt and combine as needed.

Because these are modular capabilities on a shared governed foundation, a firm can adopt the modules it needs, combine them, and extend them, while they all operate consistently on the same canonical model. A firm focused on financial trading might adopt trade capture, position and risk, and settlement; one adding physical trading can add operations, all on the same foundation. This modularity is what lets a composable platform fit a firm’s specific needs and grow with them, rather than forcing the all-or-nothing adoption of a monolith, while the shared foundation ensures the modules work together consistently.

API-first and event-driven foundations

Composability is made possible by two foundations covered earlier in this cluster: API-first architecture and event-driven design. Together they are what let capabilities be independent yet work together.

API-first means each capability exposes and is accessed through clean, governed interfaces, so capabilities can be combined and integrated cleanly. Event-driven means capabilities react to events, so they are loosely coupled, a change in one propagates through events rather than tight dependencies. Together, these foundations are what make capabilities genuinely composable: they can interact through clean APIs and events without being entangled. This is why composability is not a separate feature but the natural consequence of API-first, event-driven architecture: build a platform that way, and it becomes composable almost by construction, which is exactly how a next-generation platform achieves its flexibility.

AI and analytics in a composable platform

AI and analytics fit naturally into a composable platform as capabilities that operate on the shared governed foundation. Because the composable platform is built on one canonical model exposed through clean APIs, AI and analytics can be composed in as capabilities that reason over that governed data.

This is where composability and the AI-native vision meet. The analytics layer, forecasting, and copilots are all capabilities that operate on the governed model, and composability lets a firm adopt them as it is ready, all grounded in the same foundation. Because they share the governed canonical model, the AI and analytics capabilities are grounded and consistent with the rest of the platform, which is what keeps them reliable. Composability and AI-native design reinforce each other: modular AI capabilities on one governed foundation, adopted as the firm is ready and grounded throughout.

Reference architecture

Bringing the concept together, a composable ETRM is a set of modular capabilities on a shared governed foundation, interacting through clean APIs and events. (This is a representative architecture, not a prescriptive standard.)

Because the capabilities are modular and independently adoptable but share one governed foundation, the platform is both flexible and consistent, adaptable to a firm’s needs without fragmenting its data. This is the architectural achievement of a composable ETRM: the flexibility of modularity with the consistency of a governed foundation, which is what makes it the next generation beyond the rigid monolith.

Adoption roadmap

Adopting a composable platform works best incrementally, which is precisely composability’s advantage. (This is a representative roadmap, not a prescriptive standard.)

Foundation. Establish the governed canonical model and API-first, event-driven foundation that composability rests on.

Core capabilities. Adopt the core modules the firm needs first, trade capture, position and risk, settlement, on the shared foundation.

Extend. Add further capabilities, operations, analytics, AI, as the firm is ready, each grounded in the same foundation.

Integrate and compose. Integrate with enterprise systems and compose capabilities into the firm’s workflows. Because capabilities are modular on a shared foundation, the firm adopts and grows incrementally rather than through all-or-nothing monolith adoption, which is the core benefit of a composable platform.

Why Gravitas is built as a composable platform

Gravitas is composable: modular capabilities on one governed foundation.

Because capabilities are modular on one governed foundation, the platform is both flexible and consistent, adaptable without fragmenting data. And it is delivered at economics that suit desks the incumbents priced out. See the platform, who Gravitas is for, or request a demo.

Best practices

Building and adopting a composable ETRM well rests on a few principles. Organise the platform as modular capabilities with clean interfaces, on a shared governed canonical model, so flexibility does not fragment the data. Build on API-first and event-driven foundations, which make composability natural. Adopt capabilities incrementally, taking what the firm needs and growing. Compose AI and analytics in as capabilities grounded in the foundation. And keep the governed foundation consistent under all the modules.

The through-line is that composability delivers the flexibility a modern firm needs, selective adoption, free integration and extension, incremental evolution, while a shared governed foundation preserves the consistency a monolith provided. A well-designed composable ETRM gives both, which is why it is the next generation beyond the rigid monolith: flexible capabilities on a consistent, governed foundation.

Composable platform KPIs

A composable platform can be measured across flexibility, consistency, and adoption.

Modularity and interface cleanliness measure flexibility; foundation consistency measures whether data stays unified; incremental adoption and extensibility measure whether the firm can grow freely. Together they describe a composable platform that is flexible without fragmenting.