Enterprises undergoing modernization often face a dilemma of whether to build or buy for their full system solution. While there are many trade offs between the two — buy, for example, can mean faster time to market while build can offer more flexibility and room for customization — we shouldn’t think in such binary terms. Instead, we need to learn to embrace both. The way to do this effectively, is to consider build and buy not through the lens of product, but rather component: that way you’re getting the flexibility you need where necessary while also moving quickly and minimizing the time you spend building repeatable, commodity parts of your system.
How it works in manufacturing
Let’s look closer at this by looking at an example from manufacturing. In manufacturing, costs can be reduced by purchasing customized components from low-cost or efficiently organized manufacturing centers. For instance, in the initial phase of the mobile phone manufacturing industry, mobile manufacturers built everything. However, as the industry matured, things changed. Manufacturers started to focus on design and relied on external vendors for parts like chips and displays. For example, Apple buys displays and lenses from external vendor partners that are customized to their specifications. With this approach, we see synergy between vendor partners and manufacturers, forming a healthy partnership ecosystem leading to a hybrid manufacturing ecosystem.
The hybrid manufacturing approach helps mobile manufacturers maintain mobile as their core product identity with agility to roll out new products at faster pace with buying upgraded & new components from the vendor partner ecosystem.
We see similar trends in the car manufacturing industry. With the rise of SaaS (software as a service), it today applies to the software industry too. The decision has shifted from building or buying systems to building or buying components.
What does this all mean in practice? The first step is to design your system architecture blueprint with the required components and then later make decisions on whether you should build or buy each component.
As in the case of mobile phones or cars, the end product or system is the company’s identity and brand, which should make an impact as a cohesive product.
To design your new system with a mix of build and buy components, where each component does one job — and does it very well — is to apply the principle of 'Single Responsibility' for each component.
In the software world these components are referred to as the business capabilities of the system. By using techniques like Event storming and Domain Driven Design, you can identify different components of the large system; to build it, you can apply a platform thinking approach.
Here is an example of different components of an insurance system with candidates to buy in GREEN color:
The Product lifecycle and Apply components in the example above are key to creating a unique and differentiated brand experience. This means they need to be built.
One of the common use cases from above is to buy a Payments mechanism. This is available in the SaaS model and is easy to integrate with the overall system. As a payments service typically requires support for many different types of payment methods. With new methods emerging, requiring upgrades to a payment mechanism, it isn’t hard to see why businesses would choose to buy this component. Doing so can relieve pressure on development teams and could even reduce the time to go to market.
Many components that are typically purchased from providers are available in software-as-a-service or self-hosted solutions. Some key driving factors for SaaS vs. self-hosted solutions include:
Data and privacy guidelines meeting local government regulatory policies
Realtime/runtime dependency vs async/offline dependency with SLAs, such as availability and performance
Pricing model (pay per use, subscription model or purchase and host)
One primary architecture principle for choice of build or buy components (services) is that they should be composable with loosely coupled architecture such as microservices, which allows it to be replaced or upgraded without customer impact or system downtime.
Following microservices architecture, these components are built as single or multiple microservices and help achieve a loosely coupled architecture where each service can independently evolve. You should be able to swap or check the feasibility of replacing an old component using practices such as canary releases or A/B testing.
This approach can also help leverage off-the-shelf or existing components as a stop-gap to achieve faster time to market and eventually replace it with better alternatives.
In today’s world of software development with software-as-a-service (SaaS) paradigm, one should always look to leverage purpose-built components — what might be called “commodity software” — that meet product requirements like Payments service providers or Document management services. This hybrid approach allows the enterprise to maintain its core product identity and focus on product differentiation; it also helps it deliver at pace. Following the Single Responsibility Principle and loosely coupled architecture allows each component/service to evolve or be replaced independently.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.
