Nearly 60 years ago, Melvin Conway observed that an organisation’s technology will inevitably mirror its internal structure. It’s a law that has aged uncomfortably well in capital markets, where billions spent on trading, risk and analytics systems have produced vertical stacks that reflect business-line org charts rather than the horizontal data flows firms now need to compete.
That tension was the central theme of a panel discussion at A-Team Group’s TradingTech Summit London 2026, where five senior practitioners debated whether the industry can break free of its self-imposed architectural constraints. The panel – Aviad Axelrod, Head of Fixed Income and Equities Product EMEA, BNY Pershing; Rahim Chitalya, Trading Technology Delivery lead, Phoenix Group; Fabian Basciani, Senior Executive Director, Trading Technology, JP Morgan Asset Management; Will Brown, Senior Sales Engineer, Genesis Global; and Jon Butler, CEO, Velox – was moderated by Steve Grob, Founder of Vision57.Their discussion ranged across composable architecture, data strategy, AI readiness and the organisational inertia that continues to hold the industry back.
The monolith isn’t the villain, but it is the problem
The panel’s opening exchange set a deliberately contrarian tone. One speaker argued that monolithic platforms have survived for two decades for good reason: they work, they’re tightly coupled where business demands tight coupling, and they’re hard to replicate. The instinct to tear them down can be simplistic. Some firms have moved to API-driven architectures only to reverse course when the short-term costs outweighed the distant benefits.But survival isn’t the same as fitness. Monoliths were designed for a world in which business lines operated independently. Now firms must operate across asset classes, geographies and functions simultaneously, and the architecture wasn’t built for that. Layer on T+1 settlement, the push toward 24/5 trading, DORA, and compressed margins, and the case for change becomes existential.
The emerging response is the “buy and build” trend: assembling platforms from a combination of in-house intellectual property, third-party components and API-driven connectors, rather than purchasing another monolithic replacement or attempting a prohibitively risky full rebuild.
One panellist went further, arguing that the industry’s vocabulary is part of the problem. Terms like “OMS” and “EMS” reinforce silo thinking and turf wars. Firms should instead describe problems and capabilities – a pricing engine, an order router, a connectivity layer – which naturally leads to reusable, cross-asset components. It’s a cultural and linguistic shift as much as a technical one, and it goes to the heart of Conway’s Law: change the way people talk and organise, and the technology will follow.
Data is the real bottleneck
An audience poll during the session confirmed what the panellists already knew: data quality and organisational resistance are seen as bigger barriers to composability than technical integration. The panel agreed unanimously.
One speaker described building a trading capability from a greenfield position, with a mandate that every platform and data feed must route through a centralised data layer. The principle is sound, but just two years in, data models are already diverging as use cases shift, new assets get onboarded before pipelines are ready, and business urgency overrides architectural purity. The firm’s leadership team recently identified data architecture as their single biggest strategic challenge, despite being at an early stage.
Another panellist described a different approach: standardising not the data store but the interaction patterns, such as consistent messaging infrastructure, standardised error handling, uniform API contracts. If everything looks the same at the interface level, the argument runs, it matters less what sits behind each service. And crucially, it makes the codebase far more navigable for AI tools.
The common thread: data is not a problem you solve once. It’s a continuous discipline, and firms that treat it as a project rather than a practice will find themselves back where they started.
Buy and build in practice
The panel offered concrete examples of composable architecture delivering results. A sell-side practitioner described embedding proprietary algorithmic logic into a third-party EMS – outsourcing market data ingestion, order flow, exchange connectivity and order management to the vendor – while retaining the firm’s differentiating IP in-house. The integration worked well in the US and remains in production, though it proved less successful in Europe, a reminder that composability depends on regulatory and market context, not just clean APIs.
From the vendor perspective, a panellist described building white-labelled client trading portals for banks, connected to existing infrastructure via standard protocols and delivered from contract to production in roughly four months. The key: not asking clients to change their core systems, but building around them.
The concept of an orchestration layer surfaced repeatedly, i.e. a middle tier that translates between FIX, REST and Kafka-based systems, handles data normalisation and presents a unified interface to users. This relieves individual teams of solving the entire integration picture and lets them focus on what differentiates them.
AI amplifies discipline – or its absence
The conversation turned naturally to artificial intelligence, but the panel framed it less as a revolution and more as a magnifying glass. One speaker was emphatic: if your codebase is well-structured, consistently patterned and thoroughly documented, AI coding agents can absorb the patterns and produce reliable output at speed. Their team maintains dedicated markdown files that instruct AI agents on design patterns and interaction models before they touch any code. Combined with standardised frameworks and large-context models, the results have been impressive.
The corollary was equally blunt: if your codebase is spaghetti, AI will produce more spaghetti, faster. The risk of short-term productivity gains creating long-term maintenance nightmares is real. One panellist cautioned the industry against creating “a huge mess we don’t know how to maintain.”
A related concern touched the talent pipeline. If firms eliminate junior developer roles in the rush to automate, they hollow out the path to seniority. Several panellists noted the pendulum is already swinging back.
The road ahead
Asked whether we’ll still be debating composable architecture in five years, the panel’s answer was a frank yes. Not because the technology is lacking, but because the industry struggles with seismic change. The absence of shared data models and common standards will, one speaker predicted, block much of the value that AI could otherwise unlock.
But the direction of travel is clear. End users are becoming more technically sophisticated and will demand the flexibility that composable platforms promise. Vendors are increasingly accepting that open APIs, not lock-in, are the price of relevance. And firms that invested in engineering discipline – consistent patterns, rigorous documentation, cross-asset thinking – are finding themselves better positioned not just for composability but for the AI-driven acceleration now arriving on top of it.
Conway’s Law still holds. Breaking it means changing the organisation, not just the architecture. That remains, as this panel made clear, the industry’s hardest problem. But also the one most worth solving.
Subscribe to our newsletter
