At EY-Parthenon, we look at many software companies in due diligence engagements for technology-oriented investors. These companies span many vertical market sectors, including health care IT, SMB office software, various enterprise application subsectors, financial services, and enterprise resource planning (ERP) and human capital management (HCM). There is a lot of commonality across these companies, which leads to the question, “What makes a good software company?”
At the top level, revenues, income in the form of EBIDTA and year-over-year (YoY) revenue growth are familiar metrics that define a good company. Everyone wants a $100m revenue company with 90% gross margins, 40% EBITDA margins and 20% growth of the top line YoY. But drill down a little further, and there are other elements that make a good software company that are worth exploring in more detail.
In this multi-part article, we look at the deeper elements that go into a good software company, how we assess them and some potential pitfalls that companies fall into. While the bottom line is financial, these sometimes less-tangible traits help measure a company’s ability to grow into a company whose financial performance can meet or exceed top-tier metrics.
The preeminent business model for installed software has been the perpetual license with an annual fee for maintenance and updates, typically 20% of base license cost. Over time, as companies have moved to software as a service (SaaS), where software is delivered as a web-based application running on the vendor’s servers (or in the public cloud), the model has moved to a subscription basis on an annual or multiyear (typically three-year) basis.
The move away from perpetual licensing means that companies are not limited to the 20% annual maintenance fee and can move to a recurring revenue model, which supports smoother growth, as opposed to large chunks of up-front revenue for perpetual licenses.
Product road map
An area of importance for investors is the product road map, or a company’s plan for future product evolution and growth. The road map is often owned by the product management organization or jointly with the R&D organization. Typically, there is a near-term product road map covering a rolling 12 to 18 months of product development, and a long-term road map, which looks out three to five years. The near-term road map is often more tactical, addressing immediate demands of the market with new features, integration with other products and services, and projects to improve performance or scalability. The long-term road map should be strategic, looking at adding new capabilities, expanding markets, and confirming long-term sustainability and growth of the product.
We often see road maps that are either too tactical, focused only on immediate needs and customer demands, or too vague in terms of things that can actually be achieved economically and in a reasonable time frame. Obviously, the near-term road map should be more detailed in terms of actual features and delivery dates, but long-term road maps need to be articulated with a certain amount of credibility about the company’s ability to execute on them.
We look at the quality of the product road map and, in particular, its ability to support the company’s growth plan.
A good company will:
- Have a detailed product road map outlined by quarter for the next 12 to 18 months
- Develop a rolling product calendar covering the next six quarters
- Balance short-term customer needs, infrastructure projects (sometimes referred to as technical debt remediation) and product growth opportunities
- Have a strategic two- or three-year long-term road map that connects to the company’s growth plan and can be credibly executed
- Have a product portfolio management process that evaluates and prioritizes potential additions to the product road map
Architecture is the high-level design or structure of a product. It is owned by the R&D organization, usually headed by a chief architect and supported by product architects attached to the development teams.
Architecture provides the “rules of the road” for building applications. It confirms that the technology stack (programming languages, frameworks, tools and services) is consistent and vetted for fit for purpose. It governs the type of solutions that developers can propose and implement, which ultimately controls product maintainability, performance, scalability and ability to evolve to meet future needs without requiring a wholesale rewrite.
There are many aspects of architecture that come into play in developing a product or a suite of products:
- Choice of tech stack
- Choice of architectural pattern or overall structure
- Definition of a governance process for selecting new third-party or open source licensed software used in the product
- Definition of an architectural review process that verifies that proposed solutions conform to the “rules of the road” set out for developing new solutions
Good software companies have a strong architectural practice that tends to these aspects. This is especially important for larger companies that have multiple products and companies that grow through acquisition. But even for smaller, single-product companies, good architecture makes the difference between a company that can grow smoothly and strategically with positive EBITDA, and one that is “a mess” and stuck with a disparate set of products that cannot be integrated or evolve for growth without significant investment in rewriting code.
The best companies, and particularly companies with multiple products, have an architecture review board that is chaired by the CTO or chief architect and includes architects or senior developers from each of the product teams.
Let’s look at each of the aspects of architecture in more detail.
The tech stack is the programming language, supporting frameworks, databases and other third-party services that are used to develop the product. The tech stack is an important choice early in the life cycle of the product. There are many tech stacks in use today in modern software development. At some level, it doesn’t really matter which stack is chosen. Successful products have been built in different stacks, there are pros and cons with all of them, and personal preference and experience of the development teams is often a guiding factor in the choice.
The most important things relative to the tech stack are arguably as follows:
- It is widely used – mainstream programming languages mean it’s easier to find good developers, often the most critical resource in a software company.
- It has good fit for purpose – a high throughput financial application has different needs than a large-scale web application, etc.
- It is able to support product scalability and evolution – can the tech stack chosen carry the company through many years of growth and technology change?
One of the biggest issues that larger companies face, especially those that have grown through acquisition, is that there are multiple tech stacks in use in different parts of the company and different products (and sometimes in the same product). This can lead to “siloing” of the R&D organization. Developers in different tech stacks cannot be easily moved from one product to another. Sometimes, however, this cannot be avoided. A red flag is a proliferation of languages and tech stacks within one company or within a product.
A well-architected software product conforms to a well-known architectural pattern. Examples of architectural patterns are Service-Oriented Architectures (SOAs), multi-tier architectures and parallel processing architectures. These patterns have been developed over time to fit particular types of applications. They control the ability of the product to scale and to evolve.
For example, in a loosely coupled architecture, different components of the software do not have internal dependencies on one another, meaning that they can be developed somewhat independently and integrated based on a set of contracts, or rules for how they interact. Older, tightly coupled architectures mean that there is more shared assumption about how the pieces work together, and they are less easy to evolve.
With the proliferation of web-based SaaS applications, SOAs have become common. An SOA fosters a number of positive attributes in creating applications: separation of presentation (user interface) from business logic and common services, like data persistence, loose coupling and move of application infrastructure to the cloud (i.e., a public Infrastructure as a service, such as Amazon Web Services). Most mobile applications are built on an underlying SOA.
Software companies with legacy products that have not kept up-to-date with modern architectural patterns like SOA are harder to evolve and costlier to maintain. These include older client and server architectures, such as thick client desktop applications that have more dependencies between client and server components, mainframe-based applications (though mainframes can play as back-end processors in more modern SOA systems), batch-oriented applications, and older-style web applications with dated web application servers. Often, these older architectures must be replaced by wholesale rewrites or hybrid evolution strategies that can be quite costly.
The “-ilities” – assessing the architecture
When we evaluate product architectures, we assess a number of factors that bear on the quality of the architecture:
- Scalability – how does the product scale with usage?
- Extensibility – how easy is it to extend or enhance product functionality without rewriting the underlying platform or re-architecting it?
- “Integratability” – how easy is it to integrate with other products or to use third-party products within the application?
- Reliability – how reliable is the application based on architectural factors?
- Maintainability – how easy is the software to maintain over time and keep up-to-date with underlying operating system, database or other middleware changes?
- Reusability – can code and services that make up the application be reused in other products of the family?
- Security – has attention been paid to data security, penetration by malicious parties and access controls in the architecture?
- Complexity – how complex is the architecture of the application, and are there many moving parts and complicated interfaces?
We also look at use of open source and third-party software in the product (see below), use of well-known architecture patterns and adherence to standards when evaluating an architecture.
All of these architectural factors bear on how much it will cost to maintain and evolve the software, and how it will respond to growth in usage over time.
One other important aspect of cost to maintain, evolve and grow a software product that is particular to enterprise software applications is client customization. Large-scale applications that have significant implementation costs will often include customizations that are specific to client needs. These can be as simple as placing a client logo on a login banner, to customizing user interface screens for particular customer needs, to supporting specific business processing rules that vary by customer. Especially in legacy installed products, client customization can result in a significant amount of custom code that must be maintained as the product is evolved. This can be a barrier to moving to new technology platforms or just having customers adopt updated versions of the product.
If client customization features are designed into the product, they can be built in such a way as to be portable when the software is upgraded or evolved. For example, there are third-party software “rules engines” that can allow sets of “if-then-else”-style business rules that support custom business logic in a way that can be supported by business analysts rather than requiring extensive bespoke product code modification. User interface customization mechanisms that allow different fields to be suppressed, customer logos and design themes can also limit the impact of these types of customizations.
Products that require a lot of custom development to support client customizations can be difficult to adapt and modernize without high costs.
Technical debt remediation is work that is required to keep software systems up-to-date that does not include upgrading or adding to functionality. It may include updating for current versions’ third-party software components, such as databases, operating systems and application servers. It may also include the need to rewrite software systems to replace older, out-of-date architectures such as those discussed above. Technical debt is typically measured by the amount of effort required to perform these types of tasks, either in terms of man-months or dollar costs.
All software systems develop technical debt over time. Paying off technical debt is analogous to maintaining a house: to stay in good repair, a house must be painted regularly, the roof must be replaced over time, and systems in the house, like the heating system, must be kept up-to-date. It is important for software companies to keep track of technical debt and to have a process in place to prioritize the retirement of technical debt alongside functional enhancements in the product road map.
When we evaluate a software company, we look at both the amount of technical debt that has accumulated around the product, as well as the processes for managing the debt. A good company has a manageable amount of technical debt and good processes for managing and retiring debt. The architecture team is usually the responsible organization for defining and running this process.
Large amounts of technical debt may require a purchaser to increase R&D investment, especially if the debt impedes the ability for the company to evolve the product for growth. Companies that do not have processes to track technical debt may have increased financial, product and support risk.
In Part II of this article, we will address open source software, governance, hosting and security, organization and process of the R&D organization, software development life cycle, and testing.
EYG no. 011580-18Gbl