Software is the lifeblood of most IT departments. So it’s logical that determining when to buy a packaged solution versus building a custom one for a given business requirement is one of the most common types of decisions they have to make. Usually, making the “Buy versus Build” decision involves both technical and business resources. How it’s done varies greatly from one enterprise to the next. Some organizations spend a significant amount of time deciding, while others focus more on analyzing the “buy” choices once it’s been determined that custom development isn’t going to happen. Still others bypass most of the process altogether and dive head first into a “buy” commitment. For the folks who know for sure that they’ll be buying, the big question is often, “When?” This post will focus on situations where the buy decision hasn’t yet been made.

The Architect’s Role

IT architects are often asked to help facilitate the process. While they’re usually not the ones charged with making the decision, they’re often the people who provide the recommendation. If there is to be any formal analysis process, then the architect tends to conduct it. Making the build-versus-buy decision necessarily precedes any product selection process. It should – but doesn’t always -- come after some sort of preliminary needs assessment or strategy activity. If a strategy was developed, the capability might be defined at a functional level and even sequenced on a roadmap, though not defined in very much detail. The more information, the better of course, but even if there’s relatively little data to start with, some of the key questions you’ll need to ask will remain the same. So, what are the most important questions to ask when approaching a Build vs. Buy analysis?

1. Is it really just build versus buy, or is it more complex? In other words, is there a third or even fourth option to include in your analysis? The most common of these include do nothing (or don’t do it yet) and build some, buy some (then you have to determine what proportion for each). It’s understood that many types of Commercial Off the Shelf Software, or COTS, are meant to be customized somewhat – like when you build reports in Cognos or Oracle BI tools. Other COTS require or allow very little customization. Understanding how customization ought to occur and how it’s handled in a particular package is vital to making an accurate assessment.
2. Is the solution redundant with an existing capability (either custom or COTS) and if so, is there a logical migration path to the new capability? And how will that transition be impacted by the buy versus build decision? This question generally implies that a transformation is in progress, and that usually involves added dependencies and constraints.
3. Do you already have a support model in operation or one in the works? For example, if you are thinking about expanding existing Oracle e-business applications, then having an Oracle standard LDAP tool might make more sense than a homegrown one. Also, support includes having people on-site or off who can troubleshoot issues for you in near-real time.
4. Does the business case (or basic proposition) align better with one option versus another? If the value proposition is that some type of ERP-like capability is needed near-term, then building something homegrown might be faster than deploying a major ERP COTS package.
5. Is your organization capable of delivering a custom solution based on the stated requirements? Not every IT shop can do everything – understanding your internal limitations will make a big difference in the overall solution. By the same token, some internal groups will place limits on what COTS (or even hardware needed by COTS) they will support.
6. What is the overall cost of doing one option versus another? Some folks refer to this as “Total Cost of Ownership.” It usually reflects the full lifetime expense related to the solution. It’s obviously more difficult to estimate this up front for a custom solution than it is for COTS, but that doesn’t mean that the COTS approach is always cheaper. Very often, answering this correctly requires some advance work in understanding support costs for existing systems in your own environment.
7. If someone expressed an initial expectation or preference up front, validate why. This is fairly important as it may indicate that the buy or build decision has been more or less made before the analysis even began. In this type of situation, the stakeholders may want the analysis mainly to provide support for and a risk assessment of their initial decision. So, you might ask yourself, what if the stakeholders' initial decision is wrong? That’s a tricky situation since you generally don’t want to be in the habit of trying to deny the wishes of your employers. However, if you feel that there is a serious issue surrounding their direction, document it in the risks and note the possible mitigation that choosing alternatives might provide.

The format you use to highlight the results of the analysis can vary. More often than not, PowerPoint is used to convey the key results of the activity back to the stakeholders. In that presentation, capture the following elements:

1. Description of the Requirement.
2. Goals for the Analysis (and Process).
3. Description of the Technical “Problem Space” / Context.
4. Identification of Options (Build versus Buy, or More).
5. Ratings Matrix (with Explanation of Weights / Priority Applied).
6. Solution Recommendation.
7. Risk Assessment and Issues.

When conducting an analysis like this, the most important thing to remember is that there often aren’t slam dunk answers. In other words, the advantages between one versus another option may not be overwhelming. There may also be tradeoffs to consider that help refine the recommendation. Ultimately, the answer that comes closest to being accurate is the one that assimilates client needs and constraints the best.