SingleDealerPlatforms.Org

Single-Dealer Platforms and other enterprise software systems are increasingly being implemented as a set of discrete services, often using a Service-Oriented Architecture (SOA). In fact, designing an SDP as a set of loosely-coupled services is often more important than for other enterprise software due to a combined demands of business agility and integrations touching many other parts of the enterprise. So let’s look at some of the services that are required for a web-delivered SDP, and while doing so, assess where in the overall e-trading infrastructure they might be best placed.

But, before we do that, let’s recap a typical SDP architecture:

A simple view of a typical layered SDP architecture

A typical SDP architecture has an Integration and Distribution layer connecting to one or more systems providing prices, trading, risk, user information and entitlements and other content. The web front-end is delivered into the users’ browsers and connects over the internet to this layer to access all the services it needs, in a real-time fashion.

Core business services

Put simply, these are the essential services needed to offer pricing, trading and other content to the SDP front-end. They are always provided by the underlying trading platform(s) and usually are separated in the following manner:

• Prices
• Execution
• Order Management
• User Authentication
• Research, news and other content

Most SDPs are built on top of many different, already existing, e-trading infrastructure pieces that may be serving existing electronic channels like MDPs or API connections. These may or may not already conform to an SOA approach, but usually have well established interfaces and APIs. Some existing infrastructure, especially products from trading platform vendors, provide all of these services from a single system. Others may be very dotted all over the enterprise. Whichever approach, in terms of an SDP architecture, it usually makes sense to make each service individually addressable and treat them as if they could be provided independently. Doing so facilitates extension and enhancement of these capabilities by replacement of parts of the system without having to re-implement or disentangle the other services at the same time.

Value-add SDP services

In addition to these core business services are a number of services which are either necessary for a performant, scalable SDP or to provide capabilities that are needed to deliver a rich front-end user experience that would otherwise be impossible in a web application. Some of these may already exist within the organisation and so can be leveraged, others probably don’t as they are unique to a web-delivered e-trading offering.

Let’s start with the SDP-specific services. These, in my experience, must be provided in the integration/distribution layer or else the architecture becomes incredibly messy, the scalability and resilience is compromised and in some cases the performance requirements placed on underlying systems by the SDP channel can cripple existing infrastructure.

• Service addressing and data routing, including mappings for user-specific pricing
• Fan-out for shared data
• List and subscription management, with data filtering, sorting and grouping capabilities
• Flow control / conflation / throttling

Other value-add services may not be SDP-specific, so can be provided by either in the integration/distribution layer or the underlying systems, if they already exist.

One big advantage of the integration/distribution layer providing them is that they usually sit above, and make use of, the core business services. If your SDP is connecting to more than one e-trading system (for example to providing trading across more than one asset class) then a good SDP architecture will allow these services to be shared between each different underlying source. By layering the architecture in this way it becomes much quicker and cheaper to add additional core services incrementally without needing significant investment each time to re-implement these value-add services. The SDP platform can also provide access to these services for other e-trading components, if required.

• Client tiering and/or spreading
• User persistence and preferences
• Price and rule-based alerting
• Intraday caching for charts or time-and-sales displays

Filed under: Web trading technology |