April 30, 2018 | Point of View

Evaluating software scalability in M&A: How to identify risks and opportunities

According to recent data from Pitchbook, private equity deal volume in 2017 fell in all sectors except software and technology. In 2018, software-based deals look to be just as appealing to investors, with 78% of private equity firms planning three to four software acquisitions in 2018-19 and 13% planning five or more, according to a 2017 survey by West Monroe.

It’s clear that private equity firms are identifying proprietary software as a key differentiator or growth driver. ”

But how do you evaluate whether a software solution can adapt to support future growth objectives? Doing this effectively requires an understanding of what can impact architectural scalability, and how these factors manifest in different scenarios.

Defining scalability: Where to begin

One of the most common questions our private equity clients ask when considering investment in a software- driven business is how to define and assess scalability. It has become a popular validation point, but what does it really mean in the context of a technical solution? As it turns out, it means potentially many different things all at once.

Typically, the question of scalability is rooted in a need to understand risk exposure and potential inhibitors of an investment thesis. There is also a need to provide context around the investment necessary for remediation, both in terms of time and capital. At the end of the day, scalability concerns can meaningfully impact valuation, and may even influence a decision to move forward with a transaction.

The now well-known 2011 essay, “Why Software is Eating the World” by Marc Andreessen, has steadily manifested across every industry imaginable, including those who had initially declared themselves exempt. Software is indeed eating the world, and as companies increase their reliance on codebases to realize their mission, having an effective mental model for thinking about scalability is important for technologists and financial stakeholders alike.

Being able to effectively assess technical scalability requires sufficient understanding of solution orientation and leveraging this to identify the factors that are both appropriate and high impact. Most meaningful discussions around technical scalability start here.

The remainder of this paper attempts to lay out a framework for considering the various scalability factors that could impede (or unlock) business growth objectives. These should be viewed as a series of evaluation lenses, and their relative applicability is scenario-dependent.

Understanding solution orientation: What does the platform do?

Solution orientation is a structured way of describing the purpose of a particular platform or product. This is a precursor to evaluating scalability, providing the necessary context to prioritize the relative impact of different scalability factors.

Next, we will consider a couple of (fictitious) examples for illustration.

Recognizing a shift in solution orientation can uncover key scalability concerns

Most investment opportunities are driven by an expectation of healthy organic growth, driven by secular trends, strong management, or addressable whitespace. This implies that the underlying solution orientation will remain relatively stable over the hold period. 

In certain cases, however, a solution orientation may require some form of transformation as a result of a transaction. When a buyer or investor has determined there is an alternate operating path that can drive an improved rate of return or market position, this may require a fundamental repositioning of a solution over time. Having a full understanding of this direction is critical, as it directly impacts how scalability is assessed. A similar exercise can then be undertaken to derive a future-state solution orientation to ground discussions around transition and scale within the new opportunity space.

Having a full understanding of growth goals and future product positioning is critical, as it directly impacts how scalability is assessed. ”

How to select appropriate scalability factors and understand their impact

Defining solution orientation provides the key contextual link between a software-based asset (or broader portfolio) and its value or importance to the underlying business. Aligning the analysis to solution orientation allows us to focus on the right mix of scalability factors, while discounting those that are unlikely to be useful.

Next, each of the identified scalability metrics needs to be considered relative to the expected growth of the business. Note that the shape and characteristics of that growth are most important here, assuming uniform, organic year-over-year growth poses the risk of an asset being incorrectly evaluated if there are other considerations at play.

Metrics describing scale tend to be expressed in relative terms, with a current-level baseline (x). A series of appropriate multipliers (2x, 5x, 10x, etc.) can then be used to represent growth thresholds over the course of the investment hold. These thresholds are useful when identifying potential bottlenecks and can help prioritize urgency of remediation.

In combination, a well-defined solution orientation and thoughtfully selected scalability factors allow for an analysis that is focused on the appropriate, high risk aspects of technical and operational scale. 

Scalability areas and factors to consider: Focus on external impacts to predict future demand

The following are the major areas typically considered within a scalability evaluation. Each area contains multiple individual factors. Keep in mind that each factor is external to the solution, which should make sense since this is ultimately a readiness evaluation for a future demand scenario if no changes were made to the solution at all.

Transactional demand represents the overall change in externally driven activity across the different solution interfaces (including user interfaces, APIs, and batch processes).

Data complexity considers the factors that could impact the data environment under a future scenario. In this case, it is necessary to consider expected capability or functional improvements as they could change the underlying data needs of the solution significantly.

Usage patterns looks at how the size and shape of the end user population is expected to change over time. This includes the growth in user population, but also how the solution will be expected to meet needs for different subsets of that population.

Geographic footprint comes into play when the solution is expected to serve a broader set of countries or regions in the future. This often highlights scale limits both in terms of performance and functionality (including language, currency, and regulatory differences).

Solution deployment considers factors related to delivering capabilities and successfully onboarding new and potentially different types of users. Changes to the sources of demand can impact an existing deployment strategy.

Service reliability relates to factors that reflect the overall uptime and resiliency of a solution. This can be particularly important, for example, in situations where the solution is responsible for delivering mission-critical capabilities or supporting near real-time operations.

Human-assisted operations
are all of the human- supported activities that happen around the solution, which may be impacted by a gradual (or sudden) change in delivery scale. This includes areas such as customer support, usage analytics, and system event monitoring.

Focusing on high-impact scalability factors

While it can be comforting to envision a “fully scalable” solution, this is not really a meaningful objective. In practice, the scalability conversation should be centered around understanding a manageable collection of constraints and their impact on the investment thesis.

Note that this can (and often does) extend beyond the technical solution itself, spanning the entire software development ecosystem and operating environment.

The following questions are often helpful in analyzing and prioritizing a potential scalability factor:
  1. When is this expected to become an issue? (Urgency)
  2. What will happen if this is not addressed? (Risk)
  3. Is there a clear path to resolution? (Complexity)
  4. What is the range of investment involved? (Cost)
  5. What is the advantage of taking action? (Value)

These questions are intended to drive a deeper level of inquiry and reveal potential nuances. Ultimately, this exercise should uncover the data points needed to identify potential scalability risk, and the rough magnitude of associated remediation efforts. 

When applied across the scalability areas, this should provide significant clarity to inform which collection of targeted investments will ensure sufficient technical scale.

Making software your competitive advantage

Being able to effectively discern the nuances around technical scalability has tremendous value in the context of modeling the return of a software-focused investment. Technical and non-technical stakeholders alike should align on the current and future solution orientation in order to ensure there is a plan in place to enable sufficient scale over the investment hold period. 

As proprietary software assets become increasing integrated within businesses of all types, having a clear view of the factors that drive (and potentially limit) solution scalability will enable buyers to effectively evaluate and prioritize investments to contain risk and support growth objectives.

Explore our latest perspectives