The Build vs. Buy Question - Part I - The Problem Universe

Oh, this "Build vs. Buy" question on enterprise software - I am plain exasperated with it! No matter how many times this is conclusively answered, it resurrects itself with painful regularity.

This question came up again on a call yesterday that I was on. The people involved were talking about how best to pitch solutions to indian CIOs, and one of them remarked how almost every pitch to a Indian CIO invariably resulted in the CIO asking them about team size, the amount of time it took to build the solution etc - and this really meant that the CIO was sizing up the efforts he would have to put in to get this done in-house. Yeah, the same - should he buy this solution, or get it built himself? Should a CIO build software?

This has been answered by many many people. But for whatever it is worth, here are my thoughts on it. I think I am qualified to have an opinion, having been a CIO and vendor both - and have loved being both. So, heres my take on it - my two penny worth, so to speak :)

1. The Problem Universe of Technology

Companies who have IT teams, lead by CIOs, of 10 to 100 people, run their IT operations on need-to-run basis. They have IT people so that the IT people can support, lead and manage their IT initiatives. These IT initiatives are closely bound to the operations of the business, and in a way, these operations define the problem universe for these IT professionals. A microcosm in a way, of a particular industry, and in that, of a particular set of people who formulate and run the business processes within that company. Technology here, is defined in the way it can be deployed and modified to suit this particular company. Needless to say, this definition changes as the business needs evolve, people change and often, as the technology trend and usage changes in the world at large.

Technology then is evaluated by the best way it "fits" the needs of the organization, the means to the end. Technology is further tuned to meet the needs of the company, so much so that sometimes, the process becomes the USP of the company and its product/services delivery. In any case, the problem universe seldom exceeds the current company and its processes.

Contrast this with a start-up. Start-ups are small skunk-works teams that build some path-breaking technology, something that has not been done before, and try and find companies who need that technology to solve their business problem. Even for niche software companies, the problem universe is normally a set of processes, which could potentially be useful to a large set of users. Here, the technology is built, and then a customer who has a matching need, uses the technology to run its operations. The start-up then fits the problem more closely by watching its initial customers, and then very quickly tries to find who else could have a similar need, and sells it to them. The team listens to not just one customer, but dozens of them, and finds a way to build around the core technology so that it can sell to larger and larger no. of users.

Technology here is the end, and not just the means, for the start-up. And their problem space maybe initially defined by a set of companies, but they are hungry to built out their problem space so that they can be relevant to thousands of users.

In a nutshell, the difference in the Problem Universe is:

1. For a CIO led technology: Built for the company, bounded by the company, fitted for the company. The more unique, the better!
2. For a start-up led technology: Built for technology's sake, bounded initially but striving to be unbounded, seeking to fit as many companies as possible. The more general the better!

In the next post, I will talk about how the Problem Universe affects the constitution and architecture of the solution, its maintainability, and its shelf life.