It is generally wise to follow the principle of parsimony in development: do the least amount of new coding that you can without sacrificing competitive capability. In recent years the scope for parsimony has extended well beyond code reuse to the adoption of platforms, software and even business processes that are provided by Cloud specialists. Their commercial proposition is to provide infrastructure as a service at a lower cost than an institution can run it when bearing the full cost themselves.

This can be illustrated with the familiar example of Customer Relationship Management (CRM) software. Historically, large banks have a surfeit of this, having typically developed numerous departmental systems. It would be possible for each bank to rationalise and try to pick its best but when the spotlight is trained on the software assets available in house the case for investing in any of them can look weak, especially in areas such as CRM where there is a deep range of mature third-party alternatives.

For a firm looking to outsource CRM, there is a spectrum of Cloud-based options that, starting with the maximum degree of outsourcing, looks something like this:

1. Outsource the business process. Some firms will choose to develop products that are exclusively distributed through a partner network. They need no CRM software. The partner is (or may be) offering Business Process as a Service (BPaaS).
2. Outsource the software. Some firms manage their own customers and use a CRM system but choose to take it as a service from a software company such as Salesforce. They use CRM software but don’t develop or operate it. Here Salesforce is offering Software as a Service (SaaS).
3. Customise Cloud applications. Some firms will use Cloud-delivered componentry customised with firm-specific features. For example, they may use Airtable configured to offer CRM functionality. As with the Salesforce example above, in this case Airtable would manage all of the firm’s Cloud hosting choices.
4. Write Cloud applications. For much more deployment flexibility and control, some firms will write their own CRM system on top of a Cloud-hosted database such as Amazon’s RDS running Postgres on AWS. Although they can leave the hosting of physical infrastructure to Amazon, the firm then can (and must) choose how to configure their own server instances and WAN topology. This is Platform as a Service (PaaS).
5. Write everything without leveraging Cloud components. These days no one writes a CRM from the ground up as the economics of it make no sense!

This is well understood – but what is actually happening?

For start-ups, strategies 1 and 2 are realistic and sensible. In contrast, for most large Financial Services firms in most application areas, their current preoccupation is migrating a vast amount of proprietary on-prem software to strategy 4 (PaaS) or possibly strategy 3 (some form of SaaS). Until the Legal sheep risk flocking to the greener field, at the time of writing this is still often onto a hybrid Cloud (if we allow that “hybrid Cloud” is not simply an expensive oxymoron).

There is a universe of tooling to help with such migrations. What is appropriate will depend upon the characteristics of the relevant functional domain. For this purpose, it is perhaps helpful to partition application areas into three categories:

A) Apps that interact politely

For these, latency sensitivity is not critical (milliseconds to seconds is acceptable) and overlapping state dependencies can be avoided. The large majority of banking applications fall into this category including virtually all back-office applications and web-delivered front office applications. Functionality is implemented as (micro) services and inter-app communication can often be implemented using REST API’s over HTTP. These applications can be containerised and deployed using technology such as Docker, Kubernetes and/or OpenShift.

B) Apps that interact brusquely

For these, latency sensitivity is critical (sub millisecond), state dependency is enmeshed between components and recovery from any failure typically requires complex orchestration. Front office e-trading services for high-volume products delivered over an API (rather than a GUI) fall into this category. Vanilla HTTP-based and container-based technologies cannot service these demands. Technologies such as 29West, Hazelcast’s IMDG and Adaptive’s Hydra are designed to manage the performance and resilience demands of these domains.

C) Apps that interact greedily

Here monetary value arises from waging and winning a speed war with competitors. In Financial Services, this applies exclusively to the domain of market access and execution. It is not relevant to all market participants and even for those for whom it is relevant it describes only a small fraction of the software estate. The required edge typically demands customisation at low levels of software design and/or in hardware. Relevant technologies include microwave networks, SolarFlare cards deploying kernel bypass, DPDK and FPGA.

We can illustrate where a range of banking functions sit within this categorisation:

Pyramid of convenienceThe tip of the figure represents the functional domain whose defining essence is competitive performance. Although High Frequency Trading (HFT) is an imprecisely defined term, we take it here to mean operation in markets that only exist when an edge in speed can be created. Paradoxically perhaps, this was arguably the first area of Financial Services for which “Cloud” had real force, but only in the specific sense of running on other people’s hardware in co-location facilities. As a general characteristic, this bleeding tip of the software estate brooks no compromise with other systems and will not be impeded by layers of software indirection or fabric architectures optimised for simplicity of wide scale deployment.

While the brusquely interacting middle slice of the software estate contains a much smaller number of applications, it is economically important, notably covering non-GUI electronic trading and access to fast electronic markets.

The majority of applications, probably more than 90% by simple count, live in – or could be re-engineered to live in – the politely interacting segment, shown here at the base of the figure.

If we accept this three-way categorisation, what does it imply?

First, that having a high standardised strategy for the migration of container-based applications to the (real) Cloud generates the biggest “vision win” in Cloud migration.

Second, that such a programme will not carry over to the middle slice of brusquely interacting applications that implement non-GUI electronic trading. For banks that see themselves as more than regional margin-collecting intermediaries between the retail and wholesale markets, this is and will remain a critical area of business. It needs a technology strategy beyond containerisation for the delivery of stateful, inter-dependent low latency applications on a Cloud platform.

Finally, for a number of trading firms, success in HFT operations, as defined here, is definitional. Most banks will have to decide its relevance to them at a time when regulators would like to see much less of it.