Build vs Buy: Buy when possible, build when necessary

EA Principles Series Part 6

Mihai Stancu
chick-fil-atech
5 min readFeb 28, 2023

--

This is part 6 in our 7 part Architecture Principles series. We’re going to discuss one of our core principles for technology at Chick-fil-A which is how we evaluate “Build vs. Buy” decisions.

Photo Credit:https://www.nytimes.com/2020/12/15/business/modular-construction-pandemic-coronavirus.html

How this principle is related to the Chick-fil-A Corporate Purpose

One of the cornerstone principles set forth by our company’s founder, Truett Cathy, is found in the Chick-fil-A Corporate Purpose.

The Corporate Purpose is useful in thinking about “Build vs. Buy” decisions across Chick-fil-A as it relates to stewardship: we want to begin with how we can be good stewards of our technology portfolio and our organizational resources (time, people, money).

In addition, we also have to take into consideration the business capabilities we have / aspire to have and how we can best build a technology portfolio to support them.

Principle: Build vs. Buy: Buy when possible, build when necessary

Here is our principle as written:

Enterprise Architecture recommends purchasing Software-as-a-Service solutions when the market provides options that are congruent with Chick-fil-A’s business and technology requirements.

When a decision to buy is made, teams should not make implementation decisions that force the proprietary aspects of the purchased product onto other teams. Proprietary data field names, integration patterns, and authentication methods should be abstracted by using adapters (light-weight programs that convert proprietary aspects to CFA-standards). Teams should also consider the ability of the product or platform to integrate and “fit” into Chick-fil-A’s larger technology ecosystem.

When the market does not offer a viable solution or Chick-fil-A wishes to differentiate themselves from the marketplace in a particular area, build an internal product using a Product Team + DevOps model (staff-led or partner-led engineering).

Why? Buying best-in-class SaaS products reduces time-to-market and the high costs of ownership, management, and support of custom software over time. It also lets us leverage the expertise of the marketplace. Building solutions that are available in the market also results in a high opportunity cost while resources are tied up an unable to work on more strategic initiatives.

Outcomes and Tradeoffs

Outcome 1: Embed healthy Build vs Buy thinking in the our organization

The primary goal behind this principle is to ensure we are correctly allocating and positioning our internal resources to develop and maintain the innovative applications needed to scale Chick-fil-A’s business into the future while maintaining a healthy and sustainable technology portfolio.

In order to be good stewards of our technology, we need a clear understanding of requirements and the business capabilities we are trying to develop a solution for to help us elect if we should Build or Buy.

The best way to achieve this is to embed a model for evaluating Build vs Buy decisions in the heads of the people making those decisions. Hence this principle and our efforts to socialize it through roadshows and project discussions.

Outcome 2: Buy best in class SaaS products

Exploring best in class SaaS products should be our first consideration for new / replacement of existing business applications as it reduces our time-to-market for a solution and minimizes the amount of software we have to build and maintain ourselves. Every product we decide to build comes with a lot of costs over time.

SaaS products are typically easy to implement and use, require some minimal customization, and offer an immediate value by leveraging already established features and functionality for a specific business need. Buying an existing product significantly reduces the need for Chick-fil-A to source in-house software development and engineering resources as the software vendors provide ongoing technical support, upgrades and development of new features and functionality.

Purchasing SaaS products also comes with some limitations. Many products are designed to support a broad range of use cases across service industries and may not fully meet our unique business needs. This is especially important to consider when evaluating build vs. buy for solutions related to business capabilities that differentiate us in the market place and make us unique. In such cases, the business ends up having to pay for a lot of customization services or workarounds to tailor the product to their requirements and in return this can drive up the cost significantly, create compatibility issues and also drive down user satisfaction.

Sometimes we do have teams that build things that could be bought. We have open and honest conversations about the cost of these decisions to inform the decision maker as best as possible. In some cases, we may flag these decisions as “yellow” or “red” in our EA Principle Governance process to make sure every leader of a functional area can understand where they have taken on additional risks or embraced a sub-optimal approach to architecture in their areas. This is intended to provide information to leaders, not shame a team for their decisions. We always tell them about a “yellow” or “red” first in the event they wish to change course.

Outcome 3: Build innovative software solutions

Building custom software solutions in-house gives us the flexibility to develop solution designs that meet unique needs and requirements for our business. It also gives us the opportunity to be ahead of the industry when it makes business sense. This approach provides complete control over the functionality, design, and user experience. Building solutions in house also allows us control of the technology stack and makes integration simpler, reducing the risk of any compatibility issues.

However, building software solutions in-house is a time consuming and resource intensive process and requires a significant investment. When we decide to build a product, we require the establishment of an internal Product Team using a DevOps model. It is the Product Team’s responsibility to deliver the product and to handle ongoing maintenance, upgrades, and technical support. This has significant impacts to total cost of ownership over time.

We encourage teams to evaluate build decisions carefully and be sure that we are investing in building things that give us a market edge or where there is no viable solution, and buying whatever we can outside of that.

Conclusion

The decision to buy or build software depends on several factors. Teams should carefully evaluate their requirements, resources, and constraints before making a decision.

Before a decision is made to buy or build software, it is important to thoroughly research existing options for best-in-class SaaS products and consider the tradeoffs: total cost of ownership, opportunity costs, etc..

We believe that buying best-in-class SaaS products reduces time-to-market, lowers the long term costs of ownership and allows for us to take advantage of industry expertise in certain business areas as appropriate. We also believe that there are certain business capabilities that are unique and strategic to helping Chick-fil-A perform as a leader in the marketplace and we support building those systems and applications whenever we can.

--

--