A central feature of the eCo model is the clean separation between the licensing of intellectual property (IP) and the provision of service. Here, of course, the IP is software in the form of source code. There is much to say about who is selling this software and I’ll cover that another time. This week’s column is about service provision: why we separate it, who will be doing it and what it entails.
One reason for the “Why?” is immediately obvious. The prognosis for support would be bleak indeed if buyers had to rely on the seller where the seller is a large bank and the buyer is another large bank – and especially when there are many buyers. Apart from the trust and confidentiality issues that would arise, there is an equally significant matter of organisation. Supporting software used by people who paid for it requires dedicated resources: a help desk, client support technicians, client-aware QA staff and seasoned managers. Moreover, clients need to know that these resources will not be commandeered to other tasks. Also, the company providing support needs robust systems for all of its client-, code-, version- and issue-management functions.
For a seller bank to take on all of this would be onerous and draw most banks well outside of their remit. In contrast, for software companies this is just what they do and mature firms necessarily have the required infrastructure. Thus when licensing software from a bank over eCo it makes perfect sense for the buyer to contract support services off another party that is organised to provide them rather than to thrust obligations on the seller that they probably can’t dispatch.
There is also a less obvious point. Often when banks license commercial software and things go wrong it’s actually due to the conflation of the software and the services around it. We all know of cases in which a client has a bad experience with a supplier arising not primarily from problems with the licensed software but from a professional services contract that isn’t going well – and that the buyer (or the supplier) can’t get out of.
eCo is all about creating an efficient market and this extends to the supply of services as well as to the software itself. Traditionally, breaking the tie between the IP sale and the maintenance/support contract is problematic since only the seller has visibility into the code. However, since eCo creates a market in source code rather than in opaque binaries compiled from it, it’s feasible to uncouple sales and support – so long as the software is good enough, which is what eCo’s Technical Assessment measures. This in turn means that if a professional services engagement isn’t working out a new agreement can be negotiated with a new partner.
With freedom to choose a Service Partner other than the seller, it’s crucial to choose the right one; eCo plays an important role here. Remediating a choice that doesn’t work out will be far more painful than making a smart choice upfront. If it does become necessary to consider swapping Service Partners in flight, for the benefit of any party, eCo will ensure that the analysis is based on facts rather than sentiment and will run a fair and orderly process.
We’ve been in dialogue with several prospective Service Partners over the past months to maximise the chances of this model working smoothly. As much as the sellers, these firms are an integral part of the eCo community. It’s in the interest of everyone for this role to be successful so that operationally eCo is effective, harmonious, competitive and profitable for all participants.
The three firms that we’ve spoken with most to date bring different perspectives to the Service Partner function. They are:
IBM. IBM already engage deeply with very many potential eCo participants regarding cost mutualisation opportunities. Their experience should be especially useful for firms looking to assess how commercialisation and/or sourcing over eCo can fit into an overarching technology strategy.
SunGard. We know SunGard well and were steered to them at eCo by a participant that named a SunGard division as their preferred commercial software supplier. As we all begin to embrace a new paradigm of technology provision, the experience of one of the world’s foremost suppliers of productised financial services software is invaluable.
Cognizant. Cognizant is another substantial company (they actually have 10X the headcount of SunGard) with a very significant presence in many Investment Banks, where they have live code maintenance responsibilities. Indeed, Cognizant staff are materially responsible for some of the assets already listed on eCo in the name of the owning institution. It’s hard to think of more relevant credentials for managing similar (or the same) code assets going forward.
We enjoy and benefit from continuing dialogue with these firms. However, in conjunction with other participants, notably the relevant sellers, we’ll always aim to find the most appropriate Service Partner for each asset transacted on eCo. The range of other excellent potential partners we are in discussion with include:
- Domain experts in particular functional areas
- Firms who have strength in a particular geographical territory
- Appliancing specialists
- Strategic consultants.
The way that each such kind of speciality can enrich the eCo community and open up new and potentially highly fruitful options is worth a column in itself.
Whatever their background, and whatever else they can offer, each Service Partner needs to have the required core strengths that enable them to service clients around a common code line. This means being able to take code and upgrades from the seller and code check-backs from the buyer community and to manage these along with their own fixes and enhancements – then periodically package out new versions for adoption by all parties. The richest win for the whole community comes when as many participants as possible periodically re-combine onto the same code line for as long as possible.
This all illustrates some essential truths about the evolution of the financial technology landscape that are central to the eCo vision. First, federating a range of tasks (in this case support of common software) to parties with special expertise can improve quality and reduce cost. Second, moving to such a federated model requires an attitude of partnership rather than confrontation. The rules of engagement must be fair and give everyone the opportunity to prosper according to the value that they contribute: neither screwing the “vendor” nor leveraging a monopoly position to rip off the client has a place. Third, to make this viable there needs to be a high level of transparency, independent scoring of both code and service, and socialisation of the experience of all parties – hence eCo.