When software is key asset in a merger and acquisition (M&A) transaction, performing software due diligence is a critical part of the process. There’s a lot to cover when it comes to this part of diligence, and you can learn more by reading our take the breadth of the process. But the focus here is on software quality.
Architectural design is a defining facet of software quality, but it is often given less attention than it deserves. Our organization performs hundreds of audits every year, usually in M&A scenarios, and we find that most clients’ process for software due diligence entails a manual review of the target’s software architecture. While that kind of review is an important aspect of software due diligence, it won’t provide a measurement of how well the code is structured and the implications that may have on future development.
Often, over time, the structure of the software itself drifts from the original architectural diagrams. That’s why complementing manual review of the architects’ intent with a tool-based analysis of the structure of the actual code enables buyers to understand the architectural health of the codebase and what will be required to improve it going forward. Will the inherent design of the software be a key asset or a drag on future development?
The target company often performs a manual review of the architecture for the acquirer. This review typically covers the functionality and design elements in flowcharts and high-level architectural component diagrams. It’s a good indication of the design skills of the architects, but it doesn’t dig into details of the actual software implementation, so it can’t easily identify specific problem areas within the codebase.
Our auditors have observed a wide range of software systems and development practices over many years, and we have found that the documented high-level design elements don’t always tell the whole story. How well this vision is adhered to and translated by the developers into functional components, and how the code within these components evolves over time, can make or break the stability and performance of a system, impact its potential to scale if workload or growth is expected, and influence the time and resources needed to maintain it. Often of key importance to an acquirer’s investment thesis is the target’s capacity to integrate easily and possibly cloud-enable either the entire system or parts of it. Without the appropriate architecture, the acquirer’s plans will be fraught with setbacks and costly to achieve.