In Financial Services, The Cloud is the technology solution of choice amongst non-technologists. You can see why. Here at eCo our efforts are given over to avoiding duplicative development and running costs in IT – going a step further and handing over swathes of technology to someone else to run in toto might almost sound easier. It’s certainly a bigger and bolder play.

In fact, mutualising source code over eCo can be seen as only the first of a range of steps that might be taken to outsource service delivery, each of which is incrementally more ambitious and offers more scope for further cost reduction. Here are the next three steps in the path…


Once a community of buyers has agreed on the precise functionality of some software that it wants from a seller, the Service Partner (or another specialist) might very naturally offer the buyers the option of an asset that can be conveniently implemented in each buyer’s data centre. Such an implementation of software in turn-key form is known as an appliance. The term “appliance” suggests an actual dedicated hardware device and traditionally many appliances are exactly this. For example, a router is an appliance.

At the sharper end of financial technology, there are appliances that implement links to exchanges and sometimes even the formation of an order book across several exchanges. This can be implemented on a server that will typically be racked up in a co-location facility (“co-location” being with an exchange’s own servers for minimal data transit times) or it can be implemented on an FPGA card with programmable circuitry.

Alternatively, an appliance can be as simple as a disk image that can be mounted on a client server, ensuring that an entire software bundle is correctly built and internally consistent. This is still referred to as an appliance, even though, since a disk image doesn’t look like a toaster, the term in this context is metaphorical.

Appliances have the advantage that they simplify deployment and thus reduce the likelihood of an important category of error. They can also increase reliability and reduce latency in performance-critical software (although this is not automatic).

A disadvantage of appliancing is that the client loses transparency. In the case of an FPGA card, for example, the appliancer has to re-programme the software using a specialist language such as VHDL. Even if the client has access to the original code, written, say, in C++, there is no guarantee that what happens on the card is what they expect.

A more devastating problem for appliancing is that it’s not currently fashionable.


Whereas appliancing gives the client an asset to deploy in their own data centre, hosting relieves the client of the need to run the software at all.  Instead, the hoster (who could be the eCo Service Partner) runs the Software as a Service (SaaS), interfacing with the client at the periphery of the software to take data inputs and return processed outputs. These days, SaaS is often referred to as Cloud computing since this sounds cooler and more happening, in a Google/Appley way, than SaaS and has none of the sinister disease connotations of “hosting”.

As Gavin, our CTO, says, the phrase “to/in the Cloud” can always be replaced, with increased clarity, by the phrase “to/on someone else’s hardware”. So “We’re moving our payments software to the Cloud” becomes, “We’re moving our payments software to someone else’s hardware”.

In this more direct formulation both the benefits and the complexity of Cloud migrations is apparent. The significant win arises because having another party run software on behalf of many clients is clearly de-duplicative in a new dimension over and above eCo’s reduction of software development and maintenance costs. The potential difficulties, especially for a bank, lie in the new considerations that have to be given when data and its manipulation move outside the client’s firewall. How can data security be guaranteed? What liability is required of the hosting party? What happens when a change is needed that the hoster doesn’t want to make, or won’t do quickly enough?

Business Process Optimisation

Reduction in Force

Reduction in Force

BPO is a euphemism – like Reduction in Force (RIF) for large-scale layoffs – that means contracting someone else to run functions that are currently run by in-house staff. Again, the BPO provider can either be the eCo Service Partner or another specialist.

This is a more profound form of cost mutualisation even than hosting. Like the prior steps along our progression of service delivery outsourcing, it opens up a wholly new category of cost savings and comes with new challenges.

The cost savings arise from the elimination of staff performing those line functions that migrate to the firm providing the BPO service.

In addition to all of the challenges arising from hosting, BPO also raises specific issues of its own. For example, if outsourced line functions are not executed well there is potential for reputational damage, as anyone who has come to hate a company through encounters with its call centre staff can attest. Also the line staff affected may have multiples roles and areas of expertise whose entanglement may make extracting them difficult.

Between earth and heaven

If appliancing, hosting and BPO were routinely successful mechanisms with a track record of saving a significant fraction of financial services IT bills we would never have created eCo. We tried them all.  In the light of the experience that we had and that’s common across the industry – an industry that has seen IT spending stuck at a cripplingly high level for a decade – with eCo we are attempting two things.

First, we’re putting in place a workable methodology for the mutualisation of software costs that can be applied to any domain in which firms are spending money in parallel.  Appliancing, hosting and BPO each has tremendous potential, and the further you progress down this path of delivery outsourcing the more you can save. But the path quickly narrows: at each step the realistic applicability, or the number of instances that a firm can process in a year, dramatically drops, probably by an order of magnitude. By focusing on the base level of software mutualisation, eCo maximises the target area over which savings can be sought.

service delivery path

This leads onto our second goal. By establishing a realistic process for software mutualisation, we de-risk each of the more complex potential later steps. Appliancing, hosting and BPO all implicitly require an agreement about what software is being applianced or hosted and what exact business process is being optimised. It’s no part of our plan to extend into these grander services but our infrastructure for alignment of software can make each of them more likely to succeed with more predictability and greater frequency.