Chapter 15. Focus on Core Competencies: Build Versus Buy

While we’ve made the point that you should never rely on a vendor as the solution for scaling your product, we do not mean to imply that third-party solutions do not have a place in your product. In fact, as we will discuss in this chapter, we believe that companies that specialize in developing specific components should provide most of the components within your product. The difference between allowing a vendor to provide scale of your product and allowing a vendor to provide components is simple: You are the owner of your product and must architect it to both achieve the business case and scale to meet end-user demand. No third party will ever have your best interests in mind; every entity has its own shareholder expectations to meet. Let’s turn our attention to when and how we should source product components from third-party providers.

The impact of these decisions on scalability is obvious. The more time an organization spends on supporting existing solutions, the less time it has to spend on creating growth and scale. As we will discuss in Chapter 20, Designing for Any Technology, two keys to architecting scalable solutions are to always ensure that you can scale horizontally (“out rather than up”) and agnostically. Scaling agnostically requires that we design solutions such that components are replaceable; in other words, we should be able to obtain authentication solutions, databases, load balancers, and persistence engines from a number of vendors. When architectures are designed to scale horizontally and agnostically, the question of whether to build or buy something becomes one of competitive differentiation, company focus, and cost.

Anytime you buy rather than build, you free up engineering resources that can be applied to differentiating and growing your business. Engineers are one of your most precious and critical resources—why would you ever want to focus them on things that do not create superordinate shareholder value?

You may recall from past education or even from some of the earlier discussions in this book that shareholder value is most closely associated with the profits of the company. Rising profits often result in changes to dividends, increases in stock prices, or both. Profits, in turn, are a direct result of revenues minus costs. As such, we need to focus our build versus buy discussions along the paths of decreasing cost and increasing revenue through focusing on strategy and competitive differentiation.

Our experience in this area is that most technology organizations have a bias toward building components. This bias most often shows up in an incorrect or incomplete analysis showing that building a certain system is actually less expensive to the company than purchasing the same component. The most common mistakes in this type of analysis are underestimating the initial cost of building the component, and missing or underestimating the future costs of maintenance and support. It is not uncommon for a company to underestimate the cost of support by an order of magnitude, as it does not have the history or institutional DNA to know how to truly develop or support critical infrastructure on a 24/7 basis.

If you adopt a cost-focused strategy for the build versus buy analysis of any system, a good way to test whether your strategy is working is to evaluate how often the process results in a build decision. Your decision process is probably spot on if nearly all decisions result in a buy decision. The exception to this rule is in the areas where your company produces the product in question. Obviously, you are in business to make money, and to make money you must produce something or provide a service to someone.

A major weakness of cost-focused strategies is that they do not focus on strategic alignment or competitive differentiation. The focus is solely on reducing or limiting the cost incurred by the company for anything that is needed from a technology perspective. Very often, this strategy is employed by groups implementing back-office information technology systems. Focusing on cost alone, though, can lead to decisions to build something when a commercial off-the-shelf (COTS) or vendor-provided system will be more than adequate.

• Are we the best or among the best (top two or three) providers or builders of the technology in question?

• Does building or providing the technology in question provide sustainable competitive differentiation?

To be able to answer the first question, you need to be convinced that you have the right and best talent to be the best at what you are doing. Unfortunately, we find that too many technology organizations believe that they are the best at providing, well, you name it! Not everyone can be the best at everything. If your company doesn’t specialize in something, you will not be the best in anything; and if you believe you are the best in everything, you are guaranteed, due to lack of focus, to be the best at nothing for a very long time. In the real world, only two or three providers of anything can claim to be the best or at least in the top two to three. Given the number of candidates out there for nearly any service or component, unless you are the first provider of some service, the chances are slim that your team really is the best. It can be good, but it probably is not the best.

To be able to answer the second question, you need to be able to explain how, by building the system in question, you are raising switching costs, lowering barriers to exit, increasing barriers to entry, and the like. How are you making it harder for your competitors to compete against you? How does building the system help you win new clients, keep existing clients, and operate more cost-effectively than any of your competitors? What keeps them from copying what you are doing in very short order?

