To Buy Or To Build, Is That The Right Question?

I’ve been working on a buy vs. build white paper for Progress Software this week. It’s focused on the decisions that senior financial technology executives face every time they need to deliver new functionality or systems to support their business. I thought I’d share some observations gained while doing the research for this piece. Some will be pretty obvious; others might come as a surprise. I’d love to hear your observations and feedback, so comments are encouraged!

Build or buy is never a simple binary choice

Except for small sell-side firms and buy sides with little or no in-house development talent, the buy/build decision is rarely, if ever a simple binary choice. Even firms with a clear in-house build bias tend to buy certain portions of the infrastructure and software, where it doesn’t make sense to re-invent the wheel. In fact, I focused the white paper on the decision continuum.

Small firms and buysides often buy

Small firms that lack development resources almost always end up buying pre-packaged software, a need that hedge fund service providers, packaged software providers and sell-side shops have effectively leveraged for years.

“Not invented here” shops shoot themselves in the foot

In some cases, I think the “not invented here” technology departments shoot themselves in the foot by building custom technology to deliver functionality that is relatively commoditized. Wouldn’t it be better to focus your hotshot development teams on the functionality that really differentiates the business instead of reinventing wheels?

Ultra low latency HFT players build everything

Of course, there are firms out there who even design their own hardware. Those firms are generally technology houses that do trading, rather than trading houses that rely on technology. Years ago, I talked to a prop firm that was customizing the firmware on all their routing and switching technology. I assume that this is a fairly standard approach today for the ultra-low latency high frequency trading shops.

Secret sauce vs. commoditized infrastructure

As we all know, keeping the “secret sauce” secret is a common motivator for building in-house. But that doesn’t necessarily mean that you can’t leverage pre-packaged components to build an in-house system, allowing the team to focus on that secret sauce instead of building infrastructure.

Many systems in the trading workflow are commoditized

Let’s face it, market data feed handlers, FIX engines, smart order routers, matching engines, message buses, order management systems, and pricing aggregators are no longer “secret sauce.” These systems are commoditized, and unless you’re focused on ultra-low latency, it rarely makes sense to build them in-house.

Problems with Offshoring

When firms try to leverage offshore resources to build specialized functionality, they sometimes end up with disappointing results. I’ve long suspected that part of this is a cultural issue. American and European firms tend to expect financial technology developers to think for themselves and apply what we might call “common sense” in this country. But that doesn’t necessarily translate to other cultures. It’s my understanding that universities in some countries train developers to code exactly to the specs.

An Indian friend of mine told me a story that illustrates this. He was given a project in school to code a system based on a spec in the text book. He followed the instructions, but the code didn’t work. So he fixed it, got the app running, and turned in his assignment. His teacher gave him an “F” because he didn’t conform precisely to the specification in the textbook. I realize this is a gross generalization. Also, the incident he described happened about a decade ago, and things have changed radically in recent years. But nevertheless, cultural issues do affect the success of projects, and the more specialized the functionality, the more critical the impact.

Risk of single purpose applications

There is a huge problem in the industry with applications that are built for a single purpose. While these purpose-built applications are faster and cheaper to deploy up front, they are often rigid and hard to evolve as the market changes. Most banks are dealing with a hodge podge of siloed applications that are not documented, hard to support, and that drive up ongoing maintenance costs.

Ongoing software support costs

Business cases justifying in-house builds rarely do a thorough analysis of ongoing software lifecycle costs. But Mark Lutchen, former global CIO of PricewaterhouseCoopers, now head of the firm’s IT Effectiveness practice says, “70 percent of software costs occur after implementation. A rigorous lifecycle analysis that realistically estimates ongoing maintenance by in-house developers often tips the balance in favor of buying.” Here’s an interesting InfoWorld article on the topic.

Little content helping with build or buy decisions

There is remarkably little content out there targeted at helping the senior technology executives in the financial industry make buy/build decisions related to trading, surveillance, compliance and risk management software for the financial services industry (at least that I could find via Google). I found this surprising, given the fact that every financial institution faces these kinds of decisions on a recurring basis. Providing content like this, written from a neutral point of view, can be very helpful and can position your firm as a trusted advisor.

Much of the content I did find was actually just thinly veiled sales pitches. Financial technology white papers are marketing tools and need to deliver an ROI. But your readers will immediately see through advertorials and won’t trust the content. So be careful.