Should you build or buy software solutions?
It has been a long debate about whether an organization should build software solutions using in-house IT resources (build) or buy market-ready products (buy). Many articles put together plausible arguments in favor of one approach over the other, and/or ranking/listing important factors for consideration. However, in the software industry, the only constant is change. Some factors are still valid, while some traditional arguments might need a second thought. For example, in an inspiring article (link), Colin Hung summarized six arguments that are compelling but actually should be ignored.
At the beginning of the decade of the 2020s, shall we look into the ?build vs. buy decision? dilemma from a different angle? This post is going to list some critical factors in the decision-making process.
Setting the Stage
Let?s assume an organization is planning to install a software solution to improve a business process and/or optimize operation structure and efficiency. If the organization doesn?t have enough monetary power, doesn?t have an internal IT resource or the internal IT staff are not competent in making the solution or not available due to prioritization, then the ?build vs. buy decision? will fall apart or be solved automatically. Three scenarios will happen: (1) if the organization doesn?t have enough cash, but has internal IT resources or has a partnership with external IT teams, then the software solution can simply wait for the availability of IT resources; (2) if the organization doesn?t have IT resource at hand but has money, then it can simply acquire a solution on the market; (3) if the organization has neither cash nor the IT resources available, then the plan of having a software solution will become mission impossible.
The ?build vs. buy? dilemma often occurs when an organization has both financial resources (or borrowing power) and internal IT resources (or partnership) ready to implement the solution.
With the growth of the computing technology and software industries, many specialized software vendors are rising and many innovative products are available on the market. At the same time, more and more companies and organizations have their own IT departments with strong teams capable of solution customization and integration. Generally, for both software vendors and in-house IT departments, the IT community shares more or less the same design and implementation skills, and software development best practices. If the internal IT staff lacks the competency to implement the required features in the software, then the ?build vs. buy decision? has an obvious answer. For example, most organizations are incapable of creating a solution similar to the Microsoft Office 365 suite or MS SQL Server, and simply ?buy? those products. This ?buy? approach isn?t necessarily bad, because most organizations don?t want to allocate IT resources to develop generic products, but focus on strategic solutions to specific problems.
Alright. The point here is to compare apples to apples. The following discussion assumes that an organization has both monetary and IT resources, and its IT resources are capable of implementing a similar solution to a commercial-off-the-shelf (COTS) product.
Now, let?s analyze the ?build vs. buy decision? problem.
The Invisible Force: Cultural and Political Factors
A famous article by Patrick Hung and Graham Cedric Low, 2008 (link) discusses the political factors that influence an organization?s decision-making process. I put this point first because we cannot deny that the organization?s culture and senior management?s influence can easily push the ?build vs. buy decision? in one direction. The biased opinions usually come from prior experience, vendors? marketing influence on higher-ups, budgeting policies, end-user preference, and company?s culture, which are not specific to a software solution.
However, the ultimate accountability of the software still lies with the internal IT group. So, during the ?build vs. buy? decision-making process, IT leaders and IT teams should always keep the cultural and political factors in mind. Effective communication with the senior management team will help unveiling myths. Overall, the organization?s culture and politics should guide it smoothly toward either a smooth software procurement or an internal development.
After pointing out the non-specific factors, let?s examine factors specific to the software solution that could affect the ?build vs. buy decision?. The specific factors are determined by the software requirements. For example, the business vision and scope, the functional requirements, the architectural requirements, and other non-functional requirements. Careful examination of the software requirements can help us understand the needs and use cases, and recognize the critical features and business values of the software. The sections below list some factors worth considering in the ?build vs. buy? decision-making process.
The Two Extremes: Core Competency vs. Plug-and-Play Product
Almost all articles have the same opinion that a company should ?build? business value and ?buy? the basics.
Larger companies choose to ?build? software systems that are part of their core competencies. For example, banking systems are critical to every financial organization and are mostly developed in-house. Sometimes, companies are forced to take the ?build? approach to avoid disputes with rivals. For example, AWS developed DocumentDB to remedy the tension with MongoDB. Huawei announced Harmony OS in order to prepare for the Android prohibition due to America?s trade war with China.
The other extreme is to ?buy? generic products with multiple functions. For example, IT teams are willing to purchase licenses or subscriptions for Visual Studio and other tools used throughout the software development life cycle, sales teams are willing to buy Salesforce, and HR teams trust PeopleSoft. The generic products are easy to install and have been tested by many users. When there are several vendors, we can also evaluate products and negotiate pricing plans. In this case, the ?build? approach hardly has any advantage.
If the software falls into one of the two extremes, then the ?build vs. buy? problem is relatively easy to solve. For software solutions that need customization and/or integration, the ?build vs. buy? problem becomes daunting because there are ties on both sides, and sometimes fears and misconceptions might lead to a bad decision.
Time of Delivery Requirement
If both ?buy? and ?build? approaches can meet the delivery time requirement, then this factor is of lower priority. If the software delivery is time-sensitive, then we need to put more weight on this requirement.
It is generally accepted that the COTS product can guarantee the delivery time. This argument assumes that the market will eliminate vendors and products that are not able to deliver on time. This point is generally true. However, there are chances that your organization might be the one that identifies passive vendors. So a diligent investigation of the market is necessary. Besides evaluating external conditions, you might need to consider the lead time for the procurement process overall, customization/integration time, and/or business process adjustment/training time.
While the ?buy? approach has some advantages at the time of delivery, you might consider ?build? approach if a multi-stage development cycle is possible. In this scenario, the internal IT team delivers a set of features first to meet the timeline and quality requirements, then iteratively adds peripheral features in later phases.
When coming to the point of time estimation, some people are afraid of (1) vendors bragging about or over-stating their products capabilities, and (2) the ego of internal IT staff. These things are not under our control. Decisionmakers should forget the stereotypes of both vendors and local development teams, and instead, judge the statements based on the implementation time of similar projects.
Return on Investment Requirement
Organizations strive to achieve high returns on investments (ROI). Also, the ROI requirement usually determines the allocation of funding and resources.
Generally, the ?buy? approach has advantages in pricing, not only because the COTS products have wide user bases to lower unit costs, but also because software vendors and service providers are exploring a variety of modern marketing strategies. For example, more and more vendors offer the subscription pricing model, so that buyers don?t have a big upfront expense. Service providers, like AWS, modularize or componentize their products, so that customers only pay for what they really need.
Even though it is commonly accepted that the market-ready solution is cheaper than the home-build solution, Colin Hung (link) pointed out that we should think twice. The ?buy? supporters usually list some impressive numbers comparing the costs of the COTS software and the equivalent in-house software. However, this comparison ignores the fact that an organization probably doesn?t need all features of the COTS software. If we compare the costs feature-for-feature, then both approaches tend to end up at very similar numbers.
It is tricky to compute the total cost of ownership (TCO) of the ?buy? and ?build? software. When estimating the TCO of the COTS software, people sometimes accidentally ignore the cost of product-comparison, customization implementation, and integration with existing infrastructure. On the other hand, when evaluating the TCO of the ?build? software, people sometimes count in irrelevant costs, such as operation overhead cost, depreciation and amortization, and so on.
Therefore, in order to have a cost-effective software installation, the TCO comparison should be specific to each vendor/product. For some widely used software or services, we are able to get a good bargain. While for some software products that are very specialized, the ?build? and ?buy? approaches might have equivalent TCOs.
Non-functional Requirements
Decision-makers need to think carefully about some non-functional requirements which might turn the tables in the ?build vs. buy decision?.
Most ?buy? applications need customization or integration with existing infrastructure or other systems. Does the COTS solution map into the organization?s business processes? If there are gaps between the ?buy? product and the current business processes, could the internal IT team work on customization, or could the organization adjust business processes?
Will the COTS solution integrate with existing systems and technology? Some organizations are open to solutions that are not in the same ecosystem, but some organizations are not. Even though the ?build? product can integrate well, we should be aware of the fact that more and more COTS solutions are designed to be framework agnostic.
There are other non-functional questions that could affect the ?build vs. buy decision?. Does the COTS solution complicate the overall architecture? Does the COTS solution meet all security requirements and legal compliances? Are the COTS product and in-house software scalable, reliable, and highly available?
Maintenance and Support
We certainly wish that once the software is installed, then the less IT intervention the better. But things always change. Both the ?buy? and ?build? software need to install security patches, fix bugs, and/or add new features.
People usually think that the service level of internal IT teams is better than that of vendors. For a ?build? an application, the internal IT team has more control over the solution, thus better maintenance and support quality. If a company opts to ?buy? a product, it may find that a vendor takes longer and charge more money for maintenance and support. All these opinions are assumptions or promises. The reality could be different and there are risks in both ?build? and ?buy? approaches.
A better way is having a service-level agreement (SLA) signed when acquiring a COTS product or before building an in-house application. The SLA permits all parties to understand their responsibilities involved with the use and maintenance of the software.
The ?build vs. buy? debate is challenging. There are pros and cons on both sides, and we cannot use a formula to weigh the two approaches. Analyzing delivery time and TCO helps ensure cost-effective software procurement or development. Examining non-functional requirements guarantees smooth software installation. A careful study of the maintenance and support assures the sustainability of the software.
The ?build vs. buy decision? is not a science, but more of an art. In this decision-making process, nothing is absolute. We should analyze them in a scope that is specific to a software solution, and view all factors without bias.
The good thing is that ?build? and ?buy? are competing with each other and both are improving. Moreover, having the ?build vs. buy? discussion is a sign of a healthy organization, which indicates that people are really thinking about the best way to advance the business.
Thanks for reading.