We call this the “Not Built Here” (NBH) phenomenon. Not only is the NBH attitude dangerous from the perspective of scalability, it is crippling from a shareholder perspective. When applied to very small things that take only a portion of your development capacity, it is just an annoyance. When applied to critical infrastructure, this mindset very often becomes the source of the company’s scalability crisis. Too much time is spent managing the proprietary system that provides “incredible shareholder value,” and too little time is devoted to making and creating business functionality and working to really scale the platform.

To clarify this point, let’s take a well-known real-world example like eBay. If eBay had a culture that eschewed the use of third-party or COTS products, it might focus on building critical pieces of its software infrastructure such as application servers. Application servers are a commodity and can typically be acquired and implemented at very little cost. Assuming that eBay spends 6% to 8% of its revenue on building applications critical to the buying and selling experience, a portion of that amount will now be spent on building and maintaining its proprietary application server. As a consequence, either less new product functionality will be created for that 6% to 8%, or eBay will need to spend more than 6% to 8% of its revenue to both maintain its current product roadmap and build its proprietary application server. Either way, shareholders suffer. eBay, by the way, does not have such a culture; in fact, it has a very robust build versus buy analysis process to keep just such problems from happening.

The right approach is to merge the two approaches and develop a set of tests that can be applied to nearly any build versus buy decision. We also want to acknowledge a team’s and company’s natural bias to build—and we want to protect against it at all costs. We’ve developed a very simple, non-time-intensive, four-part test to help decide whether you should build or buy the “thing” you are considering.

Are you increasing switching costs for your customers and making it harder for them to leave your product or platform? Are you increasing the switching costs for your suppliers? Are you changing the likelihood that your customers or suppliers will use substitutes rather than your product or that of a competitor? Are you decreasing exit barriers for the competition or making it harder for new competitors to compete against you? These are only a few of the questions you should be able to answer to be comfortable with a build versus buy decision. In answering these questions or going through a more formal analysis, recognize your natural bias toward believing that you can create competitive differentiation. You should answer “No” more often than “Yes” to this question and stop your analysis in its tracks. There is no reason to incur the lost opportunity associated with dedicating engineers to something that will not make your company significantly better than its competition.

If you answer, “No, we won’t sell it, because it creates differentiation for us and we want to win with our primary product,” you are only half right. A fully correct answer would also include “The value in selling it does not offset the cost of attempting to sell it,” or something along those lines.

Here’s something else to consider: Given that there can be only one company, team, or entity that’s best at any given “thing,” how likely is it that your team can be the best at both what you do to make money and the new component you are considering building? If your organization is a small company, the answer is “Very unlikely.” If it is statistically unlikely you are the best at the thing you started on, how can it be more probable that you will be the best at both that old thing and this new thing?

If your organization is an online commerce company, it’s entirely possible that it is the best at logistics planning or the best at presenting users with what they are most likely to buy. It is not very likely at all that the company can be the best at one of those things and be the best developer of databases for its internal needs or the best fraud detection system, or the best at developing its special firewall or its awesome load balancer. More than likely someone else is doing it better.

Make sure you treat the analysis as you would a profit and loss statement. If you are dedicating engineers to this project, which projects are they not working on and which revenues are you deferring as a result, or which scalability projects won’t get done and how will that impact your business?

1. Seattle Computer Products. Wikipedia. http://en.wikipedia.org/wiki/Seattle_Computer_Products.

In 1980, as IBM was starting to look for partners to produce software for its new PCs (“Project Chess”), it came calling on Bill Gates at Microsoft to determine if Microsoft would be willing to license its programming languages (e.g., Basic, Fortran, Pascal, COBOL) to IBM. IBM also enquired as to whether Microsoft would be willing to develop an operating system. Microsoft didn’t have any operating systems at the time—the company focused on building programming languages—and it referred IBM to the largest operating system vendor at the time, DRI. Accounts vary as to why DRI didn’t win the contract initially, with most of them circling around the unavailability of the owner for discussions. IBM was in a hurry and came back to Microsoft with its need for an operating system.²

2. The rise of DOS: How Microsoft got the IBM PC OS contract. PC Magazine, August 10, 2011. http://forwardthinking.pcmag.com/software/286148-the-rise-of-dos-how-microsoft-got-the-ibm-pc-os-contract.

