Choosing the Right Software Solution: Build Vs. Buy

With very few exceptions, all systems have taken advantage of reusable service components like databases or code libraries for many years. Choosing the correct service level components can be, in itself, a complicated process that requires understanding of data access patterns, governance, user behavior and other service use metrics. This article does not attempt to delve into the complexities of service level build-vs-buy decisions, but instead focuses on business level decisions and what exactly it is that is being paid for. Cloud native architectures have given us functional level components that are more composable at a business outcome level than previous service based component solutions.

Before cloud computing, the Build vs. Buy decision was largely about who got paid for what part of the solution. The IT Operations department was paid to run the hardware and shared services used by the solution. Then either the IT development team got paid to build the software or an external vendor was paid for the code. Finally came the ongoing operational support of the solution, which is by far the largest component of the total cost of the system. If you bought the solution, you had the choice to outsource support to the software vendor, or train an in-house team to support the tools.

Cloud-native subscription based services and modern DevOps processes have fundamentally changed the “Build vs. Buy” question. At first glance it might seem that subscription services are just a new model to pay for computing services, a simple shift from “Build vs. Buy” to “Build vs. Subscribe”. Upon closer examination, however, you may realize that cloud-native computing, and the API-driven economy it creates, are designed from the ground up to support robust integrations. Modern DevOps practices provide special value by combining the team who builds the software with those who run it. Support is now a multi-layered process that crosses different service level boundaries. All of those lines that formerly made a clean divide with the “Build vs. Buy” decision have been erased.

It may help to think of the new Build vs. Buy design choice as a continuum. At one end, you design, build and run 100% of what you need in-house (which no one does) and at the other, you outsource the entire solution lock, stock, and barrel to one service provider. In between, there is a lot of flexibility about how much you want to manage and how much you want to pay someone else for.

Where you fall on this spectrum is largely influenced by how rigid your business processes and needs are. As you consider purchasing a service, you may find that your business process would need to adapt to a specific solution. At this point, it’s worth asking “Does my company do it better than the industry, or is this an opportunity to adopt industry-based best practices?” If you find that your unique process is a key differentiator, then you should protect that value and find a better way to automate. For example, you might invest in adapting the software to your process if possible, select a different service, or even create custom components to support your process.

As you consider this process, remember that we’re dealing with business level components. Let’s say you need a solution to help your incident responders more effectively respond to, track, and learn from their work. One component of that solution might be a ticketing system that tracks when an incident starts and ends. The system would also enforce some level of governance over things like root cause analysis and post mortems and provide a view into historical incidents. Another component might be a chat collaboration tool like Slack or Teams that makes it easy for a group of people to work together on finding a solution to the problem. Implementing an integrated solution that captures key tracking events from the chat conversation to update information in the ticketing system allows you to stitch together a solution that leverages multiple fine-grained services with custom integrations that support the unique ways your team works.

So if all the lines that used to surround a “Build vs. Buy” decision are gone, how do I manage that decision? What is the real question I should be asking myself?

What Parts of this Solution will Need to be Custom Built?

When deciding how much of a solution to build as custom software, the question is primarily one of value. Will subscribing to a given piece of the solution generate the most value (in terms of ROI and benefit vs. cost), or is it better to build exactly what you need and take on the increases in ongoing care and feeding costs of the solution?

If you’re a small or mid-size business looking to transition to cloud native, you’ll need to work with an architect who can help you determine how all the pieces fit together. You may be able to handle this decision-making process in-house if you have someone on your team who has information architectural skills. The problem for many smaller businesses, however, is that even if they have such a team member, that person may not have the capacity to take on the work.

If that’s your situation (or if you don’t have the necessary skills on your team at all), it’s a good idea to partner with a software development agency to help you with your research. Choosing an agency partner early in the process will also give you immediate access to cloud native developers who can build (or assemble) the solution for you if that is what you need.

5 Things to Keep in Mind when Making Build vs. Buy Software Decisions

Now that you have a big picture idea of what it takes to make a build vs. buy (or subscribe) decision, let’s dig a little deeper into the nuts and bolts of the process. Because it’s so important that you understand the architectural framework of the solution before you make a decision, we’ll reiterate: you’ll need someone with architecture-level knowledge and skills to walk with you through this process.

With that in mind, here’s how you take the next step.

1. Identify Your Context

