Answering the Build or Buy Question

One of the questions that CIOs frequently face is termed "build
or buy." Should we build this system or function ourselves, or
should we just buy something even though it may not meet our needs
exactly? For example, often the business side will argue for
building something because the systems that can be bought don't
quite align with how the business runs. Other times, the techies
will want to build something and the reason comes down to having
fun. So, what criteria should you use to decide whether to build or
by your next system?

I think there's one simple measure that can be applied to answer
the build vs. buy question: Does the system or function add
competitive advantage? If so, then build it. If not, buy it. A few
examples:

Company IT departments don't build general ledger packages anymore for a good
reason: your accounting software won't add to your competitive
advantage. We do, however, see organizations trying to significantly
modify ERP systems to change how paydays are handled, etc. In Utah
for example, we modified SAP's payroll system to handle
a special way the Highway Patrol had of paying troopers because
they couldn't be convinced to follow a standard business
convention. The end result will be a system that's more prone to problems now and more expensive
to upgrade later.

Of course, Utah isn't a business, but if it were, they'd be
deriving no special competitive advantage from the way troopers
receive their paycheck. These kinds of system should be bought and
business processes should be changed to ensure that the system requires
as few modifications as possible.

On the other end of the spectrum, I'd cite my experience at
iMALL. We built a subscription-based eCommerce system. It wasn't
one of a kind--at several points we could have bought something
that did something similar. In the end, however, we believed we could
build a better system and that was the basis of our competitive
position. Worked too. We sold the company for $450 million (in 1999
dollars) based largely upon the business model and the technology.
We eventually had over 50,000 merchants using the system and did
partnerships with companies like First Data Corp. that we would
have never been able to pull off without our own system.

The cloud in that silver lining is this: we built too much of
the system. For example, we should have bought a transaction monitor
(application servers were too new) early on instead of trying to
handle them ourselves. We spent a lot of precious capital building
components that we should have bought. The rule works here too:
many of the components offered no special competitive advantage and we
had no business building them.