Gates and Paul Allen discussed the opportunity. Microsoft didn’t have the in-house expertise to build the operating system in a time frame that would meet IBM’s need. As most folks with a computer science degree will understand, the development of a compiler or interpreter is significantly different from the development of an operating system. But Allen did know that Tim Paterson of SCP, while waiting for DRI to port its Control Program for Microcomputers (CP/M) operating system to the 8086, had developed his own “quick and dirty” operating system dubbed “QDOS.” Microsoft initially licensed the software for $10,000 and ultimately purchased it outright for $50,000 while also hiring Paterson away from SCP.

We think you know the rest of the story: Microsoft went on to dominate the PC industry. Looking through our questions, you can see several elements. Even though this was clearly a strategic move for Microsoft, the company’s leaders knew that they didn’t have the right skills in house to do it right. So rather than “build it,” they “bought it.” But in this case, they bought the whole product and the experience along with it.

The “Classic Mac OS” that premiered in 1984 had, by the early 1990s, started to become bloated and slow. In addition to being slow, it lacked critical features such as memory protection and preemptive multitasking. Apple as a company probably had little choice except to focus on both hardware and the operating system for the original Macintosh. But Apple’s attention span drifted into creating multiple versions of the Macintosh and several peripherals, creating an absence of focus and sparse resources applied to any single product.^3,4 Apple attempted several times to update its Mac operating system, including the failed Copland initiative of the early 1990s. By 1996, it had become clear to then CEO Gil Amelio that Apple needed to purchase its next operating system.

3. The real leadership lessons of Steve Jobs. Harvard Business Review, April 2012. http://hbr.org/2012/04/the-real-leadership-lessons-of-steve-jobs/.

4. Avoiding Copland 2010. ARS Technica, September 27, 2005. http://arstechnica.com/staff/2005/09/1372/.

Enter NeXT, the company Jobs founded after being ousted from Apple. NeXT was experiencing its own issues with lack of focus. Having decided to both create the world’s first GUI-enabled UNIX operating system and an innovative hardware solution, NeXT was beset with a number of product delays. Marketing and distribution failures crippled the company’s ability to persuade customers to adopt its hardware solutions. Businessland, once heralded as the largest retailer of personal computers, had entered into a relationship to distribute the NeXT platform but shortly thereafter filed for bankruptcy, leaving NeXT with no distribution partners of any significance.⁵ Jobs was largely funding NeXT with his own resources; given the company’s cash burn rate, he needed to focus on doing one thing well. While he considered it a personal failure, he decided to focus on the NeXT operating system (NeXTStep) and creating licensing relationships for distributing the operating system for use on other platforms. In 1993, NeXT exited the hardware business.

5. Loss could force Businessland into bankruptcy. New York Times, May 15, 1991. http://www.nytimes.com/1991/05/15/business/loss-could-force-businessland-into-bankruptcy.html.

NeXT’s operating and financial problems collided with Apple’s need for a next-generation operating system. Both companies had suffered from a lack of focus. NeXT was a limited-resources startup attempting to create an innovative hardware and operating system. Apple was a technology behemoth spread thinly across multiple platforms, software, and devices. Neither company was successful attempting to do everything. The drain of resources was causing growth and viability concerns for both. As Jobs relayed to Walter Isaacson, “Deciding what not to do is as important as deciding what to do.” Apple announced its purchase of NeXT in 1996, ultimately creating an opportunity for Jobs to take control of Apple and “fix it.”⁶

6. Apple acquires NeXT, Jobs. CNet, December 20, 1996. http://news.cnet.com/Apple-acquires-Next,-Jobs/2100-1001_3-256914.html.

The two most common approaches to making build versus buy decisions are the cost-centric and strategy-centric strategies. A third approach, merging the benefits of both approaches, avoids most of the problems each approach has individually. You can also use a four-part checklist for your build versus buy decisions to help you make the right choice.

• Cost-centric approaches to build versus buy focus on reducing overall costs but suffer from a lack of focus on lost opportunities and strategic alignment of the component being built.

• Strategy-centric approaches to build versus buy focus on aligning the decision with the long-term needs of the company but do not account for total costs.

• Merging the two approaches results in a four-part test that has the advantages of both approaches but eliminates the disadvantages.

• To reach a build versus buy decision, you should answer the following questions:

Does this component create strategic competitive differentiation?

Are we the best owners of this asset?

What is the competition for the component?

Can we build the component cost-effectively?