Identify your Context – What kind of software do you need? Are you looking for enterprise-level software such as an ERP, CRM, or accounting system? These kinds of platforms will have a much more rigorous evaluation and selection process since they will touch many parts of your organization. Large players in this space often have a “one-stop-shopping” mentality, so you’ll see an ERP system with some CRM functionality, or an Accounting package with some ERP components. As part of your research, you’ll need to understand both the out-of-the-box configurations of their solutions as well as the extensibility features and effort required for any needed customizations. If you’re looking more at departmental level initiatives or new customer facing innovation, you will still need to be aware of the enterprise context that you will be expected to interact with.

A note on highly customizable systems: In general we recommend avoiding large customization efforts within complex solutions like CRM or ERP platforms. These customizations can have unintended consequences when the software or service releases updates or worse yet on the availability and performance of the larger system. Modern cloud native solutions typically integrate smaller components, and then augment those systems with bespoke functionality rather than investing in large customization efforts in a monolithic solution.

2. Collect Requirements

When we talk about requirements in software development, we want to include both functional requirements (i.e., what are the meaningful user outcomes) and non-functional requirements. Those non-functional requirements are often overlooked, so make sure you evaluate meaningful service management information such as requirements for security, availability, scalability, observability, performance, service levels and support systems. The goal here is to determine what meaningful outcomes the system should deliver, as well as the governance and runtime requirements that will be used to evaluate providers.

3. Identify Potential Services

If you are working in a large context, start by breaking apart the requirements into discrete components (i.e. Ticketing and Collaboration from our example earlier). Now you can conduct a software search for those components. We always start with open source searches, since at the component level there are frequently strong open-source solutions available. Quickly weed out any open-source solutions that do not have a significant user base and active support community. We then move on to searching for standard cloud hosted services from the major cloud providers. In many cases this will simply be a cloud managed version of one of those open-source solutions, so understanding the management overhead of open source solutions is important at this point. Finally we make a search for specialized software solutions like ERP or CRM platforms. A consideration of large cross industry platforms like SAP or MS Dynamics should be supplemented by smaller players that are more domain specific to your industry or operational model.

4. Evaluate Contenders

Now that you have identified sources for different components you can evaluate those contenders to eliminate any that do not meet the requirements (functional and non-functional). Then you will want to evaluate the level of customization required and the availability of integration APIs. Take your time during this phase to consider how service management requirements will be composed from the service levels provided by each component. Once you have found the solutions that will meet all the requirements, it’s time to start looking at cost comparisons. It can be very difficult to understand relative costs when components are licensed or priced based on different metrics (users, transactions, capacity, etc.) so make sure you have a very sharp pencil in hand for that part.

Bear in mind that you will be confronted with decisions about adapting your business processes to the software vs. customizing or creating a solution that fits your processes. Remember to evaluate the processes that would need to be changed to identify if it is a differentiator or a liability.

5. Consider Building

Building a custom solution from the ground up is usually a last resort, and as stated previously even this approach will leverage reusable service components. The good news is that you may not (and in most cases won’t) have to build everything from the ground up. Instead, you should be able to find a solution that leverages multiple components that take you 80% of the way to a solution, and then you can custom build the 20% that represents a unique advantage in your industry.

Worthwhile: Your Partner for Greater Value in Software Development

At Worthwhile, our goal is to step into the process where we can provide the most help and support. As your agency partner, we provide the architectural knowledge and skill you need as well as a meticulous analysis and design process that walks you through the five steps described above. Whether you need to integrate several services or create a custom solution, we’ll help you determine which option is best suited to your needs and help you move seamlessly into the build process.

Stage One of our Software Development Life Cycle (SDLC) zeroes in on the design process. During this phase, we work with you to collect requirements based on meaningful outcomes for your users. Then, we conduct research and build a roadmap that captures the big picture of your software strategy and identifies what the most important things to start with are. We then move into research that will evaluate both open source and commercial services that may meet part or all of the requirements. The goal here is to determine what will be the best fit for your business needs and processes. We also help you analyze the build vs. subscribe options so you can take the best path forward.

Wherever you fall on the continuum, we will never pressure you to take an action you don’t need to take. If subscribing to a service and integrating with your current software will meet your needs, we will assist with integration and customization as needed. If building a custom solution on top of your ERP or other enterprise software is the best move, our process ensures the least risk and best results as you segue into the build stage of the SDLC.

Want to know more about our Software Development Life Cycle and how it creates better outcomes for you? Request a copy of our detailed SDLC and Vocabulary Documentation to dig deeper into how our process sets us apart.

About Worthwhile Storyteller

We'll never tell you a lie, but we might tell you a success story that protects the intellectual property of our clients and partners. Our Worthwhile Storyteller is an amalgamation of all of our thoughts, experience, and expertise brought together to give you the facts about our relentless improvement in the software development space.