Organizations should emphasize processes that connect the dots between software development practices, business risk and due diligence activities.
Typically, it’s businesspeople and lawyers who coordinate due diligence in an M&A transaction. A few might be former developers; often, many have gained some understanding of how software is built through osmosis and have at least an intuitive sense of technical risk. The better that attorneys, corporate development folks, and financial investors are at understanding how software is developed and where it can go off the rails, the better equipped they are to ensure their companies and clients have eyes wide open to software risks. And that allows them to better plan how to manage post close.
An organization’s software development team and process determines the attributes of its code. A well-designed process will lead to better software. The particulars of the process will drive specific attributes in the output. If developers are well-trained on application security and static application security testing (SAST) tools are routine, it’s likely that more-secure software will result.
A well-designed process is table stakes, but what’s on paper may not be what’s in practice. Only a well-governed and well-disciplined organization can stick to best practices. Too often, business pressures can drive development awry. Of course, a full security code review makes sense, but when the project is behind and the deadline for the release is looming, will the team stick to the plan? Often they don’t, and the shortcuts they take accumulate as “technical debt.”
Evaluating an organization and development process is fundamental to post-close planning. This provides a forward look at how productive the development team will be at executing the roadmap. It’s also critical, particularly in acquisitions where much of the value lies in the software, to assess what’s in the code. Defined processes may be newly implemented or not always followed. The code is where you’ll find the technical debt, the pile of security, quality, and licensing issues the team will need to clean up in addition to executing the roadmap. Just as financial debt can get out of control, so can technical debt, and “paying it off” needs to be worked into the business case.
Most acquirers do some level of organization and process due diligence themselves; that makes sense and is important. Thorough due diligence on the code complements the process evaluation to complete the picture and inform the deal and post-close integration planning. If you want to hear it from the horse’s mouth, Declan Burns, who’s seen everything that can go wrong with a software project, explains all this in webinar, “Software Construction and Business Risk: A Crash Course for Investors and Lawyers.” And I elaborate further in a pair of white papers titled “Understanding Software Development, Technical Debt, and Risk” and “Mitigating Risk in Mergers and Acquisitions.” I also recommend our software due diligence checklist; it’s the most comprehensive that we’ve seen.
Phil is the general manager of Synopsys’s Black Duck Audit business auditing the composition, security and quality of software for companies on both sides of M&A transactions. He focuses on software due diligence best practices and the M&A market. He also works closely with the company’s law firm partners and the open source community and is a frequent speaker on open source management and M&A. Phil chairs the Linux Foundation's Software Package Data Exchange (SPDX) working group which created an ISO standard for Software Bills of Materials (SBOMs). With decades of software industry experience, Phil held senior management positions at Hammer/Empirix and High Performance Systems, a startup in computer simulation modeling. He began his career in marketing and sales with Teradyne's electronic design and test automation (EDA) software group. He’s also written a book on fly fishing. Phil has an AB and an MS in engineering from Dartmouth College.