With thousands of transactions and billions of dollars spent on technology mergers and acquisitions (M&A) every year, buyers must protect their investments by conducting due diligence. M&A due diligence allows acquirers to do three important things:
Confirm the premises of the deal
Gather information to plan the integration
Identify unknown risks
When considering an acquisition, a buyer will first amass information about the target company and formulate an investment thesis. Then, the buyer would perform due diligence to integrate the target into their operation, within a predetermined window of time as agreed upon between the buyer and the target company. The buyer must figure out how the target’s people and products fit into the organization and plan integration costs which are critical to a successful outcome and future growth post investment. Then comes the process of identifying the unknown risks. Even in the best-laid plans, there are unknowns. Some unknowns put the business plan and efficacy of the investment at risk. The buyer needs to unearth and mitigate those unknown risks.
M&A due diligence for technology acquisitions typically focuses on security and legal risks. However, poor code and architecture quality can have a lasting impact especially where software assets are a significant part of the valuation of the target company. When a technology company or private equity buyer acquires a software-based product company, the technology is often the most important asset, even more valuable than existing customer base, branding or employees. In that scenario, among all the other due diligence considerations, identifying risks in the software becomes a top priority.
Technology Risks during Technology M&A
Modern software contains a mix of open source, third-party, and proprietary code. They all contribute to the following dimensions of risk:
• Legal Risks
For open source and third-party software, legal risk is the most prevalent. Being out of license compliance can have real-world consequences including lawsuits, impact on corporate reputation if sued for licensing and loss of IP if license compliance requires distribution of source code. To surface and mitigate legal problems in codebase, careful assessment should be performed highlighting obligations in open source and third-party licenses and any conflicts with their use and distribution models.
• Security Risks
To create a full risk profile of the technology being acquired, buyer must examine its security risk across multiple dimensions. Issues with the architecture, proprietary code or open source components could lead to points of weakness making the software vulnerable to attack. The consequences associated with such vulnerabilities include data breaches, regulatory issues and unplanned work to resolve security issues. A security evaluation must identify high-level design flaws and ensure security controls are designed into the architecture. Next, it must analyze the proprietary code for security bugs externally using ethical hacking and internally using application testing tools. Finally, it must examine open source and third-party components for known vulnerabilities.
• Software Quality Risks
Although Software Quality Risk may not appear to have as immediate an impact as legal or security risks but it does have a significant effect insidiously. Low-quality code written in a nonmodular way is hard to maintain and makes it difficult to add features, fix bugs, and patch vulnerabilities. Low-quality code creates technical liability including non-value-adding efforts such as bug fixes, brittle code maintenance, code refactoring that must occur to keep the codebase functioning. It imposes a burden that eats away resources from the future and reduces developer availability. Poor quality software can slow integration and blow the business case for an acquisition.
Software Audits
A software audit is an internal or external review of a software program to check its quality, progress or adherence to plans, standards and regulations. Software audits may be conducted for a number of reasons including verifying licensing compliance and compliance with industry standards. Code quality and Design quality are two different aspects of the source code that should be reviewed in order to check quality and sustainability. A good Software Audit incorporates both a Code Quality Audit and a Design Quality Audit to assess the source code comprehensively.
Code quality includes the extensive quality check of code line by line and function by function. The company with poor code quality won’t get sued or breached but its products may be hard to enhance and maintain. The product would be buggy and there can be a drag on every fix or feature. In order to reduce these problems company may need to redesign the code which may further require to hire more senior developers.
Code Quality Audit combines static analysis tools and manual code review to analyze code quality. It requires access to source code and libraries and focuses on quality of coding at the file and method level relative to the industry. Further, it includes comparisons to industry benchmarks to assess quality, reusability, extensibility, and maintainability in proprietary code. Various metrics and benchmarks such as Total Size of Codebase (File Size and No. of Lines), Comment Density and Ratios, Inactive to Active Code Ratio, and Quality Compliance Rates per Developer are used to quantify how well the code has been developed.
Design quality involves the hierarchical construction and architecture of the code depicting its modularity and scalability. The code should ideally have layered architecture and hierarchical dependencies between them. Each layer should have their individual APIs and bad cyclicality must be avoided. The architecture update of the code is time consuming, thus fixing poor design quality is a slow process.
Design Quality Audit combines the skills of experienced architects and powerful architectural analysis tools to assess overall architecture in terms of modularity and hierarchy, thus rounding out a complete picture of the health of the software. It includes an analysis of how the architecture affects maintainability and identifies potential risk areas that are candidates for code refactoring. Metrics such as Open Source vs. Proprietary Code, Number and Ratio of Classes and Methods and File Interdependencies are used to quantify how the code has been designed.
A great architecture can have a poor implementation, and vice versa, so it’s important to dig into the quality of the code. Ideally, the proprietary code is well written and the open source components are up to date and well supported by the community. The quality of code greatly affects the economic aspect of the product. An unhealthy code with lots of bugs would decrease developer’s productivity as he has to spend more time fixing those bugs. Had the code been architecturally sound, this time could have been used to develop new features. It directly affects the revenue generation and optionality for new businesses. Moreover, the safety of an unhealthy code would always remain a question and would result in decreased cyber reliance of the product.
It is therefore important to understand the holistic risk when evaluating software assets in M&A. Poor quality design and unhealthy code can slow integration, impede fixing and improving software whereas healthy code can increase developer’s efficiency, cost reduction and enhance safety.