The age old topic of buy versus build was raised at the Sydney FIX Conference on 23rd October 2014. I’ll set out my position clearly below, since it’s a complex issue…Let’s first clarify what we mean by the terms “buy” and “build”Buy
Note that I make no assertion around who installs, implements and configures the software. I also don’t make any statements about who owns the hardware or where the hardware is located. The key point here is that the IP is delivered by a vendor. Note further that there is no assertion of ownership of the IP. It may be that the vendor is providing open source software or a combination of open source and proprietary software.
Typically this will involve a clear price – so the firm will know in advance that the delivery of code should cost a specific amount. Provided a decent contract is in place the firm should be able to offload delivery risk to the vendor. This means that if the vendor is late in delivery or not feature complete then the firm should pay a reduced amount. This true delivery risk offload model is very rare, most vendors attempt to engage in a partnership/co-development model where the firm pays whether delivery is up-to-standard or not.
In many cases I have seen a “heads I win, tails you lose” approach taken where a firm agrees to a contract that ensures regular payments to a vendor with no gatekeeper to ensure payment on results, no clawback in the event of a failure and a general expectation that the vendor is working on a best efforts basis. The range of what gets signed off in many financial service firms is one that rarely ceases to amaze…
The challenge here is that project oversight is often very difficult, since there are a whole host of folks who are dependent on the project reaching completion and often no-one as a fair arbiter of whether or not the project is on track. While a Project Manager should be keeping track of a project, one must recall that turkey rarely vote for Christmas and so PMs are often not incentivised to actually manage the delivery of a project in a meaningful way. One classic example is the third party project manager hired on a daily rate basis. What incentive does he have? Clearly, if he is looking to maximise income he would benefit from dragging the project on and on, since every day is another dollar.
In this taxonomy we see that the main difference is the process of development of the code and who bears the risk of late or incomplete delivery.
So, what’s the real difference between the two?
Many firms have a “buy” policy as a way of attempting to reduce risk. The perception is that building software is risky, since it’s a leap into the unknown. The buy option removes that risk. The challenge to that analysis is pretty simple. When people talk about buying software they often forget that the actual work of getting the software to work is a massive part of the total time to live. That is to say that the time taken to write code is a fraction of the total elapsed time from start of a project to go-live.
Let’s look at an example. Implementing an equity trading system for a single market. Let’s work on the basis that the firm has an exchange membership already and has a functioning back office.
Ask the wrong question (buy versus build?), and you will generally receive the wrong answer…
This usually means that a firm purchases technology of some description from a provider of software. As a concrete example, if an Investment Bank wants to trade cash equities they could buy software from a vendor such as Fidessa, IRESS, Sungard, Orc etc. The vendor will deliver the software to their client and the software is installed on hardware, implemented, configured and used by the client. It could be the case that the code has not yet been written and is only developed after the firm has contracted with the vendor.
Note that I make no assertion around who installs, implements and configures the software. I also don’t make any statements about who owns the hardware or where the hardware is located. The key point here is that the IP is delivered by a vendor. Note further that there is no assertion of ownership of the IP. It may be that the vendor is providing open source software or a combination of open source and proprietary software.
Typically this will involve a clear price – so the firm will know in advance that the delivery of code should cost a specific amount. Provided a decent contract is in place the firm should be able to offload delivery risk to the vendor. This means that if the vendor is late in delivery or not feature complete then the firm should pay a reduced amount. This true delivery risk offload model is very rare, most vendors attempt to engage in a partnership/co-development model where the firm pays whether delivery is up-to-standard or not.
In many cases I have seen a “heads I win, tails you lose” approach taken where a firm agrees to a contract that ensures regular payments to a vendor with no gatekeeper to ensure payment on results, no clawback in the event of a failure and a general expectation that the vendor is working on a best efforts basis. The range of what gets signed off in many financial service firms is one that rarely ceases to amaze…
Build
This usually means that a firm develops software. The software may be proprietary or open source or a combination of both. The code may be written by permanent employees, contractors, consultants or external software development companies. In this case, once the firm decides to build the code the process of development can commence. This will not generally involve a clear price, since the firm that is writing the software will simply bear the cost. Of course, the firm may cancel the development some of the way through the process.
The challenge here is that project oversight is often very difficult, since there are a whole host of folks who are dependent on the project reaching completion and often no-one as a fair arbiter of whether or not the project is on track. While a Project Manager should be keeping track of a project, one must recall that turkey rarely vote for Christmas and so PMs are often not incentivised to actually manage the delivery of a project in a meaningful way. One classic example is the third party project manager hired on a daily rate basis. What incentive does he have? Clearly, if he is looking to maximise income he would benefit from dragging the project on and on, since every day is another dollar.
In this taxonomy we see that the main difference is the process of development of the code and who bears the risk of late or incomplete delivery.
So, what’s the real difference between the two?
Many firms have a “buy” policy as a way of attempting to reduce risk. The perception is that building software is risky, since it’s a leap into the unknown. The buy option removes that risk. The challenge to that analysis is pretty simple. When people talk about buying software they often forget that the actual work of getting the software to work is a massive part of the total time to live. That is to say that the time taken to write code is a fraction of the total elapsed time from start of a project to go-live.
Let’s look at an example. Implementing an equity trading system for a single market. Let’s work on the basis that the firm has an exchange membership already and has a functioning back office.
Task
|
Both
|
Build only
|
Buy only
|
Project scoping and analysis
|
Yes
| ||
Hiring developers, testers, business analysts
|
Yes
| ||
Establishing where to run software, procure datacentre space if needed or sign an outsource agreement with a third party datacentre provider
|
Yes
| ||
Purchase communications lines or use existing cross connects
|
Yes
| ||
Senior management oversight
|
Yes
| ||
Integrating system to back office
|
Yes
| ||
End-to-end testing
|
Yes
| ||
Document workflows that are required
|
Yes
| ||
Test documented workflows against delivered application
|
Yes
| ||
Project management of project
|
Yes
| ||
Risk management of project
|
Yes
| ||
Proving training to users
|
Yes
| ||
Providing support to users
|
Yes
| ||
Application management (DevOps)
|
Yes
| ||
Vendor Search, research, reference site calls, due diligence
|
Yes
| ||
RFI, RFP, ITT process
|
Yes
| ||
Procurement, corporate vendor management
|
Yes
| ||
Contract negotiations with software provider
|
Yes
| ||
Design application
|
Yes
| ||
Writing application code
|
Yes
|
Clearly the above is a simplification, but the point I make is that if we add up the time and money for the tasks required for ‘only buy’ or ‘only build’ we will see that they are a fraction of the total time and money cost.
A more nuanced debate is around the impact on the firm in terms of permanent headcount and cost of operation. This is something that has to be viewed on a case-by-case basis so no generalisation is possible.
The piece I consider more important is the ongoing review of buy vs build. If a firm is seeking bleeding edge technology then often the way to proceed is to build since it’s perceived that the first mover advantage can be better sustained if the intellectual property created is owned by the firm rather than a vendor. The problem in this case is if that technology becomes an albatross around the neck of the firm. An example of this is a firm I worked with a number of years ago. They had built a bleeding edge modular client/server electronic trading application. It was written in C++ using a set of third party libraries for client user-interface elements. The vendor of the third party libraries went bust and the code was made accessible via source code escrow. The firm then had to take over maintenance of the library code. The original development team left the firm. The firm required this application to be supported and so hired a new development team. The new development team then realised that the application was hard to maintain and support and so gained approval for a re-write into a new Java front end application while retaining the C++ back end. That was done and then the firm realised performance was not sufficient. Hence a further re-write to a new C# front end. After all of this the firm then started to replace functional modules with new build and new buy. This cost a huge amount of time and effort. And each re-write essentially replicated the same application functionality rather than extending and enhancing. A case of running at full speed ahead in order to stay in the same place.
The problem is simply that unless there is a level of technology portfolio management in place we often see “technology management” simply managing the existing technology stack rather than looking at a more strategic level. Looking at "how do we keep this system running" rather than "should we be running this software, should we go to market to replace it with a vendor offering?".
Hence my view – the question of buy versus build leads to answers to a static question, not the dynamic management of a technology portfolio within a firm. As such, I believe that any firm in the financial services industry that ever aspires to a leadership position needs to retain technologists with an eye for making strategic decisions, rather than simply keeping the lights on.
Ask the wrong question (buy versus build?), and you will generally receive the wrong answer…
Comments
Post a Comment