The phrase “Build vs. Buy” has become so widely used that it has become a part of our industry’s lexicon. In general, it refers to the decision whether to build a new application, or buy one “off the shelf.” However there is an implied “either/or” approach to the decision which can be very self-limiting.

First of all, consider this idea of building or buying. In a pure “build” approach, we would have to start by writing an operating system and then work our way up. Or perhaps we should design our own CPU chips? Of course this is silly! How about a pure “buy” approach? Well if an application is very general in nature – such as a word processor – then sure, it’s likely that a pure “buy” solution is out there in a shrink-wrapped box somewhere. But for a complex enterprise solution, at the very least some kind of configuration or customization is going to be needed to fit an organization’s needs.

So from the start we can see that pure “build” isn’t going to happen, and while “buy” may make sense for a general-purpose desktop application, it’s likely that a more complex application is going to require at least some configuration or customization! In reality we are dealing with a continuum of approaches ranging from “build” to “buy”; there may be multiple points along that scale that would work technically but present different trade-offs from a business and engineering perspective.

At the Microsoft Technology Centers, it’s our job to help our customers select the right solution, given of course that it’s based on Microsoft technology. These customers have a lot to think about! They have to navigate user requirements, technical constraints and multiple vendors to make their choice. That “build vs. buy” decision, even within a single vendor’s platform, is just one more wrinkle they need to sort out. For example, is a particular solution better suited to SharePoint, or a custom web application? Should that invoicing application be custom, or could it be built on top of Microsoft Word or Excel as an Office Business Application (OBA)? Should those reports be driven by Performance Point, SQL Reporting Services or by writing an application with WPF or SilverLight? The answer is different for every customer, yet each of these represents a different point along the build-buy continuum.

Each time we use a vendor’s technology – whether it’s “middleware” on a server or a customizable desktop application – we are moving the needle away from “build” and over towards “buy”. If we look at the spectrum, it might look something like this:

BUILD

• Custom application from “the ground up”
• Custom application on a rich framework (e.g. .NET Framework)
• Custom application on one or more vendor products (e.g. Commerce Server application)
• Multiple vendor applications with custom integration, or integration with a smaller custom application
• Vendor application with customizations (e.g. a SharePoint portal with custom developed web parts and workflows)
• Vendor application with configuration (e.g. a SharePoint portal configured with the customer’s logo and desired information structure)
• Vendor application “out of the box”

BUY

Of course, these are fuzzy and may overlap, and there are often hybrid approaches. Making this decision requires deep knowledge of the candidate technologies!

THE CASE FOR MOVING TOWARDS “BUY”

I would say that most of the customers I’ve worked with want to buy and not build. While there are some good reasons for this, it makes sense to think them through. Here are some typical ones:

• Cost: This needs to be analyzed for each case. If a vendor’s product does only 20% of what’s needed, and the rest is all custom, then it’s probably a waste of money. On the other hand if the product removes a significant amount of the build cost, then it may well be worth it. Vendors have the ability to spread their development costs across many customers, so they should be passing that economy of scale to their customers!
  
• Delivery time: Again, if the vendor’s product removes a significant amount of building, it will usually save time. On the other hand, if a vendor’s product is a bad fit, it may cost time (and money) working around the issues.
  
• Support: The vendor supports and updates the product over time. This needs to factor into the cost equation, but it also has implications on reliability and security, assuming your vendor issues periodic fixes to their product and has a good support offering
  
• Features: Any project is going to have a features list that is too long, and project managers always draw a “cut” line somewhere. A vendor’s product may have some of these lower priority features included, so they are more or less “free” if the cost of the product is justified by the high priority factors.
  
• Agility: If it’s well designed, a vendor’s product or platform can provide more agility in the form of allowing quick changes through configuration, for example. It may remove some agility as well, however; if users don’t want to do things the way the product was designed to do them, then excessive customization or disgruntled business users may be the result.

THE CASE FOR MOVING TOWARDS “BUILD”

The same factors come into play in building more of the solution…

• Cost: If the vendor’s product is only a marginally good fit, the cost to purchase, learn, customize and deploy it may be more than the cost to build it all. Or if the product cost is excessive compared to the work it saves, again it’s time to call in the development team.
  
• Delivery Time: In general, buying something that works should save time over building a new one, but don’t forget the time needed to learn the new technology! If an application is simple, and developers are ready and trained with the technology to write it, it might be quicker than learning a vendor product. But this applies only in the simplest of applications, and these projects have a way of being harder than they first appear! Analyze all the use cases, for current and future needs, before shying away due to a learning curve.
  
• Support: Vendor support isn’t usually fun, and there’s a certain satisfaction to having the ability to fix it yourself! However you need to ask who has the time and skills to do the support. And what if they get hit by the proverbial bus? How hard would it be for a new person to pick it up? The larger and more complex the solution, the harder it will be to support all aspects of it yourself.
  
• Features: If there is no available product that satisfies most of the high-priority requirements, then “build” is the only option. Sometimes the only way to get the desired feature set is to build them.
  
• Agility: If you can think it, you could build it … given infinite resources of course. If you don’t want to compromise at all, then build the parts that need to be “just so”. But be aware that you’ll only be as agile as your ability to hire developers to make a change, and that they will need time to make it.

