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.
The importance of design quality
A well-designed software system allows developers to understand the various component parts and gain a clear sense of the relationships between those functional areas. In an audit, a combination of interview-based and tool-based analysis help us reveal the reality of the implemented architectural design, so buyers can better understand the layout of the system, the layout of the team, and the ways developers think about their code and manage their organizations. Well-designed code is nicely hierarchical and modular, with no one module too big for an individual developer to understand. This practice allows for easy maintenance and feature additions.
Unfortunately, we find that in 80% of complex codebases, there’s a discrepancy (sometimes a significant one) between how architects and managers in the target company believe their code is built, and what developers have actually coded into their system.
Figure 1. Manager’s view of the software as modular.
Figure 2. The reality is often low modularity and high dependencies.
Factors to assess during software due diligence
Over time, it’s not unusual for implementation details to stray from the intended architecture, and so the architecture diagrams reflect the current system less and less. Developers are often on tight deadlines to ship new or improved system functionality and are forced to skip best practices like code reviews and maintenance, automated testing, or secure programming practices. Similarly, organizations often lack the discipline to maintain conformance to the defined architecture.
Lack of testing and related best practices can also lead to codebases that stray from the intended design criteria, and the logic defined by the code can become tangled and brittle to change. Testing the functionality of messy code that is highly interdependent can be challenging and time-consuming. A codebase that breaks with a small change is difficult to maintain, let alone to evolve. All these factors should be assessed as part of software due diligence, so the acquiring company can understand things like
- How much time and cost will be associated with making code changes in the future?
- How much time are developers spending fixing brittle code vs. shipping new functionality?
- Is it necessary to refactor parts of the codebase?
- What would be the costs and benefit of this acquisition?
Benefits of a design quality audit in software due diligence
A Black Duck® Design Quality Audit serves as a bridge between the intended architecture and the actual implementation to provide a complete picture of the overall design quality of the target company’s software systems. This type of audit is also useful for measuring the modularity of a system and identifying problematic components. It provides insight at the source code level and assesses the maintainability of the system as well as the underlying components.
By using sophisticated tooling to analyze the actual code, we can discover areas where modularity in a codebase has broken down in ways the developers often don’t understand. For example, we identify highly interdependent pieces of code that can be difficult to maintain and enhance. The more direct or indirect cyclical dependencies a codebase contains, the higher the chances of defects being introduced as developers work on it. This is important because studies have shown that these architectural “hotspots” (known as cores in academic literature) are also places with significant defects and where developer productivity grinds to a halt. Rapid and automated design quality analysis can identify these risky hotspots, like the ones called out in the unhealthy architecture in Figure 3, so a plan can be put in place to fix them and move toward a healthier, modular, layered, and hierarchical architecture like the healthy architecture in Figure 3.
Figure 3. How component dependencies impact architecture.
Higher defect rates and diminished developer productivity lead to longer development times, which lead to increased costs, degraded planning estimations, and delayed releases. A Design Quality Audit will both zero in on areas of concern and provide estimates for maintenance costs and expected defect rates as new features are added to the system.
In addition to identifying trouble spots, the audit also assists with the difficult decision of whether to refactor an existing codebase or rewrite components to improve overall quality, and it can provide the ability to better estimate this level of effort. Expert review of audit data can also help uncover underlying organizational issues such as lack of focus on testing or a shortage of experienced technical resources. Acquirers that are faced with evaluating a target company’s software systems must adopt a multipronged approach to this analysis to ensure they have all the information they need to plan for a potential integration.
Software due diligence: A buyer's checklist and guidelines
Continue Reading
