At Bulger Partners, we look at a lot of software companies in due diligence engagements for technology oriented investors. These companies span many vertical market sectors, including healthcare IT, SMB office software, various enterprise application sub-sectors, financial services, and ERP/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 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 year over year. 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 take a 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 achieve top tier metrics.
The pre-eminent 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 multi-year (typically 3-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.
An area of importance for investors is the product roadmap, or a company’s plan for future product evolution and growth. The roadmap is often owned by the Product Management organization or jointly with the R&D organization. Typically, there is a near term product roadmap covering a rolling 12-18 months of product development, and a long term roadmap which looks out 3-5 years. The near term roadmap 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 roadmap should be more strategic, looking at adding new capabilities, expanding markets, and ensuring long term sustainability and growth of the product.
We often see roadmaps 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 timeframe. Obviously, the near term roadmap should be more detailed in terms of actual features and delivery dates, but long term roadmaps 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 roadmap and, in particular, its ability to support the company’s growth plan.
A good company will:
- Have a detailed product roadmap outlined by quarter for the next 12-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 roadmap 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 roadmap
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 ensures 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 ensures 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: the programming language, supporting frameworks, databases, and other 3rd party services that are used to develop the product. The tech stack is an important choice early in the lifecycle of the product. There are many tech stacks in use today in modern software development, Java/J2EE and Microsoft .NET/C# being the most prevalent in current products. At some level, it doesn’t really matter which stack is chosen. Successful products have been built in different stacks, and there are plusses and minuses 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:
- 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 which 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 silo’ing 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 (SOA), multi-tier architectures, parallel processing architectures, etc. 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, Service Oriented Architectures have become common. 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/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 the product scales with usage
- Extensibility – how easy is it to extend or enhance product functionality without rewriting the underlying platform or rearchitecting it.
- Integratability – how easy is it to integrate with other products or to use 3d 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, 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, access controls in the architecture
- Complexity – how complex is the architecture of the application, 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 in order 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, application servers, etc. 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 roadmap.
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 2 of this article (next month) we will address Open Source Software, governance, hosting & security, organization and process of the R&D organization, software development lifecycle, and testing.