Buy vs. Build vs. ?

Buying software from the market vs. creating your own intellectual property. Or is there more to it? Timeless decisions that every organization must make for its own IT estate.

The context of this article

Before we go into details, let’s define the scope. This article is for large enterprises looking to improve their technology and business capabilities. It is not for companies that build and sell software products as their core business.

For product companies, the choice to buy or build is not just technical but rather strategic. It affects their ability to innovate, grow and compete.

This article assumes you have already checked if you own a solution to the problem.

Define Your Needs

Before choosing a third-party solution, ask yourself key questions. Do you really need an external provider for the business capability you want? Not all business capabilities matter equally when comparing your organization to competitors. You must know which ones must be strong and which only need to match others.

Business Capabilities fall into the following categories:

• Differentiating capabilities (Core): These help your company stand out. They are unique in your organization and differentiate you from your competitors. In competitive markets, investing in these capabilities makes sense because they give you an advantage.
• Supporting capabilities (Enabling): These help your core capabilities work. They are important but do not define your business. A core capability in one business may be a supporting one in another.
• Commodity capabilities (Generic): These are common needs, like accounting or managing the payroll. They do not set your company apart. You will find them in many organizations. The best approach is to use standard industry practices. They should be functional but not a focus for investment.

Deciding which category a capability belongs to depends on your business context and strategy.

What makes your organization unique?

Sometimes, a capability that seems like a commodity may actually be a differentiator. This depends on how your company operates and your Unique Selling Proposition (USP).

• Keep in-house if it is a core skill, involves proprietary knowledge, or has high risk, regulatory, or quality concerns.
• Outsource if it is non-core, can be done faster and cheaper externally, and does not reduce strategic control.

Avoid defining your business capabilities too broadly. For example, instead of thinking about an entire Enterprise Resource Planning (ERP) system, break it down into smaller parts. Some may be commodities, while others provide an advantage.

Before buying, consider how the decision affects your key strengths. Vendors’ best practices may force changing your business processes and affect how your teams are organized. Consider how such decisions impact your entire value chain.

An approach to understand Commodities vs. Differentiators

"A Wardley map is a map for business strategy. Components are positioned within a value chain and anchored by the user need, with movement described by an evolution axis."
https://en.wikipedia.org/wiki/Wardleymap

Wardley Maps help your organizations to understand their market, find ways to stand out, and make better investment decisions.

They show you how capabilities, technologies, and services/products change over time within a value chain.

Wardley Mapping

How can you have better strategy discussions, in 90 seconds.

What about the existing IT estate?

Organizations must review their landscape on regular basis. The industry changes fast. An application that was unique a year ago may now be standard. Business priorities also shift. What seemed essential to build in-house may no longer be necessary. Prices may also change, making third-party solutions more attractive.

There is often a desire to replace old applications with new ones. This may be the right choice. However, first consider to extend the life of what you already have:

• Modernizing: Insource your differentiator, use cloud environments, and apply DevSecOps with automation. Make sure you have a good developer experience. Adhere to modern architecture principles.
• Extending: Add missing building blocks instead of replacing the entire application. Create a mobile or web front-end on top of legacy backends. Or build and integrate specific microservices to fill critical gaps. Weigh the total costs (!) against the benefits.

If third-party solutions fit better and updating your application is not worth it, start evaluating new options.

Conclusion  

There is no single answer to buy or build. It is not one or the other anymore. Organizations that value agility and resilience understand this. Modern architecture decisions go beyond buy versus build.

A strong architecture function helps to manage trade-offs and keeps technology aligned with strategy. Decisions must consider integration, scalability, and operations. Clear architecture principles ensure consistency and adaptability.

The choice depends on your needs, current IT landscape, and technology importance to your business. Align decisions with goals and budget. Weigh benefits and risks. Consider long-term impact.

If you like my content and would like to support me, please subscribe and follow me on LinkedIn.