Making these tradeoffs isn’t easy, and requires a deep understanding of the business requirements, the customer’s organization, and the technologies in question. This is part of what happens at an MTC, usually during an “Architecture Design Session,” with the customer, partners and MTC architects all working together as a team to find the best solution among the alternatives.

COMMON FALLACIES:

Here are some common misconceptions about build vs. buy, in addition to the idea that it’s an either/or decision:

• “You can’t be innovative unless you build it yourself”
  The range of possibilities using configuration and customization are surprising! Even the way an application is used can be unique to a situation. It’s worth considering moving towards the “buy” side even if you think nobody has done something before.
  
• “Not Invented Here”
  People who have built something, or who want to, are likely to defend more of a “build” solution. Do the analysis and make a business decision.
  
• “We’d only be using a small part of the product’s capabilities, so it’s a bad fit.”
  If a product provides a lot of value for the solution, it’s worth considering even if there are other parts of the product that won’t be needed. Do the math. If using the product saves build and support costs, then it may be a good value even if you’re paying for some features you’ll never use.
  
• “If I Had a Hammer”
  If the team uses hammers all the time, every solution will look more like a nail. There is some value to staying within a team’s comfort zone, but it is limited. Does the vendor’s product add enough value to justify the learning curve?

A SHORT STORY

I’d like to close with a short story of a customer who ran headlong into the build-buy continuum, and nearly had to suffer the worst of both worlds: a large complex application with a lot of “building” and a lot of code to support, which still required a significant vendor product. I’ll change all the names to protect my customer – and myself I suppose!

Woodgrove Bank wanted a new executive portal for their Intranet. The solution involved a lot of financial “dashboards” combined with documents and collaboration information such as tasks and calendars. I led a briefing and Architecture Design Session for Woodgrove at the MTC, and they ended up choosing a solution based on SharePoint technology. They also chose another software package from Fabrikam Software, and a system integrator, Contoso Services, to put it all together.

About six months later, the customer called, somewhat upset about the project. It seemed that many of the things that I told them would be “out of the box” with SharePoint ended up requiring custom development, and the software from Fabrikam was nearly useless, according to the folks at Contoso Services. As a result, his implementation cost was skyrocketing as Contoso built more and more of the solution from scratch – on top of SharePoint. The customer was starting to feel like the software he purchased was a waste of money.

We agreed to hold another Architecture Design Session to review the architecture and determine what had happened. We had everyone there: stake-holders from Woodgrove, Fabrikam and Contoso were in attendance as well as me and others from Microsoft.

The meeting quickly became awkward as Contoso spelled out the reasons that, feature after feature, SharePoint’s way of doing something wouldn’t work for the Woodgrove executive portal. For example, they had asked users if they wanted the search box on the right or left; the users said “Left” and SharePoint had it on the right, so that was custom work! (The product was SharePoint Portal Server 2003; many of their customizations would have been easier in the 2007 equivalent.) The Fabrikam product features met a similar fate – they were close but didn’t exactly meet the needs, which were all taken literally with no cost-benefit tradeoffs.

The Woodgrove project lead started squirming in his seat. Contoso had an elaborate data model that caused a huge amount of extra work, and had a theoretical technical justification over just using the SharePoint API. One by one, the Contoso consultants justified their customizations based on business requirements or technical arguments, but there had been no cost-benefit analysis. By the end of the day, the customer was fuming, and fortunately not at me! If only they had asked, he would have been glad to relax the requirements in a way that got the job done using the provided software components. A couple of weeks later, Fabrikam sent one of their consultants over to Woodgrove Bank and they were able to replace a lot more of the custom work with their built-in functionality.

Woodgrove had no technical staff on the project: they had a strong business sponsor but no knowledge of the technology on their own. And as it turned out, Contoso only made money by billing for services, and they took advantage of the situation. This is unusual, by the way – the vast majority of systems integrators I’ve worked with would take the high road in such cases – but still there is the tendency for them to stay in their own comfort zone, and if that’s writing code, you can expect to end up with a lot of it.

Lessons learned? I’d say to any customer, if you don’t have your own technical staff to watch over a project, then hire another consultant to do it. I see this often. One consultant is hired to oversee the technical decisions and architecture, and is not considered for the implementation project. That way they can watch out for the customer while allowing the customer to hire an implementation specialist in whatever technology they end up choosing. Better yet, involve the software vendor's consulting services in an architectural and QA role; Microsoft Consulting Services often provides this kind of engagement.

This certainly would have paid for itself at Woodgrove! All those small build-buy decisions pushed them back towards “build” after they already had decided to mostly “buy”, so in effect many features were purchased twice: once in a product and once for the custom code version that Contoso Services wrote.

SUMMARY

As our industry gets better and better at reusing code, whether it’s in class libraries or whole application suites that allow customization, there will be more and more opportunities to fine tune the build-buy decision. Realize that it’s a continuum and keep an open mind as you consider the options along that spectrum.

Bob German
Technology Architect
MTC: Boston

This posting is provided “AS IS” with no warranties, and confers no rights. Thank you for reading it!

(cross-posted to my blog, Vantage Point; check it out for more on SharePoint and related technologies!)